닭발개발

42일차. 오브젝트: 코드로 이해하는 객체지향 설계[7주차_토요일] 528-537pg #요약 **Chapter 15. 디자인 패턴과 프레임 워크** 01. 디자인 패턴과 설계 재사용 02. 프레임워크와 코드 재사용 1) 코드 재사용 vs 설계 재사용 2) 상위 정책과 하위 정책으로 패키지 분리하기 3) 제어 역전 원리 - 상위 정책을 재사용하는 것은 도메인에 있는 핵심 개념들 사이의 협력관계를 재사용한다는 의미 - 객체지향 설계의 재사용성은 개별 클래스가 아니라 객체들 사이의 공통적인 협력 흐름으로부터 나온다. - 의존성 역전 원리는 전통적 설계방법과 객체지향을 구분하는 핵심원리 - 시스템이 진화하는 방향에는 항상 의존성 역전 원리를 따르는 설계가 존재해야 한다. - 의존성 역전 원리는 프레임워크의 가장..

40일차. 오브젝트: 코드로 이해하는 객체지향 설계[7주차_목요일] 505-518pg #요약 **Chapter 14. 일관성 있는 협력** 01. 핸드폰 과금 시스템 변경하기 02. 설계에 일관성 부여하기. 03. 일관성 있는 기본 정책 구현하기 1) 변경 분리하기 2) 변경 캡슐화하기 3) 협력 패턴 설계하기 4) 추상화 수준에서 협력 패턴 구현하기 5) 구체적인 협력 구현하기 - 일관성 있는 협력은 개발자에게 확장 포인트를 강제하기 때문에 정해진 구조를 우회하기 어렵게 만든다. - 유사한 기능에 대해 유사한 협력 패턴을 적용하는 것은 객체지향 시스템에서 개념적 무결성을 유지할 수 있는 가장 효과적 방법이다. - 시스템이 일관성 있는 몇 개의 협력 패턴으로 구성된다면 시스템을 이해, 수정, 확장하는 데..

39일차. 오브젝트: 코드로 이해하는 객체지향 설계[7주차_수요일] 494-504pg #요약 **Chapter 14. 일관성 있는 협력** 01. 핸드폰 과금 시스템 변경하기 02. 설계에 일관성 부여하기. 1) 조건 로직 대 객체 탐색 2) 캡슐화 다시 살펴보기 - 데이터 은닉 : 오직 외부에 공개된 메서드를 통해서만 객체의 내부에 접근할 수 있게 제한함으로써 객체 내부의 상태 구현을 숨기는 기법 - 캡슐화는 데이터 은닉 이상이다. - GOF의 조언에 따르면 캡슐화란 단순히 데이터를 감추는 게 아님. - 소프트웨어 안에서 변할 수 있는 모든 '개념'을 감추는 것임 - 캡슐화의 가장 대표적 예) 객체의 퍼블릭 인터페이스와 구현을 분리하는 것. - 자주 변경되는 내부 구현을 안정적인 퍼블릭 인터페이스 뒤로..

38일차. 오브젝트: 코드로 이해하는 객체지향 설계[7주차_화요일] 483-493pg #요약 **Chapter 14. 일관성 있는 협력** 01. 핸드폰 과금 시스템 변경하기 1) 기본 정책 확장 2) 고정요금 방식 구현하기 3) 시간대별 방식 구현하기 4) 요일별 방식 구현하기 5) 구간별 방식 구현하기 - 현재 구현의 가장 큰 문제는 이 클래스들이 유사한 문제를 해결하고 있음에도 불구하고 설계에 일관성이 없다는 것. - 이 클래스들은 기본 정책을 구현한다는 공통의 목적이 있지만 정책을 구현하는 방식은 완전히 다르다. - 개념적으로는 연관돼 있지만 구현 방식에 있어서는 완전히 제각각 - 유사한 기능을 서로 다른 방식으로 구현해서는 안된다. - 유사한 기능은 유사한 방식으로 구현해야 한다. 02. 설계에..

원인 함수인데 함수로 써주지 않아서 생기는 원인 ex) function() 인데 function으로 작성할 경우 해결 함수인데 function 이라고 작성한 게 있다면 function()으로 수정한다. 참고 : https://heytech.tistory.com/428

원인 useRoutes는 로 감싸야 하는데, 감싸지 않고 사용해서 발생한 에러. 해결 index.js 에서 import { BrowserRouter } from 'react-router-dom'; 해주고, const root = ReactDOM.createRoot(document.getElementById('root')); root.render( ); 이렇게 App.js 를 BrowserRouter로 감싸주니 해결됨. 참고 : https://itprogramming119.tistory.com/entry/Uncaught-Error-useRoutes-may-be-used-only-in-the-context-of-a-Router-component-%ED%95%B4%EA%B2%B0-%EB%B0%A9%EB%B2%95

36일차. 오브젝트: 코드로 이해하는 객체지향 설계[6주차_토요일] 460-470pg #요약 **Chapter 13. 서브클래싱과 서브타이핑** 01. 타입 02. 타입의 계층 03. 서브클래싱과 서브타이핑 04. 리스코프 치환 원칙 1) 클라이언트와 대체 가능성 2) is-a 관계 다시 살펴보기 3) 리스코프 치환 원칙은 유연한 설계의 기반이다. - 클라이언트의 입장에서 퍼블릭 인터페이스의 행동 방식이 변경되지 않는다면 클라이언트의 코드를 변경하지 않고도 새로운 자식 클래스와 협력할 수 있다. - 리스코프 치환 원칙을 따르는 설계는 유연할 뿐만 아니라 확장성이 높다. - 리스코프 치환 원칙이 어떻게 개방-폐쇄 원칙을 지원하는지 : 자식클래스가 클라이언트의 관점에서 부모 클래스를 대체할 수 있다면 기능 ..

35일차. 오브젝트: 코드로 이해하는 객체지향 설계[6주차_금요일] 447-459pg #요약 **Chapter 13. 서브클래싱과 서브타이핑** 01. 타입 02. 타입의 계층 03. 서브클래싱과 서브타이핑 4) 클라이언트의 기대에 따라 계층 분리하기 - 인터페이스는 클라이언트가 기대하는 바에 따라 분리돼야 한다. 그러면 변경에 대한 영향을 더 세밀하게 제어할 수 있게 된다. - 인터페이스는 클라이언트의 요구가 바뀜에 따라변겨된다. - 인터페이스 분리 원칙 : 인터페이스를 클라이언트의 기대에 따라 분리함으로써 변경에 의해 영향을 제어하는 설계 원칙 - 인터페이스 분리 원칙은 비대한 인터페이스의 단점을 해결한다. - 설계가 꼭 현실 세계를 반영할 필요는 없다. - 현실을 정확하게 묘사하는 것이 아니라 요구..

34일차. 오브젝트: 코드로 이해하는 객체지향 설계[6주차_목요일] 436-446pg #요약 **Chapter 13. 서브클래싱과 서브타이핑** - 13장의 목표 : 상속이 서브타입 다형성과 동적 메서드 탐색에 밀접하게 연관돼어 있음 알기. - 객체기반 프로그래밍 : 상태와 행동을 캡슐화한 객체를 조합해서 프로그램을 구성하는 방식. - 객체지향 프로그래밍 : 객체기반 프로그래밍의 한 종류, 상속과 다형성을 지원하지만 객체기반 프로그래밍은 지원하지 않음. 01. 타입 1) 개념 관점의 타입 : 우리가 인지하는 세상의 사물의 종류 - 우리가 인식하는 객체들에 적용하는 개념이나 아이디어 - 어떤 대상이 타입으로 분류될 때 그 대상을 타입의 인스턴스라고 부름 - 객체 : 타입의 인스턴스 - 타입은 심볼, 내연,..

33일차. 오브젝트: 코드로 이해하는 객체지향 설계[6주차_수요일] 425-435pg #요약**Chapter 12. 다형성** 01. 다형성(Polymorphism) 02. 상속의 양면성 03. 업캐스팅과 동적 바인딩 04. 동적 메서드 탐색과 다형성 1) 자동적인 메시지 위임 2) 동적인 문맥 3) 이해할 수 없는 메시지 a. 정적타입 언어일 때 b. 동적타입 언어일 때 4) self 대 super - super를 런타임에 결정하는 경우 : 스칼라의 트레이트는 super의 대상을 믹스인되는 순서에 따라 동적으로 결정함. 따라서 사용하는 언어의 특성에 따라 달라질 수 있다. - 동적 바인딩과 self 참조는 동일한 메시지를 수신하더라도 객체의 타입에 따라 적합한 메서드를 동적으로 선택할 수 있게 함. -..