🐹 10. Object Oriented Design

07. 객체 지향 설계

[ 접근법 ]

단계 #1: 모호성의 해소

객체 지향 설계(OOD) 관련 문제들은 대게 고의적으로 모호성을 띄고 있다. 왜냐하면 면접관들은 스스로 가정을 만들어내고 질문을 통해 명확히 해나가는 과정을 살펴보고 싶어하기 때문이다. 결국, 무엇을 개발해야 하는지 이해하지 못한 상태에서 코딩부터 시작하는 개발자는 회사의 시간과 돈을 낭비하며, 그보다 더 심각한 문제들을 만들어 낸다.

객체 지향 설계에 관한 질문을 받으면, 아래에 대한 질문을 던져야 한다.

→ 누가 그것을 사용할 것이며

→ 어떻게 사용할 것인지

질문에 따라서는 육하원칙에 따른 질문을 던져야 할 때도 있다. 누가, 무엇을, 어디서, 언제, 어떻게, 왜.

ex) 커피 메이커에 대한 객체 지향적 설계를 한다고 해보자.

커피 메이커는 시간당 수백 명의 고객을 상대하며 열 가지 이상의 제품을 만들어 내야 하는, 대규모 식당에 설치되는 기계일 수도 있다. 혹은 나이 드신 분들이 사용하는, 블랙 커피만 만드는 간단한 기계일 수도 있다. 어떤 용도로 쓰이느냐에 따라 설계 자체가 완전히 뒤바뀐다.

단계 #2: 핵심 객체의 설계

이제 무엇을 설계할 것인지 이해했으니, 시스템에 넣을 ‘핵심 객체’(core object)가 무엇인지 생각해 봐야 한다.

ex) 식당을 객체 지향적으로 설계한다고 해보자.

이때 핵심 객체로는 Table, Guest, Party, Order, Meal, Employee, Server, Host 등이 있을 수 있다.

단계 #3: 관계 분석

핵심 객체를 어느 정도 결정 했다면, 이제 객체 사이의 관계를 분석해야 한다.

→ 어떤 객체가 어떤 객체에 속해 있는가(member)?

→ 다른 객체로부터 상속(inherit) 받아야 하는 객체는 있나?

→ 관계는 다-대-다(many-to-many) 관계인가 아니면 일-대-다(one-to-many) 관계인가?

가령, 식당 문제에선 다음과 같이 설계해 볼 수 있다.

• Party는 Guests 배열을 갖고 있어야 한다.
• Server와 Host는 Employee를 상속받는다.
• 각 Table은 Party를 하나만 가질 수 있지만, 각 Party는 Tables를 여러 개 가질 수 있다.
• Restaurant에 Host는 한 명 뿐이다.

여기서 주의할 점은, 종종 잘못된 가정을 만들어 사용하는 경우가 있다는 것이다.

예를 들어, 하나의 Table에 여러 Party가 앉는 경우가 있을 수도 있다(요즘 많이 사용되고 있는 대형 공동 테이블(communal table)이 그런 경우이다). 설계가 얼마나 일반적이어야 하는지에 관해서는 면접관과 상의한 후 결정하는 것이 좋다.

단계 #4: 행동 분석

여기까지 왔다면 객체 지향 설계의 골격은 어느 정도 잡힌 상태일 것이다. 이제 남은 일은 객체가 수행해야 하는 핵심 행동(core action)들에 대해서 생각하고, 이들이 어떻게 상호작용해야 하는지 따져 보는 것이다. 그러다 보면 깜빡 잊은 객체가 있을 수도 있고, 상황에 따라 설계를 변경해야 할 수도 있다.

ex) 한 Party가 Restaurant에 입장하고, 한 Guest가 Host에게 Table을 부탁한 경우

Host는 Reservation을 살펴본 다음 자리가 있으면 해당 Party에게 Table을 배정할 것이다. 자리가 없다면 Party는 Reservation 리스트 맨 마지막에 추가될 것이다. 한 Party가 식사를 마치고 떠나면 한 Table이 비게 되고, 그 테이블은 리스트의 맨 위 Party에게 할당될 것이다.

[ 디자인 패턴 ]

싱글톤(singleton)이나 팩터리 메서드(factory method)와 같은 디자인 패턴을 살펴본다.

계속해서 특정 문제에 ‘가장’ 적합한 디자인 패턴을 찾으려는 함정에 빠지지 않도록 조심하라. 필요하다면 그 문제에 적합한 디자인을 직접 만들면 된다. 특별한 경우에는 이미 만들어진 패턴이 적합할 수도 있겠지만, 많은 경우에는 그렇지 않다.

싱글톤 클래스(singleton class)

싱글톤 패턴(singleton pattern)

어떤 클래스가 오직 하나의 객체만을 갖도록 하며, 프로그램 전반에 걸쳐 그 객체 하나만 사용되도록 보장

→ 정확히 하나만 생성되어야 하는 전역 객체(global object)를 구현해야 하는 경우에 특히 유용

ex) Restaurant 클래스는 정확히 하나의 객체만 갖도록 구현하는 것이 좋다.

public class Restaurant {
    private static Restaurant _instance = null;
    protected Restaurant() { ... }
    public static Restaurant getInstance() {
        if (_instance == null) {
            _instance = new Restaurant();
        }
        return _instance;
    }
}

많은 사람들이 싱글톤 디자인 패턴을 좋아하지 않고 심지어 ‘안티-패턴’이라고 부르기도 한다. 싱글톤을 싫어하는 이유 중 하나는 싱글톤이 단위 테스트(unit test)에 방해되는 요인이기 때문이다.

팩터리 메서드(factory method)

팩터리 메서드

어떤 클래스의 객체를 생성하기 위한 인터페이스를 제공하되, 하위 클래스에서 어떤 클래스를 생성할지 결정할 수 있도록 도와줌

• 구현 방법
  • 1번째: Factory 메서드 자체에 대한 구현은 제공하지 않고 객체 생성 클래스를 abstract로 선언하고 놔두는 것
  • 2번째: Factory 메서드를 실제로 구현한 Creator 클래스를 만드는 것. 이 경우에는 Factory 메서드에 생성해야 할 클래스를 인자로 넘겨줘야 한다.

    public class CardGame {
        public static CardGame createCardGame(GameType type) {
            if (type == GameType.Poker) {
                return new PockerGame();
            } else if (type == GameType.BlackJack) {
                return new BlackJackGame();
            }
            return null;
        }
    }