지난 포스트에서 자바스크립트는 세상에서 가장 잘못 이해되고 있다고 언급했는데, 이 말은 자바스크립트의 구루 이자 JSON의 창시자인 Douglas Crokford 가 쓴 글의 제목입니다.  Crokford 는 그 글에 자바스크립트의 역사부터 왜 오명을 뒤집어 쓰게 됐는지, 제대로 사용하기 위해서는 어떻게 해야 하는지 서술하고 있습니다. 지식이 미천하니 저의 생각을 펼치는 경지에는 미치지 못하고 번역 포스트들이 늘어남을 어찌해야 할런지. ㅡㅡ;; 

컨퍼런스의 Douglas Crokford, "제대로 작성하라" 모든 언어에 통용 되면서, 특히 자바스크립트에서 강조되는 문장. 사진원본: http://www.flickr.com/photos/allenr/4482835614/sizes/l/in/photostream/




Javascript: 세상에서 제일 잘못 이해되고 있는 언어
http://javascript.crockford.com/javascript.html :번역

Douglas Crokford : www.crokford.com

Mocha, LiveScript, JScript, ECMAScript로 알려져 있는 Javascript는 세상에서 가장 유명한 언어중의 하나이다. 자바스크립트 인터프리터는 세상의 모든 퍼스널 컴퓨터에 설치되어 사용되고 있다. Javascript의 유명세는 WWW 스크립팅 언어의 막중한 책임을 맡고 있기 때문이다.

이런 유명세에도 불구하고, 오로지 몇몇만이 자바스크립트를 매우 좋은 동적 object-oriented 범용 목적의 프로그래밍 언어로 알고 있다.  이게 어떻게 비밀일 수 가 있는가? 왜 이 언어는 이렇게 오해를 받고 있을까?


이름 (The Name)
이름에 사용된 Java라는 접두사는 Javascript가 Java의 subset 또는 덜 호환적인 자바버전과 어떤 관계가 있어 보인다. 이 이름은 혼란을 유발 시키고, 이 혼란으로부터 오해가 발행하고 있다. Javascript는 Java의 인터프리티드 언어가 아니다. Java는 인터프리티드 언어다. 자바스크립트는 완전히 다른 언어다. 자바가 C와 유사한 만큼 Javascript는 자바와 문법적 유사성을 가지지만 Javascript는 Java의 subset이 아니라 C의 Subset이다.  Javascript는 Java가 원래 의도 했던것 보다 더 잘 동작한다.

Javascript는 자바의 고향인 Sun Microsystems가 개발 하지 않았다. javascripts는 Netscape에 의해서 개발 되었다. 원래는 LiveScript라 불리었는데 오히려 그 이름이 혼란을 불러 일으키지 않는다.


-Script subffix 는 실제 프로그래밍 언어가 인것 처럼 제안한다. 스크립팅 언어는 프로그래밍 언어보다 못하다 . 하지만 핵심이 되는 것은 특성화이다. C와 비교 해서 Javascript는 동적과 표현력을 위해서 성능을 양보한 것이다.


C의 옷을 입은 Lisp (Lisp in C's Clothing)

Javascript와 같은 C-like 문법은 중괄호와 for 문장을 가지고 있어서 일반적인 절차적 언어처럼 보이게한다. Javascript는 Lisp나 Scheme처럼 C나 Java보다 더 일반적인 Functional (함수적 언어) 언어이다. 리스트보다 배열을 가지고 있고, 속성 리스트 대신 오브젝트를 가지고 있다. 함수 하나만으로 클래스이며, 모든 균형이 맞추지 않고도 끼워 넣을 수 있다.


타입변환(Typecasting)
Javascript는 Netscape 네비게이터에서 동작되도록 고안되었다. 이것은 모든 웹브라우저에 성공적인 표준 장비가 되었다. 이건 형변환의 결과이다. Javascript는 프로그래밍 언어의 George Reves이다. Javascript는 웹과 관계가 없는 큰 클래스에도 잘 들어 맞는다.


움직이는 표적 (Moving Target)
첫번째 버전의 Javascript는 매우 빈약했다. 상속과 내부함수와 예외 처리에서 난파되어 버렸으나 현재에 와서 완벽하게 object-oriented 프로그래밍 언어가 되었다. 하지만 많은 경우에는 불완전한 형태에 기반하고 있다.

ECMA committee 는 Javascript의 확장을 개발하는 선의의 책무를 맡았지만 , 자바스크립트의 가장 큰 문제는 너무 많은 버젼이 존재하고 있다는 것이었고, 이것이 혼란을 만들어 내고 있다.


디자인상의 에러들(Design Errors)

완벽한 언어란 없다. Javascript도 디자인상의 에러들을 가지고 있다. + 연산자를 오버로딩 하는 것이 더하기와 연결 둘 다를 의미하는 것, with 문구로 부터 발생되는 에러는 무시 될 것이다. 예약어 정책은 너무 엄격하며, 세미콜론 삽입은 문자 정규 표현식과 마찬가지로 크나큰 실수 였다. 이 실수들은 프로그래밍 에러들을 유발하며, 언어 디자인의 전반적인 문제라고 일컬어 졌다. 다행스럽게도, 이런 많은 문제들은 좋은 교정 프로그램으로 인해서 해소 되었다.


언어디자인 문제는 조용해 졌다. 놀랍게도 ECMAScript committee는 이런 문제를 바로 잡는데 흥미를 보이지 않았으며, 아마도 새로운 것을 만드는 데 빠져 있을 것이다.


형편없는 구현들(Lousy Implementations)

몇몇의 초기에 Javascript로 구현된 것들은 버그 투성이다. 이것이 언어를 나쁘게 보이게 했다. 이것들로 조합된 구현들이 최악의 버그투성이 인채로 웹브라우저들에 삽입되었다.


나쁜책들(Bad Books)
많은 Javascript 책들은 지독하게 개판이다. 에러를 담고 있으며, 저질 예제, 저질 연습을 가르친다. 매우  빈번하게 중요한 요소들을 잘못 설명 하였으며, 방치하였다. 나는 수십권의 Javasript책들을 리뷰했으며, 내가 유일하게 추천하는 책은 JavaScript: The Definitive Guide (5th Edition) by David Flanagan 이다. (저자들에게 : 당신이 좋은 책을 쓴 것이 있다면, 리뷰할 수 있게 나에게 보내 달라)



스탠다드의 부분 스탠다드(Substandard Standard)
공식적인 언어 정의는 ECMA에서 공표되어 진다. 정의는 극강 최악의 품질을 보인다. 읽는 것도 이해하는 조차도 어렵다. 이 것은 나쁜 책 문제에 일조 했다, 저자들이 언어를 이해하도록 도움을 주지도 못했으며, 표준 문서로 사용할 수도 없었다. ECMA와 TC39 위원회는 깊이 반성해야 한다.


아마추어들(Amateurs)
프로그래머가 아닌 모든 사람들이 Javascript를 작성한다. 그들은 좋은 프로그램을 작성하는 훈련과 연습이 안된 사람들이다. Javascript는 그들이 사용할 수 있는 매우 많은 표현력을 가지고 있다. 어쨋든, 이 말은 아마추어들에게 해당 되는 것이지 프로페셔널 프로그래밍에 맞지 않는다.


Object-Oriented
JavaScrpt가 Object-Oriented 인가? 오브젝트는 행위와 관련된 특정 데이터와 메소드를 담을수 있다. 오브젝트는 다른 오브젝트를 담을수 있다. Javascript는 클래스들을 가지고 있지 않지만 클래스처럼 생성자를 가지고 있다. class-oriented 상속을 가지고 있지 않지만 원형 상속을 지원한다.  이 두가지 방법으로 오브젝트 시스템을 구축한다. 상속(is-a) , 집합(has-a) , Javascript는 둘다를 지원하지만, 태생적으로 집합을 더 잘 지원한다.


Javascript가 진정한 객체지향이 아니라는 몇 가지 논쟁은 정보은폐 Infroamtion hiding 를 못 한다는데서 비롯된다.  그 말은 private 값과 , private 메소드가 없다는 말이다. : Javascript의 모든 멤버는 public 이다.


하지만 Javascript는 private values와 private 메소드를 가질 수 있는 것으로 밝혀졌다(http://www.crockford.com/javascript/private.html). 물론  Javascript가 세상에서 가장 잘못 이해되고 있는 언어이기 때문에 소수만이 이 사실을 이해하고 있다.

Javascript가 진정한 객체지향이 아니라는 몇 가지 논쟁은 상속을 지원하지 않는다는 것도 포함된다. Javascripts는 고전적인 상속을 지원하지는 못하지만 코드 재사용 패턴은 잘 지원하고 있다(http://javascript.crockford.com/inheritance.html).

### 끝.


Douglas Crockford : The Javascript
http://video.yahoo.com/watch/111593


저작자 표시
신고

이 글을 Twitter / Facebook 에 공유하기
이 글이 유익하다면 아래의 트위터 버튼을 눌러 공유해 주시거나, 페이스북 "좋아요" 버튼을 눌러 주세요.

   


Posted by 반더빌트
세상에서 가장 잘 못 이해 되고 있는 언어라는 것이 있습니다. 바로 자바스크립트 javascript 라는 놈이랍니다. 방문자의 주의를 끌기 위해 깜빡이는 글자, 흘러가는 글자, 마우스를 올렸을 때 사진을 바꿔주는 기능, 소스 보기를 못하게 마우스 오른쪽 클릭을 막는 일, 약간은 불법적인 용도로 다른 페이지로 납치하는 일 등등.

정적이었던 HTML 페이지에 생동감을 불어 넣어 주었던, 어쩌면 귀여운, 어쩌면 조잡한 일을 담당했던 언어가 바로 자바스크립트 라는 놈이었다라고 기억 하실 겁니다. 

다른 사이트의 괜찮은 기능을 소스보기를 통해 복사해 붙여넣어 사용함으로써 근본없이 꼬여버리는 언어라고 인식되어 졌고, 점점 사양길로 접어 드는 듯했습니다. 자바스크립트를 살리는 역사적인 일이 벌어졌으니, Fat 클라이언트, UX, Ajax를 이용한 부분 업데이트 개념들의 부상(결정적으로 구글맵스와 야후의 YUI )과, 더 이상은 스파게티라고 부르지 말아줘라며 자바스크립트 프레임워크 Prototype Framework, jQuery Framework 라는 것의 등장이었습니다.


웹개발자들은 자바스크립트를 다시 보기 시작했고, 제대로 공부할 필요가 생겼습니다. 뭘 공부해야 할 까요. 언어의 스펙은 당연 기본일 것 입니다. 또 알아야 할 것이 있다면 자바 스크립트가 프로토타입-베이스드 언어 Prototype-Based Language 라는  약간은 생소한 언어 라는 것 입니다. 
 
그래서 모질라 개발자 센터의 Core JavaScript 1.5 Guide: class-Based vs. Prototype-Based Language 라는 문서를 번역 합니다.


class-Based vs. Prototype-Based Language




Core JavaScript 1.5 Guide: class-Based vs. Prototype-Based Language

클래스-베이스 vs 원형 베이스 언어
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Class-Based_vs._Prototype-Based_Languages 

원본 : 모질라 개발 센터 : 번역

Core JavaScript 1.5 Guide: class-Based vs. Prototype-Based Language

Contents

1. class-Based vs. Prototype-Based Languages
 1.1 Defining a Class
 1.2 Subclasses and Inheritance
 1.3 Adding and Removing Properties
 1.4 Summary of Differences

class-Based vs. Prototype-Based Languages
(클래스 기반 vs 원형 기반 언어)

Java와 C++와 같은 Class-Based object-oriented language는  Classe 와 Instance로 대표되는 두개 구별되는 개념에 가진다.

-Class는 그를 성격화 하는 object의 집합으로 속성을 정의한다.(Java에서의 method 와 field 또는 C++에서 Property가 되는 멤버). 

하나의 Class는  object 집합의 특정 멤버를 묘사하기보다는 사물을 추상화한다.
예를 들어,  Employee class는 모든 Employee의 집합을 표현 할 수 있다.


-Instance ( 다른말로 class의 실체화) 는 그 멤버들중 하나이다. 예를 들어 Victoria는 Employee로 특정 개개인을 표현하는 Employee클래스의 하나의 Instance가 될수 있다.
 하나의 인스턴스는 정확하게 그 부모의 속성을 가진다(더 많지도, 더 적지도 않게)


Javascript와 같은 Prototype-Based language는 이 구별을 가지지 않는다. 단순하게 object를 가진다. Prototype-Based language는 Object의 원형이란 개념을 가진다. Object는 새로운 Object의 속성들을 초기화하기 위한 템플릿으로서 사용된다.
모든  Object는 생성시 와 Runtime 시를 막론하고 Object의 모든 속성들을  지정할 수 있다.  덧붙여, 모든 object는 첫번째 Object의 속성들을 공유하는 두번째 Object를 허용하는 또다른 object를 위한 원형으로 구성될수 있다.



클래스 정의하기 Defining a Class

Class-Based language에서는 분리된 Class 정의로 정의한다. Class 정의에서 여러분은 클래스의 인스턴스를 만드는 Constructor라고 하는 생성자를 호출하는 특정한 메소드를 지정할 수 있다. 생성자 메소드는 생성시에 특정한 값을 초기화하고 적절한 작업을 수행할 수 있다. 여러분은 생성자로 구성된 클래스를 인스턴스화하기 위해 new 연산자를 사용할 수 있다.

Javascript도 비슷한 모델을 따른다, 하지만 클래스 정의로부터 분리된 생성자를 가지지는 않는다. 대신 여러분은 특정한 값과 속성으로 초기화된 오브젝트를 생성할 수 있는 생성자 함수를 정의할 수 있다. 어떤 Javascript 함수도 생성자가 될 수 있다. 새로운 오브젝트를 생성하기 위해 생성자를 이용한 new 연산자를 사용할 수 있다.

하위클래스와 상속 Subclasses and Inheritance
class-based language에서 클래스 정의를 통하여 클래스의 구조를 만들 수 있다. 클래스 정의에서 , 당신은 새로운 클래스가 이미 존재하는 클래스의 하위 클래스로 정의할 수 있다. subclass는 superclass의 모든 속성을 상속 받는다. 덧붙여 새로운 속성과 상속받은 속성을 수정할수 잇다. 예를 들어 Employee 클래스가 name과 dept라는 property를 가지고 있다고 가정하자. 이런 경우에 Manager 클래스의 Instance는 세개의 속성들을 가질 것이다. name, dept, and reports

Javascript는 생성자 함수의 원형 구성으로 상속을 구현한다. 그래서 , 여러분은 정확히 Employee-Manager 예제를 생성할 수 있다. 하지만 약간 다른 서술법을 사용한다. 첫째로 Employee 생성자 함수를  정의한다. name과 dept의 속성을 지정한다. 다음으로 Manager 생성자 함수를 정의한다. reports 속성을 지정한다. 마지막으로 새로운 Employee 오브젝트를 Manager 생성자 함수의 원형으로써 대입한다.



프라퍼티 추가 제거하기 Adding and Removing Properties

class-based languages에서 전형적으로 컴파일 타임에 클래스를 생성하고, 컴파일 타임 또는 실행 타임에 인스턴스화 한다. 일단 클래스를 정의한 후에는 멤버나 속성의 타입을 변경할 수 없다. 그러나 Javascript에서는 실행 시간에 객체의  속성을 추가하거나 삭제할 수 있다.  이미 사용되고 있는 오브젝트에 원형으로써 property를 추가한다면 , 그 object의 원형 역시 새로운 property를 가질 것이다.

Summary of Differences

Class-based (Java)

Prototype-based (JavaScript)

Class and instance 구별되는 속성이다.

모든 objects instance 이다.

클래스를 정의하는 것은 클래스 정의와 클래스를 정의하는 생성자 메소드의 정의이다.

정의한.생성자 함수로 오브젝트를 생성한다.

new연산자를 이용하여 오브젝트를 생성한다.

Same.

이미 존재하는 클래스를 이용하여 클래스의 계층구조를 구축한다.

생성자 함수로 구성되어 있는 함수의 원형을 대입함으로써 계층구조를 구축한다.

클래스 연쇄를 따라서 속성을 상속 받는다.

원형의 연쇄에 따라서 속성을 상속 받는다.

클래스 정의는 모든 인스턴스의 속성을 지정하며. 실행타임에 동적으로 추가 없다.

생성자 함수 또는 원형은 속성을 지정할 있다. 모든 오브젝트의 집합 또는 개개의 오브젝트는 실행 타임에 동적으로 프라퍼티를 추가 또는 삭제 있다.


### 끝.

[이 포스트는 새로운 블로그 운영으로, 이전 블로그 http://smack.kr/174 
Core JavaScript 1.5 Guide: class-Based vs. Prototype-Based Language, 2008년 3월 4일 포스트,
의 글을 수정하여 다시 포스트 한 것입니다.]

Prototype-Based 에 대한 더 읽을 자료.

저작자 표시
신고

이 글을 Twitter / Facebook 에 공유하기
이 글이 유익하다면 아래의 트위터 버튼을 눌러 공유해 주시거나, 페이스북 "좋아요" 버튼을 눌러 주세요.

   


Posted by 반더빌트
구름 사이로 비추는 햇볕에 이따금씩 반짝이는 사금파리 처럼 수년동안 머릿속에 남아있는 구절이 있다면, 개발자로 밥을 먹고 있으면서 수년동안 읽은 개발서 중에 머리가 아닌 가슴을 에이게 하는 책이 있다면 그중 하나가 바로 이책입니다. 개발서 치고는 얊은 데다가 타이포그래피가 구닥다리 냄새를 풍기고 있기는 하죠. [버그 안녕] 이라는 부제는 텔레토비를 연상케 하는군요. 원서로는 93년도에 나왔으며, 번역으로는 2001년에 출판된 책을 온라인 서점에서 지금도 구매할 수 있습니다.




Writing Solid Code.(부제: 버그 안녕) STEVE MAGUIRE 저, 나윤석. 이을재 공역, 높이깊이 ISBN 89-7588-020-6

많은 좋은 내용이 있지만 그중 머릿속에 멤도는 몇가지는 아래와 같습니다.

에러를 리턴하는 함수는 사용하지 말라 - 만일 어떤 함수가 에러값을 리턴한다면, 그 함수를 호출한 모든 곳에서 에러를 처리해야 한다. 
p.168

C 언어를 처음 배울때 실패시에는 -1 또는 0을 성공시에는 1을 리턴하라는 가르침은 그 후에 어떤 언어를 배우더라도 성공, 실패를 값으로 리턴하려는 습관이 생겨 버립니다. 이 습관은 exception을 이해해고 적절하게 사용하는데 가장 걸림돌이 된다고 생각하며, C#이나 자바와 같은 고급언어를 공부한 후, C 나 C++ 언어를 공부하는 것이 더 좋다 라고 생각하는 이유 중 하나 입니다. 에러값을 리턴하는 함수를 사용하지 말자는 철학은 고급언어에 exception 메커니즘이 적용된 이유입니다.

보충 설명 : 고급언어에서의 exception 메커니즘

Unix와 C에 기초한 시스템들은 전통적으로 루틴의 성공 또는 실패를 나타내는 리턴 코드를 사용한다.
자바는 예외(exception)라는 더 좋은 수단을 가지고 있다. 예외는 일반적인 처리 과정과 예외 처리 과정을 명확하게 분리하기 때문에 더 좋다. 이는 프로그램을 이해하기 쉽게 만든다. 프로그램을 쉽게 이해할 수 있도록 작성하는 것이 매우 중요하다는 사실을 이제는 믿어 주기 바란다.

리팩토링, 마틴 파울러 지음/윤성준,조재박 옮김, 대청, p.358




효율성과 이상적인 설계 사이

프로그래머들 가운데에는, 아무리 사소하 것이라도 효율을 향상시킬 수 있는 부분을 포기하는 것을 마치 죄악처럼 여기는 사람들도 있다. 가장 이상적인 것은 효율을 약간 희생하더 라도 안전한 설계와 구현 방법을 선택하여 위험을 줄이는 것이다. 
p.214

개발조직에서 논쟁을 하다 보면 효율성을 위해서 이상적인 설계와 구현 방법, 도구를 포기하자는 목소리가 클때가 많습니다. 효율과 이상적인 설계중 선택하라면, 저는 이상적인 설계를 선택합니다. 효율성 자체로서 크리티컬한 도메인 이라면 그 의견에 동의 하겠지만, 그러한 경우는 극히 드뭅니다. 효율을 약간 희생하더라도 안전한 설계와 구현 방법을 선택하는 것이 대부분의 경우에 적합하다 라는 것은 매우 동의하는 구절중의 하나 입니다.


페인트 젓는 막대

페인트 젓는 막대, 잘 저어질수 있도록 넓으며, 일회성이란 성격으로 버릴 수 있는 소재로 되어 있다.


페인트 젓는 막대

페인트 깡통의 뚜껑을 열고 페인트를 휘젓는 데에 드라이버를 사용하는 것은, 아주 오래 전부터 집집마다 통상적으로 써 오던 방법이다. 나도 그 방법을 즐겨 사용했었다. 그 결과, 우리 집에는 여러 색의 페인트로 겹겹이 덮인 드라이버거 여러 개 있다. 사람들은 그래서는 안된다는 것을 알면서도, 왜 드라이버로 페인트를 젓는 것일까? 이유는 자명하다. 그 당시에는 드라이버가 편리하게 생각되었고, 실제로 페인트도 잘 저어졌기 때문이다. 페인트 젓는 막대가 된 드라이버 처럼, 편리하게 사용할 수도 있고 프로그램도 제대로 작동하지만 원래의 목적에서는 벗어나는 방법들이 코딩 과정에도 많이 사용된다.  ~ 이 기준은, 마치 법률을 피하면서 세금을 적게 내는 방법을 가르쳐 주는 납세 지침서와 마찬가지이기 때문이다. 납세 지침서는 모두, 의도의 불순성을 무시하고 목적의 달성만을 추구하고 있는 것이다. 앞 페이지 예의 진짜 문제점은 코드에 있는 것이 아니라, 프로그래머의 자세에 있다. 수치적 연산을 위하여 논리적 연산을 사용하고도 마음이 편한 프로그래머라면, 다음엔 어떤 기상천외한 방법을 동원할까? 그 방법들을 어떻게 믿을 수 있을까?
p.252,253

페인트까지 저을 수 있는 드라이버를 개발에서는 재사용이 가능하며 유연하며 활용도가 높은 객체라고 생각하기 쉬울수 있습니다. 엄밀히 말하자면 원래의 용도가 아닌 객체를 동작한다는 이유로 다른 용도로 사용하게 되는 것이죠. 

때로는 실용적이라는 변명으로 목적이 수단을 합리화하는 일은 우리의 일상 뿐만이 아니라 개발에서도 발생합니다. 어떤 때는 적절한 행동처럼 보이기도 하구요. 거기에 동조하기도 하고, 눈을 살짝 감기도 합니다.  결과가 좋았더라도 가슴한 구석이 편치 않았던 때가 많았었죠. 살면서 그렇게 행했던 때, 개발하면서 그런 선택을 했을때, 페인트 통을 또한 번 드라이버로 저었다라는 생각을 합니다. 그러한 선택이 많아 질 수록 그 회사, 조직, 서비스, 나 자신이 어떠한 모습으로 변해갈지. 그러한 방법들을 어떻게 신뢰할 수 있을지.



증상만 치료하지 말고, 원인을 제거하라.

앤토니 로빈스(Anthony Robbins)는 그의 책 [내 안의 거인을 일깨우자]에서 어떤 의사의 이야기를 하고 있다. 한 의사가 물살이 빠른 강의 제방에 서 있다가, 물에 떠내려가며 살려 달라고 외치는 비명소리를 들었다. 자기 이외에는 도와줄 사람이 없다는 것을 안 그 의사는, 주저하지 않고 물 속으로 뛰어들었다. 물에 빠진 사람을 강가로 끌어 낸 뒤, 의사는 인공호흡으로 그를 소생시키려 했다. 그런데 그가 소생되기도 전에, 강에서 두사람의 비명 소리가 또 들려왔다. 의사가 두 사람을 구조하여 소생시키기 무섭게, 강에서는 또다시 네 사람의 비명 소리가 들려 왔다. 어어서, 여덟명의 비명이 들려 왔다... 안타깝게도, 이 의사는 사람들을 구조하기에 너무 바쁜 나머지, 상류로 올라가서 도대체 누가 사람을 물에 빠뜨리는가 찾아 볼 시간이 없었다.
p.273

증상만 치료하다가 정작 중요한 일을 하지 못하는 조직, 서비스. 자신의 조직이 아니라고 말 할 수 있는 개발자가 몇이나 될까요? 시간이 소요되더라도 원인을 제거해야 진짜 중요한 일을 할 수  있으며, 개발자도 발전 할 수 있습니다. 



융통성이 크다는 것

융통성이 크다 는 것이  '사용하기 쉽다'는 뜻이 아니다. 함수나 기능을 설계할 때는, 사용상의 용이성에 초점을 맞추어라. 함수나 기능이 융통성이 크다면, 아무리 애를 써도 그것들을 사용하기 쉽게 만들기는 어려울 것이다. 그 대신, 버그 찾기만 더욱 어렵게 만들 것이다. 
p.299

커다란 유혹입니다."지금 필요하진 않지만 나중에 필요할 지 모르니 그걸 붙일수 있게 개발해! 그렇게 하면 나중에 붙이기만 하면 되잖아!" 내가 개발하는 프로그램이 융통성이 있게 하자. 이 유혹과 소프트웨어를 단순 레고블록으로 취급하는 마인드는 오버 엔지니어링을 유발하고, 유연하기는 하지만 용이성을 잃어 버리기 쉽습니다. 그리고 버그의 온상이 되기 쉽죠. 이 균형을 맞추는 일은 성장이냐 분배냐의 질문에 대답하는 것 만큼이나 어렵습니다. 이럴 때마다 머리속으로 생각하는 답이 있습니다. 

 YAGNI  You ain't gonna need it! KISS Keep it simple, stupid! 단순하게 해 멍청아!

저작자 표시
신고

이 글을 Twitter / Facebook 에 공유하기
이 글이 유익하다면 아래의 트위터 버튼을 눌러 공유해 주시거나, 페이스북 "좋아요" 버튼을 눌러 주세요.

   


Posted by 반더빌트
존 아킹, 스콧 밀렛의 Professional Enterprise.NET 이  웹지니 장현희님의 번역으로 제이펍에서 출간되었습니다.  엔터프라이즈에 대한 개념이 척박한 닷넷 커뮤니티와 국내 환경에 또하나의 귀중한 책이 번역되 더욱 편하게 공부할 수 있게 되서 매우 반가운 소식입니다. 엔터프라이즈 시스템이 익숙한 분들도 있고, 아닌 분들도 계실 겁니다. 아마도 낮선 분들이 더 많을 것으로 생각됩니다. 이 책은 책의 목차만으로도 내용을 추측 할 수 있을 정도로 매우 직관적으로 저술 되었으며, 엔터프라이즈에 대한 기반 지식을 조금 알고 있다면 술술 읽혀질 정도록 매끄럽게 번역 되었습니다.


엔터프라이즈 닷넷 표지, 출처 웹지니님 블로그 http://www.mvpmagazine.net/40




원서를 펼쳤을 때 공 저자인 아킹이 엔터프라이즈를 알았을 때 느꼈다는 감정에 너무 동감 했기 때문에 읽지 않을 수 없었던 책이며, 번역서를 발견 했을 때 매우 기쁜 책입니다. 엔터프라이즈의 개념을 접하는 분들은 아마 공통적으로 느낄 감정이라고 생각됩니다.

"아킹 씨, 귀하의 경험과 능력은 출중하지만 이력서로 미루어 볼 때 귀하는 엔터프라이즈 분야의 경험이 전무하군요, 아쉽지만 다음에는 함께 일할 수 있는 인연이 있기를 바랍니다"

...

감독관이 말했던 '엔터프라이즈 패턴'에 대해 알아보기 시작했다. 그러나 인터넷에서 엔터프라이즈 아키텍처에 대해 검색했을때, 지난 8년간 내가 해왔던 컴퓨터 프로그래밍을 무용지물로 만드는 완전히 새로운 수준의 소프트웨어 디자인을 발견하고는 머리가 멍해지는 느낌이었다. - 프로페셔널 엔터프라이즈닷넷 - Professional Enterprise.NET, p.3

업계에서 '엔터프라이즈' 라는 용어는 '기업용' 이라는 한정적인 의미로 받아들이는 경향이 있습니다. 이런 생각은 자신의 영역이 기업용의 복잡한 비즈니스를 처리하는 서비스가 아니니 엔터프라이즈 아키텍처는 나와는 관계가 없어 라고 무시 또는 회피하는 경우가 발생합니다. 저는 엔터프라이즈에 대한 저자의 아래의 정의에 동의 합니다.

엔터프라이즈 아키텍처란 무엇인가?

엔터프라이즈 아키텍처 Enterprise architecture 란 주로 조직의 요구를 효과적이고 효율적으로 지원하기 위한 비즈니스 프로세스, 정보의 흐름, 시스템, 애플리케이션, 데이터 그리고 인프라스트럭처 등을 묘사하는 광범위한 프레임워크를 설명하기 위해 사용된다. 

....

개발자의 관점에서 엔터프라이즈 아키텍처란 어떤 의미를 가질까? 엔터프라이즈 아키텍처를 정의한다는 것은 프로세스, 프레임워크, 디자인, 개발 및 배포를 위한 일련의 패턴을 정의하고, 회사나 부서에서 필요로 하는 소프트웨어의 모든 것을 관리한다는 것을 말한다. 이 문장에서 가장 중요한 구문은 소프트웨어의 모든 것 all of software이다. 즉, 엔터프라이즈 아키텍처란 모든 단계의 디자인에서 소프트웨어가 필요로 하는 모든 요소들을 생성하기 위한 통합된 개발 플랫폼이다. -  p.5, p.6


이 책은 에릭 에반스의 도메인-드리븐 디자인 DDD 와 마틴 파울러의 패턴 오브 엔터프라이즈 어플리케이션 아키텍처 PoEAA 에서 제안된 개념들을 닷넷에서 어떻게 적용될 수 있는지, Structuremap, NHibernate 등의 프레임워크가 구현한 개념이 무엇이며 그 적용되는 방법은 무엇인지에 대해 다루고 있습니다. 실제 자신의 프로젝트에 이런 프레임워크를 적용해 보지 않더라도 작동방법을 알 수 있고, 엔터프라이즈의 다양한 주제에 대한 인덱스를 한권의 책을 통하여 제공받을 수 있다는 것은 개발자들에게 매우 행운이 아닐 수 없습니다.

이 책의 좋은 점중 하나는 개념의 도입부에 그 개념이 도출된 히스토리를 담고 있는 것입니다. 이런 내용은 오랜 경험과 같은 것인데 책보다는 사수로 부터 일대일로 전해지는 내용이어서 도자기를 만드는 기술이 그러하듯이 단절되기 쉬운 것이죠.

책 한권을 읽는다고 해서 엔터프라이즈 아키텍처의 모든 것을 알 수 있다고 기대하는 건 아니겠죠? 저자는 서문에서 아래와 같이 밝히고 있습니다.

만일 여러분이 개발에 매우 능하며 블로그와 포럼에 많은 시간을 할애하는 오픈 소스 전문가라면 지금 당장 이 책을 내려놓기 바란다. 이 책은 엔터프라이즈의 모든 것을 다루는 완벽한 참고서가 아니다. 이 책은 테스트 우선 방법론을 강요하지 않는다. 또한 애자일 선언문을 내세우지도 않으며 엔터프라이즈 전문가에게 어필하는 책도 아니다. - 저자 서문 중에서


이 책은 엔터프라이즈 아키텍처의 많은 필수 개념과 최신의 프레임워크들을 소개한다 라는 관점에서 매우 가치있는 책이라 생각됩니다. 포스트의 제목이 적용하기 안내서 인 것은 바로 이 때문입니다.


관련링크
알라딘 책 사러가기 - 가격비교에서 강컴이 2~3천원 더 싸다. 책은 예스24에서 샀다.  <-- 이런 난 뭐니~~~


### 끝.



저작자 표시
신고

이 글을 Twitter / Facebook 에 공유하기
이 글이 유익하다면 아래의 트위터 버튼을 눌러 공유해 주시거나, 페이스북 "좋아요" 버튼을 눌러 주세요.

   


Posted by 반더빌트
성숙한 개발팀에서 어플리케이션 또는 서비스 개발함에 있어 종종 프레임워크를 만든 다는 말이 거론됩니다. 이는 아직 개념이 잡히지 않은 개발자들을 혼란스럽게 만드는 말이 될 수가 있습니다. 범위에 대한 정의가 생략되어 말해지기 때문이죠. 프레임워크를 개발한다는 것은  매우 넖으면서도 깊은 지식과 경험을 필요로 하며, 닷넷프레임워크와 같은 '기반 프레임워크'를 만드는 일은 엄청난 인원, 자원, 시간이 소요되는 작업입니다. 인-하우스 개발팀이 프레임워크를 개발해 사용한다는 말은 닷넷프레임워크와 같은 '기반 프레임워크'가 아닌, 어플리케이션 프레임워크를 말하는 것입니다. 이 포스트는 어플리케이션 프레임워크란 무엇이며 개발기법에 대한 것입니다. 포스팅의 그림과 내용은 Developing Application Framework in .NET by Xin  Chen (ISBN:1590592883) , Apress , 2004  일부 내용 요약 및 정리입니다.

“당신이 애플파이를 맨 처음부터 만들고자 한다면, 세상을 먼저 만들어야 할 것이다.  If you want to make an apple pie from scratch, you must first create the universe.”
—칼 세이건, Carl Sagan

어플리케이션 프레임워크란?

어플리케이션 프레임워크란 이 어떠한 문제를 해결하는 어플리케이션을 개발할 때  '어떻게 하면 맨손으로 개발 하지 않을 수 있을까?' 의 고민으로 부터 시작된 것입니다. 맨손으로 시작하지 않기 위해서는 구조화된 '그 무엇'을 개발자에게 제공해야 하며, 그 '무엇' 이 바로 '어플리케이션 프레임워크 이다' 라고 Xin Chen이 제안한 용어(selling idea) 입니다. 닷넷, 자바 개발자들은 닷넷프레임워크 와 자바프레임워크 위에서 개발을 합니다. 각각의 문제를 해결하기 위한 코드의 덩어리, 공통문제 해결을 지원하는 라이브러리등을 개발하게 되죠. 어플리케이션을 개발 할 때마다 데이터베이스로부터 화면표시까지 모든 개개의코드 덩어리를 만들고 있다면 여러분은 맨손으로 세상을 만들고 있는 중 입니다. 

인-하우스 개발팀이 프레임워크라 불리우는 것을 만들고 있다면 닷넷프레임워크 또는 자바프레임워크 위의 계층에서 돌아가는 '어플리케이션 프레임워크'라는 것을 개발한다는 뜻 이며, 삼성 SDS 의 애니프레임(Anyframe), SK C&C의 NEXTCORE 등이 어플리케이션 프레임워크라 할 수 있습니다.


어플리케이션 프레임워크 왜 사용하는가?

우리가 개발을 할때 마다 거의 같은 일을 하는 코드들을 개발자 개개인이 나름의 스타일로 만드는 일이 대부분 입니다. 매번 같은 일을 맨손으로 만드는 일이 허다하고, 같은 문제를 해결함에도 모두 다른 스타일로 만들어 진 것은 '개발' 과 '관리'의 악몽을 수반합니다.

어플리케이션 프레임워크는 일관된 개발을 지원하고, 경계설정을 강제함으로써 모듈성 Modularity, 재사용성 Reusability, 확장성 Extensibility, 단순성 Simplicity, 유지관리성 Maintainability 의 이익을 얻게 됩니다.


프레임워크 레이어 계층 구조


어플리케이션 프레임워크 레이어, 전체 시스템에서의 각각 프레임워크의 책임. 하위레이어로 갈수록 특정 비즈니스와 커플링이 느슨해 짐



비즈니스 어플리케이션

비즈니스 영역의(Business-Domain) 의 문제를 해결하는 어플리케이션.


어플리케이션 프레임워크

어플리케이션 프레임워크는 Domain-Specific Framework 와 Cross-Domain Framework Layer로 구분됩니다.

Domain-Specific Framework Layer

문제영역에 특화된 작업을 지원하는 프레임워크. 비즈니스 어플리케이션과 하부 레이어가 완전히 분리 된다면 개발과 유지관리에서 레고블록 처럼 결합하고 교체할 수 있겠지만, 이것은 이상(ideal)일 뿐 문제를 해결하기 위해서는 연관이 필연적으로 발생합니다. Domain-Specific 프레임워크는 비즈니스 어플리케이션 문제영역에 특화된 일을 처리하기 위한 프레임워크 입니다.

Cross-Domain Framework Layer

문제영역과 상관없이 모든 문제 영역에서의 공통 문제 해결을 지원하는 프레임워크를 의미합니다. MVC 프레임워크, Entity Framework, Spring 프레임워크 등의 문제영역과 상관없이 여러 비즈니스 도메인 공통주제를 지원하는 프레임워크 레이어 입니다.


프레임워크 개발 기법


Common spots - 모든 비즈니스 어플리이션에서 반복적으론 나타나는 공통 주제로써, 어플리케이션에 따라 변경할 필요 없이 인스턴스화 해서 사용할 수 있는 지점.

Hot spots - 개별 비즈니스 어플리케이션에 따라서 커스터마이즈 되어야 작동하는 지점.

상속을 통한 접근법 Inheritance Approach
공통된 문제를 해결하지만 어플리케이션에 특화되어 처리되어야 하는 Hot Spot 지원하기 위한 접근법으로는 상속 Inheritance 이 있으며, 상속은 override 를 이용한 hook method 방법과  해결방법의 형태를 잡아 놓는 Template Method 방법이 있습니다.

조합을 통한 접근법 Composition Approach
Hot Spot 문제를 해결하는 간단한 접근법이 상속 접근법이지만 이는 부모의 상세 detail 을 너무 많이 알게 된다는 잠재적인 문제를 가지고 있습니다. 조합을 통한 접근법은 Pluggable components 기법을 사용하며 Interface 의 구현으로 Hot Spot을 작동하게 만드는 방법입니다.


White-box framework
추상클래스 abstract 들로 구성된 프레임워크로 상속 접근법으로 Hot Spots을 작동하도록 하는 구조를 가지는 프레임워크 입니다. 옷으로 치자면 맞춤복.


Black-box frameworks
옷으로 치자면 기성복 Ready-Made, Ready-To-Use, 바로 사용 할 수 있는 클래스와 서비스들로 구성된 프레임워크입니다. Composition 접근법으로 Hot Spots 을 지원합니다.

Gray-box frameworks
옷으로 치면 반-기성복 Measure-To-Made,  White-box 와 Black-box가 결합된 형태로 상속 접근법과 조합 접근법 모두를 지원하는 프레임워크.


White, Black, Gray의 세가지 접근법은 성능, 유지관리성, 재사용성 에서 트레이드-오프 (동시에 성취 될수 없는 배타적인) 특성이 있음을 유념해야 합니다.

파운데이션 프레임워크

닷넷프레임워크와 같은 기반 프레임워크 입니다.

운영체제

파운데이션 프레임워크를 호스팅 하는 운영 시스템 입니다.

결론

일선 웹서비스와 소프트웨어 개발 회사의 프레임워크 팀은 바로 '어플리케이션 프레임워크'를 작업하는 팀을 말하며 ,유지관리 될 수 있는 소프트웨어와 서비스를 만들고 싶다면, 단순 공용 라이브러리가 아닌 어플리케이션 프레임워크를 구축하는 것을 심각하게 고려해 봐야 합니다. 


### 끝.

참고자료 :

Developing Application Framework in .NET by Xin Chen (ISBN:1590592883) , Apress , 2004
저작자 표시
신고

이 글을 Twitter / Facebook 에 공유하기
이 글이 유익하다면 아래의 트위터 버튼을 눌러 공유해 주시거나, 페이스북 "좋아요" 버튼을 눌러 주세요.

   


Posted by 반더빌트

부유한 노예 The Future of Success - 로버트 라이시, 2000 년에 출판된 책으로 성장은 고사하고 생존 자체가 가장 중요하게 되어 버린 현재의 경제시스템을 말합니다.


미국 전 노동부 장관이었던 로버트 라이시의 이 책은 [신경제]로 일컬어지는 지금의 경제체제의 특성을 직시하는 내용을 담고 있습니다.


 

공급자가 시장을 장악하던 시대
80년대의 헤게모니는 '시장만능주의', '시장자유주의' 였으며, 상품공급자들은 호황을 누렸고, 이론적 기반은 '아담 스미스'의 '국부론'이었죠. 저는 스미스의  '보이지 않는 손'은 공급자와 수요자가 공정하게 경쟁한다고 가정할 수 있는 '이상계(ideal system)'에서 작동할 수 있는 이론일 뿐 현실세계에 작동할 수 없는 이론이라 생각합니다. 스미스의 이론은 수요/공급이 최적의 균형점을 만든다고 말하지만, 실세계는 경제주체의 힘에 의해 균형점이 만들어지죠. 시장만능주의가 장악한 때는 1920년대 후버 대통령때, 1980년대 아버지 부시와 최근의 아들 부시에서 되풀이되죠.

 공급자가 최대 이윤을 얻을 수 있는 방법은 경제주체들 중에서 힘을 가장 많이 가지는 것이고, 힘을 만드는 방법은 시장독점, 담합, 정보통제가 있죠. 시장 만능주의는 독점과 담합 조차도 자연스러운 현상으로 치부해 버리는 속성을 가져서 결국에는 불균형의 장기화로 시장자체가 붕괴. 고난의 행군이 시작됩니다.

지금은 수요자의 힘이 커진 시대
[신경제]란 90년대 정보혁명에 의한 생산혁신이 일어나고, 생산비용 절감과 생산효율을 가져오게 되었습니다. 여기 까지는 공급자에게 유리한데, 현실은 공급자에게만 유리하게 된게 아니었죠. 정보혁명은 수요자들의 정보접근 능력을 향상시켰고, 생산혁신은 공급과잉을 불러왔으며 결과적으로 힘의 균형점이 수요자에게 이동된 상태. 바로 그것을 의미합니다.

라이시의 부유한 노예는 이런 [신경제] 하에서 경제주체들의 의미있는 행동에 대한 관찰이라고 볼수 있습니다.


이 블로그는 소프트웨어 개발에 관련된 것이므로 [신경제]가 개발과 어떻게 접목되느냐가 포스트의 관심사 입니다.


다품목 소량생산의 강제 및 정보과잉
가격 비교 웹사이트와 상품에 대한 정보 찾기가 쉬워짐에 따라서, 구매자가 거의 모든 것을 결정하는 구매자 천국이 신경제의 특징입니다.  이전의 체제인 공급자 주도의 경제는 소량 모델의 대량 생산, 또는 공급량의 조절로 가격을 높게 결정하는 방식으로 시장의 지배력을 높이고 이윤을 극대화 할 수 있었지만, 구매자들이 상품에 대한 정보 접근이 쉬워짐에 따라 시장 지배력은 구매자에게 넘어 갔으며, 공급자들은 다품목 소량 생산을 강요 받고 있습니다(mass customization). 이는 공급자가 원하지 않는 방향으로 시장 상황이 전개됨을 뜻합니다.

여기서 구매자도 마냥 좋은 것만은 아닙니다. 정보과잉 발생으로 품질 높은 정보를 찾는 일 자체가 많은 비용을 요구하게 됩니다. 더 효율적인 정보탐색 도구를 요구하게 되고, 이 도구는 [디렉토리검색:야후] -> [페이지 랭크 :구글] -> [집단지능: 디그] -> [소셜 검색: 트위터, 페이스북] 으로 이전하됩니다. 물론 도구의 완전한 이전은 아닙니다. 가치의 균형점이 변하는 것이죠.


능력만 있으면 좋은 일자리를 구할 수 있을 것이라고 생각하는가?  메리트가 있는 일자리의 리크루트 메일함에는 수백통의 지원자의 이력서가 쌓이지만, HR 담당자는 모든 메일을 읽어 볼 수가 없고, 결국에는 인간 간계에 의한 리크루팅 비중이 높아 진다. - 책 내용 중.

책 내용의 일부인 위 인용은 재화 ( 상품, 사람까지 모두 모함한 개념)가 가진 원래의 가치 만으로는 시장에서 선택되기 어려우며, 선택의 중요한 요소로 '관계'를 꼽습니다. 2000년에 출판된 이 책은 '관계'를 중요한 요소라는 것을 강조하고 있습니다.


신경제의 중요한 인재상 Geeks 와 Shrink
신경제는 폭넓은 지식으로 전반적인 통찰력을 가진 슈링크(shrinks) 와 그것이 상품화 가능성이 있는지 없는지에 상관 없이 한가지에 집중해서 개발해 내는 기크(geeks - 괴짜 라는 뜻을 가지고 있는 slang) , 이 두가지 인재에 의해 굴러간다.

신경제는 생산할 상품을 공급자가 아닌 수요자가 선택한 상품이 생산되는 시스템입니다. 공급자가 권력을 잡고 있던 시대와는 달리 다품목, 소량, 적시(간반 이라고 말하는 것) 생산과 짧아진 상품 라이프사이클 환경이 조성되었고, 모든 정보를 완벽히 파악하고 상품을 생산하는 것은 거의 불가능한 상태가 되었습니다. 이런 환경은 통찰력을 가진 쉬링크 shrinks 라는 인재를, 결정된 상품을 수요자의 높아진 눈높이를 맞출수 있게 생산할 능력을 가진 기크 geeks 를 요구합니다.


Geeks 이면서 동시에 Shrinks인 사람들
Geeks 와 Shrinks 별개로 나누는 것은 이 둘이 배타적인 성격을 갖기 때문이죠. 속성상 동시에 가지는 것이 매우 어렵습니다. 그럼에도 불구하고 둘을 모두 갖춘 이들이 있었으니, 마이크로소프트의 빌 게이츠, 애플의 스티브 잡스, 페이스북의 마크 주커버그 등 혁신을 만들어낸 회사의 리더들이죠. 모두 개발의 전문성(Geeks)을 가지고 있으면서 팔릴 수 있는 상품이 무엇인지를 아는 통찰력(Shrink)을 가졌습니다. 잡스가 말한 '기술' 과 '인문학'의 교차점이 바로 Geeks 와 Shrinks의 균형점을 의미한다고 저는 생각합니다.


우리나라의 상황은 어떤가?
Geeks = 엔지니어 = 을, Shrinks = 갑, 우리나라에서도 Shrink 라고 판단 할 수 있는 몇사람이 있으며, 박경철 원장님 같은 사람이라고 생각하며, Geek 이면서 Shrink인 사람으로 안철수 교수님이라고 생각합니다. 우선 Geeks 와 Shrink 라는 인재상의 정의 및 인지의 부재가 가장 큰 문제라고 여겨 집니다. Geek와 Shrink 의 인지 부재 및 이런 인재상을 안다고 해도 무작정 모든 일을 할 수 있는 사람을 원합니다. 좋은 말로 멀티플레이어 나쁜 말로 잡부. 

이와 같은 현상은 '산업사회' 에서 '지식사회'로의 이전 중인 혼란한 과도기 상태로 정확한 진단을 못하고 있는 것을 의미하죠.



[이책의 주요 키워드]

캘리포니아 현상: 신경제의 고용시장에서 발생하는 현상. 첨단기술의 메카인 미국 서부에서는 해고되거나 직장을 떠나는 것이 직원의 능력과는 별개의 문제라고 인식되는 현상. 이와 같은 현상은 현재 미국 전역에 퍼진 상태임.

DINS(Double Income, No Sex): 신경제의 가족상의 특성을 나타낸 단어. 부부가 맞벌이를 하면서 피곤에 절어 있기 때문에 성 관계를 갖지 않는 라이프 스타일


기크(geeks): 신경제가 원하는 인재상의 하나. 원래 뜻은, 일반 사람과는 다른 행동을 하는 사람을 뜻함. 자신의 관심 분야에만 전략을 다함. 혁신적인 아이디어가 넘침. 특히 첨단 기술 혹은 새로운 것에서 가능성을 찾아 상업화 하는데 희열을 느끼는 성향을 가진 사람.


슈링크(shrinks): 기크 이외의 신경제가 원하는 인재상의 다른 하나. 탁월한 경영자는 기크와 슈링크의 기질을 겸비해야 함.사람들이 원하고 필요로 하는 것을 잘 알아내는 창조적 혁신적 성향을 가진 사람. 유형의 상품에 고객이 원하는 무형의 특성을 가미해 부가가치 상품을 만드는 탁월한 능력을 가진 사람.


책의 목차

1부 새로운 일 

1. 구매자 천국의 시대 
2. 혁신의 정신 
3. 기크 & 슈링크 
4. 이제는 어울리지 않는 신의 
5. 과거 고용 방식의 종말 

2부 새로운 삶 

6. 열심히 일하라는 유혹 
7. 자신을 팔아라 
8. 줄어든 가족 
9. 돈 주고 사야 하는 관심 
10. 하나의 상품으로서의 지역 사회 

3부 선택 

11. 개인의 선택 
12. 사회의 선택




관련자료

cimio 님 - 달러의 위기 

poety82 님 - 한국의 경제위기, 민주주의와 시장만능주의(MB경제정책 반박) 


책 [부유한 노예] 에 대한 좋은 블로그 포스트

여유만만님 - 부유한 노예

바람처럼님 - 부유한 노예

Jay Park 님 - 부유한 노예


PS :  부유한 노예에 대해 꽤 오래전에 읽은 책을 다시 정리하는 포스트 였습니다. 여러 블로그의 글을 읽어보니 우리나라에서는 그리 많이 팔리지 않았다는 글들이 많네요. 다시 보니 지금 더 절실함이 느껴지는 책이라는 생각이 듭니다.

책 상세정보 보러 가기


### FINE

저작자 표시
신고

이 글을 Twitter / Facebook 에 공유하기
이 글이 유익하다면 아래의 트위터 버튼을 눌러 공유해 주시거나, 페이스북 "좋아요" 버튼을 눌러 주세요.

   


Posted by 반더빌트
근래의 거의 모든 프로그래밍 객체지향이란 개념으로 구현합니다. 또한, 새롭게 제시되는 방법론 들도 모두 객체지향을 기반으로 제시됩니다. 실세계의 사물을 추상화(Abstraction) 하고, 캡슐화(Encapsulation) 하며, 계층구조는 상속(Inheritance)시키며, 부모와 다른 자식의 특성, 행위는 다형성(Polymorphism) 으로
구현된 그것, 바로 객체의 구성으로 프로그램을 만들어 나가는 것을 객체지향 프로그래밍 이라 하는 것이죠.

객체지향 프로그래밍



이렇게 정의가 되어 있어도 다시 나오는 질문이 있습니다 : "그래 알겠는데, 도대체 객체지향이 뭐야?, 뭐가 특별하다는 거지?, 왜 객체지향 방법론을 사용해야 하는데?, 어떻게 하는 거지?"

이와 같은 질문에는 다시 객체지향의 개념이 반복되죠. 끝이 없습니다. 도대체 어떻게 하면 객체지향을 제대로 이해 할 수 있을까요?  이 질문에 대한 잘 기술된 글이 있어 번역 포스트 합니다. 무엇이 객체지향이고, 무엇이 객체지향이 아니며, 객체지향을 만족시키려면 어떻게 해야 하는가? 어떤 이득이 있는 것인가? 를 다룬 글 입니다. 대부분의 관점에 동의 하며 특히 아래의 객체지향의 핵심을 집어내는 정의로써 에릭 에반스의 DDD 에서 이 장점을 취하기 위해서는 어떻게 해야 하는가에 대한 내용을 다루고 있습니다.

객체지향 프로그래밍 이란 캡슐화, 다형성, 상속 을 이용하여 코드 재사용을 증가시키고, 유지보수를 감소시키는 장점을 얻기 위해서 객체들을 연결 시켜 프로그래밍 하는 것 입니다.



번역 :

제목 :  What is Object Oriented Programming (OOP)?
http://www.tonymarston.net/php-mysql/what-is-oop.html


들어가는 말

뉴스그룹이나 포럼에서 나는 다음과 같은 질문을 매우 빈번히 접합니다. : 무엇을 객체지향(OOP) 라고 부르나요?, 뭐가 특별한가요? 왜 해야 하죠? 어떻게 하는 거죠?. 이런 종류의 질문을 하는 사람은 보통 비객체지향(non-OO) 프로그래밍에 경험이 있으며, 방법론의 전환을 위해서 잇점이 무엇인지 알고 싶어 하는 것입니다. 짧던 길던 불행하게도 대부분의 답변은 동화같고 애매모호하며, 의미없는 것들 뿐입니다.

비객체지향 언어로 1,000개 이상의 프로그램과 500개가 넘는 객체지향 기능의 PHP 프로그램을 작성해본 경험으로 이 논쟁에 기여를 해보려 합니다. 몇몇 객체지향 순혈주의자들은 내가 그들의 방법을 따르지 않는다고 생각하고, 나또한 그들의 방법론을 따르는 것을 거부합니다. 이것에 대한 나의 대답은 "세상에는 객체지향을 유일한 방법이란 없다" 입니다. 사람들은 나의 방법이 틀렸다지만, 그들은 전통적인 실수를 하고 있습니다. 내 방법이 틀리지 않은 간단한 이유는 "작동한다" 입니다. 길 막고 물어 봐도 "작동 하는 것이 틀릴 수는 없습니다. 작동하지 않는 것이 옳을 수는 없습니다."  내 방법이 틀린 것이 아니라, 약간 다를 뿐 입니다.

사람들이 전혀 쓸모 없는 답변을 하는 하나의 이유는 그들이 그렇게 배웠으며, 배운 것 이상으로 생각할 능력이 없기 때문입니다. 또다른 이유는 객체지향에 대한 설명들이 막연하고, 여러가지 의미로 해설될 수 있으며, 어떤 것이 해석 될 때는 '잘못 해석' 될 가능성이 있습니다.  심지어 추상화 Abstraction, 갭슐화 Encapsulation, 정보은닉 Information-Hiding 의  어떤 기본 용어들은 사람들 마다 다른 뜻으로 정의하고 있습니다. 사람들이 OOP의 기본개념들에 동의하지 않는 데, 어떻게 구현에 동의 할 수 있겠습니까.


OOP가 아닌 것은 무엇인가?

내가 반박할 첫번째는 non-OOP 에도 이미 존재 하고 있음에도 OOP 에서만 가능한 것처럼 말해지는 것들입니다.

OOP는 실세계 real world 를 모델링 하는 것이다.

OOP는 실세계를 모델링 하기 위해 추상화 Abstraction 을 사용하는 프로그래밍 패러다임이다. 더 나은 도메인 분석과 시스템 디자인의 통합을 제공 함으로써 실세계 모델링을 더 잘 지원한다. 

OOP 가 다른 방법론들 보다 실세계 모델링을 더 잘 지원한다는 것은 쓰레기 같은 말입니다. 모든 컴퓨터 프로그램은 프로세스를 모델링하는 방법을 찾는 것 입니다. 모델이 잘 못 됐다면 소프트웨어도 잘 못 됩니다. 개념적 모델은 실세계의 분석으로 만들어 집니다. 그리고 컴퓨터 소프트웨어는 전적으로 개념적 모델에  기반합니다. OOP는 더 잘 모델링하는 것을 보장하지 않습니다. 모델의 구현방법이 약간 다를 뿐입니다.

"추상화 Abstraction" 또한 해석해야 하는 용어 이고, 잘 못 해석되는 용어 입니다. "추상화의 진정한 의미 이해하기" 의 논의 에서 처럼, 추상화라는 말은  미켈란젤로의 작품을 보아야 할  때, 피카소의 작품을 떠올리게 합니다.

고객에게 필요한 X,Y,Z 기능이 없고, A,B,C 의 기능을 가진 소프트웨어가 만들어지는데는 이유가 있습니다. 고객이 요구사항 분석서에  X,Y,Z 를 언급하지 않았으며, 분석가가 이것을 집어내는 것을 실패했기 때문입니다. 내 오랜 경력에 비추어 이런 일은 빈번하게 벌어집니다.

OOP 에 의해 실세계가 모델로 바로 매핑된다는 것에 모든 사람들이 동의하지는 않습니다. 더 심하게는 프로그램은 세상을 모델링 하는 것이 아니라 세상의 부분만을 모델링 할 수 있다 입니다.


OOP는 코드 재 사용을 위한 것이다.

객체지향시스템은 코드를 재사용 함으로써 생산성을 증대시키고, 품질을 향상시키며, 비용을 축소 시키는 것을 약속한다.

쓰레기같은 말이다. 이것은 코드 재사용이 non-OOP 에서는 불가능하고 OOP 에서만 가능하다는 의미를 내포하고 있습니다. 코드 재사용은 코드를 어떻게 작성 하느냐에 달려 있는 것이지, OOP가 코드 재사용을 보장하는 것이 아닙니다. non-OOP 언어로도 재사용 가능한 라이브러리를 작성하는 것이 가능하며,  OO 언어로도 재사용 불가 코드가 만들어 집니다.

어떤 언어에서 같은 코드 블록이 100군데 이상 중복 되는 것은 언어 능력의 문제가 아닙니다. 또한, 어떤 언어로도 코드 블록을 재사용 가능한 라이브러리로 만들고 100군데에서 호출하게 할 수 있습니다.

OOP에 대해 수년동안 들어온 약속중에 하나는 , 소프트웨어 벤더들이 이미 작성해 놓은 라이브러리를 사용 가능하게 한다는 것입니다. 프로그래머들에게는 클래스를 작성하는 대신에 이미 작성해 놓은 클래스를 사용하라고 말했습니다. 그것은 '바퀴를 재발명하는 것'이라 면서 말이죠. 꿈은 실현되지 않았습니다. OOP 는 많이 약속 하고 조금 배달 한다는 것을 증명했을 뿐이죠.


OOP는 모듈화에 대한 것이다.

어떤 오브젝트에 대한 소스 코드는 다른 오브젝트 코드와 별개로 작성되고 관리되어질 수 있다. 한번 만들어지면 시스템 안으로 쉽게 전달 할 수 있다.

모듈화 프로그래밍은 non-OO 언어에도 수년동안 존재해 왔습니다. 그래서 이 논재는 객체지향이 비객체지향보다 낮다는 설명으로 쓰일 수 없습니다. 모든 언어는 하나의 어플리케이션 소스코드를 한개의 파일에 집어넣을 수 있습니다. 또한 여러개의 작은 모듈로 나누어서 모듈 별로 파일에 넣고, 유지보수하고, 컴파일 할  수 있습니다.

게다가, 여러개의 클래스로 구성된 어떤 소프트웨어는 자동적으로 모듈화 됩니다. 중요한 요소는 모듈 또는 클래스를 잘 디자인 하는 것입니다.


OOP는 플러그를 가능하게 하는 것이다.

특정 오브젝트가 문제가 있다고 밝혀지면, 여러분은 어플리케이션에서 그 오브젝트를 간단하게 제거하고 다른 오브젝트를 플러그 하듯이 대체할 수 있다. 이는 실세계와 유사하다, 볼트가 부러지면 전체 머신이 아니라 볼트만 대체하면 된다.

이것은 다른 모듈을 손볼 필요없이 개개의 모듈이 독립적으로 수정되고 컴파일 되고 삽입될 수 있다고 말하는 모듈화의 경우와 같다.


OOP는 정보 은닉에 대한 것이다.

객체의 인터페이스와만 상호작용함으로써 내부 구현은 바깥 세상으로 부터 감추어 질수 있다.

첫 부분, 여기서 설명 하는 것은 '구현' 의 은닉이지 '정보'의 은닉이 아니다. 어떤 사람들은 무의식적으로 객체의 데이터가 포함된다고 가정합니다. 다시 말하면, API 뒤로 코드를 감춘다는 것은 뷰로 부터 감춘다는 것이지 객체로 부터 데이터를 감춘다는 말이 아닙니다.

두번째 부분 , 구현 은닉은 OOP의 목적이 아닙니다. 이것은 캡슐화의 부산물 입니다. 바깥 세상은 오브젝트의 메소드 이름만을 볼 수 있습니다. 메소드 뒤의 코드를 볼 수 있는 것이 아닙니다.

세번째 부분, 구현 은닉은  OOP만의 특별한 것이 아닙니다. 인터페이스를 가진 80년대에 작성된 상업용 COBOL 패키지를 기억합니다. 이 패키지의 벤더는 우리의 코드에서 호출해서 사용할 수 있도록 컴파일된 패키지를 제공 했었습니다. 우리는 그 서브루틴의 소스코드를 볼수 없었습니다. 우리는 단지  API 목록과 입력과 출력의 기술서를 받았습니다.



OOP는 메시지 전달에 대한 것이다.

메시지 전달이란 한 객체에서 다른 객체로 데이터를 전달하거나, 다른 객체의 메소드를 실행 시키는 것이다.

객체지향 언어에서 객체가 메소드를 실행시키는 것은 비객체지향 언어에서 함수나 프로시저를 실행시키는 것과 구별되는 것입니다. 비객체지향 언어에서의 함수나 객체 메소드를 실행 시키는 것은 "메시지 전달 Message Passing" 이 아니라 "호출 calling" 이라고 부릅니다. 사실 몇몇 언어에서는 서브루틴을 실행시키기 위하여 "호출" 이라고 부르는 단어가 필요합니다.

non-OO : $result = function(arg1, arg2, ...)
OO :        $result = $object->function(arg1, arg2, ...)

각각의 실행의 결과는 정확하게 동일합니다. - 통제권은 피호출자로 넘어가고 호출자는 기다립니다. 통제권은 피호출자가 종료 될때까지 반환되지 않습니다.

나는 과거에 메시징 스프트웨어를 작업해 보았습니다. 그것이 완벽하게 다르다고 말할 수 있습니다.

첫번째로 메시징 소프트웨어는 한 프로세스에서 다른 프로세스로 메시지를 전달하는 것을 허용합니다. 같은 프로세스에서 다른 모듈로의 메시지 전달이 아닙니다. 같은 어플리케이션의 한 non-Modal 폼에서 다른 non-Modal 폼으로 메시지를 전달 하는 것이었죠. 이것은 오로지 분리된 sendMessage() 함수와 수신 모듈에서의 수신되는 메시지를 처리하기 위한 receiveMessage 트리거 로써 가능합니다. 수신자가 송신자에게 응답하는 방법은 메시지를 전송하는 방법 이외에는 없습니다.

두번째로 행위( Behavior )가 전혀 다릅니다.

그것들은 비동기 입니다. 이것은 호출자는 메시지를 큐에 전송하고 다른 프로세스를 처리합니다. 피호출자가 통제권을 반환 하는 것을 기다릴 필요가 없습니다. E-mail이 전통적인 메시징시스템의 예 입니다.

메시지큐는 프로세스의 개수와 메시지의 갯수에 제약받지 않습니다. 수신 프로세스는 메시지 큐의 첫번째 메시지를 꺼내고, 또 다음 것을 꺼냅니다.

수신자는 메시지를 받자마자 송신자에게 acknowledgement 를 전송합니다. 또는, 처리된 메시지를 반환 합니다.

메시지 시스템은 acknowledgement 또는 결과를 전송하는 코드를 포함하고 있어야 합니다.

보다시피 객체가 메소드를 확성화 시키는 메커니즘은 비객체지향 함수가 활성화 시키는 것과 정확하게 동일합니다. 메시징 시스템의 메시지 전송과는 무관합니다.



OOP 는 책임의 분리에 대한 것이다.

각각의 객체는 구별되는 역할과 책임을 가지고 있는 작은 머신으로 보여질 수 있다.

언어의 문제가 아니라 전적으로 모듈이 어떻게 작성되느냐에 달려 있습니다. COBOL과 같은 절차적 언어로도 독립적인 모듈을 작성할 수 있습니다. 반대로 객체지향 언어로도 지극히 종속적인 모듈이 작성될 수 있습니다.


책임분리의 문제는 그 뜻이 정확히 무엇이든지 상관없이 해석하는 사람마다 다릅니다. 어떤 사람은 SELECT, INSERT, UPDATE, DELETE 와 같은 데이터베이스 오퍼레이션이 그를 필요로 하는 객체에 존재해야 한다고 생각하고, 어떤 사람은 그것들을 한데 모은 별도의 객체에(Data Access Object , DAO) 넣어야 한다고 생각합니다. 어떤 프로그래머는 테이블 마다의 DAO를 작성해야 한다고 생각하고  어떤 프로그래머는 모든 데이터베이스 테이블을 취급하는 한개의 DAO를 작성해야 한다고 생각합니다. 여러분은 책임들을 분리하기 전에 언어와의 별도의 디자인 결정에 의해 책임을 구별해야만 합니다.

내 모든 경험을 통틀어 "기술의 난이도"에 의해 실패한 단 하나의 프로젝트는 "책임의 분리"에대한 모든 것을 알고 있다고 생각하는 객체지향 설계 전문가와 함께 한 것이었습니다. 그들은 각각의 책임을 가지는 모듈로 나누고, 디자인 패턴을 이용하여 설계하였습니다. 이 결과로 UI 에서 데이터베이스 까지는 적어도 10개의 레이어를 가지도록 설계 되었습니다. 이로써 컴포넌트는 필요 이상으로 복잡해 졌고 테스트와 디버깅은 완전히 악몽이었습니다. 그 결과 고객의 시간과 비용은 엄청 증가하였습니다. 그 고객은 플러그를 뽑고 전체 프로젝트를 중단하여 손실을 제한하였습니다. 구식의 비객체 방법론으로 한시간도 채 안걸리는 컴포넌트를 최신 유행하는 객체지향 기술로는 10일이 걸렸습니다.

덧붙여서, "관심이 분리된 Seperation of Concern" 여러개의 클래스/모듈 로 자동으로 구성된 소프트웨어는 특정 엔터티에서는 "걱정거리 Concern"로 고려 되어 질 수 있습니다. 중요한 요소는 클래스 /모듈이 엔터티의 요구사항을 어떻게 잘 취급하는가 입니다.



OOP는 배우기가 쉽다.

OOP는 이전의 접근방법보다 배우기가 매우 쉽다. 이 접근방법은 개발과 유지보수를 단순하게 하며,  다른 절차적 방법론 보다  분석, 코딩, 복잡한 상황의 이해도를 직관적으로 만들어 준다.

마케팅 전략일 뿐입니다. 모든 언어/도구/패러다임은 그 가치보다 모든 것이 좋다고 제안됩니다.  무엇을 사용하느냐가 아니라 어떻게 사용하느냐가 중요합니다. 유능한 프로그래머에 의해 사용되는 '구식' 언어는 '신식'언어의 광고되는 생산성보다 몇배는 더 큽니다.

한 사람의 학습 능력은 종종 가르치는 사람과 가르치는 도구에 의해 제한 됩니다. 나는 프로젝트를 성공 시키는 것 보다 너무 비효율적이고, 복잡하게 하는 것을 배우는 것을 두려워 합니다. OOP를 가능하게 하는 방법은 "단 한가지" 뿐이라고 주장하는 선생님이 너무 많습니다. 나는 이것에 가장 동의하지 않습니다. 나는 소위 전문가 라고 하는 사람들의 방법을 무시하고도  비객체 지향 언어로 작성된 것을 성공적으로 객체지향언어로 마이그레이트한 경험이 많습니다.

어떤 사람은 프로시저 함수를 클래스로 감싸는 것 만이 OOP가 아니라고  나에게 말 했습니다. 나는 동의 하지 않습니다. 그것은 간단 합니다. 유일한 트릭은 연결된 함수를 한곳에 모으고( 캡슐화 라고 말하는) , 객체로 관리될 수 있도록 조정 합니다. 여러분이 클래스로 할 수 있는 정말 똑똑한 것은 부모 또는 추상 클래스를 상속(Inheritance)을 통하여 수개의 서브클래스로 확장하는 것 입니다. 다형성(Polymorphism)을 이용하여 서로 다른 클래스의 메소드/함수를 사용 가능하게 할 수도 있습니다. 나는 함수들이 잘못 혼합된 매우 많은 예제들을 접해 봤습니다. 관계 없는 함수가 한 클래스에 있으면 안됩니다. 나는 상속의 과잉 사용으로 매우 복잡한 계층구조를 가져서 유지보수와 진보가 거의 힘든 경우를 보았습니다.  나는 다른 프로그래머에게 인상적으로 보일 목적 이외로는 볼 수 없는 객체지향의 모든 기능을 사용하여 코드를 더욱 불분명하게 만드는 프로그래머를 본적이 있습니다. 그들은 너무 단순하면 틀렸다고 생각하는 듯 합니다. 아마도 KISS( Keep-It-Simple, Stupid. 단순하게 하란 말야. 멍청아!) 원칙을 들어본적이 없어 보입니다.


OOP는 행위자(actors) 와 행위(actions) 에 대한 것이다.

객체지향 프로그래밍이란 소프트웨어 개발을 행위자와 행위를 코드를 이용하여 분해하고 모듈화하는 것이다.

이것은 매우 모호하고, 전혀 쓸모 없는 말입니다.



OOP 는 늦은 바인딩( late binding )에 대한 모든 것이다.

'늦은' 이라는 것은 (어떤 바이너리를 로드할 지 , 어떤 함수를 호출 할지) 바인딩을 가능한한 늦추는 결정이다. 컴파일 타임에 바인딩 (early) 하기 보다는 호출 될 때 바인딩 하는 것이다.

빠르거나 늦게 바인딩 되는 것은 객체지향과 비객체지향 차이와 무관합니다. 비객체지향 언어도 늦은 바인딩을 지원합니다. 비객체지향 언어가 늦은 바인딩을 지원한다고 해서 마술같이 객체지향으로 바뀌지 않는 것 처럼, 객체지향 언어가 빠른 바인딩을 한다고 해서 비객체지향 언어가 되는 것이 아닙니다.


알겠지만, 위는 너무 불명확하거나 OOP에 한정된 것이 아니어서 구별되는 기능으로 사용될 수 없는 것들을 기술한 것입니다.



객체지향 언어란 무엇인가?

아래의 것들을 제공한다면 그 언어는 객체지향언어 목록에 추가 될 수 있습니다.

객체-지향 언어의 5가지 특성
1. Object
2. Class

3. Encapsulation
4. Inheritance
5. Polymorphism

5가지 특성이 무엇인지에 대한 설명 포스트: 객체-지향 프로그래밍이란 무엇인가? 다섯개의 기반 개념 참조 하세요.


클래스는 엔터티의 프라퍼티(데이터) 와 그 프라퍼티들에 작동하는 메소드( 함수 또는 오퍼레이션) 들을 정의(캡슐화 Encapsulation) 합디다. 엔터티의 프라퍼티나 메소드는 클래스 바깥에 정의 되어서는 안됩니다.


객체지향 이란 무엇인가?

여러분이 믿고 싶어하는 것보다 훨씬 단순 합니다. 사람들은 실제의 그들 자신보다 더 영리해 보이기 위해 더욱 복잡한 정의를 사용합니다. 여기에 진짜 정의가 있습니다.

객체지향 프로그래밍 이란 캡슐화, 다형성, 상속 을 이용하여 코드 재사용을 증가시키고, 유지보수를 감소시키는 장점을 얻기 위해서 객체들을 연결 시켜 프로그래밍 하는 것 입니다.


객체지향 프로그래밍을 하기 위해서는 객체지향 언어가 필요합니다. 캡슐화, 상속, 다형성을 지원한다면 객체지향 언어라고 말 할 수 있습니다. 다른 기능들도 지원 할 수 있지만 그것들은 그닥 중요하지 않습니다.  이는 개인적인 의견이 아니라 객체지향 용어를 발명한 사람의 의견 입니다. Bjarne Stroustrup 은 그의 문서 Why C++ is not just an Object Oriented Programming Language: 섹션 3 에서 지금의 널리 사용되는 "객체지향" 이라는 용어를 제시하였습니다.

언어 또는 기술은 다음을 직접 지원 한다면 객체지향 이다.
1. 추상화 - 클래스나 객체를 제공한다.
2. 상속 - 이미 존재하는 것으로 부터 새로운 추상화를 만들어 낼 능력을 제공한다.
3. 런타임 다형성 - 수행시간에 바인딩 할수 있는 어떠한 폼을 제공한다.


많은 객체지향 언어들은 나중에 더 많은 기능들을 추가 하였고, 몇몇 사람들은 이 부가 기능들을 객체지향을 결정하는 요소라고 생각하지만 나는 전혀 동의하지 않습니다. 이는 온도조절기나 네비게이션이 없다고 자동차를 자동차가 아니다라고 말하는 것과 같습니다. 이것들은 구별되는 기능이 아니라 선택 사양 입니다.

바퀴가 있다고 해서 자동차라고 말 하는 것 또한 틀린 것입니다. 바퀴를 가졌다고 모든 것이 차가 되는 것은 아닙니다. 손수레에 바퀴가 있다고 해서 자동차가 되는 것은 아닙니다. 이것은 구별되는 기능이 아닙니다. 비객체지향 언어에 이미 존재하는 것이기 때문에 "모듈성", "재사용성", "메시징"을 비객체와 객체를 구별하는 기능이 아니라고 말하는 간단한 이유입니다.


OOP 와 non-OOP 의 차이점



비객체와 객체의 차이점을 설명하는 가장 좋은 방법은 실제 예제를 보는 것입니다.

다르게 정의 됩니다.

함수는 필요한 것을 가진 코드의 블록으로 정의 됩니다. 각각의 함수 이름은 어플리케이션에서 유일해야 합니다.

function fName ($arg1, $arg2)
// function description
{
    ....
   
    return $result;
   
} // fName


클래스 메소드는 클래스 정의의 경계로써 규정됩니다. 각각의 클래스 이름은 어플리케이션에서 유일 해야 합니다. 각각의 클래스는 클래스 내부에서 유일한 이름을 가지는 다수의 함수(메소드라고 알려진)들을 가질수 있습니다. 어플리케이션에서 유일할 필요는 없습니다. 사실 공통의 함수/메소드 이름을 가지는 것은 다형성에서 필요로 하는 공유의 능력을 위해서 입니다.

class cName
{
    function fName ($arg1, $arg2)
    // function description
    {
        ....
       
        return $result;
       
    } // fName
   
} // cName



접근 방법이 다릅니다.

함수/클래스는 그 정의가 로드되기 전에 접근될 수 있음을 주목해야 합니다. 

함수를 호출하는 것은 직접적입니다.

$result = fName($arg1, $arg2);


클래스의 메소드를 호출하는 것은 직접적이지 않습니다. 먼저 클래스의 인스턴스를 생성해야 합니다. 그리고  오브젝트의 함수 이름을 통해서 접근합니다.  오브젝트 이름은 어플리케이션에서 유일 해야 합니다.

$object = new cName;
$result = $object->fName($arg1, $arg2);


다수의 다른 복제본을 가지고 있습니다.

함수는 접근되기 전에 인스턴스화 될 필요가 없습니다. 단 한개의 카피본 만이 존재하기 때문이죠.

클래스 메소드는 오브젝트로 인스턴스화 된 후에만 접근될 수 있습니다. (정적 메소드로 정의된 경우를 제외하고) . 같은 클래스로 서로 이름이 다른 다중의 오브젝트로 인스턴스화 시킬수 있습니다.
 
$object1 = new cName;
$object2 = new cName;
$object3 = new cName; 

 
인스턴스화 시키지 않고 정적메소드에 접근할 수 있다 하더라도, non-Class 함수의 접근보다 나을 것이 없습니다. 오브젝트에 의해 실제로 사용되지 않으며, 객체지향 프로그래밍의 한 부분으로 고려되는 사항이 아닙니다.


다수의 엔트리 포인트를 가집니다.

함수는 단일의 진입점을 가집니다. 그것은 함수 이름 그 차체 입니다.
오브젝트는 여러개의 진입점을 가집니다. 각각의 메소드 이름 입니다.


상태 관리를 위한 다수의 메소드를 가집니다.

함수는 기본적으로 상태를 가지지 않습니다. 이것은 호출 될 때마다 새로운 실행으로 취급된다는 것을 의미합니다. 이전 실행과는 아무 연결이 없습니다.

오브젝트는 상태를 가집니다. 각각의 오브젝트의 메소드가 호출될 때 마다 오브젝트의 상태가 변경됩니다.

이것은 함수와 클래스 메소드 모두 로컬 변수를 사용한다는 점에서 같은 방식으로 동작합니다. 로컬 변수란 함수나 클래스 메소드의 범위를 넘지 않는다는 것을 뜻합니다. 그리고, 실행들 사이에서 저장되지 않는다는 것이죠.


함수가 서로 다른 수행에서 값을 기억할 수 있는 방법은 정적 변수를 사용하는 것입니다.

function count () {
    static $count = 0;
    $count++;
    return $count;
}

이 함수는 호출 될 때마다 이전 호출 값보다 하나더 증가된 값을 반환 합니다.  static 키워드가 없다면 항상 '1' 이라는 값을 반환 합니다.

클래스 레벨에서 선언된 변수를 함수(메소드) 범위 밖으로 저장시키려면 다음과 같이 하면됩니다.


class calculator{    // define class properties (member variables)    var $value;        // define class methods    function setValue ($value)     {        $this->value = $value;                return;            } // setValue        function getValue ()     // function description    {        return $this->value;            } // setValue        function add ($value)     // function description    {        $this->value = $this->value + $value;                return $this->value;            } // setValue        function subtract ($value)     // function description    {        $this->value = $this->value - $value;                return $this->value;            } // setValue    } // cName

클래스/오브젝트의 참조는 $this->varname. 과 같은  $this->  프리픽스 에 의해 참조 된다는 것에 주목하세요.
this 키워드로 참조되지 않은 $varname 변수는 로컬 변수로 취급됩니다.

각각 인스턴스는 자신의 변수를 가지고 있습니다. 같은 클래스로 부터 나왔을 지라도 하나의 오브젝트의 컨텐츠는 다른 오브젝트와 독립적입니다.


(실제 예제 - 캡슐화, 상속, 다형성의 예제는 번역에서 생략합니다. 예제는 원문을 참조하세요.)


결론.


많은 사람들이 OOP의 의미를  서로 다른 단어로 묘사합니다. 문제는 그 단어들이 오역되기 쉽다는 것이죠. 루이스 캐롤의 험프티-덤프티가 자칭한 유리창 너머로 볼때 처럼.

내가 이 단어를 사용할 때는 내가 선택한 뜻을 의미해, 더도 덜도 아니야


OOP의 창작자가 사용한 단어를 사용할 때, 그 단어에 다른 뜻을 적용한다면, 다른 사람은 여러분의 단어를 또 다른 뜻으로 적용합니다. 그것은 원래와 전혀 관계 없는 것으로 끝이 납니다.

객체지향과 비객체지향을 구별하는 데에느 단지 세가지 기능이 있습니다. 이것들은 캡슐화, 상속, 다형성 입니다. 이거 이외에는 헛소리 입니다. 객체지향 프로그래밍은 프로그래밍 언어에서 이 기능들을 이용하는 것입니다. 높은 재사용성과 낮은 유지보수 비용은 보장될 수 없습니다. 전적으로 이 기능들을 어떻게 구현하느냐에 달려 있습니다.

몇몇 사람들은 내가 OOP에 대해 너무 단순한 관점을 가졌다고 비난합니다. "필요이상으로 단순화 시켰다거나", "필요이상으로 복잡화 했다 거나" 라고 하는 대신에 말이죠. KISS 원칙의 오래된 추종자로써 나는 다른 사람들을 가르치기 쉬운 더욱 적절한 관점을 알고 있습니다.

### 끝.


더 읽을 꺼리 :
제목 : 구조적 프로그래밍 이란?
http://user.chol.com/~hurcb01/study5_sub7.html
신고

이 글을 Twitter / Facebook 에 공유하기
이 글이 유익하다면 아래의 트위터 버튼을 눌러 공유해 주시거나, 페이스북 "좋아요" 버튼을 눌러 주세요.

   


Posted by 반더빌트
이 포스트는 사람들이 왜 정보를 탐색하고, 탐색할 이유가 있다면 그 방법은 무엇일까? 라는 궁금점으로 시작 되었습니다.  그러던 차에 정보탐색과정론(테롤 클싸우 지음, 김효정 옮김, 한국디지틀포럼, 2000) 이라는 책이 도움이 되는군요.
더불어 정보탐색도구 로써의 검색엔진과 소셜미디어의 포지셔닝에 대해 생각합니다.

정보탐색은 정보요구에 의해서 유도되며, 정보탐색의 과정에는 서지적 패러다임과 구성적 패러다임이 존재합니다. 구글과 같은 검색엔진은 서지적 패러다임에 위치하는 도구이고, 트위터와 같은 소셜미디어는 구성적 패러다임과 정보탐색과정 6단계(탐색착수, 논제선정, 탐색조사, 초점형성, 정보수집, 정보표현) 에서 논제선정, 탐색조사, 초점형성 단계와 밀접하다는 결론을 얻게 되었습니다.

정보탐색과정론은 문헌정보학 관점에서의 적용방법과 사례가 포함되어 있으나 이 포스트는 일반적인 정보탐색과정을 전제로 요약하고, 정보탐색도구로써의 검색엔진과 소셜미디어의 차이를 이야기 합니다.

소셜미디어는 정보탐색의 초점형성을 지원하는 도구. 이미지출처 : http://debrahelwig.files.wordpress.com/2010/09/focus.jpg




정보탐색과정론 (테롤 클싸우 지음, 김효정 옮김, 한국디지틀포럼, 2000)

1.   동기

      정보탐색의 과정을 밝히기 위한 이론 정.

      이론이란? " 번에 포괄적으로 이해할 있도록 다양한 사실을 함께 묶을 있는 방법" 이며 " 인간생활의 실제 행위에 대한 근거를 제공한다." - 조지 켈리

      이론은 실무자가 단순히 예감이나 직감에 의존하지 않고 일반적인 원리를 통해 실무에 접근 있도록 한다. 이론에 근거한 경험은 역동적인 이용자의 요구에 부응하는 서비스의 설계와 합리적인 진단에 있어서 기본적인 요소이다.


2.   정보탐색 3단계

      정의적영역(감정)

      인지적영역(사고)

      물리적영역(행동)


3.   정보탐색과정 6단계

      탐색착수(initiation) : 정보요구의 인식

      논제선정(selection) : 찾고자 하는 포괄적인 논제 확인 선택

      탐색조사(exploration) : 자신의 이해를 확장하기 위해서 포괄적으로 논제에 대한 정보를 파악

      초점형성(formulation) : 파악한 정보로부터 구체적인 논제의 관점에 초점을 맞춤

      정보수집(collection) : 구체적인 논제와 관련된 정보 획득

n  적합성 적절성을 기준으로 필터링.

      정보표현(presentation): 정보탐색을 완료하고 결과물 이용 제시 준비


4.   공적 지식과 사적 무지,윌슨 1977

      인간은 세상사에 대한 내적 모델의 최신성을 유지하기 위한 일련의 습관과 경로를 갖고 있으며, 내적 모델을 확대 혹은 확장하기 위해서 공적지식을 이용한다.(p.36)


5.   정보서비스 패러다임

      서지적 패러다임

n  정보 자료원의 소장위치를 파악하는 것이 주요 목적(물리적 접근)

n  확실성과 정돈을 강조

n  측정된 특정 질의문에 대한 응답과 단순 사실에 한정하며, 정확한 재현율의 측정에 바탕을 .

      구성과정 패러다임

n  정보자료원 내의 포함된 지식과 정보의 의미 해석에 역점을 .(지적 접근)

n  불확실성과 정신적 혼란을 강조.

n  이미 알고 있는 정보와 매칭 시키는 과정, 이미 알고 있는 지식을 새로운 관점으로 확장하는 과정을 포함.


6.   개인구성이론(personal construct theory)

      켈리(Kelley, 1963)

      새로운 정보는 기존의 구성 체계에 맞도록 재구성 되어야 한다. 세상사에 대한 우리의 견해는 새로운 경험에 의해 끊임없이 재구성된다. 과정은 기존의 구성체계와 새로운 정보간에 존재하는 모순과 불일치로 인하여 증대되는 불확실성으로부터 출발한다.

      인간은 환경에 보다 적응하고 행동의 근거가 되는 자신의 예측 과정을 향상시키기 위해서 자신의 구성체계를 조정한다. "세상에 대한 현재의 견해는 지속적으로 수정된다."


7.   정보에 대한 관점

      전통적 : 올바른 해답과 적합한 자료를 도출해 있는 사물이나 결과물로 인식.

      구성주의 : 학습하거나 구성체계를 변화시키는 .


8.   정보탐색의 인지과정

      정보요구

n  정의: 부족한 것에 대한 막연한 인식으로부터 발전한 . 혹은 이해와 의미구성에 도움이 되는 정보에 도달하려는 .

n  정보요구수준, 테일러

잠재적 수준(visceral): 실재하지만 표현되지 않은 요구.

의식적 수준(conscious) : 막연하게 머릿속에 표상된 요구.

형식적 수준(formalized) : 구체적인 용어로 진술된 요구.

타협적 수준(compromised) : 정보시스템에 표현된 요구.

n  탐색의 초기단계에서 대부분의 이용자는 자신의 기존 지식과 연계된 질문의 형식으로 정보요구를 표현하고 있음을 밝힘. 정보요구 수준의 마지막 단계에서 기존 지식과의 격차를 확인한 후에야 정보시스템의 명령어 형식으로 정보요구를 표현할 있다는 .

n  탐색과정은 정신적 활동, 물리적 활동 그리고 궁극적으로 이용자가 의미구성을 위해 시행하는 개념적인 활동이 유기적으로 조합된 과정이라 있다.


9.   정보탐색의 감정적 경험

      탐색요구의 초점이 형성되지 않은 상태에서 불안감을 느낌.


10.  정보탐색의 인지부조화

      이용자들은 정보탐구의 기능에 대해서 기본적으로 못된 인식을 하고 있으며, 검토해야 증거물을 찾는 것이 아니라 '문제에 대한 해답' 찾고 있다- 패트리샤 나프

      이용자들은 인지, 점검, 조사, 초점 형성과 같은 보다 탐구적인 과업을 초월하여 모든 단계에서 "수집(gathering) 완성(completing)" 이라는 과업만을 선택하고 있으며, 이는 탐색조사 초점형성 단게 없이 직접 수집단계로 넘어갈 잇는 논제를 선택한 후에 이용자의 기대치에 의존하는 방법이다.

      정보 탐색의 단계를 "포괄적인 사고, 반성적인 사고 학습"으로 인식하기 보다는 "시간 지연의 요인" 같은 부정적인 용어로 인식.


11.  듀이

      철학과 역사적 관점

      반성적 사고의 단계 , How We Think, 1933

n  제안(Suggestion) : 불완전한 상황으로 인한 의구심 상태.

n  개념화(Intellectualization) : 문제의 개념화

n  아이디어 유도(Guiding Idea) : 일시적인 해석.

n  추론(Reasoning) : 보다 정확한 사실에 의한 해석.

n  행동(Action) : 명확하거나 가상적인 행동에 의한 검증.


12.  조지 켈리

      심리적 관점

      구성의 5단계

n  혼동과 의구심: 새로운 경험

n  혼동과 가능한 위협 정리 : 불일치/부조화 정보.

n  일시적인 가설 설정 : 탐구 방향 설정.

n  검증 평가 : 실행 결과 평가.

n  재구성 : 새로운 구성체계 동화.


13.  브루너

      현재의 관점

      해석적 과업

n  지각 : 새로운 정보에 직면

n  선택 : 패턴 인식

n  추론 : 군집화 혹은 범주로 결합

n  예측 : 주어진 정보 초월

n  행동 : 정신적 산물 창조

      스키마

n  스키마란 개개인이 실질적인 증거를 초월하여 의미의 격차를 줄이고, 이미 아는 사실로부터 추정할 있도록 과거에 직면했던 자료의 재구성을 유도하는 과거의 경험과 행동에 대한 통합적이고 조직화된 표상이다


14.  패러다임의 변화 요인

      패러다임의 변화는 놀라움, 혼동 그리고 분열을 야기하는 대량의 유일성 정보가 통합되는 경우에 발생한다. - 토마스 .


15.  적합성과 적절성

      적합성

n  적합정보 : 연구 과제와 관련되어 있으며, 정보탐색에 있어서 유용한 것으로 판단되는 정보.

n  부적합정보 : 해당 논제와 일치하지 않거나 이해하는데 도움이 되지 않는 정보. 주제 이외의 정보라 있으며, 정보 탐색에 유용하지 않은 .

      적절성

n  정보가 적합하다기 보다는 주제에 어느 정도 결정력이 있으며, 어느 정도로 관련성이 있는가를 판단하는데 사용되는 기준. 개인적인 정보 요구와 밀접하게 관련되어 있음.


16.  논제와 초점에 대한 결정 기준 4가지

      개인적인 흥미와 관심

      연구과제의 요구조건

      정보의 입수가능성

      할당된 시간


17.  정보탐색의 태도

      수용적(invitational) : 개방적인 탐색을 촉진시키며, 새로운 정보를 수용할 있는 자세를 갖게 .

      지시적(indicative) : 탐색 완료단계를 향해 진행하도록 하는 자세를 갖게 .


18.  가설 설정(Hypothesis)

      수용적 태도에 의한 가설은 사실로서 주장하는 것이 아니라 마치 사실인 것처럼 일정 기간 지지할 있도록 비현실적인 결론을 제공하는 .

      불확실성을 극복하고 혼동과 의구심 그리고 위협감을 해소하는 방법.


19.  예측과 선택

      예측은 구성체계를 확신하거나 거절하는 행동을 유도한다. 인간은 외부세계와 조화를 이룰 있도록 자신의 구성체계를 지속적으로 평가하고 재구성한다. 예측의 정확성은 행동으로 인한 효과를 결정짓는다. 구성체계의 재구성을 통하여 예측을 변화시키며, 이로 인한 행동 또한 변화가 일어난다.


20.  정보탐색도구 로써의 검색엔진과 소셜미디어

      검색엔진(Goolge)

n  서지적 패러다임

n  정확도(Precision) 재현율(Recall) 최우선 키워드

n  초점형성이 되어 있음의 가정하에 수집(gathering) 완성(completing) 과업 수행

n  인지부조화

일상적인 정보요구에 초점이 형성 되어 있는 경우는 드물다.

      소셜미디어(Twitter)

n  구성과정 패러다임

n  정보요구, 사적무지 지각, 초점형성을 도와주는 도구

### 끝.



저작자 표시
신고

이 글을 Twitter / Facebook 에 공유하기
이 글이 유익하다면 아래의 트위터 버튼을 눌러 공유해 주시거나, 페이스북 "좋아요" 버튼을 눌러 주세요.

   


Posted by 반더빌트

Social Design Best Practices : 번역
이 포스트는 구글의 OpenSocial 문서에 포함된 Social Design Best Practices 의 번역입니다. 소셜을 디자인 하는 9가지에 대해서 설명합니다. 짧은 글인데 핵심을 집어 내고 있어, 소셜을 이해하고 실제 디자인 하는데 매우 훌륭한 문서로 생각되어 발번역 했습니다. 9가지 항목은 자신의 어플리케이션에서 부족하고 과한 것이 무엇인지, 기능들이 어떤 의미를 가지는지 판별하는 체크리스트로 이용해도 좋습니다.




http://code.google.com/apis/opensocial/articles/bestprac.html

새로운 링크 : http://wiki.opensocial.org/index.php?title=Social_Design_Best_Practices




소셜 디자인

님의 소셜 어플리케이션을 디자인하세요. 이미지소스: http://www.cyberdesignz.com/blog/website-design/how-to-socialize-your-website/


 

1. Engage Quickly

 

컨테이너를 넘어사용자는 알려지지 않은 어플리케이션을 사용하게 되는 공통적인 경향이 있다즉각적으로 가치를 찾을 수 없는 것은 제거해라인터렉션 으로부터 배워야할 교훈은 첫인상이 매우 중요하다는 것이다.

그리고사용자가 주의를 잃기 전에 계약을 맺는 것이 필요하다이것이 끝나면 30-second 경험에 집중하도록 제안한다전문적인 요소들 또는 초대장 보내기등의 기능으로 사용자가 산만해지기 전에 , 사용자에게 당신의 어플리케이션의 맛보기를 보여줘라.

 

아래의 내용을 시도해 보라.

 

당신의 어플리케이션을 완벽하게 깔끔하게 만들어, 목적과 핵심요소들을 이용해 가치와 정체성을 보여줘라.

브라우저 친숙한 경험으로 재미있고 흥미있는 컨텐츠를 보여줘라

당신의 어플리케이션에서 사용자가 컨텐츠의 추가, 설정 변경이 쉽고, 소유감을 느끼게 만들어라사용자 프로파일을 보관하는 것은 사용자의 기대감을 증가시킨다.

 

 

2. Mimic Look and Feel

OpenSocial 컨테이너들에는 수많은 look and feel 페이지와 프로파일이 있다당신의 어플리케이션을 디자인 할때, UI컨테이너에 비슷한 폰트, 탭버튼들을 이용함으로써 일관성을 유지하는 것이 좋다.

 

어플리케이션의 정체성을 나타내려 노력하는 것은 , 좋은 UI 룩앤필을 만드는 것과 약간 다를 수가 있지만여전히 심미적으로 강하게 하는 것은 사용자 취향과 자기표현이 필요하다.

 

 

3. Enable Self Expression

프로파일 컨테이너는 사용자의 정체성, 흥미와 취향을 표현한다사용자의 입장으로 볼때 이것은 자기표현과 소셜 그래프를 탐험하는 출발점을 의미한다뷰어 관점에서 볼 때 이곳은 배우고커뮤니케이트하고공유할 흥미로운 것을 찿는 곳이다연예브랜드그룹의 공통의 관심사를 통하여 자기 표현을 활성화 하는 것을 어플리케이션 입장에서 많은 장점을 가지게 된다.

자기표현은 또한 특정 주제 또는 제스쳐선물 같은 특정 커뮤니케이션 폼을 통하여도 활성화 된다.

 

 

 4. Make it Dynamic

좋은 소셜 어플리케이션은 자기표현의 뱃지로서 고정되어 있지 않다세션을 통하여 흥미로운 경험을 제공하기 위해 역동적으로 변한다.  친구들의 상호작용으로 변화되는 소셜 그래프의  변화를 어플리케이션의 상태를 변화함으로써 유발될수 있다변화는 어플리케이션 내부적으로 생산되는 새로운 컨텐츠에 의해서 유발될 수 있다이 두가지 경우에서날마다의 변화는 어플리케이션에 대한 흥미와 기대를 유지시키는 데 도움을 준다.

 

 

5. Expose Friend Activity

어플리케이션을 역동적으로 만드는 특히 쉬운방법은 소셜을 기록하는 것과 어플리케이션을 사용하는 친구의 활동을 제공하는 것어플리케이션 자체에서 항상 제공되어지는  뉴스친구 활동의 업데이트로 어플리케이션에 특정지어진 활동으로 생각 되어 질수 있다사용자는 이를 통해서 다른 사람들이 어떤 어플리케이션을 이용하고변경되고 사용량이 증가되는지를 인지할 수 있다.

 

 

 

6. Browse the Graph

친구의 활동은 소셜그래프를 탐색하는 것으로 수동적으로 노출 될 수 있다사용자는 종종 '친구의 최근 활동 , 컨텐츠를 비교하고 고르는 것그리고 그들의 활동만으로 간접적으로 상호작용'을 하는 것과 같이 적은 힘을 들여 상호작용하는 것에 흥미가 있다.  이런 스타일의 상호작용을 지원함으로써친구가 무었을 하는지 쉽게 찾을수 있게하는데 필수이다이것은 종종 사용자 프로파일의 이름의 연결 또는 사용자의 활동과 컨텐츠를 요약해서 보여주는 어플리케이션 특성화된 프로파일 형태로  제공된다.

 

그래프를 브라우징 하는 것은 단지 친구를 뛰어 넘을 수 있다어떤 상황에서는 친구의 친구를 보는 것이 흥미로울 수 있다특별하게 공통의 관심사에 빠졌을때사용자가 기회, 새로운 친구컨텐츠를 발굴해내는 것으로부터 소셜서클의 가치를 어플리케이션에 추가하는 것은 창의적인 방법이다.

 

 

 7. Drive Communication

친구의 활동과 컨텐츠를 브라우즈 하는 것은 종종 대화로 흐르게 한다.

깊은 사회적관계를 개발하기 위해 기회를 만드는 것커뮤니케이션이 일어날 수 있는 장소이것은 명확하게 가능하게하는 옵션을 만드는 좋은 연습이다.  이것은  코멘트 시스템 또는 wall의 공유를 통한 공공적  매너메세지를 링크하고이메일 또는 인스턴스 메세징 시스템을 이용하는 사적인 것이 될수 있다.  또는 포크와 같은 내무 커뮤니케이션또다른 단순한 제스처와 메세지들로써 더욱 지속될 수 있다.

 

 

8. Build Communities

컨테이너의 모든 소셜 그래프는 종종 너무 거대하고사용자가 쉽게 트랙킹 하기에 너무 클수 있다작은 커뮤니티를 키움으로써그리고 접근할 수 있게 만든는 것,  어플리케이션은 향상된 종합적인 사회적 경험과 같은 승미로운 기능과 풍푸함을 제공할수 있다다음의  공통적으로 만들어지고 사용될 수 있는 커뮤니티의  세개의 카테고리가 있다.

그룹지어진 관계(e.g 베스트 프렌드가족동창, etc)

즉각적인 소셜 서클의 사용자들의 공통 관심사

전체 소셜 그래프의 공통 관심사

 

 

9. Solve Real World Tasks

자기 표현과 커뮤니케이션은 종종 재미있고혼자 놀수 있다. OpenSocial 은 실세계의 문제를 푸는 플렛폼이 될수 있다소셜 그래프는 결정을 내리는 데 도움을 줄수 있다. 예를 들어 누군가 서가에서 무작위로 책을 집는다좋은 추천을 해주는 친구가 많이 있을 것이다.  엔터테인먼트의 다양한 가능성과 흥미로써모이고추적하고추천하고정보를 관리하고 배우고당신의 어플리케이션을 넘어서 지속되는 경험을 주는 유용한 요소가 될 수 있다.


### 끝.

저작자 표시
신고

이 글을 Twitter / Facebook 에 공유하기
이 글이 유익하다면 아래의 트위터 버튼을 눌러 공유해 주시거나, 페이스북 "좋아요" 버튼을 눌러 주세요.

   


Posted by 반더빌트
코딩의 시작은 객체의 생성 부터 입니다. 객체의 생성은 디자인패턴에서 생성패턴, 구조패턴, 행위패턴(Creational, Structural, Behavioral Patterns) 중 첫번째에 해당하는 것입니다. 생성패턴에 해당합니다. 개발 과정에서 객체의 생성은 매우 빈번하게 발생하며, 상태를 지정하고 변경하고 사용하는 방법을 디자인 하는 것은 매우 중요합니다. 객체지향 5원칙을 준수하는 생성자를 디자인하고 사용하는 방법에 대해서 다룹니다.

 

생성자를 디자인하다.

모든 시작은 생성자의 디자인으로 부터... 출처: 위키피디아, 천지창조 Creation Of Adam, 미켈란젤로


생성자의 책임

생성자는 최대한 가용상태임을 유지해야 하는데, 아래의 2가지 책임을 가집니다. 
1. 인스턴스를 생성한다. 
2. 인스턴스가 잘 못된 상태에 있지 않도록 초기화 되어야 할 항목을 사용자에게 알린다.


 

생성자 Constructor


생성자는 타입(type) 생성자 와 인스턴스(instance) 생성자 두가지가 있습니다.
public class Customer {
public Customer() { ... } // instance constructor
static Customer() { ... } // type constructor
}
타입 생성자는 static 이며 타입이 사용되기 전에 CLR(Common Language Runtime) 에서 실행 되며, 인스턴스 생성자는 타입의 인스턴스가 만들어 질때 실행 됩니다. 타입 생성자는 파라미터를 가질 수 없고 인스턴스 생성자는 가질 수 있습니다.


 

생성자의 디자인


1. 가능한 단순하게 하라. 이상적으로는 default 생성자를 제공한다. 
2. static factory method 형태를 제공하라. 이는 Loose Coupling을 지원한다. 
3. 메인 속성(Property)는 생성자 파라미터로 전달하라. 
4. 파라미터 이름은 속성이름과 동일하게 하라. 
5. 가장 최소한의 일을 하도록 하라. 가능한 파라미터를 속성에 할당하는 일만 하라.
6. 초기화에 문제가 있다면 생성자에서 예외를 발생시켜라. 생성자 범위를 벗어나면 잘 못 생성된 인스턴스가 사용될수 있는 상태에 놓여진다. 
7. default 생성자가 필요하다면 명시적으로 선언하라. default 생성자는 명시적으로 선언하지 않더라도 컴파일러가 암시적으로 만들어 놓는다. 파라미터가 있는 생성자를 나중에 추가 한다면 컴파일러는 암시적 default 생성자를 추가하지 않게되고, 이는 잠재적인 문제를 발생시킬 수 있다. 
8. 생성자 내부에서 virtual 멤버를 호출하지 마라. base 클래스의 생성자가 먼저 호출 되기 때문에 잘못된 초기화가 일어날 수 있다. virtual 메소드의 호출은 override 메소드가 담당하도록 해야 한다.


 

타입 생성자 디자인


타입 생성자란 타입을 초기화 하기 위한 static 생성자를 말합니다. 타입이 최초 사용되어 질때 CLR에 의해 실행됩니다. 
1. static 생성자는 private 으로 선언해야 한다. 타입 생성자는 CLR 이외의 곳에서 사용되지 않도록 설계 되어 있다. 
2. static 생성자에서는 예외를 던져서는 안된다. 현재 어플리케이션 도메인 내에서 의미가 없다. 
3. static fields 에 대한 초기화는 inline에서 수행하라. 생성자 내부에서 초기화 하는 field는 런타임이 최적화를 수행하지 못한다.


 

의존 주입 Dependancy Injection 관점으로 인스턴스 초기화 설명하기

(여기서 말하는 초기화는 일반적인 초기화 및 사용시의 가용상태를 만드는 것을 포함합니다.)

 

 

생성자에서 주입하기 Constructor Injection


생성자에서 파라미터를 전달하여 값(또는 객체, 이하 의존 dependency 이라고 칭함.)을 전달하는 것을 Constructor Injection 이라 정의한다. setter 메소드를 이용하는 방법을 Setter Injection 이라 정의 한다.
public class Emailer {
private SpellChecker spellChecker;
public Emailer(SpellChecker spellChecker) {
this.spellChecker = spellChecker;
}
}
[Constructor Injection]
public class Emailer {
private SpellChecker spellChecker;
public void setSpellChecker(SpellChecker spellChecker) {
this.spellChecker = spellChecker;
}
}
[Setter Injection] 

 생성자는 인스턴스 초기화의 책임이 있습니다. 초기화 할때는 속성에 의존을 할당하여 적절한 상태를 만들어야 하는데, 의존을 할당하는 방법은 생성자 파라미터, Setter 메소드 2가지가 있습니다. 

생성자와 일반 메소드와의 차이 : 
* 아무것도 반환하지 않는다.
 * 완전히 생성되기 전에 실행완료 되어야 한다. 
* final 필드를 최기화 할 수 있다. 메소드는 못한다. 
* 인스턴스 당 단 한번 호출된다. 
* 다른 이름을 지정할 수 없다. 클래스 이름과 같아야만 한다. 
* vitual 로 지정할 수 없다. 선언했으면 구현해야 한다.

 

 

Setter 메소드로 주입하기 Setter Injection


인스턴스가 완전히 생성된 후에 의존을 주입하는 것이 Constructor Injection과 다른 점입니다. Setter 메소드는 일반적인 메소드와 같은 방법으로 동작하면서 생성자의 제한을 극복하는 유연성(flexibility)을 가지고 있습니다. 하지만 유연성은 잇점을 가지고 있는 동시에 때때로 문제를 일으키는 원인이 되기도 합니다. Setter Injection은 일반적으로 매우 쉽게 사용됩니다. 많은 예제와 튜토리얼이 왜 사용되어야 하는지 아무 설명 없이 Setter Injection을 사용합니다. 사실 Setter Injection은 매우 유연하고, 편리합니다. 하지만 의존성 주입(Dependancy Injection) 관점에서 봤을때 완벽하지 않습니다. 

Setter Injection의 단점 : 
1. 인스턴스 초기화에 많은 setter가 필요할때 우리의 통제를 쉽게 벗어납니다. 
2. 클라이언트 코드 작성자는 setter 메소드가 사용되어야 할 적절한 시기에 대해서 알고 있어야 합니다. Setter Injection은 Information Hiding을 위반합니다. 클라이언트 코드 작성자는 사용하려는 타입에 대한 정보를 너무 많이 알아야 합니다.

 

인터페이스 주입 Interface Injection


Interface Injection은 인스턴스의 책임(role)을 주입해서 속성(property)에 대한 정보를 아는 것을 회피하자는 아이디어 입니다.
public class Rocket implements EngineMountable, Loadable, Startable,
Stoppable {
private Engine engine;
private Cargo cargo;
public void mount(Engine engine) {

this.engine = engine;
}
public void load(Cargo cargo) {
this.cargo = cargo;
}
public void start() {
//start this rocket's engine...
}
public void stop() {
//stop this rocket...
}
}
[Interface Injection] Interface Injection 의 장점: 
1. 목적에 맞는 이름을 붙일수 있다. setCargo(Cargo cargo) 보다는 load(Cargo cargo)라고 붙이는 것이 목적에 더욱 부합하며 이를 가능케 한다. 
2. 속성 정보에 대한 접근을 제한할 수 있다. 

단점: 
1. 모든 의존 마다 인터페이스를 정의하는 것은 낭비다. 
2. 많은 인터페이스를 나열하는 것은 class 정의를 깔끔하지 못하게 만든다. 
3. class signiture 를 지저분하게 만들며, 더 중요하게 처리해야 할 인터페이스로 부터 주의를 분산시킨다.

 

Method decoration (or AOP injection)


Method decoration은 의존 주입 방법의 변경에 흥미로워 합니다. 목적된 주입보다는 메소드 관점으로 접근합니다. 다시 설명하면, 원래 값이 아닌 injector-provided value를 반환하는 것입니다. 이 과정을 decorating 이라고 부르며 Decorator design pattern 으로 부터 이름을 따왔습니다.
public class Dispenser {
private Sugar sugar;
public Pez dispense() {
return new Pez(sugar);
}
}
[Method decoration]

 

 

Constructor vs. setter injection


Constructor 와 Setter injection 중에 선택하는 것은 인스턴스의 초기화에서 state 와 mutablility 두가지 요소에 의해서 좌우 됩니다. 우리는 대부분의 경우 필드가 딱 한번 할당되고, 변경되지 않길 바랍니다. 객체 생애 동안 의존이 변하지 않기를 바라는 것을 말하는 것이 아니라, 적시에 사용가능한 상태이어야 한다는 말입니다. Constructor Injection은 의존 불변을 제공해 줍니다. 고정된 의존 상태는 언제든지 사용가능하다는 것을 보증합니다. 프로그래밍에서 불변성(immutablility)은 매우 중요합니다. Setter Injection은 유연성을 가지는 대신에 immutablility를 훼손합니다. 그렇다면 Constructor Injection 만을 사용 해야 하느냐? 모든 의존이 결정되어 있고 불변하다면 Construction Injection 으로는 해결이 안되는 문제가 있습니다. 그것은 Reinjection Problem 이라고 합니다. 

 Reinjection problem : 의존하고 있는 인스턴스의 생애가 길고(long-lived) 의존 당하는 인스턴스의 생애가 짧으며(short-lived) 의존이 재 할당 되어야 하는 경우. 


의존이 예측되어 있고 불변한 것에는 Constructor Injection을 사용하고, Reinjection 이 요구되는 것에는 Setter Injection을 사용하는 것이 방어적이며 견고한 프로그래밍이라고 할 수 있습니다.

 

 

참고

Framework Design Guide Lines 2nd, 
Dependency Injection, Manning, by Dhanji R. Prasanna
저작자 표시
신고

이 글을 Twitter / Facebook 에 공유하기
이 글이 유익하다면 아래의 트위터 버튼을 눌러 공유해 주시거나, 페이스북 "좋아요" 버튼을 눌러 주세요.

   


Posted by 반더빌트


티스토리 툴바