작성 맥락
이 글은 직접 학습하거나 구현하며 남긴 개인 기술 기록입니다. 참고 자료가 있는 경우 본문에 출처를 남기고, 틀린 부분을 발견하면 수정합니다.
객체지향 방법론 (출제빈도: 상)
빈출태그: 객체 용어, 객체 기술, 디자인 패턴, 럼바우
1. 객체지향 방법론 개요
기본 개념
- 현실의 개체들을 디지털 세계의 객체로 표현
- 특성은 속성으로 표현, 특성과 관련된 기능을 메소드로 표현
장단점
장점:
- 확장성
- 유지보수 용이성
- 개발 속도 상승
- 규모가 큰 프로그램도 무리없이 개발 가능
단점:
- 개발은 쉽지만 객체 자체의 설계가 어려움
- 속도가 느려질 수 있음
2. 객체지향 기술의 구성요소
- 클래스: 객체 타입을 정의하고 구현하는 틀. C언어에선 구조체와 구조체를 연산하는 함수를 묶어서 발전시킨 것
- 객체: 클래스에 의해 구현된 대상들
- 인스턴스: 특정 클래스의 객체
- 메세지: 인터페이스. 요청 메시지를 통해 메소드 수행 시작
- 메소드: 수행해야할 연산을 정의. C언어의 함수와 같음
3. 객체지향 기술
핵심 개념
- 캡슐화: 문제 해결을 위한 속성과 메소드를 묶음. 인터페이스가 단순해지고 재사용이 용이해짐
- 정보은닉: 외부의 영향으로부터 보호하는 것. 캡슐화의 가장 큰 목적이며, 외부로부터 감추는 것
- 추상화: 상위클래스는 하위클래스 구현을 위한 틀을 제공. 현실세계를 보다 자연스럽게 표현
- 상속: 상위 클래스 멤버를 하위 클래스가 물려받도록 하는 것. 재사용하고 확장할 수 있음
- 다형성: 상속된 여러 하위 객체가 서로 다른 형태를 가질 수 있게 함. 오버로딩, 오버라이딩 기술. 둘 이상의 클래스에서 동일한 메세지에 대해 서로 다르게 반응함
4. 객체지향 개발 방법론
럼바우(Rumbaugh)
- 다양한 그래픽 표기법으로 모델링
- 객체, 동적, 기능 모델링 순으로 진행
- 객체모델링(정보모델링): 객체 다이어그램을 활용
- 동적 모델링: 상태, 활동 다이어그램을 활용
- 기능 모델링: 자료 흐름도(DFD)를 활용
기타 방법론
- Booch: 미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 사용
- Jacobson: 시나리오(Use-Case)를 활용
- Coad와 Yourdon: E-R다이어그램을 사용
- Wirfs-Brock: 분석과 설계간 구분이 없음. 고객 명세서를 평가해서 연속적으로 수행
5. 객체지향 설계원칙
- 단일 책임: 하나의 클래스가 제공하는 기능이 하나의 문제만 해결하도록 설계. 낮은 결합도 높은 응집도
- 개방 폐쇄: 확장에 대해서 개방적이며 수정에 대해선 폐쇄적이어야 함
- 리스코프 치환: 하위 클래스는 상위 클래스의 기능이 호환됨. 상위 클래스의 제약사항을 준수해야 함
- 인터페이스 분리: 하나의 포괄적 인터페이스보다 다수의 구체적 인터페이스를 구성. 사용하지 않는 인터페이스 구현하지 않아야 함
- 의존성 뒤집기: 하위클래스의 변경사항이 상위 클래스에 영향을 미치지 않도록 구성
6. 객체지향 테스트
- 스레드 기반 테스트(Thread-Based Testing): 클래스들의 집합을 통합(하향식)해가는 테스트 방식
- 사용-기반 테스트(Use-Based Testing): 클래스들을 독립적으로 검사하고 상위 클래스와 결합(상향식)하는 방식
- 검증과 시스템 테스트: 사용자 요구가 객체에 정확히 반영됐는지 검사
7. 디자인 패턴
개요
- 반복적인 문제를 해결하기 위한 설계 패턴을 일반화
- GoF(Gang of Four)가 제시
- 구현 단계의 문제에 실제로 적용 가능
- 기능 향상이 아닌 문제 해결을 통한 구조 변경, 코드 가독성 등에 집중
구성 요소
- 패턴명과 구분
- 문제 및 배경
- 솔루션
- 사례
- 결과
- 샘플코드
특징
- 구조 파악과 원활한 의사소통
- 개발의 생산성, 효율성, 재사용성, 확장성이 향상됨
- 초기비용이 많이 들고 객체지향 개발에만 사용할 수 있음
생성(Creational) 패턴
- Factorial Method: 상위클래스에서는 인터페이스를 정의하고 하위클래스는 인스턴스를 생성할지 결정
- Abstract Factory: 관련있는 서브클래스를 묶어서 팩토리 클래스로 만들고 객체 생성
- Builder: 복잡한 객체 생성을 단계별로 분류
- Prototype: 새로운 객체를 생성하는 게 아닌 기존의 객체를 복사
- Singleton: 클래스가 오직 하나의 인스턴스만을 가지도록 하는 패턴
구조(Structural) 패턴
- Adaptor: 서로 다른 인터페이스를 가진 클래스를 함께 사용할 수 있도록 함
- Bridge: 복잡하게 설계된 클래스를 기능부와 구현부로 분리하여 연결
- Composite: 객체들의 관계가 트리 구조로 구성되고 단일객체와 복합객체를 동일하게 다룸
- Decorator: 클래스 변경 없이 주어진 상황에 따라 기능을 추가
- Facade: 복잡한 서브시스템을 간편하게 사용하도록 단순화된 인터페이스를 제공
- Flyweight: 메모리 사용량을 최소화하기 위해 데이터 공유를 극대화
- Proxy: 대리자를 통해 접근함으로써 원본 객체의 생성 연기, 원격 제어, 접근 제어 등을 결정
행위(Behavioral) 패턴
- Interpreter: 언어의 문(Statement)를 평가하는 방법을 규정
- Template Method: 상위 클래스에서 알고리즘의 뼈대를 정의하고 하위 클래스에서 구체적인 단계를 정의
- Chain of Responsibility: 문제 해결을 위해 일련의 처리 객체가 순서대로 문제 해결
- Command: 요청을 객체의 형태로 캡슐화하여 복구 취소가 가능하게 함
- Iterator: 내부 구현을 노출시키지 않고 집약된 객체에 접근
- Mediator: 객체간의 통신이 중재자를 통해 이루어져 결합도를 감소
- Memento: 롤백을 통해 객체의 상태를 이전 상태로 되돌리는 기능 제공
- Observer: 객체의 상태 변화를 관찰하고 변화가 있을 때마다 등록된 옵저버에 통지
- State: 객체의 내부 상태에 따라 다른 기능을 수행하는 메소드를 구현
- Strategy: 알고리즘을 별도로 분리(캡슐화)하는 패턴
- Visitor: 알고리즘을 자료구조에서 분리하고 클래스 수정 없이 새로운 알고리즘을 추가
댓글이 보이지 않으면 GitHub에 로그인한 뒤 새로고침해 주세요. 공개 댓글은 로그인 상태에서 더 안정적으로 표시됩니다.