わなから飛び出せ!プラグイン化プロジェクトインタフェースはより優雅に設計されます~
2534 ワード
わな!罠だ!
わなをかける者は、罠にかかる!つまり、あなたの思考は既存のやり方に限られており、発散しにくく、自然とより優雅な構造設計を逃しやすいということです.猫がネズミを捕まえるのはみんなが認めている道理ですが、すべての猫がネズミを捕まえるのですか?ネズミを見て驚いた猫がいっぱいいますね.では、本稿で指摘する道理は何でしょうか.黒板を叩いて重点を引く==インタフェースを開放して、閉鎖して実現する==引き続き重点を引く~==しかしこの道理は絶対的ではありません==
不快な罠!
オープンインタフェース、クローズインプリメンテーション、すなわち、インタフェースを宣言し、プラグインにインタフェースのインプリメンテーションを提供する必要があります.この場合、インタフェースを実装するプラグインが実行されているかどうかは確認できません.それから問題が来て、あなたはインタフェースを提供して私に使わせて、私が使う時また先にインタフェースが実現しているかどうかを確認しますか?間違いはありませんか.あなたは私にサービスを提供して、私はもちろん直接呼び出すことができることを望んでいます!これでいいです.私が呼び出す前に登録実装があるかどうかを判断しなければなりません.あなたのこのインタフェースの設計はどうしてそんなに安心させませんか.気分が悪くなったら、コードで安心させないインタフェースがどんな方法なのか見てみましょう.
1.カードフレーム
2.インタフェースの宣言(共通jarパッケージ)
3.インタフェース呼び出し
より優雅な実現!
エレガントでこんにちは!ワナさようなら!心配しないコードがなぜそんなに心配しないのか簡単に分析してみましょう.どんな分析がありますか.心配しないのは心配しないで、人の前の人と後ろの2つの様子があって、登録が実現する時勝手に調整して、登録が実現していない時はすべて空のポインタです.では、何か良い措置がありますか?デフォルトの実装を追加すればいいので、どうしても登録されていない実装の論理には行かないことになります.まとめてみると、登録されていない実装の論理を修復せず、登録されていない実装の論理を削除しました.X D
コードで優雅なインタフェースがどのように実現されているかを見てみましょう.
1.インタフェース宣言(共通jarパッケージ)
2.インタフェース呼び出し
オープンクローズの原則は、インタフェースと実装ではなく、変化と不変に対するものです.常に変化するインタフェースの実装では、サービスを提供するプラグインに閉じる必要があります.ほとんど変わらないインタフェースでは、もちろん共通のjarパッケージに開く必要があります.しかし、デフォルトのインタフェース実装では、サービス設計当初からほとんど変わらないデフォルト実装が定められており、サービスを提供するプラグインに閉じ込める必要はなく、共通のjarパッケージに完全に開放できる!
利益関係
著者のもう一つの文章は、本論文のもう一つのバージョンでもある:プラグイン化フレームワークの下でモジュール間インタフェースの新しい試み(反設計モードのインタフェース設計)
わなをかける者は、罠にかかる!つまり、あなたの思考は既存のやり方に限られており、発散しにくく、自然とより優雅な構造設計を逃しやすいということです.猫がネズミを捕まえるのはみんなが認めている道理ですが、すべての猫がネズミを捕まえるのですか?ネズミを見て驚いた猫がいっぱいいますね.では、本稿で指摘する道理は何でしょうか.黒板を叩いて重点を引く==インタフェースを開放して、閉鎖して実現する==引き続き重点を引く~==しかしこの道理は絶対的ではありません==
不快な罠!
オープンインタフェース、クローズインプリメンテーション、すなわち、インタフェースを宣言し、プラグインにインタフェースのインプリメンテーションを提供する必要があります.この場合、インタフェースを実装するプラグインが実行されているかどうかは確認できません.それから問題が来て、あなたはインタフェースを提供して私に使わせて、私が使う時また先にインタフェースが実現しているかどうかを確認しますか?間違いはありませんか.あなたは私にサービスを提供して、私はもちろん直接呼び出すことができることを望んでいます!これでいいです.私が呼び出す前に登録実装があるかどうかを判断しなければなりません.あなたのこのインタフェースの設計はどうしてそんなに安心させませんか.気分が悪くなったら、コードで安心させないインタフェースがどんな方法なのか見てみましょう.
1.カードフレーム
public class PluginFramework {
public static void registerService(String key, Object service) {
/* todo */
}
public static void unregisterService(String key) {
/* todo */
}
public static Object getService(String key) {
return null;
/* todo */
}
}
2.インタフェースの宣言(共通jarパッケージ)
public interface Service {
int method();
}
3.インタフェース呼び出し
public class Test {
public void function() {
Service service = (Service) PluginFramework.getService("key");
if (service != null) {
service.method();
}
}
}
より優雅な実現!
エレガントでこんにちは!ワナさようなら!心配しないコードがなぜそんなに心配しないのか簡単に分析してみましょう.どんな分析がありますか.心配しないのは心配しないで、人の前の人と後ろの2つの様子があって、登録が実現する時勝手に調整して、登録が実現していない時はすべて空のポインタです.では、何か良い措置がありますか?デフォルトの実装を追加すればいいので、どうしても登録されていない実装の論理には行かないことになります.まとめてみると、登録されていない実装の論理を修復せず、登録されていない実装の論理を削除しました.X D
コードで優雅なインタフェースがどのように実現されているかを見てみましょう.
1.インタフェース宣言(共通jarパッケージ)
public class Service {
private static Service service;
private static Service getService() {
if (service == null) {
service = new Service();
}
return service;
}
protected final void register() {
service = this;
}
protected final void unregister() {
service = null;
}
protected int methodImpl() {
return 0;
}
public static int method() {
return getService().methodImpl();
}
}
2.インタフェース呼び出し
public class Test {
public void function() {
Service.method();
}
}
オープンクローズの原則は、インタフェースと実装ではなく、変化と不変に対するものです.常に変化するインタフェースの実装では、サービスを提供するプラグインに閉じる必要があります.ほとんど変わらないインタフェースでは、もちろん共通のjarパッケージに開く必要があります.しかし、デフォルトのインタフェース実装では、サービス設計当初からほとんど変わらないデフォルト実装が定められており、サービスを提供するプラグインに閉じ込める必要はなく、共通のjarパッケージに完全に開放できる!
利益関係
著者のもう一つの文章は、本論文のもう一つのバージョンでもある:プラグイン化フレームワークの下でモジュール間インタフェースの新しい試み(反設計モードのインタフェース設計)