디자인의 원칙

디자인의 원칙

- 애플리케이션에서 달라지는 부분을 찾아내고, 달라지지 않는 부분으로부터 분리 시킨다.(바뀌는 부분은 캡슐화한다)

=> 바뀌는 부분은 따로 뽑아서 캡슐화시킨다. 그렇게 하면 나중에 바뀌지 않는 부분에는 영향을 미치지 않는 채로 그 부분만 고치거나 확장할 수 있다.

- 구현이 아닌 인터페이스에 맞춰서 프로그래밍한다.(상위형식에 맞춰서 프로그래밍한다)

 => 변수를 선얼할때는 보통 추상클래스나 인터페이스 같은 상위 형식으로 선언한다.

객체를 변수에 대입할 때 상위 형식을 구체적으로 구현한 형식이라면 어떤 객체든 집어넣을 수 있기 때문이다. 변수를 선언하는 클래스에서 실제 객체의 형식을 몰라도 된다.

구현에 맞췄을경우

Dog d = new Dog();

d.bark();

상위형식 맞췄을 경우

Animal animal = new Dog();

animal.makeSound();

상위형식의 인스턴스를 만드는 과정을 직접코드로 만드는 대신 구체적으로 구현된 객체를 실행시에 대입하는 것.

a = getAnimal();

a.makeSound();

-상속보다는 구성을 활용한다.("A에는 B가 있다")

=>구성(Composition)을 이용하여 시스템을 만들면 유연성을 크게 향상시킬수 있다.

예시) 오리

=============== 스트래티지 패턴 ===========================

-서로 상호작용을 하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인을 사용해야 한다.

=> 느슨하게 결합하는 디자인을 사용하면 변경 사항이 생겨도 무난히 처리할 수 있는 유연한 객체지향 시스템을 구축할 수 있다.

객체 사이의 상호 의존성을 최소화할 수 있기 때문이다. (Loose Coupling)

예시) 날씨

=============== 옵저버 패턴 ===========================

- 클래스는 확장에 대해서 열려 있지만 변경에 대해서는 닫혀 있어야 한다. (OCP)

예시) 커피주문

=============== 데코레이터 패턴 ===========================

- 추상화된 것에 의존하라. 구상 클래스에 의존하지 않도록 한다. 

예시) 피자주문

=============== 팩토리 메서드 패턴 / 추상 팩토리 패턴 ===========================

- 최소 지식 원칙 - 정말 친한 친구하고만 얘기하라

예시) 홈시어터

=============== 퍼사드 패턴 ===========================

- 헐리우드 원칙 - 먼저연락하지 마세요. 저희가 연락드리겠습니다.

예시) 커피와 차 주문

=============== 템플릿 메서드 패턴 ===========================

- 어떤 클래스가 바뀌는 되는 이유는 한가지 뿐이어야만 한다.

예시) 팬케이크 하우스와 식당 메뉴 통합

=============== 이터레이터와 컴포지트 패턴 ===========================

디자인의 원칙

1. 애플리케이션에서 달라지는 부분을 찾아내고, 달라지지 않는 부분으로부터 분리시킨다.

=> 달라지는 부분을 찾아서 캡슐화. 바뀌지 않는 부분만 고치거나 확장할 수 있다.

2. 구현이 아닌 인터페이스에 맞춰 프로그래밍한다.

=> 상위형식에 맞춰 프로그래밍한다. (변순선언시 추상클래스나 인터페이스 같은 상위 형식으로 선언) 다형성을 활용

3. 상속보다는 구성을 활용한다.

=> A는 B이다 보다는 A에 B가 있다. 유연성을 크게 향상

4. 서로 상호작용을 하는 객체 사이에서는 가능하면 느슨한 결합을 하는 디자인을 사용해야 한다.

=> 그 둘이 상호작용을 하긴 하지만 서로에 대해 서로 잘 모른다는 것을 의미.

->변경상항이 생겨도 무난히 처리할 수 있는 유연한 객체지향 시스템을 구축할 수 있고, 객체 사이의 상호의존성을 최소화 할 수 있다.

5. 클래스는 확장에 대해서 열려 있어야 하지만 코드 변경에 대해서는 닫혀 있어야 한다.

=> 기존코드는 건드리지 않고 채로 확장을 통해서 새로운 행동을 간단하게 추가할 수 있도록 한다.

6. 추상화된 것에 의존하도록 만들어라. 구상클래스에 의존하다록 만들지 않도록 한다.

=>고수준 구성요소는 다른 저수준 구성 요소에 의해 정의되는 행동이 들어 있는 구성요소를 뜻한다.

-> 구상 클래스처럼 구체적인 것이 아닌 추상클래스나 인터페이스와 같이 추상적인것에 의존하는 코드를 만들어야한다.

7. 최소 지식 원칙 - 정말 친한 친구하고만 얘기하라.

=> 어떤 메서드에서든지 네 종류의 객체의 메서드만 호출 (객체 자체, 메서드에 매개변수로 전달된 객체, 그 메서드에서 생성하거나 인스턴스를 만든 객체, 그 객체에 속한 구성 요소)

8. 헐리우드 원칙 - 먼저연락하지 마세요. 저희가 연락드리겠습니다.

=> 저수준 모듈을 언제 어떻게 호출할지는 고수준 모듈에서 결정하는 것이 좋다.

-> 의존성부패(dependency rot) 방지를 할 수 있다.

고수준 구성요소가 저수준 구성요소에 의존하고, 그 저수준 구성요소는 다시 고수준 구성요소에 의존하고, 그 고수준 구성요소는 다시 또 다른 구성요소에 의존하고, 그 다른 구성요소는 또 저수준 구성요소에 의존하는 것과 같은 식으로 의존성이 복잡하게 꼬여있는 것을 의존성의 부패라고 부른다.

이렇게 의존성이 부패되면 시스템이 어떤식으로 디자인된것인지 거의 아무도 알아볼수 없게된다.

9. 어떤 클래스가 바뀌는 되는 이유는 한가지 뿐이어야만 한다.

=> 어떤 클래스에서 맡고 있는 모든 역할들은 나중에 코드 변환을 불러올수 있다.

역할이 두개 이상 있으면 바뀔수 있는 부분이 두가지 이상이 되는것이다.

한 클래스에서는 한가지 역할만 맡도록 해야 한다