Dog foot print

컴포지트 패턴 활용 : 객체들의 관계를 트리구조로써 부분 전체 계층을 표현하는 패턴으로 사용자가 단일 객체 복합 객들도 모두 동일하게 다룰 수 있도록 할 때 사용 한다. 객체 구성 Component : 인터페이스를 정의하며, 컴포지트 객체에 대한 기본 동작을 구현한다. Leaf 와 Composite가 구현해야 하는 interface이며, 이 두 요소는 상황에 따라 개별적인 클래스가 아닌 Component 인터페이스로 다루어 진다. Composite : Leaf 혹은 Composite 인스턴스를 자식으로 가진다. Leaf : Composite의 자식의 역할을 하며, 이 노드가 Compsite를 자식으로 두지 않는다. 책의 카테고리라는 구성으로 본 Composite 패턴 . 카테고리 : 카테고리는 책을 포함..

싱글턴 패턴 활용 싱글턴 패턴은 시스템 전반에 걸쳐서 어떤 인스턴스가 한개만 생성되고 한개의 사용을 강제하는 것에 있다. 예를 들어 API 를 관장하는 인스턴스는 굳이 모듈별로 인스턴스를 생성하지 않아도 되며, API 인스턴스는 프로퍼티의 변화가 거의 없기 때문에 인스턴스를 계속 생성하면 메모리만 낭비하게 된다. 개발자간의 상호 협의간에 싱글턴 인스턴스를 사용하는 예시 var API = ( ()=>{ return { getData(){ console.log("Data 가져오기") }, postData(data : any){ console.log(`${data} 전송중`) } } } )() API.getData() API.postData("데이터") static 인스턴스를 사용하는 방법 class API ..

빌더 패턴 활용 구축 단계만 노출하여, 내부 구성요소를 캡슐화 하고 최종 제품을 직접 제공하는 패턴이다. 복잡한 객체 구축에 대한 더 유연한 추상화와 구현을 가능하게 한다. 즉 빌더는 구성요소를 만들 때, return 하지 않는다. 참여 객체 빌더 : 제품을 구축하는 빌더의 인터페이스를 정의한다. 구체적인 빌더 : 제품의 부분을 구축하는 메서드를 구현하며, 현재 구축 상태를 추적한다. 디렉터 : 단계를 정의하고 제품 구축을 위해 빌더와 협업한다. 최종 제품 : 빌더가 구축한 제품이다. [image:1A0310E4-6A98-4677-B66E-2F97E85EC6BD-75143-0008E9D425CBAA97/2021-10-23_15-22-44.png] 코드 예시 내가 만들고 싶은 Product abstract..

추상화 팩토리 메서드 활용 같은 생성 방식을 가진 클래스군을 만들기 위해서 사용하는 패턴이다. 만약 생성 절차는 동일하지만, 전체 팩토리 교체를 통해 동일한 생산 방식을 따르며 서로 다른 제품을 생산 할 수 있게 한다. 참여 객체 추상 팩토리 : 팩토리의 산업 표준을 정의하여 생산 절차가 복잡한 제품을 만드는 데 필요한 인터페이스를 제공한다. 구체적인 팩토리 : 추상팩토리에서 정의한 인터페이스를 구현하고 구체적인 제품을 만든다. 추상 제품 : 팩토리가 만들 제품의 인터페이스를 정의한다. 구체적인 제품: 구체적인 팩토리가 만들 실제 제품을 나타낸다. 클라이언트 : 팩토리 전체에 생산 프로세스를 배치한다. [image:1A58DCCB-066E-4AE6-B22E-56E6E7D4B8F7-75143-000796B..

팩토리 메서드 패턴 활용 클래스가 어떤 객체를 생성할지 정확하게 예측할 수 없는 경우가 존재하거나, 클래스의 서브클래스가 해당 객체를 더 구체적인 버전으로 생성하기 원할수도 있는 경우 . 참여 객체 Product : 팩토리가 반환할 추상클래스나 인터페이스를 의미 . Concrete Product : 팩토리가 실제로 반환하는 객체 Creator : 제품 생성을 하기 위해 접근하는 추상화 팩토리 클래스 Concrete Creator : Concrete Product를 실제로 구체화 하기 위한 생성자 . 이를 클래스 다이어그램으로 표현 하면 다음과 같다. 실생활 예제 우리가 자동차를 주문하기위해 접근 할 수 있는 공장이 존재한다. 우리는 이 공장에 자동차를 주문하면 우리가 원하는 자동차 가 전달 되는 것을 알..

서론 지난 포스팅에 이어 마지막 DIP 에 대해서 포스팅 하겠습니다. DIP :(Dependency Inversion Principle) 의존관계 역전 원칙 의존성 역전 원칙에서 말하는 "유연성이 극대화된 시스템"이란 소스코드가 추상에 의존하며 구체에는 의존하지 않는 시스템을 의미한다. 추상 인터페이스에 변경이 생기면 이를 구체화한 구현체들도 따라서 수정해야 한다. 반대로 구체적인 구현체에 변경이 생기더라도 그 구현체가 구현하는 인터페이스는 항상 변경될 필요가 없다. 따라서 인터페이스는 구현체보다 변동성이 낮다. 즉 안정된 소프트웨어 아키텍처란 변동성이 큰 구현체에 의존하는 일은 지양하고, 안정된 추상 인터페이스를 선호하는 아키텍처라는 뜻이다. 이 원칙을 구체적인 코딩 실천법으로 요약 하면 다음과 같다...

서론 지난 포스팅에 이어 오늘은 [i]에 대해서 포스팅 하도록 하겠습니다. ISP (Interface Segregation Principal) : 인터페이스 분리 원칙 인터페이스 분리 원칙은 어떤 인터페이스로부터 상속받아 클래스를 정의 할 때, 사용하지 않는 메서드까지 상속 받지 말고 새로운 인터페이스를 생성하여 기존 상속하려던 인터페이스를 새롭게 확장하여 상속 받아야 한다는 분리원칙이다. 다음의 클래스다이어그램을 보도록 하자 . 위의 클래스 다이어그램에서 파리,벌,사슴벌레 클래스는 곤충 인터페이스를 상속받는다. 이 경우 파리 클래스에서는 독을 뿜다. 라는 메서드가 필요없으며, 벌 클래스와 사슴벌레 클래스에서는 각각 뿔을 움직인다, 독을 뿜다라는 메서드가 필요없음에도 곤충인터페이스를 상속 받았기 때문에 ..

서론 지난 포스팅에 이어 SOLID 원칙 중 [L]에 대해서 포스팅을 이어나가보도록 하겠다. LSP(Liskov substitution Principle) : 리스코프 치환 법칙 리스코프는 하위타입에 대해서 다음과 같이 정의하였다. "S타입의 객체 o1 각각에 대응하는 T타입 객체 o2가 있고, T타입을 이용해서 정의한 모든 프로그램 P에서 o2의 자리에 o1을 치환하더라도 P의 행위가 변하지 않는다면,S는 T의 하위 타입이다. " 리스코프의 말이 어렵게 느껴지는 것이 당연하다. 이를 조금 더 쉽게 풀어 설명하면, 다음과 같다. "부모 A로부터 상속받은 자식 B가 존재할 때 부모 A는 자식 B로 타입을 치환하여도 프로그램에서 행위는 변하지 않는다. " 어찌 보면 당연한 소리이다. 부모 A로부터 만들어진 ..