전체 글149 6. 메시지와 인터페이스 - 2 코드스피츠 4강 내용 ❗핵심내용: OCP와 제네릭을 통한 해결 if + instanceof 코드를 클라이언트 방향으로 밀어내야함. 클라이언트를 여러개 만들고 매핑해야함 클라이언트층은 서비스를 다룸 객체설계를 시키는 식으로 만들면 되는데 물어보는 식으로 만들기 때문에 안되는거임 →제일 좋은 것은 시키는것. 그래야 영향을 안받음. LSP(리스코프 치환 원칙): 자식형을 부모형으로 완전히 대체할 수 있다. 문제점 원인: 성급한 추상화 기존보다 메서드 개수가 줄어든다면 괜찮다. 기존보다 메서드가 늘어날 경우 문제가 생김 다운캐스팅을 사용하면 안됨 다운캐스팅: OCP 위반을 일으킴 →제너릭을 통해 해결하자 설계 상에서 LSP, OCP를 지키려고 하자 → if + instanceof 를 쓰지 말자. 문제: 추상형에.. 2022. 10. 14. 6. 메시지와 인터페이스 - 1 목차 협력과 메시지 클라이언트-서버 모델 메시지와 메시지 전송 메시지와 메서드 퍼블릭 인터페이스와 오퍼레이션 시그니처 인터페이스와 설계 품질 묻지 말고 시켜라 의도를 드러내는 인터페이스 함께 모으기 원칙의 함정 디미터 법칙은 하나의 도트(.)를 강제하는 규칙이 아니다 결합도와 응집도의 충돌 명령-쿼리 분리 원칙 반복 일정의 명령과 쿼리 분리하기 명령-쿼리 분리와 참조 투명성 책임에 초점을 맞춰라 2022. 10. 14. 5. 책임 할당하기 - 5 🐿️ 4장 초반에 개발한 데이터 중심 설계를 리팩토링하는 과정을 통해 리팩토링으로 책임을 할당하는 방법의 장점을 설명 🗣️ 책임 주도 설계의 대안 1. 메서드 응집도 중요한 것은 메서드의 이름과 메서드 몸체의 의미적 차이 객체로 책임을 분배할 때 가장 먼저 할 일: 메서드를 응집도 있는 수준으로 분해하는 것 → 긴 메서드를 작고 응집도 높은 메서드로 분리하면 각 메서드를 적절한 클래스로 이동하기가 더 수월해짐 작고, 명확하며, 한 가지 일에 집중하는 응집도 높은 메서드는 변경 가능한 설계를 이끌어 내는 기반이 된다. 이런 메서드들이 하나의 변경 이유를 가지도록 개선될 때 결과적으로 응집도 높은 클래스가 만들어진다. 2. 객체를 자율적으로 만들자 어떤 메서드를 어떤 클래스로 이동시켜야 하는가 : 메서드가 .. 2022. 10. 14. 5. 책임 할당하기 - 4 🐿️ 올바른 설계가 됐는지 코드를 통해 검증 🗣️ 구현을 통한 검증 movie의 구현을 고려하지 않고 필요한 메시지를 결정 → movie의 내부 구현을 깔끔하게 캡슐화함 public class Screeening { private Movie movie; private int sequence; private LocalDateTime whenScreened; public Reservation reserve(Custoemr customer, int audienceCount) { return new Reservation(customer, this, calculateFee(audienceCount), audienceCount); } public Money calculateFee(int audienceCount) .. 2022. 10. 14. 5. 책임 할당하기 - 3 🐿️ 3장에서 책임 주도 설계 방법에 대해 좀더 자세히 살펴봄 🗣️ 책임 할당을 위한 GRASP 패턴 1. 도메인 개념에서 출발하기 설계 시작 전에 도메인에 대한 개략적인 모습을 그려보는 것이 좋음 어떤 책임을 할당해야 할때 가장 먼저 고민해야 하는 유력한 후보는 도메인 개념 책임을 할당받을 객체들의 종류와 관계에 대한 유용한 정보를 제공할 수 있다면 충분 설계를 시작하는 것일뿐 도메인 개념들을 완벽하게 정리하는 것은 아님 빠르게 설계와 구현을 진행 도메인 모델: 실용적이면서 유용한 모델이 되게 하기 2. 정보 전문가에게 책임을 할당하라 책임 주도 설계 방식의 첫번째: 애플리케이션이 제공해야 하는 기능을 애플리케이션의 책임으로 생각하기 영화 예매 기능 질문1: 메시지를 전송할 객체는 무엇을 원하는가? →.. 2022. 10. 14. 5. 책임 할당하기 - 2 🙂 5장 내용: 🐿️ 2장에서 소개한 코드의 설계 과정을 한 걸음씩 따라가 보면서 객체에 책임을 할당하는 기본적인 원리를 살펴보기 🗣️ 책임 주도 설계를 향해 1. 데이터보다 행동을 먼저 결정하라 객체에게 중요한 것은 데이터가 아니라 외부에 제공하는 행동이다. 책임 중심의 설계에서는 객체의 행동, 즉 책임을 먼저 결정한 후에 객체의 상태를 결정한다. 객체지향 설계에서 가장 중요한 것은 적절한 객체에게 적절한 책임을 할당하는 능력이다. 객체에게 어떤 책임을 할당해야하는가는 협력에서 찾을 수 있다 2. 협력이라는 문맥 안에서 책임을 결정하라 객체에게 적절한 책임을 할당하기 위해서는 협력을 고려 협력을 고려함에 있어 적절한 책임은 클라이언트 관점에서 적절한 책임 올바른 객체지향 설계는 메시지(클라이언트가 전송.. 2022. 10. 14. 5. 책임 할당하기 - 1 목차 책임 주도 설계를 향해 데이터보다 행동을 먼저 결정하라 협력이라는 문맥 안에서 책임을 결정하라 책임 주도 설계 책임 할당을 위한 GRASP 패턴 도메인 개념에서 출발하기 정보 전문가에게 책임을 할당하라 높은 응집도와 낮은 결합도 창조자에게 객체 생성 책임을 할당하라 구현을 통한 검증 DiscountCondition 개선하기 타입 분리하기 다형성을 통해 분리하기 변경으로부터 보호하기 Movie 클래스 개선하기 변경과 유연성 책임 주도 설계의 대안 메서드 응집도 객체를 자율적으로 만들자 책임에 초점을 맞춰서 설계할 떄 직면하는 가장 큰 어려움은 어떤 객체에게 어떤 책임을 할당할지를 결정하기가 쉽지 않다는 것이다. 따라서 올바른 책임을 할당하기 위해서는 다양한 관점에서 설계를 평가할 수 있어야 한다. 🍀.. 2022. 10. 14. 4. 설계 품질과 트레이드오프 목차 데이터 중심의 영화 예매 시스템 데이터를 준비하자 영화를 준비하자 설계 트레이드오프 캡슐화 응집도와 결합도 데이터 중심의 영화 예매 시스템의 문제점 캡슐화 위반 높은 결합도 낮은 응집도 캡슐화를 지켜라 자율적인 객체를 향해 스스로 자신의 데이터를 책임지는 객체 캡슐화 위반 하지만 여전히 부족하다 높은 결합도 낮은 응집도 데이터 중심 설계는 객체의 행동보다는 상태에 초점을 맞춘다 데이터 중심 설계의 문제점 데이터 중심 설계는객체를 고립시킨 채 오퍼레이션을 정의하도록 만든다 🍀목표 데이터 중심 설계를 통해 책임 주도 설계가 얼마나 중요한지를 알기 객체지향 설계의 핵심은 역할, 책임, 협력이다. 역할: 대체 가능한 책임의 집합이다. 책임: 객체가 다른 객체와 협력하기 위해 수행하는 행동이다. 협력: 애플.. 2022. 10. 14. 이전 1 ··· 13 14 15 16 17 18 19 다음