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

私は常に仕事で厳密にDRYの原則に従うようにしています。怠inessな状態からコードを繰り返すたびに、後でそのコードを2か所で維持する必要が生じたときに戻ってしまいます。 しかし、多くの場合、互いに参照できない 2つのプロジェクトで再利用する必要がある小さなメソッド（10〜15行のコード）を記述します。この方法は、ネットワーク/文字列/ MVVMなどに関連するものである可能性があり、元々のプロジェクトに固有ではない一般的に有用な方法です。 このコードを再利用する標準的な方法は、再利用可能なコード用に独立したプロジェクトを作成し、必要なときにそのプロジェクトを参照することです。これに伴う問題は、2つの理想的ではないシナリオのいずれかになってしまうことです。 最終的に、数十/数百の小さなプロジェクトになります-それぞれが再利用する必要のある小さなクラス/メソッドを収容します。.DLLほんの少しのコードだけでまったく新しいものを作成する価値はありますか？ 関係のないメソッドとクラスのコレクションが増え続ける1つのプロジェクトになります。このアプローチは、私が以前働いていた会社がやったことです。彼らには、base.common前述のようなネットワーク、文字列操作、MVVMなどのフォルダーを持つプロジェクトがありました。それは信じられないほど便利でしたが、不要なすべての無関係なコードを不必要にドラッグして参照しました。 だから私の質問は： ソフトウェアチームは、プロジェクト間で少量のコードを再利用するのに最適な方法を教えてください。 特に、この分野でポリシーを持っている会社で働いている人や、私のように個人的にこのジレンマに直面している人に興味があります。 注：「プロジェクト」、「ソリューション」、および「参照」という言葉の私の使用は、Visual Studioでの.NET開発の背景から来ています。しかし、この問題は言語とプラットフォームに依存しないと確信しています。

102 project-management  code-reuse  projects-and-solutions  dry 

非常に簡単ですが、同じプロセスをいくつかの小さな調整で数回繰り返すだけで、すべてのケースとスケーラブルなデータで機能するコードを作成したいのはなぜですか？ すぐにこれを再度編集する必要はないでしょう。 行くだけで仕事が減るみたいです... function doStuff1(){/*.a.*/} function doStuff2(){/*.b.*/} function doStuff3(){/*.c.*/} そして、何かを追加する必要がある場合... function doStuff4(){/*.d.*/} 削除する必要がある場合は、削除します。 すべてをすべてのケースにデータを供給して処理できる1つの単純なパターンにすべてを作り、私がこれまでにないような気がしない多くの変更を行う方法を理解することは困難ですする。 クイックカット+ペーストで作業が大幅に減るのに、どうしてDRYになるのですか？

81 code-quality  dry 

たとえば、他のクラスを拡張するクラスがあるとします。 public class LoginPage { public String userId; public String session; public boolean checkSessionValid() { } } およびいくつかのサブクラス： public class HomePage extends LoginPage { } public class EditInfoPage extends LoginPage { } 実際、サブクラスにはオーバーライドするメソッドがありません。また、一般的な方法でHomePageにアクセスしません。つまり、次のようなことはしません。 for (int i = 0; i < loginPages.length; i++) { loginPages[i].doSomething(); } ログインページを再利用したいだけです。ただし、https: //stackoverflow.com/a/53354によると、インターフェイスLoginPageは必要ないため、ここでは構成を優先する必要があります。したがって、ここでは継承を使用しません。 public class HomePage …

36 inheritance  composition  dry 

ほぼ同一のコードがいくつかありますが、メイン変数ではまったく異なる型を使用し、それらの間には継承はありません。具体的には、C＃およびVB.NET用のRoslynを使用して、次のタイプのアナライザーを作成しています。 Microsoft.CodeAnalysis.CSharp.Syntax.AttributeSyntax Microsoft.CodeAnalysis.VisualBasic.Syntax.AttributeSyntax コードは同じことをしているので、できるだけDRYのままにして、できるだけ別々の（ただしタイプ以外は同じ）メソッドに分割するか、2つのメソッドが完全に分離するのかどうか疑問に思っています関連しておらず、将来の変更が一方のバージョンの変更を強制する可能性がありますが、もう一方のバージョンは変更しない可能性はありますか？ 編集： 1年ほど後、私はこの同じ問題にぶつかり、Roslynチームが解決に協力しました。ジェネリックを取り、TAttributeSyntaxほとんどの作業を行うパラメーターを持つ基本クラスを作成します。次に、特定の型を必要とする最小限のデータで派生クラスを作成します。

34 c#  design  dry 

優れたOOPデザイン、クリーンなコード、柔軟性、将来のコードのにおいを避けるという点で、何が優れているのだろうかと思っています。イメージの状況。クラスとして表す必要がある非常によく似たオブジェクトがたくさんあります。これらのクラスには特定の機能はなく、データクラスだけで、名前（およびコンテキスト）だけが異なります。例： Class A { String name; string description; } Class B { String name; String count; String description; } Class C { String name; String count; String description; String imageUrl; } Class D { String name; String count; } Class E { String name; String count; String imageUrl; String age; …

24 object-oriented  inheritance  dry 

私はすべてが一般的な基本クラスから継承するいくつかのクラスを持っています。基本クラスには、typeのいくつかのオブジェクトのコレクションが含まれますT。 各子クラスは、オブジェクトのコレクションから補間値を計算できる必要がありますが、子クラスは異なるタイプを使用するため、計算はクラスごとにわずかに異なります。 これまで、コードをクラスからクラスにコピー/ペーストし、それぞれに小さな変更を加えました。しかし、今は重複したコードを削除し、基本クラスの1つの汎用補間メソッドに置き換えようとしています。しかし、それは非常に困難であることが証明されており、私が考えているすべての解決策は非常に複雑に思えます。 DRYの原則はこのような状況にはあまり当てはまらないと思い始めていますが、それは冒aspのように聞こえます。コードの重複を削除しようとすると、どれだけ複雑になりますか？ 編集： 私が思いつく最良の解決策は次のようなものです： 基本クラス： protected T GetInterpolated(int frame) { var index = SortedFrames.BinarySearch(frame); if (index >= 0) return Data[index]; index = ~index; if (index == 0) return Data[index]; if (index >= Data.Count) return Data[Data.Count - 1]; return GetInterpolatedItem(frame, Data[index - 1], Data[index]); } protected abstract T GetInterpolatedItem(int …

24 c#  code-quality  complexity  code-reuse  dry 

次の方法を検討してください。 public List<Employee> GetAllEmployees() { using (Entities entities = new Entities()) { return entities.Employees.ToList(); } } public List<Job> GetAllJobs() { using (Entities entities = new Entities()) { return entities.Jobs.ToList(); } } public List<Task> GetAllTasksOfTheJob(Job job) { using (Entities entities = new Entities()) { return entities.Tasks.Where(t => t.JobId == job.Id).ToList(); } …

23 c#  design-patterns  dry 

既存のJava APIのほとんどの機能を公開するREST APIを構築しています。両方のAPIは、組織内で使用するためのものです。外部で使用するために設計する必要はありません。私は両方のAPIに影響を及ぼしていますが、REST APIを実装しています。Java APIは引き続きローカルアプリケーションに使用されます（「非推奨」ではありません）が、重要な新規開発にはREST APIが使用されます。 Java APIクラスの一部は単なるデータです（プロパティ、ゲッター、セッターを持つBean）。そして少なくともこれらのいくつかは、REST APIを介して（何らかの形で）データ（XMLまたはJSONにマーシャリングされる）として送信するのに意味があります。たとえば、サーバーマシンに関する情報を格納するクラス。これらのデータクラスについて、次の選択に直面しています。 元のJavaクラス（またはサブクラス）をREST APIで直接公開する、または REST API専用の新しいデータ転送クラス（DTOパターン）を作成しますか？ いずれにせよ、RESTデータ転送クラスがあります。問題は、オリジナルに注釈を付けるか、新しいものを作成するか（オリジナルのコピーに近い場合があります）です。他の選択肢もありますが、主にこれら2つに焦点を当てます。 ＃1の引数： DRY（繰り返さないでください） 実装が速い REST APIのアップグレードが簡単 ＃2の引数： REST APIをJava APIとは別にバージョン管理する必要がある場合はどうなりますか？（これは多少可能性があります。） プロパティの削除、動作の追加、クラス階層の変更など、Javaデータクラスに大幅な変更があった場合はどうなりますか？（これも多少可能性があります。） 要するに、DRY（＃1）とデカップリング（＃2）の間のトレードオフのように思えます。 ＃1から始めて、その後＃2に移って問題が発生した場合は、必要なことを証明できないものを構築しないというアジャイルガイドラインに従っています。これは悪い考えですか。とにかくそこに行き着くかもしれないと思うなら、私は＃2から始めるべきですか？ 私のリストに欠けている主要な議論/結果はありますか？

19 java  api  rest  coupling  dry 

私は間違いなくそうすべき ケースで100％乗っています、クライアント側とサーバー側の両方のデータ検証使用するます。 しかし、私が働いてきたフレームワークと環境では、私が見たアプローチは決して乾いたことはありませんでした。ほとんどの場合、計画やパターンはありません。検証はモデルの仕様に記述され、検証はビューのフォームに記述されます。（注：私の実際の経験のほとんどは、Rails、Sinatra、およびjQueryを使用したPHPに関するものです） それを熟考すると、検証のセット（モデル名、フィールド、条件など）が与えられると、必要なクライアント側とサーバー側の両方のマテリアルを生成できるジェネレーターを作成することは難しくないようです。あるいは、そのようなツールはサーバー側の検証（たとえば、validates ActiveRecordモデルのコード取得し、クライアント側の検証（フォームに適用されるjQueryプラグインなど）を生成できます。 明らかに、上記は単なる「このアイデアを思いついた」という考えであり、正式な提案ではありません。この種のことは、アイデアが思いついたときよりも確かに難しいです。 それで、データ検証のための「1回だけ書き込み、サーバーとクライアントで実行する」技術の設計にどのようにアプローチしますか？ 関連サブトピック：特定のフレームワークまたはクライアント/サーバーテクノロジーには、そのようなツールが存在しますか？1セットの検証のみを維持しようとする場合の大きな落とし穴や課題は何ですか？

17 design  validation  dry  client-server 

ウィキペディアの記事「ルールオブスリー」に出会いました 3つのルールは、コードの複製された部分を新しいプロシージャに置き換える必要があるかどうかを判断するための、コードリファクタリングの経験則です。コードは1回コピーできますが、同じコードを3回使用すると、新しいプロシージャに抽出する必要があると記載されています。ルールは、リファクタリングでマーティン・ファウラーによって導入され、ドン・ロバーツに起因します。 これは単なる経験則であることは知っていますが、2回目の複製後にのみリファクタリングすることが推奨されるのはなぜですか？最初の複製を作成するときに、リファクタリングにマイナス面はありますか？

16 refactoring  dry  rule-of-three 

関数の入力パラメーターを検証するのに最適な場所はどこですか：呼び出し元または関数自体ですか？ コーディングスタイルを改善したいので、この問題のベストプラクティスまたはいくつかのルールを見つけようとします。いつ、何がより良い。 私の以前のプロジェクトでは、関数内のすべての入力パラメーターをチェックして処理していました（たとえば、nullでない場合）。ここで、入力パラメーターの検証は呼び出し側の責任であることをいくつかの回答とPragmatic Programmerの本で読みました。 つまり、関数を呼び出す前に入力パラメーターを検証する必要があるということです。関数が呼び出されるすべての場所。そして、それは1つの質問を提起します：それは、関数が呼び出されるすべての場所でチェック条件の複製を作成しませんか？ null条件だけに興味はありませんが、入力変数（sqrt関数への負の値、ゼロ除算、状態と郵便番号の間違った組み合わせ、またはその他）の検証に興味があります 入力条件をチェックする場所を決定する方法はありますか？ 私はいくつかの議論について考えています： 無効な変数の処理が異なる場合、呼び出し側で検証するのが適切です（たとえば、sqrt()関数-場合によっては複素数を処理したいので、呼び出し側で条件を処理します） チェック条件がすべての呼び出し元で同じ場合、重複を避けるために関数内でチェックすることをお勧めします 呼び出し元の入力パラメーターの検証は、このパラメーターを使用して多くの関数を呼び出す前に1回だけ行われます。したがって、各関数のパラメーターの検証は効果的ではありません 適切なソリューションは、特定のケースに依存します この質問が他の質問と重複していないことを願っています。この問題を検索し、同様の質問を見つけましたが、彼らは正確にこのケースに言及していません。

16 coding-standards  validation  dry 

関数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 

DRYとコードの結合に関するガイダンスを探しています。私は自分のコードを複製したくないし、無関係なモジュール間のコードの結合も嫌いです。そのため、複製が導入されてから1年後に同一の重複コードが見つかった場合、重複コードをリファクタリングします。しかし、現実の世界がはるかに予測不可能な状況を経験し、コードをリファクタリングした後、コードを再度フォークする必要がある状況が発生しています。 たとえば、ガソリン車、ガソリンSUV、電気自動車、電気SUVを処理するコードがあった場合、「コード」を「ガソリン」階層と「電気」階層にリファクタリングするとします。どちらも「車両」階層から派生しています。ここまでは順調ですね。そして、私の会社はハイブリッド車とハイブリッドセミを導入します。これには、元の階層自体に中核的な変更が必要になります。たぶん、ガソリンと電気階層の間の「組成」が必要になるでしょう。 上記のすべての製品に共通する変更を実装するのにかかる時間が長くなるため、明らかにコードの複製が悪いことです。しかし、一般的なコードをリファクタリングすると、製品固有のバリエーションを導入することも同様に難しくなり、バグを修正するためにコードの行を見つけなければならない場合に多くの「クラスジャンプ」が発生します。すべての子孫の間でトリガー回帰のバグをトリガーします。 DRYと不要なコードカップリングの最適なバランスをどのように実現しますか？

14 design  dry  coupling 

非自明なC ++ const関連の重複を避けるために、const_castは機能するが、非constを返すプライベートconst関数は機能しない場合がありますか？ Scott MeyersのEffective C ++ item 3では、const_castと静的キャストを組み合わせることで、コードの重複を避けるための効果的で安全な方法を提案しています。 const void* Bar::bar(int i) const { ... return variableResultingFromNonTrivialDotDotDotCode; } void* Bar::bar(int i) { return const_cast<void*>(static_cast<const Bar*>(this)->bar(i)); } マイヤーズは、const関数にnon-const関数を呼び出すことは危険であると説明しています。 以下のコードは反例を示しています。 マイヤーズの提案に反して、静的キャストと組み合わせたconst_castは危険な場合があります 時々const関数がnon-constを呼び出すことはそれほど危険ではありません const_castを使用して両方の方法で潜在的に有用なコンパイラエラーを隠すことがあります。 const_castを避け、const以外のメンバーを返すconst constメンバーを追加することも別のオプションです コードの重複を回避するconst_cast戦略のいずれかが適切なプラクティスと見なされていますか？代わりにプライベートメソッド戦略を好むでしょうか？const_castは機能するが、プライベートメソッドは機能しない場合がありますか？複製以外に他のオプションはありますか？ const_cast戦略に関する私の懸念は、コードが記述されたときに正しい場合でも、メンテナンス中にコードが不正確になり、const_castが有用なコンパイラエラーを隠す可能性があることです。一般的なプライベート関数の方が一般に安全なようです。 class Foo { public: Foo(const LongLived& constLongLived, LongLived& mutableLongLived) : mConstLongLived(constLongLived), mMutableLongLived(mutableLongLived) {} // …

14 c++  dry  const 

（ActiveRecord）モデルに加えて、常にデータベースレベルで制約を適用しています。しかし、私はこれが本当に必要かどうか疑問に思っていましたか？ 少しの背景 私は最近、モデルの基本的な自動タイムスタンプ生成方法を単体テストする必要がありました。通常、テストはモデルのインスタンスを作成し、検証なしで保存します。ただし、テーブル定義でnullにできない他の必須フィールドがあります。つまり、ActiveRecord検証をスキップしてもインスタンスを保存できません。だから私はdb自体からそのような制約を削除し、ORMにそれらを処理させる必要があるかどうかを考えていますか？ db、imoの制約をスキップした場合に考えられる利点 - データベースを移行することなく、モデル内の検証ルールを変更できます。 テストで検証をスキップできます。 考えられる不利益は？ ただし、ORM検証が失敗またはバイパスされる可能性がある場合、データベースは制約をチェックしません。 どう思いますか？ 編集このケースでは、データベースからモデルを生成するYii Frameworkを使用しているため、データベースルールも生成されます（ただし、生成後はいつでも記述できます）。

13 database  orm  validation  dry