ソフトウェアエンジニアリングの概要、ケースプレゼンテーションの六の設計の原則

この記事の出所：GitHubにはこちらをクリック・ || GitEEは・こちらをクリック

単一責任の原則

1、概念の説明

クラスの場合、クラスは唯一の任務を担当する必要があること。クラスは2つの機能のために責任がある場合は、状況での職務、職責2原因の変更の変化があるかもしれません。クラスは抽象ロジックやビジネスロジックに基づいて絞り込むことができます。

2、ケースプレゼンテーション

こことクラスベースの洗練方法は、実際のトラフィックに応じて選択することができます。

class Animal {
    public void dogVoice (){
        System.out.println("狗叫声：旺旺");
    }
    public void cowVoice (){
        System.out.println("牛叫声：哞哞");
    }
}
class DogVoice {
    public String getDogVoice (){
        return "旺旺" ;
    }
}
class CowVoice {
    public String getCowVoice (){
        return "哞哞" ;
    }
}

3ノート

クラスは、可読性と保守性を向上させる、コードの状況では、大規模な変化によって引き起こされるプログラムチェンジ減らすクラスの複雑さを低減します。通常の状況、単一責任の原則を遵守する必要性の下では、単一責任の原則に違反して充当することができます。

第二に、インタフェースの分離の原則

1、概念の説明

クライアントの不要なインターフェイスに依存してはならない、他のクラスに依存するクラスは、最小のインターフェイスに基づくべきです。

2、ケースプレゼンテーション

interface ReadBlog {
    String getBlog () ;
}
interface AdminBlog {
    Boolean insertBlog () ;
    Boolean updateBlog () ;
    Boolean deleteBlog () ;
}
/**
 * 读者只开放博客阅读接口
 */
class Reader implements ReadBlog {
    @Override
    public String getBlog() {
        return null;
    }
}
/**
 * 管理员有博客全部的管理权限
 */
class AdminUser implements AdminBlog,ReadBlog {
    @Override
    public String getBlog() {
        return null;
    }
    @Override
    public Boolean insertBlog() {
        return null;
    }
    @Override
    public Boolean updateBlog() {
        return null;
    }
    @Override
    public Boolean deleteBlog() {
        return null;
    }
}

3ノート

インターフェースの設計の小さな粒子サイズ、アプリケーションプログラムシステムをより柔軟、プログラム構造は、可撓性もの手段であるとしながら、開発の難易度の開発と理解が大きく減少保守なり、複雑さを増加させました。

第三に、依存関係逆転の原則

1、概念の説明

要約頼るべき両方とも低レベルレイヤモジュールモジュール、に依存してはならない。要約詳細に依存してはならない、詳細は抽象に依存する必要があり、中心的な考えは、プログラミングインターフェイスを向いています。

2、ケースプレゼンテーション

public class C01_FarmFactory {
    public static void main(String[] args) {
        Animal animal = new Dog() ;
        FarmFactory farm = new Farming() ;
        farm.breed(animal) ;
        animal = new Pig() ;
        farm.breed(animal) ;
    }
}
/**
 * 接口声明依赖对象
 */
interface FarmFactory {
    void breed (Animal animal) ;
}
class Farming implements FarmFactory {
    @Override
    public void breed(Animal animal) {
        System.out.println("农场饲养："+animal.getAnimalName());
    }
}
interface Animal {
    String getAnimalName () ;
}
class Dog implements Animal {
    @Override
    public String getAnimalName() {
        return "牧羊犬";
    }
}
class Pig implements Animal {
    @Override
    public String getAnimalName() {
        return "土猪一号";
    }
}

3ノート

システム開発の変動に関しては、抽象的に比較的安定しました。安定的かつ詳細ベースのアーキテクチャよりも柔軟性を構築するための抽象ベースのアーキテクチャ。下位モジュールは、できるだけ抽象クラスやインタフェース、優れた安定性プログラムとして持っている必要があります。抽象クラスやインタフェースである可能な限り変数の型を宣言し、この変数は、プログラムが拡大し、最適化するのに役立ちます現実とオブジェクト間の過渡的空間の存在を指します。

第四に、リヒターの置換原則

1、概念の説明

次のシナリオを想定します。

• 存在するオブジェクトは、TlのタイプをO1、および例
• 、存在型T2、およびオブジェクトのインスタンスO2

オブジェクトO1 T1のすべてのタイプがタイプT2のオブジェクトO2に置き換えている場合は、プログラムの動作は変更されません。T2は、次に、型が型T1のサブタイプです。換言すれば、ベースクラスのすべてのローカル参照は、そのサブクラス透過オブジェクトを使用しなければなりません。

2、ケースプレゼンテーション

public class C01_Calculate {
    public static void main(String[] args) {
        BizCalculate bizCalculate = new BizCalculate() ;
        System.out.println(bizCalculate.add(2,3));
    }
}
class Calculate { }
class BaseCalculate extends Calculate {
    public int add (int a,int b){
        return a+b;
    }
}
/**
 * 这里使用组合的方式完成计算
 */
class BizCalculate extends Calculate {
    private BaseCalculate baseCalculate = new BaseCalculate() ;
    public int add (int a,int b){
        return this.baseCalculate.add(a,b);
    }
}

3ノート

サブクラスは親クラスの機能を拡張することができますが、親クラスの本来の機能を変更することはできません;継承を使用する場合は、サブクラスで親クラスを上書きしないようにしよう、リヒターの置換原則に従って適切な例では、によって依存問題を解決するなど、重合性、組成物。

第五に、開閉の原則

1、概念の説明

オープニングとプログラミングの最も基本的な原則を閉じて、デザインのコード構造の設計において最も重要な設計原理を拡張するためのオープンと考えられますが、変更のため閉鎖されなければならない、構造を構築するための抽象的思考、延長の具体的な実装の詳細。

2、ケースプレゼンテーション

public class C01_BookPrice {
    public static void main(String[] args) {
        ParityBook parityBook = new DiscountBook("Java",100.00) ;
        System.out.println(parityBook.getPrice());
    }
}
interface Book {
    String getName () ;
    Double getPrice () ;
}
/**
 * 平价书籍
 */
class ParityBook implements Book {
    private String name ;
    private Double price ;
    public ParityBook(String name, Double price) {
        this.name = name;
        this.price = price;
    }
    @Override
    public String getName() {
        return this.name ;
    }
    @Override
    public Double getPrice() {
        return this.price ;
    }
}
/**
 * 打折数据扩展价格计算策略
 */
class DiscountBook extends ParityBook {
    public DiscountBook(String name, Double price) {
        super(name, price);
    }
    @Override
    public Double getPrice() {
        double oldPrice = super.getPrice();
        return oldPrice * 0.8 ;
    }
}

3ノート

開口部の設計原理に基づいており、コードの再利用と保守の開閉構造は、動作指定されたポリシー・パッケージに基づいて変化するクラスの動作を変更することができるインタフェースまたは抽象クラスの制約によって改善することができ、オープンデザインパターンを拡張可能基本的な原理は、開閉の原則に従うことです。

第六に、Dimmit原則

1、概念の説明

ディミトリス原則は、その依存クラスのクラスはよく知っていること以上の既知の原則と呼ばれます。つまり、依存クラスは、できるだけ内部ロジックは、クラスの中にカプセル化された方法を複雑に関係なくため。提供される外部のパブリックメソッドに加えて、任意の情報に開いていません。クラスとクラスの間のより密接な関係、結合のより大きな程度、多くの方法、依存、関連した、合成、重合のカップリング。

• 直接の友人の概念

2つのオブジェクト間の結合は、2つのオブジェクト間の友人関係を言う、があります。これは今、クラス内のローカル変数のうち、直接の友人ではありません、直接の友人として知られているクラスのメンバ変数、メソッドの引数、メソッドの戻り値を表示されます。原則的には、奇妙な種類は、クラス内のローカル変数として表示されないことが最善です。

2、ケースプレゼンテーション

public class C01_Employee {
    public static void main(String[] args) {
        HeadCompanyEmpManage empManage = new HeadCompanyEmpManage() ;
        BranchCompanyEmpManage branchEmp = new BranchCompanyEmpManage() ;
        empManage.printEmp(branchEmp);
    }
}
/**
 * 总公司员工
 */
class HeadCompanyEmp {
    public String name ;
    public HeadCompanyEmp(String name) {
        this.name = name;
    }
    @Override
    public String toString() {
        return "HeadCompanyEmp{name='" + name + '}';
    }
}
/**
 * 分公司员工
 */
class BranchCompanyEmp {
    public String name ;
    public BranchCompanyEmp(String name) {
        this.name = name;
    }
    @Override
    public String toString() {
        return "BranchCompanyEmp{name='" + name + '}';
    }
}
/**
 * 分公司员工管理
 */
class BranchCompanyEmpManage {
    // 添加分公司员工
    public List<BranchCompanyEmp> addEmp (){
        List<BranchCompanyEmp> list = new ArrayList<>() ;
        for (int i = 1 ; i <= 3 ; i++){
            list.add(new BranchCompanyEmp("分公司员工"+i)) ;
        }
        return list ;
    }
    // 获取分公司员工
    public void printBranchCompanyEmp (){
        List<BranchCompanyEmp> list = addEmp () ;
        for (BranchCompanyEmp emp:list){
            System.out.println(emp);
        }
    }
}
/**
 * 总公司员工管理,基于迪米特原则,不出现陌生类
 */
class HeadCompanyEmpManage {
    // 添加总公司员工
    public List<HeadCompanyEmp> addHeadEmp (){
        List<HeadCompanyEmp> list = new ArrayList<>() ;
        for (int i = 1 ; i <= 3 ; i++){
            list.add(new HeadCompanyEmp("总公司员工"+i)) ;
        }
        return list ;
    }
    public void printEmp (BranchCompanyEmpManage empManage){
        // 打印分公司员工
        empManage.printBranchCompanyEmp();
        List<HeadCompanyEmp> headEmpList = addHeadEmp () ;
        for (HeadCompanyEmp headCompanyEmp:headEmpList){
            System.out.println(headCompanyEmp);
        }
    }
}

3ノート

原則として意思デメテルの関係をカップリング不要な依存性を低減させることができるので、各クラスが低減され、クラス間の結合を低減することです。結合関係を低減することが複雑増加をもたらす、中間クラスの大量製造が容易完全に必要な依存関係、デメテル原理の過度の使用、ではありません。したがって、デメテルの原理を使用する場合は、実際のビジネスに基づいて比較検討する必要があります。

デザインサマリの七つの原則

デザインパターンと設計原理の核となるアイデアは、次のとおりです。業務アプリケーションの裁判官は、モジュールを変更することができ、かつ指定されたポリシーに基づいて、これらのモジュールの独立した、カプセル化ではなく、イデオロギー的に、それらのほとんどのモジュールが一緒に結合されているパッケージを変更するにはベースのインターフェースと抽象クラスではなく、具体的な実施プログラム。コアの目的は、相互作用する物体間の疎結合の度合いを低減することです。デザインパターンと原則は機械式、個人的な理解を適用することはできません：限り、形状など、魅力自然に悪くありません。

八、送信元アドレス

GitHub·地址
https://github.com/cicadasmile/model-arithmetic-parent
GitEE·地址
https://gitee.com/cicadasmile/model-arithmetic-parent