I. 재사용성과 유지보수 향상을 위한, 객체지향 설계 5대 원칙의 개요
가. 재사용성을 극대화 하는 객체지향 설계의 개념
- 소프트웨어 개발 및 유지보수성 향상을 위한 설계관점의 기본원칙
- 코드를 좀더 유지보수하기 쉽고, 유연하고, 확장하기 쉽게 만들기 위한 설계
나. 객체지향 설계의 특징
- 재 사용성, 유지 보수성, 이식성 통한 생산성 및 품질의 향상
- 모형의 적합성: 현실 세계 및 인간의 사고 방식과 유사
- 일관성, 추적성: 전체 공정에서 각 단계간의 전환과 변경이 자연스럽고 신속함
II. 객체지향 설계 원칙(5대 원칙, SOLID)
가. 단일책임의 원칙(SRP : Single Response Principle)
구분 | 설명 |
정의 | - 시스템의 모든 객체는 하나의 책임만을 가지며, 객체가 제공하는 모든 서비스는 그 하나만의 책임만을 수행해야 한다는 설계 원칙 |
특징 | - 응집도 향상으로 유지보수성 향상 - 하나의 책임만을 수행하기 때문에 변화에 적응도 높음 -두 개 이상의 책임을 가지면, 온전한 책임을 다할 수 있도록 분리 |
예시 | ![]() |
예시 설명 | - (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)처럼 변화에 따른 충격에서 자유롭도록 추상 클래스를 만들고 그 추상 클래스와 상속 관계를 유지하도록 설계 |
II. 객체 지향 설계의 향후 전망 및 실무 적용 시 고려 되어야 될 사항
가. 적용 방법론과 기술적 측면에서의 향후 전망
측면 | 내용 |
방법 | -소프트웨어 개발이 복잡, 다양해 짐으로 Prototype을 개발하여 위험 요인 사전 제거 활동 필요 -웹 개발 환경의 보편성으로 유사 반복 내용에 대한 디자인 패턴 개발 적용 및 소프트웨어 시스템 관점으로 접근하고 있음 -개발의 생산성을 위해 Case도구 및 Repository를 환경을 토대로버전 및 형상 관리를 위한 자동화 추세 |
기술 | -최근 프로그래밍 언어가 분산 객체 환경을 지원하는 웹 서비스가 가능한 플랫폼 지원 -객체 지향 기술은 기업 비즈니스 또는 산업 차원에서소프트웨어 재사용성을 높이기 위해 CBD 프로젝트가 활성화 될 전망임 |
나. 객체 지향 기술 적용 시 고려 되어야 할 항목
항목 | 내용 |
프로젝트 착수 시 | -프로젝트 착수 시에 객체지향은 재사용에 대한 규모 산정, 재사용 체계 구축에 대한 계획 수립 및 활용도 측면에서의 고려 필요 |
프로젝트 수행 시 | -분석/설계 시에 클래스의 책임과 역할 분석을 위한 CRC (Candidate, Responsibility, Collaboration)카드 작성 -재사용성을 극대화 하기 위한 Design Pattern 활용 |
유지보수 수행 시 | -재사용 컴포넌트 관리와 프로세스(기능)과 연계 관리가 필요 -컴포넌트의 조립으로 결합 컴포넌트 생성 |
'2. 소프트웨어 공학 > 소프트웨어 분석 및 설계' 카테고리의 다른 글
CBAM(Cost Benefit Analysis Model) (0) | 2022.10.17 |
---|---|
객체 지향 설계 원칙 (0) | 2022.07.23 |
객체지향 설계원칙 (0) | 2022.07.23 |