SOLID에 따르면 기능 또는 범주별로 중복성을 제거 할 예정입니까? 예를 들어SOLID에 따른 중복
우리는 각각의 멤버 변수로 String filepath = "..."을 포함 3 개 클래스는, 멤버 변수로 filepath와 즉 Settings.java을 새로운 클래스를 만드는 더 나은 것이 있다면 또는 각에서 filepath 3 회를 유지하기 위해 더 나은 것 각 클래스가 자체 속성에 대한 전적인 책임을 지도록 클래스가 속한 클래스
나는 또한 당신이 무엇이 최선인지 이해하기에는 너무 적은 정보를 제공한다고 주장 할 것이다.
중복 그 자체에 대해 말하는 SOLID 원칙은 기억하지 않지만 DRY 원칙이 있습니다.
중복에 대해 알아 낸 점은 여러 장소에서 한 가지 작업을 수행하는 경우 작업을 수행해야하는 모든 장소를 업데이트해야한다는 점입니다. 한 곳을 잊어 버린 경우 시스템에 불일치가 생겨서 개념 상 동일한 작업을 수행하는 데 최소한 두 가지 방법이 있습니다.
일반적으로 항상 쉽게 찾아 낼 수없는 버그가 발생합니다.
물론 이것은 중복성이 없어도 쉽게 해결할 수 있습니다. 무언가를하기 전에 해당 기능이 이미 시스템에 있는지 확인하고 관련이없는 항목을 찾아 일반화하려고 시도하십시오.
아니오 "는 멤버 변수로 파일 경로와 새로운 클래스, 즉 Settings.java을 만들 좋을 것이다"그게 더 좋을 거라 생각하지 않습니다. 세부 사항이 없으면 어렵지만 ISettings와 같은 인터페이스를 만들어 DI를 사용하여 필요한 클래스에 주입 할 수 있습니다.
솔리드와 더 많은 인라인이 될 것이라고 생각합니다.
직접 반복하지 말아야 할 것은 Single Responsibility Principle의 "측면"입니다. SRP는 학급이 변할 하나의 이유 만 가져야한다고 말합니다. DRY는 사실에 대한 진실의 단일 소스가 있어야한다고 말합니다. 따라서 사실을 변경하면 그 사실에 의존하는 모든 것이 귀하의 한 변경에 영향을받습니다.
귀하의 경우, 각 클래스의 사용법은 filepath입니다. 특정 비즈니스 요구 사항을 충족시키기 위해 파일에 공통 경로가 있어야하는 경우, 모두 단일 정의를 참조하고 해당 요구 사항을 포함하는 어딘가에 보관해야합니다. 그렇지 않으면, 그들은 아마도 독립적 인 선언을 가져야합니다. 그렇지 않으면 매우 재사용 할 수 없을 것입니다.
필자는'filepath'가'interface'로 여겨 져야하는 이유를 이해합니다. 'filepath'가 각 클래스마다 고유하거나 불가능할 가능성이있는 좋은 생각입니다. 각 클래스에서 필요에 따라 변경할 위치를 알아 두십시오. 아마도'filepath'를 변수로 사용하는 non-singleton/non-static 재사용/동적 클래스'Settings.java'를 갖는 것이 유용 할 것입니다. 왜냐하면 미래의 개발을 위해 모든 변경이 필요한 곳을 찾기가 쉽기 때문입니까? – ThreaT