[Facts]
1. 왜 FACTORY를 사용하는지
2. 순수한 가공물 (PURE FACBRICATION)
3. 역할, 책임, 협력
4. 상속과 조합[Feelings+Finding]
1. FACTORY
생성할 책임을 가지는 곳은 생성 방식을 알아야 하고, new를 통해 특정 구현체에 의존성이 생기게 된다.
그래서 생성과 사용을 분리해야 한다. 사용할 때 생성하는 것이 아니라, 객체를 생성할 책임을 클라이언트로 옮겨야 좋다.
그런데, 클라이언트에게도 생성할 책임을 주고 싶지 않을 때 FACTORY를 쓰는 것이다.
2. 순수한 가공물
어떤 행동을 추가하려고 하는데 이 행동을 책임질 만한 마땅한 도메인 개념이 없을 때는 PURE FACBRICATION을 추가
예를 들어, 애플리케이션에서 DB 접근을 위한 객체 같은 개념이 이에 해당한다.
도메인의 본질적인 개념을 표현하는 추상화를 이용해 애플리케이션을 구축하다가 마땅한 도메인 개념이 없다면 망설임 없이 인공적인 객체를 추가해도 된다.
이런 책임을 도메인에 추가하게 되면 낮은 응집도, 재사용성 저하 같은 문제가 생길 수 있다.
객체 지향은 세상을 모방하는 것이라고 생각했는데, 꼭 그래야 하는 것은 아니구나, 요런 거도 있구나라는 느낌으로 적어봤습니다
3. 역할, 책임, 협력
객체 지향 설계의 핵심은 협력을 구성하기 위해 적절한 객체를 찾고, 적절한 책임을 할당하는 과정
협력: 애플리케이션의 기능을 구현하기 위해 수행하는 상호작용
책임: 객체가 협력에 참여하기 위해 수행하는 로직
역할: 객체들이 협력 안에서 수행하는 책임들이 모여 객체가 수행하는 것
책임은 그 일을 처리하는데 가장 많은 정보를 아는 객체에게 할당하는 게 좋다. (객체의 상태와 행동을 참고해서)
역할은 배역 느낌. 객체는 배우! 배우는 여러 배역을 맡을 수 있듯이, 객체는 여러 역할을 맡을 수 있다.
4. 상속과 합성
상속은 부모 클래스와 자식 클래스의 결합도를 강하게 만들어, 부모 클래스의 수정이 자식 클래스에게 너무 큰 영향을 미친다.
부모 클래스를 수정하면 자식 클래스 모두를 살펴보고 적용해주어야 한다,,
중복을 줄이려고 상속을 사용하려다 오히려 더 중복을 만들거나, 캡슐화를 위반하게 된다.
합성을 통해 퍼블릭 인터페이스만 사용할 수 있게 되어, 불필요한 오퍼레이션들로 인해 오염되지 않을 수 있다. 포함되는 객체의 내부 구현을 알 필요가 없다. 상속보다 더 유연하게 할 수 있다.
상속과 조합을 벗어나서도 웬만하면 유연하게 하는 편이 좋은 방법이다.
'우테코' 카테고리의 다른 글
우테코에서의 6주차 WIL (0) | 2025.03.25 |
---|---|
우테코에서의 5주차 WIL (0) | 2025.03.17 |
우테코에서의 3주차 WIL (0) | 2025.03.06 |
우테코에서의 2주차 WIL (1) | 2025.02.23 |