OOP 띵로그

/

OOP

2

단일 책임 원칙 (Single Responsibility Principle, SRP) - SOLID 오늘 이야기할 단일 책임 원칙(SRP)은 이 SOLID 의 다섯 가지 원칙 중 첫 번째에 해당하며, 이를 잘 이해하고 적용하는 것이 나머지 원칙들을 제대로 구현할 수 있는 토대가 된다고 생각합니다

0

2

6 months ago

25 min read

article-thumbnail

저는 사실 '상속' 을 별로 좋아하지 않아요 ?저는 왜 '상속'을 피하고 싶은지에 대한 이유와 컴포지션이 어떤 장점들을 제공하는지 비교해 보겠습니다

0

2

6 months ago

11 min read

article-thumbnail

·

I always hope you're happy.

태그

상속컴포지션개발방법OOP객체지향설계SOLID디자인패턴

최근 댓글

물론 정답은 없고, 책임의 기준은 사람마다 다를 수 있습니다. 하지만 ‘주문 서비스’라는 관점에서 보면, ‘주문’이라는 하나의 도메인 안에서 주문 생성과 취소는 당연히 하나의 책임으로 볼 수 있습니다. SRP는 클래스가 하나의 응집된 역할을 가지는 것을 강조하며, 주문 생성과 취소는 같은 도메인에 속하는 연관된 기능이라고 생각합니다 :)

클래스는 한 가지의 책임만을 가져야 한다고 하는데, 그렇다면 OrderService는 '주문하기' 라는 함수가 있다면 '주문 취소'라는 함수를 갖는 것은 2가지 책임을 가지는걸까요?

저는 특히 IDE에서 자동으로 호출할 수 있는 메서드들을 불러올 때, 상속 구조에서는 원치 않는 슈퍼클래스의 메서드들까지 리스트에 포함되어 양이 많아져서 은근히 불편함을 느낍니다 🤣 컴포지션이라면 제가 원하는 `클래스`.`메서드` 형태로 정확히 찾아갈 수 있는데, 상속일 경우 모두 한꺼번에 나와 스트레스가 쌓이더라구요.. 그래서 저는 항상 가능하면 컴포지션 방식을 선호하고, 꼭 필요한 경우가 아니라면 상속은 지양하는 편입니다:)

스프링에서는 로깅, 인증 등과 같은 횡단 관심사 로직을 어노테이션 기반 AOP를 통해 처리할 수 있기도 하고, 여차하면 Spring Event 같은 것을 활용해서 이벤트 기반 아키텍처를 구축하는 것이 어쩌면 그냥 상속해서 비즈니스 로직을 구현하는 것보다 더 유연한 설계를 지원하는 것 같아요. 그래서 더더욱 도메인 객체 같은 걸 짤 때가 아니라면 오히려 상속을 쓸 일이 잘 없게 되는 것 같아서 신기해요