닭발개발

16일차. 클린코드[3주차_ 목요일] 142-150pg #요약 7. 오류처리 1) 오류 코드보다 예외를 사용하라 2) Try-Catch-Finally 문부터 작성하라 3) 미확인(unchecked) 예외를 사용하라 4) 예외에 의미를 제공하라 5) 호출자를 고려해 예외 클래스를 정의하라 6) 정상 흐름을 정의하라 7) null을 반환하지 마라 8) null을 전달하지 마라 9) 결론 - 깨끗한 코드는 읽기도 좋아야 하고, 안정성도 높아야 한다. - 오류 처리를 프로그램 논리와 분리하면 독립적인 추론이 가능해지고 코드 유지보수성도 높아진다. 8. 경계 - 외부 코드를 우리 코드에 깔끔하게 통합하는 법 - 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교 1) 외부 코드 사용하기 - 인터페이스 제공자는 적용성..

4일차. 클린코드[1주차_목요일] 24-34pg #요약 1. 깨끗한 코드 2. 의미 있는 이름 소프트웨어에서 이름은 어디에나 쓰이기 때문에 이름을 잘 지으면 여러모로 편하다. 1) 의도를 분명히 밝혀라 2) 그릇된 정보를 피하라 - 진짜 list가 아니면 list도 쓰지 마라 - 서로 흡사한 이름을 쓰지 마라 - 유사한 개념은 유사한 표기법을 사용한다. 일관성이 떨어지는 표기법도 그릇된 정보다. 3) 의미있게 구분하라 - 잘못된 예시 : moneyAmount와 money, customerInfo와 customer, accountData와 account - 읽는 사람이 차이를 알도록 지어라 4) 발음하기 쉬운 이름을 사용하라 5) 검색하기 쉬운 이름을 사용하라 - 7, e는 검색이 어렵다. - 이름의 길이..

3일차. 클린코드[1주차_수요일] 13-23pg #요약 1. 깨끗한 코드 {깨끗한 코드란?} - 론 제프리스 : 중복이 없고 표현력 높이고, 초반부터 간단한 추상화를 고려한 코드 - 워드 커닝햄 : 코드를 읽으며 짐작했던 기능을 제대로 수행한 코드 {우리들 생각} 이 책은 우리의 오브젝트 멘토 진영이 생각하는 깨끗한 코드를 설명한다. {우리는 저자다.} Javadoc에서 @author 필드가 저자를 소개하듯이 우리는 저자다. - 코드를 짤 때, 자신이 저자고, 이것을 볼 독자가 있다는 사실을 기억해야 한다. - 새 코드를 짜면서 기존 코드를 끊임없이 읽기 때문에 읽기 쉬운 코드가 중요하다. 보이스카우트 규칙에서는 캠핑장에 체크인 할 때보다 체크아웃 할 때 더 깨끗하게 하라고 한다. 코드도 마찬가지이다. ..

45일차. 오브젝트: 코드로 이해하는 객체지향 설계[8주차_수요일] 558-573pg #요약 **APPENDIX. 계약에 의한 설계** 01. 협력과 계약 02. 계약에 의한 설계 03. 계약에 의한 설계와 서브타이핑 1) 계약 규칙 2) 가변성 규칙 - 부모 클래스보다 못한 자식 클래스는 서브타입이 아니다. - 서브타이핑과 공변성, 반공변성 사이의 관계 - S가 T의 서브타입일 때 공변성, 반공변성, 무공변성 . 공변성 : S와 T사이 서브타입 관계가 그대로 유지됨 . 반공변성 : S와 T사이 서브타입 관계가 역전됨 . 무공변성 : S와 T사이에는 아무런 관계도 없음 - 공변성과 반공변성의 영역으로 들어서려면 타입의 관계가 아니라 메서드의 리턴 타입과 파라미터 타입에 초점을 맞춰야 한다. - 리턴 타입..

44일차. 오브젝트: 코드로 이해하는 객체지향 설계[8주차_화요일] 547-557pg #요약 **APPENDIX. 계약에 의한 설계** 01. 협력과 계약 02. 계약에 의한 설계 03. 계약에 의한 설계와 서브타이핑 - 서브타입이 리스코프 치환 원칙을 만족시키기 위해서는 클라이언트와 슈퍼타입 간에 체결된 계약을 준수해야 한다. - 리스코프 치환원칙의 규칙 a. 계약 규칙 : 슈퍼타입과 서브타입 사이의 사전조건, 사후조건, 불변식에대해 서술할 수 있는 제약에 관한 규칙 b. 가변성 규칙 : 파라미터와 리턴 타입의 변형과 관련된 규칙 1) 계약 규칙 - 사전조건 완화는 리스코프 치환 원칙을 위반하지 않는다. - 사후조건 완화는 리스코프 치환 원칙 위반이다.

43일차. 오브젝트: 코드로 이해하는 객체지향 설계[8주차_월요일] 538-546pg #요약 **APPENDIX. 계약에 의한 설계** 01. 협력과 계약 1) 부수효과를 명시적으로 2) 계약 - 계약은 협력을 명확하게 정의하고 커뮤니케이션할 수 있는 범용적인 아이디어. 02. 계약에 의한 설계 - 버트란드 마이어가 제시한 계약의 개념 . 협력에 참여하는 각 객체는 계약으로부터 이익을 기대하고 이익을 얻기 위해 의무를 이행한다. . 협력에 참여하는 각 객체의 이익과 의무는 객체의 인터페이스 상에 문서화된다. - 계약에 의한 설계를 이용하면 오퍼레이션의 시그니처를 구성하는 다양한 요소들을 이용해 협력에 참여하는 객체들이 지켜야 하는 제약 조건을 명시할 수 있다. - 의도를 드러내는 인터페이스를 만들면 오퍼..

37일차. 오브젝트: 코드로 이해하는 객체지향 설계[7주차_월요일] 471-482pg #요약 **Chapter 14. 일관성 있는 협력** 01. 핸드폰 과금 시스템 변경하기 1) 기본 정책 확장 2) 고정요금 방식 구현하기 3) 시간대별 방식 구현하기 - 책임을 할당하는 기본 원칙은 책임을 수행하는 데 필요한 정보를가장 잘 알고있는 정보 전문가에게 할당하는 것.

31일차. 오브젝트: 코드로 이해하는 객체지향 설계[6주차_월요일] 403-415pg #요약 **Chapter 12. 다형성** 01. 다형성(Polymorphism) 02. 상속의 양면성 03. 업캐스팅과 동적 바인딩 1) 같은 메시지, 다른 메서드 - 업캐스팅 : 부모 클래스 타입으로 선언된 변수에 자식 클래스의 인스턴스를 할당하는 것이 가능한 것. 부모클래스에 대해 작성된 코드를 전혀 수정하지 않고도 자식 클래스에 적용할 수 있음. - 동적 바인딩 : 객체지향 시스템이 메시지를 처리할 적절한 메서드를 컴파일 시점이 아니라 실행시점에 결정하기 때문에 선언된 변수의 타입이 아니라 메시지를 수신하는 객체의타입에 따라 샐행되는 메서드가 결정되는 것. - 업캐스팅과 동적 바인딩은 상속을 이용해 개방-폐쇄 원..

35일차 헤드퍼스트 디자인패턴 [6주차_금요일] 464-474pg 요약 **CHAPTER 11. 객체 접근 제어하기 (feat. 프록시 패턴)** 사람들이 좋은 경찰에 접근하는 일을 나쁜 경찰이 제어한다. 패턴에서 나쁜 경찰은 프록시(proxy)이다. 접근을 제어하고 관리한다. [ 원격 프록시의 역할 ] - 원격 객체의 로컬 대변자 역할 - 원격 객체 : 다른 자바 가상 머신의 힙에서 살고 있는 객체(다른 주소 공간에서 돌아가고 있는 객체) - 로컬 대변자 : 로컬 대변자의 어떤 메소드를 호출하면, 다른 원격 객체에게 그 메소드 호출을 전달해주는 객체 - 클라이언트 객체는 프록시를 활용하는 객체다 : 클라이언트 객체는 원격 객체의 메소드 호출을 하는 것처럼 행동한다. 하지만 실제로는 로컬 힙에 들어있는 ..

34일차 헤드퍼스트 디자인패턴 [6주차_목요일] 453-463pg 요약 **CHAPTER 10. 객체의 상태 바꾸기 (feat. 상태패턴)** 전략패턴과 상태패턴은 꽤나 다르지만 밑 바탕의 설계는 거의 같다. 어릴적 헤어진 쌍둥이처럼 [ 객체지향 패턴 추가 + ] - 상태패턴 : 내부 상태가 바뀜에 따라 객체의 행동이 바뀔 수 있도록 해준다. 마치 객체의 클래스가 바뀌는 것 같은 결과를 얻을 수 있다. **CHAPTER 11. 객체 접근 제어하기 (feat. 프록시 패턴)** 사람들이 좋은 경찰에 접근하는 일을 나쁜 경찰이 제어한다. 패턴에서 나쁜 경찰은 프록시(proxy)이다. 접근을 제어하고 관리한다. [ 뽑기 기계 재고와 현재 상태 파악하는 기능 추가 ] - 원격으로 파악하고 싶다는 CEO -> 원..