객체지향 설계 원칙 ~ 생성패턴

54. 객체지향 설계 원칙 =SOLID 원칙

• SRP, Single Responsible Principal: 객체는 단 하나의 책임만 져야 한다.
• OCP, Open-Closed Principal: 기능을 추가할 때 기존의 코드를 변경하지 않을 수 있어야 한다.
• LSP, Liskov Substition Principal: 자식 클래스는 최소한 부모 클래스의 행위는 수행할 수 있어야 한다.
• ISP, Interface Segregation Principal: 자신이 사용하지 않는 인터페이스와 의존관계나 영향을 받지 않아야 한다.
• DIP, Dependency Inversion Principal: 각 객체들 간 의존관계가 성립될 때, 구체적인 객체보다 추상화에 의존해야 한다.

*DIP 추가설명!

객체에서 어떤 클래스를 참조해야 할 때, 직접 클래스를 참조하는 것이 아니라 그보다 상위 클래스(추상 클래스 or 인터페이스)를 참조해야 한다. 

 

 

55. 결합도 (Coupling)

모듈 간 상호의존하는 정도, 연관관계

약할 수록 품질 높고, 강할 수록 품질 낮다.

 

결합도가 약함에서 강함 순! 자스제외공내 (자스 제외하고 공부한 나..)

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

 

56. 응집도 (Cohesion)

정보 은닉 개념을 확장한 것

모듈이 독립적인 기능으로 정의되어 있는 정도

약할 수록 품질 낮고, 강할 수록 품질 높다.

 

응집도가 강함에서 약함 순! 기순통절시논우 (기가 순한 통은 절에서 시를 짓고 논에서 운다...)

• 기능적 응집도, Functional Cohesion: 모듈 내부 모든 기능이 단일 문제와 연관되어 수행
• 순차적 응집도, Sequential Cohesion: 모듈 내 활동으로부터 나온 출력 데이터를 다음 활동의 입력 데이터로 사용
• 통신적 응집도, Communication Cohesion: 동일한 입/출력을 사용해서 서로 다른 기능을 수행하는 구성요소들이 모임
• 절차적 응집도, Procedural Cohesion: 다수의 관련 기능을 가질 때, 순차적으로 기능을 수행함
• 시간적 응집도, Temporal Cohesion: 특정 시간에 처리되는 몇 기능을 모아 하나의 모듈로 작성
• 논리적 응집도, Logical Cohesion: 유사 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성됨
• 우연적 응집도, Coincidental Cohesion: 모듈 내부 각 요소가 서로 관련 없는 요소로만 구성

 

57. 팬인(Fan-In)/ 팬아웃(Fan-Out)

팬인(Fan-In): 어떤 모듈을 호출하는 모듈의 수

팬아웃(Fan-Out): 어떤 모듈에 의해 호출되는 모듈의 수

시나공 정처기 필기 핵심 요약

 

58. N-S 차트 (Nassi-Schneiderman Chart)

논리의 기술에 중점을 둔 도형을 이용한 표현, 박스 다이어그램

연속, 선택 및 다중 선택, 반복 등 제어 논리 구조를 표현

화살표x

참고 

 

60. 재사용

재사용되는 대상은 결합도는 낮고 응집도는 높아야 한다.

비용과 개발 시간을 절약하기 위해 이미 개발된 기능들을 재구성하여 새로운 기능을 사용하기 적합하도록 최적화

규모에 따른 분류

• 함수와 객체: 클래스나 메서드 단위 소스 코드 재사용
• 컴포넌트: 독립적인 기능을 수행하는 실행코드 기반으로
• 애플리케이션: 공통 기능을 제공하는 애플리케이션을 공유하는 방식

 

61. 효과적인 모듈 설계 방안

기능은 예측가능해야 하며 지나치게 제한적이면 안된다

효과적인 제어를 위해 계층관계를 정의하는 자료가 제시되어야 한다.

복잡도와 중복을 줄이고 일관성을 지킨다.

 

64. 디자인 패턴(Design Pattern)의 개요

• 각 모듈의 세분화된 역할이나 모듈들 간 인터페이스 같은 코드를 작성하는 수준의 세분적인 구현 방안을 설계 시  참조할 수 있는 전형적인 해결방식 또는 예제.
• 구성: 문제 및 배경, 실제 적용된 사례, 재사용 가능한 샘플 코드 등,,,
• Don't reinvent the wheel, 바퀴를 다시 발명하지 마라 : 개발 중 문제가 발생하면 새로운 해결책을 구상하는 것보다 문제에 해당하는 디자인 패턴을 참고해서 적용하는 것이 더 효율적!!
• GoF의 디자인 패턴은 유형에 따라 생성 패턴 5개, 구조 패턴 7개, 행위 패턴 11개 총 23개의 패턴으로 구성됨

 

65. 디자인 패턴 사용의 장/단점

범용적인 코딩 스타일로 인해 구조 파악 용이

객체지향 설계 및 구현의 생산성 높임

검증된 구조의 재사용으로 시간과 비용 절약

설계 변경 요청에 대한 유연한 대처 가능

의사소통 원활

 

초기 투자 비용 부담

객체지향 기반이므로 다른 기반의 애플리케이션 개발에는 적합하지 않다.

 

66. 생성 패턴 (Creational Pattern)

객체의 생성과 참조 과정을 캡슐화해서 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 해서 유연성을 높임

 

총 5가지 추싱팩프빌 (추석에 팩하는 프로 보디빌더..)

1. 추상 팩토리, Abstract Factory:
   구체적인 클래스에 의존하지 않고 인터페이스를 통해 연관 의존하는 객체들의 그룹으로 생성하여 추상적으로 표현
   연관된 서브 클래스를 묶어 한 번에 교체 가능 -> DIP가 떠오른다!!
   
   
2. 싱글톤, Singleton:
   하나의 객체를 생성하면 생성된 객체를 어디서든 참조할 수 있지만 여러 프로세스가 동시에 참조할 순 없음
   클래스 내 인스턴스가 하나뿐임을 보장하며, 불필요한 메모리 낭비를 최소화
   
   
3. 팩토리 메소드, Factory Method
   =가상 생성자 패턴, Virtual Constructor
   객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화한 패턴
   상위 클래스에서 인터페이스만 정의하고 실제 생성은 서브 클래스가 담당
   
   
4. 프로토타입, Prototype
   원본 객체를 복제하는 방법으로 객체를 생성하는 패턴
   일반적인 방법으로 객체를 생성하며, 비용이 큰 경우 주로 이용함
   
   
5. 빌더, Builder
   작게 분리된 인스턴스를 건축하듯이 조합하여 객체를 생성
   객체의 생성 과정과 표현 방법을 분리하고 있어서 동일한 객체 생성에서도 서로 다른 결과를 만들어낼 수 있음