2014-01-24 1 views
0

따라서 단일 책임 원리 - 계급은 하나의 이유만으로 변경되어야하지만 어떻게 그 책임이 실제로 무엇인지를 효과적으로 판단해야합니다. 간단한 예 :S in SOLID - 어떻게/어디서 그 선을 그립니까?

public class UserManager 
{ 
    public void AddUser() { } 
    public void RemoveUser() { } 
    public void UpdateUser() { } 
} 

이 중 하나가 SRP를 손상시킬 수 있다고 주장 할 수 있습니다. 그래서 결국 두 사람을 위해 DI를 사용하고 결국 다음과 같이됩니다.

public class UserManager 
{ 
    private UserRemover _remover; 
    private UserUpdater _updater; 

    public UserManager(UserRemover remover, UserUpdated updater) 
    { 
     _remover = remover; 
     _updater = updater; 
    } 

    public void AddUser() { } 
    public void RemoveUser() { } 
    public void UpdateUser() { } 
} 

사용자 관리와 관련된 다른 방법이 있다면 어떻게 될까요? 그 길을 계속 가면 생성자에 추가 의존성을 계속 전달할 수 있을까요? 둘 이상의 public 메소드를 가진 클래스의 경우, SRP를 깨뜨린다 고 주장 할 수 있습니다. 상식을 사용하고 옵션 1과 함께 가나 순수 주의자가되어 옵션 2를 사용합니까?

+0

이것은 의견을 바탕으로 작성되었습니다. 그러나 누군가가 당신에게 옵션 2가 더 좋다면 나는 충격을받을 것입니다. 극단적 인면에서 보잘것 없다. – StilesCrisis

+1

답변은 의견을 기반으로하지 않습니다. 대답은 "SRP가 깨질 때까지 SRP를 깨지 못한다"입니다. 서로 다른 사용자를 다른 방식으로 제거하기 위해 사업 적 이유가있을 때까지 고유 한 "UserRemover"가 필요하지 않습니다. 따라서 비즈니스 요구 사항이 발생할 때까지 동일한 수업을 계속하십시오. 그런 다음에 만 리팩터링하여 새 함수를 삽입하십시오. (애자 일의 YAGNI 원칙을 기억하십시오.) –

답변

2

단일 책임 원칙

A. UserManager의 책임은 무엇입니까?

  1. 사용자를 업데이트 할 때 무엇을합니까?
  2. 사용자를 삭제할 때 무엇을합니까?
  3. 사용자를 추가 할 때 무엇을합니까?

방법이 간단하면 DB의 사용자를 업데이트하는 것보다 MORE를 수행하지 않습니다. UserManager의 책임은 아마도 UserRepository 일 수 있습니다.

또는 아마도 UserManager의 책임은 사용자 목록과 비슷할 것입니다. List 객체를 보면. 다른 하위 클래스를 많이 사용합니까? 아니. 이 상황이 발생하면 UserManager 개체의 이름을 UserList 개체의 이름으로 변경해야합니다.

이 상황에서 SRP 원칙을 잘 모르는 주된 이유는 MANAGER라는 단어가 특별한 것을 의미하지 않기 때문입니다. 더 나은 이름을 찾으려고하면 대답을 찾을 수 있습니다. 클래스가 더 구체적인 객체에 액세스해야하는 경우 이름에 표시됩니다.

또한 단위 테스트를 통해 문제를 파악하는 것이 좋습니다. 단위 테스트는 그러한 신비를 드러내는 좋은 방법입니다.

또한 순수 주의자는 그런 종류의 문제를 설계하는 것이 아닙니다.) 조기 최적화는 모든 악의 근원입니다.