🧠 설계
혼자든 여러 명이든 하나의 프로젝트를 진행한다면 설계하는 과정은 필수다.
- 1. 의존성 과다 방지
모든 객체가 하나의 객체의 데이터에 의존하면 이것을 갓 오브젝트 라고하며,
이 오브젝트의 데이터를 수정하면 연결된 모든 오브젝트의 코드를 수정하는 경우가 생긴다.
- 2. 책임을 생각하지 않은 무분별한 기능 추가 방지
하나의 객체는 하나의 책임을 가진다는 객체지향의 원칙 중 하나인 단일 책임 원칙을 위반한다.
-
3. 나는 이해할 수 있지만 팀원들에게 설명하기 위해
내가 짠 코드는 나는 당연히 이해가 되지만,
팀원들은 그 구조를 파악하기 어려울 수 있다. -
4. 문제 발생시 문제 파악이 어려움
설계 없이 구현한 구조는 어디서 어떻게 연결되어 있는지 파악하기 힘들다.
버그가 발생했을 때 위치와 수정이 늦어진다.
그럼 어떻게 설계할 수 있을 까?
💻 GitHub
깃허브에서는 Repository에 코드만 올리는게 아니라
협업을 위한 설계를 관리하는 기능이 있다.
즉, 프로젝트를 관리할 수 있다.
✅ Issues
Issue에서는 해야 할 작업들을 정리할 수 있다.
bug, feature, good first issue 같은 라벨을 붙여 구분할 수 있고,
이슈에 관하여 코멘트를 남겨 소통할 수도 있다.
마치 TODO 같은 느낌이다.
📅 Project
Project에서는 일정 관리와 현재 상황을 파악할 수 있다.
각 이슈들을 한눈에 보고 담당자나 진행도?를 확인할 수 있다.
개발하는 기능의 마감일을 정하는게 📆달력에 적어놓는 것 같다.
📐 UML Diagram
UML 다이어그램은 설계를 시각화할 수 있다.
Class Diagram
클래스 내부의 정적인 내용이나 클래스 사이의 관계를 표기하는 다이어그램
Association (연관 관계)
- A has B
- 멤버변수에 값을 가지고 있거나 버릴 수 있는 관계
ex) 아이템을 들고있거나 버릴 때
Dependency (의존 관계)
- A use B
- 짧은 시간동안 사용하는 관계
ex) 멤버변수에 접근해서 함수를 사용, 매개변수를 사용, 로컬변수들?
Generalization (일반화 관계)
- A is B
- 한 클래스가 다른 클래스를 포함하는 관계
ex) 상속 (abstract)
Realzation (실체화 관계)
- A can B
- 책임들을 실제로 구현한 클래스들 사이의 관계
ex) 인터페이스 (Interface)
Composition (합성 관계)
- A 구성에 B가 필수
- 클래스들 사이의 전체 또는 부분같은 관계
- 책임을 분산
- 필드변수로 가지고 있음
ex) 컴포넌트 (Component), 코루틴 (Coroutine)
Aggregation (집약 관계)
- A와 B가 느슨하게 연결
- 전체가 없어도 유지됨
집약 관계는 아직 잘 이해를 못해서 예시가 안떠오른다...
Activity Diagram
작업 흐름을 순서대로 표현하는 플로우 차트
다이어그램중 제일 알기 쉬워보인다.
Sequence Diagram
두개 이상의 객체의 상호작용을 표현
핸드 트래킹으로 물체를 잡거나 놓거나 하는 VR에서 주로 사용한다고 한다.
설계 방법에 대해 하루만에 머릿속에 많이 들어오니
이해하기 되게 어려웠다... (사실 지금도 안됨)
