デザインパターンの6つの原則とは何ですか?

三角形や四角形の面積を計算する場合…ソースコードを変更せずにShapeインターフェースを実装させるだけで済みます。

リヒター置換原則

リヒター置換原則では、主に継承に関するいくつかの原則、つまり、継承をいつ使用するか、いつ何を使用するかを説明します。継承とその基礎となる原則を使用すべきではありません。 Liskov 置換はもともと継承再利用の基礎であり、基底クラスとサブクラス間の関係を反映し、開始と終了の原則を補足し、抽象化を達成するための特定の手順を規定します。 <br/>

リスコフ置換原理の役割

リスコフ置換原理の主な機能は次のとおりです。

• リスコフ置換原理は、開閉原理を実現する重要な方法の 1 つです。

• #これにより、継承で親クラスをオーバーライドすることによって引き起こされる再利用性の低下という欠点が克服されます。

• #アクションの正確性を保証するものです。つまり、クラスの拡張によって既存のシステムに新しいエラーが導入されることはなく、コード エラーの可能性が減ります。

• プログラムの堅牢性を強化し、変更時に非常に優れた互換性を実現し、プログラムの保守性と拡張性を向上させ、要件の変更に必要な時間を短縮します。 . リスクが導入されました。

リスコフ置換原則 (継承) の実装方法

わかりやすく言えば、リスコフ置換原則 つまり、サブクラスは親クラスの機能を拡張できますが、親クラスの元の機能を変更することはできません。言い換えると、サブクラスが親クラスを継承する場合、新しい関数を完成させるために新しいメソッドを追加する場合を除き、親クラスのメソッドをオーバーライドしないようにしてください。

上記の理解に基づいて、リスコフ置換原則の定義は次のように要約できます:

• サブクラスは親クラスの抽象メソッドを実装できます。クラスの非抽象メソッド

• # サブクラスは独自の一意のメソッドを追加できます

• サブクラスのメソッドが親クラスのメソッドをオーバーライドする場合、メソッドの前提条件 (メソッドの入力パラメーター) は親クラスのメソッドよりも緩くなります

• サブクラスのメソッドが親クラスのメソッドを実装する場合 (上書き/オーバーロード、または抽象メソッドの実装)、メソッドの事後条件 (つまり、出力/戻り値)

依存関係の反転 (配線図の詳細)

<br/>

依存性と反転原理の機能

• 依存関係逆転の原則により、クラス間の結合を減らすことができます。

• #依存関係逆転の原理により、システムの安定性が向上します。

• #依存関係逆転の原則により、並列開発によって引き起こされるリスクを軽減できます。

• #依存関係逆転の原則により、コードの可読性と保守性が向上します。

依赖倒置原则的实现方法

依赖倒置原则的目的是通过要面向接口的编程来降低类间的耦合性，所以我们在实际编程中只要遵循以下4点，就能在项目中满足这个规则。

• 每个类尽量提供接口或抽象类，或者两者都具备。

• 变量的声明类型尽量是接口或者是抽象类。

• 任何类都不应该从具体类派生。

• 使用继承时尽量遵循里氏替换原则。

依赖倒置原则在“顾客购物程序”中的应用。

分析：本程序反映了 “顾客类”与“商店类”的关系。商店类中有 sell() 方法，顾客类通过该方法购物以下代码定义了顾客类通过韶关网店 ShaoguanShop 购物

class Customer {
    public void shopping(ShaoguanShop shop) {
        //购物
        System.out.println（shop.sell());
    }
}

但是，这种设计存在缺点，如果该顾客想从另外一家商店（如婺源网店 WuyuanShop）购物，就要将该顾客的代码修改如下：

class Customer {
    public void shopping(WuyuanShop shop) {
        //购物
        System.out.println(shop.sell());
    }
}

顾客每更换一家商店，都要修改一次代码，这明显违背了开闭原则。

存在以上缺点的原因是：顾客类设计时同具体的商店类绑定了，这违背了依赖倒置原则。

解决方法是：定义“婺源网店”和“韶关网店”的共同接口 Shop，顾客类面向该接口编程，其代码修改如下：

class Customer {
    public void shopping(Shop shop) {
        //购物
        System.out.println(shop.sell());
    }
}

class Customer {
    public void shopping(Shop shop) {
        //购物
        System.out.println(shop.sell());
    }
}

这样，不管顾客类 Customer 访问什么商店，或者增加新的商店，都不需要修改原有代码了，其类如下图所示：<br/><br/><br/><br/>程序代码如下：

package principle;
public class DIPtest
{
    public static void main(String[] args)
    {
        Customer wang=new Customer();
        System.out.println("顾客购买以下商品："); 
        wang.shopping(new ShaoguanShop()); 
        wang.shopping(new WuyuanShop());
    }
}
//商店
interface Shop
{
    public String sell(); //卖
}
//韶关网店
class ShaoguanShop implements Shop
{
    public String sell()
    {
        return "韶关土特产：香菇、木耳……"; 
    } 
}
//婺源网店
class WuyuanShop implements Shop
{
    public String sell()
    {
        return "婺源土特产：绿茶、酒糟鱼……"; 
    }
} 
//顾客
class Customer
{
    public void shopping(Shop shop)
    {
        //购物
        System.out.println(shop.sell()); 
    }
}

程序的运行结果如下：

顾客购买以下商品：
韶关土特产：香菇、木耳……
婺源土特产：绿茶、酒糟鱼……

インターフェイス分離原則 (インターフェイス)

インターフェイス分離原則 (ISP) では、プログラマーは、肥大化したインターフェイスをより小さなインターフェイスに分割する必要があります。 , そのため、インターフェイスには顧客が関心のあるメソッドのみが含まれます。 <br/>

2002 年、Robert C. Martin は「インターフェイス分離原則」を次のように定義しました: クライアントは、使用していないメソッドに依存することを強制されるべきではありません。この原則には別の定義があります。あるクラスの別のクラスへの依存関係は、可能な限り最小のインターフェイスに依存する必要があります。

上記の 2 つの定義の意味は、呼び出しに依存するすべてのクラスに対して巨大なインターフェイスを構築しようとするのではなく、各クラスに必要な専用インターフェイスを確立することです。

インターフェイス分離の原則と単一責任は、どちらもクラスの凝集性を向上させ、クラス間の結合を軽減することであり、カプセル化の概念を具体化していますが、この 2 つは異なります:

• 単一責任原則は責任に焦点を当てますが、インターフェイス分離原則はインターフェイスの依存関係の分離に焦点を当てます。

• 単一責任原則は主にプログラムの実装と詳細を目的としたクラスを制約し、インターフェイス分離原則は主に抽象化とインターフェイスを制約します。プログラム全体のフレームワークの構築。

#インターフェイス分離原則の利点

• 肥大化したインターフェースを複数の粒度の小さなインターフェースに分解すると、外部変更の拡散を防ぎ、システムの柔軟性と保守性を向上させることができます。

• インターフェイスの分離により、システムの凝集性が向上し、外部との相互作用が減少し、システムの結合が減少します。

• インターフェースの粒度が適切に定義されていれば、システムの安定性は保証できますが、定義が小さすぎると、システムの安定性が保証されなくなります。インターフェイスが多く設計が複雑になり、定義が大きすぎると柔軟性が低下し、カスタマイズされたサービスが提供できなくなり、プロジェクト全体に予期せぬリスクがもたらされます。

• インターフェース全体の定義はインターフェースの継承を通じて実現できるため、複数の特殊なインターフェースを使用すると、オブジェクト階層を反映することもできます。

• # プロジェクト エンジニアリングにおけるコードの冗長性を削減できます。通常、大きすぎるインターフェイスには未使用のメソッドが多数含まれているため、このインターフェイスを実装する場合は冗長なコードを設計する必要があります。

#インターフェイス分離原則の実装方法インターフェイス分離原則を具体的に適用する場合は、次のとおりです。測定するためのいくつかのルールに従う必要があります。

• #インターフェイスは、制限内で可能な限り小さくする必要があります。インターフェイスは 1 つのサブモジュールまたはビジネス ロジックのみを提供します。

• # インターフェイスに依存するクラスのサービスをカスタマイズします。呼び出し元が必要とするメソッドのみを提供し、不要なメソッドはブロックします。

• #環境を理解し、盲目的に従うことを拒否してください。各プロジェクトまたは製品には、選択された環境要因があります。環境が異なれば、インターフェイス分割の基準も異なります。ビジネス ロジックを深く理解してください。

• #結束力を高め、外部とのやり取りを減らします。ほとんどのことを達成するためにインターフェイスで使用するメソッドを最小限にします。

インターフェイスの分離については、単一責任で説明されている例を参照できます:

public interface UserService {
    
    public void login(String username, String password);
    public void register(String email, String username, String password);
    public void logError(String msg);
    public void sendEmail(String email);
    
}

这时候，应该就能理解拆分的好处了。

迪米特法则 (类与类之间的关系)

迪米特法则（Law of Demeter，LoD）又叫作最少知识原则（Least Knowledge Principle，LKP)，产生于 1987 年美国东北大学（Northeastern University）的一个名为迪米特（Demeter）的研究项目，由伊恩·荷兰（Ian Holland）提出，被 UML 创始者之一的布奇（Booch）普及，后来又因为在经典著作《程序员修炼之道》（The Pragmatic Programmer）提及而广为人知。<br/>

迪米特法则的定义是：只与你的直接朋友交谈，不跟“陌生人”说话（Talk only to your immediate friends and not to strangers）。其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。

迪米特法则中的“朋友”是指：当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象同当前对象存在关联、聚合或组合关系，可以直接访问这些对象的方法。

迪米特法则的优点

迪米特法则要求限制软件实体之间通信的宽度和深度，正确使用迪米特法则将有以下两个优点。

• 降低了类之间的耦合度，提高了模块的相对独立性。

• 由于亲合度降低，从而提高了类的可复用率和系统的扩展性。

但是，过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。

迪米特法则的实现方法

从迪米特法则的定义和特点可知，它强调以下两点：

• 从依赖者的角度来说，只依赖应该依赖的对象。

• 从被依赖者的角度说，只暴露应该暴露的方法。

所以，在运用迪米特法则时要注意以下 6 点。

• 在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有利于实现可复用的目标。

• 在类的结构设计上，尽量降低类成员的访问权限。

• 在类的设计上，优先考虑将一个类设置成不变类。

• 在对其他类的引用上，将引用其他对象的次数降到最低。

• 不暴露类的属性成员，而应该提供相应的访问器（set 和 get 方法）。

• 谨慎使用序列化（Serializable）功能

明星与经纪人的关系实例。

分析：明星由于全身心投入艺术，所以许多日常事务由经纪人负责处理，如与粉丝的见面会，与媒体公司的业务洽淡等。这里的经纪人是明星的朋友，而粉丝和媒体公司是陌生人，所以适合使用迪米特法则，其类图如下图所示。<br/><br/><br/><br/>代码如下：

package principle;
public class LoDtest
{
    public static void main(String[] args)
    {
        Agent agent=new Agent();
        agent.setStar(new Star("林心如"));
        agent.setFans(new Fans("粉丝韩丞"));
        agent.setCompany(new Company("中国传媒有限公司"));
        agent.meeting();
        agent.business();
    }
}
//经纪人
class Agent
{
    private Star myStar;
    private Fans myFans;
    private Company myCompany;
    public void setStar(Star myStar)
    {
        this.myStar=myStar;
    }
    public void setFans(Fans myFans)
    {
        this.myFans=myFans;
    }
    public void setCompany(Company myCompany)
    {
        this.myCompany=myCompany;
    }
    public void meeting()
    {
        System.out.println(myFans.getName()+"与明星"+myStar.getName()+"见面了。");
    }
    public void business()
    {
        System.out.println(myCompany.getName()+"与明星"+myStar.getName()+"洽淡业务。");
    }
}
//明星
class Star
{
    private String name;
    Star(String name)
    {
        this.name=name;
    }
    public String getName()
    {
        return name;
    }
}
//粉丝
class Fans
{
    private String name;
    Fans(String name)
    {
        this.name=name;
    }
    public String getName()
    {
        return name;
    }
}
//媒体公司
class Company
{
    private String name;
    Company(String name)
    {
        this.name=name;
    }
    public String getName()
    {
        return name;
    }
}

程序的运行结果如下：

粉丝韩丞与明星林心如见面了。
中国传媒有限公司与明星林心如洽淡业务。