Object - 기초편

Object 강의를 보고 작성한 내용입니다.

자바를 사용하는 이유는 무엇인가요?

자바의 장점은 플랫폼 독립성, 자동 메모리 관리, 풍부한 라이브러리, 객체 지향 지원, 안정성과 보안입니다. 핵심은 한 번 작성한 코드를 다양한 환경에서 안정적으로 실행할 수 있고, 객체 지향 설계를 통해 변경에 비교적 강한 코드를 만들 수 있다는 점입니다.
자바는 소스 코드를 바이트코드로 컴파일하고, JVM이 각 운영체제에 맞게 실행합니다. 그래서 Windows, Linux, macOS 같은 환경 차이를 JVM이 흡수해줍니다.
또한 객체를 힙 메모리에 생성하고, 더 이상 참조되지 않는 객체는 GC가 회수합니다. 개발자가 직접 메모리를 해제하지 않아도 되기 때문에 메모리 관리 부담이 줄어듭니다.
다만 이런 장점들은 책에서 자주 봐도 체감하기 어렵습니다. 특히 객체 지향의 장점은 절차적인 설계의 불편함을 직접 겪어봐야 더 잘 이해되는 것 같습니다.

도메인 분석이란 무엇인가요?

도메인 분석은 소프트웨어로 구현해야 할 요구사항의 범위를 이해하고, 그 안에서 중요한 개념과 관계를 찾는 과정입니다.
도메인은 소프트웨어가 해결하려는 문제 영역입니다. 예를 들어 주문 시스템이라면 회원, 상품, 주문, 결제 같은 개념이 도메인에 포함됩니다.
도메인 분석에서 중요한 것은 개념 사이의 관계도 함께 보는 것입니다. 이때 다중성이라는 개념이 등장합니다. 다중성은 도메인 개념들 사이에 연결 가능한 숫자의 범위를 의미합니다.
도메인을 분석하는 이유는 단순히 문서를 만들기 위해서가 아닙니다. 분석된 도메인은 이후 객체에게 책임을 할당할 때 중요한 재료가 됩니다.

설계란 무엇인가요?

설계는 코드를 배치하는 방식입니다.
같은 기능을 구현하더라도 데이터를 어디에 둘지, 로직을 어느 객체가 처리하게 할지에 따라 코드의 변경 난이도가 달라집니다. 좋은 설계는 기능이 돌아가는 것에서 끝나지 않고, 요구사항이 바뀌었을 때 코드를 쉽고 안전하게 수정할 수 있게 만듭니다.
즉 설계는 "어떻게 동작하게 만들 것인가"뿐만 아니라 "어떻게 변경 가능하게 만들 것인가"까지 포함합니다.

절차적인 설계의 문제점은 무엇인가요?

절차적인 설계의 문제는 데이터와 프로세스를 분리해서 생각하기 쉽다는 점입니다.
절차적인 설계에서는 보통 데이터를 먼저 정의하고, 그 데이터를 사용하는 프로세스를 나중에 설계합니다. 이 방식은 단순한 프로그램에서는 이해하기 쉽지만, 요구사항이 변경되면 데이터와 프로세스가 함께 수정되어야 하는 경우가 많습니다.
예를 들어 여러 프로세스가 같은 데이터를 직접 사용하고 있다면, 데이터 구조가 바뀌는 순간 그 데이터를 사용하는 로직도 연쇄적으로 수정해야 합니다.
이것은 의존성 문제로 이어집니다. A가 B를 사용하면 A는 B에 의존합니다. B가 변경될 때 A도 변경될 가능성이 생깁니다. 절차적인 설계에서는 프로세스가 데이터에 강하게 의존하기 쉬워 변경에 취약해질 수 있습니다.

책임 주도 설계란 무엇인가요?

책임 주도 설계는 객체가 수행해야 할 책임을 중심으로 설계하는 방법입니다.
절차적인 설계가 데이터와 프로세스를 분리한다면, 객체 지향 설계는 데이터와 프로세스를 하나의 객체 안으로 모읍니다. 데이터를 사용하는 로직을 데이터 내부로 이동시키는 것입니다. 이것을 책임의 이동이라고 볼 수 있습니다.
객체는 단순히 데이터를 들고 있는 수동적인 존재가 아닙니다. 객체는 자기 상태를 바탕으로 스스로 판단하고 행동하는 능동적인 존재여야 합니다.
클래스의 인스턴스가 데이터가 될 수도 있고 객체가 될 수도 있다는 말은 이 차이를 의미합니다. 로직이 인스턴스를 수동적으로 다루면 그것은 데이터에 가깝고, 인스턴스가 자기 책임을 수행하면 객체에 가깝습니다.

객체 지향 설계가 필요한 이유는 무엇인가요?

객체 지향 설계가 필요한 이유는 요구사항이 변경될 때 코드를 쉽고 안전하게 수정하기 위해서입니다.
객체 지향 설계의 핵심은 객체 사이의 협력입니다. 먼저 협력에 필요한 행동을 결정하고, 그 행동을 수행할 객체를 선택해야 합니다. 객체를 먼저 만들고 나서 억지로 책임을 끼워 넣는 것이 아니라, 필요한 책임을 먼저 찾는 것이 중요합니다.
또한 클래스 내부에서도 행동을 먼저 생각하고, 그 행동에 필요한 데이터를 나중에 선택해야 합니다. 데이터 중심으로 설계하면 객체가 수동적인 자료구조가 되기 쉽습니다.
정리하면 객체 지향 설계의 원칙은 다음과 같습니다.
1. 협력에 필요한 행동을 먼저 결정하고, 행동에 적합한 객체를 선택한다.
2. 객체의 행동을 먼저 구현하고, 행동에 필요한 데이터를 나중에 선택한다.

책임 주도 설계는 어떤 흐름으로 진행되나요?

책임 주도 설계는 애플리케이션의 기능을 객체들의 책임과 협력으로 바꾸는 과정입니다.
흐름은 다음과 같습니다.
1. 애플리케이션이 제공할 기능을 파악한다.
2. 기능 요구사항을 시스템의 책임으로 변환한다.
3. 시스템의 책임을 객체의 책임으로 변환한다.
4. 책임을 담당할 적절한 객체를 선택한다.
5. 객체가 혼자 처리할 수 없다면 다른 객체에게 도움을 요청한다.
6. 이 요청을 또 다른 객체의 책임으로 변환한다.
7. 그 책임을 담당할 객체를 선택한다.
여기서 중요한 것은 문맥입니다. 애플리케이션의 기능이 협력을 위한 문맥을 제공하고, 협력이 책임을 위한 문맥을 제공합니다.
즉 책임은 혼자 존재하지 않습니다. 어떤 기능을 수행하기 위한 협력 안에서 책임이 결정됩니다.

도메인 모델은 왜 필요한가요?

도메인 모델은 도메인에서 중요한 개념과 관계를 단순화한 모델입니다.
객체 지향 설계에서는 도메인 모델을 설계의 재료로 사용합니다. 도메인에 존재하는 개념을 코드에서도 비슷하게 표현하면, 요구사항과 구현 사이의 거리가 줄어듭니다.
이 거리를 표현적 차이라고 합니다. 표현적 차이는 도메인에 대한 개념적 모델과 소프트웨어 구현 사이의 거리입니다.
표현적 차이가 작을수록 코드를 읽을 때 도메인 개념을 이해하기 쉽고, 요구사항 변경도 코드에 반영하기 쉬워집니다.

GRASP란 무엇인가요?

GRASP는 객체에게 책임을 할당할 때 사용할 수 있는 일반적인 원칙들의 집합입니다.
GRASP는 General Responsibility Assignment Software Pattern의 약자입니다. 객체 지향 설계에서 "이 책임을 어떤 객체에게 줘야 하지?"라는 질문에 대한 기준을 제공합니다.

Information Expert란 무엇인가요?

Information Expert는 책임을 수행하는 데 필요한 정보를 가장 많이 알고 있는 객체에게 책임을 할당하라는 원칙입니다.
객체가 어떤 일을 하기 위해 필요한 정보를 이미 가지고 있다면, 그 객체가 그 일을 처리하는 것이 자연스럽습니다. 이렇게 하면 불필요하게 데이터를 외부로 꺼내지 않아도 되고, 캡슐화도 지킬 수 있습니다.

Creator란 무엇인가요?

Creator는 객체 생성 책임을 누구에게 줄지 판단하는 원칙입니다.
B가 A를 포함하거나 참조하거나, A를 기록하거나, A를 긴밀하게 사용하거나, A를 초기화하는 데 필요한 정보를 알고 있다면 B에게 A 생성 책임을 줄 수 있습니다.
객체 생성도 책임입니다. 아무 곳에서나 `new`를 호출하는 것이 아니라, 어떤 객체가 생성 책임을 가지는 것이 자연스러운지 판단해야 합니다.

Low Coupling이란 무엇인가요?

Low Coupling은 객체 사이의 의존성을 낮게 유지하라는 원칙입니다.
결합도가 높으면 한 객체의 변경이 다른 객체로 쉽게 전파됩니다. 반대로 결합도가 낮으면 변경의 영향 범위를 줄일 수 있고, 재사용성도 높아집니다.
책임을 할당할 때는 단순히 기능이 동작하는지만 보면 안 됩니다. 이 책임 배치가 전체 설계의 결합도를 높이는지 낮추는지도 함께 봐야 합니다.

High Cohesion이란 무엇인가요?

High Cohesion은 서로 관련 있는 책임을 하나의 객체에 모으고, 관련 없는 책임은 분리하라는 원칙입니다.
응집도는 한 요소의 책임들이 얼마나 강하게 관련되어 있는지를 의미합니다. 응집도가 높은 객체는 변경 이유가 명확합니다. 반대로 너무 많은 일을 하는 객체는 변경 이유가 여러 개가 되고, 수정하기 어려워집니다.
좋은 객체는 연관성 높은 책임을 가지면서도 너무 많은 일을 하지 않는 객체입니다.

Polymorphism이란 무엇인가요?

Polymorphism은 같은 메시지를 보냈을 때 객체 타입에 따라 서로 다르게 동작하게 하는 원칙입니다.
타입에 따라 행동이 달라져야 할 때 조건문으로 분기할 수도 있습니다. 하지만 조건문이 늘어나면 새로운 타입이 추가될 때마다 기존 코드를 수정해야 합니다.
다형성을 사용하면 변하는 행동을 각 타입에게 책임으로 할당할 수 있습니다. 클라이언트는 구체 타입을 몰라도 같은 메시지를 보내고, 실제 동작은 객체가 결정합니다.

Protected Variations란 무엇인가요?

Protected Variations는 변화가 예상되는 지점을 안정적인 인터페이스나 추상화로 감싸는 원칙입니다.
소프트웨어에서 변경은 피할 수 없습니다. 중요한 것은 변경이 발생했을 때 그 영향이 다른 요소로 퍼지지 않게 막는 것입니다.
변할 가능성이 높은 부분을 식별하고, 그 주변에 안정적인 경계를 만들면 변경의 영향 범위를 줄일 수 있습니다.

Indirection이란 무엇인가요?

Indirection은 직접 의존을 피하기 위해 중간 객체를 두는 원칙입니다.
두 객체가 직접 의존하면 한쪽의 변경이 다른 쪽에 영향을 주기 쉽습니다. 이때 중간 객체가 조정 역할을 하면 의존성을 낮출 수 있습니다.
대표적으로 컨트롤러, 서비스, 어댑터 같은 객체들이 간접화 역할을 할 수 있습니다.

Pure Fabrication이란 무엇인가요?

Pure Fabrication은 도메인 개념에는 없지만, 낮은 결합도와 높은 응집도를 위해 인위적으로 만드는 객체입니다.
모든 책임을 도메인 객체에게만 할당하면 오히려 응집도가 낮아질 수 있습니다. 이때 도메인 개념을 직접 표현하지 않더라도, 특정 책임을 깔끔하게 분리하기 위해 별도의 객체를 만들 수 있습니다.
예를 들어 Repository, Service 같은 객체가 여기에 해당할 수 있습니다.

Controller란 무엇인가요?

Controller는 UI 계층을 통해 들어온 시스템 오퍼레이션을 가장 먼저 받아 조정하는 객체입니다.
컨트롤러는 실제 비즈니스 로직을 모두 처리하는 객체라기보다, 요청을 받아 적절한 객체에게 작업을 위임하고 전체 흐름을 조정하는 역할에 가깝습니다.
즉 워크플로우를 표현하는 객체에게 책임을 할당하는 패턴입니다.

책임 주도 설계의 핵심 구성 요소는 무엇인가요?

책임 주도 설계의 핵심 구성 요소는 역할, 책임, 협력, 메시지입니다.
역할은 협력 안에서 책임을 수행하는 대상입니다. 하나의 객체일 수도 있고, 여러 객체가 대체할 수 있는 슬롯일 수도 있습니다.
책임은 객체가 협력하기 위해 알아야 하거나 수행해야 하는 것입니다.
협력은 한 객체가 다른 객체에게 메시지를 보내 도움을 요청하고 응답을 받는 과정입니다.
메시지는 객체 간 협력을 위한 커뮤니케이션 수단입니다. 객체 지향에서 중요한 것은 객체가 어떤 데이터를 가지고 있는지가 아니라, 어떤 메시지를 주고받으며 협력하는지입니다.

의존성 주입이란 무엇인가요?

의존성 주입은 객체가 의존하는 객체를 외부에서 전달받는 방식입니다.
컴파일 타임 의존성과 런타임 의존성 사이의 차이를 해결하기 위해 사용합니다. 코드에서는 추상 타입에 의존하고, 실제 실행 시점에는 외부에서 구체 객체를 넣어줄 수 있습니다.
이를 통해 객체가 직접 구체 클래스를 생성하지 않아도 되고, 테스트와 확장이 쉬워집니다.

좋은 설계는 어떻게 평가하나요?

좋은 설계는 응집도가 높고, 결합도가 낮고, 캡슐화를 지키는 설계입니다.
설계를 평가할 때는 변경의 관점으로 봐야 합니다. 지금 코드가 예쁜지보다, 요구사항이 바뀌었을 때 어디를 얼마나 수정해야 하는지가 중요합니다.
응집도는 변경의 시점과 이유가 같은 책임들이 함께 모여 있는지를 봅니다. 이는 SRP와 연결됩니다.
결합도는 변하는 것에 의존하고 있는지를 봅니다. 변하기 쉬운 구현에 강하게 의존하면 변경에 취약해집니다.
캡슐화는 변경될 수 있는 부분을 외부에 감추는 것입니다. DIP, LSP, OCP 같은 원칙도 결국 변경에 강한 구조를 만들기 위한 기준으로 볼 수 있습니다.

상속보다 합성을 선호하는 이유는 무엇인가요?

상속은 컴파일 타임에 자식 클래스가 부모 클래스에 강하게 결합된다는 한계가 있습니다.
부모 클래스의 구현이 바뀌면 자식 클래스가 영향을 받을 수 있고, 상속 계층이 깊어질수록 변경의 영향도 커집니다.
반면 합성은 객체를 참조로 연결합니다. 필요한 기능을 다른 객체에게 위임할 수 있고, 런타임에 조합을 바꾸기도 쉽습니다.
그래서 단순한 코드 재사용을 위해 상속을 사용하는 것은 위험할 수 있습니다. 상속은 "is-a" 관계가 명확할 때 사용하고, 기능 조합이나 변경 가능성이 크다면 합성을 먼저 고려하는 것이 좋습니다.

Composite 패턴은 언제 사용하나요?

Composite 패턴은 협력하는 객체의 개수를 캡슐화할 때 사용합니다.
개별 객체와 객체 집합을 동일하게 다뤄야 할 때 유용합니다. 예를 들어 파일과 폴더, 메뉴와 메뉴 그룹, UI 컴포넌트 트리 같은 구조에서 사용할 수 있습니다.
클라이언트 입장에서는 단일 객체인지 여러 객체의 묶음인지 크게 신경 쓰지 않고 같은 메시지를 보낼 수 있습니다.

객체 지향 설계 학습을 통해 정리한 결론은 무엇인가요?

객체 지향 설계는 단순히 클래스를 많이 만드는 방식이 아니라, 변경에 강한 협력 구조를 만드는 방식입니다.
기존에도 객체 지향적으로 코드를 작성한다고 생각했지만, 왜 그렇게 설계해야 하는지에 대한 근거는 부족했습니다. 이번 학습을 통해 객체 지향 설계의 목적이 "변경에 강한 코드"를 만드는 데 있다는 점을 다시 정리할 수 있었습니다.
물론 절차적인 설계가 항상 나쁜 것은 아닙니다. 단순한 문제에서는 절차적인 코드가 더 읽기 쉽고 빠를 수 있습니다. 결국 중요한 것은 상황에 맞는 trade-off를 판단하는 것입니다.
요즘은 단순히 코드를 작성하는 것보다, 내가 왜 이렇게 설계했는지 설명할 수 있는지가 더 중요하다고 느끼고 있습니다. 탄탄한 기초와 이론 없이 감으로만 코드를 작성하면 성장하기 어렵습니다.
그래서 앞으로는 기능을 구현하는 것에서 끝내지 않고, 변경 가능성, 책임 분배, 의존성 방향까지 함께 고민하는 습관을 들이려고 합니다.