GONI

프로그램에서 객체들은 저마다 수행해야 할 역할이 존재하는데 몇몇 객체들의 경우에는 너무 많은 역할을 수행해야 하거나, 부여된 역할을 수행하기 위해 여러 가지 복잡한 과정을 거쳐야 할 수 있다. 이 같은 경우 그냥 해당 객체가 모든 역할이나 작업을 수행하도록 하면 그 객체의 구현이나 유지, 보수는 굉장히 어려워질 것이다. 반면 실세계의 대리 체제처럼 복잡하거나 다양한 작업을 대신 수행해줄 수 있는 객체를 정의하고 사용한다면 전반적인 구현이나 유지, 보수 등이 오히려 손쉬울 수 있다. 왜냐하면 복잡하고 다양한 작업이 대리 객체에 의해 숨겨질 수 있기 때문이다. 문제 사례 설명 인터넷에서 웹으로 만화 서비스를 제공하는 경우 만화 서비스는 텍스트로 구성된 일반적인 웹페이지에 비해 데이터량이 많은 이미지 파일로 ..

프로그램을 개발하다 보면 크게 두 가지 목적에 '공유'를 고려하게 된다. 하나는 논리적인 관점에서 공유가 필요한 경우고, 다른 하나는 구현 측면에서 컴퓨터 자원을 효율적으로 사용하기 위해 공유가 필요한 경우다. 전자의 대표적인 예로는 데이터베이스나 파일 등의 공유에서처럼 동일한 데이터나 자원을 공유하는 경우를 들 수 있고, 후자의 대표적인 예로는 동일한 값이나 데이터에 대해 포인터 변수 등을 통해 공유를 수행하는 경우를 들 수 있다. 여기서 공유를 수행하는 두 가지 목적 중 논리적 관점에 따른 공유는 보통 논리 모델에 기반해서 공유될 객체가 별도로 정의되기 때문에 이 객체를 잘 사용하는 형태로만 설계를 하면 공유에 따른 문제는 쉽게 해결될 수 있다. 반면, 컴퓨터 자원 사용 효율화를 위한 구현 관점에서의..

객체지향 설계에서는 주로 객체들 사이의 관계와 클래스 구조로 설계 결과를 표현한다. 그러나 이런 표현 방법은 설계하는 시스템이 커질수록 사용하는 객체와 클래스가 많아지기 때문에 한 눈에 설계 결과를 파악하기 힘든 문제를 발생시킨다. 이런 문제를 해결하기 위해서는 객체 여러 개나 클래스를 묶어 하나의 설계 구성 요소로 취급할 수 있는 방법이 필요한데 이를 위해 객체지향 설계에서 제시하고 있는 방법이 서브시스템을 정의하는 것이다. 여기서 서브시스템은 임의로 정의하는 것이 아니라 서로 밀접하게 관련된 객체나 클래스들을 묶고, 이를 추상화(Abstraction)시켜 정의한다. 따라서 서브시스템을 설계의 기본 구성 요소로 활용하게 되면 복잡한 설계 내용도 한 눈에 대강의 뼈대를 파악하는 것이 가능하다. 그러나 서..

문제 사례 설명 게임 프로그램에서 아이템 취득에 따른 기능의 추가나 삭제는 어떤식으로 제공되었을까? 다양한 접근 방법 및 DECORATOR 패턴 다른 종류의 기능 아이템에 대해서는 공격 방향의 추가, 삭제와 비슷하게 설계를 고려해보면 될 것이다. 기본적으로 게임 플레이어가 게임을 시작하면 전방으로만 총을 쏠 있다. 그러다 아이템을 먹으면 전후좌우 모두 공격 할 수 있게 된다. 그러다 실수로 추가 공격 방향 삭제 아이템을 취득하게 되면 초기 상태로 되돌아가 전방 공격만 가능하게 된다. 기본적인 방법: 클래스 재정의를 통한 객체 기능 조정 방법 공격 방향의 추가, 삭제 문제만 놓고 본다면 객체 내부에 공격 방향에 대한 데이터 멤버를 두고, 이 값의 변화에 따라 객체의 공격 방향을 조정해주는 것이 가장 손쉬운..

객체 하나는 객체 여러 개로 구성된다고 할 수 있다. 왜냐하면 객체를 구성하는 데이터 멤버들을 살펴보면 이들 각각이 객체이기 때문이다. 이처럼 객체들간에는 어느 한 객체가 다른 객체를 구성하기 위한 일부분이 되는 관계가 존재하는데 이를 구성(Composition) 관계 또는 부분-전체(Part-Whole) 관계라고 한다. 대부분의 객체에서 이러한 구성 관계 또는 부분-전체 관계는 데이터 멤버를 통해 정적으로(Static) 정의된다. 그러나 때로 우리는 객체 하나를 구성하는 요소들을 동적으로 정의할 필요가 있다. 예를 들어 실행 시간에 객체 여러 개를 그룹핑해서 객체 하나로 정의하고자 할 경우가 여기에 속할 것이다. 이처럼 객체 하나를 구성하는 여러 객체들을 동적으로 정의해서 사용하고자 할 때 어떤 방식으..

객체는 외부에 공개되는 인터페이스와 내부적인 구현으로 이루어진다. 따라서 객체지향 설계는 기본적으로 인터페이스와 구현을 분리한 접근 방법이다. 이처럼 인터페이스와 구현을 독립적으로 분리해서 접근하게 되면 객체를 구현하는 방식이 바뀌더라도 그 객체를 사용하는 프로그램은 수정하지 않아도 되기 때문에 변경의 국지화(Localization of Change), 즉 어느 한 곳의 변경으로 인해 영향을 받는 범위를 한정지을 수 있는 장점을 가진다. 그러나 객체가 가지는 이 같은 장점은 때때로 깨뜨려지는 경우가 있을 수 있다. 예를 들어 하나의 클래스를 여러 가지 플랫폼에서 구현한다고 할 때 플랫폼마다 서로 다른 클래스를 정의하는 것은 이를 사용하는 프로그램이 플랫폼마다 다르게 작성되어야 함을 의미한다. 문제 사례 ..

문제 사례 설명 그래픽 편집기를 만들고 있다고 가정해보자. 모든 형태의 그림을 대표하기 위해 Shape 클래스를 추상 클래스로 정의했다. 그리고 하위 클래스로 각 그림 형태에 따라 Line, Rectangle, Circle 등의 클래스들을 정의했다고 하자. 그런데 선이나 다각형이 아닌 텍스트를 그리거나 편집할 수 있는 기능을 추가로 구현해달라는 요청을 받았다. 이런 요청을 수용하기 위해 텍스트를 그리거나 편집하는 기능 구현을 검토해보았더니 여러 가지 면에서 훨씬 구현이 까다로워서 주어진 개발 기간 내에는 개발을 완료하기가 힘들다는 결론이 났다. 그런데 마침 원하는 기능이 잘 구현된 TextView 클래스 라이브러라 존재한다는 사실을 발견 그러나 막상 TextView 클래스를 사용하려고 보니, 모든 그림을..

객체 생성을 위한 패턴 객체를 생성하는 방식은 크게 두 가지로 구분된다. Client가 직접 생성하는 방식과 다른 객체를 이용해서 간접 생성하는 방식으로 구분된다. 객체를 간접 생성하는 방식도 크게 두 가지가 있을 수 있다. 객체를 생성하기 위해 하위 클래스를 정의해서 사용하는 방식 Factory Method패턴에서처럼 객체를 생성하기 위해 하위 클래스를 정의해서 사용하는 방식이다. 이 방식은 새로운 종류의 객체를 생성하려고 할 때마다 다른 하위 클래스를 정의해야 한다는 단점이 있다. 반면 Factory Method 패턴은 다른 패턴들에 비해 커스터마이징 하기가 쉽다는 장점이 있다. 왜냐하면 Factory Method 패턴의 경우 커스터마이징을 하기 위해서는 새로운 클래스의 정의없이 새로운 연산만 정의하..

생성되는 객체의 최대 개수를 제한하는데 있어서 객체의 생성을 요청하는 쪽에서는 일일이 신경쓰지 않아도 되도록 만들어주는 방법은 어떤 것들이 있는지 알아본다. 문제 사례 설명 게임 개발자는 생성 가능한 유닛의 최대 개수를 제한할 필요가 있다. 왜냐하면 게임에 등장하는 유닛이 너무 많아지면 컴퓨터 자원을 과도하게 사용하게 되고, 이는 게임 전체의 속도를 느리게 만들어 게임에 대한 박진감을 떨어뜨릴 수 있기 때문이다. 더구나 게이머 입장에서는 유닛이 너무 많으면 이들을 일일이 컨트롤하기 힘들기 때문에 게임에 대한 흥미가 반감될 수 있을 것이다. 이처럼 객체를 생성하더라도 최대 N개까지만 객체가 생성되게 제한할 필요가 있는 경우 객체 생성을 제한할 수 있는 방법은 무엇일까? 다양한 접근 방법 및 SINGLETO..

이미 생성된 객체를 복제해서 새로운 객체를 생성 할 수 있다. 문제 사례 설명 그래픽 편집기를 객체지향 개념에 바탕을 두고 설계를 한다면, 문서에 추가되는 각각의 그래픽 요소는 객체로 표현될 수 있을 것이다. 즉, 문서에 새로 끌어다 놓여지는 그래픽 요소 각각이 객체로 생성될 것이고, 문서는 이들을 포함하는 형태가 될 것이다. 여기서 우리가 고민해볼 문제는 각각의 그래픽 요소들이 문서에 추가될 때 어떤 방식으로 객체를 생성해주는 것이 가장 쉬우면서도 추후의 변경 등에 유연하게 대처할 수 있는 형태가 될 것인가라는 점이다. 다양한 접근 방법 및 PROTOTYPE 패턴 주어진 문제를 요약하면, 팔레트에 정의된 그래픽 요소들을 객체로 생성하는 데 있어 가장 바람직한 방법은 무엇인가라는 것이다. 여기서 감안해야..