소프트웨어 공학 개요, 사례 발표의 여섯 개 설계 원칙

이 문서 출처 : GitHub의이 · 여기를 클릭 || GitEE이 · 여기를 클릭하십시오

단일 책임 원칙

1 개념 설명

클래스의 경우 클래스는 단지 의무에 대한 책임을 져야한다는 것을. 클래스가이 개 기능을 담당하는 경우, 의무, 책임 상황이 명 원인 변경에 변화가있을 수 있습니다. 클래스는 추상적 인 논리 나 비즈니스 로직을 기반으로 정제 할 수있다.

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 개념 설명

다음과 같은 시나리오를 가정합니다 :

• 존재하는 객체는 T1 내지 유형을 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 주

서브 클래스가 상위 클래스의 기능을 확장 할 수 있지만, 부모 클래스의 원래 기능을 변경할 수 없습니다, 상속을 사용하는 경우, 서브 클래스에서 부모 클래스를 오버라이드 (override)하지 않으려 고, 리히터 대체 원칙에 따라 적절한 경우에 의해 중합 성 조성물 등의 문제가 해결 의존한다.

다섯째, 개폐의 원리

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 케이스 프레젠테이션

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