객체 지향 프로그래밍 (OOP)

객체 지향 프로그래밍 (OOP)

“상태 + 행동”으로 모델링하고, 변경을 격리하는 설계 언어

클래스/상속을 외우는 글이 아니라, 실무에서 변경이 퍼지지 않게 만드는 구조를 기준으로 정리합니다.

정의

객체 단위로 프로그램을 설계하는 방식입니다.

실무에서 코드는 요구사항이 추가되고, 정책이 변경되고, 트래픽이 늘고, 팀원이 바뀌며 계속 바뀝니다.

객체 지향 프로그래밍은 이런 변화 속에서 시스템이 무너지지 않게 만드는 “설계 언어”입니다.

“객체를 쓰는 것” 자체가 아니라, 복잡한 문제를 역할과 책임으로 나눠 변경에 강하고 유지보수 가능한 구조로 만드는 게 목적입니다.

핵심 메시지

변경을 격리하는 기술

핵심 메시지

“객체지향은 기능을 나누는 기술이 아니라,
변경을 격리하는 기술이다.”

- 변경이 퍼지면, 비용이 폭발한다 -

핵심 개념

보통 4가지 핵심 개념으로 설명합니다.

개념	한 줄	설명
캡슐화	숨기고 보호	내부 상태를 직접 건드리지 못하게 하고, 공개된 메서드로만 사용하게 함
추상화	핵심만 드러냄	불필요한 세부사항은 감추고, 중요한 역할/행동만 인터페이스로 제공
상속	재사용	기존 타입의 특성을 물려받아 확장(하지만 실무에선 “남용 주의”)
다형성	교체 가능	같은 인터페이스를 다양한 구현으로 바꿔 끼울 수 있음(확장/테스트에 유리)

💡 TIP / 참고사항

실무에서 “객체지향을 잘한다”는 건 보통 상속을 많이 쓴다가 아니라,
캡슐화 + 다형성(인터페이스) + 역할 분리로 변경을 안전하게 만드는 걸 의미합니다.

본질

객체지향의 핵심은 역할(Role)과 책임(Responsibility)을 객체에 부여하는 것입니다.

“결제” 기능을 구현할 때 모든 로직이 하나의 클래스에 몰리면 변경이 들어올 때마다 전체가 흔들립니다. 반대로 결제 검증, 할인 정책, 결제 수단 같은 책임을 객체로 분리하면, 변경은 해당 객체 내부에 갇히고 나머지 코드에는 파급이 줄어듭니다.

실전 예시

다형성으로 “정책”을 교체하는 구조

// (개념 예시) 할인 정책을 인터페이스로 분리하면
// "할인 방식 변경"이 와도 결제 흐름(Caller)은 거의 안 바뀝니다.

interface DiscountPolicy {
    int discount(int price);
}

class RateDiscountPolicy implements DiscountPolicy {
    public int discount(int price) {
        return (int)(price * 0.1);
    }
}

class FixDiscountPolicy implements DiscountPolicy {
    public int discount(int price) {
        return 1000;
    }
}

class PaymentService {
    private final DiscountPolicy policy;

    PaymentService(DiscountPolicy policy) {
        this.policy = policy;
    }

    public int pay(int price) {
        int discounted = price - policy.discount(price);
        return discounted;
    }
}

// 포인트
// - PaymentService는 "할인 정책이 무엇인지" 몰라도 됨(추상화)
// - 구현체를 교체하면 정책 변경이 가능(다형성)

GOOD / BAD

객체지향이 “살아있는 코드”가 되는 조건

👍 GOOD

• 객체가 “하나의 책임”을 가진다(SRP 느낌)
• 데이터는 숨기고, 행동 중심으로 설계한다
• 변경 포인트는 인터페이스로 분리해 교체 가능하게 한다
• 테스트가 쉬운 구조(주입/Mock 가능)

👎 BAD

• 객체는 데이터만 들고 로직은 서비스 한 곳에 몰림
• 상속으로 모든 걸 해결하려다 깊은 계층 구조가 됨
• if/switch로 타입 분기 남발
• setter 중심으로 외부에서 상태를 막 바꿈

실무 체크

“이 코드가 객체지향인가?”를 빠르게 점검하는 질문

1) 변경이 들어오면 어디가 바뀌나?

한 곳이면 좋고, 여러 곳이면 설계 경계가 새고 있을 가능성이 큽니다.

2) if/switch로 타입 분기하고 있나?

많다면 다형성(인터페이스)으로 바꿀 여지가 큽니다.

3) 테스트하기 쉬운가?

Mock/주입이 어렵다면 결합도가 높을 가능성이 있습니다.

4) 객체가 데이터를 보호하고 있나?

setter로 외부에서 상태를 막 바꾸면 불변 조건이 깨지고 버그가 늘어납니다.

핵심 요약

한 번에 정리

• ✔️ 객체(상태+행동) 단위로 역할/책임을 나눠 변경에 강한 구조를 만든다.
• ✔️ 핵심 개념은 캡슐화·추상화·상속·다형성이며, 실무에선 특히 캡슐화/다형성이 중요하다.
• ✔️ 좋은 객체지향은 변경을 한 곳에 가두고, 테스트가 쉬운 구조로 이어진다.

RELATED POST

다음으로 이어 읽기 좋은 글

DESIGN

SOLID 원칙: “원칙”을 코드 구조로 바꾸는 법

단일 책임부터 의존 역전까지, 실무 리팩터링 기준으로 정리

PATTERN

전략 패턴(Strategy): if/switch를 지우는 가장 빠른 방법

결제/할인/알림 등 변하는 로직을 객체로 분리하기