확인, 하여 IComparable을 구현하고 하나의 클래스에 다른 인터페이스 (처럼 는 IDisposable)을 SRP 원칙의 위반. 모든 클래스는 signle Responsibility는과 방법을 구현해야합니다SOLID, SRP,에서 IComparable
SRP 상태는 응집력 클래스을 달성하기 위해 높은 수준의 상호 연결되어야한다.
다른 책임을 비교하지 않습니까?
일부 설명이 이해 될 것이다.
만약 내가 당신이라면 SRP를 고수하려고 노력할 것입니다. 그러나 그 노력이 마침내 역효과를 낳지는 않습니다. 이제 그 말로, 당신은 무엇을해야합니까? IComparable을 구현하고 비교를 개체에 완전히 캡슐화하거나 별도의 비교기를 사용하여 비교 논리를 구현합니다. 비교를 위해, SRP에 관해서는, 비교가 상당히 기본적이고 변경의 대상이되어서는 안되는 경우, 나는 IComparable을 구현하고이를 수행 할 것입니다. 미래에 약간의 변화를 합리적으로 예측할 수 있거나 비교가 유스 케이스에 따라 다르다면 비교기 경로를 사용할 것입니다. 궁극적 인 목표는 닫힌 구성 요소를 개발하여 구성하여 협업하도록하는 것이므로 비교할 기회가 거의없는 경우 구성 요소를 닫을 수 있으므로 다시 들으실 수 없습니다. 또한 코드에서 IComparable의 사용에 대해 언급 할 수 있으며 향후 변경이 발생할 경우 비교기를 사용하여 변경해야합니다. 변경 사항이 실제로 발생하지 않았기 때문입니다.
감사합니다. 따라서이 원칙을 고수하는 것이 그렇게 엄격하지 않아야합니다. 그것은 상황에 달려 있습니다. 엔티티 비교는 어떻습니까? –
SOLID는 도구이므로 끝내려는 수단이 아닙니다. 게다가 엄격함과 관용 사이를 선택하는 경우가 많습니다. 모든 변경 사항을 예측할 수 없으며 간단하게 유지해야합니다. 저의 겸손한 견해로 볼 때, 엄격한 SRP는 당신에게 힘을 실어 줄 것입니다. 엔티티에 관한 한, 엔티티가 영구 객체를 의미하는 경우, 앞서 작성한 객체가 여전히 보유하고 있습니다. 변경의 유사성과 일부 유스 케이스에 대한 의존성에 따라 다르며 향후 동일한 엔터티에 대해 서로 다른 비교를 사용하는 다양한 유스 케이스를 갖게 될 것입니다. –
나는 IComparable과 IDisposable의 임무가 이 아니며,이 아니므로 SRP를 위반하지 않을 것이라고 주장합니다.
SRP와 관련하여 책임은 시스템의 상호 작용자 (즉, 사용자, 역할 또는 외부 시스템)에게 있습니다. 귀하의 시스템에 비즈니스 요구 사항 문서가 있다면, 모든 책임은 적어도 기능적 또는 비 기능적 요구 사항 내에서 추론되어야합니다. 그렇지 않다면 어떤 사업주가 당신에게 물체가 어떻게 처분되는지를 물어볼 것입니다.
SRC에 대해 학습 한 첫 번째 프로젝트에서이 클래스를 "클래스 당 하나의 공용 메서드"로 해석하고이를 어려운 규칙으로 적용했습니다. 이로 인해 "컴플라이언스"를 유지하는 것이 쉬워졌지만, 필 요한 것보다 훨씬 복잡한 코드로 끝 맺었습니다.
IComparable/IDisposable 구현을 변경해야하는 경우 해당 변경은 클래스의 기능 (비즈니스) 부분에서도 변경 (동시에 이유)해야합니다.
그렇다면 ISP는 어떻습니까? SRP와 ISP는 모두 SOLID의 일부이므로 충돌하지 않아야합니다. –