Level : 13,717 WORDPRESS BOOK LINKEDIN PATENT Send Mail 동냥하기 윤지오

Digital Nomad

블로그 항해 일지/Design Pattern +2



0. 시작



최근 안드로이드와 iOS 파트를 후임들에게 물려주고 있다. 안드로이드 플랫폼 자체가 패턴 덩어리. 그리고 많은 디자인 패턴이 적용된 어플을 주고 있다. 당최 인터넷 찾아봐도 패턴을 잘 모르겠다는 후임들을 위해 세미나를 하고 있는데 작은 몇 마디 만으로도 Creational Pattern을 이해하는 것을 보고 실무 프로그래밍 중급편에 실릴 내용으로 세미나를 하여 여기도 적어 본다. 우선 "썰"이라 붙인 이유는 자세한 설명은 인터넷에 많으니 그들의 연결 개념을 전체적으로 말해두려고 한다. 열심히 공부하다 보면 이 글의 말로 Creational 패턴을 모두 연결할 수 있을 것이다.





1. 패턴 공부는 시작은 자바로



우선, 패턴은 자바 기준으로 공부하는 게 맞다. JAVA와 C#은 실무 프로그래밍을 한 입장 + 문법 관점에서 완전히 동일한 언어로 봐도 된다. C++도 마찬가지겠지만 그렇게 보면 안 되겠다. class 가 메소드(펑션, 함수)를 포함한다는 것을 빼면 struct랑 완전히 동일 개념이지만 다르다고 생각해야 하듯이 C++은 다른 언어로 봐야 한다. 물론, 공부할 때 생각만 다르다고 하는 것이지. C/C++, JAVA, C#, SWIFT에 적용되는 패턴은 완전히 동일하다. C/C++ 만 한 친구들에게 자바를 이해시키고 예제 코드를 짜게 하는데 딱 하루 걸렸다. 그다음 날은 전혀 스트레스 없이 완전하게 자바 코드를 짜고 자바 기반의 안드로이드 프로그램을 수정하기 시작했다. 그러나 자바 기준으로 이야기를 하는 것에 대해서는 이해를 하기 바란다.





2. 패턴을 만든 이유



진심은 이 글 제일 마지막에 적었다. 그러나 표면적 이론을 따지자면, 생성 패턴은 코드수를 줄이기 위해 만들었다. 코드수를 줄이는 방법은 재사용성을 높이는 것이고, 재 사용성을 높이려면 작은 조각으로 나누되 설계를 잘해서 만들어야 한다. 코드수가 많아지더라도 요구사항에 대해 더욱 유연하게 대응해서 개발 시작부터 Acceptance Test를 할 기간을 더 줄일 수 있다면, 그것은 패턴이 잘 적용된 것이다. 패턴 공부는 따로 안 해도 된다. 안드로이드 프로그래밍을 하면 된다. 거기 모든 패턴이 녹아 있다. 그래서 안드로이드 프로그래밍 한 달만 하고 이 글을 보면 바로 모든 게 이해될 것이다.





3. 한방에 설명



자바에서 메모리에 뭔가를 생성시키는 것은 딱 3가지밖에 없다. new, static, primitive type. 그러나 기본 자료형은 빼야 한다.(너무 당연한 것이고 기본자료형으로만 통신하는 프로토콜을 만들 때(안드로이드의 AIDL 같은)만 필요해서 빼는 것이다) 결국 2가지인데, Creational Pattern은 애들은 어떻게 쓰느냐에 따라 다른 것이다.



결국 static와 new를 어떻게 쓸 것이냐.







지워졌었던 내 글을 봤다면 다형성은 void 포인터로 for문을 돌리기 위해 만든 개념이고 캡슐화는 개발자를 믿지 못하기 때문에 만든 개념이라고 이해했을 것이다.





싱글톤 패턴은



생성자를 캡슐화하고 하나만 생성되게 하는 것이다. private으로 생성만 만들면 결국 캡슐화를 통해 매소드를 통해서 전달할 수밖에 없는데 하나만 전달하게 하면 싱글톤 패턴이 되는 것이다.







public static synchronized GlobalSetting getInstance() {



if (mInstance == null) {



synchronized (java.lang.Object.class) {



if (mInstance == null)



mInstance = new GlobalSetting();



}



}



return mInstance;



}







이런 녀석은 예제의 이름처럼 세팅값을 저장하고 여러 클래스에서 불러 쓸 때 매우 유용한다.





팩토리 매소드도 비슷한 녀석이다.







public FactoryMethodModel() {



ARM samsung = makeInstance();



ARM nvidia = makeInstance();



ARM qualcomm = makeInstance();







직접 NEW를 하지 않는 점에서.



다른 클래스에서 생성해서 리턴해 주도록 만들면 된다.







class SAMSUNGEngineer extends FactoryMethodModel {



@Override



protected ARM makeInstance() {



return new ARM("samsungARM");



}



}







문제는 왜 이렇게 만들까?



final List<ARM> armlist = new ArrayList<>();



리스트를 만들 수 있기 때문이다.



armlist.add(samsung);



이렇게 추가하기 위해서다.







자바의 abstract는 interface와 똑같은 녀석인데 멤버 자료형을 가질 수 있다는 점에서 차이가 있다. 자바 용어로 말하면, 멤버 변수인데 별로 마음에 안 든다. 여하튼, 그것을 이용한다.







얘는 어디에 쓸까? 안드로이드의 BR 서비스랑 비슷한 것을 만든다고 하자. 그럼 앱 규격을 내려주고 하위에서 구현해서 위로 올려주고 나는 목록만 가지고 있으면 알림이 왔을 때 리스트에 대고 for를 돌리면 그게 BroadCast 가 된다. 해당 앱.수행할 메소드() 를 적어주면 메시지 구조나 이벤트 드리븐 기능을 구현할 수 있다.





템플릿 메소드는



사실상 팩토리 매소드와 같다. new 를 하는 주체가 연결 클래스에 있으니 말이다. 템플릿은 interface를 하나 더 두어서 연결 클레스가 구현해야할 메소드의 명세를 명시화 한다는 개념이 추가 되어 사실상 더 큰 개념이다. 인터넷에 이론가들은 절대 동의하지 않는 것 같지만 뭔 프로그램을 만들었는지 알게 뭐람. 컴파일러 만들 때도 실무 경험 없는 이론가들이 만드는 개념은 무쓸.





빌더 패턴은



new 할 때 멤버변수를 미리 세팅하고자 하기 위해 만들었다. 그냥 생성자를 오버로딩 해서 쓰는게 LOC(Line Of Code)가 더 줄지 않느냐고 묻는다면 어느 정도 수준에서는 빌더 패턴이 더 낫다고 말하고 싶다. 그게 어느 수준이냐?



Chip c = Builder.setBrand("SAMSUNG").setPrice("개비쌈").build();



로 나갈 때 setPrice가 int면 모르겠는데 저렇게 String을 적는다면 setPirce만 오버로딩 하면 되는데 생성자의 경우 경우의 수가 더 많아진다.



그럼 저렇게 . 찍는 것은 어떻게 구현하냐?



this.brand = brand;



return this;



return 을 클래스 자체로 리턴하면 계속 . 을 찍을 수 있다. 이론 관점이 아니 코드 관점에서 먼저 보면 참 쉽다.





Strategy 패턴은



인터페이스를 나누는 기술이다.



라는 것만 알고 인터넷 서핑 공부법(실무프로그래밍 참고)으로 공부하면 된다.





Prototype 패턴은



interface, Abtract, class를 얼마나 예쁘게 만드는지에 대한 연구이다. 사실 팩토리 메소드 패턴인데 객체 생성 이름은 clone()으로 한 것 뿐. clone() 안에 super.clone() 이 있던 말던 최종 clone에는 static 혹은 new가 들어갈 수밖에 없다.







이 모든 패턴을 조합해서 만든 Creational 패턴이 바로





Abstract Factory Pattern이다.



Factory Method처럼 바로 하위에서 바로 객체를 생성해서 리턴해 주는 게 아니라 우선 Factory를 받아오고 해당 Factory를 이용해서 new(creation)를 한다. 이렇게 설계하는 과정 자체에 protytype과 stategy 패턴이 들어가고 팩토리에서 실제 객체를 생성하는 패턴은 Factory Method다. 해당 팩토리가 부르는 클래스 안에는 세팅 다 해서 자기 객체 리턴하는 하는데, 생성자가 복잡해진다 싶으면 빌더 패턴으로 구현하는 것이 편하다.





내가 패턴을 공부하게 되었던 것도 학창 시절 교수님께서 구입해 주셨던 GoF Design Pattern 때문인데. 사실 코드로 보다 보니 거기 써져있던 패턴 맵이 그 책의 정수라는 것을 알게 되었다.







권장하는 것은 아니지만 워낙 유명한 책은 인터넷에 항상 PDF로 있으니



gof design pattern filetype:pdf



으로 잘 찾으시고 책이 좋으면 꼭 원서를 구입하시기 바란다.





4. 결론



creational pattern 은 new를 어디서 할지 정하는 패턴.



즉,



new pattern 으로 불러야 한다. 너무 싼티나면







memory allocation pattern.





스타트업 이야기



혹은,



I can't trust you pattern. 사실 패턴이란 것은 협업 시 다른 사람에게 인터페이스, Abstract, Protocol, Specification Documents(스펙) 던져주고 전체 그림을 못 보게 만들려는 수작이다. 전체 소스는 주되 쉽게 접근할 핵심은 말 안하다는(언젠가는 분석된다면 시간이 필요하지) 나 혼자 성공하려면 넌 좀 모르게 할 필요가 있을 때 쓰니까 그런 정치에 맞서 사용자가 원하는 프로그램을 만들고 싶을 때, 패턴을 잘 배워두자.

'블로그 항해 일지 > Design Pattern' 카테고리의 다른 글

Creational Pattern 에 대한 썰  (0) 2019.01.22
refactoring.guru  (2) 2019.01.06

Comment +0


블로그 포스팅의 힘






전에 밝혔지만, 직장 생활하면서도 교육에 관심이 여러 활동을 하는데 특이한 것은 가끔 오는 과외 문의는 결국 인터넷 글을 보고 온다.






- 안녕하세요 현재 *지역 거주 중이고 제가 필요한 건 opengl 중에 간단하게 동작하는 것들을 구현하는 걸 배우고 싶습니다 * 페이는 과제 난이도 및 개수로 일단 회당 5~10만 원 정도로 생각중입니다 *


- 안녕하세요. 리눅스 커널을 공부하고 있는데 quick start를 위해 도움을 주실 분들 구하다가 글을 발견하고 메일 보내봅니다. *


- 안녕하세요. * 혹시 어셈블리어 기초과정 과외 가능하시면 연락 주십시오 시간은 되도록 그쪽 사정에 맞출 수 있습니다. *




공유 지식의 힘






대부분의 인터넷 글을 정리하고 카페 활동을 시작했었다. 사실 쓴 책에도 밝혔지만 "인터넷 서핑 공부법"이란 게 있어서 내가 썼던 글과 지식도 시간이 지나면 쓸모없는 것이 되고, 단순히 블로그 조회수만 올려주는 역할만 하는데 사람들에게 도움이 되진 않는다. 그래서 차라리 카페가 낫겠다 싶었다. 그렇게 카페를 하다 접었다가 최근 다시 시작했다. 내가 몰랐던 사실은 대부분의 사람들은 잘 된 카페에 모이고 활동을 한다는 것. 지인도 마찬가지. 결국 잘 안되더라도 재미를 느끼고 활동하는 사람과 함께 해야 유지시킬 수 있다는 것이다. 잘되고 나서는 얼마든지 사람을 모을 수가 있다. 그리고 퀄리티 있는 지식의 공유는 결국 사람을 모은다. 모여진 사람을 이끌며 줏대 있는 결심을 지속적으로 내비치면 주는 사람이 더 도움을 받는 커뮤니티가 된다.





프로그래머 Programmer : 네이버 카페


기술을 더욱 깊이 있게 하고픈 개발자 모임입니다.


cafe.naver.com 









Design Pattern


디자인 패턴의 실무적 접근방법은 이미 이전 포스팅에서 모두 말했다. Creational Pattern 뿐이지만 객체를 생성하는 new의 위치를 어디에 쓰느냐가 패턴의 종류를 결정했었다는 글은 내 책의 글귀인 "프로그래밍은 CPU와 MEMORY의 장난"이라는 말과 일맥상통한다.





C&JAVA Programming 실무 프로그래밍 초급편









GoF Design Pattern이 소프트웨어 영역에서는 시온이기에 사실 모든 디자인 패턴은 이 책에서 나왔다고 할 수 있다.





GoF의 디자인 패턴


이 책은 디자인 패턴을 다룬 이론서로 디자인 패턴의 기초적이고 전반적인 내용을 학습할 수 있다.


www.yes24.com 







그러나 내가 기존의 알던 내용을 제대로 정립하고, 배운 곳은 여기다.





The Catalog of Design Patterns



refactoring.guru 







아마 링크만 클릭하고 조금의 노력만 더해진다면 실무에서 쓰이는 코드들을 리팩터링 하면서 디자인 패턴을 제대로 배워 볼 수 있겠다. 내가 쓰는 중급 편의 지식도 대부분 여기서 파생되었다고 보면 되겠다. 그러나 내가 생각하는 것은 좀 더 Firmware 쪽 지식 base기에 디자인 패턴의 하부 단계를 생각할 수 있겠다. 조금 더 C에 가깝고, 리눅스 커널에 가깝다고 해야 할까?






지금까지 소개한 디자인 패턴은 사실상 모듈 디자인 패턴이다. 아키텍처 디자인 패턴은





10 Common Software Architectural Patterns in a nutshell


Ever wondered how large enterprise scale systems are designed? Before major software development starts, we have to choose a suitable…


towardsdatascience.com 







여기를 참고하여 인터넷 서핑으로 공부를 해야 하고, 그 상위의 시스템 디자인 패턴은 스스로가 갈고닦을 수밖에 없고, 나중에는 개인 경험 차이에 의해 다변화된다. 실무 프로그래밍 고급 편에 총정리를 할 생각이다. 그 사이 많은 시스템을 설계하고 만드는 수밖에 없다.






디자인 패턴 레이어가 햇갈리면 요구사항 분석 - 시스템 설계 - 아키텍처 설계 - 모듈 설계로 가는 V 모델을 보라.






지금도 많은 프로젝트를 하고 있지만 사실상 시스템 디자인 패턴은 아마존 클라우드로 귀결되고 있고, 그 비용을 낮추는 물리 시스템을 설계하는데 많은 시간을 쏟고 있다. 그게 내가 가질 차별점이라면 차별점일까...






따지고 보면 메이저 리그가 아닌 마이너리그에서의 비용 때문의 고민일 것 같지만, 자본주의 사회에서 똑같이 필요한 서비스를 제공한다고 했을 때 결국 승리하는 것은 적인 비용이라는 것은 누구나가 아는 사실.






단, 시간이 문제인데 "성공"이라는 것을 또 경험해보고 싶다면 그 시간을 어떻게 줄일지 고민해야 한다.






아직 1년 안된 신입 개발자가 폭풍 성장하는 것을 보면서, 결국 IT 기술 정립을 어떻게 해야 할지 몰라서 각자 목소리를 내고 있는 IT 기술을 학교로 돌려 보낼 수 있다고 자신한다. 






이미 많은 사람들이 노력하고 있기도 하고.

'블로그 항해 일지 > Design Pattern' 카테고리의 다른 글

Creational Pattern 에 대한 썰  (0) 2019.01.22
refactoring.guru  (2) 2019.01.06

Comment +2

var ie7 = 0;