Readable Code ‐ 객체 지향 패러다임 이해하기 - dnwls16071/Backend_Study_TIL GitHub Wiki
📚 객체 지향 패러다임 - 객체 설계
- 관심사의 분리 - 높은 응집도와 낮은 결합도
- 객체 추상화 : 비공개 필드(데이터), 비공개 로직(코드)
- 공개 메서드 선언부를 통해 외부 세계와 소통 -> 각 메서드 기능은 객체의 책임을 드러내는 창구
- 객체 책임이 나뉨에 따라 객체 간 협력 발생
- 절차 지향에서 잘 보이지 않았던 개념 가시화
- 관심사가 한 군데로 모이기 때문에 유지보수성 향상
- 여러 객체를 사용하는 입장에서 구체적인 구현에 신경 쓰지 않고 보다 높은 추상화 레벨에서 도메인 로직을 다룰 수 있다.
- 생성자, 정적 팩토리 메서드에서 유효성 검증이 가능하다.
- setter 사용 자제
- 데이터는 불변이 최고다. 변하는 데이터라도 객체가 핸들링할 수 있어야 한다.
- 객체 내부에서 외부 세계의 개입 없이 자체적인 변경/가공으로 처리할 수 있는지를 확인한다.
- 만약 외부에서 가지고 있는 데이터로 데이터 변경 요청을 해야 하는 경우
set~이라는 단순한 이름보다는 update~같이 의도를 드러내는 네이밍을 고려하자.
- getter도 처음에는 사용 자제
- 외부에서 객체 내 데이터가 필요하다고 getter를 남발하는 것은 무례한 행동이다.
- 필드의 수는 적을수록 좋다. 불필요한 데이터가 많을수록 복잡도가 높아지고 대응할 변화가 많아진다.
- 필드 A를 가지고 계산할 수 있는 A` 필드가 있다면 메서드 기능으로 제공한다.
- 단, 미리 가공하는 것이 성능 상 이점이 있다면 필드로 가지고 있는 것이 좋을 수 있다.
📚 SRP(Single Responsibility Principle)
- 하나의 클래스는 단 한 가지의 변경 이유(책임)만을 가져야 한다.
- 객체가 가진 공개 메서드, 필드, 상수 등은 해당 객체의 단일 책임에 의해서만 변경되는가?
- 관심사의 분리
- 높은 응집도, 낮은 결합도
📚 OCP
📚 LSP
📚 ISP
📚 DIP