[TIL] 객체지향 코드 설계 2

SOLID 원칙

이전 강의에서 잘 설계된 객체지향 코드는 응집도를 높이고 결합도를 낮춰야 한다고 했다.

그리고 지금 아래에서 설명할 SOLID 원칙은 그렇게 코드를 짜는데 도움을 주는 원칙들이다. 

 

Single Responsibility Principle

단일책임원칙

 

• 하나의 클래스는 하나의 책임(기능)만 가진다.
• 다만 함수를 하나만 가지라는 뜻이 아닌 그 클래스에 관련된 함수들로 구성되어야 한다는 뜻이다.

ex) 움직임에 관한 클래스는 움직임에 관련된 책임만 가지고 있는다.

 

Open Closed Princple

개방폐쇄원칙

 

• 확장에는 열려있고, 수정에는 닫혀있어야 한다.
• 자식클래스 입장에서 확장이 열려있고 부모클래스 입장에서는 닫혀있여야 한다.
• 상속에 연관지어서 말하자면,어떤 기능이나 함수가 추가된다고 가정할 때 부모클래스는 그대로 놔두고 상속받은 자식 클래스를 수정해야한다.

 

Liskov Substitutuion Principle

리스코프 치환 원칙

 

• 서브(자식)타입은 기반(부모)타입으로 교체할 수 있어야 한다.
• 우리가 기능을 확장을 시킬 때 적용해야할 원칙으로 Override 등을 사용해서, 로직을 상속받아서 쓰라는 원칙이다. 

 

LSP는 OCP를 재정립하고 방향성을 정해준 원칙 으로

OCP 와 LCP는 필요충분 조건 이다.

 

Interface Segregation Principle

인터페이스 분리 원칙

 

• SRP가 클래스 단일책임이라면, ISP는 인터페이스 단일 책임을 말한다.
• 인터페이스도 하나의 책임을 져야하나보다.
• 인터페이스에 연관도 없이 많은 기능을 넣지 말라는듯 하다.

Dependency Inversion Priniple

의존 역전 원칙

 

• class를 참조할 때, 직접 참조하지 말고 상위 요소를 참조하라는 뜻이다.
• 파생된 자식 클래스를 참조하지말고 상속해준 부모 클래스를 참조해야 한다..

 

Class  v.s Interface

어떨 때 클래스를 써야하고 인터페이스를 사용할지 잘 모르겠을 때 

 

Class 는 is- a 

ㅁㅁ는 OO이다.

클래스는 본인을 선언한다는 느낌이든다. 

 

Interface 는 has- a 

ㅁㅁ는 ㅇㅇ할 수 있다, 또는 가지고 있다.

자신이 뭘 할 수 있는 지 어떤 기능이 있는지 구현할 때 쓰는 느낌이다.

 

사실 이 정의만 보고서 크게 와닿지는 않는다. 

앞으로 명세서를 작성할 때  인터페스와 클래스의 특징을 고려해서 구조를 설계해야 할 것 같다.   

 

 

디자인 패턴

GOF(Gang Of Four)가 발견하고 정립한 프로그래밍 패턴으로

응집도를 높이고 결합도를 낮추는 SOLID 법칙이라면 

그것을 잘 활용한게 디자인 패턴이다.

 

크게 생성패턴 구조패턴 동작패턴 으로 나눌 수 있다.

 

유니티에서 적용할 수 있는 패턴들

컴포넌트 패턴

컴포지션 패턴 - 컴포넌트를 여러개 붙여넣은거

싱글톤 패턴 - 생성과 관련된 패턴

옵저버 패턴

오브젝트 풀링 패턴

전략 패턴

상태 패턴

등