본문 바로가기
프로그래밍 놀이터/안드로이드, Java

[Spring] Spring Framework 의 개요 #2

by 돼지왕 왕돼지 2013. 6. 25.
반응형


 Spring Framework의 개요 #2

 


[Spring] Spring Framework 의 개요 #2


변화를 예상 -> design pattern 적용 가능.



관심사의 분리( Separation of Concerns )


관심이 같은 것끼리는 하나의 객체 안으로, 관심이 다른 것은 가능한 따로 떨어져 영향을 주지 않도록 분리.




템플릿 메소드 패턴( Template Method Pattern )


슈퍼클래스에 기본적인 조작의 흐름을 만들고, 그 기능의 일부를 추상 메소드나 오버라이딩 가능한 protected 메소드 등으로 만든 뒤, 서브클라스에서 이런 메소드를 필요에 맞게 구현해서 사용하도록 하는 방법.


이 때 선택적 override 가능한 method 를 hook method 라고 한다.




팩토리 메소드 패턴( Factory Method Pattern )


서브클래스에서 구체적인 오브젝트 생성 방법을 결정하게 하는 것. 보통 interface type 의 object 를 return 한다.




디자인 패턴( Design Pattern )


소프트웨어 설계 시 특정 상황에서 자주 만나는 문제 해결을 위해 사용할 수 있는 재사용 가능한 솔루션.

주로 객체지향 설계에 관한 것이고, 객체지향원칙을 이용해 문제 해결.

보통 클래스 상속과 오브젝트 합성이 그 방법.

패턴에서 가장 중요한 것은 핵심 목적 또는 핵심 의도이다.







상속의 단점


1. Java 는 다중상속이 불가능하다.


2. 상하위 클래스가 강하게 결합된다.

super class 의 내부변경이 생기면, sub class 를 함께 수정하거나 다시 개발해야 할 수도 있다.

변하지 않는 super class 라는 제약이 추가된다.




추상화


한 class 가 사용하는 다른 class 에 대해 자세히 아는 것은 좋지 않다.

종속성이 강해지고, 확장이 어렵다.

이럴 때 사용하는 것이 interface 를 이용한 추상화이다.




개방 폐쇄 원칙( OCP, open-closed principle )


클래스나 모듈은 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다.




객체지향 설계원칙( SOLID )


SRP ( The Single Responsibility Principle ) : 단일책임의 원칙

OCP ( The Open Closed Principle ) : 개방 폐쇄의 원칙

LSP ( The Liskov Substitution Principle ) : 리스코프 치환원칙

ISP ( The Interface Segregation Principle ) : 인터페이스 분리 원칙

DIP ( The Dependency Inversion Principle ) : 의존관계 역전 원칙




높은 응집도와 낮은 결합도 ( High Coherence and Low Coupling )


하나의 module, class 는 하나의 책임 또는 관심사에만 집중한다.





겹합도

하나의 오브젝트가 변경될 때 관계를 맺고 있는 다른 오브젝트에게 변화를 요구하는 정도를 이야기한다.


높은 응집도

변화가 일어날 때 해당 모듈에서 변하는 부분이 크다.

부분수정은 오히려 검증이 어렵다.

단일 책임으로 세분화시켜 모두 변하도록 해야 한다.


낮은 결합도

다른 오브젝트 또는 모듈과 낮은 결합도를 가진다.

즉 느슨하게 연결된 형태를 유지해야 한다.

느슨한 연결은 관계를 유지하는데 꼭 필요한 최소한의 방법만 간접적인 형태(interface)로 제공한다.

낮은 결합도는 하나의 변경이 다른 모듈과 객체의 변경을 요구하지 않는 것.

따라서 결합도가 낮으면, 변화에 대응하기 쉽고, 구성도 깔끔하며, 확장도 편리하다.




전략 패턴( Strategy Pattern )


자신의 기능 맥락( Context ) 에서 필요에 따라 변경이 가능한(필요한) 알고리즘을 interface를 통해 통쨰로 외부로 분리하고, 이를 구현한 구체적 알고리즘 클래스를 필요에 따라 바꿔서 사용할 수 있게 한 design pattern.




제어의 역전( IoC, Inversion of Control )


자신이 사용할 오브젝트를 스스로 선택하지 않는다. 당연히 생성하지도 않는다.

자신도 어떻게 만들어지고 어디서 사용되는지를 알 수 없다.

모든 제어 권한을 다른 대상에게 위임하고, 수동적 자세를 취한다.








라이브러리( Library ) 와 프레임워크( Framework ) 의 차이


Library는 App이 흐름을 직접 제어하여 사용한다.


App의 코드가 Framework에 의해 사용된다.

Framework에 Class 등록, Framework 가 흐름을 주도한다.

분명한 제어의 역전(IoC) 개념이 있어야 Framework 라 할 수 있다.



반응형

댓글