오브젝트 - 📒 1. 객체, 설계

 

본 게시물은 조영호님의 저서 오브젝트를 학습하면서 정리한 내용입니다.

객체지향 개발자라면 꼭 알아야할 내용들이 가득한 책이기 때문에 참고만하시고 반드시 책을 구매해서 읽어보길 권해드려요!

(네이버 도서 구매링크 클릭)

저작물에 대한 문제가 발생할 경우 비공개 처리하겠습니다.

---

소프트웨어의 3가지 목적 - 마틴

1. 실행 중에 제대로 동작하는가 (제대로 실행되어야 한다.)

2. 변경을 위해 존재하는가 ( 변경에 용이 해야한다.)

3. 특별한 훈련이 없어도 개발자가 쉽게 읽고 이해할 수 있는가 (이해하기 쉬워야 한다.)

 

💡

목적을 잃은 물건은 금방 의미를 상실한다 소프트웨어도 마찬가지인 것 같다. 내가 만드는 소프트웨어는 그 목적을 잘 달성하는가? 3가지 목적이 기준이 된다면 내가 만드는 소프트웨어는 의미를 찾을 수있지 않을까

💡

소프트웨어의 존재 이유를 변경을 위해서 존재한다는게 인상깊다

 

책 속 예제

• before : theater의 의존관계가 과하게 많음

 

예상을 빗나가는 코드 - 이해하기 어려운 코드

• 이해 가능한 코드란 그 동작이 우리의 예상을 크게 벗어나지 않는 코드다.

• 코드의 진행이 상식을 벗어나기 시작하면 코드를 읽는 사람과 의사소통이 어려워 질 수 있다.

• 코드를 이해하기 위해서 한번에 여러가지 세부 사항을 기억해야 한다면 이해하기 어렵다.
  • 하나의 클래스나 메서드에서 너무 많은 세부사항을 다루면, 이해가 어려울 뿐 아니라 변경에도 영향을 미친다.

 

변경에 취약한 코드

• 다른 클래스의 세부적인 내용을 많이 알수록 변경이 어려워진다 → 그렇다고 무작정 의존관계를 없애는 것은 정답이 아니다 "최소한의 의존성만 유지하도록 하는 것"

 

• 의존성은 변경과 관련되어 있음 → 의존성은 변경에 대한 영향을 암시 ”의존성이라는 말 속에는 어떤 객체가 변경될 때 그 객체에게 의존하는 다른 객체도 함께 변경될 수 있다는 사실을 내포하고 있다.”

 

해결방법 : 자율성을 높이자

• 객체 스스로가 자신의 정보를 처리하도록 만드는 것 객체를 자율적인 존재로 만들면된다.

• 자율적인 존재를 만든다는 것은 외부에서 구체적인 정보까지 직접 접근하는 것을 차단하고 정보를 갖고있는데 객체에 의해서 정보가 나갈 수 있게 만드는 것

• 객체가 수동적이면 다른 객체에서 세부적인 정보까지 알고 있어야 하기 때문에 필연적으로 변경에 취약해진다.

• 다른 누군가의 통제를 받는다는 것은 객체사이에 의존성이 생겼다는 말이다.

 

예시

 

 

 

 

 

• 해당 소스에서 다양한 문제가 있지만, 대표적인 문제로 의존성의 문제를 들 수 있다.
  • 대표적인 예로 영화관에 입장하는데 ticketSeller 가 있고, ticketSeller한테 ticketOffice 정보를 받고, ticketOffice가 갖고있는 ticket을 준다는 걸 영화관이 다 알고 있다는 점이 문제이다.
    • 만약 ticketOffice말고 다른 방식을 통해서 ticket을 받게 된다면?→ getTicketOffice()~ 소스는 삭제되어야 한다.
    • 만약 ticketOffice 말고 다른 방식도 가능하게 변경된다면?→ if문으로 분기처리를 해서 getTicketOffice() 외에도 다른 방식도 추가하게 된다.
    
    ⇒ Theater입장에서는 몰라도 되는 구현때문에 본인의 소스가 바뀌어야 하는 상황을 맞이할 수 있음
  • Bag 도 동일한 이유로 문제가 발생한다.

• 캡슐화를 통해 구체적인 구현에 숨기고 결합도를 낮춘다.

• 캡슐화의 목적은 결합도를 낮추고 변경하기 쉬운 코드를 만드는 것

 

💡

객체 내부의 속성을 무작정 getter 로 다 내보내주는 것은 어떤면에선 무책임한 것 일 수도 있다는 생각이 든다. 객체는 각자가 책임을 다해야 한다. 단순히 데이터를 잡아두고 있다가 무책임하게 날 것 그대로를 반환한다면 수동적인 존재로 변경에 걸림돌이 된다.

 

캡슐화와 응집도

• 객체 내부의 상태를 캡슐화 하고 오직 메시지를 통해서만 상호작용하도록 만듦

• 밀접하게 관련있는 작업만 수행하고 연관성이 없는 작업은 다른 객체에게 위임 → 응집도를 높임

• 객체의 자율적이게 만듦

 

절차지향과 객체지향

• 프로세스와 데이터의 위치로 구분

• 절차지향 : 데이터와 프로세스가 별도의 모듈에 위치함 모든 처리가 하나의 클래스 안에 위치 함, 처리를 실행하는 클래스를 제외한 나머지 클래스는 단순히 데이터의 역할만 수행 ( getTicket() 메서드를 쓰면 ticket 객체를 전달해주 듯 단순힌 데이터로의 역할)

• 객체 지향 : 데이터와 프로세스가 동일한 모듈 내부에 위치

 

 

좋은 설계

• 캡슐화를 이용해 의존성을 적절히 관리 → 객체사이의 결합도 낮추고 응집도를 높임

• 자신의 문제를 스스로 처리해야 함

• 객체 내부의 변경이 객체 외부에 파급되지 않도록 제어

 

책임의 이동

• 책임이 집중되어 있다는 건 한 곳에서 집중적으로 제어를 하고 있다는 것

• 객체지향설계에서는 기능을 완성하기 위해서 분산되어 있는 여러 책임이 협력함

• 객체지향설계는 책임이 개별 객체로 이동함→ 객체는 자신을 스스로 책임진다.
• ⇒ 데이터와 프로세스를 하나의 단위로 통합해놓는 방식

• 어떤 데이터를 가지냐 보다 어떤 책임을 할당할 것인지에 집중하는 것 필요

 

이점

• 책임이 이동함에 따라 코드는 더 이해하기 쉬워짐

• 변경에 탄력적인 대응이 가능해짐→ 견고한 설계

 

주의점

• 설계에는 명확한 정답이 있는 것이 아님
  • 설계는 트레이드오프의 산물 ⇒ 어떠한 경우에도 모든 사람을 만족시킬 수 없음
  • 균형을 맞추는 것

 

객체지향설계

• 의존성을 효율적으로 통제 → 변경에 유연하게 대응할 수 있는 코드를 작성
  • 변경에 유연하게 대응할 수 있는 코드
    • 이해하기 쉬움
    • 느슨한 결합