[design-patterns] 피해야 할 디자인 패턴 [닫기]

패턴이 복잡함

모든 디자인 패턴은주의해서 사용해야합니다. 제 생각 에는 패턴을 즉시 구현하는 대신 타당한 이유가있을 때 패턴을 리팩토링해야합니다 . 패턴 사용의 일반적인 문제는 복잡성을 추가한다는 것입니다. 패턴을 과도하게 사용하면 특정 응용 프로그램이나 시스템을 추가로 개발하고 유지 관리하기가 번거로워집니다.

대부분의 경우 간단한 솔루션이 있으며 특정 패턴을 적용 할 필요가 없습니다. 경험상 좋은 규칙은 코드 조각이 대체되거나 자주 변경되어야 할 때마다 패턴을 사용하고 패턴을 사용할 때 복잡한 코드에 대한주의를 기울일 준비를하는 것입니다.

기억 당신의 목표는 단순해야 하고 당신이 당신의 코드에서 지원 변화에 대한 실제적인 필요를 볼 경우 패턴을 사용합니다.

패턴에 대한 원칙

패턴이 과도하게 엔지니어링되고 복잡한 솔루션으로 이어질 수 있다면 패턴을 사용하는 것이 문제처럼 보일 수 있습니다. 그러나 프로그래머가 대부분의 패턴에 대한 토대가되는 디자인 기술과 원칙 을 읽는 것이 훨씬 더 흥미 롭습니다 . 실제로 내가 가장 좋아하는 ‘디자인 패턴’책 중 하나는 문제의 패턴에 적용 할 수있는 원칙을 반복함으로써이를 강조합니다. 관련성 측면에서 패턴보다 유용 할 정도로 간단합니다. 일부 원칙은 코드 모듈을 빌드 할 수있는 한 Liskov Substitution Principle 과 같은 객체 지향 프로그래밍 (OOP) 이상을 포함하기에 충분히 일반적 입니다.

다양한 디자인 원칙이 있지만 GoF 책 의 첫 번째 장에 설명 된 내용은 시작하기에 매우 유용합니다.

• ‘구현’이 아닌 ‘인터페이스’로 프로그래밍하십시오. (강 오브 포 1995 : 18)
• ‘클래스 상속’보다 ‘객체 구성’을 선호하십시오. (강 오브 포 1995 : 20)

잠시 동안 당신에게 가라 앉게하십시오. GoF가 작성되었을 때 인터페이스 는 추상화 (슈퍼 클래스를 의미하기도 함)를 의미하며 Java 또는 C #의 유형 인 인터페이스와 혼동해서는 안됩니다. 두 번째 원칙은 오늘날에도 여전히 흔히 볼 수 있는 상속의 남용에서 비롯됩니다 .

여기에서 Robert Cecil Martin (일명 Bob 삼촌) 이 알려준 SOLID 원칙 을 읽을 수 있습니다 . Scott Hanselman 은 이러한 원칙 에 대한 팟 캐스트 에서 Bob 삼촌을 인터뷰했습니다 .

• S 화롯불 책임 원칙
• O 펜 폐쇄 원리
• L iskov 대체 원칙
• 나는 독방 원리를 nterface
• D의 ependency 반전 원리

이러한 원칙은 동료들과 함께 읽고 토론하기에 좋은 출발점이됩니다. 원칙이 서로, 그리고 관심사 분리 및 종속성 주입 과 같은 다른 프로세스와 얽혀 있음을 알 수 있습니다 . TDD 를 한동안 수행 한 후에 는 분리 되고 반복 가능한 단위 테스트 를 생성하기 위해 어느 정도 따라야하기 때문에 이러한 원칙이 실제로 실제로 온다는 것을 알 수 있습니다 .

답변

interface IShape
{
    double intersectWith(Triangle t);
    double intersectWith(Rectangle r);
    double intersectWith(Circle c);
}

interface IShape
{
    Area getArea();
}

class Area
{
    public double intersectWith(Area otherArea);
    ...
}