안녕하세요 이웃님들~
요즘 클린 아키텍처를 읽어보고 있는데요~!
평소 많이 보는 SOLID 원칙은 인터넷 상에 자료가 많으니
컴포넌트 응집도 3가지 원칙인 REP, CCP, CRP를 정리해 보려고 합니다~!!!
재사용 단위는 릴리스 단위와 같다
컴포넌트가 릴리스 절차를 통해 추적 관리가 되고, 릴리스 번호가 부여되어야 한다는 원칙입니다. 그래야 컴포넌트의 사용자인 개발자가 이 컴포넌트를 계속 재사용 할지 여부를 결정할 수 있게 된다는 것 인데요.
책에서도 당연한 얘기 아니냐고 하지만, 당연한 이 원칙이 지켜지지 않으면 컴포넌트를 사용하는 것이 사용자 입장에서 꺼려지겠죠!
동일한 이유로 동일한 시점에 변경되는 클래스를 같은 컴포넌트로 묶어라.
서로 다른 시점에 다른 이유로 변경되는 클래스는 다른 컴포넌트로 묶어라.
이 원칙의 설명을 딱 들어보면 뭔가... 단일 책임 원칙(SRP)가 생각 나지 않나요? 단일한 클래스는 변경의 이유가 한 곳에서만 발생을 해야한다는 것이 단일 책임의 원칙에 나오는데요..! 그것의 컴포넌트 버전의 원칙이 CCP 라고 합니다.
REP가 재사용에 관한 원칙이라면 CCP는 유지보수에 관련된 원칙인데요! 유지보수를 할때 가장 문제되는게 어디서 변경이 일어나서 여기저기 사이드가 나는거겠죠... 그래서 변경이 한곳에서 일어나면 여기저기 고쳐야 되기 보다는 한 곳만 그 변경에 영향권에 있는게 유지보수 면에서 좋겠죠! 또한 다른 컴포넌트까지 다 배포 할 필요 없이 변경점이 생긴곳만 배포 하면 된다는 장점도 있겠습니다.
그래서 같은 이유로 변경이 될 만한 클래스들은 묶어서 컴포넌트로 관리해주어야 한다고 합니다.
마찬가지로 개방 폐쇄의 원칙(OCP)가 생각이 나는데요! 이런 변경이 일어날 때 (물론 가능하면 확장을 하고 변경을 안하면 좋겠지만) 불가피하게 변경을 해야한다고 하더라도 변경의 영향범위가 한정되어 있으니 더욱 안정적으로 운영이 가능하도록 설계하는 것이라고 하네요.
컴포넌트 사용자들을 필요하지 않는 것에 의존하게 강요하지 마라
같이 재사용이 되는 경향이 있는 클래스와 모듈들은 같은 컴포넌트에 포함 되어야 한다는 원칙인데요.
이런 원칙들은 뭐를 해라~ 보다 하지말아라를 잘 봐야되겠죠..?
단 하나의 클래스만을 사용하기 위해서 하나의 컴포넌트로 묶어버리면 이미 의존성이 생겨버린 상태에서 하나의 클래스를 쓰더라도 사용하는 컴포넌트가 변경될때마다 의존성을 가지는 다른 컴포넌트로 바꿔줘야 하는 상황이 생길 수 있어요. 그래서 결합이 아주 강해야 하는 경우를 제외하면 단일 컴포넌트로 묶는 것을 경계해야 한다고 합니다.
[iOS, 트러블 슈팅] 소켓 데이터의 순서가 뒤바뀌어 들어와요 (1) | 2023.06.01 |
---|---|
SeSAC 새싹 iOS 개발자 데뷔과정 지원자의 질문 Top 8 (3) | 2023.05.04 |
iOS 앱개발을 배울 노베이스, 초보 개발자 학생을 찾습니다. (과외정보) (6) | 2023.02.02 |
[청취사/취업후기] SeSAC iOS 개발자 데뷔과정 그 후의 생활 (11) | 2022.10.14 |
[취준] iOS 신입 개발자 코딩테스트 보는 꿀팁 (2) | 2022.07.02 |