Chapter07. 여채현 (끝~~~~!!)

[1000hyehyang]

드디어 마지막 장이다. 지금까지 객체지향 설계의 이론과 예시들을 머리로 배워왔다면, 7장은 그 모든 개념들을 직접 코드에 녹여보는 ‘실전’의 단계다. 그리고 이 마지막 장에서 저자는 객체지향 설계에서 바라보는 세 가지 관점을 소개하며, 다시 1장에서 다뤘던 ‘커피 공화국’ 예제를 통해 그 관점을 어떻게 코드로 구현하는지 보여준다.

🧠 객체지향 설계의 세 가지 관점

객체지향 설계에서 클래스를 바라보는 세 가지 방식이 존재한다. 개념 관점, 명세 관점, 구현 관점이다.

• 개념 관점(Conceptual Perspective)
  도메인 모델의 개념을 그대로 반영하는 단계다. 커피 전문점이라는 현실 세계를 소프트웨어 안에서 그대로 모사한다. 객체 간의 포함 관계, 연관 관계 등 현실의 구조와 흐름을 그대로 옮긴다. 사용자의 관점, 도메인의 시선이 주가 되는 영역이다.

• 명세 관점(Specification Perspective)
  이제 초점은 소프트웨어 쪽으로 넘어온다. 각 객체가 ‘무엇’을 할 수 있는지, 어떤 메시지를 주고받을 수 있는지에 관심을 둔다. 바로 ‘인터페이스’에 대한 설계가 이 관점에서 결정된다. 구현은 드러나지 않는다. 이 단계에서 인터페이스와 구현을 분리해두지 않으면, 이후 유지보수가 지옥이 된다.

• 구현 관점(Implementation Perspective)
  마지막으로, 실제 동작하는 코드들을 작성하는 단계다. 객체의 책임을 ‘어떻게’ 수행할 것인가에 초점이 맞춰진다. 메서드, 필드, 로직 등 객체의 내부가 구현되지만, 이 내부 구현은 외부에 영향을 끼치지 않아야 한다. 내부는 언제든 바뀔 수 있고, 외부는 그 변화로부터 안전해야 한다.

이 세 가지 관점을 통해 우리는 같은 클래스도 서로 다른 관점에서 세 번 설계하게 된다. 그만큼 객체지향에서의 ‘관점’은 단순한 시선이 아니라, 구조를 이끄는 핵심 설계 도구다.

☕ 커피 전문점 예제로 본 객체 협력의 흐름

1장의 커피 공화국 예제로 돌아와서, 객체지향 설계를 풀어본다.

도메인엔 네 개의 주요 객체가 있다:

• 손님
• 메뉴판
• 메뉴 항목
• 바리스타

이 네 객체는 하나의 주문이라는 협력을 중심으로 움직인다.

• 메뉴판은 여러 개의 메뉴 항목을 ‘포함’하고 있고 (합성 관계)
• 손님은 메뉴판을 알고 있어야 하며 (연관 관계)
• 손님은 메뉴판에서 메뉴 항목을 고른 뒤
• 바리스타에게 커피를 제조하라고 요청한다.

여기서 중요한 건, 누가 어떤 메시지를 주고받는지가 객체 설계의 출발점이라는 점이다.
“커피를 주문하라” → 이 메시지는 손님이 발신한다.
“메뉴 항목을 찾아라” → 이 메시지는 메뉴판이 응답한다.
“커피를 제조하라” → 이 메시지는 바리스타가 책임진다.

즉, 객체의 책임은 개발자가 결정하는 게 아니라, 메시지가 객체를 선택한다는 사고 전환이 핵심이다. 메시지가 먼저 오고, 그 메시지를 누가 처리할지를 ‘설계’하는 게 객체지향 설계의 본질이다.

🧩 인터페이스를 먼저, 구현은 나중에

협력을 설계하면 자연스럽게 객체의 인터페이스가 만들어진다. 이 인터페이스를 기준으로 객체들이 서로 협력한다.

중요한 건, 인터페이스는 객체의 안정적인 측면이고,
구현은 가장 자주 바뀔 수 있는 불안정한 측면이라는 점이다.
따라서 구현을 외부에 드러내선 안 되며, 인터페이스는 항상 ‘불변’처럼 유지되도록 해야 한다.

이를 위해, 예제에서는 손님이 커피를 주문할 때 바리스타와 메뉴판을 직접 알고 있는 대신,
이 객체들을 메소드 인자로 전달받는 방식을 택했다.
이처럼, 구현 단계에서 의존성을 적절히 주입하거나 캡슐화하는 방식은 객체간 결합도를 낮춰주는 좋은 전략이 된다.

정리하며... – 객체지향은 ‘클래스’가 아닌 ‘협력’을 설계하는 것

이 책이 강조하는 메시지는 단 하나다.
“훌륭한 객체를 만드는 것이 목표가 아니라, 훌륭한 ‘협력’을 설계하는 것이 객체지향의 본질이다.”

그동안 나는 객체지향을 단순히 클래스들 간의 관계, 상속과 구성, 캡슐화 같은 기법들의 모음 정도로만 생각했다. 하지만 이 책을 읽고 나서야, 객체지향 설계가 ‘관계’나 ‘형식’이 아니라, ‘역할과 책임의 분배’, **‘메시지를 중심으로 한 협력의 설계’**라는 것을 깨달았다.

특히 좋았던 건, 앞에서 배운 개념을 반복적으로 상기시키면서, 어느 포인트가 중요한지를 저자가 계속해서 각인시켜줬다는 점이다.
그 반복 덕분에, 단순히 읽고 넘기지 않고 머릿속에 깊게 남았다. 왜 객체지향 입문서로 이 책이 추천받는지 알겠더라. (그렇지만 너무 반복해서
지루한 감이 없지않아 있다.)

물론, 마지막 7장에서의 코드 예시는 조금 아쉬운 감이 있다. 너무 정형화된 예제로 ‘설계’라기보단 단순한 코드 구현에 가까워 보여,
실무적인 관점에서 보여줬다면? 하는 아쉬움이 있다. 그냥 책의 논리를 쉬운 상황에 대입한 느낌?

실무적인 관점에서 CRUD로 구현해본다면??

정리했던 객체지향 설계의 세 가지 관점 — 개념, 명세(인터페이스), 구현 — 을 CRUD 시스템에 적용해서 Java 코드로 작성헤보자.

예시는 흔한 게시글(Post) 도메인을 기반으로 할 거고, CRUD = Create, Read, Update, Delete 에 해당하는 기능을 구현할 예정이다.

👓 1. 개념 관점 (Conceptual Perspective)

도메인 모델을 중심으로 객체 간 관계를 설계하는 단계. 여기서는 아래와 같은 객체가 등장한다.

• Post: 게시글 자체 (제목, 내용, 작성자 등)
• PostRepository: 게시글들을 보관하는 저장소 개념
• PostService: 게시글에 대한 행위를 정의 (글쓰기, 조회 등)
• Client: 실제 사용하는 사용자 (메시지를 발신하는 쪽)

🧩 2. 명세 관점 (Specification Perspective)

이제 인터페이스 설계를 중심으로 객체 간 협력을 설계한다. 객체가 무엇을 할 수 있는지, 외부에 제공하는 인터페이스를 정의한다.

// Post.java — 개념 관점에 해당하는 도메인 객체
public class Post {
    private Long id;
    private String title;
    private String content;
    private String author;

    public Post(Long id, String title, String content, String author) {
        this.id = id;
        this.title = title;
        this.content = content;
        this.author = author;
    }

    // getter, setter 생략 (여기선 OOP 설계에 집중)
}

// PostRepository.java — 저장소의 명세 (무엇을 할 수 있는지)
public interface PostRepository {
    void save(Post post);
    Post findById(Long id);
    void update(Post post);
    void deleteById(Long id);
}

// PostService.java — 비즈니스 로직 인터페이스 (명세 관점)
public interface PostService {
    void createPost(Post post);
    Post readPost(Long id);
    void updatePost(Post post);
    void deletePost(Long id);
}

🔧 3. 구현 관점 (Implementation Perspective)

위 명세를 실제 코드로 구현하는 단계다. 인터페이스는 고정되어 있고, 구현체는 바뀔 수 있다는 점을 기억해야 한다.

// InMemoryPostRepository.java — 구현 클래스 (저장소)
import java.util.*;

public class InMemoryPostRepository implements PostRepository {
    private final Map<Long, Post> storage = new HashMap<>();

    @Override
    public void save(Post post) {
        storage.put(post.getId(), post);
    }

    @Override
    public Post findById(Long id) {
        return storage.get(id);
    }

    @Override
    public void update(Post post) {
        storage.put(post.getId(), post); // 덮어쓰기 방식
    }

    @Override
    public void deleteById(Long id) {
        storage.remove(id);
    }
}

// PostServiceImpl.java — 구현 클래스 (비즈니스 로직)
public class PostServiceImpl implements PostService {
    private final PostRepository repository;

    public PostServiceImpl(PostRepository repository) {
        this.repository = repository;
    }

    @Override
    public void createPost(Post post) {
        repository.save(post);
    }

    @Override
    public Post readPost(Long id) {
        return repository.findById(id);
    }

    @Override
    public void updatePost(Post post) {
        repository.update(post);
    }

    @Override
    public void deletePost(Long id) {
        repository.deleteById(id);
    }
}

🧪 실행 예시

// Main.java — 클라이언트 코드 (메시지를 보내는 쪽)
public class Main {
    public static void main(String[] args) {
        PostRepository repository = new InMemoryPostRepository();
        PostService postService = new PostServiceImpl(repository);

        Post post = new Post(1L, "객체지향 설계", "진짜 제대로 배워보자!", "채현");
        postService.createPost(post);

        Post found = postService.readPost(1L);
        System.out.println("읽은 게시글 제목: " + found.getTitle());

        post = new Post(1L, "객체지향 설계 완전 정복", "이제는 CRUD도 객체지향이다!", "채현");
        postService.updatePost(post);

        postService.deletePost(1L);
    }
}

---

관점	설명	예시 코드
개념 관점	도메인과 객체 식별	Post
명세 관점	객체가 ‘무엇’을 할 수 있는가	PostRepository, PostService
구현 관점	객체가 ‘어떻게’ 동작하는가	InMemoryPostRepository, PostServiceImpl

이 구조를 따르니까 인터페이스와 구현을 자연스럽게 분리하게 되고,
나중에 PostRepository를 JDBC나 JPA 기반 저장소로 바꾸더라도
서비스 로직(PostService)은 건드릴 필요가 없다. 그게 객체지향의 진짜 힘이다.