일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- 책임부과
- 셀렉트어드민
- 어드민 페이지
- SROOM
- nestjs library
- coarse-grained
- nestjs decorator
- 오브젝트
- API 설계
- 자바
- 추상 클래스
- 파일조회
- java
- 티스토리챌린지
- 오블완
- SW마에스트로
- Mock
- API 개발
- YouTube Data API
- jest
- 권한검증
- NestJS
- guard
- nestjs libraries
- typeorm
- 멀티테넌시
- monorepo
- Connection pool
- mailerservice
- fine-grained
- Today
- Total
목록오브젝트 (2)
독산구너
이 글의 목적 - '스룸' 프로젝트의 리팩토링 과정을 설명하고자 합니다. - '스룸' 프로젝트의 공동 개발자들에게 재설계한 객체 협력 구조를 설명하고, 피드백 받고자 합니다. 설계 원칙 '코드로 이해하는 객체지향 설계, 오브젝트' 를 읽고 데이터 중심 설계가 아닌 객체 지향 설계를 하여 '스룸' 프로젝트 BE 소스코드를 리팩토링 하고자 합니다. 많이 부족하지만, 다음과 같은 기준을 두고 설계를 해보았습니다. 1. 책 오브젝트에서는 객체들에게 적절한 책임을 부과하고 객체간의 협력관계를 가지게 하는것은 어려우며, 데이터 중심 설계로 먼저 코딩한 뒤, 이를 바꾸는 방식도 괜찮다고 하였습니다. 이미 모든 서비스 로직이 마련되어 있으니, 최대한 객체의 데이터가 아닌 책임과 역할에 집중하고자 합니다. 2. 객체보다..
이 글의 목적 - '스룸' 프로젝트의 BE 구조 리팩토링의 필요성을 설명하고자합니다. 리팩토링을 하게 된 과정 '스룸' 프로젝트를 진행하는 '4m9d' 팀의 SW마에스트로 백엔드 담당 멘토님께 BE repo 코드 피드백을 받았습니다. 내용은 다음과 같습니다. - service에서 하는 일이 너무 많다. - 의존관계가 복잡하다. 이상하다. - private과 public 인 경우를 구별해라 - 자바 공부를 해라 이러한 피드백을 자바 스프링을 사용하여 개발을 하는 과정에서 '객체지향적인 코드를 작성하지 않았다'라는 의미로 받아들였고, 조영호 저자인 '코드로 이해하는 객체지향 설계, 오브젝트' 를 읽고 이를 프로젝트에 적용하여 리팩토링 하게 되었습니다. '오브젝트' 의 내용 간략하게 책 '오브젝트' 의 내용을..