객체지향 설계·분석·리팩토링

실기 학습 목표

객체의 책임과 의존 방향을 요구 사례에 대응시킨다.

핵심 이론

객체지향의 추상화는 필요한 특징 선택, 캡슐화는 데이터와 동작을 묶고 내부 접근을 통제, 상속은 타입·구현 확장, 다형성은 공통 계약의 다양한 구현이다.

SOLID: SRP는 변경 이유를 하나로, OCP는 확장에 열고 수정에 닫기, LSP는 하위 타입의 치환 가능성, ISP는 사용하지 않는 기능에 대한 의존 분리, DIP는 고수준·저수준 모두 추상화에 의존하기다.

하위 타입이 상위 계약의 입력 허용 범위를 더 좁히면 LSP를 위반할 수 있다. 의존성 주입은 DIP를 구현하는 방법 중 하나이며 원칙 자체와 구별한다.

럼바우 분석은 객체 모델(정적 구조), 동적 모델(상태·사건), 기능 모델(데이터 변환·DFD)이다. 리팩터링은 외부 동작을 유지하며 내부 구조를 개선한다.

설계 원칙은 무엇 때문에 바뀌는지를 묻는다

SRP는 클래스의 변경 이유를 분리한다. OCP는 새 동작을 확장하면서 기존의 안정된 코드를 자주 고치지 않도록 한다. LSP는 하위 타입을 상위 타입 자리에 넣어도 계약을 지키도록 한다. ISP는 사용하지 않는 메서드에 의존하지 않도록 인터페이스를 나누고 DIP는 구체 구현보다 추상화에 의존하게 한다.

상위 계약이 0 이상의 입력을 허용하는데 하위 타입이 100 미만을 거부하면 기존 호출자가 실패할 수 있으므로 LSP 문제다. 주문 정책이 특정 저장 드라이버를 직접 만들다가 저장 인터페이스를 받게 바뀌면 의존 방향과 추상화가 핵심이므로 DIP를 본다. 인터페이스가 등장했다는 이유만으로 언제나 ISP라고 답하지 않는다.

리팩터링은 외부 관찰 동작을 유지하며 내부 구조를 개선하는 작업이다. 중복 코드 추출과 이름 개선이 대표적이며 새 기능을 추가했다면 그것 자체를 리팩터링으로 부르지 않는다. 럼바우의 객체·동적·기능 모델은 각각 정적 구조·사건과 상태·입출력 데이터 변환을 표현한다. 지문이 어떤 관점을 설명하는지 연결하면 암기량을 줄일 수 있다.

풀이 예시

주문 정책 클래스가 특정 DB 드라이버를 직접 생성하던 구조를 바꿨다. 주문 정책은 저장 인터페이스에만 의존하고, 드라이버 어댑터도 그 인터페이스를 구현하며 외부에서 구현체를 공급한다. 고수준 정책과 저수준 구현 모두 추상화에 의존하게 한 원칙을 쓰시오.

예시 정답

의존성 역전 원칙

풀이 과정

고수준 정책이 저수준 구체 구현에 직접 의존하지 않고 양쪽이 추상화에 의존하도록 방향을 바꾼다. 의존성 주입은 이를 실현하는 방법 중 하나이며 질문의 원칙은 DIP이다.

답안 점검

위 풀이 예시의 답을 가린 뒤, 핵심 이론의 규칙을 적용해 직접 풀어 보세요. 코드와 계산 문제는 중간값·단위·최종 출력의 순서를, 용어 문제는 지문의 핵심 단서와 답의 의미를 점검하세요. 해설과 다른 부분이 있으면 어느 조건을 놓쳤는지 확인하고 연결된 실기 문제로 다시 연습하세요.