setter 주입이 왜 안되는지 생각해볼것

public class MemberService implements UserDetailsService {
    private final NonSocialMemberRepository nonSocialmemberRepository;
    private final SocialMemberRepository socialMemberRepository;

    public MemberService(NonSocialMemberRepository nonSocialmemberRepository, SocialMemberRepository socialMemberRepository) {
        this.nonSocialmemberRepository = nonSocialmemberRepository;
        this.socialMemberRepository = socialMemberRepository;
    }

    public Long join (NonSocialMemberSaveForm nonSocialMemberSaveForm) throws NoSuchAlgorithmException {
        int login_type = nonSocialMemberSaveForm.getLogin_type();
        //중복 처리 한번더 검증
        validateDuplicateEmail(nonSocialMemberSaveForm,login_type);
        validateDuplicateName(nonSocialMemberSaveForm,login_type);
        Long user_id = -1L;

        //로그인 타입별 다른 회원가입 로직
        switch(login_type) {
            case 0: // non-social 회원가입의 경우
            {
                NonSocialMember member = new NonSocialMember(); // DAO (Entity)로 바꾸는 작업
                member.setUser_name(nonSocialMemberSaveForm.getUser_name());
                member.setUser_email(nonSocialMemberSaveForm.getUser_email());
                member.setUser_pw(nonSocialMemberSaveForm.getUser_pw());
                NonSocialMember saveMember = nonSocialmemberRepository.save(member);
                user_id = saveMember.getUser_id();
                return user_id;
            }
            case 1: //social 회원가입의 경우 -> 요청 필요
            {
                throw new NotYetImplementException("해당 요청은 아직 구현되지 않았습니다.");
            }
        }
        return user_id; // non valid request, return -1
    }

    public void validateDuplicateName(NonSocialMemberSaveForm memberForm, Integer login_type){
        MemberRepository memberRepository = null;
        switch(login_type){
            case 0: {
                memberRepository = nonSocialmemberRepository;
                break;
            }
            case 1: {
                memberRepository = socialMemberRepository;
                break;
            }
        }
        log.info("check = {}",memberRepository.findByName("hi"));
        memberRepository.findByName(memberForm.getUser_name()).ifPresent(m->{
            log.info("name check");
            throw new IllegalStateException("이미 존재하는 회원 닉네임입니다.");
        });
    }

    public void validateDuplicateEmail(NonSocialMemberSaveForm memberForm, Integer login_type){
        MemberRepository memberRepository = null;
        switch(login_type){
            case 0: {
                memberRepository = nonSocialmemberRepository;
                break;
            }
            case 1: {
                memberRepository = socialMemberRepository;
                break;
            }
        }
        memberRepository.findByEmail(memberForm.getUser_email()).ifPresent(m->{
            throw new IllegalStateException("이미 존재하는 회원 이메일입니다.");
        });
    }

    @Override
    public UserDetails loadUserByUsername(String userEmail) throws UsernameNotFoundException {
        Optional<NonSocialMember> nonSocialMember = nonSocialmemberRepository.findByEmail(userEmail);

        if (nonSocialMember.isPresent()) {
            NonSocialMember member = nonSocialMember.get();
            log.info("member info in loadByUsername method = {}", member.getAuth_id());
            //non social, social 섞어있기 때문에, user_id를 CustomUserDetail 의 id로 생성합니다. ->토큰의 getName의 user_id가 들어갑니다.
            return new CustomUserDetails(member.getUser_id(),member.getUser_email(),member.getUser_pw(),true,false );
        } else {
            throw new UsernameNotFoundException("User not found with userEmail: " + userEmail);
        }
    }

}

SOLID 원칙중
SRP가 완전히 깨졌다고 볼 수 있나..?....

지금의 코드는 완벽히 구현체에 의존하고 있지만, 지금상황에서는 필수적으로 보인다.
왜냐하면, 회원가입,로그인 로직을 구현할때 소셜로그인과, 일반로그인의 로직이 다르기 때문이다.
그래서 이를 아예 로그인 구현에 맞는 다른 서비스구현체에 다른 repository를 참조하게 만들어야 한다.

하지만 여기서 생각이 든게 setter 주입으로 바꾼다면, 괜찮지 않을까 생각했었는데,
생각해보니 setter주입은, 주입을 유연하게 하기위한 것으로써, repository 구현체를 바꾸는 것이 훨씬 이상하다.
예를들어, bean으로 등록된 어떤 객체를 주입할지 말지, 이런 유연성의 측면에서 setter주입이 괜찮아 보인다.

물론 생성자 주입에서도 @Nullable 로 유연하게 할 수도 있다..

사실 아직까지 setter주입의 요긴한점을 모르겠다..