객체지향과 디자인 패턴

day1 : 완성되지 않은 코드 작성 (작성 이유 : 처음시도는 지저분한 코드를 수정하기 쉬운 코드로 바꾸기 위한 테스트 코드 (미완성 코드임))

day2 : 디미터 법칙 적용 (장점 : 유지보수 용이 , 단점 : 메스드를 많이 만들다 보면 오버헤드될 수 있음)

day3 : SOLID

• 단일 책임 원칙 (Single responsibility principle SRP) : 클래스는 단 한 개의 책임을 가져야 한다.
  • 하나 클래스가 여러 책임을 가지고 있게 되면, 결합도가 높아지는 문제도 있고, 코드 변경 시 다른 책임에 주는 영향은 증가 하게 됨 이런 코드는 결국 절차지향 코드가 되므로 수정하기 어려움
• 개방 폐쇄 원칙 (Open-Closed principle OCP) : 기능을 젼경하거나 확장할 수 있으면서, 그 기능을 사용하는 코드는 수정하지 않는다.
  • 기존 interface에 새로운 기능이 추가되지만 기존 코드는 수정하지 않는다. (사용하고 있는 코드를 변경하지 않는다.)
  • 개방 폐쇄 원칙을 구현하는 다른 방법은 *상속
• 리스코프 치환 원칙(Liskov substitution principle LSP) : 상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야함.
• 인터페이스 분리 원칙(Interface segregation pringciple ISP) : 클라이언트는 자신이 사용하는 메서드에만 의존.
• 의존 역전 원칙 (Dependency inversion principle DIP)

정리 :

• 단일 책임원칙과 인터페이스 분리 원칙은 객체가 거대해지지 않도록 막아준다.
• 리스코프 치환 원칙과 의존 역전 원칙은 개방 폐쇄 원칙을 지원
• 변화되는부분을 추상화하고 다형성을 이용함으로써 기능 확장을 하면서 기존 코드를 수정하지 않도록 만들어준다.
  • 의존 역전 원칙 : 변화되는 부분을 추상화할 수 있도록 하는 것
  • 리스코프 치환 원칙 : 다형성을 도와주는 것

day4 : DI와 서비스 로케이터 (서비스 로케이터를 통해 의존 객체를 찾게 됨)

day5 : DI을 이용한 의존 객체 사용 (필요한 객체를 직접 생성하거나 찾지 않고 외부에서 넣어주는 방식!)

• 서비스 로케이터의 단점 보완을 위한 방법 ** 스프링 프레임워크가 바로 객체를 생성하고 조립해 주는 기능을 제공하는 DI framework
• 생성자 방식과 설정메서드 방식이 있음
  • 생성자 방식은 생성 시점시 필요한 모든 의존 객체를 준비할 수 있다.
  • 설정 메서드 방식은 객체를 생성한 뒤에 의존 객체 주입.
  • 의존 객체를 먼저 생성할 수 없다면 생성자 방식을 사용할 수 없음.

day6 : 디자인패턴 살펴보기