상 | 객체지향 설계의 원리 | 1. 단일책임의 원칙 ( SRP : Single Response Principle ) [응집도 향상] - 시스템의 모든 객체는 하나의 책임만을 가지며, 객체가 제공하는 모든 서비스는 그 하나만의 책임만을 수행해야 한다는 설계 원칙 2. 개방 폐쇄 원칙 ( OCP : Open Closed Principle) [전략패턴] - 확장에는 열려있고 수정에는 닫혀있어야 한다는 설계 원칙 - Open(클래스 수직관계), Close(클래스 수평관계) 3. 리스코프 치환의 원칙 (LSP :Liskov Substitution Principle) - 부모 클래스의 객체들이 자식 클래스 사용되는 곳에 대체되야한다는 원칙 4. 인터페이스 분리의 원칙 (ISP : Interface Segregation Principle) - 어떤 클래스가 다른 클래스에 종속될 때는 최소한의 인터페이스만을 사용해야 한다는 설계 원칙 5. 의존성 역전의 원칙(DIP/Dependency Inversion Principle) - 높은 레벨의 모듈은 낮은 레벨의 모듈을 의존하면 안되며 서로 추상에 의존해야 한다는 설계 원칙 |
SOLID |
토픽 이름 | 객체지향 설계의 원리 |
분류 | 소프트웨어 > 개발방법론 > 객체지향 설계의 원리 |
키워드(암기) | 객체지향방법론, GoF Design Pattern , SOLID SRP (Single Response Principle), OCP ( Open Closed Principle), LSP (Liskov Substitution Principle), ISP (Interface Segregation Principle), DIP (Dependency Inversion Principle) |
암기법(해당경우) | SOLID |
기출문제
번호 | 문제 | 회차 |
1 | 4. 소프트웨어 재사용성과 유지보수 향상을 위하여 객체지향 설계 5대 원칙을 적용하고 있다. 다음에 대하여 답하시오. 가. 의존성 역전 원칙(Dependency Inversion Principle)을 설명하시오 나. 의존성 주입(Dependency Injection)을 구현하는 3가지 방식을 설명하고 각 방식별 아래의 조건을 고려하여 구현 예시를 작성하시오 |
121.관.2 |
2 | LSP(Liskov Substitution Priciple) | 105.컴.1.2 |
3 | 1. 객체지향 소프트웨어 설계에 많은 도움을 주는 GoF의 디자인 패턴(Design Pattern)영역을 목적과 범위에 따라 분류하고, 분류별 특성을 설명하시오. 또한, 객체지향시스템에서 개발된 기능의 재사용을 위해 사용되는 대표적 기법인 화이트박스 재사용(White-box Reuse), 블랙박스 재사용(Black-box Reuse) 및 위임(Delegation)이 패턴과 어떤 관계가 있는 지 설명하시오. |
104.관.3.1 |
4 | 객체지향기법의 기본원칙을 기술하고, 구조적 기법과 차별화되는 개념을 설명하시오. | 응용98.2 |
5 | 객체지향 언어로 알려진 C++과 JAVA에 대하여 클래스(class) 관점에서 차이점을 설명하시오 |
응용93.2 |
6 | 소프트웨어 개발방법론은 구조적방법론, 정보공학방법론, 객체지향방법론, 컴포넌트기반 방법론의 형태로 발전되어 왔다. 이 중 정보공학방법론의 특징과 의의를 타 방법론과 비교하여 설명하시오. | 관리90.4 |
- 재사용성과 유지보수 향상을 위한, 객체지향 설계 5대 원칙의 개요
- 소프트웨어 개발 및 유지보수성 향상을 위한 설계관점의 기본원칙
- 코드를 좀더 유지보수하기 쉽고, 유연하고, 확장하기 쉽게 만들기 위한 설계
- 재 사용성, 유지 보수성, 이식성 통한 생산성 및 품질의 향상
- 모형의 적합성: 현실 세계 및 인간의 사고 방식과 유사
- 일관성, 추적성: 전체 공정에서 각 단계간의 전환과 변경이 자연스럽고 신속함
- 객체지향 설계 원칙 ( 5대 원칙, SOLID )
구분 | 설명 |
정의 | - 시스템의 모든 객체는 하나의 책임만을 가지며, 객체가 제공하는 모든 서비스는 그 하나만의 책임만을 수행해야 한다는 설계 원칙 |
특징 | - 응집도 향상으로 유지보수성 향상 - 하나의 책임만을 수행하기 때문에 변화에 적응도 높음 - 두 개 이상의 책임을 가지면, 온전한 책임을 다할 수 있도록 분리 |
예시 | ![]() |
예시 설명 | - (a)는 단일책임 원칙을 따르지 않은 클래스로 메서드가 DB관련 메서드들과 비즈니스 관련 메서드들로 구성되어 있음. - 단일책임의 원칙을 지키기 위해 (b)와 같이 각각의 책임을 갖는 두 개의 클래스로 분할 |
- 개방 폐쇄 원칙 ( OCP : Open Closed Principle)
구분 | 설명 |
정의 | - 소프트웨어 Entity(classes, Modules, Function)는 확장에는 열려있고 수정에는 닫혀있어야 한다는 설계 원칙 |
특징 | - 기존 코드의 변경 없이 확장을 통한 코드의 변경을 허용 - 오버라이딩 - 상속을 의미하지만, 크게 유연석 확보 차원의 원리 - 기능의 상속이 아닌 설계의 유연성을 강조 Open(클래스 수직관계), Close(클래스 수평관계) - Strategy 패턴 : 인터페이스 변경은 어려우나 구현은 열려 있음 |
예시 | ![]() |
예시 설명 | - 원칙을 따르지 않고 설계 시, 삼각형, 사각형, 원 등의 면적을 구하려면 (a)와 같이 각 도형의 면적을 구하는 메서드가 하나의 클래스에 모두 존재하게 됨. - 상속의 개념을 적용하여 (b)와 같이 설계하면 클라이언트가 추상클래스에 의존하므로 구체클래스의 내부 변경에 영향을 받지 않음. |
- 리스코프 치환의 원칙 (LSP :Liskov Substitution Principle)
구분 | 설명 |
정의 | 부모 클래스의 객체(타입과 매소드의 집합)들이 자식 클래스 사용되는 곳에 대체될 수 있어야 한다는 설계 원칙 that objects of a superclass shall be replaceable with objects of its subclasses without breaking the application. |
특징 | - 클래스의 생성 목적에 맞게 설계하기 때문에 상/하위 클래스의 호환성 향상 - 하위 클래스는 상위 클래스의 책임을 넘지 않음 - 하위 클래스는 사용자의 요구 사항대로 설계됨. |
예시 | ![]() |
예시 설명 | - LSP를 위배하는 예제 - Introduce를 상속한 DetailIntroduce 클래스가 함수 q가 요구하는 행동을 하지 않고, 엉뚱한 소리를 하고 있음 - 위의 예는 error 클래스를 만들때 주로 나타날 수 있음 - 하위 클래스의 행동 또한 상위 클래스의 책임범위 내에서 생성되어야 함 |
- 인터페이스 분리의 원칙(ISP/Interface Segregation Principle)
구분 | 설명 |
정의 | - 어떤 클래스가 다른 클래스에 종속될 때는 최소한의 인터페이스만을 사용해야 한다는 설계 원칙 |
특징 | - 인터페이스의 단일 책임을 강조 - 하나의 인터페이스에 해당 인터페이스의 목적에 부합되지 않는 기능을 선언하지 않기 때문에 구현 클래스에서 불필요한 기능의 구현 방지 - 소스 레벨의 가독성 향상 |
예시 | ![]() |
예시 설명 | - 클라이언트가 사용하지 않는 인터페이스 때문에 영향을 받아서는 안 된다는 것. - 클래스는 사용자에게 꼭 필요한 메서드만 갖는 인터페이스를 제공 - 인터페이스 분리의 원칙은 (b)처럼 각 클라이언트에 맞는 인터페이스만 분리하여 사용 |
- 의존성 역전의 원칙(DIP/Dependancy Inversion Priciple)
구분 | 설명 |
정의 | - 높은 레벨의 모듈은 낮은 레벨의 모듈을 의존하면 안되며 서로 추상에 의존해야 한다는 설계 원칙 - 클라이언트 변경 최소화를 위해 클라이언트는 구체 클래스가 아닌 인터페이스나 추상 클래스에 의존한다는 설계 원칙 |
특징 | - 구현 클래스에 의존성이 제거하여 낮은 결함도 유지 - 추상화된 클래스에 의존하기 때문에 확장성이 높아져서 유지보수성 향상 |
예시 | ![]() |
예시 설명 | - 의존관계 역전의 원칙은 상속 개념을 적용할 때 (a)와 같이 구체 클래스에서 상속을 받는 구조로 설계하지 말라는 것, 이유는 구체 클래스는 추상 클래스(인터페이스)보다 변하기 쉽기 때문 - 의존 관계를 구체 클래스에서 추상 클래스로 바꾸면 향후 변경에 따른 영향을 최소화할 수 있고, 느슨한 결합도를 유지할 수 있다. - (b)처럼 변화에 따른 충격에서 자유롭도록 추상 클래스를 만들고 그 추상 클래스와 상속 관계를 유지하도록 설계 |
- 객체 지향 설계의 향후 전망 및 실무 적용 시 고려 되어야 될 사항
측면 | 내용 |
방법 | -소프트웨어 개발이 복잡, 다양해 짐으로 Prototype을 개발하여 위험 요인 사전 제거 활동 필요 -웹 개발 환경의 보편성으로 유사 반복 내용에 대한 디자인 패턴 개발 적용 및 소프트웨어 시스템 관점으로 접근하고 있음 -개발의 생산성을 위해 Case도구 및 Repository를 환경을 토대로 버전 및 형상 관리를 위한 자동화 추세 |
기술 | -최근 프로그래밍 언어가 분산 객체 환경을 지원하는 웹 서비스가 가능한 플랫폼 지원 -객체 지향 기술은 기업 비즈니스 또는 산업 차원에서 소프트웨어 재사용성을 높이기 위해 CBD 프로젝트가 활성화 될 전망임 |
- 객체 지향 기술 적용 시 고려 되어야 할 항목
항목 | 내용 |
프로젝트 착수 시 | -프로젝트 착수 시에 객체지향은 재사용에 대한 규모 산정, 재사용 체계 구축에 대한 계획 수립 및 활용도 측면에서의 고려 필요 |
프로젝트 수행 시 | -분석 / 설계 시에 클래스의 책임과 역할 분석을 위한 CRC (Candidate, Responsibility, Collaboration) 카드 작성 -재 사용성을 극대화 하기 위한 Design Pattern 활용 |
유지보수 수행 시 | -재 사용 컴포넌트 관리와 프로세스(기능)과 연계 관리가 필요 -컴포넌트의 조립으로 결합 컴포넌트 생성 |
'정보관리기술사 > 소프트웨어공학' 카테고리의 다른 글
SW Architecture (0) | 2024.03.30 |
---|---|
(외부)EPMO (0) | 2024.03.11 |
객체지향 프로그래밍 특징 (0) | 2024.03.09 |
Architecture (0) | 2024.03.08 |
번다운차트 (0) | 2024.03.07 |