タグ付けされた質問 「design」

この質問は、Software Engineering Stack Exchangeで回答できるため、Code Review Stack Exchangeから移行されました。 6年前に移行され ました。 現在、C ++向けにEntity Systemを再設計しています。多くのマネージャーがいます。私の設計では、ライブラリを結合するためにこれらのクラスがあります。「マネージャー」クラスに関しては、多くの悪いことを聞いたことがあります。おそらく、クラスに適切な名前を付けていません。しかし、他にどのような名前を付けるべきかはわかりません。 私のライブラリーのほとんどのマネージャーは、これらのクラスで構成されています（ただし、多少異なります）。 コンテナ-マネージャ内のオブジェクトのコンテナ 属性-マネージャー内のオブジェクトの属性 ライブラリの新しいデザインには、ライブラリを結び付けるために、これらの特定のクラスがあります。 ComponentManager-エンティティシステムのコンポーネントを管理します ComponentContainer コンポーネント属性 シーン*-シーンへの参照（以下を参照） SystemManager-エンティティシステム内のシステムを管理します SystemContainer シーン*-シーンへの参照（以下を参照） EntityManager-エンティティシステム内のエンティティを管理します EntityPool-エンティティのプール EntityAttributes-エンティティの属性（これはComponentContainerおよびSystemクラスのみがアクセス可能です） シーン*-シーンへの参照（以下を参照） シーン-すべてのマネージャーを結び付ける ComponentManager SystemManager EntityManager Sceneクラス自体にすべてのコンテナ/プールを配置することを考えていました。 すなわち これの代わりに： Scene scene; // create a Scene // NOTE: // I technically could wrap this line in …

26 design  design-patterns  c++  class  entity-component-system 

言語が商用ソフトウェアと同じと見なされる場合、新しいリリースを正当化するために常に新しい機能を追加する必要が常にあることがわかります。 バージョン1.0が最終バージョンである言語は存在しますか、または存在しますか？もちろん、バグ修正はこれを免除されますが、機能セットは常に同じままですか？ この方法では、言語のすべての機能がうまく適合し、後方互換性のために廃止された機能がまだ残っているという事実の後にボルトで固定されているようには見えません。 いくつかの学術言語はこのようなものだと思いますか？しかし、この考えに従って商業的に成功した言語はありますか？付属のライブラリも新しい機能を無料で入手できますが、言語は常に一定です。 私が挙げることができる一例は、私がよく使用するお気に入りの言語C＃の1つです。リリースごとにますます多くの機能が追加されています。これらを活用するには、些細な概念を取り上げてそれらを組み合わせてより複雑な問題を簡単に解決するのではなく、実際のタスクを手元に落とし、これらの学習にかなりの時間を費やさなければなりません。 だから私は、すべてが一貫し、理にかなっており、可能な限り直交するミニマリストのアプローチを探していると思います。

26 programming-languages  design  language-design  languages  commercial 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 2年前に閉店。 地球上の住所に適した地理的な住所/場所の正しい形式は何ですか？今のところ： 国 シティ 通り 数 テキストデータ（簡単にするため） zip 緯度/経度 しかし、私はそれを改善できると信じています。国の州/地域または地域のようなものがあるかもしれません。または、シンガポールや香港には、地域/地域/州はありません。 通りはないかもしれませんが、道路や大通りなどがあります。多数の建物が複合している場合があります。床があるかもしれません。部屋番号。等....

25 design  database  database-design  database-development 

私が出会ったOOP原則の1つは次のとおりです。-さまざまなものをカプセル化します。 私はフレーズの文字通りの意味が何であるかを理解しています。しかし、私はそれがより良いデザインにどの程度貢献するのかわかりません。誰かが良い例を使って説明できますか？

25 design  design-patterns  object-oriented  encapsulation 

同僚と少し議論をしました。簡単に言えば、純粋な関数を非表示/カプセル化する正当な理由はありますか？ 「純粋」とは、ウィキペディアの定義を意味します。 同じ入力から常に同じ結果を返します。（この説明のために、値のセマンティクスがないFoo Create(){ return new Foo(); }場合Fooは不純であると見なされます。） 可変状態（ローカル変数を除く）またはI / Oは使用しません。 副作用を引き起こしません。

25 design  pure-function 

モバイルアプリケーションを開発したい。最近、Telerik Forumの記事を読みました。この記事では、3種類のモバイルアプリケーションを比較していますが、どちらを選択すればよいかわかりません。以下は、さまざまなモバイルデザインの選択の長所と短所を説明する画像です。 これらの設計の選択を決定するために、図にリストされている各アーキテクチャの選択の長所と短所をよりよく理解したいと思います。各アーキテクチャアプローチの長所と短所は何ですか？

25 design  architecture  programming-practices  mobile 

私の職場では、「アジャイル」とは「あいまいな要件、受け入れ条件の悪さ、幸運」を意味することが多いという課題に直面しています。私たちは、一般的な改善努力として、それに対処しようとしています。 そのため、その一環として、ユーザーストーリーレベルを超えて、システム内の特定の機能の影響の予備調査の結果を正確に反映し、私たちが持っている質問への回答を含む設計ドキュメントを生成することを提案していますビジネスに尋ねた。 これに効果的な基準はありますか？ 現在、新しい機能が「泥の大玉」システムの複数の領域に影響を与える可能性がある状況に直面しており、この技術的負債により見積もりが上昇し始めています。うまくいけば、より思慮深い設計プロセスが役立つことがあります。

25 design  agile  documentation 

変更のための先見の明を持つ外部アプリケーション用のAPIを設計しようとすることは簡単ではありませんが、少し前もって考えておくことで、後で生活が楽になります。私は、以前のバージョンのハンドラーをそのままにしておくことで、後方互換性を維持しながら将来の変更をサポートするスキームを確立しようとしています。 この記事の主な関心事は、特定の製品/会社に対して定義されたすべてのエンドポイントでどのパターンに従う必要があるかです。 基本スキーム のベースURLテンプレートを考えると、https://rest.product.com/すべてのサービスが/api、/authおよびなどの他の非レストベースのエンドポイントと共に存在することを考案しました/doc。したがって、次のようにベースエンドポイントを確立できます。 https://rest.product.com/api/... https://rest.product.com/auth/login https://rest.product.com/auth/logout https://rest.product.com/doc/... サービスエンドポイント 次に、エンドポイント自体について説明します。懸念はPOST、GET、DELETEこの記事の主な目的ではなく、それらのアクション自体に懸念されます。 エンドポイントは、名前空間とアクションに分類できます。また、各アクションは、戻り値の型または必須パラメーターの基本的な変更をサポートする方法で表示される必要があります。 登録されたユーザーがメッセージを送信できる架空のチャットサービスを利用すると、次のエンドポイントがある場合があります。 https://rest.product.com/api/messages/list/{user} https://rest.product.com/api/messages/send 今度は、壊れる可能性のある将来のAPI変更に対するバージョンサポートを追加します。私たちは、どちらかの後にバージョンの署名を追加することができ/api/たりした後/messages/。与えられたsendエンドポイント我々は、v1の以下のものを持つことができます。 https://rest.product.com/api/v1/messages/send https://rest.product.com/api/messages/v1/send だから私の最初の質問は、バージョン識別子の推奨場所は何ですか？ コントローラーコードの管理 そのため、以前のバージョンをサポートする必要があることを確立しました。そのため、時間の経過とともに廃止される可能性のある新しいバージョンのそれぞれのコードを何らかの方法で処理する必要があります。Javaでエンドポイントを記述していると仮定すると、これをパッケージで管理できます。 package com.product.messages.v1; public interface MessageController { void send(); Message[] list(); } これには、すべてのコードがネームスペースを介して分離されているという利点があります。この場合、重大な変更はサービスエンドポイントの新しいコピーを意味します。これの不利な点は、すべてのコードをコピーする必要があり、新しいバージョンと以前のバージョンに適用するバグ修正を各コピーに適用/テストする必要があることです。 別のアプローチは、エンドポイントごとにハンドラーを作成することです。 package com.product.messages; public class MessageServiceImpl { public void send(String version) { getMessageSender(version).send(); } // Assume we have …

25 design  design-patterns  web-services  rest  services 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 6年前に閉鎖されました。 ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 図をどこかに保存して後で編集できるようにする必要がある場合、ほとんどの設計/建築作業にMS Visioを使用します。私はVisioの最大のファンではありませんが、仕事を終わらせます（仕事中は無料です）。 かなり高価なVisioソフトウェアに代わる優れた代替品があり、おそらくもっと良いものがありますか。私は確かにツールボックスにそのプログラムを持ちたいです！

25 design  architecture  visio 

このStack Overflowの質問は、ポインターを介して親を参照している子に関するものです。 最初は、デザインがひどいアイデアであるというコメントは非常に重要でした。 私はこれがおそらく最善のアイデアではないことを理解しています。一般的な経験則から、「これをしないでください！」 ただし、このようなことを行う必要がある場合、どのような条件が存在するのか疑問に思います。ここでのこの質問と関連する回答/コメントは、グラフでもこのようなことをしないことを示唆しています。

24 design 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 12か月前に閉鎖されました。 ユーザーが1日に1回しかアクションを実行できない場合（たとえば、コンテストの無料チケットを取得する場合）、私の経験で出会った2つの可能性があります。 1）24時間リセット 1日目の午後11時45分にアクションを実行する場合、2日目の11時45分以降にのみアクションを実行できます。彼は2日目の11:44にそれを行うことができません。 2）ミッドナイトリセット（または任意の固定時間） ユーザーが1日目に何時にアクションを実行しても、深夜になり2日目が始まるとすぐに、再びアクションを実行できるようになります。 どちらもユーザーが1日に1つのアクションしか実行できないように制限しますが、ほとんどの場合、方法1に遭遇します。 最初に私は時間を待たなければなりません 長い期間にわたって2番目に、アクションを実行する私のタイムスタンプは、数秒または数分後にそのタイムスタンプで毎日正確にアクションを実行することができないため、ますます遅くなります。 私の意見では事前に述べたユーザーにとっての重大な不利益はありますが、方法1を好むという技術的な理由はありますか？ 編集して、指定します。特に、現在の 24時間ごとに1つのフリースピンを獲得するTheory11のフリースピンイベントのように、24時間の実際のタイムギャップは明らかに必要ではない例について話しています。入賞時。

24 design  programming-practices  coding 

アプリケーション用のデータベースを設計する際の一般的なベストプラクティスをいくつか知っていますが、再設計についてはどうですか？ 私は「内部」と言っているにも関わらず、内部ビジネスアプリケーションの再設計を担当するチームに所属していますが、残念ながら、システムの実際のユーザーとの接触から多くの層の人々がいます。 現在のプログラムはOracle Formsにあり、非正規化された多数のテーブルに散らばっています。場合によっては、互いのデータにわずかな異形を持つ複数のほぼ重複したテーブルがあります。多くの場合、制約は、適切に実施されていないストアドプロシージャの形式です。型でさえ正しく保存されていないようです。Oracleが無視しているように見えますが、SQL Serverのインポート/エクスポートウィザードに適合する（そして当然のことながら）あらゆる種類の不正なデータに遭遇しました。（たとえば、2桁の整数は完全な日時を構成しません！） 元のプログラムはおそらく20年前に遡り、元の開発者は皆かなり前に退職しているため、ここの年配の人でさえ自分が誰であるかわかりません。その結果、明確な要件をクリアする必要もありません。既存のアプリケーションの機能を複製し、既存のデータを保持するだけです。 書き換えの最終結果は、バックエンド用のMS SQL Serverを備えたASP.NET上で実行されるWebベースのバージョンになります。 私の他の2人の開発チームメイトは、私よりはるかに年上で、どちらもビジネス/ MISのバックグラウンドを持っていますが、私の場合はCSです。シニアメンバーの経験はほとんどOracleフォームのみであり、他のメンバーはほとんどがVisual Basicでビジネスアプリケーションの作業を行っています。私のデータベースの背景は、MySQLまたはSQLiteのプロジェクト用の新しいデータベースの設計に限られていますが、ほとんどは私の学部クラスですが、実際にデータベースを設計した経験があるのは私だけです。 既存のすべてのデータをニュートラル形式に読み込み、再キャストして新しいデータベースに配置する準備ができたC＃で小さなプログラムを既に作成しました。宛先データベースの設計後にロードインコードを記述することで、データを新しい正規化されたテーブルに適切に分割し、新しい順序に従って正しい順序で追加するなどして、同じプログラムを後で実行できるようにする予定です。生産データを実際に新しく展開された再設計にコピーします。これにより、データベースの実際の再設計が主要な問題として残ります。 だから私の質問の中心：既存のアプリケーションのデータベースレベルアップから再設計を行うためのいくつかのベストプラクティスは何ですか？

24 database-design  design 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 閉じた3年前。 最近、Three Big Liesのブログ投稿を読みましたが、2番目の嘘を正当化するのに苦労しています。 （嘘＃2）コードは世界のモデルの周りに設計されるべきである コードが架空の世界の何らかのモデルまたはマップであることには価値がありません。一部のプログラマにとってこれがなぜこれほど魅力的であるかはわかりませんが、非常に人気があります。ゲームにロケットがある場合は、「ロケット」クラス（コードはC ++であると仮定）があり、これには1つのロケットのデータのみが含まれ、ロケットのような処理を行うことをご安心ください。どのデータ変換が実際に行われているか、またはデータのレイアウトはまったく考慮されません。または、1つのことはどこにあるのかという基本的な理解がなければ、おそらく複数あります。 この種の設計には多くのパフォーマンス上のペナルティがありますが、最も重要なことは、スケーリングしないことです。まったく。ロケット100個のコストは、ロケット1個の100倍です。そして、それ以上の費用がかかる可能性が非常に高いです！プログラマーでなくても、それは意味をなさないはずです。規模の経済。何かがもっとあるなら、それはもっと高くなくて、より安くなるはずです。そして、それを行う方法は、データを適切に設計し、同様の変換によって物事をグループ化することです。 特にこの嘘に関する私の問題はここにあります。 想像上の世界をモデル化することは、コードを視覚化して整理するのに役立つので、仮想的な世界のモデル/マップであるコードには価値があります。 「ロケット」クラスを持つことは、私にとって、クラスにとって完全に有効な選択です。「ロケット」は、AGM-114ヘルファイアなどのタイプのロケットに分類できます。これには、ペイロードの強度、最大速度、最大旋回半径、ターゲットタイプなどが含まれますが、発射されるすべてのロケットには位置が必要ですそして速度。 もちろん、100個のロケットを所有するには1ロケット以上かかります。画面上に100個のロケットがある場合、それらの位置を更新するには100個の異なる計算が必要です。2番目の段落は、100個のロケットがある場合、状態を更新するのに100未満の計算コストが必要だと主張しているように聞こえますか？ ここでの私の問題は、著者が「欠陥のある」プログラミングモデルを提示しているが、それを「修正」する方法を提示していないことです。おそらく、ロケットクラスの類推につまずいているかもしれませんが、この嘘の背後にある理由を本当に理解したいと思います。代替手段は何ですか？

23 design  programming-practices 

私はデザインに取り組んでいますが、引き続き障害にぶつかっています。私は特定のクラス（ModelDef）を持っています。これは、本質的にXMLスキーマを解析することで構築された複雑なノードツリーの所有者です（DOMを考えてください）。優れた設計原則（SOLID）に従い、結果のシステムを簡単にテストできるようにします。DIを使用してModelDefのコンストラクターに依存関係を渡すつもりです（テスト中に必要に応じてこれらを簡単に交換できます）。 しかし、私が苦労しているのは、ノードツリーの作成です。このツリーは、個別にテストする必要のない単純な「値」オブジェクトで完全に構成されます。（ただし、これらのオブジェクトの作成を支援するために、Abstract FactoryをModelDefに渡すことができます。） しかし、私は、コンストラクターが実際の作業を行うべきではないことを読み続けています（例：Flaw：Constructor does Real Work）。「実際の作業」とは、後でテストのためにスタブアウトする可能性のある重い依存オブジェクトを構築することを意味する場合、これは私にとって完全に理にかなっています。（これらはDI経由で渡される必要があります。） しかし、このノードツリーなどの軽量の値オブジェクトはどうでしょうか。ツリーはどこかに作成する必要がありますよね？ModelDefのコンストラクター（buildNodeTree（）メソッドなどを使用）を使用しないのはなぜですか？ ModelDefの外でノードツリーを作成してから（コンストラクターDIを介して）渡したいとは思いません。スキーマを解析してノードツリーを作成するには、かなりの量の複雑なコードが必要です。 。私はそれを「グルー」コードに委ねたくありません（これは比較的簡単なはずで、おそらく直接テストされません）。 ノードツリーを作成するためのコードを別の「ビルダー」オブジェクトに入れることを考えましたが、実際にはビルダーパターン（テレスコープの排除に関心があると思われる）と一致しないため、「ビルダー」と呼ぶことをためらいます。コンストラクター）。ただし、別の名前（NodeTreeConstructorなど）を呼び出したとしても、ModelDefコンストラクターがノードツリーを構築するのを避けるために、ちょっとしたハックのように感じます。どこかに構築する必要があります。なぜそれを所有しようとしているオブジェクトではないのですか？

23 java  design  design-patterns  dependency-injection  constructors 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 私は最近ソフトウェア設計のコースを受講しており、サービスのコンポーネントが可能な限り独立したマイクロサービスサブコンポーネントに分離される「マイクロサービス」モデルの使用について、最近の議論/推奨がありました。 言及された部分の1つは、すべてのマイクロサービスが通信する単一のデータベースを持つという非常によく見られるモデルに従うのではなく、マイクロサービスごとに個別のデータベースを実行することでした。 これについてのより適切な言葉で詳細な説明は、http：//martinfowler.com/articles/microservices.htmlの分散型データ管理セクションにあります 。 これを言っている最も顕著な部分： マイクロサービスは、各サービスが独自のデータベース、同じデータベーステクノロジーの異なるインスタンス、または完全に異なるデータベースシステムを管理できるようにすることを好みます-Polyglot Persistenceと呼ばれるアプローチ。モノリスでポリグロット永続化を使用できますが、マイクロサービスではより頻繁に表示されます。 図4 私はこの概念が好きで、他の多くのことの中でも、保守と複数の人が取り組んでいるプロジェクトの強力な改善と考えています。とはいえ、私は決して経験のあるソフトウェアアーキテクトではありません。誰もそれを実装しようとしましたか？どのようなメリットとハードルに遭遇しましたか？

23 design  database-design  microservices