pattern

SRP : 단일 책임 원칙 OCP : 개방-폐쇄 원칙 LSP : 리스코프 치환 원칙 ISP : 인터페이스 분리 원칙 DIP : 의존관계 역전 원칙

어댑터 패턴, 퍼싸드 패턴 // 원리를 잘 따르다가 생겨난 패턴들..큰 프로젝트일수록 기초공사가 중요함추상 클래스와 인터페이스는 생김새, 사용법도 다르지만 하는 일이 비슷하다.

Usecase diagram(사용사례 다이어그램)Activity diagram(액티비티 다이어그램) : flowchart와 유사Interaction diagram : 객체들이 어떻게 상호작용하는가. Sequence diagram이 많이 사용됨Class diagram :

컴포지트 패턴과 브리지 패턴 // 이전 글의 어댑터, 퍼싸드 패턴과 함께 프로그램의 뼈대/골격이 될 만한 패턴이다컴포지트: 개별이 될 수도 있고 집합이 될 수도 있는 객체

책임패턴: 객체의 책임을 중앙 집권화, 확대, 제한하는 기법을 사용 싱글톤 패턴, 옵서버 패턴, 중재자 패턴

프록시 패턴 : 하나의 객체가 다른 객체를 대신하게 함 책임 체인 패턴 : 요청을 보내느느 쪽과 받는 쪽의 결합을 피함 플라이웨이트 패턴 : 본질적인 것과 부가적인 것을 구분함

생성 패턴 일반적으로 객체를 생성할 때에는 생성자(constructor)를 제공한다. 때로는 변형이 필요한데, 생성 객체에 초기값을 줄 때나 생성할 클래스를 선택하려 할 때가 그렇다. 여러 개의 생성자가 필요할 때면, 서로 협력이 필요하다. > 상속된 부모클래스와 자식

생성패턴 보통의 생성자와는 다른 객체를 만드는 패턴 - 프로토타입 패턴 - 메멘토 패턴

오퍼레이션에 임무를 준다던지 하는 특징을 가지고 있는 패턴 일반적인 정의 오퍼레이션 - 클래스의 인스턴스가 요청할 수 있는 서비스의 명세 메소드 - 오퍼레이션을 구현한 것 알고리즘 - 입력을 전달받아 출력을 생성하는 프로시저 일반적인 오퍼레이션을 넘어 템플릿 메소드

커맨드 패턴 어떤 커맨드를 선택하고 인지하기 복잡함 -여러개의 객체가 들어올 수 있는 다형성을 가짐 하나로 만들자

리팩토링 : 프로그램의 가치를 높이는 코딩 정리 기술 Fowler의 정의 : 관측 가능한 동작의 수정 없이 소프트웨어의 내부 구조를 변경하여 더욱 이해하기 쉽고 변경하기 쉬운 구조로 만드는 일 : 관측 가능한 동작의 수정 없이 리팩토링을 적용하여 소프트웨어를 재구조화함

GoF 디자인 패턴 생성패턴 이름|설명 :--:|-- 추상 팩토리(Abstract Factory)|구체적인 클래스를 지정하지 않고 인터페이스를 통해 서로 연관되는 객체들을 그룹으로 표현함 빌더(Builder)|복합 객체의 생성과 표현을 분리하여 동일한 생성 절차에서도

MVC Pattern

waterfall 순차적으로 요구사항 정의 디자인 개발 테스트 배포 프로세스를 진행하는 방식 > agile 빠르게 변하는 고객의 요구에 대응하기 위하여 속도/변화에 취약한 waterfall 방법론의 대안으로 생겨났다.

우리의 밥아저씨 Martin이 제안한 SOLID 설계 원리는 객체지향 소프트웨어 설계를 보다 쉽게 유지관리 하고, 쉽게 확장하게 만든다. 쉽고 정확한 설계 및 의사소통을 위한 솔리드 원리를 알아보자!