SOLID (object-oriented design)

객체지향적으로 개발 할 때 OOD를 따져서 설계하고 개발한다면 더욱 더 좋은 소스가 될 수 있다.

한번 알아보도록 하자!

 

출처 : http://en.wikipedia.org/wiki/Solid_(object-oriented_design)

 

추억의 솔리드..ㅋㅋㅋㅋㅋ 이밤에 끝을 잡고~

 

Initial	Stands for (acronym)	Concept
S	SRP	Single responsibility principle - 단일 책임의 원칙 a class should have only a single responsibility. 하나의 클래스에 오직 하나의 책임이어야 한다는 원칙. 예를 들어 MVC 패턴이 나오기까지...jsp에 모든 것을 다 때려 넣었던 그런 시절이 있었다...단일 페이지에 모든 것을....와우! 그런 것처럼 하나의 클래스에 하나의 책임을 주어서 유지보수와 소스의 가독성, 재사용성을 높일 수 있다.  ex) Class에 오직 하나의 책임..그렇다면! 메소드도 있는데??? 그렇다! 하나의 Class에 여러가지 메소드가 있을 것이다. 그 메소드들이 Class들 마다 하는 역할을 구분하여 오직 하나의 역할(책임)을 줘야 한다는 뜻이다.   즉, public class acetData{           public void load(){              .........................            }             public void save(){              .........................            }             public void del(){              .........................            }              public void displayToUi(AcetVo acetVo){              .........................            }             }   위의 클래스에서 Data와 관련 된 메소드는 데이터를 load 데이터를 save 데이터를 del 이렇게 3가지이며, 데이터 관련 책임이라고 볼 수 있으며, displayToUi는 UI 화면에 데이터를 뿌려주는 것! 즉, 화면에 보여주는 책임이라고 볼 수 있다.  displayToUi는 UI Class로 빼줘야 한다.
O	OCP	Open/closed principle - 개방 폐쇄의 원칙 “software entities … should be open for extension, but closed for modification.” 요녀석은 확장에 대한 open~!!!!! closed는 수정에 대한 내용이다. 라고 대부분 나와있다..ㅋㅋㅋㅋ 여기에서 중요한 것은!!! 확장이다! 영어로 extension~!! 수정에 대한 closed 즉, 수정이 되면 안된다는 것이다. 어떨때??? 확장 땜시롱! 확장을 위해! open! 확장이 매우 용이하게!! 그렇다고 본 소스를 마구마구 수정하면 No!! 즉, 수정에 대한 것은 closed!! 결론적으로 확장을 잘하기 위한 원칙이다. 바로 상속의 개념인 것이다. 즉, 공통적인 부분을 추상하여 SubClass나 SubType으로 표현한다. 자세히 말하면 바로 SubClass(extends), SubType(implements) 인 것이다.
L	LSP	Liskov substitution principle - 리스코프 치환 원칙 “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” See also design by contract. 너무나도 헷깔렸던 개념이다..-_-;; 그 이유가 SubClass와 SubType 차이를 몰랐었고...OCP나 LSP는 요 2가지로 표현이 된다는 것이다.. 특히 위에 나오는 영어에서도 보면 subType의 인스턴스가 교체된다는 것인데... 여기에서 교체된다는 말이 code로 표현을 어떻게 해줘야하는건지...잘 떠오르지 않았다..주변 동료에게 이런저런 이야기를 같이 해보다가...알게 되었다^-^ 우선 정의를 보도록 하자. 정의 :  1) SuperClass(상위타입)을 SubClass(하위타입)로 교체(치환)해도 정상 작동 해야 한다.        또는 2) SuperType(상위타입)을 SubType(하위타입)로 교체(치환)해도 정상 작동 해야 한다.               1)은 Class기반의 상속을 생각하면 된다.         2)는 Interface 기반의 상속(구현)을 생각하면 된다.           1)은 말그대로 객체를 치환하여도 같은 동작을 하면 OK!!         2) 객체를 치환한다는 개념으로 접근하기보다 SubType의 기능 수행으로             생각하면 된다. ex) dataSave()면 데이터 저장인데 그 안에서 modify기능을             하면 안된다.            이 원칙은 OCP를 잘 구현하기 위해 체크하는 스펙 같은거라고 보면 될 것 같다.          반대로 말하면 리스코프 치환 원칙을 지키지 않으면 OCP를 지키지 않을          가능성이 커진다는 것이다.            특히 2번, 인터페이스 기반에서는 치환이라는 개념 자체가 이해가 가질 않았을          것이다..그러므로 기능, 리턴, 예외 등 올바른 작동을 하는지 봐야 한다. 참고 사이트 1)http://www.cs.princeton.edu/courses/archive/fall98/cs441/mainus/node12.html 2) http://vandbt.tistory.com/41 3) http://hyukmini.tistory.com/16
I	ISP	Interface segregation principle - 인터페이스 분리 원칙 “many client-specific interfaces are better than one general-purpose interface.”[4]   많은 뚜렷한 인터페이스들은 하나의 일반적인 취지의 인터페이스보다 낫다. 옹마~앙대요~~왜이리 말이 어려운지.....OTL =3=3   인터페이스 분리 원칙은..클라이언트를 기준으로 인터페이스를 분리하는 원칙. 이 말을 다시 풀어보면..   각 클라이언트가 사용하는 기능을 중심으로 인터페이스를 분리함으로써, 클라이언트로부터 발생하는 인터페이스 변경의 여파가 다른 클라이언트에 미치는 영향을 최소화 할 수 있게 된다.         생각해보자! 기능 중심?????? 인터페이스를 분리해??? Why??         인터페이스를 하나 만들려고 한다. 그 안에는 여러가지 메소드들이         많이 있을 것이다.         즉, ISP의 원칙을 잘모른다면..동작의 역할 인 메소드들이 뒤죽박죽         하나의 인터페이스에 얽혀있을 것이다.         하지만 ISP를 잘~~알고 인터페이스를 만든다고 하면! 바로 기능중심!!! 으로         나눠서 이쁘게 잘~~~쓰게 될 것이다.       참고문헌 : 개발자가 반드시 정복해야 할 객체지향과 디자인 패턴(최범균 저)
D	DIP	Dependency inversion principle - 의존관계 역전의 법칙 one should “Depend upon Abstractions. Do not depend upon concretions.”[4] Dependency injection is one method of following this principle.        DI(Dependency Injection)이라고 보면 된다. springframework의 특징       중인 IoC/DI 이다. 커플링을 최소화시키며(외부주입을 해주니깐!)         특히, 생성자 또는 setter로 주입을 시키는 특징이 있다.

 

 

                 - END -