본문 바로가기

Study/오프젝트

02) 객체지향 프로그래밍

 

 

 

 

1. 클래스를 고민하기보다 객체를 고민하자

나 또한 어떤 클래스가 필요한지 고민을 한다. 객체지향은 말 그래도 객체를 지향하는 것이다.

진정한 객체지향 패러다임으로의 전환은 클래스가 아닌 객체에 초점을 맞춰야 한다.

 

 

1.1 클래스를 고민하기 전에 어떤 객체들이 필요한지 고민하자

클래스는 객체를 생성하기 위한 설계도이다. 그렇기 때문에 클래스를 정의하기 위해선 객체들이 어떤 상태와 행동을 가지는지를 먼저 생각해봐야 한다.

 

1.2 객체를 기능을 구현하기 위해 협력하는 공동체의 일원으로 보자

객체는 서로 도움을 주거나 의존하면서 협력적인 존재다. 그러므로 객체지향적으로 생각하고 싶다면 객체를 고립된 존재로 보지 말고 협력자로서 생각하자

 

 

 

 

2. 협력

객체는 상태행동을 함께 가지는 복합적인 존재다. 접근 제어 메커니즘을 통해 외부의 간섭을 최소화 해야한다. 객체의 상태는 숨기고 행동만 외부에 공개해야 한다. 객체는 다른 객체의 인터페이스에 행동을 수행하도록 요청하고, 요청받은 객체는 자율적인 방법에 따라 요청을 처리한 후 응답한다. 이러한 방법은 1장에서 언급한 메시지를 통한 상호작용이다. 자신만의 방법으로 요청을 처리하는걸 메서드라고 부른다.

 

 

 

 

3. 추상 클래스와 인터페이스

인터페이스와 추상 클래스의 차이는 '어떤 방식으로 공유하는지'에 있다.

3.1 추상 클래스

공통된 기능을 가진 클래스를 만들때 사용한다. 공통된 '행동의 구현'을 공유

3.2 인터페이스

공통된 행동에 대한 규격을 정의한다. 어떤 메소드를 반드시 구현해야 한다는 것을 명시

3.3 다형성

한 가지 형태가 여러 가지 작업으로 수행될 수 있음을 의미

 

 

 

 

4. 상속과 합성

상속클래스를 통해 강하게 결합되는 데 비해 합성메시지를 통해 느슨하게 결합된다. 그렇기 때문에 코드의 재사용성을 위해서는 합성을 선호하는 것이 더 좋은 방법이다. 하지만 상속을 절대 사용하지 말라는 건 아니다. 코드의 재사용성을 위해 합성을 선호하는 것이 옳지만 다형성을 위해 인터페이스를 재사용하는 경우에는 상속과 합성을 함께 조합해 사용해야 한다.

4.1 상속

기존의 클래스를 재사용하여 새로운 클래스를 만드는 방법

4.1 상속의  문제점

  • 캡슐화를 위반한다.
    • 상속을 이용하기 위해서는 부모 클래스의 내부구조를 잘 알고 있어야 한다. 결과적으로 부모 클래스의 구현이 자식 클래스에게 노출되기 때문에 캡슐화가 약화된다. 이에 따라 자식 클래스가 부모 클래스에 강하게 결합되어 부모 클래스를 변경할 경우 자식 클래스도 함께 변경될 확률이 높다.
  • 설계를 유연하지 못하게 만든다.
    • 부모 클래스와 자식 클래스 사이의 관계를 컴파일 시점에 결정된다. 따라서 실행 시점에 객체의 종류를 변경하는 것은 불가능하다.

4.2 합성

인터페이스에 정의된 메시지를 통해서 코드를 재사용하는 방법

  • 인터페이스에 정의된 메시지를 통해서만 재사용이 가능하기에 구현을 효과적으로 캡슐화할 수 있다.
  • 의존하는 인스턴스를 교체하는 것이 비교적 쉽기 때문에 설계를 유연하게 만든다.

'Study > 오프젝트' 카테고리의 다른 글

06) 메시지와 인터페이스  (0) 2023.12.15
05) 책임 할당하기  (0) 2023.12.11
04) 설계 품질과 트레이드오프  (1) 2023.12.07
03) 역할, 책임, 협력  (2) 2023.12.03
01) 객체, 설계  (2) 2023.11.27