[C++ & C#] 정리

[ggjae]

GoF 디자인 패턴 : Gangs of Four 네명이 저자로 디자인 패턴에 대한 책을 집필

Protected 소멸자 : 객체를 파괴할 때 직접 딜리트하기보다는, '멤버함수를 통해서 Delete하라'라는 의미가 담겨 있다.

Upcasting : 자식으로 생성한 객체를 부모에게다 연결하는 것

순수가상함수 : 가상함수를 만들 때, =0 을 붙여 파생 클래스에서 구현을 기대하는 함수

추상 클래스 : 순수가상함수를 한 개 이상 가지고 있는 클래스

OCP : Open Close Principle, 객체 지향 SOLID 중 O에 해당하는 법칙. 기능 확장엔 Open, 수정엔 Close한다는 Principle

interface : 제품을 먼저 만들지 말고, interface(규칙, 계약)을 먼저 설계한다. 카메라라는 규칙을 만들어 새 카메라 제품이 들어온다 해도, 카메라 인터페이스를 따른다면 코드의 추가가 더 필요 없게 된다.

coupling : 결합으로, tightly coupling (서로에 대해서 잘 알고 있는 것, 교체나 확장이 불가능한 경직된 디자인), loosely coupling (객체가 서로 상호작용하지만, 서로에 대해 잘 알지 못하는 것)

struct로 인터페이스를 구현했던 이유 : struct는 public으로서 코드의 온전한 가독성을 위함

final : C++11문법 중 1, 뒤에 final을 붙이면 파생 클래스가 재정의할 수 없게 만듬.

디자인 패턴의 기본 : 변하지 않는 코드에서, 변하는 부분은 분리되어야 한다.

Prototype Design Pattern : Clone() 사용해 instance로부터 별도의 instance를 만드는 패턴.

Template Method Pattern : 모든 도형에 공통적인 변하지 않는 전체적인 흐름을 기반 클래스에서 제공함. DrawImp의 경우 훅 메소드 ( 알고리즘의 일부를 서브클래스에서 구현 ), Draw는 템플릿 메소드라 함.

Strategy Pattern : 구성의 디자인 방법이다. 이 정책을 실행시간에 바꿀 수 있다. 알고리즘의 군을 정의하고 각각을 캡슐화해 교환하여 사용할 수 있도록 만든다. 게임프로그래밍에서 자신이 처한 상황에 따라 공격이나 행동하는 방식을 바꾸고 싶을 때 전략패턴은 매우 유용하다.

템플릿 메소드와 전략 패턴의 차이 : 재사용성이 필요하고, 실행시간에 교체가 필요하다면 전략패턴이고, 그게 필요 없다면 템플릿메소드 패턴을 사용하면 좋다.

inline : 함수 호출이 함수 자체의 내용 복사본으로 대체되어 함수 오버헤드가 제거된다. 최근에는 컴파일러 자체에서 자동으로 넣어줌.

Policy Base Design : 전략패턴은 가상함수기반으로 정책교체가 가능했지만, 느렸다. 하지만 단위전략디자인은 인라인치환이 가능하고, 빠르지만 실행 시간에는 교체할 수 없다. 템플릿인자를 이용해 교체할 수 있게 만드는 디자인

State Pattern : 상태에 따라 변경되는 동작들을 다른 클래스로 분리한다.

---

변하지 않는 코드에서 변해야 하는 부분을 분리할 때, 함수 인자로 분리 (함수포인터, 함수객체, 람다표현식 등), 가상함수로 분리(Template Method), 다른 클래스로 분리(인터페이스로 교체는 Strategy, State이고, 템플릿 인자 Policy Base Design)

함수 포인터를 쉽게 사용하기 : C++11부터는, function<void()> f; 처럼 일반화된 함수 포인터 역할을 지원하는 템플릿이 생김
헤더는 functional을 이용하여야 한다. bind를 이용해서 f = bind(&Dialog::Close, &dlg); 코드로 사용할 수도 있다.

Composite Pattern : 메뉴아이템에 빗대어서 설명해주셨던 것. 팝업메뉴와 메뉴아이템에서 기반 클래스인 BaseMenu만든 것. 단일 객체와 그 객체들을 가지는 집합 객체를 같은 타입으로 취급하여, 트리 구조로 객체를 엮는 패턴

Observer Pattern : 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에게 연락이 가고, 자동으로 내용이 갱신되는 방식으로 일대다 의존성을 정의, 핸들러 만들어서 함수포인터 이용하는 것. 쉬운 예시로는 엑셀의 한 셀을 변경하면 그래프가 막 자동으로 갱신되고 그랬지. 그것이 옵저버 패턴.

옵저버 패턴의 방식 : 1. 그래프에서 계속 테이블을 관찰하는 것 2. 테이블이 바뀌었을 떄 그래프들에게 바뀌었다고 알려주는 것
관찰자를 Observer라고 하고, 관찰자의 대상을 Subject라고 한다.

CPP 생성자에서의 콜론 : 초기화 리스트, default 생성자가 없을 때 씀

깊은 복사, 얕은 복사 : 얕은복사는 해당 메모리 주소를 같이 쓰고, 깊은 복사는 참조 공유 안함

상속과 구성에 따른 차이 : 상속은 클래스에 코드 작성시 기능 추가가 가능하고, 구성은 객체에 실행 시간에 기능 추가가 가능
상속은 경직되고, 유연성이 부족하지만 구성은 유연성이 뛰어나다.

Adapter Pattern : 클래스의 인터페이스를 사용자가 기대하는 인터페이스로 변환하는 패턴, 호환성이 없는 인터페이스때문에 함께 동작할 수 없는 클래스들이 함께 동작하도록 한다. 기존 클래스를 재사용할 수 있도록...

Proxy Pattern : 어떤 객체를 사용하고자 할 때, 객체를 직접적으로 참조하는 것이 아니라 해당 객체를 대행하는 객체를 통해서 원하는 객체가 메모리에 존재하지 않아도, 기본적인 정보를 참조하거나 설정할 수 있고 객체의 생성을 미룰 수 있다.

facade Pattern : SDK개발들이 이것을 많이 사용하지 않을까? 인터페이스를 단순화시키기 위해서 인터페이스를 변경한다.

Bridge Pattern : 구현부에서 추상층을 분리하여 각자 독립적으로 변형이 가능하고, 확장이 가능하도록 하는 것. 기능과 구현에 대해 두 개를 별도의 클래스로 구현

PIMPL : Pointer to IMPlementation으로, 포인터를 활용해 선언부에서 데이터 구현 세부를 감추는 프로그래밍 방법

한줄 요약

인터페이스의 변경은 Adapter, 대행자는 Proxy, 서브시스템의 복잡한 과정을 감추기 위해 Pacade, Update를 독립적으로 수행하기 위해 Bridge.

Visitor Pattern : 모든 요소를 두배로 만들고 싶어! 할 때, 객체 구조에 속한 요소에 수행할 오퍼레이션을 정의할 객체, 클래스를 변경하지 않고도 새로운 오퍼레이션을 정의할 수 있게 해줌. 모든 요소를 방문자에게 전달해서 직접 처리하는 것(트와이스 비지터, 트리플비지터)

Singleton : 클래스를 디자인 할 떄, 사용자가 오직 하나밖에 만들 수 없게 보장하고 이에 대한 접근은 어디에서든지 하나로만 통일하여 제공

Factory Method Pattern : 부모클래스에 알려지지 않은 구체 클래스를 생성하는 패턴. 자식이 어떤 객체를 생성할 지 결정하도록 하는 패턴이다. 객체를 생성해서 결과값이 객체인 것.

Builder Pattern : 지원서 객체는 다양한 형태로 생성될 수 있었는데, 이름, 전화번호, 주소로 되어 상황에 따라 Raw text, html, XML방식으로 만들어야 했지. => Builder Interface를 만들어서 어떻게 만들지 constructor가 결정하는게 아닌 빌더에게 맡기는 것.