닭발개발

19일차. 클린코드[4주차_ 월요일] 170-179pg #요약 10. 클래스 - 깨끗한 클래스 만들기 1) 클래스 체계 - 클래스를 정의하는 표준 자바 관례에 따르면, 추상화 단계가 순차적으로 내려간다. 가. 캡슐화 : 변수와 유틸리티 함수는 반드시 숨겨야 한다. 캡슐화를 푸는 것은 언제나 최후의 수단 2) 클래스는 작아야 한다! - 클래스의 첫째는 크기, 둘째도 크기. 작아야 한다. - 얼마나? 클래스가 맡은 책임을 기준으로. 한 클래스에 책임이 너무 많으면 안됨 - 클래스 설명은 25단어 내외로 해야함. 가. 단일 책임 원칙(SRP, Single Responsibility Principle) : 클래스나 모듈을 변경할 이유가 단 하나뿐이어야 한다. 큰 클래스 몇개가 아니라 작은 클래스 여럿으로 이뤄진..

12일차. 오브젝트: 코드로 이해하는 객체지향 설계[2주차_토요일] 142-155pg #요약 **Chapter 05. 책임 할당하기** - 책임에 초점을 맞춰서 설계할 때는 어떤 객체에 어떤 책임을 할당할지 결정하기가 쉽지 않다. - 책임 할당 과정은 일종의 트레이드오프 활동 - GRASP 패턴은 책임 할당의 어려움을 해결하기 위한 답을 제시해줄 것. 01. 책임 주도 설계를 향해 1) 데이터보다 행동을 먼저 결정하라. 2) 협력이라는 문맥 안에서 책임을 결정하라 3) 책임 주도 설계 02. 책임 할당을 위한 GRASP 패턴 1) 도메인 개념에서 출발하기 2) 정보 전문가에게 책임을 할당하라. - 수행할 정보를 알고 있는 객체에게 책임을 할당하는 것 : Information Expert(정보 전문가) 패..

10일차. 오브젝트: 코드로 이해하는 객체지향 설계[2주차_목요일] 119-130pg #요약 **Chapter 04. 실제 품질과 트레이드오프** 04. 자율적인 객체를 향해 2) 스스로 자신의 데이터를 책임지는 객체 - 상태와 행동을 객체라는 하나의 단위로 묶는 이유는 객체 스스로 자신의 상태를 처리할 수 있게 하기 위해서다. - 이 객체가 어떤 데이터를 포함해야 하는지, 데이터에 대해 수행해야 하는 오퍼레이션은 무엇인지 - 데이터를 처리하는 데 필요한 메서드를 데이터를 가지고 있는 객체 스스로 구현하고 있다. 05. 하지만 여전히 부족하다. 1) 캡슐화 위반 - 내부의 구현의 변경이 외부로 퍼져나가는 파급효과(ripple effect)는 캡슐화가 부족하다는 명백한 증거다. - 캡슐화의 진정한 의미 :..

9일차. 오브젝트: 코드로 이해하는 객체지향 설계[2주차_수요일] 108-118pg #요약 **Chapter 04. 실제 품질과 트레이드오프** 2) 영화를 예매하자 02. 설계 트레이드오프 1) 캡슐화 - 한 곳에서 일어난 변경이 전체 시스템에 영향을 끼치지 않도록 파급효과를 적절하게 조절할 수 있는 장치 제공 - 변경될 가능성이 높은 부분은 구현, 상대적으로 안정적인 부분은 인터페이스 2) 응집도와 결합도 - 응집도 : 모듈에 포함된 내부 요소들이 연관돼 있는 정도를 나타냄 - 모듈 내의 요소들이 하나의 목적을 위해 긴밀하게 협력한다면 그 모듈은 높은 응집도를 가진다. - 변경의 관점에서 응집도란 변경이 발생할 때 모듈 내부에서 발생하는 변경의 정도로 측정할 수 있다. - 응집도가 높을수록 변경의 대..

3일차. 오브젝트: 코드로 이해하는 객체지향 설계[1주차_수요일] 17~33pg #요약 **Chapter 01. 객체, 설계** - 결합도(coupling)가 높음 : 객체 사이의 의존성이 과한 경우 - 변경과 의사소통의 문제는 서로 엮어 있음 : 의도를 정확하게 의사소통하지 못하기 때문에 코드가 이해하기 어려워진 것. => 해결 : 극장이 관객과 매표소에 관해 너무 세세한 부분까지 알지 못하도록 정보를 차단하면 된다. 즉, 관객과 매표소를 자율적인 존재로 만들면 된다. [ 자율성을 높이자 ] - TicketSeller에서 getTicketOffice 메소드가 제거 됨. -> 결과적으로 ticketOffice에 대한 접근은 오직 TicketSeller안에만 존재하게 된다. -> 캡슐화(encapsulat..