この問題について例を挙げて検討します。 多かれ少なかれ大規模なシステムで定期的に発生するいくつかのタスクを検討してください。 このタイプのタスクの原因は、この投稿の範囲外です。ここでは、実装について説明します。
Webフォームデータ処理
フォームは似ています：1つのフィールドを追加し、別のフィールドを削除し、可能な値を数値に切り取り、1つだけではなく複数の選択を行います 表現の観点から-小さな変更。 内部ロジックはどのように変化しますか？
単純なフォームを見るときに最初に頭に浮かぶのは、オブジェクトをフォームにマップし、フォームの各フィールドにオブジェクトの適切なフィールドを提供することです。 リクエストを受信すると、オブジェクトの対応するフィールドにフォームのすべてのフィールドを書き込み、エラーがある場合は検証し、フィールドにバインドしてユーザーにそれらを提供し、すべてがOKであれば再編集させて、さらなる処理のために送信します（処理方法-タスクによって異なります） ）、処理の結果としてエラーが発生した場合、エラーをレンダリングしました（フォームと一緒に）。
アイデアを発展させます。
フォームの進化を見てみましょう。 原則として、次の傾向があります（任意の組み合わせが可能です）。
- 新しいフィールドを追加する
- オプションのフィールドを削除する
- コンテキストの変更
- 強制充填の変更（両方向）
- 必須フィールドの削除（=必須の変更+オプションのフィールドの削除）
- 値のタイプの変更を含む、可能なフィールド値の変更
ここから、次の問題が発生する可能性があります。
- 新しいフィールドが追加されました。 以前は同じフォームのフィールドのセットは、時間の経過とともに完全に異なるものになる場合があります。
- オプションのフィールドが削除されました。 このパラメーターのハンドラーを削除するだけです。 データベース内のテーブルとこのフィールドを操作するためのコードを消去するのは良いことですが、重要ではありません。
- フィールドは必須でしたが、オプションになりました。 nullをチェックすると、寿命が完全に損なわれます。
- フィールドはオプションでしたが、必須になりました。 問題は既存のデータにあります。値がない場合にどのように処理するかですが、操作には必要ですか？
- 値のタイプの変更を含む、可能なフィールド値の変更。 問題は明らかだと思います。フィールドのタイプへのすべての依存関係を変更する必要があります。
結論は何ですか？
- データベースでNULLチェックを行う必要があるのは、必須フィールドが保証されている場合のみです。 これらは、データベース内のエントリが意味を失うフィールドです。 原則として、これらのフィールドは少なく、多くの場合、代替キー（またはそのサブセット）を表します。 信じられない場合は、匿名ユーザー（登録のないユーザー）の紹介を検討してください。
- 意味的に類似したフォームで、フィールドのセットがコンテキスト（たとえば、異なる顧客のアンケート形式）に応じて大きく変化する場合、データベース内の1つのレコードが1つのフィールド値（フォームフィールドのセット全体ではなく）に対応する属性ロジックを導入することは理にかなっています。
- オプションのフィールドが多数あり、それらがデータの保存のみを目的としている場合、属性ロジックを使用することも意味があります。実際のセットは変更される可能性があります。
- システムのさまざまな部分のオプションフィールドにさまざまなロジックが関連付けられている場合、それを1か所に統合することは理にかなっています。 最初に、2つまたは3つのメソッドを持つクラスにします。次に、その数を簡単に15〜20に増やします。 また、フィールドが必須になった場合の潜在的な問題の解決にも役立ちます。
- 各フィールドの入力の問題をなくすには、そのタイプを保存し、 常にフィールドとそのタイプに関するメタ情報へのリンクとともにこのフィールドの値を転送します。 外部システムと交換する必要がある場合は、明確なシリアル化ルール（たとえば、XMLなどの文字列）と解析エラー処理を導入します。
- 定期的なリファクタリングでは、存在しないフィールドを操作するために古いコードを削除する必要があります。 コードブロック付きのコメントはありません。バージョン管理システムの話はお任せします。
PS以下のトピックでは、レポート作成、ネットワークプロトコルの生データの分析、およびhabrasocietyの要求に応じたその他の問題について検討します。