220219 - TIL

✅ 한 일

💻 수행한 것들

• 오브젝트 Chapter 1을 읽고 예제 코드 작성해보기
  : 읽으면서 그동안 은연 중에 절차지향적으로 코딩했던 적이 많다는 것을 느꼈다. 객체를 단순히 데이터 덩어리로 생각하기 보다는 자율적인 객체로 인식하고 책임을 부여하는 것이 중요하다고 느꼈다.

📝 배운 것들

클래스 다이어그램 정리하기

내가 만든 프로그램의 구조를 효과적으로 표현할 수 있는 좋은 방법 중 하나가 클래스 다이어그램이다. 데이터베이스 설계 시 E-R 다이어그램을 활용하는 것처럼 말이다. 그래서 언젠가는 그려봐야겠다하고 미루고 있었다가 오브젝트에서 클래스 다이어그램이 자주 등장하여 읽는 법을 배우고 그려보기도 해야겠다고 생각했다.

우선, 클래스 다이어그램에는 객체간의 관계를 나타내는 다양한 선이 있다.

• 의존 관계
  어떤 클래스 A의 메서드가 다른 클래스 B의 메서드를 호출하거나 인자로 받는 등으로 사용될 때, A가 B에 의존하면서 두 클래스는 의존 관계에 있게 된다. 연관관계와의 주요 차이점은 메서드 호출이 끝나면 연결이 끊어진다는 점에 있다.

• 연관 관계
  어떤 클래스 A가 멤버 변수로 다른 클래스 B의 객체의 참조를 가지고 있는 형태이다. 필드를 통해 반복적으로 다른 클래스의 메서드를 호출할 수 있다.

• 실체화 관계
  어떤 클래스를 인터페이스를 실제로 구현하는 관계를 말한다.

• 일반화 관계
  어떤 클래스를 상속받는 관계를 말한다.

관계 정의 관련 출처

리팩터링 #1. 객체가 자기의 문제를 스스로 해결하도록 자율성을 부여하라.

자신의 문제를 다른 객체에서 해결하도록 두면 자연스럽게 결합도가 올라간다. 그럼 변경이 일어나기 위해서 바꿔야 하는 코드의 양이 늘어난다. 그렇기 때문에 우리의 직관대로 문제를 해결해야 할 객체에서 해결할 수 있도록 코드를 구성하는 것이 좋다.

극장에 관객을 입장시킬 때, 극장이 모든 로직을 처리하는 것보다는 극장은 티켓 판매원과 관객만 알고 있고 티켓 판매원에게 관객을 입장을 시켜달라고 요청하는 것이 결합도가 훨씬 낮다. 극장이 모든 입장 로직을 처리하기 위해서는, (티켓 판매원, 매표소, 관객)을 모두 자세히 알고 있어야 한다. 하지만, 티켓 판매원이 모든 로직을 처리한다면 티켓 판매원에게 티켓을 판매하라는 메시지를 보내는 방법만 알고 있으면 된다.

이렇게 밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에 위임하는 객체는 응집도(Cohesion)가 높은 객체이다. 자신의 데이터를 스스로 처리하는 자율적인 객체들을 만들면 결합도는 낮추고 응집도는 높일 수 있다.

비록 실생활의 모든 것이 자율적인 존재는 아니다. 하지만 객체지향의 세계에서는 모든 것이 능동적이고 자율적인 존재로 바뀐다. 이렇게 소프트웨어 객체를 설계하는 원칙을 의인화(anthropomorphism)이라 부른다.

💪 좋은 점

• 오브젝트를 보고 지난 미션을 하며 부족했던 점이 무엇이었는지 알 수 있었다.

👀 아쉬운 점

• 클래스 다이어그램을 직접 그려보지 못했다.

🗒 개선 방향

• 나중에 복습이나 미션을 하면서 클래스 다이어그램을 그려보면서 결합도를 한번 체크해보는 것이 좋겠다.