패턴 그리고 객체지향적 코딩의 법칙(문우식) 내용 정리 및 패턴 정리(1)

책을 읽다 보면 너무 객체지향을 찬양하는 듯 하지만, 현재 프로그래밍 기법에 있어서 보편적인 방법이고, 가장 관리하기 편한 방법이기에 객체지향에 관한 책도 많이 나와있지 않을까? 하지만 이렇다 할 프로젝트도 해본 적 없고, 사실 객체지향에 대해 많이 듣기는 했지만 단순히 내가 아는 것은 클래스화하거나, 구현하려는 프로그램에 있어서 필요한 기능을 나누어 구현하는 것을 객체지향적 프로그래밍이라고 알고 있었기에 이 책에 나온 얘기들을 절대 나쁘다고 할 처지가 못 된다. 예전에 이 책을 봤을 때는 전혀 이해가 안되어 그냥 읽다가 포기했던 흔적을 발견했다. 책갈피로 쓰는 포스트 잇이 책 중간쯤에 빳빳하게 그 자태를 드러내고 있었다. 과감히 뜯어내어 다시 처음부터 시작했다.

 이 책을 보기 전에 사실 디자인 패턴에 대해 심도 있게 공부하려고 생각만(!) 하고 있었다. 왠지 디자인 패턴에 맞춰서 프로그래밍을 해야 최고의 프로그래머가 될 수 있고, 멋들어지게 프로그래밍을 하고, 이 소스는 어떤 패턴을 사용하고, 이런 패턴을 썼더니 좀 더 빠르게 돌아가더라 뭐 이러며 자랑을 하기 위한 지식으로 약간은 불순한 동기로 공부를 하려 했는데, 이 책에서는 그런 디자인 패턴이 그렇게 중요하지 않다는 것 책 처음 부분에 쓰여져 있다. 이 책을 읽고 나서 생각해보니, 아마 이 책에 써있을 것이다. 디자인 패턴이라는 것이 이렇게 쓰이면 좀 더 좋더라 이런 것이지, 절대적 진리는 아니라고 생각된다. 다양한 상황 변화와 환경에 맞게 프로그래밍을 해야 하는데 단순히 몇 가지의 디자인 패턴에 딱딱 맞춰 프로그래밍을 하게 되면 아마 유연하지 못한 소스가 될 것 같다는 생각이 든다. 그만큼 자유롭다는 것을 알기에 내가 프로그래밍을 좋아해가고 있는 이유가 될 수 있으니. 그래도 열심히 지하철, 카페에서 졸면서 읽은 책이니 패턴에 관한 정리를 하면 좋을 것 같기에 정리 해놓는다. 그 전에 책 앞부분에 써있는 지저분한 소스를 탄생시키는 대표적인 경우 적어놔야지. 나중에 내 소스를 뒤돌아 볼 기회를 주지 않을까나?

1.      지저분한 소스를 탄생시키는 경우들

A.     무책임한 개발자

B.     Case By Case 로 땜빵하는 코드

C.     소스의 이해 부족으로 인한 잘못된 수정

D.     높은 결합도로 인한 부작용

E.      문서와 다른 소스

F.      “역사적인 이유로~”라며 시작되는 변명

G.     커뮤니케이션의 부족

2.      깨끗한 코드를 작성하기 위한 원칙

A.     다른 개발자들에게 API를 제공한다는 마음으로 개발하라.

B.     남이 봐도 쉬운 코드를 만들어라.

C.     ‘역사적’인 이유를 만들지 말아라.

D.     자신의 코드만 보지 말아라.

E.      기존의 코드와 통일성 있는 코드를 작성하라.

F.      커뮤니케이션 하라.

G.     항상 ‘1년 뒤에 이 소스를 본다면?’ 이라고 생각하라.

H.     리팩토링 하라.

 

그 밖에 앞부분에는 나와 같은 대학생이 놓칠만한 코딩 습관(?) 그런 것에 대한 얘기가 있으니 필요하신 분들은 사서, 혹은 도서관에서 빌려서 보세요.

 

디자인 패턴

1.      팩토리 패턴

A.     서로 관련성이 있거나 책임이 같은 클래스들을 생성해 주는 클래스를 객체 생성 과정 중간에 두어 복잡도를 줄이는 방법이다.

B.     진정한 가치

                i.         클래스 상속 트리가 책임이 명확, 노출된 함수의 형태가 객체지향 언어가 지원하는 다형성에 의해 잘 동작할 수 있을 때

               ii.         책임도 다르고 노출된 함수 형태도 다른데 억지로 팩토리로 묶는다고 효과를 볼 수 없다. (주의사항)

C.     성격이 같은 객체를 생성할 때 구체적인 객체 타임에 따른 생성 부분을 캡슐화시켜서 코드의 복잡도를 줄여준다.

                i.         책에 많이 나오는 얘기인데 공통점 묶기를 통해 객체 트리를 구성하여 팩토리 클래스가 반환할 부모 클래스를 얻을 수 있다.

1.      부모 클래스 작성시 유의 사항: 함수를 묶는 것뿐만 아니라 부모 클래스의 인터페이스를 통해 필요한 모든 기능을 수행할 수 있는지도 면밀히 따져 봐야 큰 효과를 볼 수 있다.

 

2.      추상 팩토리(Abstract Factory) 패턴 – 이른바 관점을 조금 바꾼 팩토리 패턴

A.     이른바 팩토리를 생성하는 팩토리

B.     그림 그리기를 통해 객체를 구분하거나 필요한 기능을 찾아내는 것이 중요함.

C.     기존의 개념보다 더 큰 개념이 보일 경우 과감히 리팩토링해야 한다.

                i.         처음 버튼 하나에 대한 ‘기능 중심의 공통점 묶기’에서 텍스트 박스, 프로그램 바 등 다른 기능이 추가되면 ‘스타일 중심의 공통점 묶기’라는 더 큰 개념에 대한 새로운 개념으로 편입되어야 한다.

D.     목적

                i.         관련성을 가지는 객체의 집합을 생성하는 인터페이스를 제공하는 것이 목적

E.      단점

                i.         팩토리를 사용하는 것은 좋지만 무분별하게 많아지면 그 자체로도 코드의 이해도는 떨어질 수 있다.

3.      팩토리 메소드(Factory Mathod) 패턴

A.     객체 생성에 대한 책임을 자식 클래스로 미루는 방법

                i.         예) 기본 툴바와 동일한 컨트롤을 사용하지만 배치만 다른 툴바 클래스를 만들고 싶다면

1.      CToolbar 클래스를 상속받아 virtual void Build() 함수만 따로 구현해준다.

B.     인터페이스는 부모 클래스에서 정할 수 있지만 구체적인 객체 생성은 보다 적합한 자식 클래스에서 생성하는 것

C.     장점

                i.         객체지향 언어가 제공하는 다형성을 활용하는 좋은 예로 결국 부모 클래스에서는 공통된 인터페이스로 확장되는 클래스들을 일괄적으로 다룰 수 있다.

4.      템플릿 메소드(Template Method) 패턴

A.     함수의 동작 방식의 구조가 부모 클래스에서 정의되고 구체적인 동작 방식은 자식 클래스에서 정의되는 형태

B.     순수 가상 함수

                i.         부모 클래스에서 정의되는 함수는 순수 가상 함수여도 무방하다. 다만 순수 가상 함수일 경우에는 자식 클래스에서 반드시 재정의 해주어야만 한다.

               ii.         위와 같은 이유는 인스턴스를 만들 수 있기 때문에 아무 일도 하지 않는 빈 껍데기 함수를 부모 클래스에서 재정의 해주는 편이 개발하기 쉽다.

              iii.         Hook이라는 개념이 나옴

1.      이벤트의 흐름이 진행될 때 중간에 갈고리를 걸어서 이벤트의 흐름을 자신이 재정의한 코드로 가져오는 개념

C.     상속을 통하여 물리적으로 클래스를 나누는 경우

                i.         자식 클래스에서 원하는 곳에 코드를 넣을 수 없다.

               ii.         자식 클래스에서 원하는 시점에 코드를 넣을 수 없다.

              iii.         그래서 오버라이딩 할 수 있는 함수들을 적절한 시점을 잡아서 정의

1.      부모 클래스의 수정 없이 기능을 확장할 수 있다.

2.      부모 클래스는 동작의 구조를 정의하게 되고 특화된 동작은 자식 클래스가 가지게 됨

5.      빌더(Builder) 패턴

A.     빌더는 객체의 생성과 구성에 모두 관여한다.

B.     객체의 생성과 조립을 하나의 패턴으로 만든다. à 조립 과정에 공통점 묶기를 적용했다.

C.     장점

                i.         복잡한 개체를 만드는 과정만을 추출해 재사용성을 높인 클래스

               ii.         객체 생성 과정을 클래스화하여 객체를 동일하게 생성하는 여러 곳의 코드 중복을 막아 준다.

D.     다른 패턴에서도 중요한 개념이지만, 문제 상황에 딱 맞는 적절한 방법을 찾는 것이 중요하다. à 객체 생성과 관련해 어디서부터 어디까지 공통점 묶기를 할 것인지 범위를 명확히 해야 한다.

6.      싱글턴(Singleton) 패턴

A.     클래스가 오직 하나만 생성되도록 하고 클래스 외부에서의 잘못된 접근 방식을 없애는 방법

                i.         객체지향은 데이터를 잘못된 방식으로 접근하는 것을 원천적으로 차단하려 함. à 버그는 자신도 모르게 일어나기 때문이다.

B.     이 패턴을 사용하면 적절한 접근자를 사용해서 컴파일러가 잘못된 접근을 컴파일 타임에 잡아줄 수 있기 때문이다.

C.     단점

                i.         싱글턴을 사용한다는 의미는 싱글턴 객체가 어디서 생성됐는지 또 누가 생성하는지 명확하지 않다.

1.      하지만 싱글턴으로 만드는 이유는 시스템 종속적인 자원을 만드는 것

2.      따라서 삭제하는 시점은 시스템의 자원을 정리하는 시점

D.     가장 큰 책임: 함부로 접근되어서는 안 되는 자원을 보호하는 것(시스템에 관련된 자원)

                i.         접근을 제어할 필요가 없는 자원을 싱글턴으로 작성할 필요는 없다. 쓸데 없이 객체 접근에 대한 부하만 높이는 꼴이 됨.

7.      프로토타입(Prototype) 패턴

A.     나오게 된 배경

                i.         개체마다 다른 속성을 복사하기 위해 다운 캐스팅을 일일이 한다면 모든 객체마다 어떤 속성값을 복사해 주어야 하는지 일일이 알아야 한다. 이것은 조금만 알기에 위배된다.

1.      다운 캐스팅: 인터넷을 검색해서 내 개인적인 의견으로는

A.     선언한 클래스(구조체)를 다른 함수에 보내고

B.     그 다른 함수에서 다른 정의된 클래스(구조체)로 변경

C.     변경된 클래스(구조체)에 정의된 함수를 이용하는 것.

D.     안 좋은 이유

                                           i.         정상적인 메모리를 깨거나 예외를 발생시킴 à 예외가 발생한다 해도 콜스택, 텀프를 조사해도 문제를 찾을 수 없다.

                                          ii.         최악의 버그를 발생시킴

B.     객체의 원형을 기반으로 자신과 똑 같은 객체를 생성하는 방식.

C.     장점

                i.         추상 팩토리 패턴처럼 객체군을 생성하는 팩토리에 응용하면 효과적일 수 있다.

               ii.         객체를 복제할 때 내부 상태(객체의 속성)를 동일하게 복제하기 때문에 현재 객체의 스냅샷(snap-shot)을 찍는데 활용할 수 있다.