정보처리기사[실기 핵심 정리] - 객체지향 설계

객체지향(OOP, Object oriented Programming)

1) 객체지향 개념

• 현실 세계의 유형, 무형의 모든 대상을 객체(Object)로 나누고, 객체의 행동(Method)과 고유한 값(Attribute)을 정의하여 설계하는 방법
• 객체를 만들고 조작하여 객체끼리 관계를 맺음으로써 다수의 객체가 함께 수행될 수 있게 한다.

 

2) 객체지향 구성요소

구성요소	설명
클래스 (Class)	● 유사한 종류의 유형/무형의 존재를 속성과 연산을 정의해서 만든 틀 ● 다른 클래스와 독립적으로 디자인한다. ● 데이터를 추상화하는 단위
객체 (Object)	● 클래스의 인스턴스 ● 객체는 자신 고유의 속성을 가지며, 클래스에서 정의한 연산을 수행 ● 객체의 연산은 클래스에 정의된 연산에 대한 정의를 공유함으로써 메모리를 경제적으로 사용
속성 (Attribute)	● 객체들이 가지고 있는 고유한 데이터를 단위별로 정의한 것 ● 성질, 분류, 수량, 현재 상태 등에 대해서 표현한 값
메서드 (Method)	● 어떤 특정한 작업을 수행하기 위한 명령문을 집합 ● 객체가 가지고 있는 속성들을 변경할 수 있는 하나의 연산
메시지 (Message)	● 객체에게 어떤 행위를 하도록 지시 ● 객체의 메서드를 호출함으로써 객체 간의 상호작용을 할 수 있도록 한다

 

3) 객체지향 언어의 특징

특징	설명
캡슐화	● 속성(Attribute)과 속성을 조작하는 메서드(Method)를 하나로 묶은 것 ● 캡슐화된 객체의 세부내용은 외부에 은폐(정보은닉)되어, 오류의 파급 효과가 적다. ● 캡슐화된 객체들은 재사용이 용이 ● 객체들 간의 메시지를 주고받을 때, 해당 객체의 세부 내용을 알필요가 없으므로 인터페이스가 단순해지고, 결       합도가 낮아진다.
정보은닉	● 캡슐화의 가장 중요한 개념 ● 다른 객체들이 객체의 내부 데이터에 직접 접근할 수 없도록 제한하며, 오직 공개된 메서드를 통해서만 내부 상     태에 접근할 수 있게 한다.
상속	● 상위 클래스(부모 클래스)의 모든 속성과 메서드를 하위 클래스가 물려받는 것 ● 상속을 이용하면 하위 클래스는 상위 클래스의 속성과 메서드를 자신의 클래스에 다시 정의하지 않아도 된다. ● 하위 클래스는 상위 클래스에서 상속받은 요소 외에 새로운 속성과 메서드를 추가하여 사용할 수 있다. ● 상위 클래스의 요소들을 사용할 수 있기 때문에, 소프트웨어 재사용을 증대시키는 중요한 개념
다형성	● 하나의 메시지에 대해 각 객체가 가지고 있는 여러 가지 방법으로 응답할 수 있는 개념 ● 객체에서 동일한 메서드명을 인자값의 유형이 개수만 틀리게 한느 오버로딩이 존재 ● 객체에서 상속받은 메서드를 재정의하는 오버라이딩이 존재
추상화	● 실체의 핵심적인 개념만을 추출하여 간결한 형태로 표현하는 것 ● 하위 클래스에 존재하는 공통적인 메서드를 상위 클래스 혹은 인터페이스로 정의하고, 하위 클래스가 해당           메서드를 재정의 할 수 있도록 하는 것

 

4) 객체지향 설계 원칙(SOLID)

설계 원칙	설명
단일 책임 원칙 (SRP, Single Responsibility)`	● 한 클래스는 하나의 책임만을 가져야 한다.
개방 폐쇄 원칙 (OCP, Open-Closed Principle)	● 소프트웨어 엔티티(클래스, 모듈, 함수 등)는 확장에 대해서는 열려 있어야 하지만, 수정에 대해서는 닫혀 있어야 한다. ● 기존의 코드를 변경하지 않으면서(Closed), 기능을 추가할 수 있도록(Open) 설계
리스코프 치환 원칙 (LSP, Liskov Substitution Principle)	● 자식 클래스는 언제나 자신의 부모 클래스를 대체할 수 있어야 한다. ● 부모 클래스가 들어갈 자리에 자식 클래스를 넣어도 계획대로 작동해야 한다.
인터페이스 분리 원칙 (ISP, Interface Segregation Principle)	● 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다. ● 자신이 사용하지 않는 인터페이스 때문에 영향을 받아서는 안 된다.
의존성 역전 원칙 (DIP, Dependency Inversion Principle)	● 의존 관계를 맺을 때 자주 변화하는 것보다 변화가 거의 없는 것에 의존해야 한다. ● 구체적인 클래스보다 인터페이스나 추상 클래스와 의존 관계를 맺어야 한다.

디자인 패턴

1) 디자인 패턴(Design pattern) 개념

• 객체지향 프로그래밍 설계를 할 때 자주 발생하는 문제들에 대해 재사용 할 수 있도록 만들어놓은 패턴들의 모음
• 이미 만들어져서 잘 되는 것을 활용하여 재사용함으로써 프로그램 최적화에 도움을 준다.
• 효율적인 코드를 만들기 위한 방법론

 

2) 디자인 패턴 구조

구조	설명
패턴의 이름과 유형	● 각 패턴은 고유의 이름을 가지고 있어 개발자들 사이의 의사소통을 돕고, 특정 디자인 패턴을 쉽게 식별할 수 있게 해준다. ● 패턴의 유형(생성, 구조, 행동 등)은 패턴의 목적과 사용방식을 분류하는 데 도움이 된다.
문제 및 배경	●  패턴이 어떤 상황에서 사용되어야 하는지, 어떤 문제를 해결하려고23 하는지에 대한 설명을 포함한다.
솔루션	● 패턴의 구조와 그것이 어떻게 작동하는지를 설명한다. ● 클래스, 객체, 그리고 그들 사이의 관계와 상호작용을 포함한 패턴의 요소를 정의한다.
사례	● 실제 문제나 기술적 상황에서 패턴이 어떻게 적용될 수 있는지에 대한 예를 제공한다.
결과	● 패턴을 사용함으로써 얻을 수 있는 장단점, 그리고 패턴이 시스템에 미치는 영향에 대해 설명한다.
샘플 코드	● 구체적인 코드 예제는 패턴을 실제로 어떻게 구현하는지 보여준다

 

3) GoF 디자인 패턴

• 에리히 가마, 리차드 헬름, 람프 존슨, 존 블리시디스에 의해 개발 영역에서 디자인 패턴을 구체화하고 체계화 시킴
• 23가지의 디자인 패턴을 정리
• 각각의 디자인 패턴을 생성, 구조, 행위 3가지로 분류
• GoF 디자인 패턴 분류

생성 패턴	● 객체 생성과 관련된 패턴 ● 객체 생성에 있어서 프로그램 구조에 영향을 크게 주지 않는 유연성 제공
구조 패턴	● 클래스나 객체를 조합해서 더 큰 구조를 만드는 패턴
행위 패턴	● 객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴

 

4) 디자인 패턴 종류

• 생성 패턴
  • 객체 생성에 관련된 패턴
  • 객체의 인스턴스 생성을 추상화하는 방법
  • 객체의 생성 과정과 클래스의 인스턴스화를 캡슐화하여 특정 상황에서 어떤 객체를 생성할지 결정 할 수 있게 도와준다.

종류	설명
추상팩토리 (Abstract Factory)	● 구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴
빌더 (Builder)	● 복합 객체의 생성과 표현을 분리하여 동일한 생성 절차에서도 다른 표현 결과를 만들어낼 수 있음
팩토리 메서드 (Factory Method)	● 객체 생성을 서브클래스로 위임하여 캡슐화 함 ● Virtual-Constructor  패턴이라고도 함
프로토타입 (Prototype)	● 원본 객체를 복사함으로써 객체를 생성함 ● java의 clone()을 이용하여 생성하고자 하는 객체에 clone에 대한 Override를 해준다.
싱글톤 (Singleton)	● 어떤 클래스의 인스턴스는 하나임을 보장하고 어디서드 참조할 수 있다.

 

2) 구조 패턴

• 클래스나 객체를 조합해 더 큰 구조를 만드는 패턴
• 상속을 통해 클래스나 인터페이스를 합성하는 방법을 정의

종류	설명
어댑터 (adapter)	● 클래스의 인터페이스를 다른 인터페이스로 변환하여 다른 클래스가 이용 할 수 있도록 함
브리지 (bridge)	● 구현부에서 추상층을 분리하여 각자 독립적으로 확장 할 수 있게 함.
컴포지트 (Composite)	● 객체들의 관계를 트리구조로 구성하여 복합 객체와 단일 객체를 구분 없이 다룸 ● 하나 이상의 유사한 객체를 묶어서 설계된 객체로 모두 유사한 기능을 나타낸다.
데코레이터 (Decorator))	● 주어진 상황 및 용도에 따라 어떤 객체에 다른 객체를 덧붙이는 방식
퍼사드 (Facade)	● 서브시스템에 있는 인터페이스 집합에 대해 하나의 통합된 인터페이스를 제곰(Wrapper) ● 서브시스템의 가장 앞쪽에 위치하면서 서브시스템에 있는 개체들을 사용 할 수 있도록 인터페이스 역할
플라이웨이트 (Flyweight)	● 크기가 작은 여러 개의 객체를 매번 생성하지 않고 가능한 한 공유할 수 있도록 하여 메모리를 절약함
프록시 (Proxy)	● 접근이 어려운 객체로의 접근을 제어하기 위해 객체의 대리(Surrogate)나 대체글(Placeholder)을 제공

 

3) 행위 패턴

• 객체나 클래스들이 상호작용하는 방법 및 책임을 정의하는 패턴
• 객체 사이의 효율적인 커뮤니케이션과 책임 활당을 돕는다.

종류	설명
책임 연쇄 (Chain of Responsibility)	● 한 객체가 처리할 수 없는 요청을 다음 객체로 전달하는 방식 ● 객체들은 연쇄적으로 연결되어 있으며, 각 객체는 요청을 처리하거나 다음 객체로 전달될수 있다.
커멘드 (Command)	● 실행될 기능을 캡슐화함으로써 주어진 조건을 만족하는 기능을 실행할 수 있는 유연성을 제공한다. ● 요청자체를 객체로 감싸서 전달함으로써 로그, 큐 관리, undo-redo 등의 기능을 구현할 수 있다.
인터프리터 (Interpreter)	● 주어진 언어에 대해 그 언어의 문법에 대한 표현을 정의하고 해당 언어를 해석하는 해석자를 위한 패턴 ● 복잡한 문법을 가진 언어의 해석에 사용된다.
반복자 (Iterator)	● 컬렉션 내부 구조를 노출시키지 않고도 그 원소들에 접근할 수 있는 방법을 제공 ● 이를 통해 단일 원칙의 적용을 유지하면서도 컬렉션에 대한 반복작업을 수행할 수 있다.
중재자 (Mediator)	● 객체 간의 복잡한 상호작용을 캡술화하고, 객체들이 서로 직접 참조하지 않도록 중재자 객체를 통해 통신하도록 만든다. ● 이를 통해 시스템을 더 잘 조직화하고 결합도를 낮출 수 있다.
메멘토 (Memento)	● 객체의 상태 정보를 저장하고 필요에 따라 이전 상태로 복원할 수 있는 기능을 제공
옵서버 (Observer)	● 객체의 상태 변화를 관찰하는 관찰자들의 목록을 객체에 등록하여, 상태 변화가 있을 때마다 메서드를 통해 객체가 직접 목록의 각 관잘자에게 통지하도록 한다. ● 이를 통해 상태의 일관성을 유지할 수 있다.
상태 (State)	● 객체의 내부 상태에 따라 동일한 작업이 상태에 따라 다르게 작동하도록 상태를 객체로 표현한다. ● 이를 통해 객체의 상태 전이 방식을 더 명확하게 표현할 수 있다.
전략 (Strategy)	● 알고리즘을 사용하는 클라이언트와 상관없이 독립적으로 알고리즘을 다양하게 만든다. ● 이를 통해 알고리즘을 쉽게 바꿔 사용할 수 있다.
템플릿 메서드 (Template Method)	● 상위클래스는 알고리즘의 골격만을 작성하고 구체적인 처리는 서브클래스로 위임함
방문자 (Visitor)	● 객체 구조를 이루는 원소에 대한 연산을 정의하는 데 사용되는 패턴 ● 이를 통해 새로운 연산을 추가하더라도 그 객체 구조를 변경하지 않아도 된다. ● 객체지향 원칙(SOLID) 중 하나인 개방-폐쇄 원칙(OCP, Open-Close Principle)을 적용하는 방법