[소프트웨어설계] 3. 애플리케이션 설계

이 챕터는 다 중요하다!!!!

---

목차

021. 소프트웨어 아키텍처 (★★★) 022. 아키텍처 패턴 (★★★) 023. 객체지향 (★★★) 024. 객체지향 분석 및 설계 (★★★) 025. 모듈 (★★★) 026. 공통 모듈 (★★★) 027. 코드 (★★★) 028. 디자인 패턴 (★★★)

---

021. 소프트웨어 아키텍처 (★★★)

• SW 아키텍처 설계) SW의 골격이 되는 기본 구조 / 좋은 품질 유지하면서 사용자의 비기능적 요구사항 제약 반영&기능적 요구사항 구현 / 기본 원리 - 모듈화, 추상화, 단계적 분해, 정보 은닉
  • 상위설계/하위설계

	상위 설계	하위 설계
별칭	아키텍처 설계, 예비 설계	모듈 설계, 상세 설계
설계 대상	시스템의 전체적인 구조	시스템의 내부 구조 및 행위
세부 목록	구조, DB, 인터페이스	컴포넌트, 자료구조, 알고리즘

• 모듈화(Modularity) : SW 성능 향상 or 시스템 수정, 재사용, 유지관리 등 용이하도록 시스템의 기능들을 모듈 단위로 나누는 것 / 자주 사용되는 것을 공통 모듈로 구성 → 재사용성 ↑ / 모듈 크기 小 ~> 개수 多... 통합비용 ↑ / 기능 분리 가능 ~> 인터페이스 단순화 / 프로그램 효율적 관리 가능, 오류 파급 효과 최소화
• 추상화(Abstraction) : 문제의 포괄적 개념을 설계 후 차례로 세분화하여 구체화하는 것 / 복잡한 문제에 사용... 완전한 시스템 구축 전 유사 모델 만들어 테스트 ㄱㄴ / 최소비용으로 실제 상황 대처 가능, 시스템구조&구성 대략적 파악 가능
  • 유형(제과자)
    
    • 제어 추상화 : 이벤트 발생의 정확한 절차, 방법 정의 X ~> 대표할 수 있는 표현으로 대체
    • 과정 추상화 : 자세한 수행 과정 정의 X, 전반적인 흐름만 파악하게 설계
    • 데이터(자료) 추상화 : 데이터의 세부적인 속성, 용도 정의 X ~> 데이터 구조 대표하는 표현으로 대체
•  단계적 분해(Stepwise Refinement) : 하향식 설계 전략... 상위 중요 개념으로부터 하위 개념으로 구체화 / 예 - 건물 전체 설계 후 인테리어 구성
•  정보 은닉(Information Hiding) : 정보가 감추어져 다른 모듈이 접근, 변경 못하게 하는 기술 / 필요한 정보만 인터페이스 통해 주고 받음 / 모듈을 독립적 수행 가능, 모듈 하나가 변경 되어도 다른 모듈에 영향 X ~> 수정, 시험, 유지보수 용이 / 예 - 감기약(재료는 몰라도 약인건 앎)
• SW 아키텍처 품질 속성 : 잘 설계했는지 품질 평가하는 요소들 / 시스템, 비즈니스, 아키텍처 측면
  • 시스템 측면) 성능 / 보안 / 가용성 / 기능성 / 사용성 / 변경 용이성 / 확장성 / 기타 속성(테스트 용이성, 배치성, 안정성 등)
  • 비즈니스 측면) 시장 적시성 / 비용과 혜택 / 예상 시스템 수명 / 기타 속성(목표 시장, 공개 일정, 시스템 통합 등)
  • 아키텍처 측면) 개념적 무결성(일관성 유지하는지) / 정확성, 완결성 / 구축 가능성 / 기타 속성(변경성, 시험성, 적응성, 일치성, 대체성 등)
• SW 아키텍처 설계 과정) 설계 목표 설정 → 시스템 타입 결정 → 아키텍처 패턴 적용 → 서브시스템 구체화 → 검토
• 시스템 타입 / 협약에 의한 설계
  • 시스템 타입) 대화형 시스템(요구발생 시 반응&처리) / 이벤트 중심 시스템(외부 상태 변화에 따라 동작) / 변환형 시스템(입력 데이터에 따라 정해진 작업 수행) / 객체 영속형 시스템(DB사용해 파일을 효과적으로 저장, 검색, 갱신하는 시스템)
  • 협약에 의한 설계) 컴포넌트 설계 시 클래스에 대한 여러 가정 공유할 수 있도록 명세한 것
    • 선행조건) 오퍼레이션 호출되기 전 참이 되어야 할 조건(Precondition)
    • 결과조건) 오퍼레이션 수행 후 만족되어야 할 조건(Postcondition)
    • 불변조건) 오퍼레이션 실행 중 항상 만족되어야 할 조건 (Invariant)

---

022. 아키텍처 패턴 (★★★)

• 개요) 아키텍처 설계 시 참조할 수 있는 전형적인 해결 방식 or 예제 / 개발시간 단축&고품질 SW 생산 가능 / 의사소통 간단 / 쉬운 유지보수 / 시스템 특성을 개발 전 예측 가능 / 레이어패턴, 클라이언트-서버 패턴, 파이프-필터 패턴, 모델-뷰-컨트롤러 패턴
• 레이어 패턴 : 계층 구분, 고전적 방법 / 각각의 서브 시스템들이 계층 구조를 이룸 / 특정 계층만 교체해 시스템 개선 가능 / OSI 참조 모델
• 클라이언트-서버 패턴 : 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성 / 사용자 : 클라이언트와만 의사소통 함 / 서버 : 클라이언트 요청 대비해 항상 대기 / 클라이언트나 서버는 요청, 응답 받기 위해 동기화 되는 경우를 제외하고 독립적
• 파이프-필터 패턴 : 데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화 하여 파이프를 통해 데이터 전송 / 재사용성 굿, 확장 용이 / 재배치해서 파이프라인 구축 가능 / 데이터변환, 버퍼링, 동기화에 주로 사용 / 필터 간 데이터 이동 시 데이터 변환으로 인한 오버헤드 발생 / Unix-Shell
• 모델-뷰-컨트롤러 패턴 : 서브시스템을 3개로 구조화하는 패턴 / 별도 분리 ~> 독립적인 개발 작업 수행 / 모델 : 서브시스템 핵심 기능, 데이터 보관 / 뷰 : 사용자에게 정보 표시 / 컨트롤러 : 사용자로부터 입력된 변경 요청 처리 위해 모델에게 명령 보냄 / 여러 개 뷰 만들기 ㄱㄴ ~> 대화형 앱에 적합

주요 아키텍처 패턴

• 기타 패턴
  • 마스터-슬레이브 패턴 : 장애 허용 시스템, 병렬 컴퓨팅 시스템에 주로 활용
  • 브로커 패턴 : 분산 환경 시스템에 주로 활용
  • 피어-투-피어 패턴 : 멀티스레드 방식을 사용함
  • 이벤트-버스 패턴 : 소스(생성), 리스너(수행), 채널(통로), 버스(관리)
  • 블랙보드 패턴 : 음성인식, 차량식별, 신호해석 등에 주로 활용
  • 인터프리터 패턴 : 특정 언어로 작성된 프로그램 코드 해석하는 컴포넌트 설계 시 사용

---

023. 객체지향 (★★★)

• 개요) SW 개발 시 객체들을 조립해서 작성할 수 있는 기법 / 사용자, 개발자 쉽게 이해 가능 / 객체, 클래스, 캡슐화, 상속, 다형성, 연관성
  • 구조적 문제점으로 인한 SW 위기 해결책으로 사용
  • 재사용성, 확장 용이 ~> 고품질의 SW를 바르게 개발&유지보수 가능
  • 복잡한 구조를 단계&계층적으로 표현 / 멀티미디어 데이터&병렬처리 지원
• 객체(Object) : 데이터와 데이터를 처리하는 함수를 묶어놓은 하나의 SW 모듈
  • 데이터) 객체가 가지고 있는 정보... 속성, 상태, 분류 등
  • 함수) 수행하는 기능... 데이터를 처리하는 알고리즘
  • 특성) 독립적으로 식별 가능한 이름을 가지고 있음 / 일반적으로 상태(객체가 가질 수 있는 조건)는 시간에 따라 변화 / 객체-객체는 상호 연관성에 의한 관계 형성 / 행위(객체가 반응할 수 있는 메시지)의 특징 나타내기 가능 / 일정한 기억 장소 가지고 있음 / 메소드는 다른 객체로부터 메시지를 받으면 정해진 기능 수행
• 클래스(Class) : 공통된 속성, 연산(행위)을 갖는 객체의 집합... 객체의 일반적 타입 의미 / 각각의 객체들이 갖는 속성&연산을 정의하고 있는 틀
  • 인스턴스 : 클레스에 속한 각각의 객체 / 인스턴스화 : 클래스로부터 새로운 객체 생성하는 것
  • 동일 클래스에 속한 객체는 공통된 속성, 행위 가지고 있으면서 정보가 달라 동일 기능을 하는 여러 가지 객체를 나타내게 됨
  • 최상위 클래스 : 상위 클래스 X / 슈퍼 클래스 : 특정 클래스의 상위(부모) 클래스 / 서브 클래스 : 하위 클래스 / 헤라클래스 : 제우스의 아들 ㅋ
• 캡슐화(Encapsulation) : 데이터(속성)와 데이터를 처리하는 함수를 하나로 묶는 것 / 재사용에 용이
  
  • 인터페이스를 제외한 세부 내용 은닉... 외부 접근 제한적 ~> 외부 모듈 변경으로 인한 파급 효과 少
  • 객체 간 메시지를 주고 받을 때 상대 객체의 세부 내용은 알 필요가 없어 인터페이스 단순&객체 간 결합도 ↓
• 상속(Inheritance) : 이미 정의된 상위 클래스의 모든 속성, 연산을 하위 클래스가 물려받는 것 / 상속받은 하위 클래스는 자기 클래스에서 다시 정의 안 해도 바로 자신의 속성으로 사용 가능 / 하위클래스는 상위클래스로부터 상속받은 속성, 연산 외 새로운 속성, 연산 첨가해 사용 가능 / 재사용성 아주 높음
  • 다중 속성(Multiple Inheritance) : 한 개의 클래스가 두 개 이상의 상위 클래스로부터 속성, 연산 상속받는 것
• 다형성(Polymorphism) : 메시지에 의해 객체(클래스)가 연산을 수행하게 될 때 하나의 메시지에 대해 각각의 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력(하나의 메시지에 대해 여러 가지 형태의 응답이 있는 것) / 객체들은 동일한 메소드명 사용, 같은 의미의 응답 함 / 응용프로그램 상 하나의 함수나 연산자 두 개 이상의 서로 다른 클래스의 인스턴스들 같은 클래스에 속한 인스턴스처럼 수행할 수 있도록 하는 것
• 연관성(Relationship) : 두 개 이상의 객체들이 상호 참조하는 관계
  • is member of : 연관화(Association) / 2개 이상의 객체가 상호 관련
  • is instance of : 분류화(Classfication) / 동일한 형의 특성을 갖는 객체들을 모아 구성하는 것
  • is part of : 집단화(Aggregation) / 공통 성질들로 추상화한 상위 객체를 구성하는 것
  • is a : 일반화(Generalization), 특수화&상세화(Specialization) / 상위 객체를 구체화 해 하위 객체 구성하는 것

---

024. 객체지향 분석 및 설계 (★★★)

• 객체지향 분석 개념(OOA)) 사용자 요구사항 분석 ~> 요구된 문제, 관련된 모든 클래스(객체), 연관된 속성, 연산, 그들 간의 관계 등 정의하여 모델링하는 작업 / SW개발 업무를클래스, 객체, 속성, 멤버, 전체와 부분 등을 나눠 분석함 / 클래스, 객체, 속성, 연산들을 표현해 문제를 모형화 할 수 있게 함 / 객체는 클래스로부터 인스턴스화되고, 이 클래스를 식별하는 것이 주요 목적
• 객체지향 분석 방법론
  • Rumbaugh(럼바우) 방법 : 가장 일반적으로 사용 / 분석활동을 객체 모델, 동적모델, 기능모델로 나눠 수행
  • Booch(부치) 방법 : 미시적(Micro) 개발 프로세스와 거시적 개발 프로세스를 모두 사용하는 방법 / 클래스, 객체들을 분석, 식별하고 클래스의 속성, 연산 정의
  • Jacobson 방법 : 유스케이스 강조해 사용하는 분석 방법
  • Coad와 Yourdon 방법 : E-R 다이어그램 사용 ~>  객체 행위 모델링 / 객체 식별, 구조식별, 주제정의, 속성&인스턴스 연결 정의, 연산&메시지 연결 정의 등 과정으로 구성하는 기법
  • Wirfs-Brock 방법 : 분석-설계 간 구분 X / 고객 명세서를 평가해 설계 작업까지 연속적으로 수행하는 기법
• 럼바우(Rumbaugh) 분석 기법) 모든 SW 구성요소를 그래픽 표기법 이용해 모델링... 객체 모델링 기법이라고도 함
  
  • 객체 모델링 → 동적 모델링 → 기능 모델링 (객동기!!)
    • 객체 모델링) 정보 모델링 / 시스템에서 요구되는 객체 찾아 속성, 연산 식별 및 객체들간 관계 규정 ~> 객체 다이어그램으로 표현
    • 동적 모델링) 상태 다이어그램 이용 ~> 시간 흐름에 따른 객체들 간의 제어흐름, 상호작용, 동작순서 등 동적 행위 표현
    • 기능 모델링) 자료 흐름도(DFD)이용 ~> 다수 프로세스들 간 자료 흐름을 중심으로 처리 과정을 표현
• 객체지향 설계 원칙(SOLID)
  • 단일 책임 원칙(Single Responsibility Principle, SRP) : 객체는 단 하나의 책임을 가짐 // 응집도 ↑&결합도 ↓ 설계
  • 개방-폐쇄 원칙(Open-Closed Principle, OCP) : 기존 코드 변경 않고 기능 추가할 수 있도록 설계하는 것 // 공통 인터페이스를 하나의 인터페이스로 묶어 캡슐화하는 방법이 대표적
  • 리스코프 치환 법칙(Liskov Substitution Principle, LSP) : 자식 클래스는 최소한 부모 클래스에서 가능한 행위는 수행할 수 있어야 함 // 부모 클래스 책임 무시, 재정의하지 않고 확장만 수행하도록
  • 인터페이스 분리 원칙(Interface Segregation Principle, ISP) : 자신이 사용 않는 인터페이스와 의존 관계 or 영향 받지 않아야 함 // 인터페이스가 갖는 하나의 책임
  • 의존 역전 원칙(Dependency Inversion Principle, DIP) : 각 객체들 간의 의존 관계 성립 시 추상성이 낮은 클래스보다 높은 클래스와 의존 관계 맺어야 함 // 일반적으로 인터페이스 사용하면 원칙 준수 됨

---

025. 모듈 (★★★) - 정말 중요하다!!!

• 개요) 모듈화를 통해 분리된 시스템의 각 기능들... 서브루틴, 서브시스템, SW내 프로그램, 작업 단위 등과 같은 의미로 사용 / 단독 컴파일, 재사용 가능 / 기능적 독립성 : SW를 구성하는 각 모듈의 기능이 서로 독립됨을 의미하는 것... 모듈이 기능 하나만 수행하고 다른 모듈과 과도한 상호작용 배제함으로써 이뤄짐 / 독립성 높을수록 다른 모듈한테 영향 X, 오류 쉽게 발견 / 독립성은 결합도, 응집도로 측정(결합도↓&응집도↑&모듈크기小 ~> 독립성이 높아짐) / 팔짱과 포옹으로 생각하자!
• 결합도(Coupling)) 모듈 간 상호 의존하는 정도 or 두 모듈 사이 연관 관계 / 결합도↓ ~> 품질 ↑ / 결합도 강하면 시스템 구현, 유지보수 어렵
  • (약) 자료 결합도 | 스탬프 결합도 | 제어 결합도 | 외부 결합도 | 공통 결합도 | 내용 결합도 (강)
  • 자료(Data) 결합도 : 모듈 간 인터페이스가 자료 요소로만 구성될 때 / 어떤 모듈이 다른 모듈을 호출하면서 매개 변수나 인수로 데이터를 넘겨주고, 호출 받은 모듈은 받은 데이터에 대한 처리 결과를 다시 돌려줌 / 모듈 간 내용 알 필요 X... 한 모듈 내용 변경해도 다른 모듈엔 전혀 영향 미치지 않는 가장 바람직한 결합도
  • 스탬프(검인) 결합도 : 모듈 간 인터페이스로 배열이나 레코드 등의 자료구조가 전달될 때 / 두 모듈이 동일 자료 구조를 조화하는 경우... 자료 구조의 변화(포맷, 구조의 변화)는 그것을 조회하는 모든 모듈, 변화되는 필드를 실제로 조회하지 않는 모듈한테도 영향 줌
  • 제어(Control) 결합도 : 어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어 신호를 이용해 통신 or 제어요소를 전달하는 결합도 / 한 모듈이 다른 모듈의 상세 처리 과정 알고 잇음... 통제 시 처리 기능이 두 모듈에 분리되어 설계된 경우 발생 / 하위모듈~ 상위모듈로 제어 신호가 이동해 하위모듈이 상위모듈한테 처리 명령 내리는 권리 전도현상 발생
  • 외부(External) 결합도 : 어떤 모듈에서 선언한 데이터를 외부의 다른 모듈에서 참조할 때 / 참조되는 데이터의 범위를 각 모듈에서 제안할 수 있음
  • 공유(Common) 결합도 : 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때 / 공통 데이터 영역의 내용을 조금만 변경해도 사용하는 모든 모듈에 영향을 미침,,, 독립성을 약하게 함
  • 내용(Content) 결합도 : 한 모듈이 다른 모듈의 내부 기능, 그 내부 자료를 직접 참고 or 수정할 때 / 한 모듈에서 다른 모듈의 내부로 제어가 이동하는 경우에도 해당
• 응집도(Cohesion)) 정보은닉 개념 확장한 것 / 모듈이 독립적인 기능으로 정의되어 있는 정도를 의미 / 응집도↑ ~> 품질↑
  • (강) 기능적 응집도 | 순차적 응집도 | 교환적 응집도 | 절차적 응집도 | 시간적 응집도 | 논리적 응집도 | 우연적 응집도 (약)
  • 기능적(Functional) 응집도 : 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우
  • 순차적(Sequence) 응집도 : 모듈 내 하나의 활동으로부터 나온 출력 데이터를 그 다음 활동의 입력 데이터로 사용할 경우
  • 교환적(통신, Communication) 응집도 : 동일 입출력 사용해 서로 다른 기능을 수행하는 구성 요소들이 모였을 때
  • 절차적(Precedural) 응집도 : 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성들이 그 기능을 순차적으로 수행할 경우
  • 시간적(Temporal) 응집도 : 특정 시간에 처리되는 몇 개 기능 모아 하나 모듈로 작성할 경우
  • 논리적(Logical) 응집도 : 유사 성격 or 특정 형태로 분류처리 되는 요소들로 하나의 모듈이 형성되는 경우
  • 우연적(Coincidental) 응집도ㅠ : 모듈 내부의 각 구성요소들이 서로 관련 없는 요소로만 구성된 경우
• 팬인/팬아웃(Fan-In/Out)
  
  • 팬인) 어떤 모듈을 제어하는 모듈의 수 / 팬인↑ ~> 재사용 측면에서 설계가 굿.. but, 단일 장애점이 발생할 수 있어 중점적 관리, 테스트 필요
  • 팬아웃) 어떤 모듈에 의해 제어되는 모듈의 수 / 팬아웃↑..? 불필요하게 다른 모듈을 호출하고 있는지 검토 및 단순화
  • 팬인아웃을 분석해 시스템 복잡도 알 수 있음 / 복잡도를 최적화하려면 팬인 ↑, 팬아웃 ↓
  • 예1
    • 팬인) A는 0 / B, C, D, E, G는 1 / F, H I는 2
    • 팬아웃) H, I는 0 / C, E, F, G는 1 / B, D는 2 / A는 3

예1

• N-S차트(Nassi-Schneiderman Chart)) 박스 다이어그램... 논리 기술에 중점을 둔 도형을 이용한 방법 / 연속, 선택, 다중선택, 반복 등 제어 논리 구조 표현 / GOTO, 화살표 X / 조건 복합되어 있는 곳의 처리를 시각적으로 명확히 식별하는 데 적합 / 선택, 반복 구조 시각적으로 표현 / 이해쉽고 코드변화 용이 / 읽기 쉽지만 작성 어렵... 임의로 제어를 전이하는 것이 불가능 / 총체적인 구조 표현, 인터페이스 나타내기 어렵 / 단일 입출구로 표현

---

026. 공통 모듈 (★★★)

• 개요) 여러 프로그램에서 공통적으로 사용할 수 있는 모듈 / 자주 쓰거나 매번 필요한 사용자 인증같은 기능 / 모듈 재사용성 확보와 중복 개발 회피 위해 설계 과정에서 공통 부분 식별, 명세 작성할 필요 있음 / 명세기법 준수(정확성, 명확성, 완전성, 일관성, 추적성)
  • 정확성(Correctness) : 시스템 구현 시 해당 기능이 필요하다는 것을 알 수 있도록 정확히 작성
  • 명확성(Clarity) : 해당 기능을 이해할 때 중의적으로 해석되지 않도록 명확히 작성
  • 완전성(Completeness) : 시스템 고현 위해 필요한 모든 것 기술
  • 일관성(Consistency) : 공통 기능들 간 상호 충돌 발생 않도록 작성
  • 추적성(Traceability) : 기능에 대한 요구사항 출처, 관련 시스템 등의 관계 파악할 수 있도록 작성
• 재사용(Reuse)) 이미 개발된 기능들 파악&재구성 → 새로운 시스템에 사용하기에 적합하도록 최적화 시킴 ~> 비용, 개발시간 ↓ / 누구나 이해, 사용 가능하도록 사용법 공개 / 재사용되는 대상은 외부 모듈과 결합도는 낮고 응집도는 높아야 함
  • 함수, 객체) 클래스, 메소드 단위의 소스 코드 재사용
  • 컴포넌트) 독립적 업무, 기능 수행하는 실행 코드 기반으로 작성된 모듈 / 컴포넌트 자체에 대한 수정 없이 인터페이스를 통해 통신하는 방식으로 재사용
  • 애플리케이션) 공통된 기능들을 제공한느 애플리케이션을 공유하는 방식
• 효과적인 모듈 설계 방안 (결합도 줄이고 응집도 높여야 하는 게 포인트) : 결합도 ↓&응집도 ↑ ~> 모듈 독립성, 재사용성 ↑ / 모듈 제어영역 안에서 그 모듈의 영향영역을 유지시킴 / 복잡도&중복성 ↓, 일관성 유지시킴 / 모듈의 기능은 예측 가능해야 되고, 너무 제한적이면 X / 유지보수 용이 / 모듈 크기는 시스템 전반적인 기능, 구조를 이해하기 쉬운 크기로 분해 / 하나의 입출구를 갖도록 함 / 인덱스 번호, 기능 코드들이 전반적인 처리 논리 구조에 예기치 못한 영향을 끼치지 않도록 모듈 인터페이스 설계 / 효과적인 제어 위해 모듈 간의 계층적 관계를 정의하는 자료가 제시되어야 함

---

027. 코드 (★★★)

• 개요) 정보를 신속, 정확, 명료하게 전달 / 일정한 규칙에 따라 작성, 정보처리 효율과 처리된 정보 가치에 많은 영향
  • 기능) 식별기능(구분) / 분류기능(그룹화) / 배열기능 / 표준화기능 / 간소화기능
• 종류
  • 순차코드) 일정 기준에 따라 최초 자료부터 차례로 일련 번호 부여 / 순서 코드, 일련번호 코드 / ex. 1, 2, 3, 4...
  • 블록코드) 공통성 있는 것끼리 블록으로 구분&일련번호 부여 / 구분코드 / ex. 1001~1100 : 강아지, 101~104 : 고양이
  • 10진코드) 0~9까지 10진 분할, 다시 그 각각에 대해 10진 분할 / 도서 분류식 코드 / ex. 1000 : 공학, 1100: SW공학, 1110: SW설계
  • 그룹 분류 코드) 일정 기준에 따라 대/중/소본류 등으로 구분&각 그룹 안에서 일련번호 부여 / ex. 1-01-001 : 본사-총무부-인사계, 2-01-001: 지사-총무부-인사계
  • 연상코드) 명칭, 약호와 관계있는 숫자, 문자, 기호 이용해 코드 부여 / ex. TV-40 : 40인치 TV
  • 표의 숫자 코드) 대상 항목의 성질(길이, 넓이, 부피, 지름, 높이 등)을 물리적 수치 그대로 코드에 적용 / 유효 숫자 코드 / ex. 120-720-1500 : 두께x폭x길이
  • 합성코드) 하나 코드로 필요 기능 수행 어려울 때 2개 이상의 코드 조합
• 코드 부여 체계) 이름만으로 개체의 용도, 적용범위를 알 수 있어야 함 / 각 개체에 유일한 코드 부여

---

028. 디자인 패턴 (★★★)

• 개요) 각 모듈의 세분화된 역할이나 모듈들 간의 인터페이스와 같은 코드를 작성하는 수준의 세부적인 구현방안을 설계할 때 참조할 수 있는 전형적인 해결 방법 / 문제 및 배경, 실제 적용 사례, 재사용이 가능한 샘플 코드 등으로 구성 / 문제 발생하면 새로운 해결책보다 기존 디자인 패턴 참고하는 게 효율적 / 한 패턴을 변형하면 유사한 형태의 다른 패턴으로 변화함(원룸예시) / 생성패턴(5개), 구조패턴(7개), 행위패턴(11개)로 구성
  • 아키텍처 패턴 vs 디자인 패턴) 아키텍처는 전체적, 디자인은 서브시스템(아키텍처 패턴 - 건물 윤곽 가이드라인 / 디자인 패턴 - 건물의 각 방들 인테리어) / 일부 디패는 특정 아패를 구현하는 데 유용히 쓰임
• 디패 사용의 장/단점
  • 장) 범용적인 코딩 스타일 ~> 구조파악 용이 / 객체지향 설계, 구현 생산성 높이는 데 적합 / 개발 시간, 비용, 초기 투자 비용 절약 / 원활한 의사소통 가능 / 요청에 따른 유연한 대처 가능
  • 단) 객체지향 기반... 다른 기반의 애플리케이션 개발엔 적합X
• 생성 패턴(Creational Pattern)) 객체 생성, 참조 과정 캡슐화... 변경되어도 프로그램 구조에 영향 X ~> 유연성 ↑ / 추상팩토리, 빌더, 팩토리 메소드, 프로토타입, 싱글톤
  • 추상 팩토리(Abstract Factory) : 구체적 클래스 의존 X, 인터페이스 통해 서로 연관&의존하는 객체 그룹 생성해 추상적으로 표현 / 연관된 서브 클래스 묶어 한번에 교체 가능
  • 빌더(Builder) : 인스턴스를 건축하듯 조합해 객체 생성 / 생성과정&표현방법 분리... 동일 객체여도 서로 다른 결과 가능
  • 팩토리 메소드(Factory Method/가상 생성자 패턴) : 객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화 / 상위 클래스 - 인터페이스만 정의, 서브 클래스 - 실제 생성
  • 프로토타입(Prototype) : 원본 객체 복제해 객체 생성 / 일반적인 방법으로 생성, 비용이 큰 경우 주로 사용
  • 싱글톤(Singleton) : 하나의 객체 생성 후 그 객체를 어디서든 참조할 수 있지만, 여러 프로세스가 동시 참조 X / 클래스 내 인스턴스 하나라는 걸 보장, 불필요한 메모리 낭비 최소화
• 구조 패턴(Structual Pattern)) 클래스, 객체를 조합해 더 큰 구조로 만드는 패턴 / 구조가 복잡한 시스템을 개발하기 쉽게 도와줌 / 어댑터, 브릿지, 컴포지트, 데코레이터, 퍼싸드, 플라이웨이트, 프록시
  • 어댑터(Adapter) : 호환성 없는 클래스들의 인터페이스를 다른 클래스가 이용할 수 있도록 변환해줌 / 기존 클래스를 이용하고 싶은데 인터페이스가 다를 때 이용
  • 브리지(Bridge) : 구현부에서 추상층 분리해 서로 독립적으로 확장할 수 있도록 구성 / 기능, 구현을 두 개의 별도 클래스로 구현
  • 컴포지트(Composite) : 복합개체(여러개체가짐), 단일 객체 구분 없이 다루고 싶을 때 / 객체들을 트리 구조로 구성... 파일 안에 파일 있듯 복합개체 안에 복합객체가 있는 구조 구현 가능
  • 데코레이터(Decorator) : 객체 간 결합 ~> 능동적으로 기능 확장할 수 있는 패턴 / 임의의 객체에 부가적인 기능을 추가하기 위해 다른 객체들을 덧붙이는 방식으로 구현
  • 퍼싸드(Facade) : 복잡한 서브 클래스들을 피해 더 상위에 인터페이스를 구성... 서브클래스 기능을 간편히 사용할 수 있도록 하는 패턴 / 서브클래스 사이의 통합 인터페이스 제공하는 Wrapper 객체 필요
  • 플라이웨이트(Flyweight) : 인스턴스 필요 시 매번 생성 X, 가능한 공유해서 사용 ~> 메모리 절약 / 다수 유사 객체 생성, 조작 시 유용
  • 프록시(Proxy) : 접근 어려운 객체, 여기에 연결하려는 객체 사이에 인터페이스 역할 수행 / 네트워크 연결, 메모리 대용량 객체로의 접근 등에서 주료 이용
• 행위 패턴(Behavioral Pattern)) 클래스&객체가 서로 상호작용하는 방법 or 책임분배 방법 정의 / 하나의 객체로 수행할 수 없는 작업을 여러 객체로 분배해 결합도를 최소화 하도록 도와줌
  • 책임 연쇄(Chain of Responsibility) : 요청 처리할 수 있는 객체가 둘 이상 존재해 한 객체가 처리하지 못하면 다음 객체로 넘어가는 형태 / 각 객체들을 고리로 묶여 있어 요청 해결 될 대까지 고리 따라 책임 넘김
  • 커맨드(Command) : 요청을 객체 형태로 캡슐화 ~> 재이용 or 취소할 수 있도록 요청에 정보 저장(로그 남기기) / 요청에 사용되는 각종 명령어들을 추상클래스, 구체클래스로 분리해 단순화
  • 인터프리터(Interpreter) : 언어에 문법 표현 정의 / SQL, 통신 프로토콜 개발 시
  • 반복자(Iterator) : 자구같이 접근 잦은 객체에 대해 동일한 인터페이스 사용하도록 하는 패턴 / 내부 표현 방법 노출 없이 순차적 접근 가능
  • 중재자(Mediator) : 많은 객체 간 복잡한 상호작용을 캡슐화해 객체로 정의 / 객체 사이 의존성 ↓ ~>  결합도 ↓ / 객체 간 통제, 지시 역할 수행
  • 메멘토(Memento) : 특정 시점에서의 내부 상태를 객체화 함... 이후 요청에 따라 객체를 해당 시점으로 되돌릴 수 있는 기능 / 되돌리기 기능 개발 시 사용
  • 옵서버(Observer) : 한 객체 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달하는 패턴 / 분산된 시스템 간 이벤트 생성, 발행하고 이를 수신해야 할 때
  • 상태(State) : 객체 상태 따라 동일 동작을 다르게 처리해야 할 때 / 객체 상태를 캡슐화, 이를 참조하는 방식으로 처리
  • 전략(Strategy) : 동일 계열의 알고리즘을 개별적으로 캡슐화 ~> 상호교환 가능하게 정의 / 클라이언트-독립적으로 원한느 알고리즘 선택 ㄱㄴ & 클라이언트 영향 없이 알고리즘 변경 ㄱㄴ
  • 템플릿 메소드(Template method) : 상위 클래스 골격 정의, 하위 클래스에서 세부 처리 구체화 / 유사 서브 클래스를 묶어 공통된 내용을 상위 클래스에 정의 ~> 코드 ↓, 유지보수 용이
  • 방문자(Visitor) : 각 클래스들의 데이터 구조에서 처리 기능 분리 ~> 별도 클래스로 구성 / 분리된 처리 기능은 클래스를 방문하여 수행