#응집도
5
FundamentalOOP
오브젝트; 디미터 법칙
퍼블릭 인터페이스의 품질에 영향을 미치는 원칙과 기법 디미터 법칙 묻지 말고 시켜라 의도를 드러내는 인터페이스 명령-쿼리 분리 디미터 법칙 낯선 자에게 말하지 마라. 오직 인접한 이웃하고만 말하라. 오직 하나의 도트만 사용하라. 클래스 내부의 메서드가 아래 조건을 만족하는 인스턴스에만 메시지를 전송하도록 프로그래밍해야 한다. this 객체 메서드의 매개변수 this의 속성 this의 속성인 컬렉션의 요소 메서드 내에서 생성된 지역 객체 부끄럼타는 코드 Shy code : 불필요한 어떤 것도 다른 객체에게 보여주지 않으며, 다른 객체
FundamentalOOP
오브젝트; 변경과 유연성과 리팩토링
메시지를 처리할 책임과 책임을 수행하는데 필요한 변수 지정을 먼저 한다. 다른 객체의 구현을 고려할 필요 없이 필요한 메시지를 결정하면 다른 객체의 내부 구현을 깔끔하게 캡슐화 할 수 있다. 메시지가 변경되지 않는 한 객체에 어떤 수정을 가하더라도 호출하는 쪽에는 영향을 미치지 않는다. 메시지를 기반으로 협력을 구성하면 객체 사이 결합도를 느슨하게 유지할 수 있다. 책임 주도 설계 calculateFee()를 위한 객체 설계를 한다. 상세 구현을 한다. 4장과 다른점은 switch 문 내에 또 다른 분기가 없다는 점 정도.. 첫번째
FundamentalOOP
오브젝트; GRASP와 책임 할당하기
데이터를 먼저 결정하고 고립된 객체의 상태에 초점을 맞추면 캡슐화를 위반하기 쉽고, 요소들 사이의 결합도가 높아지며, 코드를 변경하기 어려워진다. 책임에 초점을 맞춰서 설계할 때 어떤 객체에게 어떤 책임을 할당할지를 결정 하는 것이 어렵다. 책임 할당 과정은 트레이드오프 활동이다. 데이터 중심의 설계에서 책임 중심의 설계로 전환하는 방법 클라이언트 관점에서 객체가 수행하는 행동이란 곧 객체의 책임을 의미한다. 객체는 협력에 참여하기 위해 존재하며 협렵 안에서 수행하는 책임이 객체의 존재가치를 증명한다. 너무 이른시기에 데이터에 초점
FundamentalOOP
오브젝트; 데이터 중심 설계의 문제
객체지향 설계의 핵심 협력 : 애플리케이션의 기능을 구현하기 위해 메시지를 주고받는 객체들 사이의 상호작용 책임 : 객체가 다른 객체와 협력하기 위해 수행하는 행동 역할 : 대체 가능한 책임의 집합 객체지향 설계 객체에 올바른 책임을 할당하면서 낮은 결합도와 높은 응집도를 가진 구조를 창조하는 활동 객체지향의 설계의 핵심은 책임이다. 책임을 할당하는 작업이 응집도와 결합도 같은 설계 품질과 깊이 연관되어 있다. 설계 설계는 변경을 위해 존재한다. 훌륭한 설계한 합리적인 비용안에서 변경을 수용할 수 있는 구조를 만드는 것이다. 변경
FundamentalOOP
오브젝트; 객체, 설계
이론보다 실무가 먼저다. 설계에 관한 이론은 1970년이 되서야 등장했다. 설계에 대한 이론은 있으나 유지보수에 대한 이론은 없다. 객체지향 프로그램을 설계하고 유지보수하는 데 필요하는 원칙과 기법을 설명하는것이 목적이다. 코드 보기 소프트웨어 모듈의 목적 실행 중에 제대로 동작하는 것이다. 변경을 위해 존재한다. 대부분의 모듈은 생명주기 동안 변경되기 때문에 간단한 작업 만으로도 변경이 가능해야 한다. 코드를 읽는 사람과 의사소통 하는것. 현실의 프로세스와 벗어난 비즈니스 로직은 코드를 읽는 사람과 제대로된 소통이 되지 않는다.