[스터디: 오브젝트] 동적인 협력과 정적인 코드

 

오브젝트 스터디의 마지막 장이다.

마지막 장의 핵심은 설계와 코드와의 관계라고 정리할 수 있다.

 

설계가 코드를 반영하고,
코드가 설계를 반영해야한다.

 

---

 

동적인 협력, 정적인 코드

모든 프로그램은 텍스트로 작성된 코드로 동작한다.

그래서 개발자는 정적인 텍스트를 활용해서 동적인 객체들의 협력을 구현해야한다.

 

정적인 텍스트로 짜여진 코드를 동적인 객체들의 협력으로 바꾸기 위해서는 동적 모델을 기반으로 정적 모델(코드)를 작성해야한다.

 

보통 일반적으로 객체지향 프로그래밍을 설계할때 도메인 모델을 기반으로 설계를 시작한다.

도메인 모델을 바탕으로 설계를 하는 과정을 보면서 어떻게 프로그램을 동적으로 만드는지 알아보자.

 

Monster가 공격하는 게임을 만든다고 가정하자.

현재까지 확정된 Monster의 종류에는 Dragon 과 Troll 이 있다면 일반적으로 아래와 같이 설계할 수 있다.

 

하지만 추후에 엄청나게 많은 Monster가 생성된다면 어떻게 해야할까?

 

위 구조에서는 각각의 Monster 종류마다 새로운 클래스를 추가해줘야 한다.

이 방식이 SOLID 원칙을 깨는 것은 아니지만, 개발자가 반복적인 코드를 작성해야 하기 때문에 매우 비효율적이다.

 

이를 해결하기 위해서는 클래스가 아닌 인스턴스로 인스턴스 타입을 표현하는 방법이 있다.

public class Monster {
    private int health;
    private String name;
    private Skill skill;
    
    public Monster(int health, String name, Skill skill) {
        this.health = health;
        this.name = name;
        this.skill = skill;
    }
    
    public ing getHealth() {
        return health;
    }
    
    public String useSkill() {
        return skill.use();
    }
}

Monster들 마다 다른 특징인 skill은 따로 분리하여 합성을 통해 사용하도록 하고, 공통적인 부분만 Monster에 남기면 새로운 Monster가 추가될 때마다 클래스를 선언할 필요 없다.

 

클래스를 통해 타입을 구분하는 것이 아니라 아래와 같이 인스턴스를 통해 타입을 구분하는 방법이다.

Monster dragon = new Monster(230, "용", new Skill("용은 불을 내뿜는다"));
Monster troll = new Monster(50, "트롤", new Skill("트롤은 곤봉으로 때린다"));

이렇게 인스턴스로 타입을 표현하는 방법을 TYPE OBJECT 패턴이라고 한다.

 

처음 생각한 클래스다이어그램에는 Dragon과 Troll이 존재했지만, 현재의 구조에서는 Dragon과 Troll이라는 클래스는 보이지 않는다.

대신, "용", "트롤"이라는 JSON 데이터를 통해서 도메인에 이를 반영한다.

 

이렇게 도메인 모델은 단순한 클래스 다이어그램이 아니다.

 

도메인의 핵심을 간략하게 단순화 해서 표현할 수 있는 것 중 하나가 클래스 다이어그램일 뿐, 그 형식은 상관없다.

도메인 모델의 핵심은 도메인 안에 존재하는 개념과 관계를 표현하면서, 객체의 행동과 변경에 기반한 코드의 구조를 반영하는 것이지 형식이 중요한 것은 아니라는 것을 기억하자.

 

---

분석모델, 설계모델, 구현모델

분석모델이란?

해결방법에 대한 언급 없이 도메인을 설명하는 모델

 

설계모델이란?

분석모델을 바탕으로 기술적인 관점에서 솔루션을 서술하는 모델

 

구현모델이란?

설계를 바탕으로 실제 구현할 모델

 

도메인 모델을 알반적으로 이렇게 세가지로 구분하긴 하지만, 이를 명확하게 구분하는 것은 어렵고, 좋은 방법도 아니다.

이 세가지가 모두 다른것이 아니라, 한가지 도메인 모델에 세가지가 모두 반영되는 것이 바람직하다.

 

객체지향의 가장 큰 장점은 도메인 모델과 코드가 동일한 형태를 띄는 것이다.

따라서 설계 문서를 그대로 코드로 옮길 수 있고, 코드를 보고 설계 문서를 떠올릴 수 있다.

 

따라서, 객체지향 패러다임 에서는 모든 단계에서 변경이라는 요소를 고려하여 분석하고, 설계하고, 구현해야한다.

그리고 이렇게 설계한 도메인 모델은 코드로도 옮겨져서 코드가 도메인모델을 반영하고, 도메인 모델이 코드를 반영해야한다.

 

---

책을 마치며

드디어 오브젝트 서적을 다 읽었다.

 

오브젝트 책은 객체지향의 사실과 오해에서 개념으로만 설명했던 역할, 책임 협력을 코드로 보여줘서 더 잘 와닿았던 것 같다.

또한 단순하게 자바에서의 객체지향에 대한 개념 뿐만 아니라, 자바에서는 지원하지 않더라도 객체지향을 이해하는데 도움을 주는 개념들까지 알려줘서 객체지향에 대해서 깊게 공부할 수 있었던 책이다.

 

책을 읽으면서 객체지향을 조금 알았다고 생각했는데, 또 다음장을 읽으면 아직 많이 멀었다는 것도 느낄 수 있었다.

14장의 끝부분에서 객체지향 설계를 잘하려면 이를 코드에 직접 적용해봐야 한다는 것이 적혀있었다.

 

내가 이전에 한 해피에이징 프로젝트를 리펙터링 하면서 역할, 책임, 협력에 초점을 맞추어 설계를 해볼 예정이다.

그리고 책에서 조금만 언급되었던 디자인 패턴에 대해서도 공부하고, 이를 적용해 보아야 할 것 같다.

 

책을 일기 전에 객체지향하면 클래스, 상속을 떠올렸었지만, 책을 통해서 객체지향의 다양한 설계 원리와 트레이드오프에 관해 고민할 수 있었다.

이제까지 읽은 책들 중 정말 재밌고 유익하다고 느낀 책이었고, 디자인 패턴을 공부하고 다시 꺼내서 읽어보고 싶다는 생각을 했다.

 

다음에 읽을때는 진정한 객체지향 전문가 되어서 이번에 느끼지 못했던 새로운 것을 배우고 성장하고 싶다.