OO 소프트웨어 디자인 원칙

문제

나는 다음과 같은 소프트웨어 디자인 원칙의 열렬한 팬입니다. 단단한 그리고 마른. OO 소프트웨어 설계에는 어떤 원칙이 존재합니까?

메모. 나는 "코드 주석"과 같은 답을 찾고있는 것이 아니라 대신 논의 된 것과 같은 oo 디자인 원칙을 찾고 있습니다. 밥 삼촌.

해결책

Wikipedia의 상당히 포괄적 인 목록 :

다른 팁

높은 응집력 - 디자인중인 모듈의 책임은 얼마나 집중되어 있습니까?

낮은 커플 링 - 모듈이 다른 모듈에 의존하는 정도.

상속에 대한 구성은 하나입니다.

많은 사람들, 특히 OO에 새로운 사람들은 구성을 사용하는 것이 실제로 필요한 수업을 확장하기 시작합니다. 실제로 당신이 스스로에게 물어봐야한다면, 새로운 클래스 B는 A 클래스 A입니까? 그렇지 않다면 확장해서는 안됩니다.

예를 들어, 내가 있다고 가정 해 봅시다 Person 클래스, a Car 수업, 그리고 나는 DrivenCar 수업. 순진한 구현은 말하는 것입니다 (우리가 여러 상속을 받았다고 가정 해 봅시다)

class DrivenCar extends Person, Car  { ... }

Drivencar는 사람의 유형입니까? 아니에요. 사람을 연장해서는 안됩니다. Drivencar는 차입니까? 예, 확장하는 것이 합리적입니다

조성을 사용하여 구현은 모양이 될 것입니다

class DrivenCar extends Car {
    private Person driver;
}

그만큼 파악 패턴. 예, 그들은 다소 사소한 것 같습니다. 더 많은 관련 패턴이 보여주는 핵심 특성으로의 증류와 비슷합니다.

상호 작용. 대부분의 설계 패턴은 인터페이스 및 구현의 분리를 기반으로합니다.

API가 성장할 것으로 예상되면 인터페이스 대신 추상 클래스를 사용하십시오. 인터페이스에 새 메소드를 추가하려면 구현하는 모든 클래스를 변경해야합니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow