오브젝트: 코드로 이해하는 객체지향 설계 1장을 읽으며

오브젝트: 코드로 이해하는 객체지향 설계 1장을 읽으며

 

느낀점

코드 설계와 수정 과정에서 UML 다이어그램을 함께 제시해 준 부분이 매우 인상적이었음. 코드의 구조를 시각적으로 이해하면서 수정이 필요한 지점을 명확히 파악할 수 있었고, 이를 통해 객체지향 설계의 핵심 원칙들을 보다 깊이 있게 체득할 수 있었음.

특히, 처음 설계한 코드에서 필요한 수정 사항을 어떻게 반영하면 좋은지에 대한 구체적인 예시가 많아 코드 품질을 높이는 방향으로 설계를 개선하는 부분에 도움이 많이 됨

 

도입부지만 확실히 한층 더 성장하는 것 같아서 완전 추천.

 

변경에 취약한 코드

클래스가 다른 클래스의 내부에 대해 더 많이 알수록 의존성이 깊어짐.

• 의존성은 변경에 대한 영향을 암시
• 의존성은 완전히 없애는 것이 정답은 아님. 불필요한 의존성을 제거해 기능을 구현하는데 필요한 최소한의 의존성만 유지할 것.

 

객체 사이의 의존성이 강한 경우를 결합도(coupling)이 높다고 함.

• 반대로 객체들이 합리적인 수준으로 의존할 경우에는 결합도가 낮다고 함.
• 두 객체 사이의 결합도가 높을수록 함께 변경될 확률도 높아지므로 변경하기 어려워 짐.

 

즉, 설계의 목표는 객체 사이의 결합도를 낮춰 변경이 용이한 설계를 만드는 것.

 

자율성을 높이자

개념적이나 물리적으로 객체 내부의 세부적인 사항을 감추는 것을 캡슐화(encapsultation)이라고 부름

• 캡슐화의 목적은 변경하기 쉬운 객체를 만드는 것
• 객체 내부로의 접근 제한을 통한 객체 사이의 결합도를 낮추어 설계를 좀 더 쉽게 변경 가능.

인터페이스(interface)와 구현(implement)로 나누고인터페이스만을 공개

• 이는 객체 사이의 결합도를 낮추고 변경하기 쉬운 코드를 작성하기 위해 따라가는 기본적은 설계 원칙
• 즉, 캡슐화를 통해 다른 객체와 협력

 

캡슐화와 응집도

 

핵심은 객체 내부의 상태를 갭슐화하고 객체 간 오직 메시지를 통해서만 상호작용 하도록 만드는 것.

• 다른 객체를 사용함에 있어서 캡슐화로 인하여 내부 객체의 구현은 모름.
• 단지, 다른 객체가 메시지를 이해하고 원하는 결과를 응답할 수 있다는 사실만 알고 있음.

밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에 위임하는 객체를 가리켜 응집도(cohesion)가 높다고 말함.

• 자율적인 객체를 만들면 결합도를 낮출 수 있으며 응집도를 높일 수 있음.

 

외부의 간섭을 최대한 배제하고 메시지를 통해서만 협력하는 자율적인 객체들의 공동체를 만드는 것이 휼룡한 객체지향 설계의 지름길

 

절차지향과 객체지향

 

절차지향 프로그래밍 이처럼 프로세스와 데이터를 별도 모듈에 위치시키는 방식

• Theater의 enter 안에서 Audience와 TicketSeller로 부터 Bag과 TicketOffice는 관람객을 입장시키는 절차를 구현
• 이 관점에서 Theater의 enter 메소드는 Process(프로세스)이며, Audience, TicketSeller, Bag, TicketOffice는 데이터(Data)임.

객체지향 프로그래밍은 데이터와 프로세스가 동일한 모듈 내부에 위치하도록 프로그래밍 하는 방식

• 이는 객체 사이의 결합도를 낮추고 변경하기 쉬운 코드를 작성하기 위해 따라가는 기본적은 설계 원칙
• 적절한 객체 내부의 변경이 객체 외부에 파급되지 않도록 제어할 수 있기 때문에 변경하기가 수월

 

절차지향과 객체지향

 

절차지향 프로그래밍 이처럼 프로세스와 데이터를 별도 모듈에 위치시키는 방식

• Theater의 enter 안에서 Audience와 TicketSeller로 부터 Bag과 TicketOffice는 관람객을 입장시키는 절차를 구현
• 이 관점에서 Theater의 enter 메소드는 Process(프로세스)이며, Audience, TicketSeller, Bag, TicketOffice는 데이터(Data)임.

객체지향 프로그래밍은 데이터와 프로세스가 동일한 모듈 내부에 위치하도록 프로그래밍 하는 방식

• 이는 객체 사이의 결합도를 낮추고 변경하기 쉬운 코드를 작성하기 위해 따라가는 기본적은 설계 원칙
• 적절한 객체 내부의 변경이 객체 외부에 파급되지 않도록 제어할 수 있기 때문에 변경하기가 수월

 

책임의 이동

 

절차지향과 객체지향의 근본적인 차이를 만드는 것은 책임의 이동(shift of reponsibility)임

• 객체지향에서는 독재자가 존재하지 않고, 각 객체에 책임이 적절하게 자신을 스스로 책임진다.

설계를 어렵게 하는 것은 의존성이라는 것

• 이를 해결하는 방법은 결합도를 낮추기
• 세부사항을 내부로 감춰 캡슐화
• 캡술화 하는 것은 객체의 자율성을 높이고 응집도 높은 객체들의공동체를 만들도록 도움

 

불필요한 세부사항을 캡슐화하고 자율적인 객체들이 낮은 결합도와 높은 응집도를 가지고 협력하도록 최소한의 의존성만을 남기는 것이 휼룡한 객체지향 설계

 

 

객체지향 설계

 

변경에 유연하게 대응할 수 있는 코드

• 데이터와 프로세스를 하나의 덩어리로 모으는 것은 휼룡한 객체지향 설계로 가는 첫걸음.
• 객체들 사이에 의존성을 적절하게 조절함으로써 변경에 용이한 설계를 만드는 것