実際の仕事では、要件が来たら元のコードを再度変更し、別の要件が来たら前の要件のコードを再度変更するというような運用を行っていますか?今でも多くの反復作業が毎日繰り返されています.それを改善？
経験豊富な友人なら聞いたことがあると思います。さて、あなたはこの文の本当の意味を知っていますか？今日は、開閉原理がどのように実現されるかについてお話します。
開閉原理とは
開閉原理 (OCP) は、1988 年にバートランド マイヤーによって提案されました。設計原理は次のように述べています。
ソフトウェア エンティティは、拡張に対してはオープンである必要がありますが、変更に対してはクローズされている必要があります。
ソフトウェア エンティティは、拡張に対してオープンであり、変更に対してクローズされている必要があります。
オープンクローズ原則の実装方法
「拡張にオープン、変更にクローズ」、どのように理解するのですか? 最初にケースを見てみましょう, 下の図に示すように, これは、電子商取引在庫システムの在庫変更の簡単なモデル図を示しています. 在庫システムは、外部システムの在庫変更イベントを受け取り、データベース内の在庫を変更します.
このビジネス要件に直面すると、多くの人のコードは次のように記述されます。
public class Stock {
public void updateStock(String event){
if("outOfStock" == event){
// todo 出库事件 库存操作
}else if("warehousing" == event){
// todo 入库事件 库存操作
}
}
}
この時点で、新しい要件が発生します。在庫イベント (在庫過剰/在庫不足) が WMS ストレージ システム内で生成され、これらのイベントが在庫の変化につながります。したがって、コードは次のように展開されます
public class Stock {
public void updateStock(String event){
if("outOfStock" == event){
// todo 出库事件 库存操作
}else if("warehousing" == event){
// todo 入库事件 库存操作
}else if("panSurplus" == event){
// todo 盘盈事件 库存操作
}else if("loss" == event){
// todo 盘亏事件 库存操作
}
}
}
明らかに、上記のコードの実装では、要件が発生するたびにコードを 1 回変更する必要があり、メソッドに else if ブランチが追加されるため、Stock クラスは常に変化し、不安定になります。
このコードを変更する必要がなく、ビジネス ニーズに合わせて柔軟に拡張できるようにする良い方法はありますか?
この時点で、Java の 3 つの魔法の武器である継承、実装、ポリモーフィズムを取り除きます。
ビジネスモデル全体は次のとおりであることがわかりました。イベントは在庫の変化を引き起こします。では、イベントを抽出できますか? したがって、イベント モデルはインターフェイスに抽象化できます。コードは次のとおりです。
public interface Event {
public void updateStock(String event);
}
各イベントは在庫の変更に対応し、特定の実装クラスに抽象化されます。コードは次のとおりです。
受信イベント
public class WarehousingEvent implements Event {
public void updateStock(String event){
// 业务逻辑
}
}
アウトバウンド イベント
public class OutOfStockEvent implements Event {
public void updateStock(String event){
// 业务逻辑
}
}
xxx イベント
public class XXXEvent implements Event {
public void updateStock(String event){
// 业务逻辑
}
}
最後に、Stock クラスの updateStock() 在庫変更ロジックは次のように抽象化できます。
public class Stock {
public void updateStock(String event){
// 根据事件类型获取真实的实现类
Event event = getEventInstance(event);
// 库存变更操作
event.updateStock();
}
}
抽象化、分離、および変換の後、Stock.updateStock() クラスは安定し、イベントを追加して、処理のために else if ブランチを追加する必要はありません。この抽象化の利点も明白です: 新しい在庫変更イベントが発生するたびに、実装クラスを 1 つだけ追加する必要があり、他のロジックを変更する必要はありません. 在庫イベントが無効な場合、実装クラスのみが必要です.削除されます。
要約する
上記のケースを通じて、オープニングとクロージングの原則の抽象化と実装プロセス全体を示しました。ビジネスは少し単純かもしれませんが、代表的な意味は非常に強いです。
開閉原理の核心は、拡張のために開いて、修正のために閉じることです。したがって、ビジネス ニーズが常に同じコード部分を変更する必要がある場合、ビジネスに上記のケースと同様の問題があるかどうかを注意深く観察する必要があります。それらの間に共通点はありますか？これらの変更点は、コードを変更するのではなく、拡張機能によって分離して実装できますか?
実際、ビジネス開発には多くの同様のシナリオがあります: ユーザーのレベルに応じて異なる料金を計算する必要がある電子商取引システムのメンバーシップ システム; ユーザーのレベルに応じたチケット システム (一般ユーザー、プラチナ ユーザー) 、ゴールド ユーザー...) はさまざまな発券メカニズムを提供します; ゲートウェイ システムでは、さまざまな粒度 (インターフェイス、IP、サービス、クラスター) に従って電流制限が実装されます。
一部の友人は、私のビジネス シナリオも同様のシナリオであると反論するかもしれませんが、ロジックは単純であり、他の方法で実行できる場合もあります。
私の提案は、平時に懸命に働き、細部に懸命に取り組むことです。
多くの人は、ビジネス開発技術の成長の遅さ、特にジュニア プログラマーの成長の遅さについて常に不満を漏らしていますが、ほとんどの人はビジネス CRUD を出発点としています。
プロセス , このような長期にわたる意図的な実践を通じて、量的な変化は質的な変化を生み出し、徐々にこれらの古典的な設計原則の謎を理解できるようになります. 心地よいコードを生成します.