DeFacto-Standard IT

Strategy Pattern 1 : Many 관계와 같다. 객체의 타입을 하나로 다루면서 이해 다양한 연산을 적용해야할 때, Strategy Pattern을 활용하면 적절하다. 예를 들면, Video 클래스가 있다고 가정하자. 이 클래스는 동영상 파일을 의미한다. 동영상에는 Mpeg, Avi 등 여러 포맷이 존재하고, 표현하는 방법이 모두 다르다. 따라서 MpegVideo, AviVideo 등 파생 클래스가 존재한다. 전부 다르지만 Video Interface(혹은 class)를 상속받아 캡슐화하고, 추상화하여 하나의 Video로 다룰 때 유용하다. Visitor PatternMany : Many 관계와 같다. 위에서 Video 뿐만아니라 Audio까지 다루게 된다고 가정해보자. Audio 역시 다양한..

1. 연관 관계 (Association) 클래스들이 개념상 서로 연결. 한 클래스가 다른 클래스에서 제공하는 기능을 사용 1-1) 단방향 연관 관계 (Uni-Directional Relationship) - UML : 화살표 + 실선 - 소스코드public class Person { private Car car; public void doIt() { car.doIt(); } } public class Car { public void doIt() { // ... } } 1-2) 양방향 연관 관계 (Bi-Directional Relationship) - UML : 실선 - 소스코드public class Member { private Team team; } public class Team { private A..

S - Single Responsibility Princile, SRP, 단일 책임 원칙 하나의 클래스(객체)는 하나의 역할만 책임진다.(클래스를 변경하는 이유는 단 한 개여야 한다) 응집도는 높게, 결합도는 낮게 설계 DB의 정규화 과정을 거치는 것도 SRP를 적용하는 것과 마찬가지 지켜지지 않으면 이 클래스가 무슨 클래스인지도 모르며, 다른 클래스에서 했어야할 책임인데 여기서 수행하므로 전혀 상관없는 클래스를 고치게 되는 꼴이 되어버린다. 소스가 엉망이 된다는 소리. https://defacto-standard.tistory.com/110 O – Open Closed Principle, OCP, 개방 폐쇄 원칙 기능을 확장하는 것에는 열려있지만(다형성), 주변의 변화(코드 수정)에 대해서는 닫혀있다...

인터페이스를 사용하는 경우 - 관련되지 않은 클래스에 일반적인 기능을 제공하는데 적합 - 만들고 있는 기능이 광범위한 분산 개체에서 유용하게 사용될 것으로 예상되는 경우 - 작고 간결한 기능을 디자인 하는 경우 추상클래스를 사용하는 경우 - 밀접하게 관련된 개체에 사용 - 여러 버전의 구성요소를 만들 것으로 예상되는 경우 간단하고 쉽게 구성요소의 버전을 작성할 수 있다. 기본 클래스를 업데이트하면 모든 상속 클래스의 변경 내용이 자동으로 업데이트. (인터페이스의 경우 한번 만들면 변경 불가. 새 버전의 인터페이스가 필요하면 완전히 새롭게 인터페이스를 만들어야 한다.) - 큰 기능 단위들을 디자인하는 경우 - 모든 구성 요소의 구현 사이의 일반적인 구현된 기능을 제공하는 경우. 추상 클래스를 사용하면 부분..

에리히 감마 Erich Gamma 리차드 헬름 Richard Helm 랄프 존슨 Ralph Johnson 존 블리시디스 John Vlissides 생성 패턴 구조 패턴 행위 패턴 추상 팩토리 (Abstract Factory) 어댑터 (Adapter) 책임 연쇄 (Chain of Responsibility) 빌더 (Builder) 브리지 (Bridge) 커맨드 (Command) 팩토리 메서드 (Factory Method) 컴퍼지트 (Composite) 인터프리터 (Interpreter) 프로토타입 (Prototype) 데커레이터 (Decorator) 아이터레이터 (Iterator) 싱글턴 (Singleton) 퍼사드 (Facade) 미디에이터 (Mediator) 플라이웨이트 (Flyweight) 메멘토 (..

인터페이스 분리 원칙 (ISP, Interface Segregation Principle) 프로그래밍 능력에 변화가 생기더라도 외국어 능력이나 발표 능력을 사용하는 영업 업무에는 영향을 미치지 않을 확률이 높지만 개발 업무 부서에는 영향을 미칠 수 있다. ISP는 위의 관점(클라이언트의 관점에서 바라는)에서 생긴 객체지향 설계 원칙에는 클라이언트 자신이 이용하지 않는 기능에는 영향을 받지 않아야 한다는 내용이 담겨있다. 복합기 기능을 제공하는 클래스는 매우 비대해질 가능성이 크다. 하지만 이 비대한 클래스의 모든 기능을 클라이언트가 동시에 사용하는 경우는 거의 없다. 클라이언트의 필요에 따라 프린터, 팩스, 복사기 중 하나의 기능만 이용할 수 있다. 따라서 프린터 기능만 이용하는 클라이언트가 팩스 기능의..

의존 역전 원칙 (DIP, Dependency Inversion Principle) 객체 사이에 서로 도움을 주고받으면 의존 관계가 발생한다. 의존 역전 원칙은 그러한 의존 관계를 맺을 때의 가이드라인에 해당. *DIP는 의존 관계를 맺을 때 변화하기 쉬운 것 또는 자주 변화하는 것 보다는 변화하기 어려운 것, 거의 변화가 없는 것에 의존하라는 원칙. 변하기 쉬운 것과 변하기 어려운 것은 어떻게 구분하는가. 정책, 전략과 같은 어떤 큰 흐름이나 개념 같은 추상적인 것은 변하기 어려운 것에 해당하고 구체적인 방식, 사물 등과 같은 것은 변하기 쉬운 것으로 구분하면 좋다. 아이가 장난감을 가지고 노는데 어떤 경우에는 로봇을, 어떤 경우에는 자동차를 가지고 놀 것이다. 이때 구체적인 장난감은 변하기 쉬운 것이..

리스코프 치환 원칙 (LSP, Liskov Substitution Principle) 일반화 관계에 대한 이야기며 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야 한다. LSP를 만족하면 프로그램에서 부모 클래스의 인스턴스 대신에 자식 클래스의 인스턴스로 대체해도 프로그램의 의미는 변화되지 않는다. 이를 위해 부모 클래스와 자식 클래스 사이는 행위가 일관되어야 한다. LSP를 이해하려면 일반화 관계를 다시 생각해야한다. 일반화 관계는 'is a kind of 관계' 라고도 한다. 예를들어 원숭이는 포유류이고, 원숭이와 포유류 사이에 '원숭이 is a kind of 포유류 관계'가 성립한다. 따라서 부모 클래스로 포유류, 자식 클래스로 원숭이를 설정하는 것에 대체로 반론의 여지..

개방-폐쇄 원칙 (OCP, Open-Closed Principle) 기존의 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계가 되어야 한다. 단일책임 원칙에서 예를 든 성적표나 출석부에 학생의 성적이나 출석 기록을 출력하는 기능을 생각해보자. 다음 그림은 SomeClient 클래스에서 이 기능을 이용하는 경우를 모델링한 것. 성적표나 출석부에 학생을 출력하는 기능을 사용 만약 도서관 대여 명부와 같은 새로운 매체에 학생의 대여 기록을 출력하는 경우라면, 아주 간단한 방식으로 도서관 대여 명부 클래스를 만들어 SomeClient 클래스가 이 기능을 이용하도록 할 수 있다. 그러나 이 방식은 OCP를 위반한다. 새로운 기능(도서관 대여 명부에 학생의 대여 기록을 출력)을 추가하려고 SomeClient ..

단일 책임 원칙 (SRP, Single Responsibility Principle) 책임의 의미 SRP에서 책임의 기본 단위는 객체를 지칭. 즉, 객체는 단 하나의 책임만 가져야 한다. 책임 = 해야 하는것, 할 수 있는 것, 해야 하는 것을 잘 할 수 있는 것 예를 들어 Student (학생) 클래스가 수강 과목을 추가하거나 조회하고, 데이터베이스에 객체 정보를 저장하거나 데이터베이스에서 객체 정보를 읽는 작업도처리하고, 성적표와 출석부어 출력하는 일도 실행한다고 가정. 이런 경우 Student 클래스의 코드는 다음과 같이 정의될 것이다. public class Student { public void getCourses() {...} public void addCourses(Course c) {.....