객체 지향 ( Object-Oriented )

객체 지향

• 소프트웨어의 각 요소들을 객체(Object)로 만든 후 , 객체들을 조립해서 소프트웨어를 개발하는 기법
• 구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 채택되어 사용되고 있다.
• 구성요소
  • 객체(Object)
  • 클래스(Class)
  • 메시지(Message)
• 특징
  • 캡슐화(Encapsulation)
  • 상속(Inheritance)
  • 다형성(Polymorphism)
  • 연관성(Relationship)

객체 (Object)

• 데이터와 이를 처리하기 위한 함수를 묶어 놓은 소프트웨어 모듈 

클래스 (Class)

• 공통된 속성과 연산을 갖는 객체의 집합
• 클래스에 속한 각각의 객체를 인스턴스(Instance)라고 한다.

메시지 (Message)

• 객체들 간의 상호작용에 사용되는 수단으로, 객체의 동작이나 연산을 일으키는 외부의 요구 사항 

캡슐화 (Encapsulation)

• 외부에서 접근을 제한하기 위해 인터페이스를 제외한 세부 내용을 은닉하는 것 

상속 (Inheritance)

• 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것

다형성 (Polymorphism)

• 하나의 메시지에 대해 각각의 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력

객체 지향 분석 방법론

• Rumbaugh(럼바우) – 분석 활동을 객체 모델, 동적 모델, 기능 모델로 나누어 수행
• Booch(부치) – 미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 사용
• Jacobson – 유스케이스(Use Case)를 강조하여 사용
• Coad 와 Yourdon – E-R 다이어그램을 사용하여 객체의 행위를 모델링
• Wirfs-Brock – 분석과 설계 간의 구분이 없고, 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행

럼바우(Rumbaugh) 분석 기법

• 모든 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링하는 기법
• 객체 모델링 기법(OMT, Object-Model Technique)이라고도 한다.
• 분석 활동은 객체 모델링 > 동적 모델링 > 기능 모델링 순으로 이루어진다.

객체 모델링 (Object Modeling)

• 정보 모델링이라고도 하며, 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정하여 객체 다이어그램으로 표시하는 것

동적 모델링 (Dynamic Modeling)

• 상태 다이어그램을 이용하여 시간의 흐름에 따른 객체들 간의 제어 흐름, 상호 작용, 동작 순서 등의 동적인 행위를 표현하는 모델링

기능 모델링 (Functional Modeling)

• 자료 흐름도(DFD)를 이용하여 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현한 모델링

객체 지향 설계 원칙

• 변경이나 확장에 유연한 시스템을 설계하기 위해 지켜야 할 원칙
• SRP, OCP, LSP, ISP, DIP 의 다섯 가지 원칙의 앞 글자를 따서 SOLID 원칙 이라고 한다.

단일 책임 원칙 (SRP) 

• 객체는 단 하나의 책임만 가져야 한다

개방-폐쇄 원칙 (OCP)

• 기존의 코드를 변경하지 않고, 기능을 추가할 수 있도록 설계해야 한다

리스코프 치환 원칙 (LSP)

• 자식 클래스는 최소한 부모 클래스의 기능은 수행할 수 있어야 한다

인터페이스 분리 법칙 (ISP)

• 자신이 사용하지 않는 인터페이스와 의존 관계를 맺거나 영향을 받지 않아야 한다

의존 역전 원칙 (DIP)

• 의존 관계 성립 시, 추상성이 높은 클래스와 의존 관계를 맺어야 한다 

모듈 ( Module )

결합도 ( Coupling, 낮을 수록 좋음 )

• 데이터(Data Coupling) 결합도 – 모듈 간의 인터페이스가 자료 요소로만 구성될 때의 결합도
• 스탬프(Stamp Coupling) 결합도 – 두 모듈이 동일한 자료구조를 조회하는 경우
• 제어(Control Coupling) 결합도 – 어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어 신호나 제어 요소를 전달하는 결합도
• 외부 결합도(External Coupling) – 어떤 모듈에서 선언한 데이터(변수)를 외부의 다른 모듈에서 참조할 때의 결합도
• 공통(Common Coupling) 결합도 – 여러 모듈이 공통 자료 영역을 사용하는 경우 ( 전역변수 사용 )
• 내용(Content Coupling) 결합도 – 가장 강한 결합도를 가지고 있으며, 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 조회하도록 설계되었을 경우

응집도 ( Cohesion, 높을 수록 좋음 )

• 우연적 응집도(Coincidental Cohesion) – 아무 상관없는 것들을 모아둔 것
• 논리적 응집도(Logical Cohesion) – 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우의 응집도
• 시간적 응집도(Temporal Cohesion) – 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우
• 절차적 응집도(Rrocedural Cohesion) – 모듈이 다수의 관련 기능을 가질 때 모듈 내부의 기능 요소들이 그 기능을 순차적으로 수행할 경우
• 통신적 응집도 (Communication Cohesion, 교환적 응집도) – 동일한 입력과 출력을 사용하는 소작업들이 모인 경우
• 순차적 응집도(Sequential Cohesion)
• 기능적 응집도(Functional Cohesion) – 모듈 내부의 모든 기능 요소들이 한 문제와 연관되어 수행되는 경우 (모듈 응집도 가장 높음)

팬인(Fan-In)

• 어떤 모듈을 제어하는 모듈의 수

팬아웃(Fan-Out)

• 어떤 모듈에 의해 제어되는 모듈의 수

디자인 패턴 ( Design Pattern )

디자인 패턴 ( 생성 패턴 / 구조 패턴 / 행위 패턴 )

• 브릿지 패턴 (Bridge) – 구현부에서 추상층을 분리하여 각자 독립적으로 변형이 가능하고 확장이 가능하도록 한다. 즉 기능과 구현에 대해서 
• 생성 패턴 – 객체의 생성 방식을 결정하는 패턴 / 객체의 생성과 관련된 디자인 패턴으로 객체의 생성과 조합을 캡슐화해 특정 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 유연성을 제공
  • 빌더 패턴(Builder) – 복잡한 인스턴스를 조립하여 만드는 구조로 복합 객체를 생성할 때 객체를 생성하는 방법(과정)과 객체를 구현(표현)하는 방법을 분리함으로써 동일한 생성 절차에서 다양한 표현 결과를 만들 수 있는 디자인 패턴
  • 원형 패턴(Prototype) – 생성할 객체의 종류를 명시하는 데 원형이 되는 예시물을 사용하고 새로운 객체를 이 원형들을 복사함으로써 필요한 부분만 수정하여 사용하는 디자인 패턴
  • 싱글톤 패턴(Singleton) – 전역 변수를 사용하지 않고 객체를 하나만 생성하도록 하며, 생성된 객체를 어디에서든지 참조할 수 있도록 하는 디자인 패턴
  • 추상팩토리 패턴(Abstract Factory) – 구체적인 클래스를 지정하지 않고 관련성이 있거나 독립적인 객체들을 생성하기 위한 인터페이스를 제공하는 디자인 패턴
  • 팩토리 메서드 패턴(Factory Method) – 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스를 생성하도록 하는 디자인 패턴
• 구조 패턴 – 클래스나 객체를 조합해 더 큰 구조를 만드는 패턴 / 서로 다른 인터페이스를 지닌 2개의 객체를 묶어 단일 인터페이스를 제공하거나 서로 다른 객체들을 묶어 새로운 기능을 제공하는 패턴
  • 적응자 패턴(Adapter) – 클래스의 인터페이스를 사용자가 기대하는 다른 인터페이스로 변환하는 패턴으로 호환성이 없는 인터페이스 때문에 함께 동작할 수 없는 클래스들이 함께 작동하도록 해주는 디자인 패턴
  • 브리지 패턴(Bridge) – 기능의 클래스 계층과 구현의 클래스 계층을 연결하고, 구현부에서 추상 계층을 분리하여 추상화된 부분과 실제 구현 부분을 독립적으로 확장할 수 있는 디자인 패턴
  • 데코레이터 패턴(Decorator) – 기존에 구현되어 있는 클래스에 필요한 기능을 추가해 나가는 설계 패턴으로 기능 확장이 필요할 때 객체 간의 결합을 통해 기능을 동적으로 유연하게 확장할 수 있게 해주어 상속의 대안으로 사용되는 디자인 패턴
  • 프록시 패턴(Proxy) – 어떤 다른 객체로 접근하는 것을 통제하기 위해 그 객체의 매니저 또는 자리 채움자를 제공하는 디자인 패턴
  • 퍼사드 패턴(Facade) – 복잡한 시스템에 대하여 단순한 통합된 인터페이스를 제공함으로써 사용자의 시스템 간 또는 여타 시스템과의 결합도를 낮추어 시스템 구조에 대한 파악을 쉽게 하는 디자인 패턴
• 행위 패턴 – 객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴 / 한 객체가 혼자 수행할 수 없는 작업을 여러개의 객체로 어떻게 분배하는지, 또 그러면서 객체 사이의 결합도를 최소화 하는 것에 중점을 두는 방식
  • 상태 패턴(State) – 객체의 내부 상태가 변경될 때 행위 내용이 변경되는 패턴으로, 객체는 자신의 클래스가 변경되는 것처럼 보이게 된다.
  • 옵저버 패턴(Observer) – 객체들 사이에 1 : N 의존관계를 정의하여 어떤 객체의 상태가 변할 때, 의존관계에 있는 모든 객체들에 연락이 가고 내용이 자동적으로 갱신될 수 있게 만드는 디자인 패턴
  • 템플릿 메서드 패턴(Template Method) – 상위 클래스에는 추상메서드를 통해 기능의 골격을 제공하고, 하위 클래스의 메서드에서 세부 처리를 구체화하는 방식으로 코드 양을 줄이고 유지보수를 용이하게 만드는 디자인 패턴
  • 비지터 패턴(Visitor) – 각 클래스 데이터 구조로부터 처리 기능을 분리하여 별도의 클래스를 만들어 놓고 해당 클래스의 메서드가 각 클래스를 돌아다니며 특정 작업을 수행하도록 만드는 패턴으로, 객체의 구조는 변경하지 않으면서 기능만 따로 추가하거나 확장할 때 사용하는 디자인 패턴
  • 미디에이터 패턴(Mediator) – 한 집합에 속해있는 객체들의 상호 작용을 캡슐화하는 객체를 정의하는 패턴. 중재자는 객체들이 직접 서로 참조하지 않도록 함으로써 객체들간의 느슨한 연결을 촉진시키며 객체들의 상호작용을 독립적으로 다양화 시킬 수 있도록 한다.
  • 이터레이터 패턴(Iterator) – 컬렉션 구현 방법을 노출시키지 않으면서도 그 집합체 안에 들어있는 모든 항목에 접근할 방법을 제공하는 디자인 패턴
  • 스트레이트지 패턴(Strategy) – 동일 계열의 알고리즘을 정의하고, 각각 캡슐화하여 이들을 상호작용 가능하도록 만드는 것이다. 알고리즘을 사용하는 사용자로부터 독립적으로 알고리즘이 변경될 수 있도록 하는 디자인 패턴