정보처리기사 객체지향설계 정리

• 모듈화
  • 시스템의 기능들을 모듈 단위로 나누는것
• 추상화
  • 포괄적인 개념을 설계한 후 구체화
• 단계적 분해
  • 상위 → 하위로 개념을 구체화 시키는것
• 정보 은닉
  • 정보를 감추거나 변경하지 못하게 하는것

아키텍쳐 설계과정

설계목표→시스템 타입 결정 → 아키텍쳐 패턴 적용 → 서브 시스템 구체화 → 검토

협약

• 컴포넌트를 설계할 때 클래스에 대한 여러 가정을 공유할 수 있도록 명세한 것
• 선행조건
• 결과조건
• 불변조건

아키텍쳐 패턴

• 레이어 패턴 : 시스템을 계층으로 구분하여 구성
• 클라이언트-서버 : 하나의 서버와 다수의 클라이언트 구성
• 파이프 필터 패턴 : 데이터 스트림 절차를 필터로 캡슐화하여 파이프를 통해 전송
• 모델뷰컨트롤러 패턴 : 모델 뷰 컨트롤러로 구조화
• 마스터 슬래이브 패턴 : 슬레이브 컴포넌트로 작업을 나누로 메인 컴포넌트로 작업을 전달받음
• 브로커 패턴 : 브로커 컴포넌트가 특성에 맞게 컴포넌트를 연결해줌

Coad와 Yourdon 방법

• E-R다이어 그램을 사용하여 객체의 행위를 모델링함

럼바우 기법(객동기)

• 객체 모델링 → 동적 모델링 → 기능 모델링
• 객체 모델링
  • 객체들간의 관계를 규정하여 객체 다이어그램으로 표시하는것
• 동적 모델링
  • 상태 다이어그램을 시용해서 시간흐름에 따라 표현하는 모델링
• 기능 모델링
  • 자료 흐름도 DFD를 통해 처리하는 방법

SOILD

• 단일 책임의 원칙(SRP) : 객체는 단 하나의 책임만 가진다
• 개방-폐쇠의 원칙(OCP) : 기존의 코드를 변경하지 않고 기능을 추가해야한다.
• 리스코프 치환 원칙(LSP)(리스코프 substitution principle)) : 자식 클래스는 최소한 부모 클래스의 기능은 수행할 수 있어야한다.
• 인터페이스 분리 원칙(ISP) interface segregation : 자신이 사용하지 않는 인터페이스와 의존 관계를 맺거나 영향을 받지 않아야한다
• 의존 역전의 원칙(Dependency inversion principle) : 의존관계 성립시 추상성이 높은 클래스와 의존 관계를 맺어야 한다는 원칙

결합도(Coupling)

• 내용 결합도
• 공통
• 외부
• 제어
• 스탬프
• 자료

위로갈수록 결합도 커짐

• 내용결합도(Content) : 한모듈이 다른 모듈의 내부 기능 및 그 자료를 직접 참조
• 공통(공유) 결합도(Common) : 공유되는 공통 데이터 영역을 여러 모듈이 사용할때의 결합도
• 외부 결합도(External Coupling) : 어떤 모듈에서 선언한 데이터를 외부의 다른 모듈에서 참조할 때
• 제어 결합도(Control) : 어떤 모듈이 다른 모듈 내부의 논리적 흐름을 제어하기위해 제어신호나 제어 요소를 전달하는 결합도
• 스탬프(검인) 결합도(Stamp) : 모듈 간의 인터페이스로 배열이나 레코드 등의 자료 구조가 전달 될때의 결합도
• 자료 결합도 (Data) : 모델 간의 인터페이스가 자료 요소로만 구성될때 결합도

응집도(Cohesion)

• 기능적 응집도
• 순차적 응집도
• 교환(통신)적 응집도
• 절차적 응집도
• 시간적 응집도
• 논리적 응집도
• 우연적 응집도

위로 갈수록 응집도가 커짐

• 기능적 응집도(Functional) : 모든 기능 요소들이 단일 문제와 연관되어 수행
• 순차적(Sequential) : 출력 데이터를 그 다음 활동의 입력 데이터를 사용할 경우
• 교환(통신)적 응집도(Communication) : 동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우
• 절차적(Procedural) : 모듈이 다수의 관련 기능을 가질때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우
• 시간적(Temproal) : 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도
• 논리적(Logical) : 유사한 성격을 갖거나 특정 형태로 분류되는 처리요소들로 하나의 모듈을 생성
• 우연적(Coincidental) : 모듈 내부의 각 구성요소들이 서로 관련없는 요소로 만 구성된 경우

모듈 내 결합도는 낮추고 응집도를 높이는게 좋다.

Fan-in 들어오는것 fan-out 나가는것

IPC(inter-Process Communication)

• Shared Memory
• Socket
• Semapohores
• Popes&named Pipes : Pipe라고 불리는 선입선출 형태로 구성된 메모리를 여러 프로세스가 공유
• Message Queueing : 메세지가 발생하면 이를 전달하는 방식으로 통신

디자인패턴

생성패턴

클래스나 객체의 생성과 참조 과정을 정의하는 패턴

• 추상팩토리
  • 구체적인 클래스에 의존하지 않고, 인터페이스를 통해 서로 연관,의존하는 객체들의 그룹으로 생성하여 추상적으로 표현함
  • 연관된 서브 클래스를 묶어 한 번에 교체하는것이 가능함
• 빌더
  • 작게 분리된 인스턴스를 건축 하듯이 조합하여 객체를 생성함
  • 객체의 생성과정과 표현방법을 분리하고 있어, 객체 생성에서도 서로 다른 결과를 만들어 낼 수 있음
• 팩토리 / 메소드 이렇게 구분한다고 하면 암기가 좋을듯?
  • 객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화 한 패턴
  • 상위 클래스에서 인터페이스만 정의하고 실제 생성은 서브 클래스가 담당함
• 프로토타입
  • 원본 객체를 복제하는 방법으로 객체를 생성하는 패턴
• 싱글톤
  • 하나의 객체를 생성하면 생성된 객체를 어디서든 참조할 수 있지만, 여러프로세스가 동시에 참조할 수는 없음

추상팩토리 : 객체들의 공통점을 모아 인터페이스로 만든다.
빌더 : 건축가가 블록을 조립하는 모습 / 생성과 표현 기능이 나눠줘 있다!
팩토리 메소드 : 공장과 메소드가 분리된거처럼 상위는 인터페이스를 정의하고 하위에서 생성을 담당함
프로토타입 : 원본을 두고 복제품을 만드는것
싱글톤 : 하나의 객체는 하나의 프로세스만

구조 패턴

클래스나 객체들을 조합하여 더 큰 구조로 만드는 패턴

• 어댑터
  • 호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용할수 있도록 변환해주는 패턴
• 브리지
  • 구현부에서 추상층을 분리하여 서로가 독립적으로 확장할 수 있도록 구성한 패턴
  • 기능 / 구현을 두개의 별도 클래스로 구현함
• 컴포지트
  • 여러 객체를 가진 복합 객체와 단일 객체를 구분 없이 다루고자 할때 사용하는 패턴
  • 객체들을 트리구조로 구성하여 구성 가능
• 데코레이터
  • 객체 간의 결합을 통해 능동적으로 기능들을 확장할 수 있는 패턴
  • 임의의 객체에 부가적인 기능을 추가하기 위해 다른 객체들을 덧붙이는 방식으로 구현
• 퍼싸드(Facade) 정면 / 표면
  • 복잡한 서브클래스들을 피해 더 상위에 인터페이스를 구상함으로써 서브 클래스들의 기능을 간편하게 사용할 수 있도록 하는 패턴
  • 서브 클래스들 사이의 통합 인터페이스를 제공하는 Wrapper 객체가필요함
• 플라이웨이트(FlyWeight)
  • 인스턴스가 필요할때 마다 매번 생성하는것이 아니고 가능한 공유해서 사용함으로써 메모리를 절약하는 패턴
  • 다수의 유사 객체를 생성하거나 조작할때 유용하게 사용할 수 있음
• Proxy(중재)
  • 접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할을 수행하는 패턴
  • 네트워크 연결, 메모리의 대용량 객체로의 접근 등에 주로 이용

어댑터 : 변압기 → 인터페이스를 원하는형태로 바꿔줌
브리지 : 추상층을 분리해서 기능 / 구현을 분리후 연결
컴포지트(복합의) : 단일객체와 복합객체를 구분없이 합침
데코레이터 : 기능추가를 위해 새로운 객체를 만들어서 붙임(꾸밈)
퍼싸드(정면) : 복잡한 서브클래스들을 피해 상위 인터페이스를 만듬
플라이웨이트 : 부담을 가볍하게 하기 위해서 매번 생성하지 않고 공유
중재 : 나 → 변호사(중재)→ 법률 법률, 나 객체사이에 연결이 어려워 인터페이스를 통해 중재

행위 패턴

클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의

• 책임 연쇄(Chain of Responsibility)
  • 요청을 처리할 수 있는 객체가 둘 이상 존재하여 한 객체가 처리하지못하면 다음 객체로 넘어가는 형태의 패턴
  • 객체들이 고리로 묶여있어 요청이 해결될때까지 고리를 따라 책임이 넘어감
• 커맨드(Command)
  • 요청을 객체의 행태로 캡슐화하여 재이용하거나 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴
  • 요청에 사용되는 각종 명령어들을 추상클래스와 구체 클래스로 분리하여 단순화함
• 인터프리터(Interpreter)
  • 언어의 문법 표현을 정의하는 패턴
• 반복자(Iterator)
  • 자료구조와 같이 접근이 찾은 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴
  • 내부 표현 방법의 노출 없이 순차적으로 접근이 가능함
• 중재자(Mediator)
  • 수많은 객체들 간의 복잡한 상호작용을 캡슐화하여 객체로 정의하는 패턴
  • 객체 사이의 의존성을 줄여 결합도를 감소시킬 수 있음
• 메멘토(Memento)
  • 특정 시점에서의 객체 내부 상태를 객체화함으로써 이후 요청에 따라 객체를 해당 시점의 상태로 돌릴 수 있는 기능을 제공하는 패턴
  • ctrl + z 같은 기능
• 옵서버(Observer)
  • 한 객체의 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달하는 패턴
  • 주로 분산된 시스템 간에 이벤트를 생성하고, 이를 수신해야할때 이용함
• 상태(State)
  • 객체의 상태에 따라 동일한 동작을 다르게 처리해야할때 사용하는 패턴
• 전략(Strategy)
  • 동일한 계열의 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴
  • 클라이언트는 독립적으로 원하는 알고리즘을 선택하여 사용할 수 있으며, 클라이언트에 영향 없이 알고리즘의 변경이 가능함
• 템플릿 메소드(Template Method)
  • 상위 클래스에서 골격을 정의하고 하위 클래스에서 세부처리를 구체화하는 구조의 패턴
  • 유사한 서브 클래스를 묶어 공통된 내용을 상위 클래스에서 정의함으로써 코드의 양을 줄이고 유지보수를 용이하게 해줌
• 방문자(Visitor)
  • 각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성하는 패턴
  • 분리된 처리 기능은 각 클래스를 방문(visit)하여 수행함

책임연쇄 : 책임이 따라간다~
커맨드 : 각종 명령어를 하나로 캡슐화 해 로그로 기록
인터프리터 : 번역해주는거
반복자 : 반복되는 구조에서 동일한 인터페이스 사용
중재자 : 복잡한 구조를 캡슐화해서 중재
메멘토 : 특정시점의 객체를 기억
옵서버 : 참조하고 있는 객체에도 변화를 알려줌→ 보고있어~
상태 : 상태에 따라 동작을 다르게 처리
전략 : a,b,c와 같은 전랻들을 캡술화 해두고 선택적으로 사용 가능
템플릿 메소드 : 도형이라는 템플릿에 대해서 세모,네모, 동그라미로 하위로 나누는것
방문자 : 처리기능을 나누고 방문하면서 수행함