4장 서버 프로그램 구현 (결합도, 응집도, 디자인 패턴)

모듈화 (Modularity)

• 소프트웨어의 성능 향상, 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록
• 시스템의 기능들을 모듈 단위로 나눈 것
• 목표 
  • 모듈 간 결합도(Coupling)의 최소화
  • 모듈 내 요소들의 응집도(Cohesion)를 최대화

 

객체지향 설계 원칙 (SOLID)

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

 

결합도 (Coupling) 내공외제스자

• 모듈 간에 상호 의존하는 정도
  • 약할수록 품질이 좋음
  • 자료 결합도가 가장 품질이 좋음
• 내용 (Content) 결합도: 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정하는 경우
• 공통 (= 공유 Common) 결합도: 공유되는 공통 데이터 영역을 여러 모듈이 사용하는 경우
  • 모듈 밖에 선언된 전역 변수를 사용하여 전역 변수를 갱신하는 방식
• 외부 (External) 결합도: 어떤 모듈에서 선언한 변수를 외부의 다른 모듈에서 참조하는 경우
• 제어 (Control) 결합도: 어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어 신호나 제어 요소를 전달하는 경우
  • 권리 전도 현상: 하위 모듈에서 상위 모듈로 제어 신호가 이동해 하위 모듈이 상위 모듈에게 처리 명령을 내리는 현상
• 스탬프 (= 검인 Stamp) 결합도: 모듈 간의 인터페이스로 배열이나 레코드 등의 자료구조가 전달되는 경우
• 자료 (Data) 결합도: 모듈 간의 인터페이스가 자료 요소로만 구성되는 경우

 

응집도 (Cohesion) 우논시절통순기

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

 

디자인 패턴

• 모듈 간의 관계 및 인터페이스를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제
• GOF의 디자인 패턴은 생성 패턴, 구조 패턴, 행위 패턴으로 구분
  • 생성 패턴: 클래스나 객체의 생성과 참조 과정을 정의하는 패턴
  • 구조 패턴: 구조가 복잡한 시스템을 개발하기 쉽도록 클래스나 객체들을 조합하여 더 큰 구조로 만드는 패턴
  • 행위 패턴: 클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴

 

생성 패턴

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

 

구조 패턴

• 어댑터: 호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용할 수 있도록 변환
• 브리지: 구현부에서 추상층을 분리하여 서로가 독립적으로 확장할 수 있도록 구성한 패턴
  • 기능과 구현을 두 개의 별도 클래스로 구현
• 컴포지트: 복합 객체와 단일 객체를 구분 없이 다루고자 할 때 사용
  • 객체들 트리 구조로 구성
• 데코레이터: 객체 간의 결합을 통해 능동적으로 기능들을 확장
• 퍼싸드: 복잡한 서브 클래스들을 피해 더 상위에 인터페이스를 구성함으로써 서브 클래스들의 기능을 간편하게 사용
• 플라이웨이트: 인스턴스가 필요할 때마다 매번 생성하는 것이 아닌 가능한 한 공유해 사용함으로써 메모리 절약
• 프록시: 복잡한 시스템 개발하기 쉽도록 클래스나 객체를 조합
  • 대리자라고도 함

 

행위 패턴

• 책임 연쇄 (Chain of Responsibility): 요청을 한 객체가 처리하지 못하면 다음 객체로 넘어감
• 커맨드: 요청을 객체의 형태로 캡슐화해 재이용하거나 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남김
• 인터프리터: 언어에 문법 표현을 정의
• 반복자 (Iterator): 자료 구조와 같이 접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 함
• 중재자 (Mediator): 수많은 객체들 간의 복잡한 상호작용(Interface)을 캡슐화
• 메멘토: 특정 시점에서의 객체 내부 상태를 객체화함으로써 이후 요청에 따라 객체를 해당 시점의 상태로 돌림
  • ctrl + Z와 같은 기능
• 옵서버: 한 객체의 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달
• 상태 (State): 객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용
• 전략 (Strategy): 동일한 계열의 알고리즘들을 개별적으로 캡슐화해 상호 교환할 수 있게 해줌
• 템플릿 메소드: 상위 클래스에서 골격 정의하고, 하위 클래스에서 세부 처리를 구체화하는 구조
• 방문자 (Visitor): 각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성