swk의 지식저장소

팩토리 패턴 (Factory Pattern) 팩토리 메소드 패턴 : 객체를 생성하기 위한 인터페이스를 정의하는데, 어떤 클래스의 인스턴스를 만들지는 서브클래스에서 결정하게 만든다. 즉 팩토리 메소드 패턴을 이용하면 클래스의 인스턴스를 만드는 일을 서브클래스에게 맡기는 것. 추상 팩토리 패턴 : 인터페이스를 이용하여 서로 연관된, 또는 의존하는 객체를 구상 클래스를 지정하지 않고도 생성. new를 사용하는 것은 구상 클래스의 인스턴스를 만드는 것이다. 당연히! 인터페이스가 아닌 특정 구현을 사용하게 되어버리는 것. 일련의 구상 클래스들이 있을때는 어쩔수 없이 다음과 같은 코드를 만들어야 하는 경우가 있음. Duck duck; if ( type == picnic ) duck = new MallardDuck(..

데코레이터 패턴 (Decorator Pattern) 객체에 추가적인 요건을 동적으로 첨가한다. 데코레이터는 서브클래스를 만드는 것을 통해서 기능을 유연하게 확장할 수 있는 방법을 제공한다. 데코레이터 패턴 클래스 다이어그램 ConcreteComponent에 새로운 행동을 동적으로 추가할수 있다. 각 데코레이터 안에는 구성요소(Component)에 대란 레퍼런스가 들어있는 인스턴스 변수가있다. Decorator는 자신이 장식할 구성요소(Component)와 같은 인터페이스 또는 추상 클래스를 구현한다. ConcreteDecoratorA, ConcreteDecoratorB 에는 그 객체가 장식하고있는(데코레이터가 감싸고 있는 Component객체)을 위한 인스턴스 변수가 있다. 따라서 데코레이터는 Compo..

옵저버 패턴 (Observer Pattern) 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들한테 연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다(one-to-many) 의존성을 정의한다. 옵저버 패턴을 구현하는 방법에는 여러가지가 있지만 대부분 상태를 저장하고있는 주제 인터페이스를 구현한 하나의 주제객체와 주제객체에 의존하고있는 옵저버 인터페이스를 구현한 여러개의 옵저버객체 가 있는 디자인을 바탕으로 한다. 데이터 전달방식은 2가지가 있다. 주제객체에서 옵저버로 데이터를 보내는 방식 (푸시 방식) 옵저버에서 주제객체의 데이터를 가져가는 방식 (풀 방식) 옵저버 패턴 클래스 다이어그램 디자인 원칙. 서로 상호작용을 하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인을 사용해야 한다. (..

스트래티지 패턴(Strategy Pattern) 알고리즘군을 정의하고 각각캡슐화하여 교환해서 사용할 수 있도록 만든다. 스트래티지패턴을 활용하면 알고리즘을 사용하는 클라이언트와는 독립적으로 알고리즘을 변경할수 있다. 오리 어플리케이션 게임을 운영하는 회사를 다니면서 오리게임을 만든다고 가정했을때. 표준적인 객체지향 기법을 사용하여 Duck 이라는 슈퍼클래스를 만든다음 그 클래스를 확장하여 다른 종류의 오리를 만든다. 추상클래스인 Duck 클래스를 ReadHeadDuck 클래스와 MallardDuck 클래스가 상속을 받아 추상메소드인 display()를 각각 구현한다. 문제의 시작1 원래는 그럴 계획이 없었는데.. 오리들이 물에 떠있는 기능 이외에 날아다녀야하는 요구사항이 생겼다. 간단하네.. ? 이제 모..

1. 애플리케이션에서 달라지는 부분을 찾아 내고, 달라지지 않는 부분으로부터 분리시킨다. 첫번째 원칙은 스트래티지 패턴에 해당하는 장에서 등장했다. 새로운 요구사항이 추가로 들어왔다. 혹은 기존 화면의 요구사항이 변경됬다. 이럴때 우리는 클래스의 메소드나 생성자를 고치고 추가하는 작업을 한다. 그 다음에 해당 클래스를 사용하는 모든 코드를 고친다. 생각만해도 끔찍하다. 나중을 위해... 코드에 바뀌는 부분이 있다면, 그 행동을 기존 코드에서 분리시켜야한다. * 바뀌는 부분을 따로 뽑아서 캡슐화한다. * 이를 지키면 나중에 바뀌지 않는 부분에 영향을 미치지 않을 채로 그 부분만 고치거나 확장할 수 있다. Ex) class A { public methodA() { 바뀌지 않는 부분 바뀌는부분 -> 이 부분을..

- Coupling의 정의 coupling이란 서로 상호작용하는 시스템들간의 의존성을 의미한다. 의존성은 실질적 의존성과 인위적 의존성으로 나뉠 수 있다. 실질적 의존성은 한 시스템이 소비하는 다른 시스템의 기능이나 서비스 집합을 의미한다 인위적 의존성은 한 시스템이 다른 시스템이 제공하는 기능이나 서비스를 소비하기 위해 필요한 여러 요소들의 집합을 의미한다. 전형적으로 인위적 의존성은 언어적인 의존성, 플랫폼 의존성, API 의존성등이 있다. 인위적 의존성은 언제나 존재하지만 그 비용은 충분히 감소될 수 있다. Loose Coupling은 이러한 인위적 의존성을 최소한으로 줄이는 구조를 의미한다. 긴밀한 결합(Tight Coupling) 강하게 결합된 객체(Tightly Coupled Object)는 ..

MVC 패턴(Model, View, Controller) - Model과 View사이에 Controller가 있음 - MVC 패턴의 가장 큰 장점은 비즈니스 로직과 프리젠테이션 로직이 분리되어 있어서 디자이너와 개발자의 영역이 분리됨으로써 서로 각자의 영역에 더 집중할 수 있음 -> 유지보수가 용이함 Model Component - 핵심기능, 데이터 처리 등 주로 DB쪽을 담당함 - 핵심기능과 데이터를 캡슐화하여 입출력에 영향을 받지 않고 독립적으로 움직임 - DTO, DAO 등 비즈니스 로직 - 대부분의 java 파일은 전부 Model - 비즈니스 데이터는 DBMS에 의해 관리, 그 데이터를 다루는 연산은 SQL문을 통해서 구현함 View Component - 주로 디자인에 관련된 부분으로 사용자에게 ..

1. SOLID란? 객체지향 설계는 긴 세월과 수많은 시행착오를 거치며 5가지 원칙이 정리되었다. 이것은 객체지향 설계의 5원칙이라고 하며, 앞글자를 따서 SOLID라고 한다. SRP(Single Responsibility Principle) : 단일 책임 원칙 OCP(Open Closed Principle) : 개방 폐쇄 원칙 LSP(Liskov Substitution Principle) : 리스코프 치환 원칙 ISP(Interface Segregation Principle) : 인터페이스 분리 원칙 DIP(Dependency Inversion Principle) : 의존 역전 원칙 이 원칙들은 응집도는 높이고 결합도는 낮추자는 고전 원칙을 객체 지향의 관점에서 재정립한 것으로 볼 수 있다. 2. SR..