問題タブ [yagni]

カプセル化、依存性注入、最小知識の原則、そしてあなたはそれを必要としないことによって、「1つのことをする」という部分を理解することができます。しかし、2番目の部分「うまくやる」をどのように理解できますか？

与えられた例は、同じYAGNIの記事で与えられた完全性の概念でした：

たとえば、アイテムの追加、アイテムの削除、またはアイテムの変更を可能にする機能の中で、完全性を使用して「アイテムの名前変更」を推奨することもできます。

しかし、私はそのような推論がフィーチャークリープに簡単に悪用され、「1つのことをする」部分に違反する可能性があることを発見しました。

したがって、機能を確認するためのリトマス試験とは、「うまくいく」カテゴリ（したがって、関数/クラス/プログラムに含める）または他の「1つのことを行う」カテゴリ（したがって、除外する）に属します。 ？

最初の部分である「1つのことを行う」は、UNIXのlsコマンドを介して、出力をフォーマットするための過剰な数のフラグが含まれていることの反例として最もよく理解されます。これは、別の外部プログラムに完全に委任されているはずです。しかし、2番目の部分が「うまくやる」のを見る良い例はありません。

それ以上の機能を削除すると「うまくいかない」という良い例は何ですか？

内部の情報をさらに洗練する列挙値であるeventargsオブジェクトを内部で受け取るイベントハンドラーがあります。それは次のように見えます

Statusdataは、指定されたCalllbackTypeに応じて変化する基本抽象クラスです。

これで、イベントを処理するコードは次のようになります。

問題は、StatusNotificationsを変更したり、処理方法を変更したりする場合、非常に大きくなる可能性のあるスイッチを調整する必要があることです。特定のステータスのハンドラーを挿入できるものを使用することを考えていました。

一方で、今は本当に必要ありません。スイッチソリューションは機能しますが、大きくなり始めているので、メインタンブルではないという気持ちとYAGNIの間で戦っています。

そのようなスイッチをIOCパターンに変換できるパターンはありますか？そのスイッチを実際にリファクタリングする必要があると思いますか？

私は現在、拡張する 2 つのカスタム バリデーターをZend_Validate_AbstractそれぞれLib_Validate_TimeAfterとという名前で構築していLib_Validate_TimeBetweenます。名前は非常に単純です。最初の名前は、日付/日時/時刻が他の日付/日時/時刻の後にくるかどうかをテストするために使用され、2 番目は、日付/日時/時刻が他の 2 つの日付/日時/時刻の間に来るかどうかをテストするために使用されます。

これらのバリデーターはどちらも、 a 、 a (または )、 aまたは an_buildDate($value)の形式の値を取り、それを使用可能な日付形式に変換するという名前の同じメソッドに依存します。datestamphourstamphh:mmhh:mm:sstimestampISO_8601 timestamp

私は自分自身を繰り返して、両方のバリデーターでメソッドをコピーして貼り付けたくないので、それを行うための最良の方法を探していました。

私が現在検討している方法は、バリデーターが使用できるある種のクラスヘルパーを開発することです (不要な依存関係を追加するため、面倒な方法です)。日付/日時/時刻を検証し、メソッドを共有できるため、2つのバリデーターを拡張する他のバリデーターです_buildDate($value)が、バリデーターが本当に必要になるとは思いません。

それで、繰り返し（DRY）を避けるためにそのようなコードを構造化するための良い方法は何ですか（私は物事を行うための「神の方法」を実際に探しているわけではありません）。

YAGNI と KISS の間には明らかに構文上の違いがありますが、意味上の違いは見当たりません。それらは本当に本質的に同じものですか？

私はいくつかのコースを受講し、YAGNI の目的について読みました。しかし、この原則全体としては、私は決してうまくいきませんでした。それは論理的なパラドックスをもたらします。

仮定として、あなたはスケール フォワードを意図したフレームワークを設計しています。YAGNI (およびおそらく TDD) は、今に集中するように促します。予見可能なハードウェアで機能するようにしてください。結局のところ、将来の要件はあいまいであり、まあ、将来のことです。

しかし、それはフレームワークの実行可能性を本質的に制限します。そして、この仮説では、将来がどうなるかを知るための先見の明があります。プロトタイピングを行って先に取り組むことは、将来的に非常に役立つ可能性があることを知っているため、時間をかける価値があるかもしれません. 結局のところ、フレームワークの本質は、環境全体でいくつかの機能を促進することです。では、どうすればフレームワークを設計し、YAGNI の原則に厳密に従うことができるのでしょうか?

「YAGNI の使い方」について具体的なことを求めているのかどうかはわかりませんが、それよりも哲学的なことかもしれません。YAGNI、正反対の原則、ベスト プラクティスの境界線について、業界の経験豊富な開発者に尋ねているだけかもしれません。YAGNI は実施されていますか? それも考慮されていますか？それとも、本に載っているからといって、学校が教えているだけなのでしょうか?

ありがとう。

私が理解YAGNIしているように、必要な場合にのみインターフェイスを抽出する必要があると言っています。したがって、ポリモーフィズムが不要で、現在実装が 1 つしかない場合は、インターフェイスを使用する必要はありません。しかし、次のDIPように述べています。

A. 高レベル モジュールは低レベル モジュールに依存すべきではありません。どちらも抽象化に依存する必要があります。

B. 抽象化は詳細に依存すべきではありません。詳細は抽象化に依存する必要があります。

YAGNIとオプション B. の間に不一致があるようですDIP。また、適用したい場合はOCP、依存関係の制御を反転し、抽象化を抽出して、その型を変更せずに型を拡張できるようにする必要があります。

また、一部のテクノロジでは、型クライアントを単体テストできるように抽象化を抽出する必要があります。しかし、たとえばJavaでは必要ありません。ですから、現在実装が 1 つしかない場合、抽象化を抽出する必要があるかどうかを知りたいですか?