SOLID を使用するよりも、ロジック全体を手続き型パターンに記述する方が簡単な場合があります。
これ以上同意することはできません。私たちプログラマーは、手続き型パターンでコードを処理する方が簡単です。これにより、手続き型プログラミングに慣れているプログラマーにとって OOP は難しくなります。
ただし、小さなモジュール用に設計されたインターフェイスを壊すよりも、一般的なインターフェイスとコンシューマーを最初に作成する方が簡単であることがわかりました。これは一種のTest First Development -> Red, green, refactor練習です。( を達成したい場合はneat design、このガイドの代わりに TDD に従うことを検討してください。このガイドは、TDD の実行のほんの一部です)
ServiceAttendanceto doを作成したいとしましょうscanEmployeeID。次のようなインターフェイスがあります (例は C# の命名にあることに注意してください)。
public interface IServiceAttendance{
bool ScanEmployeeId();
}
なお、動作の成否はvoidではなくboolを返す方法に決めています。以下の消費者の例では、DI を使用する方法を示したいだけなので、DI を実装していないことに注意してください。次に、コンシューマーでは、次のことができます。
public void ConsumeServiceAttendance(){
IServiceAttendance attendance = Resolve<IServiceAttendance>();
if(attendance.ScanEmployeeId()){
// do something
}
}
これでコンシューマは終了です。では実装に移ります。手続き型プログラミングを使用して開発でき、モノリシック コード ブロックを取得したとします。疑似ステートメントで実装を述べることができます。
public class ServiceAttendance : IServiceAttendance{
public bool ScanEmployeeId(){
bool isEmpValid = false;
// 1 scan the employee id
// 2 validate the login
// 3 if valid, create the login session
// 4 notify the user
return isEmpValid;
}
}
これで、この 1 回の操作で 4 つの手順を実行できます。私の原則は、1 つのメソッドで 3 つ以上のファサード プロセスを実行しないことです。そのため、3 と 4 を 1 つのプロセスに単純にリファクタリングできます。今、私たちは持っています
public class ServiceAttendance : IServiceAttendance{
public bool ScanEmployeeId(){
bool isEmpValid = false;
// 1 scan the employee id
// 2 validate the login
// 3 if valid, create the login session and notify the user
return isEmpValid;
}
}
これには、3つの主要な操作があります。操作を分解することで、より小さなモジュールを作成する必要があるかどうかを分析できます。2 番目の操作を中断したいとします。私たちは手に入れる：
// 2 validate the login
// 2.1 check if employee id matches the format policy
// 2.2 check if employee id exists in repository
// 2.3 check if employee id valid to access the module
分割操作自体は、2 番目のモジュールを別の小さなモジュールに分割するのに十分明らかです。2.2との場合2.3、注入するモジュールを小さくする必要があります。単にリポジトリへの依存が必要になるため、注入する必要があります。操作ステップ にも同じケースが適用され1 scan the employee idます。これは、指紋スキャナーへの依存が必要になるためです。そのため、スキャナー ハンドラーは別のモジュールに実装する必要があります。
で実行できるように、いつでも操作を分解できます2.1。
// 2.1 check if employee id matches the format policy
// 2.1.1 employee id must match the length
// 2.1.2 employee id must has format emp#####
現在2.1.1、2.1.22 つの個別のモジュールに分割する必要があるかどうかはわかりません。決定するのはあなた次第です。これでインターフェイスを取得できたので、実装を開始できます。検証中にスローすることを期待してexceptionsください。そうしないと、カスタム クラスを渡してエラー メッセージを処理する必要があります。