'OOP'에 해당되는 글 2건

  1. 2013.09.24 OOP 용어 정리
  2. 2010.11.09 객체 지향 디자인 원리

OOP에서 사용되는 용어를 자유롭게 사용하지만 한마디로 정의하라면 그게 쉽지 않다 그래서 한번 정리해 보도록 하자!

인터페이스(Interface): 

1. 인터페이스 = 기능 = 약속(protocal) -> 기능은 변하지 않는다.

2. 100% 추상클래스(Abstract Class)다.

3. 상수(public static final)와 추상메서드(Abstract method)만을 같는다.(필드 X)

4. 다중 상속이 가능하다.

클래스(Class): 객체의 타입

객체(Object): 

1. 상태(Status)/특성(Characteristic), 오퍼레이션(Operation)/행동(Behaviour), 정체성(Identity)/고유 식별(고유 메모리/힙에 할당)을 같는다. 

2. 클래스의 인스턴스(Instance)이다.

3. 문제 영역의 요소들을 해결 영역에 표현한 것.

is-a 관계: 상속하여 대체 가능한 객체를 만드는 것.

위임(Delegation): 특정일의 책임을 다른 클래스나 메소드에 맡기는 것. (상속의 대안)

참조: http://java.ihoney.pe.kr/24

has-a 관계: 한 객체안에 다른 멤버 객체를 생성하는 것.

1. 구성(Composition)/A owns B: 한 객체가 다른 객체를 구성하고있다.(가지고 있다)

-> 하나의 인터페이스로 구현한 여러 클래스를 사용가능(객체를 서로 바꾸어 쓸 수 있다.)

-> 구성하는 객체의 소멸시 종속된 객체도 같이 사라진다.

2. 집합(Aggregation)/B is part of A: 한 객체가 다른 객체를 참조한다.

-> 참조하는 객체가 소명되도 참조되는 객체는 사라지지 않는다.

참조: http://valley.egloos.com/viewer/?url=http://ryukato.egloos.com/740197 

is-like-a 관계: 상속에서 파생된 객체에 메서드를 추가하면 베이스 타입에서는 사용할 수 없는 것.

오버라이딩(Overriding): 상속에서 슈퍼 클래스의 메서드를 서브 클래스에서 재 정의하는 것.

-> 자바 SE5 버전에서는 @Overrride 주석 태그가 추가되어 오버라이딩 할것을 오버로딩하려면 에러를 낸다.

-.> 오버라이딩을 방지하기위해 상위 클래스에서 final 키워드를 사용하여 메서드를 정의할 수 있다.

오버로딩(Overloading): 같은 메서드 명으로 인자 갯수를 다르게하여 여러 메서드를 생성하는 것.

다형성: 인터페이스와 구현을 분리시켜 확장 가능하고 가독성을 제공한다. late 바인딩으로 가능(동적 바인딩, 런타임 바인딩 이라고도 함)

-> 서로다른 타입의 객체들이 같은 메시지에 대해 제각기 다른 결과를 산출하는 개념

-> 슈퍼 클래스를 이용하는 코드에서 수정없이 서브 클래스를 사용할 수 있다.

업케스팅: 파생 타입의 객체를 베이스 타입으로 참조하는 것

-> 업케스팅은 쉽게 가능 하지만 다운 케스팅은 고려해 봐야 함

캡슐화: 접근 제한 (public, private, protected)

Posted by Brian B. Lee

객체지향 원리
1. 변하는 것은 캡슐화하라
2. 구현에 의존하기보다는 인터페이스에 의존하도록 코딩하라.
3. 각 클래스는 변경 요인이 오직 하나이어야 한다.
4. 클래스는 행동과 기능에 관한 것이다.

객체지향 원리 추가!
원리 #1
OCP(Open-Closed Principle) <= 유연성
 클래스 폐쇄와 개방
  폐쇄 - private 등
  개방 - 상속, 오버라이드, public 등

원리 #2
DRY(Don't Repeat Yourself) <= 중복코드 없세기
시스템의 각 정보와 기능을 말이되는 하나의 장소에 두는 것을 의미

원리 #3
SRP(Single Responsibility Principle) <= 하나의 책임만 같는 객체
 책임 찾기 방법
  1. ______ 이(가) 자신을 ______ 한다.    => 객체(클래스) 이(가) 자신을 메서드 한다.
  2. ______ 이(가) ______ 를 ______ 한다. => 객체(클래스) 이(가) 파라미터를 메서드 한다.  
  ex) 차가 자신을 운전 한다. (O)
  ex) 차가 자신을 세차 한다. (X) => 세차장이 자신을 세차 한다? (X) => 세차장이 스스로 차를 세차한다.

원리 #4
LSP(Liskov Substitution Principle) <= 부모 클래스 대체
자식 객체는 부모 객체를 대신할 수 있어야한다.

상속(Injeritance)? or 위임(Delegation)? or 구성(Composition)? or 집합(Aggregation)
=> 상속(is-a), 위임, 구성, 집합(has-a)는 상속 대신하며 상속보다 대개의 경우 선호된다 :
위의 3가지를 쓸 경우 상속보다 대개의 경우 소프트웨어는 더 유연하고 유지보수성, 확장성, 재사용성이 좋아진다.

위임: 기능 확장(포함 관계), 구성: 전체와 부분의 생명주기 동일(interface사용), 집합: 종속적 관계(생명주기 다름)

위의 내용은 Head First OOA&D Chapter 8을 요약한 것이다.
추가된 객체 지향 원리 중 마지막 4번째 LSP 원리는 아직도 이해가 잘 되지 않는다;;
UML에서 구성(Composition)과 집합(Aggregation)을 따로 표시하는데 (속이 꽉찬 다이아몬드와 속이 빈 다이아몬드)
구현 상 어떻게 다른지 그리고 interface를 사용하여 구성을 구현하는데 꼭 interface를 사용해야하는지
뭐 이런점이 의문이 남는다

Posted by Brian B. Lee