책 (36) 썸네일형 리스트형 유연한 설계 개방 폐쇄 원칙(OCP)확장에 대해 열려 있고, 변경에 대해서는 닫혀 있어야 한다. - 확장에 대해 열려 있다 : 요구사항이 변경될 때 새로운 '동작'을 추가해서 애플리케이션의 기능을 확장할 수 있다 - 변경에 대해 닫혀 있다 : 기존의 '코드'를 수정하지 않고도 애플리케이션의 동작을 추가하거나 변경할 수 있다 컴파일 타임 의존성을 고정시키고 런타임 의존성을 변경하라컴파일 타임 의존성 : 코드에서 드러나는 클래스들 사이의 관계런타임 의존성 : 실행시에 협력에 참여하는 객체들 사이의 관계개방 폐쇄 원칙을 따르는 설계를 하자 추상화가 핵심이다개방 폐쇄 원칙의 핵심은 추상화에 의존하는 것추상화 - 핵심적인 부분만 남기고 불필요한 부분은 생략함으로써 복잡성을 극복하는 기법 - 문맥이 바뀌더라도 변하지 않는 부분.. 도커의 기초 도커의 기본 개념컨테이너 가상화를 구현하기 위한 상주 애플리케이션과 이를 관리하는 명령형 도구로 구성컨테이너 - 컨테이너 가상화 소프트웨어 없이 운영 체제의 리소스를 격리해 만드는 가상 운영 체제 - 컨테이너를 만들면서 발생하는 오버헤드는 다른 가상화 소프트웨어보다 더 적음 - 빠르게 시작 및 종료할 수 있고 이에 들어가는 리소스도 작은편애플리케이션이 중심이 되는 도커 - 호스트 운영 체제의 영향을 받지 않는 실행 환경(Docker Engine을 이용한 실행 환경 표준화) - DSL(Dockerfile)을 이용한 컨테이너 구성 및 애플리케이션 배포 정의 - 이미지 버전 관리 - 레이어 구조를 갖는 이미지 포맷(차분 빌드가 가능함) - 도커 레지스트리(이미지 저장 서버 역할을 함) - 프로그램 가능한 다양.. 의존성 관리하기 변경과 의존성실행 시점 : 의존하는 객체가 정상적으로 동작하기 위해서는 실행 시에 의존 대상 객체가 반드시 존재해야 한다.구현 시점 : 의존 대상 객체가 변경될 경우 의존하는 객체도 함께 변경된다. 의존성 전이(transitive dependency)직접 의존성(direct dependency) : 한 요소가 다른 요소에 직접 의존하는 경우간접 의존성(indirect dependency) : 직접적인 관계는 존재하지 않지만 의존성 전이에 의해 영향이 전파되는 경우 런타임 의존성과 컴파일 타임 의존성런타임 의존성(run-time dependency) : 애플리케이션이 실행되는 시점의 의존성 - 객체 사이의 의존성컴파일타임 의존성(compile-time dependency) : 작성된 코드를 컴파일하는 시점.. 객체 분해 객체 분해추상화(abstraction) : 불필요한 정보를 제거하고 현재의 문제 해결에 필요한 핵심만 남기는 작업분해(decomposition) : 큰 문제를 해결 가능한 작은 문제로 나누는 작업 프로시저 추상화와 데이터 추상화시스템을 분해하는 방법을 결정하려면 먼저 프로시저 추상화를 중심으로 할 것인지, 데이터 추상화를 중심으로 할 것인지를 결정해야 한다.프로시저 추상화(procedure abstraction) : 소프트웨어가 무엇을 해야하는지 추상화 - 기능 분해(functional decomposition), 알고리즘 분해(algorithm decomposition)데이터 추상화(data abstraction) : 소프트웨어가 무엇을 알아야하는지 추상화 - 데이터를 중심으로 타입을 추상화(type .. 메시지와 인터페이스 메시지와 메시지 전송메시지 : 객체들이 협력하기 위해 사용할 수 있는 유일한 의사소통 수단메시지 전송, 메시지 패싱 : 다른 객체에게 도움을 요청 하는 것메시지 전송자 : 메시지를 전송하는 객체메시지 수신자 : 메시지를 수신하는 객체메시지는 오퍼레이션명과 인자로 구성되며 메시지 전송은 여기에 메시지 수신자를 추가한 것 메시지와 메서드메서드 : 메시지를 수신했을 때 실제로 실행되는 함수 또는 프로시저메시지와 메서드의 구분은 메시지 전송자와 메시지 수신자가 느슨하게 결합될 수 있게 한다. - 실행 시점에 메시지와 메서드를 바인딩하는 메커니즘은 두 객체 사이의 결합도를 낮춤으로써 유연하고 확장 가능한 코드를 작성할 수 있게 만든다. 퍼블릭 인터페이스와 오퍼레이션퍼블릭 인터페이스 : 객체가 의사소통을 위해 외부.. 책임 할당하기 데이터보다 행동을 먼저 결정하라객체에게 중요한 것은 데이터가 아니라 외부에 제공하는 행동이다.객체는 협력에 참여하기 위해 존재하며 협력 안에서 수행하는 책임이 객체의 존재가치를 증명한다.데이터는 객체가 책임을 수행하는 데 필요한 재료를 제공할 뿐이다. 협력이라는 문맥 안에서 책임을 결정하라객체에게 할당된 책임의 품질은 협력에 적합한 정도로 결정된다.책임은 객체의 입장이 아니라 객체가 참여하는 협력에 적합해야 한다. 책임 주도 설계(RDD)1. 시스템이 사용자에게 제공해야 하는 기능인 시스템 책임을 파악한다.2. 시스템 책임을 더 작은 책임으로 분할한다.3. 분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임을 할당한다.4. 객체가 책임을 수행하는 도중 다른 객체의 도움이 필요한 경우 이를 .. 설계 품질과 트레이드오프 설계 트레이드오프캡슐화 - 외부에서 알 필요가 없는 부분을 감춤으로써 대상을 단순화하는 추상화의 한 종류 - 상태와 행동을 하나의 객체 안에 모으는 이유는 객체의 내부 구현을 외부로부터 감추기 위해서이다.구현 : 변경될 가능성이 높은 부분인터페이스 : 상대적으로 안정적인 부분설계가 필요한 이유는 요구사항이 변경되기 때문이고, 캡슐화가 중요한 이유는 불안정한 부분과 안정적인 부분을 분리해서 변경의 영향을 통제할 수 있기 때문이다.응집도 - 모듈에 포함된 내부 요소들이 연관되어 있는 정도를 나타냄 - 변경이 발생할 때 모듈 내부에서 발생하는 변경의 정도결합도 - 의존성의 정도를 나타내며 다른 모듈에 대해 얼마나 많은 지식을 갖고 있는지를 나타내는 척도 - 한 모듈이 변경되기 위해서 다른 모듈의 변경을 요구하.. 역할, 책임, 협력 협력객체들이 애플리케이션의 기능을 구현하기 위해 수행하는 상호작용메시지 전송 : 객체 사이의 협력을 위해 사용할 수 있는 유일한 커뮤니케이션 수단메시지를 수신한 객체는 메서드를 시행해 요청에 응답한다.외부의 객체는 오직 메시지만 전송할 수 있고, 메시지를 어떻게 처리할지는 메시지를 수신한 객체가 직접 결정한다. - 객체는 자신의 일을 스스로 처리할 수 있는 자율적인 존재객체를 자율적으로 만드는 가장 기본적인 방법은 내부 구현을 캡슐화하는 것이다. 캡슐화를 통해 변경에 대한 파급효과를 제한할 수 있기 때문에 자율적인 객체는 변경하기도 쉬워진다.상태는 객체가 행동하는 데 필요한 정보에 의해 결정되고 행동은 협력 안에서 객체가 처리할 메시지로 결정된다. 결과적으로 객체가 참여하는 협력이 객체를 구성하는 행동과.. 이전 1 2 3 4 5 다음