처음 업무를 맡아서 원 소스를 받았을때 코드를 보기가 힘들었다. 눈에 들어오지도 않을뿐더러 이게 왜 필요한 메소드인지 왜 필요한 로직인지 이해조차 할수 없었다. 내 스타일의 코딩이 아니었고 처음 보는 구조였고 내가 익숙한 코드도 아니었다. 온갖 핑계와 이해가 안된다며 스스로 안좋은 코드라고 정의내렸다. 이는 좋은 코드는 무엇인가에 대한 고민으로 이어졌고 또 이 원 소스가 정말로 안좋은 코드인가에 대한 고민과 이해에 대해 이어졌다. 결론은 내가 문제였다. 핑계로 점칠돼 소스를 이해하지도 않았고 이 소스의 진짜 문제가 무엇인지도 몰랐다.
이에 체계적이고 유지보수가 가능한, 또 적재 적소에 필요할때 사용할수 있는 또 누구에게나 익숙한 코딩 스타일과 패턴을 익히고 사용하기위해 디자인 패턴 공부의 필요성을 느꼈다.
디자인 패턴이란?
필요성을 느끼고 나서 이것저것 책도 살펴보고 검색도 해봤지만, 어려운 말 이해되지 않는 내용과 깊은 지식과 경험을 필요로하는 조언들이 넘쳐났다. 누군가가 오랫동안 생각하고 만들고 조언한 내용들이란것은 알겠지만, 이제 갖 디자인 패턴의 필요성을 느끼고 입문하려니 너무 어려운 말들 뿐이었다.
일단, 한걸음씩 오늘은 여러 부분에서 공통적으로 강조하는 SOLID 원칙에 대해 이해하고 넘어가자.
SRP ( 단일 책임 원칙 : Single Responsibility Principle ) : 하나의 클래스는 하나의 책임만 가져야 한다. OCP ( 개방 / 폐쇄의 법칙 : Open/Closed Principle ) : 확장에는 열려있어야하고, 변경에는 닫혀있어야 한다. LSP ( 리스코프 치환의 원칙 : Liskov Substitution Principle ) : 서브 타입은 언제나 기반 타입으로 교체할 수 있어야 한다. ISP ( 인터페이스 분리 원칙 : Interface Segregation Principle ) : 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다. DIP ( 의존관계 역전의 법칙 : Dependency Inversion Principle ) : 추상화에 의존해야지 구체화에 의존하면 안된다.
더 자세한 내용! http://www.nextree.co.kr/p6960/ http://pooh-explorer.tistory.com/5 http://alleysark.tistory.com/197
출처: http://devshock.tistory.com/58 [Developer]