4일차 - 객체 지향 설계를 위한 자세

2023.08.03 THU
33p ~ 50p

 

3일차 내용 ⬇️

2023.08.02 - [개발 서적 기록/오브젝트_조영호] - 3일차 - 캡슐화를 통해 결합도 낮추기

3일차 - 캡슐화를 통해 결합도 낮추기

---

설계란 코드를 배치하는 것이다.

좋은 설계는 요구하는 기능을 완전히 수행하면서, 변경이 생길 때 매끄럽게 손쉽게 적용할 수 있는 설계다.

 

왜냐하면 요구사항은 항상 변하기 때문이다.

➡️ 요구사항은 코드 수정을 초래한다.

➡️ ➡️ 코드의 수정은 버그 발생률을 높인다.

➡️ ➡️ ➡️ 버그가 발생하면, 코드를 수정할 의지가 꺾인다. 

 

따라서, 변경이 쉬운 코드를 작성해야한다.

변경하기 쉽기 윈해서는 이해하기 쉽게 작성하는 것이 좋다.

객체의 행동의 흐름을 더 쉽게 파악할 수 있기 때문이다.

 

객체 지향적인 클래스 설계

3일차에 거쳐서, 좋은 설계는

1. 잘 작동하고

2. 변경이 매끄럽고

3. 이해하기 쉬운

설계를 말한다는 것을 반복적으로 깨달았다.

 

이것이 객체 지향적인 코드의 방향성이라면,
우리는 어떤 생각과 자세로 프로그래밍해야 객체 지향 프로그래밍을 적용했다고 말할 수 있을까?

 

두가지를 고민하고, 고려해야한다.

1. 어떤 객체가 필요한 것인지 고민한다.
   • 어떤 객체가 필요한가?
   • 그 객체는 어떤 상태와 행동을 가져야하는가?
   • 이 두가지를 고민한 후에 클래스의 윤곽을 잡아, 객체에 대한 클래스의 아이덴티티를 확립한다.
2. 객체는 협력하는 공동체의 일원임을 고려한다.
   • 객체들의 윤곽을 잡은 후, 공통된 특성과 상태를 가진 객체는 타입으로 분류한다.
   • 그리고 그 타입으로 클래스를 구현한다.

---

클래스의 내부, 외부 분리

즉, 클래스의 경계를 구분지어야한다.

 

경계를 구분지을 때에는 접근 제어자를 통해서 접근을 제어한다.

객체의 상태는 숨기고, 필요한 행동만 외부에 공개해야한다.

그래서 객체의 속성은 private, 필요에 따라서 적절히 메서드는 public으로 경계를 지을 수 있다.

 

이로써 객체의 자율성을 보장할 수 있다.

 

경계의 구분은 곧 자율성의 보장이다.

클래스의 경계를 명확히 하는 행위는 제한적으로 보이지만, 사실은 객체의 자율성을 보장한다.

왜냐하면 구현이 은닉되어, 각자의 역할에 충실할 수 있기 때문이다.

• 클래스 작성자는 클라이언트 프로그래머로부터의 영향을 걱정할 필요가 없어, 자유롭게 내부 로직을 변경할 수 있다.
• 클라이언트 프로그래머는 알아야할 지식의 양이 줄어드는 자유가 생긴다.

메서드를 통해 협력하자

경계를 구분지으면서, 필요한 행동은 접근 가능한 메서드로 제공해야한다. 그래서 메서드는 다른 객체 간의 협력 과정이다.

 

객체는 다른 객체의 메서드를 통해서 서로의 니즈를 제공하므로 협력하는 것이고, 요청은 메시지로 전달된다.

메서드를 호출하는 것이 곧 메시지 전송하는 것이다. 그래서 메시지의 전송/수신으로 객체들은 협력한다.

 

따라서 메서드는 수신된 메시지를 처리하기 위한 자신만의 방법이고, 다른 객체들을 위한 협력의 창구다.

---

외부로부터의 변경 가능성을 낮추고자, 클래스의 경계를 구분짓도록 리팩토링 한 경험이 있었는데, 그 과정이 객체 지향 프로그래밍의 일환이었다는 사실이 기쁘다.

 

더불어서, 새로운 객체를 생각할 때 객체 클래스 부터 만들기 보다는,
객체의 역할을 팀원과 정의한 뒤에 세부적인 클래스 설계에 들어가는 협업 / 개발 습관을 들여야겠다.