GYUD-TECH

[스터디: 객체지향의 사실과 오해] 객체지향설계 본문

스터디

[스터디: 객체지향의 사실과 오해] 객체지향설계

GYUD 2024. 2. 1. 01:57

객체지향설계의 3가지 관점

1. 개념관점: 사용자가 도메인을 바라보는 관점
2. 명세관점: 객체의 책임에 초점을 맞추는 관점
3. 구현관점: 실제 동작하는 코드를 작성하는 관점

애플리케이션을 설계할 때 먼저 개념관점으로 도메인을 떠올리고, 명세 관점으로 객체에 책임을 할당하고, 구현 관점으로 코드를 작성하는 것 같지만 실제로는 동일한 클래스를 바라보는 다른 시각을 뜻한다.

 

클래스가 은유하는 개념은 도메인 관점에 반영되고, 클래스의 공용인터페이스는 명세 관점에 반영되고, 클래스의 속성과 메서드는 구현 관점에 반영된다.

 

이렇게 한개의 클래스 내에서 여러개의 관점을 찾아볼 수 있다.

💡 결국, 클래스는 개념, 인터페이스, 구현을 모두 드러내야하며, 이 관점들을 쉽게 식별할 수 있게 분리해야한다.

 


객체지향설계 방법

책에서는 커피 주문 기능을 예로들어 객체지향설계 방법을 설명한다.

 

1. 먼저 커피 주문을 수행하기 위해서 어떤 객체가 필요할지 떠올린다.

  • 메뉴를 주문하는 손님객체
  • 메뉴 종류를 알려주는 메뉴판 객체
  • 메뉴판 내의 메뉴항목 객체
  • 커피를 만드는 바리스타객체
  • 커피객체
더보기

만약 내가 커피 주문을 설계했다면, 커피 객체에 가격을 추가하여, 메뉴항목 객체를 생성하지 않았을 것이다.

이렇게 하면 커피 객체에 접근했을 때 가격까지 알 수 있고, 커피이름을 메뉴판 항목 객체와 커피 객체에 중복하여 저장할 필요도 없다는 장점이 있다.

 

하지만, 메뉴판 항목에서는 커피 가격과 이름만 알면 되는데 불필요한 커피의 맛이나 양과 같은 정보도 같이 조회되며, 객체의 크기가 커져서 재사용에 어려울 것이다.

 

따라서, 책의 내용대로 객체를 분리하는 것이 더 유지보수에 용이할 것 같다는 생각을 했다.

 

2. 객체와의 관계를 생각한다.

  • 메뉴판에 메뉴항목이 포함되는 것처럼 특정 객체에 다른 객체가 포함되는 것을 포함관계 라고 한다.
  • 손님과 메뉴판의 관계처럼 포함된것이 아니라 서로를 의존하는 것을 연관관계 라고 한다.

 

3. 관계속의 협력을 생각한다.

객체와 관계를 가지는 다른 객체와의 협력을 위해 어떤 메시지를 주고받을지 떠올린다.

이렇게 메시지를 바탕으로 책임과 행동, 상태를 정의한다.

 


예시속에서 객체지향의 3가지 관점 찾기

위 설계 방식에서 객체지향의 3가지 관점을 찾아보자.

 

개념관점

손님, 메뉴판, 메뉴항목, 바리스타, 커피 객체는 개념관점에 의해서 설계되었다.

이렇게 설계하면 사용자의 관점을 반영하기 떄문에 객체의 역할을 이해하기 쉽고, 변경 가능성도 낮아진다.

 

명세관점

public 메서드와 같이 외부 객체가 아는 공용인터페이스에 초점을 맞춘 관점이다.

공용 인터페이스가 변경되면 외부 객체에도 영향을 미치기 떄문에, 잘 변하지 않는 안정적인 인터페이스를 만들어야한다.

 

구현관점

메서드와 속성과 같이 책임을 어떻게 수행할지 동작 코드에 초점을 맞춘 관점이다.

이러한 구현 코드는 변경될 수 있으며, 변경된다 하더라도 외부에 영향을 미쳐서는 안된다.

 

 

이번 챕터에서는 커피 주문 예시를 들면서 public 메서드를 공용 인터페이스로 정의하고, 클래스를 작성하는 방법을 보여주었다.

이렇게 외부에 영향을 주지 않는 클래스를 선언하는 것은 우테코에서도 많이 연습했던 객체분리 내용과 비슷했다.

객체를 분리하여 스스로의 책임만 수행하도록 설계함으로써, 안정적인 설계를 할 수 있다는 것이다.

 

이 내용은 이미 우테코를 통해 어느정도 익숙했기 때문에, 나는 책의 전체적인 내용을 인터페이스 설계로 받아들였다.

 

책에서는 클래스로 예를 들며, 캡슐화에 초점을 맞추어 설명하고 있지만, 이를 확장하여 인터페이스에 적용할 수 있다.

 

인터페이스를 통해서 외부 객체와의 창을 만들고, 이를 상속받은 클래스에서 구현방식을 선택함으로써 상대 객체에 대해 모른 채 오로지 역할에 의존하여 객체간 협력을 설계할 수 있다.

 

객체의 역할은 잘 변경되지 않기 때문에 변경 가능성도 낮을 뿐더러, 변경에도 용이하다.

 


느낀점

4개월 전쯤 이 책을 처음 읽고, 스터디 원들과 함께 다시 읽어보니 이전에는 보이지 않았던 내용들이 눈에 들어왔다.

 

처음 책을 읽을 때는, 마지막 장의 객체지향적 설계를 어떻게 해야하는지에 관한 부분이 가장 인상깊었다.

커피 주문의 예시를 읽으면서, 메시지 중심의 객체지향 설계법을 배울 수 있었고, 우테코 문제에서 객체를 분리할때 이 개념을 적용해 보기도 하였다.

 

하지만 이번에 책을 다시 읽으면서는 자바의 인터페이스 개념과 연관지어서 책을 많이 읽었던 것 같다.

객체지향의 특성인 캡슐화와 다형성을 활용하여 객체들을 쉽게 갈아끼울 수 있도록 설계하는 부분이 흥미로웠다.

 

또한, 책의 내용을 내 프로젝트에 대입하여 고민해 보는 과정을 통해 객체지향에 대해 더 깊게 공부할 수 있었다.

 

객체지향의 사실과 오해 스터디는 마무리 되었지만, 스터디원들과 계속해서 스터디를 이어나갈 것이다.

새로운 개념을 깊게 학습하고, 유익한 자료를 공유하며 함께 성장해 나가는 중이다.