DI (Dependency Injection) 의존성 주입을 왜 하나요?

의존성을 제거하기 위해서다.

의존성을 제거했기 때문에 다시 의존성을 주입해주는 거다.

 

몇 년 전부터 스프링이 대세가 되면서 당연히 DI의 개념도 화두가 되며 널리 퍼지게 된 것 같다.

스프링의 시작이 DI니까.

 

그럼 의존성이 뭐대요?

 

 

다른 것에 의지하여 존재하는 클래스 or 소스파일이 되겠다.

다시 말하면 다른 클래스에 의지하는 클래스가 되겠다.

즉 다른 클래스가 있어야 빌드가 되는 클래스다.

    public class MyFileSender{

        Ftp ftp = new Ftp();        
		
		public ReadFile(){
			ftp.Read("filename.txt");
		}
		
		public WriteFile(){
			ftp.Write("newfile.txt");
		}						

    }	

MyFileSender Class는 Ftp Class 가 있어야 Build 할 수 있다.

여기서 MyFileSender는 Ftp에 의존한다.

 

 

의존성 제거는 어떻게 하나요?

 

MyFileSender 는 Ftp에 의존하고 있다.

이 Ftp Class를 Inteface로 추출 한 후  Interface에만 의존 하는게 의존성 제거다.

    public interface IFile{
        void Read(string fileName);
        void Write(string fileName);        
    } 
	

    public class Ftp : IFile{
	
        public void Read(string fileName){
            ftp의 파일을 읽는다.......
        }
		
        public void Write(string fileName){
            ftp에 파일을 쓴다.......
        }
    } 

	
    public class MyFileSender{
	
        IFile file;
		
        public MyFileSender(IFile file_) { 
            file= file_
        }
		
		public ReadFile(){
			file.Read("filename.txt");
		}
		
		public WriteFile(){
			file.Write("newfile.txt");
		}				
    }

이제 MyFileSender에는 Ftp라는 단어가 하나도 없다.

Ftp에 대한 의존성이 제거 되었다.

의존성 주입은 생성자를 통해서 주입되게 했다.

 

이제 MyFileSender를 사용하는 곳에서는 아래 코드처럼 사용할 객체를 생성자에 넘겨 주면 된다.

MyFileSender sender = new MyfileSender(new Ftp());

new Ftp()까지 자동으로 넣어 주는게 Spring , Ninject , Unity같은 DI Container다.

 

 

의존성을 왜 제거 하나요? 좋은건가요?

 

Interface에만 의존 하는게 의존성 제거라고 위에서 말했다.

Interface에만 의존하면 Interface만 있으면 된다.

즉 IFile 만 있으면 Ftp Class가 없어도 MyFileSender를 빌드 할 수 있다는 얘기다.

나는 MyFileSender를 만들고 다른 사람은 Ftp 클래스를 만든다.

그러니까 딴 새끼가 Ftp 다 만들 때 까지 기다릴 필요가 없다.

당연히 팀의 개발속도는 빨라진다.

 

또 하나는 TDD 하기에 편하다.

근데 나는 TDD를 싫어 하기 때문에 자세히 안쓸란다.