요즘 가장 관심 있는 분야는 객체지향 설계다.
최근에 했던 프로젝트를 리팩토링 하면서 디자인 패턴을 적용하여 문제도 해결하고 있다.
리팩토링을 하는 것도 좋지만, 만약에 프로젝트 초기로 돌아간다면 좋은 객체지향 설계를 하는 것에 집중할 것 같다.
이번 기회에 어쩌면 잘못 이해하고 있었을 수 있었던 객체지향 설계에 대해 제대로 알고 싶었다.
이 책은 ' 객체지향의 사실과 오해'의 저자로 유명하신 조영호님이 쓰셨다.
예전에 '객체지향의 사실과 오해'는 조금 읽다가 이해하기 어려워서 다 읽지 못했었다. 🥹
'오브젝트'는 목차랑 내용을 살펴보니 예제도 많고 이해하기 쉬울 것 같아서 구입했다.
'오브젝트'를 다 읽으면 '객체지향의 사실과 오해'도 읽을 예정이다. 😁
알게 된 내용은 프로젝트에도 적용해야지!!!
2장. 이상한 나라의 객체
🌈 TIL
- 메시지와 메서드라는 용어를 구분할 줄 아는 게 중요하다. 메시지는 객체가 다른 객체와 상호작용을 하는 방법이다. 예를 들어, A클래스의 메서드 내부에서 B클래스의 메서드를 호출하는 것과 같은 상황을 A클래스가 B클래스에게 메시지를 전송한다고 한다. B클래스는 A클래스로부터 메시지를 받은 후 메서드를 실행 후 응답한다.
- 동일한 메시지를 전송하더라도 실제로 어떤 메시지가 실행되는지는 메시지를 수신하는 객체의 클래스에 달려있다. 이것을 다형성이라고 한다.
- 상속을 사용하는 이유가 메서드나 인스턴스의 변수를 재사용할 수 있는 장점이 있어서라고 생각했었다. 하지만, 부모 클래스가 제공하는 모든 인터페이스를 자식 클래스가 물려받을 수 있다는 게 주된 이유라는 것을 알았다.
- 추상 클래스와 인터페이스 중에서 어떤 것을 고를지 고민이 될때가 있다. 구현을 공유할 필요가 없을 때 인터페이스를 사용하고, 인스턴스를 생성할 필요가 없을 때 추상 클래스를 사용해야겠다.
- 코드 재사용을 위해서는 상속보다는 합성(Composition)을 사용하는 것이 더 좋고, 실제로는 상속과 합성을 같이 사용하는 경우가 많다. 합성은 다른 객체의 인스턴스를 자신의 인스턴스 변수에 포함해서 사용하는 방법이다. 합성을 상속보다 더 선호하는 이유는 메시지를 통해서 느슨하게 결합되기 때문에 코드 재사용성이 상속보다 더 좋다. 상속은 컴파일 시점에 부모 클래스의 코드와 자식 클래스의 코드를 강하게 결합시킨다.
3장. 역할, 책임, 협력
🌈 TIL
- 객체지향 패러다임의 관점에서 역할, 책임, 협력은 핵심이다.
- 협력은 객체들이 수행하는 상호작용
- 책임은 협력에 참여하기 위해 수행하는 로직
- 책임이 모여서 역할이 된다. 여러 종류의 객체들이 참여할 수 있는 게 역할이다.
- 책임 주도 설계(Responsibility-Driven Design)은 책임을 수행할 적절한 객체를 찾아 책임을 할당하는 설계
- 메시지가 객체를 결정한다. 어떤 메시지를 전달할지를 생각하는 게 우선이다. 객체지향 설계에 대해서 잘 모르면 대부분이 클래스에 어떤 속성, 기능을 담을까부터 생각한다.
- 데이터-주도 설계(Data-Driven Design)은 객체에 필요한 상태가 무엇인지 결정하고, 그 후에 상태에 필요한 행동을 결정한다. 객체 내부의 구현에 초점을 맞춘 설계 방법이라서 객체지향 설계와 거리가 멀다.
반응형
'JAVA' 카테고리의 다른 글
Factory Pattern을 적용한 리팩토링 (0) | 2024.09.03 |
---|---|
설계 품질과 트레이드오프 | 책임 할당하기 | 메시지와 인터페이스 (0) | 2024.08.25 |
Facade Pattern (0) | 2024.07.03 |
HttpURLConnection | RestTemplate | WebClient (0) | 2023.12.28 |
enums(열거형) (0) | 2023.05.22 |