[책] 디자인 패턴의 아름다움

[SAgiKPJH]

개요

1.1 코드를 배우는 이유

1.1.1 고품질의 코드 작성

• 속도와 확장성을 맹목적으로 추구하는 현재의 개발 환경
  • 고품질 코드 작성할 시간이 많이 없다.
  • 유지보수하는 것은 무척 힘들다.
• 높은 품질의 코드를 작성할려면? -> 코드 설계에 대한 이론적인 지식을 갖춰야 한다.

1.1.2 복잡한 코드 개발

• 어려움 2가지
  • 매우 높은 수준의 기술이 필요한 경우
  • 복잡한 비즈니스, 코드양이 매우 많은 시스템 즉, 소프트웨어 개발의 복잡성
• 코드 설계에 대한 지식이 있어야 한다.
• 보통은, 비즈니스의 요구 사항에 따라 코드를 채우는 것이 일반적인 업무
• 질문, 코드 설계를 의식하고 개발하자.
  • 계층화와 하위 모듈화 방법
  • 클래스 어떻게 나눌지
  • 각 클래스에 어떤 속성과 메서드를?
  • 클래스 간의 상호작용 설계 방법은?
  • 상속이나 연관을 사용하는게 좋을까?
  • 인터페이스나 추상 클래스 사용이 옳은가?
  • 결합도가 높은 코드와 낮은 코드?
  • 디커플링을 달성하는 방법은?
  • 싱글턴 패턴이나 정적 메서드 사용하는 것이 옳은가?
  • 객체를 생성할 때 팩토리 패턴을 사용하는 것이 옳은가?
  • 가독성 유지 및 확장성 향상을 위한 디자인 패턴 도입 방법은?

1.1.3 프로그래머의 기본 능력

• 프로그래머는 기술의 넓이와 깊이 둘다 있어야 한다.
• 심층적인 이해가 필요.’
• 우수한 프로젝트는 코드와 클래스가 많으며, 클래스 구조와 클래스 간의 관계 호출 관계도 복잡하다..
• 고도의 본질을 이해하자.

1.1.4 경력 개발에 필요한 기술

• 기본적인 능력 향상 및 기본적인 지식 습득에 꾸준히 신경을 써야 한다.
• 신입과 주니어 엔제니어의 코드리뷰 및 양성, 이끄는 일도 해야 한다.
• 팀의 개발 효율성을 신경써야 한다.
• 잘 설계되고 유지보수가 쉬운 시스템이 되어 의미있는 일을 더 할 수 있도록 한다.

1.2 코드 품질 평가 방법

• 코드 품질 평가
  • 어떤 코드가 높은 가독성을 가지는 코드인가?
  • 어떤 종류의 코드가 확장과 유지 관리에 용이한가?
  • 가독성, 확장성, 유지보수 사이의 관계는 무엇인가?
  • 유지 보수는 정확히 어떤 것을 의미하는 것인가?
• 코드 품질 요소
  • 유연성 (Flexibility)
  • *확장성 (Extensibility)
  • *유지 보수성(Maintainability)
  • *가독성 (Readability)
  • 이해 용이성 (Understandability)
  • 가변성 (Changeability)
  • *재사용성 (Reusability)
  • *테스트 용이성 (Testability)
  • 모듈성 (Moduarity)
  • 높은 응집도와 낮은 결합도 (High cohesion loose coupling)
  • 높은 효율성 (High efficiency)
  • 고성능 (High performance)
  • 보안성 (Security)
  • 호환성 (Compatibility)
  • 사용성 (Usability)
  • 깨끗함 (Clean)
  • 명확성 (Clarity)
  • *간결성 (Simplicity)
  • 직접성 (Straightforward)
  • 더 작은 코드가 더 많은 것을 담는다 (less code is more)
  • 문서화가 잘 된 (well-documented)
  • 계층화가 잘 이루어진 (well-layered)
  • 정확성 (Correctness, Bug free)
  • 강건성 (Robustness)
  • 신뢰성 (Reliability)
  • 확장성 (Scalability)
  • 안정성 (Stability)
  • 우아함 (Elegant)

1.2.1 유지보수성

• 서비스 중인 프로젝트의 경우, 새로운 코드보다는 유지관리하는데 시간이 훨씬 오래 걸릴 수 있다.
• 따라서 코드의 유지보수성이 특히 중요하다.
• 코드가 간결하고 가독성이 좋으며 확장성이 높고 명확하게 계층화되어 있으며 높은 모듈성 높은 응집도 낮은 결합도를 가지고, 구현보다는 인터페이스 기반의 설계원칙을 고수하면 코드의 유지보수가 쉽다는 의미일 수 있다.

1.2.2 가독성

• SW 설계 전문가 마틴 파울러(Matin Fowler) : ”컴퓨터가 이해할 수 있는 코드는 바보라도 작성할 수 있다. 훌륭한 프로그래머는 사람이 이해할 수 있는 코드를 작성한다.“
• 코드의 명명이 의미가 있는지, 주석이 자세히 기술되어 있는지, 함수길이 적절한지, 모듈 구분이 명확한지, 높은 응집도와 낮은 결합도를 가지는지 확인

1.2.3 확장성

• 기존 코드를 약간 수정 아니면 전혀 수정하지 않는 것 만으로 새로운 기능을 추가하는 것

1.2.4 유연성

• 유연성은 추장적인 표현이다.
• 코드가 확장 및 재사용에 용이하고 사용성이 높은 경우 일반적으로 코드가 유연하다고 할 수 있다.

1.2.5 간결성

• KISS (Keep It Simple, Stupid) 원칙
• 코드를 가능한 한 단순하게 유지한다. 즉, 단순하고 면확한 코드

1.2.6 재사용성

• 코드 작성을 최소화하고 기존 코드를 재사용 하는 것
• 다양한 설계 원칙, 설계 사상, 디자인 패턴에 의해 달성되는 최종 효과
• DRY(Don’t repeat yourself)원칙

1.2.7 테스트 용이성

• 테스트 용이성 수준이 코드 품질 수준 측면을 정확하게 반영

1.3 고품질 코드를 작성하는 방법

• 고품질 코드는 1.2에서 언급한 것과 같이, 유지하기 쉽고, 읽기 쉽고, 확장하기 쉽고, 유연하고, 간결하고, 재사용이 가능하고, 테스트가 가능한 코드를 의미한다.
• 객체지향 설계 패러다임, 설계 원칙, 코딩 규칙, 리팩터링 기술, 디자인 패턴 및 일부 세련되고 구현 가능한 프로그래밍 방법론을 마스터 해야 한다.
• 이러한 궁극적인 목표는 고품질 코드를 작성하는 것이다.

1.3.1 객체지향

• 프로그래밍 패러다임 주도하는 세 가지 스타일
  • 절차지향 프로그래밍
  • 함수형 프로그래밍
  • 객체지향 프로그래밍
• 객체지향 프로그래밍은 캡슐화, 추상화, 상속, 다형성의 풍부한 특성으로 인해 복잡한 설계 사상을 실현할 수 있다.
  • 때문에 다양한 설계 원칙과 디자인 패턴 코딩 구현의 기초가 된다.
• 2장 예고
  • 객체지향의 네 가지 주요 특성
    • 캡슐화, 추상화, 상속, 다형성
  • 객체지향 프로그래밍과 절차저 프로그래밍의 차이점과 연계
  • 객체지향 분석, 설계, 프로그래밍
  • 인터페이스와 추상 클래스의 차이점과 각각 응용 시나리오
  • 구현이 아닌 인터페이스를 기반으로 한 설계 사상
  • 더 많은 합성, 더 적은 상속의 설계 상사
  • 절차적인 빈약한 도메인 모델과 객체지향의 풍성한 도메인 모델

1.3.2 설계 원칙

• 설계 원칙이 어떤 문제와 응용 시나리오를 해결하는데 사용되는 것인지 파악해야 한다.
• 설계원칙인 정신적인 방법, 디자인 패턴은 움직임
• 설계 원칙들
  • 단일 책임 원칙
  • 개방 폐쇄 원칙
  • 리스코프 치완 원칙
  • 인터페이스 분리 원칙
  • 의존 역전 원칙
  • KISS 원칙 (keep it simple stupid)
  • YAGNI 원칙 (you aren’t gonna need it)
  • DRY원칙 (don’t repeat yourself)
  • LoD원칙 (law of demeter)

1.3.3 디자인 패턴

• 개발에서 자주 접하게 되는 일부 설계 문제에 대해 요약된 솔루션 또는 설계 사상을 모아둔 것.
• 디자인 패턴의 대부분은 디커플링과 확장성 문제를 해결한다.
• 디자인 패턴의 연구는 어떤 문제와 일반적인 애플리케이션 시나리오를 과용하지 않고 해결할 수 있는지 숙달하는데 집중해야 한다.
• 프로그래밍 언어가 발전하면서, 싱글턴 패턴과 같은 일부 디자인 패턴은 더 이상 사용되지 않고 안티패턴으로 간주한다.
• 반면에 반복자 패턴같은 일부 새로운 디자인 패턴이 등장하고 있다.
• 22개의 고차원적인 디자인 패턴을 다룰 예정.
• 패턴은 범주인 생성, 구조, 행동 패턴으로 구분할 수 있다.

1.3.4 코딩 규칙

• 주로 코드의 가독성 문제를 해결한다. 더 기본적이고 중요하다.
• 코딩규칙은 설계원칙과 디자인 패턴에 비해 구체적이며, 코드 세부 사항에 중점을 두기 마련이다.
• 최소한 변수, 클래스, 함수 명명규칙, 코드 주석 다는 범위와 같은 코드 규칙에 능숙해야 한다.
• 코드 품질을 향상시키는 17가지 규칙을 요약해줄 예정.

1.3.5 리팩터링 기법

• 지속적인 리팩터링은 코드 품질 저하를 방지하는 효과
• 코드의 희망이 없는 수준의 손상을 효과적으로 방지한다.
• 리팩터링을 위한 도구
  • 객체지향 프로그래밍 패러다임, 설계 원칙, 디자인 패턴, 코딩 규칙
• 설계 원칙과 디자인 패턴의 중요한 응용 시나리오는 리팩터링
  • 디자인 패턴을 과도하게 사용하면 코드의 복잡성이 증가.
  • 초기 단계의 과도한 설계와 개발 문제를 효과적으로 방지할 수 있다.
• 리팩터링의 3가지 측면
  • 리팩터링 목적, 대상, 시기, 방법
  • 오류가 없는지 확인하기 위한 기술적 수단
  • 두 가지 다른 규모의 리팩터링 (대규모 고수준, 소규모 저수준 리팩터링)

요약

• 객체지향 프로그래밍 페러다임
  • 캡슐화, 추상화, 상속, 다형성등 풍부한 기능으로 복작한 설계 사상을 구현할수 있다.
  • 디자인 패턴 구현의 기초
• 설계 원칙
  • 코드 설계를 이끌어 내는 몇 가지 경험의 요약
  • 일반적인 방향을 나타내는 정신
  • 디자인 패턴보다 더 일반적이다.
• 디자인 패턴
  • 개발에서 자주 접하는 문제에 대한 해결방법 및 사상을 모아둔 것.
  • 디커플링을 통해 코드 확장이 주 목적.
  • 디자인 패턴은 더 구체적이고 구현하기 쉽다.
• 코딩 규칙
  • 가독성 문제를 해결
• 리팩터링
  • 코드 품질 저하를 방지
  • 객체지향 프로그래밍 패러다임, 설계원칙, 디자인 패턴, 코딩 규칙에 의존
• 최종 목적은 고품질 코드 작성

1.4 과도한 설계를 피하는 방법

• 과도한 설계는 나중에 요구사항이 변하지 않을 수도 있기 때문에 코드의 복잡성만 높일 뿐이다.

1.4.1 코드 설계 원리 의도는 코드 품질을 향상 시키는 것이다.

• 이를 적용 하는 궁극적인 목적, 원래 위도는 코드의 품질을 향상시키는 것이다.
• 왜 이런 방식으로 살게 하는지, 왜 이 디자인 부터을 제공 하는지, 실제로 코드 품질을 향상 시킬 수 있는지, 코드 품질을 어떤 측면을 계산할 수 있는지를 생각해야 한다.
• 과도한 설계는 설계를 위한 설계

1.4.2 코드의 설계 원칙은 앞에 문제가 있고, 뒤에 방안이 있다.

• 제품의 포인트(불편함을 느끼는 지점)가 어디인지, 사용자의 니즈가 무엇인지 생각하고 요구사항에 맞는 기능을 개발해야지, 화려한 기능을 먼저 개발한 후 요구사항을 끼워 맞추는 방식은 좋지 않다.

1.4.3 코드 설계의 응용 시나리오는 복잡한 코드에 적용되어야 한다.

• 간단한 문제 -> 복잡한 디자인 패턴을 사용할 필요가 없다.
• 디커플링의 주요 목적은 코드의 복잡성 처리.
• 복잡한 코드 문제를 해결하기 위해 디자인 패턴이 만들어졌다.
• 코드가 복잡할 수 록 설계에 더 많은 시간을 할애해야 한다.

1.4.4 지속적인 리팩토링은 과도한 설계를 효과적으로 방지할 수 있다.

1.4.5 특정 시나리오 외의 코드 설계에 대해 이야기 하지 않는다.

• 특정 시나리오 없이 코드 설계가 합리적인지 이야기 하는 것은 무의미.
• 비즈니스에서 아키택쳐에 대해 이야기하는 것은 비현실적이다.

[SAgiKPJH]

2 객체지향 프로그래밍 패러다임

• 객체지향 프로그래밍이 현 시점에 가장 대중적인 프로그래밍 패러다임
• 1960년에 등장

2.1 객체지향이란 무엇인가?

2.1.1 객체지향 프로그래밍과 객체지향 프로그래밍 언어

• 객체지향 프로그래밍(object-oriented programming, OOP)는 클래스와 객체
  • Java, C++, Go, Python, C#, Ruby, JavaScript, Objective-C, Scala, PHP, Perl 등이 객체지향 프로그래밍 언어
• 1. 객체지향 프로그래밍은 프로그래밍 패러다임 또는 프로그래밍 스타일
  • 코드를 구성하는 기본 단위로 클래스 또는 객체 사용
  • 캡슐화, 추상화, 상속, 다형성의 4가지 특성 사용
• 2. 1)을 위한 문법을 지원하며 쉽게 구현할 수 있다.

2.1.2 엄격하게 정의되지 않은 객체지향 프로그래밍 언어

• 다양한 객체지향 수용
  • 엄격하게 정의되지 않은 경우, JavaScript는 캡슐화와 상속기능을 지원하지 않지만 객체지향 프로그래밍 언어.
  • 상속이 불명확한 수준과 혼란스러운 코드를 쉽게 야기 -> 따라서 Go 언어는 상속을 포기
• 클래스 또는 객체의 문법적 개념을 지원하고, 코드 구성의 기본 단위로 사용하는 한 객체지향 프로그래밍 언어로 간주할 수 있다.

2.1.3 객체지향 분석과 객체지향 설계

• 객체지향 분석 (object-oriented analysis, OOA), 객체지향 설계(object-oriented design, OOD)
  • 객체나 클래스에 대한 요구 사항을 분석하고 설계
• 객체지향 소프트웨어 개발의 3단계
  • 객체지향 분석-설계-프로그래밍

2.1.4 UML에 대한 참고사항

• 통합 모델링 언어(unified model language, UML)
  • 클래스 다이어그램, 유스케이스 다이어그램, 시퀀스 다이어그램, 액티비티 다이어그램, 상태 다이어그램, 컴포넌트 다이어그램 등 복잡한 도구

2.2 캡슐화, 추상화, 상속, 다형성이 등장한 이유

• 자신에게 익숙한 언어의 프레임워크와 문법에만 집중해서는 안 된다는 점을 명심하자

2.2.1 캡슐화

• 캡슐화(encapsulation)는 정보 은닉 또는 데이터 엑세스 보호
• 이 문법을 접근제어라고 한다.
• 접근 제어 하지 않으면
  • 속성에 접근하고 값을 변경할 수 있다.
  • 과도한 유연성은 제어할 수 없다.
  • 속성이 여러가지 이상한 방식으로 수정될 수 있다.
  • 코드의 모든 구석에 흝어져 코드의 가독성과 유지 관리 용이성에 영향을 준다.
• 필요한 작업만 노출
  • 클래스 사용성 향상
  • 비즈니스 세부사항에 대해 충분한 이해 없이 속성을 올바르게 조작 불가능
  • 모든 비즈니스를 완벽하게 이해하지 않아도 잘못 사용할 가능성이 크게 줄어든다.
  • 단순화하고 정리하는 것만으로도 학습 비용이 많이 줄어들고 오류 확률도 낮아진다.

2.2.2 추상화

• 추상화 (abstraction)는 메서드의 내부 구현을 숨기는 것
• 클래스의 메서드가 프로그래밍 언어에서 함수라는 문법을 통해 구현
  • 이러한 구현을 숨김
• 추상화는 객체지향의 네가지 주요 특성에서 제외되는 경우가 있다.
  • 함수라는 기본 문법만 제공해도 충분
  • 추상화는 특이성이 그리 높지 않으며, 객체지향 프로그래밍의 특성으로 간주되지 않는 경우가 있다.
• 추상화와 캡슐화는 인간이 복잡한 시스템을 다룰 수 있게 해주는 효과적인 수단이다.
  • 구현이 아닌 기능에만 초점을 맞춘 설계 사상인 추상화는, 뇌가 불필요한 많은 정보를 걸러내는 데 도움이 된다.
• 추상화의 네이밍
  • 추상적인 이름을 사용

2.2.3 상속

• 상속(inheritance)
• 다중 상속은 하위 클래스가 여러 상위 클래스를 동시에 상속할 수 있음을 나타낸다.
  • Java : extends 키워드
  • C++ : 콜론(:)
  • python : ()
  • Ruby : <
• Java, PHP, C#, Ruby등과 같은 일부 프로그래밍 언어는 단일 상속만 지원
• C++, Python, Perl같은 경우에는 단일 상속과 다중 상속 모두 지원
• 상속의 가장 큰 역할은 코드의 재사용
  • 상속의 특성은 이해하기 쉬울 뿐 만이 아니라, 사용하기 쉽다.
  • 과도하게 사용할 경우 가독성과 유지관리성이 떨어진다.
  • 심지어 모든 상위 클레스를 살펴볼 필요가 있을 수 있다.
• 상속은 적게 사용해야 한다.

2.2.4 다형성

• 다형성 (polymorphism)은 하위 클래스를 상위 클래스 대신 사용, 하위 클래스 메서드를 호출할 수 있는 특성
• 세 가지 문법
  • 1. 상위 클래스 객체가 하위 클래스 객체를 참조할 수 있어야 한다.
  • 2. 상속을 지원해야 한다.
  • 3. 상위 클래스의 메서드를 재정의하는 하위 클래스를 지원해야 한다.
• 상속과 메서드 재정의 방식외의 다형성 특성 구현을 위해서 인터페이스 문법 또는 duck-typing 문법을 사용한다.
  • C++언어는 인터페이스 문법을 지원하지 않으며, duck-typing 문법은 python이나 javascript같은 일부 동적인 언어에서만 지원한다.
• 두 클래스가 동일한 메서드를 가지고 있으면 두 클래스 간의 관계를 요구하지 않고 다형성 달성할 수 있다. (Duck-typing)
• 다형성 목적
  • 코드의 확장성을 향상
  • 코드의 재사용성을 향상
• 다형성의 활용
  • 전략 패턴, 구현이 아니다.
  • 인터페이스 기반의 프로그래밍, 의존성 역전의 원친, 리스코프 치환 원친, 다형성을 이용하여 if-else 구문을 제거와 같은 디자인 패턴, 설계원칙, 프로그래밍 테크닉 코드 구현의 기초이다.

2.3 객체지향 분석-설계-프로그래밍 수행 방법

• 일반적인 개발에 직면하는 문제
  • 요구 사항 분석은 어떻게 해야 하는가?
  • 책임 분감은 어떻게 해야 하는가?
  • 어떤 클래스를 정의해야 하는가?
  • 각 클래스에는 어떤 속성과 메서드가 있어야 하는가?
  • 각각의 클래스는 어떻게 상호작용 하는가?
  • 클래스를 실행 가능한 프로그램으로 조합하는 방법은 무엇인가?

2.3.1 예제 소개와 난이도 분석

• 1. 요구 사항이 불분명하다
• 2. 훈련이 안되어 있고, 경험이 부족하다.

2.3.2 객체지향 분석 수행 방법

• 요구사항 분성 작업은 하찮게 여겨지고, 특별하게 정해진 규칙이 없다. -> 자신만의 분석 방법을 개발하자.
• 요구사항 분석 프로세스는 지속적인 반복 최적화 프로세스
• 요구사항 분석 프로세스를 4단계로 나누어 최종적으로 실행과 구현이 가능한 요구사항 목록을 만들자 (예시)
• 1. 기본 분석
• 2. 1차 분석
• 3. 2차 분석
• 4. 3차 분석

2.3.3 객체지향 설계 방법

• 객체지향 설계 프로세스 4단계
  • 1. 책임과 기능을 나누고 어떤 클래스가 있는지 확인
    • 요구사항 명세에 있는 명사를 가능한 후보 클래스로 나열, 이후 필터링.
    • 어떤 기능들이 유사한 책임을 지고 동일한 속성을 사용하는지 분류
    • 단일 책임 기능으로 분해
    • 객체지향 프로그래밍은 본질적으로 반복을 통한 지속적인 최적화 프로세스, 대략적인 설계 계획을 제공한 다음에 반복적인 최적화를 수행하여 더 명확한 구현을 해 나간다.
    • 복잡한 경우, 모듈 내부에 객체지향 설계를 한다. -> 모듈의 디커플링, 식별과 클래스의 디커플링, 식별 같은 방법 사용
  • 2. 클래스 정의, 클래스 속성과 메서드 정의
    • 각 필요한 클래스에 어떤 속성과 메서드가 있는지 확인, 명세에서 동사나 명사를 추출하여 필터링 통해 정의
    • 세부 사항을 통해 현재 요구사항만 가지고는 개발이 불가능한 클래스의 속성 및 메서드가 무엇인지 알 수 있다.
    • 클래스 정의의 무결성 보장 및 향후 나타날 요구사항 개발에 대비할 수 있다.
  • 3. 클래스 간의 상호 작용을 정의
    • 클래스 간의 여섯 가지 관계
      • 일반화 (generalization)는 단순한 상속 관계
        • public class B extends A {…} // class A
      • 실체화 (realization) 인터페이스와 구현 클래스 간의 관계
        • public class B implements A {…} // interface A
      • 집합 (aggregation) 포함 관계
        • public class A { private B b; } // B 주입
      • 합성 (composition) 관계
        • public class A { private B b; } // B new 생성
        • A의 수명주기에 따라 B의 수명주기 결정
      • 연관 (association) 집합과 합성의 구 가지 속성, 매우 약한 관계
      • 의존 (dependency) 연관 관계를 포함, 연관관계보다 더 약한 관계
        • 집합 + 합성 + public void func(B b){…}
    • 네 관계 중에 일반화, 실체화, 의존에 대한 정의는 그대로 두되, 합성은 집합과 연관을 통합하는 관계로 정의
    • 더 많은 합성, 더 적은 상속 설계 원칙
  • 4. 클래스 연결하고 실행 엔트리 포인트 제공
    • 모든 클래스를 함께 조합하고 실행 엔트리 포인트 제공

2.3.4 객체지향 프로그래밍 하는 방법

• 객체지향 설계를 통해 클래스, 속성, 메서드, 클래스 간의 상호 작용을 정의, 모든 클래스를 조합, 통합된 엔트리 포인트가 준비된 상태가 된다.
• 설계 사상을 코드로 실체화

• 대부분 프로그래머는 종종 객체지향 분석과 객체지향 설계를 머리속이나 간단한 스케치로 마친 후 바로 코드 작성할 뿐만 아니라, 코드 작성 도중에도 최적화와 리팩터링 하는 경우가 많다.
• 반대로 코드를 작성하기 전에 분석과 설계를 했어도 모든 세부 사항과 상호작용을 한번에 다 정의하는 것은 불가능하다.
• 결국 소프트웨어 개발은 본질적으로 지속적인 반복, 패치, 문제 발견, 문제 해결하는 과정이며, 지속적인 리펙토링의 과정이다.
• 하나의 단계를 모두 마치고 다음 단계로 넘어가는 것은 불가능 하다.

2.4 객체지향 프로그래밍, 절차적 프로그래밍, 함수형 프로그래밍 차이

2.4.1 절차적 프로그래밍

• 객체지향과 마찬가지로, 공식적인 정의가 없지만, 그 차이를 나타내기 위해 아래와 같이 정의
• 절차적 프로그래밍
  • 코드를 구성하기 위한 기본 단위로 메서드, 기능, 연산처럼 절차가 필요
  • 맴버변수, 속성과 같은 데이터가 메서드와 분리되어 있다.
  • 순서대로 실행되는 메서드들을 나열하여 데이터를 조작, 기능 구현하는 프로그래밍 스타일
• 객체지향과의 차이
  • 절차 : 데이터 구조의 조합으로 구성되며, 메서드와 데이터 구조의 정의는 서로 관계가 없다.
  • 객체 : 메서드와 데이터 구조가 하나의 클래스로 정의, 매우 밀접한 관계를 가진다.

2.4.2 객체지향 프로그래밍과 절차적 프로그래밍의 비교

• 1. 객체지향 프로그래밍은 대규모의 복잡한 프로그램 개발에 더 적합하다
  • 객체지향은 모듈화를 강제하며, 절차적 프로그래밍은 강제하지 않는다.
• 2. 객체지향 프로그래밍 스타일의 코드는 재사용, 확장, 유지관리가 쉽다.
• 3. 객체지향 프로그래밍 언어는 더 사용자 친화적이고 고급 언어이며 지능적이다.
  • 이진 명령, 어셈블리 언어, 절차 프로그래밍 언어는 컴퓨터의 사고 방식
  • 객체 지향 언어는 인간의 사고 방식

2.4.3 함수형 프로그래밍

• 객체지향의 큰 특징 : 클래스와 객체를 코드의 구성 단위
• 절차지향 큰 특징 : 함수를 단위로 사용하여 코드를 구성하고, 데이터와 메서드를 분리
• 함수형 : 수학적 함수 또는 표현식의 조합, 코드의 구성 단위로 함수를 사용하지만, 상태를 가지고 있지 않는 스테이트리스 함수(stateless function)
• c언어에서는 함수 포인터로 비슷하게 구현 가능
• 구현 방식
  • java -> Stream 클래스
  • 람다
  • 함수형 인터페이스 (예-Func<A, T>)

2.4.4 객체지향 프로그래밍과 함수형 프로그래밍의 비교

• 객체지향 : 클래스 설계륿 비롯한 코드 모듈 설계애 중점
• 함수형 : 함수 작성과 같은 특정 구현 세부 사항에 중점

2.5 객체지향 프로그래밍 처럼 보이지만 실제로는 절차적 프로그래밍

2.5.1 getter, setter 메서드 남용

• 프로그래밍의 캡슐화 특성 위반

2.5.2 전역 변수와 전역 메서드 남용

• 정적 메서드는 메서드를 데이터에서 분리하고 캡슐화 기능을 제거한 일반적인 절차적 프로그래밍 스타일
• 코드 재사용 측면에서 좋을 수 있다.
• 적당한 수준에서 도입

2.5.3 데이터와 메서드 분리로 클래스 정의

• MVC, VO-BO-Entity 방식이 이에 해당
• 이를 제외한 일반적인 메서드와 데이터 분리
• JDK, Apache Commons, Google Guava같은 일부 표준 개발 라이브러리에도 절차적 프로그래밍 스타일 코드가 많이 포함.

2.6 빈약한 도메인 모델에 기반하나 전통적인 개발 방식은 OOP를 위반하는가?

2.6.1 빈약한 도메인 모델에 기반한 전통적인 개발 방식

• MVC 아키텍처
  • 프레젠테이션, 논리, 데이터 3가지 계층으로 구분
  • 예) 백엔드 프로젝트를 저장소, 서비스, 컨트롤러 세 계층으로 나누는 것
• 빈약한 도메인 모델 (anemic domain model)
  • 데이터만 포함하고 비즈니스 논리를 포함하지 않는 UserBo같은 클래스

2.6.2 풍성한 도메인 모델에 기반한 DDD 개발 방식

• 풍성한 도메인 모델 (rich domain model)
  • 데이터와 비즈니스 논리가 하나의 클래스에 포함
• DDD는 주로 비즈니스 시스템, 비즈니스 모듈을 분리 분할, 비즈니스 도메인 모델과 상호 작용을 정의하는 방법 설계
  • 2004년에 제안, 20년 가까이 개발
  • DDD는 애자일 개발, SOA, PaaS등과 유사

• DDD 개발 방식과 빈약한 도메인 모델의 차이
  • 빈약한 도메인 모델 : 서비스 계층은 Service 클래스와 BO클래스 두 부분으로 구성
    • BO클래스는 데이터맘 포함하는 대신, 특정 비즈니스를 포함하지 않는 빈약한 도메인 모델
  • DDD 개발 방식 : 서비스 계층은 Service 클래스와 Domain 클래스 두 부분으로 구성
    • Domain 클래스가 데이터와 비즈니스 논리를 모두 포함한 풍성한 도메인 모델 기반으로 개발
• 강조 내용
  • 빈약한 도메인 모델은 Service 클래스와 가벼운 BO 클래스를 강조
  • 풍성한 도메인 모델(예 DDD개발 방식)은 Service 클래스와 Domain 클래스를 강조

2.6.3 두 개발 방식의 비교

• 풍성한 도메인 모델 기반 DDD 개발 방식에서 Service 클래스가 여전히 남아이쓴 이유
  • Service 클래스는 저장소와 계층과의 통신을 담당
  • Service 클래스는 여러 도메인 모델과 비즈니스 논리를 결합한다.
  • Service클래스는 기능과 무관한 타 시스템과의 상호작용을 담당한다.
• 컨트롤 계층과 저장소 계층은 여전히 빈약한 모델로 작성되어 있다.
  • 컨트롤 계층은 주로 인터페이스를 노출시키는 역할
  • 저장소 계층은 데이터베이스를 처리하는 역할
  • 이 두 계층에는 그다지 많은 비즈니스 논리가 포함되어 있지 않다.
  • 비즈니스 논리가 비교적 단순하다면, 굳이 풍성한 도메인 모델로 설계할 필요가 없다.

• 컨트롤 계층의 VO
  • VO는 DTO(data transfer object)인데, 주로 다른 시스템으로 데이터 보내기 위한 인터페이스의 데이터 전송 캐리어
  • 데이터만 포함해야 하기 때문에 빈약한 도메인 모델로 설계하는 것이 합리적

2.6.4 빈약한 도메인 모델에 기반한 전통적인 개발 방식이 널리 사용되는 이유

• 현재 거의 모즌 백엔드 비즈니스 시스템은 이러한 빈약한 도메인 모델 개발 방식을 기반으로 설계
• 절차적 프로그래밍의 단점
  • 데이터와 연산이 분리, 모든 코드에서 데이터를 마음대로 수정 가능
• 빈약한 도에민 모델에 기반한 개발 방식은 절차적 프로그래밍 스타일인데도 불구하고 따르는 이유
  • 개발하는 시스템의 비즈니스가 비교적 단순
  • 풍성한 도메인 모델은 빈약한 도메인 모델보다 설계하기가 훨씬 까다롭다.
  • 일반적으로 사고방식은 한 번 자리 잡으면 변하기 어렵고, 변화에는 그만한 대가가 필요하다.

2.6.5 풍성한 도메인 모델에 기반한 DDD개발 방식의 응용 시나리오

• 풍성한 도메인 모델에 기반한 DDD 개발 방식을 사용하는 것을 고려해야 하는 요소
  • 복잡한 비즈니스 시스템을 개발하는 데 적합
  • 빈약한 도메인 모델을 풍성한 도메인 모델 방식이 무난하게 대처 가능할까?
  • 개발 방식 차이로 인해 개발 프로세스 자체가 바뀌게 된다.
• 일반적인 개발 작업은 대부분 SQL 기반
• 복잡한 비즈니스 시스템 개발의 경우, 이러한 개발 방법은 코드를 더 혼란스럽게 만들고 결국 유지관리를 할 수 없는 지경에 이르게 된다.
  • 따라서 초기 설계에 더 많은 시간을 투자해야 한다.

2.7 추상 클래스와 인터페이스

• 인터페이스를 사용하여 객체지향의 추상화, 다형성, 설계원칙을 구현
• 추상 클래스를 사용하여 객체지향 상속과 템플릿 디자인 패턴을 구현
• 언어별 지원 내용
  • C++와 같은 프로그래밍 언어는 추상클래스만 지원하고, 인터페이스는 지원하지 않는다.
  • Python과 같은 동적 프로그래밍 언어는 추상 클래스 지원하지 않는 대신, 인터페이스를 지원한다.

2.7.1 추상 클래스와 인터페이스의 정의와 차이점

• 추상 클래스의 특성
  • 인스턴스화 할 수 없으며 상속만 가능 (new 를 통해 추상 클래스의 객체를 생성할 수 없다)
  • 코드 구현을 포함하지 않을 수 있다.
  • 하위 클래스는, 모든 추상 메서드를 실제로 구현해야 한다.
  • 하위 클래스와의 상속 관계는 is-a
• 인터페이스의 특성
  • 인터페이스는 속성을 포함할 수 없다.
  • 실제 코드 구현을 포함할 수 없다.
  • 인터페이스에 선언된 모든 메서드를 구현해야 한다.
  • 하위 클래스와의 상속 관계는 has-a (계약)

2.7.2 추상 클래스와 인터페이스의 의미

• 추상 클래스는 코드 재사용을 위해 사용
  • 하위 클래스에서 동일한 코드를 다시 작성하지 않아도 된다.
• 상속을 통해 코드의 재사용 목적을 달성할 수 있다.
  • 추상 클래스를 사용하지 않아도 상속을 통한 재사용 가능
  • 하지만 추상클래스를 사용하는 이유
    • 모든 클래스의 상속관계를 확인하면서 설계의도를 파악해야 하는 추가 비용이 발생한다.
    • 추상 클래스는 메서드 재정의를 강제하므로, 사전에 잊어버리는 것을 방지
    • 추상 클래스가 아닌 일반 클래스로 생성하면, 비어있는 상위 클래스를 잘못 생성(new)할 수 도 있다.
• 추상 클래스 : 코드 재사용 초점
• 인터페이스 : 디커플링에 초점
  • 규칙과 구현의 분리를 실현하여 코드의 결합 정도를 줄이고 코드의 확장성을 향상

2.7.3 추상 클래스와 인터페이스 모의 구현

• C++의 추상 클래스로 인터페이스 모방 가능
  • Strategy 추상 클래스는 어떠한 속성도 가지지 않고 모든 메서드가 virtual 타입으로 선언되어 있어, 하위 클래스는 이를 구현해야 한다.
  • 인터페이스와 와전히 동일

class Strategy {
  public:
    virtual ~Strategy();
    virtual void algorithm() = 0;

  protected: 
    strategy();
};

• python, ruby과 같은 동적 프로그래밍 언어에서는 인터페이스 및 추상 클래스가 없다.
  • 일반 클래스로 인터페이스 모방 가능
  • 하위 클래스가 메서드를 구현하도록 예외 발생을 통해 능동적으로 구현하도록 강제할 수 있다.
  • 아래 클래스가 인스턴스화 되는 것을 막기 위해서 생성자를 protected 속성으로 설정하면 된다.
  • 하지만 다른 패키지의 클래스가 MockInterface를 인스턴스화 할 수 있는데, 이는 Google Guava에서 사용하는 @VisibleForTesting 주석 관행을 활용하여 인스턴스화 할 수 없음을 주석으로 나타내도록 사용자 정의 할 수 있다.

public class MockInterface {
  protected MockInterface() {}

  public void funcA() {
    throw new MethodUnSupprotedException();
  }
}

2.7.4 추상 클래스와 인터페이스의 응용

• is-a 관계를 나타내고자 하고, 코드의 재사용 문제를 해결하려 할 땐 추상클래스
  • 클래스 상속 관점에서 추상 클래스는 상향식 설계 방식
  • 하위 클래스의 코드를 반복한 다음에 상위 클래스를 추상화한 것이 추상 클래스
• has-a 관계를 나타내고자 하고, 코드 재사용 문제가 아닌 추상화 문제를 해결하려면 인터페이스
  • 클래스 상속 관점에서 인터페이스는 하향식 설계 방식
  • 인터페이스 먼저 설계한 뒤 구현 고려

2.8 인터페이스 기반 프로그래밍 : 모든 클래스에 대해서 인터페이스를 정의해야 할까?

• 인터페이스와 관련된 설계 사상

2.8.1 인터페이스를 이해하는 다양한 방법

• 본질적으로 인터페이스는 프로토콜 또는 규약의 집합, 사용자에게 제공되는 기능의 목록
  • 프로토콜의 집합도 인터페이스라고 부를 수 있다. (상위 수준의 추상적인 이해, 실제 코드와 관련이 없는 정의)
• 인터페이스 기반 프로그래밍을 통해
  • 구현과 인터페이스를 분리
    • 시스템끼리 인터페이스 프로그래밍과 연결
  • 캡슐화하여 불안정한 구현 감추기
    • 불안정한 구현 세부사항 의존하지 않아도 된다.
  • 구현되는 세부사항이 변경되더라도 업스트림 시스템 코드를 기본적으로 변경할 필요가 없으므로 결합을 줄이고 확장성 향상
• 추상화 기반 프로그래밍
  • 이 설계 사상이 원래 의도를 더 잘 반영
  • 소프트웨어 개발에서 가장 큰 과제는 변화하는 요구사항을 처리하는 방법
  • 추사화, 탑 레벨 아키텍처, 구현에 영향을 받지 않는 설계는 코드의 유연성을 높여주며, 이후 요구사항이 변경되더라도 훨씬 더 잘 대응할 수 있게 된다.
  • 요구사항이 변경이 될 때 조차도 기존의 코드 설계를 훼손하지 않고 유연하게 대응
  • 코드의 확장성과 유연성, 유지보수성을 향상시키는 효과적인 수단

2.8.2 설계 철학을 실제로 적용해보자

• 인터페이스 기반의 설계 철학
  • uploadToAWS() 보다는 추상적인 upload() 메서드로 명명
  • 구체적인 구현 세부사항은 캡슐화
  • 추상 인터페이스를 정의해서, 인터페이스체 의존하여 사용하도록 한다.
• 설계 철학 적용 핵심
  • 코드를 작성할 때 추상화, 캡슐화, 인터페이스에 대해서 항상 정확히 인식할 것.
  • 구현 세부 정보를 노출하지 않으면서, 구체적인 수행방법이 아닌, 어떤 작업을 수행하는지만 고려
  • 현재 인터페이스 설계가 보편적인지, 인터페이스 정의를 변경하지 않고도 다르게 구현할 수 있는지 신중하게 고려할 것.

2.8.3 인터페이스의 남용을 방지하려면 어떻게 해야 할까?

• 인터페이스의 의도
  • 구현에서 인터페이스를 분리하고 불안정한 구현을 캡슐화하고 안정적인 인터페이스를 노출
  • 불안정한 구현 세부 사항에 의존하지 않는다.
  • 코드의 확장성
• 인터페이스 불필요한 상황
  • 비즈니스 시나리오에서 특정 기능에 대한 구현 방법이 하나 뿐 인경우, 이후에도 다른 구현 방법으로 대체할 일이 없는 경우 -> 구현 클래스를 직접 사용
  • 동시에 두 개의 구현이 사용되지 않는 경우 -> 클래스 또는 추상 클래스를 직접 수정\
  • 함수의 정의가 충분히 추상적인 경우 -> 인터페이스 구현 없이도 충분히 추상화 사상 만족

2.9 상속보다 합성

• 고전적인 객체지향 프로그래밍의 설계 원칙
  • 합성이 상속보다 낫고, 상속보다 합성을 더 많이 사용하는 것 처럼 보여, 상속을 추천하지 않는다.

2.9.1 상속이 더 이상 사용되지 않는 이유

• 상속의 가장 큰 문제는 상속 계층이 너무 깊고 상속 관계가 너무 복잡하기 때문에, 코드의 가독성과 유지 보수성에 영향을 미친다.
  • 모든 상위 클래스를 파악해야 한다.
  • 상위 클래스의 정보를 하위 클래스에 노출하게 되므로 캡슐화 특성을 깨트린다.
  • 상위 클래스 코드 수정 -> 모든 하위 클래스에 영향

2.9.2 합성이 상속에 비해 나은 장점

• 합성(composition), 인터페이스, 위임(delegation)을 통해 상속의 문제를 개선할 수 있다.
  • 특정한 작업의 속성을 나타내는 인터페이스 구현 (예-fly, tweet, lay egg)
  • 여러 인터페이스를 구현하는 구현체 클래스 구현 (예-FlyAbility, TweetAbility, EggLayAbility) -> 코드의 중복 문제 해결
  • 위임

public interface Flyable {
  void fly();
}
public class FlyAbility implements Flyable {
  @Override
  public void fly() { ... }
}
...
public class Ostrich implements Tweetable, EggLayable { // 타조 클래스
  private TweetAbility tweetAbility = new TweetAbility(); // 합성
  private EggLayAbility eggLayAbility = new EggLayAbility(); // 합성

  @Override
  public void tweet() {
    tweetAbility.tweet(); // 위임
  }

  @Override
  public void layEgg() {
    eggLayAbility.layEgg(); // 위임
  }
}

• 결과
  • 상속을 합성, 인터페이스, 위임으로 대체 가능
  • is-a 관계를 has-a 관계로 변경
• 상속의 기능 대체
  • is-a 관계 표현 -> 합성과 인터페이스 has-a 관계로 대체
  • 다형성 지원 -> 인터페이스 사용하여 달성
  • 코드 재사용 -> 합성과 위임으로 달성

2.9.3 합성을 사용할지, 상속을 사용할지 결정하기

• 합성을 더 많이 사용하고, 상속을 덜 사용하도록 권장하지만, 합성이 언제나 완벽하게 동작하는 것이 아니며, 상속이 항상 쓸모 없는 것이 아니다.
• 합성
  • 더 많은 클래스와 인터페이스를 구현해야 한다는 뜻
  • 코드의 복잡성과 유지 관리 비용 증가
• 상속 사용하는 경우
  • 상속 구조가 안정적, 쉽게 변경되지 않고 2단계 이하로 얕은 경우
  • 상속관계가 복잡하지 않는 경우
• 합성을 더 많이 사용하고, 상속을 덜 사용하도록 권장하는 이유
  • 과거 프로그래머가 오랫동안 상속을 남용했기 때문
  • 합성은 완벽하지 않으며, 상속이 항상 쓸모 없는 것이 아니다.
  • 다양한 상황에서 상속이나 합성을 적절히 선택하는 것이 중요

[SAgiKPJH]

3 설계 원칙

• 고전적인 설계원칙
  • SOLID
  • KISS
  • YAGNI
  • DRY
  • LoD
• 고전적인 설계원칙을 실제 프로젝트에서 사용하는 방법 이해
• 목적
  • 설계 원칙 정의
  • 원칙의 원래 의도
  • 어떻게 사용하는지
• 고전적인 디자인 패턴은 모두 확장성을 해결하기 위해 고안

3.1 단일 책임 원칙

• SOLID 원칙
  • 단일 책임원칙
  • 개방 폐쇄 원칙
  • 리스코프 치환 원칙
  • 인터페이스 분리 원칙
  • 의존 역전 원칙
• 단일 책임 원칙 (single responsibility principle, SRP)
  • 클래스와 모듈은 하나의 책임 및 기능만 가지고 있어야 한다는 설계 원칙
  • 거대하고 포괄적인 클래스 대신, 작은 단위의 단일 기능을 가진 클레스를 설계
  • 책임이 2가지 이상 포함되어 있으면, 단일 기능을 가진 여러 작은 클래스들로 분할해야 한다
  • 시나리오 및 요구사항에 따라 단일 책임의 기준이 달라진다.
• 2가지 유형
  • 클래스 하나를 일종의 모듈로써 단일책임 원칙
  • 클래스들을 하나의 모듈로써 단일책임 원칙
• 클래스에 단일 책임이 있는지 확인 방법 (3.1.2)
  • 클래스에 코드 함수가 너무 많은 경우, 클래스 분할 (가독성과 유지보수성)
  • 클래스가 너무 과하게 의존, 클래스 분할 (높은 응집도와 낮은 결합도)
  • private 메서드가 너무 많은 경우, 클래스 분할(재사용성)
  • 클래스 이름 어려울때, 클래스 책임 정의가 명확하지 않다.
  • 클래스의 메서드가 여러 속성중 일부만 작동하는 경우, 분할
• 최대한 분할하는 것이 좋지만은 않다. (3.1.3)
  • 예) 직렬화를 직렬화, 역직렬화로 나눌 수 있는데, 비료율적이다.
  • 코드의 가독성과 확장성, 재사용성, 유지보수성을 향상시키는 것이 목적임을 잊지 말자.

3.2 개방 폐쇄 원칙

• 개방 폐쇄 원칙 (open-closed principle, OCP)
  • 확장할 때는 개방, 수정할 때는 폐쇠
  • 새로운 기능을 추가(요구사항 추가)할 때는 기존 코드를 기반으로 모듈, 클래스, 함수를 추가하는 방식으로 확장
  • 수정을 아예 안하는 것이 아니라 수정을 가능한 상위 수준 코드에서 진행
  • 코드의 확장성이 품질에 중요한 척도이기 때문에 중요하다.
  • 예) IShape는 Circle, Rectangle 확장에는 개방이고 새로운 AreCalculator에서 IShape에 또 다른 내용 수정이 필요 없도록 구성
• 핵심
  • 확장성 문제, 확장하기 쉬운지 판단하는 표준
  • 확장에는 확장, 추상화, 캡슐화 인식 필요
  • 앞으로 요구사항이 추가될 가능성이 있는지 판단할 것
  • 변경 가능 부분과 불가능 부분을 잘 식별할 것
• 방법
  • Handler 클래스 시스템
  • 디자인 패턴의 목적 자체가 코드의 확장성이며, 개방폐쇠 원칙을 기본으로 한다.
  • 다형성, 의존성 주입, 인터페이스 기반 프로그래밍 등등
  • 단기간
    • 단기간 진행 가능한 확장
    • 코드 구조 변경에 미치는 영향이 비교적 큰 확장
    • 구현 비용이 많이 들지 않은 확장
    • 3가지 확장에 대해 포인트를 미리 준비할 것
  • 확장 지원 여부가 불확실한 경우엔
    • 해당 작업이 필요할 때 리팩터링
• TradeOff

3.3 리스코프 치환 원칙

• 리스코프 치환 원칙 (Liskov substitution principle, LSP)는 1986년 MIT 의 바바라 리스코프 교수에 의해 제안된 원칙
• 느슨한 설계 원칙이기 때문에, 정상적인 상황에서 작성하는 코드는 위반하지 않는다.
• 하위 유형 또는 파생 클래스의 객체는 프로그램 내에서 상위 클래스가 나타나는 모든 상황에서 대체 가능하며, 프로그램이 원래 가지는 넌리적인 동작이 변경 되지 않으며 정확성도 유지된다
  • 만약에 S가 T에 합위 유형인 경우, T 유형의 객체는 프로그램을 중단 하지 않고도 S 유형의 객체로 대체 할 수 있다
  • 기본 클래스에서 참조 포인터를 사용하는 함수는 특별히 인지 하지 않고도 파생 클래스의 객체를 사용할 수 있어야 한다
  • 계약에 따른 설계(design by contract), 하위 클래스 설계할 때는 상위 클래스의 동작 규착을 따라야 한다.
    • 동작 규칙 : 함수 구현위해 선언한 것, 입력, 출력, 예외 규칙, 주석에 나열된 특수사례 설명
    • 이는 인터페이스와 구현 클래스로 대체 가능
• 리스코프 치환 원칙과 다형성의 차이점
  • 엄격한 다형성, 상위 클래스를 대체할 때 논리적 동작이 변경되지 않고 프로그램의 정확성이 손상되지 않도록 해야 한다.
• 리스코프 치환 원칙을 위배하는 안티패턴
  • 상위 클래스에서 선언한 기능을 위반하는 경우
  • 입력, 출력, 예외에 대한 상위 클래스 계약을 위반하는 경우
  • 주석에 나열된 특별 지침을 위반하는 경우
• 예방
  • 상위 클래스의 단위 테스트를 통해 하위 클래스의 코드를 확인하는 방법

3.4 인터페이스 분리 원칙

• 인터페이스 분리 원칙 (interface segregation principle)
  • 클라이언트(호출자, 사용자)는 필요하지 않은 인터페이스를 사용하도록 강요되어서는 안된다.
• 인터페이스
  • API나 기능의 집합
    • 불필요한 항목을 강요하는 대신, 인터페이스나 기능에서 해당 부분을 분리하여 호출자에게 별도 제공해야 하며, 사용하지 않는 인터페이스나 기능은 접근하지 못하게 한다.
    • 예, CRUD -> CR만 허용하는 인터페이스 따로 제공, UD 강요 x
  • 단일 API 또는 기능
    • API나 기능은 가능한 한 단순, 하나의 기능에 여러 다른 기능 논리를 구현하지 않아야 한다.
    • 인터 페이스 분리 원칙은 단일 책임 원칙과 다소 유사
  • 객체지향 프로그래밍의 인터페이스
    • 여러 조건에 따라 인터페이스 분리 적용, Update 인터페이스와 View 인터페이스 단일 기능 가지도록 구성
    • 설계가 더 유연하기 때문에 확장성이 높고 재사용성이 높다

3.5 의존 역전 원칙

• 의존 역전 원칙 (dependency inversion principle, DIP)
• 제어 반전 (inversion of control)
  • 제어 역전

public abstract class TestCase {
  public void run() {
    If (doTest()) { /* … */}
  }

  public abstract Boolean doTest();
}

public static void register(TestCase testCase) {
  testCase.add(testCase);
}

for( TestCase testCase : testCases)
  testCase.run();

• 의존성 주입
  • new 예약어 객체를 생성하는 대신, 외부에서 생성 후 주입하는 것.
  • 의존성 주입이 테스트 가능한 코드를 작성하는 효과적인 수단.
• 의존성 주입 프레임워크 (dependency injection framework)
  • 제어반전 컨테이너 (inversion of control container)
• 의존 역전 원칙
  • 상위 모듈(호출자)은 하위 모듈(수신자)에 의존하지 않아야 하며, 추상회에 의존해야 한다.

3.6 KISS 원칙과 YAGNI 원칙

• KISS 원칙
  • 가능한 한 단순하게 유지하라는 대전제는 비슷
  • Keep It Simple and Stupid, Keep It Short and Simple, Keep It Simple and Straight forward
  • 포괄적인 설계 원칙
  • 단순하게 유지하라고 말 할 뿐, 어떻게 개발해야 하는지 명확한 방법도 제공하지 않는다.
• 적은 줄 수의 코드가 더 간단하지 않다.
  • 정규표현식만 사용하는 경우, 정규 표현식에 익숙하지 않은 사람은 코드를 이해하기 어렵고 관리하는 것 자체가 어렵다.
• 복잡한 코드가 반드시 KISS 원칙을 위반하는 것은 아니다
  • 복잡한 알고리즘을 사용하여 복잡한 문제를 해결하는 것은 KISS원칙에 위배되지 않는다.
• KISS 원칙을 만족하는 코드 작성 방법
  • 복잡한 정규표현식, 프로그래밍 언어 제공에 지나치게 높은 레벨의 코드등 지나치게 복잡한 기술을 사용하여 코드 구현하지 않는다.
  • 바퀴를 다시 발명(reinvent the wheel)하는 대신, 기존 라이브러리를 사용하는 것을 고려 (직접 구현은 오류 발생 확률 오르고, 유지 관리 비용도 높아진다)
  • 과도하게 최적화하지 않는다. If-else대신 복잡한 조건문 사용 최소화
• YAGNI와 KISS 차이
  • YAGNI(you ain’t gonna need it)
  • 현재 사용되지 않는 기능를 설계하지 말고 작성하지 않는다는 의미이다.
  • 과도하게 설계하지 말라는 원칙이며, 포괄적인 설계원칙이다.
  • YAGNI (금지), KISS(방법)

3.7 DRY 원칙

• DRY (don’t repeat yourself)원칙
  • 중복 코드를 작성하지 말라는 뜻
  • 동일한 코드가 여러 개 존재한다는 것이 중복이 아니다. 반드시 DRY 원칙에 위배되는 것이 아니다.
  • 기능적 (의미론적) 중복이 되지 않으면 DRY 원칙에 위배되지 않는다.
  • 예) 아이디 체크, 비밀번호 체크에서 체크가 논리적으로 동일하더라도 중복이 아니다.
• 코드 실행의 중복
  • 논리적 중복이나 의미적 중복은 없지만, 코드 실행에 중복이 있어서 위배
• 코드의 재사용성을 확보하는 방법
  • 코드의 결합도를 줄인다.
  • 단일 책임 원칙을 총족
  • 코드의 모듈화는 필수, 모듈은 클래스 모음뿐만 아니라 단일 클래스나 함수도 포함
  • 비즈니스 논리와 아닌 부분을 분리
  • 일반적인 코드는 하위 계층으로 내려보냄
  • 상속, 다향성, 추상화, 캡슐화를 활용
  • 디자인 패턴 활용 (예-애플리케이션 템플릿)
  • 기타 프로그래밍 언어에서 제공하는 기능 (제네릭 등등)
• 명시적인 재사용 요구사항이 없다면 너무 많은 개발 리소스를 투자하는 것은 권장되지 않으며, YAGNI원칙에 위반
• 3의 법칙 (rule of three)
  • 처음 코드를 작성 할 때는 재사용성을 고려하지 않고, 나중에 재사용 시나리오를 만나면 다시 사용할 수 있도록 리팩토링 할 것

3.8 LoD

• 데메테르의 법칙(law of Demeter)
  • 최조 지식의 원칙(the least knowledge principle)
  • 모든 유닛이 자신과 매우 밀접하게 관련된 유닛에 대해서 제한된 지식만 알아야 한다.
  • 직접 의존성이 없어야 하는 클래스 사이에는 반드시 의존성이 업어야 하며, 의존성이 있는 클래스는 필요한 인터페이스에만 의존해야 한다.
• 높은 응집도(high cohesion), 낮은 결합도(loose coupling)
  • 코드의 가독성과 유지 보수성을 효과적으로 향상
  • 기능 변경으로 인한 코드 변경 범위를 줄이는 중요한 설계 사상
• 높은 응집도
  • 클래스 자체의 설계에 사용
  • 유사한 기능은 동일한 클래스에 배치되어야 하고, 유사하지 않는 기능은 다른 클래스로 분리해야 한다.
• 낮은 결합도
  • 클래스간의 의존성 설계에 사용
  • 의존성이 단순하고 명확해야 함을 의미
• 응집도와 결합도는 완전히 독립적이지 않기 때문에 서로 상호보완적이다.

[SAgiKPJH]

4 코딩 규칙

• 명명 (naming)
  • 명명은 코드 가독성에 큰 영향을 끼치며, 프로그래머의 기본 능력과 소영을 반영한다.
  • 긴 이름과 짧은 이름
  • 문맥 정보를 사용한 명명 단순화
    • 예) User.userName -> User.Name
  • 비즈니스 용어집을 사용한 명명 통일
    • 통일된 비즈니스 용어집을 통해 통일된 약어를 지정한다.
  • 명명은 정확하지만 추상적이어야 한다.
    • process, handle, magage와 같은 광범위한 단어를 포함하는 이름이 많은 경우, 이름이 정확한지, 더 구체적인 의미를 다른 단어로 바꿔야 하는지 고려해야 한다.
    • 적당한 이름을 찾지 못하면 토론을 거치거나 명명 방법을 참조한다.
• 주석 (comment)
  • 주석은 명명만큼 중요하다.
  • 좋은 명명이 주석을 완전히 대체할 수 있다. -> 주석을 작성해야 한다면 명명이 충분히 적합하지 않는다는 뜻, 명명을 다시 고려할 것.
  • 명명을 아무리 잘 해도 길이 제한이 있을 뿐만 아니라 모든 것을 담을 수 없으므로, 주석은 좋은 보충설명이 될 수 있다.
  • 주석에 반드시 포함되어야 하는 것들
    • 주석의 3가지 측면, what, why, how
    • (Why) 주석은 코드의 설계 의도를 나타내는 이유를 명확하게 설명하는 것으로 충분, 무엇과 어떻게는 이름이나 코드를 통해 알 수 있다.
    • (What) 주석에는 이름보다 훨씬 많은 정보를 담을 수 있다.
    • (How) 주석은 설명과 시연의 역할을 한다.
    • 요약 주석은 코드의 논리를 더 명확하게 할 수 있다.
  • 주석이 많다고 해서 좋은 것은 아니다.
    • 주석이 너무 많으면 가독성이 떨어진다는 것을 의미
• 코드 스타일 (code style)
  • 팀이나 프로젝트 전체에서 코드 스타일을 일관되게 유지하는 것이 중요
  • 클래스, 함수의 적절한 크기
    • 클래스나 함수의 코드 줄 수는 너무 많아도 안 되며, 적어도 안 된다.
  • 한 줄의 적절한 길이
    • google의 java 프로그래밍 사양에서 한 줄은 100자로 제한 되어 있다.
    • 코드줄과 관련해서 가급작 IDE의 표시 너비를 초과해서는 안된다는 규칙을 따를 수 있다.
  • 빈 줄을 이용한 코드 블록 구분
  • 4칸 들여쓰기 혹은 2칸 들여쓰기
    • Java코딩 규칙은 2칸 들여쓰기, PHP 코딩 규칙은 4칸 들여쓰기를 사용하는 경향이 있다.
    • 공간을 절약하기 위해 2칸 들여쓰기 권장
  • 여는 중괄호 위치
  • 클래스의 맴버 순서
• 코딩 팁 (coding tip), 실용적인 팁
  • 복잡한 코드의 모듈화
  • 함수의 매개변수 관리
    • 함수에 매개변수가 너무 많은 이유가 함수의 책임이 단일하지 않는 이유라면 분할
  • 함수 플래그 매개변수 제거
    • Boolean 매개변수에 따른 코드가 다르도록 설계하면 안된다.
    • 두 개의 함수로 분할하는 것이 좋다.
  • 깊은 중첩 제거
    • if, else 제거
    • continue, break, return 사용하여 중첩 바로 종료
    • 실행 순서를 조정하여 중첩 단계 줄임
    • 중첩 단계를 줄이기 위해 코드의 일부를 함수로 캡슐화
  • 설명 변수 (explanatory variable)
    • 코드 가독성을 향상시키고, 불필요한 주석을 줄일 수 있다.
    • 1. 매직 넘버 대신 상수 (예 3.1415 => PI)
    • 2. 설명 변수를 사용하여 복잡한 표현을 설명 (예 bool isSummer)

[SAgiKPJH]

5 리팩터링 기법

• 리팩터링 (refactoring)
• 지속적인 리팩터링은 코드 품질을 향상시키는 효과적인 수단
• 단순한 문제 해결보다는 코드 리팩터링할 때 더 많은 능력이 요구된다.

5.1 리팩터링의 네 가지 요소

• 목적
  • 마틴 파울러가 제시한 리팩터링의 정의
    • 리팩토링은 코드에 대한 이해를 쉽게 하기 위해 소프트웨어의 내부 구조를 개선 하는 것으로, 소프트웨어의 외부 동작을 변경 하지 않고 수정 비용을 줄이는 것을 목적으로 한다
  • 코드의 품질을 보장, 코드 품질 저하를 방지
  • 고품질 코드는 반복적인 작업의 결과로 나온다.
  • 과도한 설계를 피하는 효과적인 방법
  • 소프트웨어 엔지니어의 기술적 성장에도 중요
    • 코딩 규칙, 이론적 지식, 설계원칙, 디자인 패턴을 응용해 볼 수 있는 중요한 기회이자 코딩 능력을 측정하는 중요한 수단
• 대상
  • 대규모 고수준 리팩터링
    • 계층화, 모듈화, 분리, 재사용 가능한 구성 추상화
    • 코드 변경이 많고 그 영향이 크다
    • 작업이 오래 걸리고 버그 발생 위험이 높다
  • 소규모 저수준 리팩터링
    • 표준 명명, 표준 주석, 초대형 클래스와 함수 제거, 중복 코드 추출과 같이 세부 정보를 리팩터링하는 것
    • 수정이 집중적으로 이루어 지며, 프로세스가 간단하며 조작성이 강하다.
    • 소요시간이 짧고 버그 발생 위험이 적다
• 시기
  • 코드 유지 관리하는 데 어려움이 있고, 버그가 빈번하게 발생한다면 리팩터링하기에는 너무 늦었다.
  • 코드가 망가진 후에는 모든 문제를 한꺼번에 해결하려는 수단으로 리팩터링에 의존하면 안된다.
  • 지속적인 리팩터링
    • 단위 테스트와 코드 리뷰를 개발의 일부로 취급하는 것 처럼 지속적인 리팩터링 개발의 일부러 다루어야 한다.
• 방법
  • 대규모 리팩터링
    • 사전에 종합적인 리팩터링 계획 수립
    • 질서있고 단계적으로 진행
    • 코드가 항상 실행 가능한 상태가 되도록 구성
    • 리팩터링 영향을 받는 코드 범위 제어
    • 기존 코드와의 호환성을 고려, 필요할 때 호환성을 위해 변경 코드를 제공
    • 조직적이고 계획적이며 신중해야 하며, 경험이 있고 숙련된 수석 엔지니어가 주도해야 한다.
    • 새로운 비즈니스 개발 일정이 리팩터링과 충돌하지 않게 한다.
  • 소규모 리팩터링
    • 영향을 미치는 범위가 작고 변경사항이 적기 때문에 원한다면 시간이 있을때 마다 진행
    • 코드 품질 문제를 찾는 분석 도구인 Checkstyle, FindBugs, PMD등을 활용

5.2 단위 테스트

• 잘 못된 리팩터링을 방지하는 효과적인 방법으로 단위테스트
• 단위 테스트
  • 코드의 정확성을 테스트하기 위한 것
  • 테스트 엔지니어가 아닌 개발 엔지니어가 작성하는 것
• 단위 테스트 코드를 작성하는 이유
  • 코드에서 버그를 찾는데 도움
  • 코드 설계에서 문제를 찾는데 도움
  • 통합 테스트를 보완하는 강력한 도구
  • 코드를 작성하는 과정은 리팩터링 과정에 해당
  • 프로그래머가 코드에 빠르게 익숙해지도록 도와준다
  • 테스트 주도 개발(test-driven development, TDD)을 개선하고 대체할 수 있다.
• 단위 테스트 설계하는 방법
  • 단위 테스트는 테스트 케이스를 코드로 변환하는 프로세스
  • 단위 테스트 프레임워크 (JUnit, TestNG, SpringTesting, xUnit)
• 단위 테스트 질문
  • 단위 테스트 설계는 시간이 많이 걸리는 일인가?
    • 테스트할 코드 자체보다도 단위 테스트 코드 양이 매우 많을지라도, 단위 테스트 코드는 구현이 간단하고 설계를 고려할 필요가 없기 때문에 작성에 많은 시간이 필요하지 않다.
    • 기존의 단위 테스트 코드를 재활용 할 수 있다.
  • 단위 테스트 코드의 품질에 대한 요구사항은?
    • 프로덕션 환경에서 실행되지 않으며, 독립적이고 서로 의존하지 않으므로, 실패되지 않는 한 문제는 없다.
    • 품질 요구 사항을 낮출 수 있다.
  • 테스트 커버리지가 높으면 그것만으로 충분한가?
    • 테스트 커버리지 측정하는 통계 도구 (JaCoCo, Cobertura, EMMA, Clover등)
    • 간단한 구문 커버리지, 조건 커버리지, 결정 커버리지, 경로 커버리지와 같이 여러 커버리지 계산 방법이 있다.
    • 커버리지에 너무 집중하면 불필요한 테스트 코드를 많이 작성할 수도 있다. (예, getter, setter와 같은 단순한 메서드)
    • 테스트 커버리지가 60~70%정도면 문제가 없다.
  • 코드 구현의 논리를 이해하는 것이 필요한가?
    • 단위 테스트는 테스트 함수의 특정 논리에 의존하지 않고 기능에만 초점을 둔다.
  • 단위 테스트 프레임 워크 선택 방법은?
    • 대부분의 단위 테스트 프레임 워크는 단위테스트 요구사항 만족
• 단위 테스트 작성이 어려운 이유
  • 단위 테스트의 중요성을 깨닫고는 있지만 실행에 옮기는 사람은 많지 않고, 단위 테스트를 활용하지 않는다.
  • 단위 테스트의 작성은 인내심 테스트하는 일
  • 작성하기는 쉽지만 특별한 기술을 슥듭할 수 있는 것은 아니기 때문에 많이 꺼려한다.
  • 잘 작성된 단위 테스트와 코드 리뷰를 통해 코드의 품질에 신경 쓰면 테스트 시간을 크게 줄일 수 있다.
  • 프로그래머는 단위 테스트의 이점을 진정으로 느낄 때만 이를 인식하고 사용

5.3 테스트 용이성

• 테스트 가능한 코드 작성하는 방법
  • 모의 구현, Mock
    • 코드가 외부 시스템과 같이 제어할 수 없는 구성 요소에 종속되는 경우 그 종속 관계를 끊는 방법이다.
    • Stub, Dummy, Fake, Spy와 같은 다른 이름을 사용할 수 있다.
    • 실제 서비스를 모의 서비스로 대체하는 것으로서, 모의 구현 서비스는 완전히 통제하에 있으며 원하는 결과를 만들어낼 수 있다.
    • 수동 모의 구현
    • 프레임 워크 모의 구현
  • 클래스의 독립성, 해당 클래스가 높은 응집도와 낮은 결합도를 만족하는지에 테스트 가능한 코드 작성이 달려있다.
  • 외부 시스템과 밀접하게 연결되어 있다면 테스트 코드 구현이 어려워진다.
  • 의존성 주입, 모의 구현 ,캡슐화를 통해 외부 서비스에 대한 의존성을 없앨 수 있다.
• 테스트가 불가능한 코드
  • 보류중인 동작
    • 코드의 출력이 무작위거나 불확실하며, 대부분 시간 및 난수와 관련이 있는 것을 의미
    • 불확실한 실행 결과가 나오는 경우는 정확성을 테스트할 수 없다.
  • 전역 변수
    • 전역 변수를 잘 못 사용하면 단위 테스트 설계하기 어렵다.
  • 정적 메서드
    • 정적 메서드는 모의 구현이 어렵기 때문에 코드 테스트 용이성이 떨어지는 경우가 간혹 있을 수 있다.
    • 하지만 모의구현이 필요하지 않는 간단한 정적 메서드는 테스트 용이성에 영향을 미치지 않는다.
  • 복잡한 상속 관계
    • 합성 관계에 비해 상속 관계가 결합성이 훨씬 높다.
    • 상위 클래스에서 단위 테스트를 위해 종속 객체를 모의 구현해야 하는 경우, 상속받는 모든 하위 클래스의 단위테스트 코드에서 이 종속 객체를 전부 모의구현해야 한다.

5.4 디커플링

• 소규모 리팩터링의 주 목적은 코드의 가독성을 높이는 것.
• 대규모 리팩터링의 주 목적은 디커플링이다.
• 코드 복잡성 제어에 가장 효과적인 방법이 디커플링
  • 디커플링을 통해 응집도가 높고 결합도가 낮은 코드를 만들 수 있으며, 코드의 복잡성을 효과적으로 제어할 수 있다.
  • 코드를 너무 많이 이해할 필요없이 모듈이나 클래스에 집중할 수 있고, 리팩토링 난이도 역시 낮출 수 있다.
• 코드 디커플링 필요한지 판단하는 방법
  • 기능 코드의 일부가 수정되면 전체 코드를 모두 건드려야 하는 경우 (결합도가 너무 높아 디커플링이 필요하다는 의미)
  • 프로젝트에서 모듈과 클래스 간의 의존성 복잡성에 따라 코드 분리하는 직관적인 방법도 있다.
• 코드 디커플링 방법
  • 캡슐화와 추상화로 디커플링
    • 시스템, 모듈, 클래스 라이브러리, 구성 요소, 인터페이스, 클래스 설계와 같은 다양한 코드 설계 시나리오에 적용 가능
  • 중간 계층으로 디커플링
    • 중간 계층을 통해 모듈 사이 또는 클래스 사이의 의존성을 단순화할 수 있다.
    • 리팩터링시에도 중간 계층이 과도기적인 역할을 한다. 개발 프로세스와 리팩터링 프로세스가 서로 간섭하지 않고 동시에 진행될 수 있다.
    • 인터페이스 4단계 과정을 통해 리팩토링 빠르게 진행 가능
      • 중간계층 도입하고 이를 사요하여 이전 인터페이스를 감싸는 새 인터페이스 제공
      • 새로 개발된 코드는 중간 계층에서 제공하는 새로운 인터페이스에만 의존
      • 이전 인터페이스에서 종속된 코드를 전부 변경하여 새 인터페이스를 호출
      • 모든 코드가 새 인터페이스를 호출하는지 확인한 후 이전 인터페이스를 제거
  • 모듈화와 계층화로 디커플링
    • 모듈화 개념은 서비스 기반 아키텍처(service-oriented architecture, SOA), 마이크로 서비스, 클래스 라이브러리, 클래서와 기능의 설계에 반영된다.
    • 모듈화의 본질은 분할을 통한 제어
    • 계층화는 복잡한 시스템을 구축하는 일반적인 수단
    • UNIX는 계층 개념 기반으로 개발
      • 커널 계층
      • 시스템 호출 계층
      • 응용 프로그램 계층
    • 각 계층은 다른 계층에 영향을 주지 않고 각각 계층을 다시 구현하거나 업데이트 한다.
    • 재사용이 빈번하고 비즈니스와 관계 없는 코드는 최대한 하위 계층으로 내리고, 수정이 빈번한 특정 비즈니스와 깊은 관련있는 코드는 상위 계층으로 올린다.
  • 고전적인 코드 설계 원칙과 사상을 사용한 디커플링
    • 디커플링에 사용할 수 있는 코드 설계 원칙과 사상
    • 단일 책임 원칙
    • 구현이 아닌 인터페이스 기반 프로그래밍
    • 의존성 주입
    • 상속보다는 합성
    • LoD를 따르는 것

[SAgiKPJH]

5 리팩터링 기법 정리

리팩터링

• 정의
  • 결과의 변경 없이 코드의 구조를 재조정함을 뜻함
• 리팩터링 vs 리펙토링
  • 리팩터링(refactoring)

5 리팩터링 기법 내용 요약

리팩터링

• 리팩토링은 더 많은 능력이 요구된다.
• 대규모 리팩터링의 주 목적은 디커플링이다.
  • 코드가 항상 실행 가능한 상태가 되도록 구성
  • 조직적이고 계획적이며 신중해야 하며, 경험이 있고 숙련된 수석 엔지니어가 주도해야 한다.
• 소규모 리팩터링의 주 목적은 코드의 가독성을 높이는 것.
  • 시간이 있을때 마다 진행
• 코드 품질 문제를 찾는 분석 도구인 Checkstyle, FindBugs, PMD등을 활용

테스트

• 테스트 커버리지가 높으면 그것만으로 충분한가?
  • 테스트 커버리지 측정하는 통계 도구 (JaCoCo, Cobertura, EMMA, Clover등)
  • 커버리지에 너무 집중하면 불필요한 테스트 코드를 많이 작성할 수도 있다. (예, getter, setter와 같은 단순한 메서드)
• 테스트 커버리지가 60~70%정도면 문제가 없다.

디커플링

• 코드 디커플링 방법
• 캡슐화와 추상화로 디커플링
  • 시스템, 모듈, 클래스 라이브러리, 구성 요소, 인터페이스, 클래스 설계와 같은 다양한 코드 설계 시나리오에 적용 가능
• 중간 계층으로 디커플링
  • 중간 계층을 통해 모듈 사이 또는 클래스 사이의 의존성을 단순화할 수 있다.
  • 리팩터링시에도 중간 계층이 과도기적인 역할을 한다. 개발 프로세스와 리팩터링 프로세스가 서로 간섭하지 않고 동시에 진행될 수 있다.
• 인터페이스 4단계 과정을 통해 리팩토링 빠르게 진행 가능
  • 중간계층 도입하고 이를 사용하여 이전 인터페이스를 감싸는 새 인터페이스 제공
  • 새로 개발된 코드는 중간 계층에서 제공하는 새로운 인터페이스에만 의존
  • 이전 인터페이스에서 종속된 코드를 전부 변경하여 새 인터페이스를 호출
  • 모든 코드가 새 인터페이스를 호출하는지 확인한 후 이전 인터페이스를 제거
• 모듈화와 계층화로 디커플링
  • 모듈화 개념은 서비스 기반 아키텍처(service-oriented architecture, SOA), 마이크로 서비스, 클래스 라이브러리, 클래서와 기능의 설계에 반영된다.
  • 모듈화의 본질은 분할을 통한 제어
  • 계층화는 복잡한 시스템을 구축하는 일반적인 수단

Refactoring 툴

• Code Rush (Devexpress)
  • https://docs.devexpress.com/CodeRushForRoslyn/115806/refactoring-assistance

다른 플랫폼에서 말하는 리팩터링

• https://www.linkedin.com/advice/1/how-can-you-refactor-mobile-app-architecture-qn54f
  • 현재 아키텍처를 평가하여 존재할 수 있는 약점, 종속성 및 개선 영역을 식별
  • 리팩토링은 기존 기능의 중단을 최소화하면서 구성 요소를 재구성하고 최적화하는 체계적인 접근 방식을 포함

[SAgiKPJH]

6 생성 디자인 패턴

• 객체 생성 문제 해결, 복잡한 생성 프로세스 캡슐화, 객체 생성 코드와 사용 코드를 분리
• 종류
  • 싱글턴 패턴
  • 팩터리 패턴
  • 빌더 패턴
  • 프로토 타입 패턴

6.1 싱글턴 패턴

• 단 하나의 인스턴스만 생성
  • 하나의 프로세스 범위 안에서 유일, 새 프로세서에서는 싱글턴 클래스가 복사된다.
  • 같은 프로세서에 속한 여러 스레드사이에서 유일하다.
• 한 번만 저장되어야 하는 데이터가 포함된 경우, 싱글턴 패턴으로 설계

4가지 조건

• new 예약어 방지를 위한 생성자 private 접근 권한
• 스레드 안정성 보장
• 지연 로딩 여부
• getInstance() 함수의 성능이 충분한지

종류

• 즉시 초기화 (불러오자 마자 초기화)
• 늦은 초기화 (사용될 때 초기화)
• 이중 잠금
• 홀더에 의한 초기화
• 열거

단점

• 클래스간 의존성을 감춘다. (생성자 감춤으로 발생하는 의존성 확인이 어려운 문제)
• 코드 확장성에 영향을 미친다.
  • 두 개의 인스턴스가 필요한 경우 코드 수정이 많이 필요
  • 데이터 베이스 연결 풀과 스레드 풀에 싱글턴 적용하지 않는 이유
• 테스트 용이성에 영향을 준다.
  • 모의 구현 사용 불가
  • 모든 코드에서 공유하는 전역변수와 같기에, 수정될 경우 테스트 결과에 영향이 존재
• 새성자 미지원 (아래 3가지 방법 사용)
  • init() 함수 만들어 먼저 호출
  • getInstanse()에 파라미터로 호출
  • 매개변수를 전역변수로 구현

대안

• 정적 메서드 (테스트 용이성, 확장성 문제 해결 x)
• DI 컨테이너를 통해 개선 가능

특수 상황

• 스레드 전용 싱글톤 -> Thread.currentThread().getId()사용, ConcurrentHashMap<Long, class> 사용
• 분산 싱글턴 패턴에 해당하는 클러스터 기반 싱들턴 패턴
  • 클러스터(여러 프로세서의 모음)에서 유일, 외부 공유 저장 영역(메모리 또는 파일) 활용
• 다중 인스턴스 패턴
  • 생성할 수 있는 개수 제한

6.2 팩터리 패턴

종류

• 단순 팩터리 페턴
  • if를 통한 유형에 따른 Class를 제공
• 팩터리 메서드 패턴
  • 다형성을 통한 if 판단 논리 제거
  • java의 경우 Map<string, interface>를 통해 제공
• 추상 팩터리 패턴

특성

• 생성 과정을 캡슐화
• 생성과정을 추출한 후 재사용
• 복잡한 생성화정 캡슐화
• 생성과정과 사용 과정을 분리

6.2 팩토리 패턴 DI 컨테이너

기본 개념

• DI 컨테이너 하단 계층의 기본 설계 사상은 팩터리 패턴을 기반으로 한다.
• DI 컨테이너는 큰 팩토리 클레스에 해당
• 미리 객체를 생성하는 역할
• 많은 객체를 담을 수 있기 때문에 컨테이너로 불린다.

기능

• 설정 분석
  • 객체 생성에 필요한 정보가 담긴다.
• 객체 생성
  • 클래스를 동적으로 적재, 객체를 생성할 수 있는 리플랙션(reflection0
• 객체 수명 주기 관리
  • 지연 적재를 지원하는지 여부 설정
  • 객체가 실제 사용될 때만 생성하는지, 애플리케이션 시작 시점에 미리 생성하는지와 같은 여부 설정

기능요약

• 설정 파일을 분석하고 리플렉션을 통해 객체 생성하는 것이 전부
• DI 컨테이너의 핵심 클래스
  • java의 경우 map에 캐싱

6.3 빌더 패턴

• 생성기 패턴
• 기존 방식으로, 필수는 생성자 파라미터에 구성하고 미필수는 setter를 사용
  • 문제점1 : 필수 항목이 매우 많으면 문제
  • 문제점2: 설정 항목 사이에 의존성이 있을 수 있다. Setter로 임의 설정하면 문제 발생
  • 문제점3: 불변 객체일 경우에 내부 속성 값을 수정할 수 없다.

활용

• 모든 유효성 검사 로직을 빌더 클래스에 넣는다.
• 생성자 매개변수가 너무 많으면 빌더패턴 사용
• 빌더의 변수를 설정한 다음에 객체를 한 번에 생성하여 항상 유효한 상태가 되도록 할 수 있다.

예시

• 캐싱 시스템, 파라미터가 너무 많기 때문

빌더패턴과 팩토리 패턴 차이

• 식당의 주문 메뉴들이 팩토리
• 메뉴중 햄버거의 경우, 빵-햄-토마토-양상추-빵을 구성하는게 빌드

6.4 프로토타입 패턴

• 생성된 차이가 그리 크지 않는 경우 복사를 통해 새 객체 생성
• 기존 객체를 직접 복사하여 생성
• 얕은 복사와 깊은 복사

깊은 복사 방법

• 배열의 경우 재귀적으로 복사
• 객체를 직렬화한 다음 역직렬화

궁금증

ServiceCollection의 AddSingleton<>과 싱글턴 패턴

전통적인 싱글턴 패턴과 유사하지만, DI 컨테이너를 통해 관리된다는 점에서 차이가 있습니다.
DI 컨테이너는 객체의 생명 주기를 관리하고, 필요한 시점에 객체를 주입해줍니다.
따라서, AddSingleton<>은 DI 컨테이너를 통해 싱글턴 객체를 생성하고 관리하는 방식입니다.

Fail-Fast 설계 원칙

Fail-Fast 설계 원칙은 시스템이 오류를 감지했을 때 즉시 실패하도록 설계하는 것을 의미합니다.
이는 오류가 발생한 즉시 문제를 인지하고 해결할 수 있도록 도와줍니다.
프로그램 시작 시 인스턴스를 초기화하는 것은 Fail-Fast 설계 원칙에 부합하며, 초기화 과정에서 발생할 수 있는 오류를 조기에 발견하고 해결할 수 있습니다.

Volatitle

volatile 키워드는 변수의 값을 항상 메인 메모리에서 읽고 쓰도록 강제하여 CPU 명령 재정렬을 방지한다.
이는 변수의 값을 항상 최신 상태로 유지하고, 여러 스레드 간의 가시성 문제를 해결한다.
volatile은 Java, C# 등에서 동시성 코드를 작성할 때 사용되는 주요 키워드, C/C++의 volatile는 용도나 원리가 달라서 주요 동시성 구현 수단으로 사용되지 않는다.
멀티 스레드 환경에서 다음 두 가지 문제를 개선하기 위해 사용한다.

• 캐시 지연 문제
  • 스레드 각각의 값이 캐시에 지연 반영되는 경우가 있는데, 때문에 멀티 스레드 환경에서는 스레드간에 동일한 데이터에 대해서 값 차이가 발생할 수 있다.
  • volatile는 기존 캐시(CPU Cashe)가 아닌 항상 "메모리(RAM)"에서 읽어오게 컴파일러를 코드생성하게 한다.
• Reordering 문제
  • 컴파일러는 성능 최적화 과정 중에 Reordering이라는 과정을 수행하곤 하는데, 싱글스레드에서는 문제없지만 멀티스레드 환경에서는 순서가 변경될 수 있다.
  • volatile은 변수의 값을 항상 메인 메모리에서 읽고 쓰도록 강제하여 CPU 명령 재정렬을 방지합니다.
• 참고 사이트
  ​

Java의 Holder 싱글턴 패턴을 C#에서 구현

Java의 Holder 싱글턴 패턴은 클래스 로더의 메커니즘을 활용하여 싱글턴 인스턴스를 지연 로딩하는 방식입니다. 이를 C#에서 구현하는 예시는 다음과 같습니다:

public class Singleton
{
    private Singleton() { }

    private static class Holder
    {
        internal static readonly Singleton instance = new Singleton();
    }

    public static Singleton Instance
    {
        get { return Holder.instance; }
    }
}

생성자 패턴에서 홀더에 의한 초기화 원리

생성자 패턴에서 홀더에 의한 초기화는 클래스 로더의 메커니즘을 활용하여 싱글턴 인스턴스를 지연 로딩하는 방식입니다.
이는 클래스가 로드될 때 내부 정적 클래스가 초기화되며, 이 과정에서 싱글턴 인스턴스가 생성됩니다.
이를 통해 스레드 안전성을 보장하고, 불필요한 동기화를 피할 수 있습니다.

[SAgiKPJH]

7 구조 디자인 패턴

• 객체 결합

[SAgiKPJH]

8 행동 디자인 패턴

• 객체간의 커뮤니케이션
• 클래스나 객체 간의 상호 작용 문제를 해결
• 종류 (11가지)
  • 옵서버 패턴
  • 커맨드 패턴
  • 전략 패턴
  • 책임 연쇄 패턴
  • 상태 패턴
  • 반복자 패턴
  • 비지터 패턴
  • 메멘토 패턴
  • 커맨드 패턴
  • 인터프리터 패턴
  • 중재자 패턴

Observer Pattern

• 발행-구독 패턴 (publish-subscribe pattern)
• 많은 객체들 사이에서 일대일 의존 관계가 정의되어 있을 때, 어느 한 객체의 상태가 변경되면 이 객체에 의존하고 있는 모든 객체는 자동으로 알림을 받는다.
• 의존 대상이 되는 피관찰자, Observable이라 부르고, 관찰자를 Observer라고 한다.
• 피 관찰자
  • Observable, Subject, Publisher, Producer, EventEmitter, Dispatcher
• 관찰자
  • Observer, Subscriber, Consumer, EventListener, Listener
• 상당히 추상적이라 다양한 구현이 가능

Template Method Pattern

• 템플릿 메서드 패턴은 하나의 메서드 안에 정의된 알로리즘 골격, 일부 작업 단계를 하위 클래스로 넘길 수 있어 하위 클래스가 알고리즘 전체 구조를 변경하지 않고 알고리즘의 일부 단계를 재정의할 수 있다.
  • 알고리즘 프레임 워크 : 템플릿
  • 알고리즘 프레임 워크를 포함하는 메서드 : 템플릿 메서드
• 주로 재사용 및 확장을 위해서 사용

[SAgiKPJH]

디자인 패턴 참고 사이트

• https://github.com/abishekaditya/DesignPatterns