1. Meaningful Names (의도를 분명히 밝혀라)
- 의도를 분명히 밝혀라.
변수 작성이 귀찮더라도 최대한 직관적으로 가는 게 좋다. 왜? 코드의 저자의 의도가 명확하게 파악이 되고, 위에서 아래로 자연스럽게 해석하기가 쉽다 또한 코드의 맥락이 명시적으로 협업 및 유지보수에 탁월하다.
- 그릇된 정보를 피하라.
- 의미 있게 구분하라.
- 발음하기 쉬운 이름으로 정하자.
우리는 혼자 일하지 않는다.
- 검색하기 쉬운 이름을 사용하라.
로그 검색하기가 쉽다.
- 타입과 관련된 문자열을 넣지 말아라.
예외사항도 있다. 인터페이스 클래스와 구현 클래스의 경우, 인터페이스 클래스는 접두어를 붙이지 않고, 구체 클래스에 접두어를 붙이는 것이 좀 더 보기 좋다. 예를 들어, ShapeFactory 인터페이스 클래스와 구현체인 ShapeFactoryImp가 보기 좋다.
- 한 개념에 한 단어를 사용하라.
일관성 있는 어휘를 선택해서 이름을 붙이자. 과거에는 서비스 계층 별로 어휘를 나눠서 통일화시키는 케이스도 있다.
ex) Controller 계층에서는 fetch, Service 계층에서는 get
- 의미 있는 맥락을 추가하라.
- 불필요한 맥락을 없애라.
2. Function
- 작게 만들어라!
한 가지만 해라.
함수 내부가 자연스럽게 쪼갤 수 있다면 여러 작업을 하고 있다는 의미이다.
- 추상화 수준이란?
- Switch문.
코드 길이가 길고 한 가지 작업만 하지 않아서 좋지 않다.
- 함수의 인수 종류와 개수.
1. 인수의 개수
최대한 없는 것이 좋고, 불가피하게 인수 전달이 필요하면 1-2 개 정도가 적당하다.
우리가 사는 객체지향 세계에는 인스턴스 변수라는 것이 있고, this 키워드를 통해서 접근이 가능하다.
2. 인수의 종류
인수는 Input(입력 값)으로 인식한다.
그렇기 때문에 Output 역할을 하는 변수를 전달하는 것은 좋지 않다.
- 명령과 조회를 분리하라.
함수는 "어떤 행동을 수행" 하거나 "질문에 답" 하거나 둘 중 하나만 해야지 보기가 편하고 짧고 예측하기 쉽다 그렇게 하도록 노력하자.
- 오류 코드 보다 예외를 사용하라.
enum으로 처리하는 것보단 Try-Catch 문으로 예외처리를 하는 것이 코드의 가독성을 높여주고 변경의 유연성이라는 이점을 가질 수 있다.
trycatch 할지 throws 할지 어떻게 결정하나요? 컨트롤러에서는 trycatch를 서비스에서는 throws를 쓰는데 사람마다 다르다.
3. Object & Structure 객체와 자료 구조
- 객체란 - private 형식의 변수와 함수가 존재하는 클래스.
- 자료 구조란 - public 형식의 변수만 가지고 있고 함수가 없는 클래스.
1. 자료 (Data Type, Has Only Variables) / 객체 (Instance, Members + Method)의 비대칭
객체(Object)는 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개한다.
자료 구조(Structure)는 자료를 그대로 공개하며 별다른 함수는 제공하지 않는다. 자료 구조를 다루는 함수는 외부에 존재 한다.
2. 디미터 법칙 : 모듈은 자신이 조작하는 객체의 내부 구현을 몰라야 한다.
자료 구조의 케이스는 이 법칙이 적용되지 않는다. 모든 상태 값이 public으로 외부에 노출되기 때문이다.
객체는 상태를 숨기고 함수를 공개한다. 상태를 숨겨야 하기 때문에 조회 함수로 내부 구조를 공개하면 안된다라는 의미 이다.
3. 자료 전달 객체
자료 구조체의 전형적인 형태는 공개 변수(public variables)만 있고 함수(비지니스 로직의 일부를 처리하는 함수를 지칭) 가 없는 클래스다. 이런 자료 구조체를 때로는 자료 전달 객체(Data Transfer Object, DTO) 라고 한다 DTO는 굉장히 유용 한 구조체다.
4. 결론
객체는 동작(Action)을 공개하고 자료를 숨긴다. 그래서 기존 동작을 변경하지 않으면서 새 객체 타입을 추가하기는 쉬운 반면, 기존 객체에 새 동작을 추가하기는 어렵다.
자료 구조는 별다른 동작 없이 자료를 노출한다. 그래서 기존 자료 구조에 새 동작을 추가하기는 쉬우나, 기존 함수에 새 자료 구조를 추가하기는 어렵다.
위에서 본 예제 처럼, 무조건 객체지향이 정답은 아니다. 그렇기 때문에개발자는 편견 없이 이 사실을 이해해 직면한 문제에 최적인 해결책을 선택할 수 있는 능력을 키우는 것이 중요하다.
'강의 및 강연 > 원티드 프리온보딩 챌린지' 카테고리의 다른 글
프리온보딩 백엔드 챌린지(DB) - DB 기본기 다지기2 - (0) | 2023.10.22 |
---|---|
프리온보딩 백엔드 챌린지(DB) - DB기본기 다지기 1 - (0) | 2023.10.15 |