ライブラリからメソッドを呼び出すときは、その名前が意味することを正確に実行することを期待します。
Connection c = driver.getConnection();
- つながりを返す
- 失敗した場合にエラーを報告する
- 期待以上のことをしない
「ライブラリコード」を書くとき、デカップリング、凝集、抽象化の原則に固執するのは非常に簡単です。これらを守らないことは、ほとんどの場合、設計上のエラーを意味します。
しかし、ビジネス ロジックの場合、いくつかの問題が発生し、おそらく視点を変更する必要があります。ビジネス ロジック レベルでは、次のように言います。
session.connect(); //session is of Session type, my "business logic class"
構成ファイルを読み取り、見つからない場合はデフォルトを使用し、接続し、チェックを行い、ユーザーに通知する必要がある警告を決定します。たとえば、データベースのバージョンがクライアントよりも古いという事実です。ソフトウェア。
メソッドはまとまりがなければならないので、これらすべてを行うべきではないと言い、これを厳密に適用すると、1 行だけの connect メソッドになってしまいます。
public class Session {
...
Connection c;
public void connect() {
c = driver.getConnection();
}
}
つまりconnect
、ビジネス クラス Session のメソッドは、基になるクラスに折りたたまれます。
そして、残りのタスクは?ファイルを読んで、データベースのバージョンなどを確認しますか?
ビジネスコードをすべてのロジックを実行する「大きなメソッド」に延期しています。
そして、これはまさに私のポイントです。
ビジネス ロジックのコンテキストで結合と分離の原則を適用すると、タスクを小さなサブタスクに細分化することができず、すべての作業を行う大きな "モノリシック" メソッドがいくつかあり、読みにくくなります。
低レベルのライブラリ (Driver.getConnection()) の優れた原則 (結束、抽象化) は、ビジネス ロジックにはまったく不十分です。
私のアイデアは次のとおりです。
- 結束は、まったく新しい概念に置き換えなければなりません
- 結束は特定のポイントまで「引き伸ばされる」必要があります
そして、私は2番目が好きなので、私の質問はその点は何ですか.