개발자가 반드시 정복해야 할 객체 지향과 디자인패턴 1

개발자가 반드시 정복해야 할 객체 지향과 디자인패턴 

 

Part1. 객체지향

• 클래스 구조도
• 공통의 기능 단위를 추출

 

• 절차 지향 : 프로시저를 이용한 프로그래밍 방법 / 데이터를 공유
• 객체 지향 : 객체를 이용한 프로그래밍 방법 / 데이터와 관련된 프로시저를 객체 단위 

 

• 객체의 책임과 크기는 작을 수록 좋다
• 의존 : 의존하고 있는 코드나 타입에 영향을 준다.  (UML 참고)
• 캡슐화 : 기능 구현을 캡슐화하여 내부 구현이 변경되더라도 다른 영향을 최소화
• 상속 : 기능을 확장해서 새로운 기능을 구현할 때 사용
• 다형성 : 타입 상속을 통해서 다형성을 구현, 다중 상속을 위해서는 interface를 이용
• 추상 타입과 유연함 : 추상화가 되어 있지 않은 코드는 주로 동일 구조로 갖는 if-else 블록으로 드러난다. 요구 사항의 변화와 함께 점진적으로 도출이 된다. 앞으로의 변경 가능성이 높아 보이는 경우에만 적용할 것, 복잡성이 커지기 때문.

 

• 테스트 주도 개발(Test Driven Development) : 테스트 코드를 먼저 작성하고 실제 코드를 작성하는 방법으로 개발하는 기법, TDD는 별도의 분리되는 인터페이스로 인해 완성이 되기전부터도 테스트를 진행하며 개발 할 수 있게 된다.  
• http://javacan.tistory.com/entry/MocktestUsingMockito
  
• 재사용: 상속보단 조립
• 상속을 통한 재사용의 단점 1. 상위 클래스 변경의 어려움
• 상속을 통한 재사용의 단점 2. 클래스의 불필요한 증가
• 상속을 통한 재사용의 단점 3. 상속의 오용
• 조립을 이용한 재사용 : 다른 객체를 조립해서 필드로 가지기
• 위임 : 보통 조립 방식을 이용해서 위임을 구현함

 

Part2. 설계 원칙 / DI와 서비스 로케이터

Part3. 주요 디자인 패턴

 

 

좋았던 말

• 소프트웨어는 변화할 수 있어야한다. 이게 또 다른 소프트웨어의 가치이다.
• 머리로만 하든, 테스트 코드를 만들든, 종이에 적어서 나열을 하든 완벽하진 않더라도 정리가 필요하다.

 

Part2. 설계 원칙 / DI와 서비스 로케이터

 

설계 원칙 : SOLID

• 단일 책임 원칙 : 클래스는 단 한개의 책임을 가져야 한다.
• 개방-폐쇄 원칙 : 확장에는 열려 있어야 하고, (기존 그 기능을 사용하는 코드의)변경에는 닫혀 있어야 한다. 비슷한 if-else 블록이 존재하는 것은 개방 폐쇄 원칙을 깨뜨리는 코드일 수 있다. 
• 리스코프 치환 원칙 : 상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다. Instanceof 연산자를 사용하는 것은 전형적인 리스포크 치환 원칙을 위반할 때 발생한다. 추상화를 통해 리스코프 치환 원칙을 유지할 것
• 인터페이스 분리 원칙: 인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다. 
• 의존 역전 원칙 : 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안 된다. 저수준 모듈이 고수준 모듈에서 정의한 추상 타입에 의존해야 한다.

 

DI(Dependency Injection)와 서비스 로케이터

 

DI : 외부에서 사용할 객체를 주입 해주는 방식, 메인 메소드에서 생성자를 통해 이들이 사용할 객체를 주입한다.

• 생성자 방식
• 설정 메서드 방식

 

서비스 로케이터 : 로케이터를 통해 필요로 하는 객체를 직접 찾는 방식

• 객체 등록 방식
• 상속을 통한 구현 방식