객체지향 SOLID 원칙 / git commit

 

1. 객체지향 5가지 설계원칙 SOLID 찾아보고 정리하기

 

SOLID 원칙이란?

객체지향 설꼐에서 지켜야 할 5개의 소프트웨어 개발 원칙.

 

1) SRP : 단일 책임 원칙

한 클래스는 하나의 책임(기능)만 가져야 한다.

= 기능을 하나만 가지고 있을 때, 기능 수정이 필요할 때 코드를 변경하기 쉽기 때문. (유지보수성 상향)

 

2) OCP : 개방 폐쇄 원칙

확장에는 열림(Open) / 수에는 닫힘(Closed)

즉, 기능 추가를 위해 클래스 확장을 하되 수정을 최소화하는 방식이다.

상속을 통한 클래스 구축, 추상화 사용의 이점 극대화.

 

3) LSP : 리스코프 치환 원칙

부모 클래스로 객체를 선언해 자식 클래스의 인스턴스를 받으면, 부모의 메서드를 사용해도 정상적으로 작동해야 한다.

오버라이딩 시 주의해야할 원칙이며, 다형성 원리를 이용하기 위한 원칙.

 

4) ISP : 인터페이스 분리 원칙

인터페이스를 사용에 맞게 잘 분리시켜야 한다. (인터페이스의 단일 책임)

하나의 인터페이스보다 기능에 맞게 분리된 여러 개의 인터페이스가 낫다.

여기서 인터페이스는 클라이언트의 목적과 용도를 기준으로 분리한다.

(주의사항 : 인터페이스는 한 번 구성하면 다시 바꾸지 않는 것이 좋다.)

 

5) DIP : 의존 역전 원칙

특정 클래스를 참조할 때, 직접 참조가 아닌 대상의 상위요소(추상 클래스, 인터페이스 등)로 참조하라.

즉, 참조할 때 대상이 변화에 취약하지 않은 것을 선택하라는 것이다. (수정이 거의 필요하지 않은 쪽으로)

이 원칙의 의의는 각 클래스 간의 결합도를 낮춤으로써 객체지향의 추상화를 실현하는 것이다.

 

 

2. 팀 과제 튜터님 피드백

 

- 사용하지 않는 using문은 지울 것.

- 아스키코드 및 출력과 관련된 부분도 json으로 관리하면 코드 가독성이 높아진다.

- switch문은 숫자를 바로 사용하는 것보다 Enum을 사용하는 것이 가독성 측면에서 좋다.

 

 

3. git commit은 명확하고 직관적이게

 

<기본 구조>

- type(타입) : title(제목)
- body(본문, 생략 가능)
- Resolves : #issueNo, ...(해결한 이슈 , 생략 가능)
- See also : #issueNo, ...(참고 이슈, 생략 가능)

 

<작성 규칙>

- 제목과 본문을 빈 행으로 구분

- 제목은 영문 기준 50글자 이하

- 첫 글자는 대문자

- 제목 끝에 마침표 X

- 제목은 명령문 사용, 과거형 X

- 본문의 각 행은 영문 기준 72글자 이하

- 어떻게보다는 무엇과 왜

 

<자주 사용하는 타입>

feat : 새로운 기능 추가

fix : 버그 수정

docs : 문서 수정

style : 코드 스타일 변경 (기능 수정이 없는 경우)

design : 사용자 UI 디자인 변경 (CSS 등)

test : 테스트 코드, 리팩토링 테스트 코드 추가

refactor : 코드 리팩토링

build : 빌드 파일 수정

ci : CI 설정 파일 수정

perf : 성능 개선

chore : 빌드 업무 수정, 패키지 매니저 수정 (gitignore 수정 등)

rename : 파일 혹은 폴더명을 수정만 한 경우

remove : 파일을 삭제만 한 경우

 

타입 뒤에 변경된 함수나 메서드를 직접적으로 명시하기도 한다.

ex) fix(tab): ...

 

 

4. Asset Store 활용하기

 

Unity Asset Store 에서 유료 Asset을 구매해 게임 제작에 활용할 수 있다.

팀원이 소개해준 Pro Camera 2D 의 경우 인기가 많은 Asset인데,

Scene에서 카메라를 지정해주면 Game 내에서 화면을 자연스럽게 전환할 수 있다. 

 

 

---

 

+ 더 공부할 내용

Unity에서 싱글톤, EventHandler, oop의 장단점, oop의 4가지 특징 (캡슐화/추상화/상속화/다형화)