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

検証が必要なデータが大量にある場合、検証のみを目的として新しいクラスを作成する必要がありますか、またはメソッド内検証に固執する必要がありますか？ 私の特定の例では、トーナメントやイベント/カテゴリクラス企図：TournamentとEvent、モデルのスポーツ大会や各トーナメントは、1つのまたは多数のカテゴリがあります。 これらのクラスで検証するすべての種類のものがあります：プレイヤーは空である必要があり、一意である必要があり、各プレイヤーがプレイするマッチの数、各マッチが持っているプレイヤーの数、事前に定義されたマッチアップ、およびはるかに大きいなど複雑なルール。 また、クラスを相互に統合する方法など、全体として検証する必要のある部分もあります。たとえば、aのユニタリ検証はPlayer問題なく実行できますが、イベントに同じプレーヤーが2回ある場合、検証エラーになります。 では、これはどうですか？：モデルクラスのセッターや同様のメソッドを使用してデータを追加するときの事前チェックを絶対に忘れて、代わりに検証クラスにそれを処理させます。 だから我々は、のようなものがありますEventValidatorとのEventメンバーとして、そしてvalidate()すべてのメンバーのルールを検証するために、オブジェクト全体を検証する方法に加え、特異な方法を。 次に、有効なオブジェクトをインスタンス化する前に、無効な値を防ぐために検証を実行します。 私の設計は正しいですか？私は何か違うことをすべきですか？ また、検証メソッドを返すブール値を使用する必要がありますか？または、検証が失敗した場合に例外をスローしますか？私にとって最良のオプションは、メソッドを返すブール値であり、オブジェクトがインスタンス化されたときに例外をスローすることです、例えば： public Event() { EventValidator eventValidator = new EventValidator(this); if (!eventValidator.validate()) { // show error messages with methods defined in the validator throw new Exception(); // what type of exception would be best? should I create custom ones? } }

15 java  design  data  validation 

関数Fを実装するソフトウェアモジュールAがあるとします。別のモジュールBは、F 'と同じ関数を実装します。 重複するコードを取り除くには、いくつかの方法があります。 AにBのF 'を使用させます。 BにAのFを使用させます。 Fを独自のモジュールCに入れ、AとBの両方に使用させます。 これらのオプションはすべて、モジュール間に追加の依存関係を生成します。カップリングを増加させる代わりに、DRY原則を適用します。 私が見る限り、DRYを適用すると、カップリングは常に増加するか、リースでより高いレベルに移動します。ソフトウェア設計の最も基本的な2つの原則の間には矛盾があるようです。 （実際、そのような競合があることは驚くことではありません。これはおそらく、優れたソフトウェア設計をそれほど難しくしていることです。これらの競合は通常、入門書では扱われていません。 編集（明確化のため）：FとF 'の等価性は単なる偶然ではないと思います。Fを変更する必要がある場合、F 'も同様に変更する必要があります。

14 design  architecture  dry  coupling 

インジェクションを受け入れるのではなく、依存関係を直接構築するクライアントが1001人いるとします。上司によると、1001のリファクタリングはオプションではありません。実際には、ソースへのアクセスさえ許可されていません。クラスファイルだけです。 私たちがやるべきことは、これらの1001クライアントが通過するシステムを「近代化」することです。好きなことをリファクタリングできます。依存関係はそのシステムの一部です。そして、それらの依存関係のいくつかは、新しい実装を行うために変更することになっています。 私たちがやりたいことは、この多数のクライアントを満たすために、依存関係の異なる実装を構成する機能を持っていることです。悲しいことに、クライアントはコンストラクターまたはセッターによるインジェクションを受け入れないため、DIはオプションのようには見えません。 オプション： 1）クライアントが使用するサービスの実装をリファクタリングして、クライアントが現在必要としていることを行うようにします。完了です。柔軟ではありません。複雑ではありません。 2）実装をリファクタリングして、ファクトリを通じて取得したさらに別の依存関係に作業を委任します。これで、ファクトリをリファクタリングすることで、すべてが使用する実装を制御できます。 3）実装をリファクタリングして、作業をサービスロケーターを介して取得したさらに別の依存関係に委任します。これhashmapで、少しのキャストが行われたオブジェクトへの文字列である可能性のあるサービスロケーターを構成することで、すべてが使用する実装を制御できます。 4）まだ考えていないこと。 目的： 設計が不十分な古いクライアントコードを無意味な複雑さを加えることなく未来にドラッグすることによって引き起こされる設計の損傷を最小限に抑えます。 クライアントは依存関係の実装を知っていないか制御するべきではありませんが、で構築することを主張しますnew。制御することはできませんnewが、構築しているクラスを制御します。 私の質問： 何を考慮しなかったのですか？ Doc Brownからの質問 異なる実装間で構成する可能性が本当に必要ですか？何のために？ 機敏。未知の多く。経営陣は変化の可能性を望んでいます。外の世界への依存を失うだけです。またテスト。 実行時の仕組みが必要ですか、それとも異なる実装を切り替えるためにコンパイル時の仕組みが必要ですか？どうして？ コンパイルの時間の仕組みで十分です。テストを除く。 どの粒度で実装を切り替える必要がありますか？一斉に？モジュールごと（それぞれがクラスのグループを含む）？クラスごと？ 1001のうち、一度に実行されるのは1つだけです。すべてのクライアントが一度に使用するものを変更しても問題はないでしょう。ただし、依存関係を個別に制御することはおそらく重要です。 誰がスイッチを制御する必要がありますか？あなた/あなたの開発者チームのみ？管理者ですか？各クライアントは自分で？または、クライアントのコードのメンテナンス開発者ですか？それでは、メカニックはどれほど簡単/堅牢/完全に機能する必要があるのでしょうか？ テスト用の開発。外部ハードウェアの依存関係が変化するため、管理者。テストと構成が簡単である必要があります。 私たちの目標は、システムを迅速に作り直し、近代化できることを示すことです。 実装スイッチの実際の使用例 1つは、ハードウェアソリューションの準備が整うまで、一部のデータがソフトウェアによって提供されることです。

14 design  refactoring  dependency-injection  factory-method  service-locator 

私はまだ見習いプログラマーであると考えているので、私はいつも典型的なプログラミングのための「より良い」方法を学ぼうとしています。今日、私の同僚は私のコーディングスタイルが不必要な仕事をしていると主張しており、他の人から意見を聞きたいと思っています。通常、OOP言語（通常はC ++またはPython）でクラスを設計するとき、初期化を2つの異なる部分に分けます。 class MyClass1 { public: Myclass1(type1 arg1, type2 arg2, type3 arg3); initMyClass1(); private: type1 param1; type2 param2; type3 param3; type4 anotherParam1; }; // Only the direct assignments from the input arguments are done in the constructor MyClass1::myClass1(type1 arg1, type2 arg2, type3 arg3) : param1(arg1) , param2(arg2) , param3(arg3) {} …

14 design  object-oriented  coding-style 

私はこれに似た2つの関連する方法でインターフェースを設計しています： public interface ThingComputer { default Thing computeFirstThing() { return computeAllThings().get(0); } default List<Thing> computeAllThings() { return ImmutableList.of(computeFirstThing()); } } 実装の約半分で計算されるのは1つだけですが、残りの半分ではさらに多くの計算が行われます。 これは、広く使用されているJava 8コードに先例がありますか？Haskellがいくつかのタイプクラスで同様のことを行うことは知っています（Eqたとえば）。 利点は、2つの抽象クラス（SingleThingComputerおよびMultipleThingComputer）を使用した場合よりも大幅に少ないコードを記述する必要があることです。 欠点は、空の実装がコンパイルされますが、実行時にStackOverflowError。を使用して相互再帰を検出しThreadLocal、より良いエラーを与えることは可能ですが、それにより、バグのないコードにオーバーヘッドが追加されます。

14 java  design  interfaces  java8 

私は、オープンクローズド原則の意図を理解しています。変更せずに拡張しようとするように指示することで、変更中に既に機能しているものを壊すリスクを減らすことを目的としています。 しかし、この原則が実際にどのように適用されるかを理解するのに苦労しました。私の理解では、それを適用するには2つの方法があります。変更前と変更後： 前：できるだけ抽象化して「未来を予測する」プログラムを作成します。たとえば、将来システムにsが追加されたdrive(Car car)場合、メソッドは変更する必要 Motorcycleがあるため、おそらくOCPに違反します。ただし、この方法drive(MotorVehicle vehicle)は将来変更する必要性が低いため、OCPに準拠しています。 ただし、将来を予測し、システムにどのような変更が加えられるかを事前に知ることは非常に困難です。 変更後：変更が必要な場合、現在のコードを変更する代わりにクラスを拡張します。 練習＃1を理解するのは難しくありません。しかし、適用方法を理解するのに苦労しているのは実践＃2です。 例（YouTubeのビデオから取得しました）：CreditCardオブジェクトを受け入れるクラスにメソッドがあるとします：makePayment(CraditCard card)。1日Voucherがシステムに追加されます。このメソッドはそれらをサポートしていないため、変更する必要があります。 そもそもメソッドを実装するとき、未来とプログラムをより抽象的な用語で予測することに失敗しました（たとえばmakePayment(Payment pay)、今、既存のコードを変更する必要があります）。 練習＃2では、変更するのではなく拡張することで機能を追加する必要があります。どういう意味ですか？既存のコードを単に変更するのではなく、既存のクラスをサブクラス化する必要がありますか？コードの書き換えを避けるために、何らかのラッパーを作成する必要がありますか？ または、原則は「機能を正しく変更/追加する方法」に言及するのではなく、「最初に変更を加える必要がないようにする方法」（つまり、プログラムを抽象化する方法）に言及していますか？

14 design  object-oriented  object-oriented-design  solid 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 私は学校で学び、適切なコーディングを行う前に、優れた開発方法論には構想と設計が必要であることを他のどこでも読みました。 それは初心者プログラマにとっても新しい情報ではありません。しかし、いくつかのプログラミング言語で開発を始めて以来、最初からすべてを設計して構想することができなかったため、これは良いアドバイスかと思います。 つまり、私は常にデザイン、構想、プログラミングを溶かしました。私は世界で最悪の開発者ですか、それとも私たちが学校で学ぶアイデアはただの古い無意味な宗教教義ですか？ これまでに経験したこともプログラミングしたこともないものを、どのように考えて設計することができますか？それはばかげていませんか？プログラミングは、代わりに構想と設計をリードしませんか？

14 design  programming-practices 

私は最近、より「組織化された」プログラミングを掘り下げてきましたが、実装ではなくインターフェイスにプログラミングする必要があることを学んでいます。それを念頭に置いて、可能であれば実装を記述する前に、インターフェイスでプロジェクトを「スケッチ」する方が良いでしょうか？ サードパーティのライブラリ（Lidgrenなど）を使用する場合は、これらをインターフェイスでラップし、IOCコンテナを介して解決する必要がありますか、それともインターフェイスに公開してもかまいませんか？

14 c#  design  interfaces  third-party-libraries  inversion-of-control 

tl; dr htmlを生成する広く使用されているいくつかのプログラムは、ブラウザーが適切に段落を閉じると仮定して、閉じているタグではなく、開く段落タグのみを生成します。 一見すると、ブラウザが段落を適切に閉じるという仮定は正しくないと思われます。私の解釈は正しいですか？より一般的には、この種の決定にはどのようなトレードオフが関係していますか？ moinmoinソースコードを参照すると、次のコード行が目を引きました。 # We only open those tags and let the browser auto-close them: _auto_closing_tags = set(['p']) （ソース） 実装の残りの部分を読んだ後、確かに、moinmoinがそのページの1つに対してhtmlコードを生成するとき、適切な場合は段落開始タグを正しく生成すると同時に、段落終了タグ（簡単に実行できるにもかかわらず）。 私の特定の、かなり珍しいユースケースでは、この動作は正しくありません。バグレポートを送信したり、動作を変更したりしたいと思います。ただし、この設計上の決定は思慮深く行われたようです。私はこれが一般的に正しい動作であるかどうかを知ることができるほど、HTML標準またはさまざまなブラウザ実装の複雑さに精通していないため、この動作を修正/変更する本能は見当違い。 このコードは、ブラウザの実装について有効な仮定を立てていますか？生成されたhtmlは有効ですか？より一般的には、ここで見落としているトレードオフは何ですか？

14 design  python  html5  code-generation 

たとえば、ユーザーとそのすべての電話番号とメールアドレスを取得したいとします。電話番号とメールは別々のテーブルに保存されます。1人のユーザーが多くの電話/メールにアクセスします。私はこれを非常に簡単に行うことができます： SELECT * FROM users user LEFT JOIN emails email ON email.user_id=user.id LEFT JOIN phones phone ON phone.user_id=user.id これに関する問題*は、ユーザー名、DOB、お気に入りの色、および各レコード（ユーザーが電話レコードにメールを送信する）についてユーザーテーブルに保存されている他のすべての情報を返し、おそらく帯域幅を消費して速度が低下することです結果をダウン。 ユーザーごとに1つの行を返し、そのレコード内に電子メールのリストと電話のリストがあった方が良いと思いませんか？また、データの操作がはるかに簡単になります。 LINQまたは他のフレームワークを使用してこのような結果を得ることができることは知っていますが、リレーショナルデータベースの基礎となる設計の弱点のようです。 NoSQLを使用してこれを回避することもできますが、中間点はないはずです。 何か不足していますか？これはなぜ存在しないのですか？ *はい、このように設計されています。わかった。なぜ作業が簡単な代替手段がないのか疑問に思っています。SQLは実行中の処理を続けることができますが、キーワードまたは2つを追加して、デカルト積ではなくネストされた形式でデータを返す少しの後処理を行うことができます。 選択したスクリプト言語でこれを実行できることはわかっていますが、SQLサーバーが冗長データを送信するか（以下の例）、またはのような複数のクエリを発行する必要がありますSELECT email FROM emails WHERE user_id IN (/* result of first query */)。 MySQLにこれに似た何かを返させる代わりに： [ { "name": "John Smith", "dob": "1945-05-13", "fav_color": "red", "email": "johnsmith45@gmail.com", }, …

14 design  sql  rdbms 

多くの場合、自然キーを持たないテーブルでは、ユーザーが一意に生成された識別子を保持できると便利です。テーブルに代理主キーがある場合（そして、そのような場合は必ず期待します）、そのキーをユーザーに公開する必要がありますか、その目的で別のフィールドを使用する必要がありますか？ サロゲートキーを公開しない理由の1つは、レコード間の関係を保持する操作を実行できないが、特定の種類の削除/再挿入、1つのデータベースからデータをコピーする多くの方法など、キー値を変更することです他など 代理キーを公開する主な利点は、とにかく持っているフィールドを簡単に使用できることです。 どのような状況で、代理キーをユーザーに直接公開する方がよいでしょうか？

14 design  database-design  relational-database  rdbms  surrogate-keys 

私は、モジュールの1つの責任がXMLファイルを解析し、データベースに必要なコンテンツをダンプすることである製品に取り組んでいます。現在の要件はXMLファイルの解析のみですが、将来、あらゆる種類のファイルをサポートできるように解析モジュールを設計したいと考えています。このアプローチの理由は、特定のクライアント向けにこの製品を構築しているが、近い将来に他のクライアントに販売する予定だからです。現在のクライアントのエコシステム内のすべてのシステムはXMLファイルを生成および消費しますが、他のクライアントの場合はそうではありません。 これまでに何を試しましたか？（現在） 戦略パターンに基づいた次の設計を念頭に置いています。私はすぐに日食でコードを書き留めてデザインを伝えたので、例外を適切に処理する方法などの他の側面が今のところ無視されるといいでしょう。 Parser：解析メソッドを公開する戦略インターフェイス。 public interface Parser<T> { public T parse(String inputFile); } *ジェネリックパラメーターを使用する理由は、すべての戻り値の型を許可し、コンパイル時に型の安全性を確保するためです。 ProductDataXmlParser製品関連情報を含むproduct.xmlファイルを解析するための具象クラス。（XMLBeanを使用） public class ProductDataXmlParser implements Parser<ProductDataTYPE> { public ProductDataTYPE parse(String inputFile) { ProductDataTYPE productDataDoc = null; File inputXMLFile = new File(inputFile); try { productDataDoc = ProductDataDocument.Factory.parse(inputXMLFile); } catch(XmlException e) { System.out.println("XmlException while parsing file : "+inputXMLFile); …

14 java  design  parsing  xml 

-repositoryデータベースからデータを取得するために、接尾辞が付いた一連の個別のクラスを使用しています。各テーブルごとに独自のリポジトリ。 たとえば、customerrepository顧客を取得するためのあらゆる種類のメソッドを持つクラスと、vacancyrepository空席を取得するためのあらゆる種類のメソッドを持つクラスがあります。 このことを行う方法について2つの質問があります。 複数のテーブルにまたがるデータを取得するのはどうですか？たとえば、私はまだ空席を作成していないすべての顧客を表示する画面を持っています。のcustomerrepositoryメソッドを使用できますか、vacancyrespository両方のリポジトリが結果を返すdataserviceことができますか？両方のリポジトリから結果を取得して1つの結果に結合する階層の上位にクラスを付けますか？ そのようなリポジトリはどのくらいのロジックを処理できますか？ リポジトリに「where active == true」を実装してアクティブなレコードのみを取得してもよいと思いますか、またはその単純なロジックでさえ、階層の上位のクラスで処理する必要があります（名前を付けましょうdataservice）？ 私が今遭遇した例はこれです： 1つ以上の質問を含む質問リストがあります。 質問には結果があり、別のテーブルに保持されます。 したがって、質問リストの合計結果を取得するには、questionlistテーブル、質問テーブル、およびテーブルのデータを結合する必要がありquestionstatusます。 現在、これらのテーブルには3つの異なるリポジトリがあります。 questionlistrepositoryリスト番号12の合計結果を尋ねると、他の2つのリポジトリからデータを取得する必要があり、そのため何らかのロジックが必要になります。 またはquestionlistdataservice、使用するリポジトリを知っているものはありますか？ もう1つ：リポジトリは結果を生成できるIQueryableため、呼び出し元のサービスは結果を簡単に結合できますが、そうでない場合は、3つのテーブルすべてのコンテンツをすべて取得することは良い考えではないと思いますデータベース。

14 c#  design  design-patterns  repository 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 私は最近、かなりの数のインタビューに参加しており、企業から「[モデルを挿入]を設計する」という質問に数回以上回答するように依頼されています。 これは最近の業界では普通ですか？私は20年以上ソフトウェアの世界にいて、インタビューに参加していますが、インタビューでこのパターンが現れるのはごく最近です。 質問は非常に開かれていると感じています。たとえば、「駐車場を設計する」ためにクラス図を描くように頼まれました。インタビュアーがどのレベルの詳細を期待しているのかわかりません。これは、Visioダイアグラムを添付することが期待されていたオンラインテストであったため、彼らの期待を尋ねることはできませんでした。 この種の質問を面接プロセスで使用していますか？それらはクラス図のみに関連していますか、またはシーケンス、フローチャート、ERD（もちろん職種の性質に基づいて）を求めていますか？ *ケビンの応答用に編集* 例：完全な質問は、「空きスロットを見つけるために使用できる駐車場管理システムを設計する」です。 I 2クラスで行うことができ、ParkingLotかつSlot追加したり、私が上で行くことができるIVehicleとVehicleしてCarおよびMotorcycleクラス。どこで線を引きますか？ public class ParkingLot { IVehicle Vehicle {set; get;} List<Slot> GetEmptySlots() { }; } public class Vehicle : IVehicle { Slot SlotNum {set; get;} } public class Slot { int Row {set; get;} int Column {set; get; } }

14 design  interview  object-oriented-design  uml  hiring 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 私は時々、実際には他の場所に属していないように見えるメソッドと値を保持するのに役立つ「Util」クラスを作成します。しかし、これらのクラスの1つを作成するたびに、「あー、これを後悔するつもりだ...」と思うのは、どこかで悪いことを読んだからです。 しかし、他方では、2つの説得力のある（少なくとも私にとって）ケースがあるようです。 パッケージ内の複数のクラスで使用される実装の秘密 インターフェイスを乱雑にすることなく、クラスを増強するための便利な機能を提供します 私は破壊に向かっていますか？あなたが言うこと ！！リファクタリングする必要がありますか？

14 design  object-oriented  code-smell