PlayData 9월 30일 정리

1. 스프링 프레임 워크

   가. Solid 객체지향 설계원칙 

         1) SRP 단일 책임 원칙

              클래스를  작은 단위로 분리하여 단일 책임을 부여하는 원칙, 따라서 관련있는 기능끼리 분류할 필요가 있다.

              예를 들어 클래스 별로 사용자 정보만 관리하는 클래스, 유효성 검사만 하는 클래스 등을 나누어서 설계한다. 

              이는 코드의 유지보수성이 증가하고 다른기능을 추가하거나 변경할때 영향을 최소화 할수있다.  

 

          2) OCP 개방-폐쇄 원칙

              확장은 가능하지만 변경은 닫혀있어야 하는 원칙. 다시말해서 인터페이스를 이용하여 클래스를 제작하여
              메서드의 통일을 할수있다. 인터페이스를 이용하여 만든다. 인터페이스는 다형성을 폭넓게 혀용(?)하기 떄문에
              인터페이스를 이용하는 것이 효율적일 수 있다.

 

           3) LSP 리스코프 치환 원칙 

              자식 클래스가 부모클래스의 인스턴스 대신 사용될때 언제나 정상적으로 작동해야 한다는 것을 의미 한다,

               따라서 부모의 인스턴스에서 정의한 것에 따라  동작할 수는 있다. 그러나 아예 다른 식으로 동작하는
               것은 안된다. 따라서 굳이 필요없는 메소드는 그냥 없애 버린다.

              

            4) ISP 인터페이스 분리 원칙 

              위에서 언급한 단일 책임원칙 SRP와 비슷한 맥락이다. 그러나 ISP는 인터페이스내에서 사용하지 않는 
               메서드에 의존하지 않도록 인터페이스를 작게 분리해야 한다는 것이다.

              

            5) DIP 의존성 역전의 원칙

               기능에 매몰되지 않고 역할에 충실해야 한다. 고차원 모듈은 저차원 모듈에 의존해서는 안된다. 추상화는
               세부사항에 의존해서는 안된다.

 

이건 그냥 암기하듯이 알고있어야 한다.

 

 

< 실습 >

chap1에서 인터페이스 활용없이 제작하다 보니 그때 그때 바꿔야 했고 의존성의 문제가 발생하였다.

 

위와 같이 지속적으로 객체를 만들어와서 개발자가 직접 수정해야 하는 문제가 발생한다. 

 

chap2에서 인터페이스를 이용하여 추상화를 했지만 아직 의존성 문제가 산재했다. 

각각 부문별로 인터페이스를 만들어서 implement를 진행하면 의존성문제를 어느 정도 해결할수있었지만 아직 의존성 문제가 산재하여 수정이 필요하다 .

 

chap3에서  APPconfig 파일을 만들어 이곳에서 객체를 생성하고 주입하는 방식으로 수정하였다. 

위처럼 config 패키지안에 AppConfig자바파일을 만들어서 객체를 대신생성하도록 유도하였다.

 

chap4에서 class에 component를 이용하여 bean등록을 하였다.또, AutoWired를 이용하여 자동으로 연결할수있다. 그러나 2개 이상의 정보가 들어오게 되면 문제가 발생하여 각각 component에 별칭을 부여하였다. 또, Qualifier를 이용하여 타입이 여러개일때 명확히 구분되도록 만들수있다. 

위와 같은 방식으로 바꿔서 사용하여 의존성 문제를 해결 할수있다.