http://www.asiae.co.kr/news/view.htm?idxno=2014011306532077417

by givingsheart 2014. 4. 1. 17:40

<과정 개요>
데이터베이스 구축 후 발생하는 다양한 현상 중에는 메모리 영역의 충돌로 인한 오라클 서버의 종료, 디스크 장치의 노후화로 인한 IO 문제, 사용자의 실수로 인한 데이터의 삭제 및 변경 등 사전에 인지할 수 없는 장애 현상들이 발생합니다. 소중한 기업의 데이터가 유실되는 것도 문제일 뿐만 아니라 실시간으로 사용자들에게 데이터를 서비스할 수 없게 되는 경우 기업들이 사용자들로부터 외면 당하는 것은 더 큰 문제가 아닐 수 없을 것입니다. 이러한 문제를 빠른 시간 내에 해결하기 위해서는 체계적인 백업과 복구 전략을 수립해야 합니다



강좌내용

교육목표데이터베이스에서 발생하는 다양한 장애 현상에 대한 원인을 분석할 수 있고 빠른 시간 내에 복구할 수 있는 기술을 배양, DBMS(Database Management System)에서 제공하는 백업과 복구 방법에 대한 학습을 통해 체계적인 복구 전략을 수립, 오라클 서버의 물리적 구조와 논리적 구조들에 대한 이해를 기반으로 데이터베이스 구축 시 고려해야 할 다양한 설계 전략을 수립, 사용자 세션을 효과적으로 관리할 수 있는 네트워크 솔루션 기술을 배양
강좌내용1 강 - 3 시간
노-아카이브와 아카이브 모드
• 노-아카이브와 아카이브 모드
• 전체 완전 복구 
• 테이블스페이스 완전 복구
• 데이터 파일 완전 복구

2 강 - 3 시간
Oracle 서버 구조
• Oracle 서버 구조 
• SELECT문의 처리과정
• DML문의 처리과정
• COMMIT문의 처리과정
• 백업과 복구 원리
• 컨트롤 파일과
• 리두로그 파일의 미러링

3 강 - 3 시간
전용서버 프로세스와 공유서버 프로세스
• 전용서버 프로세스와 공유서버 프로세스
• 로드밸러스와 Fail Over
• 데이터베이스 링크
• 기타 네트워크 솔루션
∎ PARALLEL RECOVERY

4 강 - 3 시간
RMAN 유팉리티
RMAN 유팉리티
• 리모트 DB 접속을 위한
• 환경 설정
∎ LISTENER.ORA
∎ TNSNAMES.ORA
∎ SQLNET.ORA 
∎ Naming Method

5 강 - 3 시간
취소기반 불완전 복구
• 취소기반 불완전 복구
• 변경기반 불완전 복구
• 시간기반 불완전 복구
• 기타 복구 솔루션
∎ CHECKSUM 
∎ 병렬복구
∎ 데이터 가드
∎ IMPORT & EXPORT


강좌일수5 일강좌시간15 시간
참조과목오라클 데이터베이스 백업과 복구


by givingsheart 2014. 3. 27. 18:05

<과정 개요>
소프트웨어 기술을 하루가 멀다 하고 발전에 발전을 거듭하고 있습니다. 소프트웨어 개발자와 개발팀은 새로운 기술을 익히고 적용하는 일로 늘 바쁩니다. 덕분에 시스템의 생명주기 점점 짧아지고 있습니다. 업무 영역(도메인)에서는 별다른 변화가 없음에도 불구하고, 기술적인 변화 때문에 시스템을 개선하거나 재구축하는 경우도 종종 발생합니다. 
이런 상황에서 업무 모델이 기술과 뒤섞여 있으면 기술이 변경될 때, 업무 모델과 컴포넌트도 함께 변경될 수 밖에 없습니다. 소프트웨어 설계 기술은 이런 상황에서 두 가지 서로 다른 성격의 요소를 분리하라고 가르칩니다. 관심사의 분리(Separation of concern)라는 설계 원칙을 적용해야 하는 상황입니다. 쉽게 변화하는 소프트웨어 기술과 상대적으로 변화가 더딘 도메인(업무)를 잘 분리하는 것이 좋은 설계의 기본 요건입니다. 
Domain Driven Design 접근 방법은 이러한 상황에서 주목을 받게 되었고, 객체 모델링에서는 이러한 사상을 반영하여 Domain Object Modeling을 강조합니다. 많은 소프트웨어 개발팀에서 DDD나 DOM은 사상이나 이론 수준에서 머물러 있습니다. 현실로 다가오지 못하는 그래서 책에서나 볼 수 있는 기술입니다. 이러한 설계 접근방법을 실무에 적용할 수 있다면 우리가 오래도록 꿈꿔 왔던 “재사용 가능한, 유연한” 시스템 설계가 우리 팀의 현실이 될 수 있습니다. 



강좌내용

교육목표- 도메인 중심 객체 모델링에 대한 깊은 이해 
- 도메인 모델과 아키텍처 모델의 결합에 방식에 대한 이해 
- 분석 모델, 아키텍처 모델, 설계 모델 간의 상관관계 이해 
- 모델링 절차에 대한 이해 
강좌내용1 강 - 3 시간
Modern SW Development Cycle
1. Modern SW Development Cycle (1h)
2. Domain Object Modeling 시연(2h)
- 요구사항 명세(Narrative, UseCase, and more) 
- DOM을 이용한 UseCase 분석 시연 
- POC 프로토타입을 통한 DOM 구현 시연 


2 강 - 3 시간
Domain Object Modeling 실습
1. Domain Object Modeling 실습(3h)
- 요구사항 명세 이해 
- DOM을 이용한 UseCase 분석 실습 
- POC 프토타입을 통한 DOM 구현 실습 


3 강 - 3 시간
DOM과 아키텍처 결합 시연
DOM과 아키텍처 결합 시연(3h)
- 아키텍처 설계 시연 
- DOM+POC와 아키텍처 결합 시연 


4 강 - 3 시간
DOM과 아키텍처 결합 실습
DOM과 아키텍처 결합 실습(3h)
- 아키텍처 설계 실습 
- DOM+POC와 아키텍처 결합 실습 


5 강 - 3 시간
Domain Driven Design 이해
-Domain Driven Design 이해(1h) 
-DRS(Domain, Resource, Service) 패턴 이해(2h) 

강좌일수5 일강좌시간15 시간
참조과목DDD와 도메인 객체 모델링


by givingsheart 2014. 3. 27. 18:03

http://james_parku.blog.me/110146865421


(추가)

또 이런.. 미친 짓을 했엇구나.. 시간 낭비는 아니었을까? (불논리는 수학과 밀접한 로우 레벨의 엄격한 학문이다.)

by givingsheart 2014. 1. 22. 11:57

1번의 경우는 헷갈릴만 했고.. 초기화 안하고 컴파일 해본적이 없어서.. 경험부족 +  사실 이클립스에서 자동 컴파일을

하니.. 스타트 버튼만 눌러버려서 이게 컴파일 실패인지, 컴파일 성공후 익셉션인지, 컴파일들 성공후 각 .class들을 링크하는 
과정상의 오류인지.. 구분을 못했다. 즉 내게는 컴파일 하다.->링크하다 (빌드)->실행파일-> 실행 파일로 파일형태니까.. 메모리
에 올리기 위해서 뭔가가 필요하고 -> 프로그램을 실행하다 에서 각 과정에 대한 개념이 부족한듯 싶다. 
(이클립스에선 컴파일할 class에 오류가 있어도 일단 스타트 버튼은 눌리니.. 그 결과가 컴파일 오류인지, 링크 오류인지,
런타임 오류인지를 구분을 못했었다)

그중 컴파일 과정에 대해선.. 오래전 간단한 계산기 프로그램 만들어 봤었는데..

구문을 분석해서 (1+2)*(3%2) 라면..  
1.우선 타입을 체크하고.. ()는 맞는지  , + % 등 연산자는 맞는지, 각 데이터는 타입과 값이 유효한지 검증할 것이고
2.()키워드,산술 연산자 키워드를 파싱(우선순위등 해석)해서 구문들을 분리(연산자 토큰,1,2,3등 데이터 토큰)하고 
3.스택에 연산자 토큰글과 참조할 데이터 토큰들으 넣어서 스택의 위부터 차례대로 꺼내어 계산 결과를
만들었던것 같은데.. 
(정확한 개념과 동작은 까묵..)

컴파일러 입장에서 클래스에 대해 1의 과정을 할때.. 데이터 타입에 대해 암시적으로 디폴트값을 넣어주는데..
메서드에 대해 1의 과정을 할땐.. 어째서 1의 과정을 생략할까? .. 단순하게 메서드의 타입 정의 (리턴형,메서드이름,
복귀 주소, 매개변수 타입, 매개변수 값들의 주소) 요것만 체크해주나? 어째서 메서드내 지역변수에 대해 디폴트 초기화
를 안해주는 것이냐!!! 해주려면 다해주던가!!!

=>좀 더 곰곰히 생각을 했다면.. 풀었을듯 하다. 내 경우엔 class 정의에서 필드에 초기값을 안 넣어도 컴파일러가 알아서
프리미티브 형이면 0,false,0.f 등 .. 레퍼턴스 형이면 null 로 알아서 초기화 해준다는 말을 너무 의식했다가.. 스택에서 
선언하는 지역 데이터에 대해선.. 컴파일러가 초기화 안해준다는걸 깜박했다. 
class A{}
class B
{
  int x; //여기에 예전엔 int a = 0; 이라고 클래스의 멤버 필드 정의와 함께 명시적으로 초기화를 해줬었는데.. 
          //이건 c스타일이라는 말에 ;;
  static int y;
  
  A a;
}

B b = new B();
sysout(b.x); //인스턴스 멤버 데이터
=> 0

sysout(b.y); //클래스 멤버 데이터
=> 0

sysout(b.a); //인스턴스 멤버 참조형 데이터
=> null

int c;
sysout(c); //메서드 지역 데이터
=> 왜 스택 변수는 알아서 초기화를 안해주고 빨간색으로 오류만 표시해주냣? 컴파일러는 각성하랏!
클래스 정의시엔 컴파일러가 알아서 디폴트값 세팅해는데.. 스택 변수도 알아서 0이던 null이던 넣어줄수
있을텐데.. 왜 안한거니??  괜한 혼란만 왔구만 -_-;

**************************************************************************************


2번 문제는 catch를 했으니.. finally 다음 일반 블럭도 당연히 수행되는걸 까묵 
catch()의 순서에 집중하다보니.. catch가 throw된 익셉션을 처리하는걸 까묵.. catch(Exception e)로 처리가 안되면..
exception이 아니라.. error이지.. 뭔가 함정이 있을거라 생각해서 풀었나.. 내가 제대로 몰랐으니.. 제대로 못푼거다;;

아까 dao볼때 .. 익셉션 처리catch 안하고 throws 로 넘겨버리는 잔상이 남았던듯.. 그때 구현에서도 이번 시험 예제
처럼 try{} 블럭과 finally{} 블럭 외에 다른 블럭도 있었나? 있을 필요가 있나? 시험 문제를 위한 코드 구현인가?

익셉션 발생 가능 코드를 try로 묶고.. DAO 클래스 처럼 자신이 익셉션 처리를 안하고 상위 콜러로 넘길것이면(=catch절 생략)
대신 finally로 현재 워커에서 열어 놓은 리소스등 종료 처리할 부분 처리. 이런 구성인데.. finally 블럭 아래의 일반 블럭이
필요한 경우가 있을지..? (글고 전에 찾아본 익셉션 문서를 상기하자. 책임 영역! , throws 로 콜러측에 강제할 상황의 구분!
=콜러측에서 예외에 대해 핸들링이 가능한 경우만 throws.. 기타 등등)

**************************************************************************************

8번 다형성 문제는.. 솔직히 내가 이걸 풀때 뭔 생각으로 풀었는지 기억이 안난다.

(1)Super super = new Sub1(); //이건 당연히 실제 인스턴스가 하위 타입이니까 상위 타입 참조에 캐스팅 없이 잘 들어가고..

(2)Super super = new Sub1(); //이것도 당연하지만.. 고려할게.. super 참조에 들어있는 실제 인스턴스는 Sub1타입..
Sub1 sub1 = (Sub1)super;  // 내경운.. 여기서 뭔생각을 했는지 모르겠다..  sub1 참조에 sub1이 당연 들어가는데..
                                       // 나는 sub1형 인스턴스를 캐스팅해서 sub1에 넣어야 한다는거에 이질감을 느꼈다. 참조가
                                       // super니까 형변환이 당연히 명시적으로 필요한데도 -_-;;; 솔직히 예제가 Animal형 , Dog형
                                       // Cat형이었다면.. 전혀 혼란이 없었을거라 생각한다. 
                                       //  그게 아니더라도 Object obj = new MyClass(); 
                                       //  MyClass my = (MyClass)obj; 정도만 되었어도 거부감이 없었을거라 생각한다;;
                                       //  (2)에 대한 진짜 별거 아닌 이질감이.. 보기 (4)를 볼때 엉뚱한 선입견을 심어놨다.

(3)Super super = new Sub1(); //이건 sub1 인스턴스를 sub2에 넣으려 하니.. 안되는거 당연히 인식했고..
Sub2 sub2 = (Sub2)super;

(4)Super super = new Super(); //이건 큰 타입을 작은 타입으로 캐스팅이 가능하다는 생각에.. (별 고민없이..) 요거 된다고
Sub2 sub2 = (Sub2)super;       //생각했는데.. 실제 인스턴스의 타입이 중요한거였다. -_-; 난 요걸 보며 뭘 생각한거지?
                                           // 참조형과 인스턴스형의 구분은 할줄 알았는데.. (2)번 보기에서의 괜한 거부감이 (4)번 보기를
                                           // 볼때 이건 맞는 답이라는 선입견을 심어준것 같다.

                                           // 이문제를 잘못 생각한 것은.. 인정을 해야할 부분이다. 내가 명확치 못했다.
                                           // 즉.. Super super 란 참조에.. new Sub1()을 해준다는 의미가 무엇인가?  heap에 Sub에
                                           // 특화된 메모리 공간을 할당함과 동시에.. 상속받은 상위 타입의 Super란 메모리 공간도
                                           // 할당이 됨으로서.. Super 타입의 참조로는 힙상의 Super 메모리 블럭을 사용이 가능하고
                                           // Sub타입의 참조로는 힙상의 Super 메모리 블럭 + Sub 메모리 블럭을 사용이 가능하단
                                           // 의미로서.. 한마디로 Super참조로 메모리를 가리켜도 super부분엔 접근이 가능하고, Sub
                                           // 타입의 참조로 메모리를 가리키면 super와 sub란 메모리 공간에 접근이 가능하기에 
                                           // 형변환시 오류가 날리 없음으로 컴파일러가 허용을 하는 것이다.

                                           // 반대로 뒤집어서 Sub sub 란 참조에.. new Super()를 해준다는 의미는.. new를 통해
                                           // 힙에는 super 형태의 메모리 블럭만 잡힐뿐 sub를 표현하는 메모리 블럭이 할당되지
                                           // 않는다. 즉 Sub 참조형으로 사용할수 있는 메모리가 존재하지 않는다는 의미이다.
                                           // 만약 Sub 참조로 Super의 인스턴스를 가리킬수 있게끔 컴파일러가 허용을 한다면..
                                           // Super의 인스턴스를 Sub의 참조로서 메모리 블럭을 접근 시켰다면.. sub.subMethod();
                                           // sub.subData = 0; .. 존재하지 않는 메모리 블럭에 접근하게 될것이다. 그 주소는 어떤
                                           // 위치일지.. 누구도 알수 없다. 그럼으로 아예 하위 타입의 참조로서 상위 타입의 인스턴스
                                           // 를 담을수 없게 지정한 것이다. (c/c++의 포인터와 혼동하지 말것! 자바는 나같은 허접 개발
                                           //  자를 믿지 않기에 내게 메모리를 맡기지 않는다. 내 경우엔 예전 c/c++ 할때 void*를 사용하
                                           // 듯이.. 4byte 포인터 형이라면.. 무조건 내 마음대로 static캐스팅이던  dinamic캐스팅이던
                                           // 을 했었다. 자바에선 타입 안정을 더욱 엄격하게 하는게 표준인듯 싶다.)
 
                                           //자식형 인스턴스엔 부모의 클래스 정보를 가리키는 추가 정보가 들어있을테니.. heap에선
                                           //메모리상 구조에 차이가 있을텐데.. 부모 인스턴스를 자식 참조로 받는 다는 것의 숨겨진
                                           //위험성을 인지못하고 형변환을 통해 담을수 있다고 판단했으니.. (예전 c의 영향같기도..)

                                           //내가 얼마나 무식햇는지 알수 있는 대목이다. 결국 몰랐던 지식은 아닌데.. 자바vs c/c++
                                           //이해및 경험이 부족했다. 일반적으로 상위 타입 참조에 구체 타입 인스턴스를 보관함으로서
                                           //컨테이너(동일 타입의 집합)에 관리하고 다형성(rtti)을 이용해 실제 타입의 데이터or 메서드
                                           //로 바인딩 되기에 상위 타입에서 work();라고 선언해두고 하위 타입에서 work(){}를 구현(
                                           //=재정의)시 내가 원한 하위 타입의 work()가 동작되게끔 구현하는 것이 일반적이라.. 물론
                                           // 인터페이스(메서드명)를 통일 안시켰으면.. instanceof 로 타입을 식별해서 각각의 메서드를
                                           // 호출할테고..

                                           // 결론은.. 내 경우엔 상위타입은 대부분 interface 또는 abstract + protected으로 처리를 해와
                                           // 서..(설계) 실제 상위 타입을 생성할 필요성도, 생성해서 형변환을 해본 경험도 없었다는 것
                                           // 이다.
                                            
                                           // 상위 타입의 참조에 상위타입을 생성한다는 것에.. 이질감을 못느끼다니.. 
                                           // 게다가 하위 타입의 참조에 상위타입의 인스턴스를 담게 할때의 위험성 때문에 자바에서 금지
                                           // 시킨것을 인식을 못했다니.. 아직 멀었다. OTL

                                           
**************************************************************************

글고 몇번 문제였더라.. 
콜러 측에서 int형 배열을 생성해주고 .. + 명시적 초기화 없이..
워커측에 배열의 참조를 전달해 워커측에서 [원소 접근 인덱스]++ 연산 해서 그 결과를 출력하는 것이었는데..

이경우도 1번과 마찬가지로.. new 키워드를 통한 메모리 블럭 할당과 자동 초기화에서 .. 이번엔 new 키워드라 인식을 했는데..
망할..
시험지엔 {0,0,0}으로 표시를 해두고.. 뭔 생각을 했는지 or 집중력이 떨어졌는지... 레퍼런스 형 배열의 new 와 착각
해서 {null,null,null}로 착각을 해버렸다. 워커측에서 null에 [] 인덱스 연산을 하려하니 당연히 뻑(널포인터익셉션)이 날거라 
생각했던거 같다.

뭐랄까.. 시험 보면서 논리적으로 꼼꼼히 따져가며 안풀고 대충 직관적 감각으로 푼듯한 결과랄까? (솔직히 swing 개념중
각 컴포넌트에 대한 이벤트 드라이븐 처리 방식 디자인 + 멀티스레딩 처리 개념을 이해하려다 머리에 필름이 끊겼었다 OTL..) 

글고 내가 일반적으로 코딩하면서 다뤄온 구현들이 아닌, 개념 이해를 테스트하기 위한 시험 문제 출제를 위한 구현이라.. 익숙
하지 못했다.

내 경우엔 배열을 생성하고 컴파일러 프리미티브 자동 초기화만 믿고 명시적을 초기화 안해주고 바로 넘겨주는 경우가 거의
없었던 걸로 기억한다. 

int[] arr = new int[3];  someMethod(arr); .. 사용해볼 엄두도 못냈다.

예전에 전산학원에서 배웠을때 데이터 초기화의 중요성에 대해 엄격히 가르침을 받았기에.. 나라면.. 워커에 넘기기 전에..
int[] arr = {0,0,0,0}; 또는 int[] arr = new int[4]; for(int i=0; i< arr.size; i++) arr[i] = 0;   또는 arr[0] = 0; arr[1] = 0; ...
이렇게 처리한 후에야 워커에게 넘겼을것이다. 

스트링형이라도 마찬가지.. String[] strs = {"",""}; 또는 String[] strs = new String[2]; for문에서 strs[i] = ""; ...

또한 배열보단 컨테이너를 배운후 부턴 컨테이너 생성 , 개별 인스턴스를 생성후 add던 append로 컨테이너에 넣어주고
ArrayList<Type> list = new ArrayList<Type>(capacity);
Type t1 = new Type(생성자 따라 초기화); // aggregation (composition 은 매개변수로 안받음)
 //t1.setXX(XX); //기타 필요한 세팅이 필요할 경우(association)
list.add(t1);                                           
someMethod(list);

또는 컨테이너 객체.add(new Integer(1));  컴파일러가  컨테이너 객체.add(1);을 암시적으로 변환해주는지는 기억이 안난다.

이런 프로세스가 몸에 배여있다고 할까?? 결국.. 프리미티브던 레퍼런스(프리미티브 배열)던 컴파일러의 암시적 초기화를 모르
는건 아닌데.. 내가 명시적으로 초기화해 주는게 습관이 된듯하다. (그래서 명시적으로 초기화 안해주는 코드를 보며 혼란이 
온거고)

컴파일러가 자동 초기화 해주는게 물론 편하긴 하다. 근데 초기화 해주는 경우, 안해주는 경우를 구분해야하니 기억할께
많아지지 않을까? 일관되게 인스턴스는 프리미티브건, 레퍼런스건, new로 힙 생성후  생성자가 호출됐던, 지역적으로 스택에 
생성했건, 전역적으로 static에 생성했건.. 일관되게 개발자가 명시적으로 초기화해주는게 명확하지 않을까..? 

이런 측면에서 암시적 생성자, 암시적 super 호출, 암시적 this 지원등.. 편하긴 한데.. 명확하진 않다. 글고 클래스 멤버 필드 
이름 지을때도 접두어m 를 안붙이는 것도.. 마음에 안들고.. m 이 this를 대신해 인스턴스 필드임을 의미하고.. s or g 가 클래
스 필드임을 의미하기에 괜찮은것 같은데.. 뭐 this.name = name;으로 구분이 되고, AClass.NAME = name; 처럼 클래스 필드
등은 대문자로 처리하니 구분이 되니까 .. 별문제는 없는데..

많은 선배 개발자,학자 분들이 논의를 통해 표준화 시켰을테니.. 내가 java 코딩 표준에 적응해야 하는것이 옳다고 생각한다.
(자바와 c++이 다른것이.. 많은 부분이 있지만.. c/c++ 에서는 암시적 초기화가 없었던것 같다. 그외에도 수많은 차이가 있다.
전처리기도 없고.. ex)#define MAX = 10   #pragma xxx  #if(debug) #ifndef 문법이 맞는진 모르지만.. 전에 assert등 .. 디버그
용 코드를 심으려 할때.. 개발 버전, 배포 버전 구분을 어떻게 해야할지..몰라서.. 물론  jvm 매개변수로 -ea 하는 방법이 있었
고, junint을 통해 테스트용 코드를 따로 생성하는 것도 알게 되었고.. 아.. maven이나 junit, jgit?, ant도 적응을 해야하는데..)

나는 자바의 객체지향 구현과 디자인에 반해 있으면서도 일부분은 아직 c/c++프로그래머 스타일인가 보다.. 억지로 컴파일러의
암시적 자동 초기화를 받아들이려고 하니까.. 혼란이 생긴듯 하다.(물론 int등을 Integer로 자동으로 바꿔주는 것도 포함.. 메모
리 할당및 초기화, 명시적인 해제, 메모리 접근, 그리고 참조..개발자의 편의를 위해서라지만.. oop의 캡슐화와 추상화의 취지
와도 맞다고 생각하지만.. 개발자들이 위의 과정을 모르고 지나치기 쉽게끔 너무 편의를 제공했다. 예전에 new로 생성하고..
free로 해제를 안해줬을때의 그 엄청난 찜찜함이란... 게다가 가비지 컬렉터가 서비스중 메모리 부족으로 풀 가비지 컬렉팅을
했을때의 위험성도 몇몇 글에서 봤으니.. )

데이터라면 
1.컴파일러에 타입 선언 (컴파일러 기본형 아닐때.. 말 그대로 c/c++ 에서 typedef.. 타입의 선언과 구현(정의)가 분리 가능)
2.메모리 할당하고 특정 이름으로 사용하겠다는 선언 + 메모리 블럭 값에 초기값을 넣겠다는 선언  int a = 10;
3.메모리 이름= 변수명(heap or stack or 공유 데이터라면 static 상 주소)을 통해 실제 값을 넣거나 읽는 등의 사용

메서드의 경운 
1.컴파일러에게 타입 선언(메서드이름,리턴형,접근제한,매개변수타입...필수는 아니지만 변수 이름주기) 
2.구현을 통해 메서드란 타입 정의(메서드의 스택 내부에서 사용하는 지역데이터의 경우는 저 위의 과정)
3.메모리 이름=메서드명(static상 공유 주소)을 통해 실제 사용 (순차적으로 처리될 컴파일된 목적코드는 어느 영역이었드라..
실행코드영역?)

클래스의 경운 (데이터와 메서드를 캡슐화 해놓았기에.. 위의 2개 과정들 중복 + 생성자및 각종 타입간의 상속 관계등 ) 
1.컴파일러에게 전체적인 구성 타입(데이터,메서드,상위타입) 선언  
2.구현 (명시적 생성자,기타 메서드 구현) + 클래스데이터에 대한 초기화 , 생성자의 구현에서 인스턴스 데이터에 대한 초기화   .. (1,2)를 합쳐서 클래스 정의
3.클래스의 역할에 따라서.. static 메서드로 사용  vs new를 통해 클래스의 개별 인스턴스를 생성해서 서비스 메서드로서 사용


************************************************************

10번 문제는.. 대박!
예전에 지훈형님과 string이 immutable 하다는 얘기를 했었는데..  내 생각이 너무 짧았다. concat 메서드에 집중을 했지..
이뮤터블을 깜박.. 단.순.무.식 
String str2 = str.concat("bbbbb"); 

이뮤터블의 개념은 알았지만, 틀려버렸다. = 내가 제대로 몰랐다는 의미! 
솔직히 지금까지 몇몇 프로젝트에서 문자열 처리 작업을 할때.. 그것이 분석및 분류 작업이라면.. 스트링 토크나이저를 통해서 
했고 붙이기 작업이라면.. + 연산자를 사용햇지.. str.concat을 거의 써본적이 없다. sysout에서 (a + "b") 또는 sysout(str.con
cat("aa"))  myMethod(str.subString("xx"))  (즉 스트링의 서비스 메서드가 리턴하는 새로운 스트링을 바로 전달) 요런식으로 
하는게 너무 습관화돼서.. 스트링 객체의 서비스 메서드인 concat, substring, index 어쩌구 기타 등등 메서드 들을 실제 저렇게
분리해서 사용해본 경험이 너무 적었다. 예전 로또 프로젝트에서 로또 번호 문자열 처리할때 subString 썼을때는 리턴값 받아서
사용했었고..


왜 자바에서 String 을 이뮤터블 패턴으로 결정했는지는.. 아직도 잘 모르겠다. (리소스 풀에 등록시켜둘라고 그러는건가?
.intern().. 왜 string에 대해 원본성? 요런게 확보되어야 하는지 모르겠다. 물론 고급 개발자들이 string을 이뮤터블로 결정한 
깊은 이유가 있을거라 생각한다. 아참.. 스티링간 + 연산자가 컴파일러 최적화를 통해 stringbuffer append()처리 되고 
반복문 내에서의 += 연산이.. 실제 메모리를 재 할당하고 복사하는 과정 때문에 오버헤드 발생하는 것을 상기할것! + 어떤
분의 논지였는데..  스트링 빌더,버퍼,synchronized 등등을 쓸때.. 과연 여기서 써야하나? 한번쯤 고민해보고 사용할것이란
메세지를 기억할것)

결론: 이뮤터블 객체... 실전에선 실수 안하려나? 간단한 개념이지만.. 이처럼 실수하기 쉬운 개념이기도 하다!

하여튼 선생님이 선별해주신 문제덕에 내가 제대로 모르던 것을 약간이나마 확인할 수 있어서 대만족!

************************************************************

ps. 틀린 문제에 대해 나름 리마인딩을 한다고 글을 작성하고.. 가급적 객관적인 시각으로 글을 읽어보니..
나라는 존재의 성향이 비쳐졌다. 틀린 문제에 대해 피곤했느니.. 아는거였느니.. 하는 뉘앙스가 군데군데 퍼져
있다. 알량한 자존심의 발로인가? 혹은 자기 보호 본능일까? 스스로 변명을 하고 자신을 지키기 위해서.. 

머리속의 개념들을 꺼내는 과정 자체는 나쁘지 않았다. 왜냐? 복습&정리를 통해 공부가 되었으니까.. 단지 동기가 
불순하여 표현이 시건방졌다.

모르는건 모른거고(정확히 알지 못하는것 = 모르는것), 실수했던건 실수한거다. 인정을 해야한다. 인정을 하고 겸손
해져야 배움이 있고 다음 단계로의 발전이 있다. 

자존심이 강할수록 실패했을때 좌절감이 커지게된다. 내가 폐인 생활을 하게된 계기도 너무 강한 자존심과 실패후
그 결과를 납득할 수 없었기 때문이었다. 게다가 내 경운 타인의 시선을 강하게 의식하는 성향이 있어서 스스로 무너
다.(사회인으로서 커리어를 쌓아갈 나이에.. 새롭게 법학 분야에서 어린 친구들과 경쟁등.. 초반엔 지적 호기심과 
조금씩 얻게 되는 성취감에 잊고 있었지만.. 실패를 경험하다 보니 내적 갈등이 발생했고 도피처가 필요했다. 결국 
그것이 누적되어 방구석 폐인이 되었던 것이다.)

내가 폐인 생활및 그간 살아오면서 알게된 깨달음중 하나는.. 모든 개구리는 자신만의 우물을 갖고 있다는것. 우물안
의 개구리인 주제에 자신의 우물을 "다른 개구리로부터" 인정받고 지키기 위한 본능이 존재한다는 것.  

결국 자신과의 싸움이지, 상대에 대한 싸움이 아니라는 것.
(내 안에선 아직도 알량한 자존심이 꿈틀대고 있는듯 하다. 본질이 아닌, 하등 중요치 않은 것들.. 어제에 비해 오늘의 
자신이 한치라도 발전해야 뿌듯한거지)

공개된 게시판에 글을 남김으로서 나 자신조차 객관적으로 평가해 버리다보면.. 망할 자존심 문제도 점점 좋아지고 
내 주관도 객관에 가까워 질수 있겠지.. 파이팅!


1.나는 왜 지금 swing을 공부하고 있나? 
 => db쿼리 툴을 학습수준이 아닌, 서비스 수준으로 만들고 싶어서..  
   1.1 db쿼리 자체도 굉장히 어려운 분야인데.. 겉핥기식 아닐까? 
    => 쿼리문 최적화, 테이블 설계등에 대해서.. 중요 포인트이고 학습이 필요하다고 생각함. 물론 스윙으로 툴app의 외관
        과 기능을 구현해 놓으면 추후.. 고차원적인 쿼리문 최적화, join 최적화 등의 작업을 고민하고 추가하는건 간단할듯함.
2.그렇다면 왜 db쿼리 툴을 만들고 있나? 취업용 포트폴리오인가? vs 별다른 의미는 부여하지 않았나?  
 => 별다른 의미는 없음. db 쿼리문 공부를 실제 툴 프로젝트를 진행함으로서 깊이 이해할수 있으리라 판단했음.
  2.1취업용 포트폴리오라면 어떤 회사를 목표로 하기에 db쿼리 툴을 선택했나? 
 => oop 구현 기법을 적극적으로 구사하고 공부할 예정임. 이 과정을 통해 디자인 패턴을 조금 더 이해가 가능하리라 판단함
     시장의 수요에 .. xx 디자인에 대한 이해가 요구사항 이었음
3.많은 시간을 투자해 공부할 만큼 가치가 있는 부분일까? 
 => 윈도우즈 프로그래밍을 공부할때 개념들 (컴포넌트간 관게,구조,이벤트 핸들링, 멀티스레드)을 잡아놓고 어떠한 기능들이
      있는지 훑어놔야 추후에 실제 app 구현시 이런 기능의 활용을 어떻게 접근해야 하겠다는 판단력이 생기고 , 그후 요 책을
      참고 용도로 활용할 예정. 전체를 정독할 예정 아님.
  3.1스윙에 투자를 한다 함은.. gui 프로그래머가 되고 싶은 것인가? 
   =>일단 독립 app개발이 가능한 수준으로 올라가고 싶음. gui부분 공부가 그래서 필요함. 물론 모바일쪽으로 간다면
      안드로이드, 세분화 해서 게임쪽으로 간다면 unity를 공부할 필요성이 있다고 생각함.


by givingsheart 2014. 1. 2. 09:29

 

제 경운 어제 소스코드 버전 관리를 위해 '서브버전'이라는 툴을 사용해보기로 했습니다.

처음엔 제 컴퓨터(로컬)에 관리툴 서버역할(저장소)를 설치하겠다는 목표였고

각 블로그를 참고하며 빠르게 성공할 수 있었습니다.(visual svn server)

 

 

두번째 목표가 바로 생겼는데 '휴대성및 원격 작업을 편하게 하기위해' 웹상에

저장소를 만들어보면 어떨까?란 발상을 하게 되었고 이런 저런 정보를 찾던중

아영이를 통해 네이버 개발자 센터라는 것을 알게되었고 그곳에서 svn도 지원을

 

해주더군요, 순조롭게 작업 진행중 계속 commit이 실패하는 문제가 생겼고,

저는 이 문제에 대해 약 12시간 가량 매달렸던것 같습니다.

 

 

(수업에 집중도 못하고, 제가 공부하고 있는  jsp진도도 못나가고.. 자괴감에

오늘 아침엔 악몽까지 꿨습니다.)

 

 

만약, 애초에 제가 계획한 제 로컬에 저장소 설치를 완료했으니, 네이버 저장소

이용이 계속적으로 실패했다면..

 

"적당히 끊을줄 아는 지혜가 필요했던것 같습니다."

 

 

 

예전 로또 프로젝트에서 로또번호란 vo데이터를 문자열로 처리하겟다는 마음을

먹고 엄청나게 고생을 했던 경험이 있엇는데도요..(덕분에 문자열 처리 관련해

이런 저런 경험을 쌓을수 있었지만요)

참고: http://cafe.naver.com/javachobostudy/96627

 

<추가> 로또 번호를 문자열로 만든 의미를 알게 되었음. 선생님께서 웹상의 유저 입력

데이터를 자바 단(서블릿)으로 가져올때 문자열로 밖에 가져올수 없다고 말씀하심.

결국 파싱 작업이 필요하다. 내가 String lottoNumber를 처리를 위해 int[] makeIntArray

(String lottoNumbers) 이걸 만들었었다. (etx)이름은 convertXXX가 더 나을듯 하다.

 

웹의 모든 데이터는 자바에서 문자열로 읽게되나? <-- 이 문제는 아마 나름 api들이

getInt()식으로 구현을 해놓지 않았을까 한다..

 

저는 생각보다 고집이 강한가 봅니다. 제가 발상을 떠올렸으면.. 그것을 무조건

성공시켜야 하고, 그것이 잘 풀리지 않을땐 엄청난 스트레스를 받아서 자포자기의

감정까지 발생을 시키고.. (자포자기 전까진 고집 때문에 다른 방법, 적당한 타협을

받아들이려 하지 않는것 같습니다.)

 

이전에 오라클 12c설치 작업을 할때에도, 기타 이런 저런 공부를 할때에도 비슷한

느낌을 받았습니다. 지훈이 형님께선 반드시 필요한 정보만 찾아 쉽게쉽게 접근을

하시는 것을 보고 느낀점이 많았는데.. (공부는 수단일뿐 목적이 아니다는 명언)

 

저는 어제 또한번 헤매고 좌절감을 경험했네요..

 

 

신은 개개인에게 다양한 재능을 주신듯 합니다. 제가 문제를 푸는 것을 좋아하고,

적당히를 모르고 몰입하는 성향이 있는 반면, 다른 분야를 좋아하고 그것을 행함

에 있어 다른 성향을 보이는 분들도 계실테고..  "누가 좋다,옳다,뛰어나다"는 아닌

것 같습니다.(저의 고집있는 성향도 어딘가에 쓸모가 있을 수 있겠지요 ^^;)

 

서로 다른 개체간에 영향을 받아가며 조화를 이루는 과정.. 저도 여러분들께 많이많이

배우고 싶습니다. (저와 다른 다양한 생각들,문제 처리 방법들을 수용하고 싶습니다.

자칫 저만의 잘못된 아집으로 이번 처럼 삽질할 수 있으니까요)

 

 

ps.제가 이것 저것 욕심이 많아서 바빠 보이지만, 사실 저도 별로 실속은 없습니다.

저의 도움이 필요한데, 혹시 제가 부담스러워 할까봐 도움 청함을 망설이시는 분들

부담 내려놓고 요청하세요. 가능한 범위에서 , 확실하게 아는 범위에서 도와드릴께요.

(무엇보다 선생님께 질문하고 정답을 얻는것이 가장 현명한 방법입니다. 기억에도

오래남을테고요)

 

(추가로 제게 도움을 청하실때 문제풀이,개발 관련 질문이라면 조건을 하나 달겠습니다.

묻기 전에 수첩에 로직or자신의 문제 풀이 접근 아이디어or 모르는 상황을 서술해 올것.

문제를 저와 함께 풀어 냈을땐 최소 2명에게 공유할것! 입니다.)

 

 

이전에 저는 제일만 책임지고 싶다고 강조한 적이 있었는데.. 그 선언은 민망하지만,

오늘의 깨달음으로 철회하겠습니다. "함께 고민한다"의 중요성을 알아버렸기도 하고,

무엇보다 사실.. 저는 여러분들을 좋아하거든요 ㅎㅎ

 

단지 조급함 (제 처지:나이-실무경험-시간부족) 때문에 선을 그으려 한것이고요. 

반성할께요~ 오늘도 좋은(행복+의미있는) 하루가 되기를!

 

 

ps2.오늘 버스타고 오면서 생각한 잡설

 

1.디폴트 생성자의 역할.

=>저는 여전히 모든 멤버 필드(어트리뷰트)를 받는 생성자만이 필요하다고 생각하지만,

해당 클래스가 상속 트리 계층에 속해 있다면, 상위타입(부모)의 생성자를 호출해주는

연결 과정은 무척 중요합니다. 모든 멤버 필드를 받는 하위 클래스의 생성자에서도

명시적으로 super(); 를 호출해 줘야하듯이..

 

즉 디폴트 생성자는 위험성은 있지만, 상위 타입의 생성자를 호출하는 super()가 암시적으

로 숨어있기에 자칫 깜박하고 super()를 비호출하는 위험을 줄여준다고 생각했습니다.

(정확히 맞는지는 모르겠네요)

 

아 그러고 어제 배운 object클래스의 equal,hashcode,copy란 개념은 확실히 해두시는 것이

좋습니다. 제 예전글에서 한번 집어본 기억이 있는데.. 개체간의 "비교"한다는 연산은

전산에서 중요한 연산중 하나입니다. 서로 같은지 다른지 알아야 식별해서 조회도 할것이며,

식별이 되야 정렬도 할것이며, 식별을 해야 추가및 삭제도 할것이며..

 

레퍼런스 형의 메모리상 주소 비교&대입(치환) 연산   vs    개체가 가지고 있는 멤버필드들(어트리뷰트들)간

의 비교&대입 연산의 구분!   을 강조합니다.  (hash란 개념은 "식별"보단 "효율적인 식별과 배치"

의 개념이니 논외할께요)

 

개인적으로 훌륭한 블로그라 생각합니다. 제게 엄청난 영감과 깨달음을 주는 곳

(불펌)  http://iilii.egloos.com/4427484

 

 

-(추가) equals , hashCode 재정는 아래처럼 한다. (.는 멤버필드의 value이고

hashCode에서 상위 클래스(Object등)에 정의된 hashCode값에 비트연산 xor(서로 비트값이 다를떄만 1을 리턴)

를 하는것에 주목할것!   <--> 비트 마스크를(&연산) 이용해 추출하는 것과 다른 xor의 사용법임!

원본 1100 xor 암호키 1000 => 암호데이터 0100 xor 암호키 1000 => 1100 이거 + 비트간 자리수 이동 반복이 DES?

 RSA는 머였지? 공개키 머시기 였는데;;)

*********************************************************************************

     public boolean equals(Object obj) {
         return obj instanceof GregorianCalendar &&
             super.equals(obj) &&
              == ((GregorianCalendar)obj).;
     }

    
Generates the hash code for this GregorianCalendar object.
 
     public int hashCode() {
         return super.hashCode() ^ (int);
     }

 

*************************************************************************************

 

 

-(추가2) 매개변수를 잘못 받은 워커측의 대처 방법 ㅋㅋ (콜러야 니잘못이다 나는 처리 못한다. 옛다 받어라~

그러면 콜러측에선 입력값에 대한 재처리등 작업을 할 수 있다. 물론 내가 정의한 익셉션 객체를 던지면

추가 정보도 전달해 줄 수 있을것이고. (ex)선생님이 말씀하신 주문수량 vs 재고수량 tradeOff)

 

**************************************************************************************

 

public void add(int fieldint amount) {

         // If amount == 0, do nothing even the given field is out of
         // range. This is tested by JCK.
         if (amount == 0) {
             return;   // Do nothing!
         }
 
         if (field < 0 || field >= ) {
             throw new IllegalArgumentException();
         }

 

*************************************************************************************

 

2.저는 인터페이스를 두가지 의미로 구분을 했는데.. 조금 더 구분을 할 필요를 느꼇습니다.

a.해당 클래스 계층 트리에서 설계의 의미.

b.다른 역할 클래스(비지니스 클래스,입력처리 클래스,화면 그리기 클래스,데이터 관리 클래스

기타 등등) 및 패키지및 서스시스템... 과 서로간 association(상대 객체가 제공하는 메서드 호출)

관계에서 public으로 노출해주는 메서드명.

 

이중 b를 한번 더 쪼개야 할듯 싶단 생각을 했습니다.

b.클래스 외부에 노출하는 public 메서드 = 외부 인터페이스

c.클래스 내부의 각종 작업을 위해 쪼개진 private 메서드들 간에도 서로간 소통 관계(associ...)

있기 때문에 그것을 = 내부 인터페이스

 

정확한 지식이 아닌, 착상 수준의 느낌입니다. 주의해주세요!




<2013.11.27 코드컴플리트중 상속과 오버라이딩 관련 추가>


1. 상속 계층 트리에서 메서드 오버라이딩 할때 구분할 개념들





a.오버라이드 가능한 "추상" 루틴(=메서드)은 파생 클래스가 루틴의 인터페이스를 상속받지만 구현부는 상속받지


않는다는 것을 의미한다.=>설계(interface)와 구현의 분리




b.오버라이드 가능한 루틴은 파생 클래스가 루틴의 인터페이스의 기본 구현을 상속받으며 기본 구현을 오버라이드할


수 있다는 것을 의미한다. =>Object 클래스의 equal() , hashcode(), copy() 등을 내 클래스의 사용 목적에 맞게 재정의


하는것




c.오버라이드 불가능한 루틴은 파생 클래스가 루틴의 인터페이스와 기본 구현을 상속 받지만 루틴의 구현을 오버라이드


할수 없다는 것을 의미한다. =>즉 해당 인터페이스 클래스가 외부에 노출시키는 public 인터페이스(메서드)를 의미




(ex)


 public abstract class Base


{


a. public abstract void method;




b. public void method()


{


   doSomething~ 

}




c. public final void method()


{


   doSomething~

}



}





=> 인터페이스를 상속(a)받고 싶을땐 구현 상속(b)을 주의하고, 구현을 상속받고 싶을땐 인터페이스 상속을 주의하고


만약 인터페이스는 필요없고 구현만 사용하고 싶다면 상속 대신 포함(agreegacion)을 사용하라! => stratergy패턴을 의미






2.오버라이드 불가능한 멤버 루틴을 오버라이드 하지 말것 (ex) Base의 private void method()를 Child가 private void method()


=> 별개의 루틴이지만, 이름이 똑같이에 다형성인듯 착각되기 쉽기 때문




3.공통적으로 사용되는 인터페이스,데이터,행위를 상속트리에서 가능한 한 가자 높은 곳으로 이동시킨다


=>높이는 정도는 해당 루틴이 해당 객체의 추상화를 깰때. 음.. Dog 에 있는 eat() Tiger 에 있는 eat()는 


   Animal의 eat()으로 이동이 가능하지만, eat()을 Object클래스에 올리면 Object 클래스의 '일반적'개념이 부셔지지..




4.인스턴스가 하나뿐인 클래스를 의심하자


=>파생시킨 클래스가 별개의 클래스로서가 아니라 데이터로 표현될수 있나?를 고려해야 한다. is a가 아닌, has a 인지,


   이도 저도 아니라면 서로 다른 계층 트리에서 xxAble이라고 interface class를 통해 특정한 속성의 집합으로 묶을수 있다.


   단, 싱글턴은 예외이다. 동물들에 싸움 기능을 추가하고 싶다고 dog -> fightAbleDog , nonFighterAble로 파생시켜 확장


   하는 것은 미친짓. 차라리 Animal에 FighteAble 필드를 추가하거나, FighteAlbe을 인터페이스 클래스로 구현해 implements


   하거나..




5.파생클래스가 하나뿐인 기본 클래스를 의심하자


=>너무 앞서서 설계했다. 가능한한 현재의 작업을 분명하고 직관적이며 단순하게 만드는게 중요하다.




6.루틴을 오버라이드하고 파생된 루틴 내부에서는 아무것도 하지 않는 클래스들을 의심하자.


=>기본 클래스 설계의 오류를 암시한다. "is a   vs    has a "




7.깊은 상속 트리를 피하자


=>내 경우에 awt를 분석하고 java api의 클래스들간 관계성을 분석할때 해당 클래스가 깊은 계층 트리에 있어서 복잡성


이 심했다.




8.간결및 직관성 vs 디자인 패턴


=> 무조건 패턴(추상적인 설계)을 적용시켜야만 할까?





(ex)


switch( ui.Command() )


{


 case Command_OpenFile:


         OpenFile();


          break;


  


  case Command_Print:


          Print();


          break;




  case Command_Save:


          Save();


          break;




  case Command_Exit:


           Exit();


          break;


   ...


}




=> 이 경우에 기본 클래스를 생성하여 각 명령에 대한 다형성 DoCommand()메서드를 만들수 있다


( Command패턴 ) 하지만 위처럼 switch case간단하고 명확한 경우엔 굳이 Command패턴을


사용해 비 직관적이게 만들 필요가 없다.





9.상속 계층 트리에서 기본 클래스의 모든 데이터(멤버필드)를 protected가 아닌 private로 만들자?


=>상속은 캡슐화를 부순다(joshua bloch) 그럼으로 파생 클래스에서 기본 클래스의 특성을 접근해야


한다면 protected 접근 메서드를 대신 제공하라.  <- 개념엔 동의를 하지만, 실제 구현시 너무 귀찮아짐으로


패스





10.다중 상속은 미친짓


=>다이아몬드 상속구조와 그에 따른 메서드명 중복, 생성&소멸자의 호출순서등 너무 복잡해짐으로 무조건 동의. 


더이상 노코멘트 








1~10 정리


a.만약 다중 클래스가 데이터는 공유하지만 행위를 공유하지 않는다면, 클래스가 포함할수 있는 객체를 만든다.


=>연산은 공유하지 않고 특성만 공유할 경우(has a)





b.만약 다중 클래스가 행위는 공유하지만 데이터를 공유하지 않는다면, 공통적인 루틴들을 정의한 기본 클래스를 


상속받는다.


=>인터페이스(외부 노출 public 메서드에 대한 계약or통제) 즉, 인터페이스 클래스의 존재 의의와 개념





c.만약 다중 클래스가 데이터와 행위를 공유한다면, 공통적인 데이터와 루틴들을 정의해 기본 클래스를 상속받는다.


=>일반 베이스 클래스 or 추상 클래스의 존재 의의와 개념





d.인터페이스를 제어하기 위한 기본 클래스가 필요할 때에는 상속을 하고(인터페이스 클래스를 의미), 인터페이스를


제어하고 싶다면 포함시킨다.(stratergy패턴 = 메서드의 확장)











<멤버 함수와 데이터를 효율적으로 구현하기 위한 몇가지 지침들>





1.클래스에 가능한 한 적은 수의 루틴을 유지





2.원하지 않는 멤버 함수와 연산자들이 암시적으로 생성되지 않도록 주의


=>자바의 경우 컴파일러가 추가해주는 암시적 default 생성자및 Object클래스에서 상속 받게 되는 


copy() 참조주소 복사 , equal() 참조주소 비교 , hashCode() 참조주소를 통한 해쉬코드 등을 의미한다.


즉 내 클래스의 목적과 특성에 맞도록 재정의해야만 하고, 또한 주의해야만 한다.





3.클래스에서 호출되는 루틴의 수를 최소화


=>클래스가 타 클래스와 assciation이 많아지면 오류가 증가할 가능성이 많아지고 이것을 "팬아웃" 이란 용어로 사용





4.다른 클래스에 대한 간접 루틴 호출을 최소화("데미테르의 법칙")


=> 객체 A가 객체 B를 인스턴스화했다면, B가 제공하는 루틴은 어느 것이던 호출이 가능하지만 , B에 의해 제공되는


객체들(C,D)의 루틴은 호출하지 말아야 한다.


(ex) account.contactPerson()   vs   account.contactPerson().dayTimeContactInfo()





5.일반적으로 클래스가 다른 클래스와 협력하는 정도를 최소화(4번을 다시 설명)


a.인스턴스화되는 객체의 수


b.인스턴스화된 객체에 대한 서로 다른 직접적인 루틴 호출의 수


c.인스턴스화된 다른 객체에 의해서 리턴되는 객체에 대한 루틴 호출의 수 








<생성자에 필요한 지침>





1.가능하다면 모든 멤버 데이터를 모든 생성자에서 초기화


=>내 경우에도 이것을 동의함. 매개변수 없는 생성자는 너무 위험하다고 느낌.(reflect를 이용해 생성할때


  클래스에 정의된 매개변수있는 생성자 타입 객체를 만드는게 가능한데.. 왜 프레임워크 들에서 단순하게 


  디폴트 생성자 타입 객체를 인스턴스화하고 거기에 invoke를 이용해 setter로 멤버 데이터를 초기화 하는진 의문임..)





2.private 생성자를 사용하여 싱글턴 속성을 구현


=>잘 알기에 패스 (단, 멀티스레드 환경을 고려할때 getInstance()의 if(instance == null) syncronized(instance) if(instance


  == null) {instance = new ClassType();} <- 이 패턴을 기억해둘것 (첫번째 if조건은 비 인스턴스화시 불필요한 연산을 


  방지하기 위한 성능 향상 목적이고, 두번째 if조건은 멀티스레드 환경을 고려한 구문임)





3.다른 사항이 증명될 때까지 얕은 복사보다 깊은 복사를 하자


=>동의함. value비교,복사는 시간은 오래 걸리지만, 객체의 독립성을 보장해줌. reference(주소)비교 복사는 시간은 빠르지만


객체의 독립성을 보장해주지 않고, 객체의 메모리상 존재만 보장해줌. 그럼으로 copy, equal, hashCode 는 기계적으로 해주자. 나중에 참조 형태로 풀어주더라도..








<클래스를 작성하는 이유>





1.실세계의 객체를 모델링





2.추상 객체들을 모델링





3.복잡성을 줄인다 


=>캡슐화&정보은닉&무엇을 public으로 노출시킬것인가 = 무엇을 private로 감출 것인가에 대한 고찰





4.복잡성을 고립시킨다.


=>클래스의 역할및 개념정의 책임의 영역 설정, 타 클래스와의 불필요한 관계 단절





5.세부적인 정보를 숨기자(3번과 동일. Interface적 의미)





6.변경의 영향을 제한할것(3,5의 정보 은닉과 동일)


=>(ex)하드웨어에 의존적인 부분(display,io등), 비지니스 규칙, 복잡한 데이터형





7.전역 데이터를 숨길것


=>클래스에서 public 으로 멤버 필드를 노출해주면 전역 데이터 처럼 사용이 가능한데.. 이것은 멀티스레드에


   안전하지 않을 뿐더러 관계되는 여러 클래스들이 전역 데이터에 의존적이게 됨





8.association에서 매개변수의 전달을 간소화


=>만약 어떤 매개변수를 여러 루틴들 사이에서 전달하고 있다면, 매개변수를 객체 데이터로 공유하는 클래스에 


이 루틴들을 포함시켜야 할 필요성이 있다는 것을 암시





9.중앙 집중 관리할것 


=>Format, Word(비지니스로직)의 설계를 reminding , 즉 Word는 여러개의 부분들을 통합해 의미 있는 업무


 를 창출하는 중앙 통제자의 역할임





=> 이해가 부족함. 코드 컴플릿2 236p.. 매우 중요한 개념 같은데.. 프레임 워크의 개념을 의미하는 것일까?





10.코드의 재사용을 도울것


=>재사용 가능성이 높은 일반적인 연산이라면 별도의 클래스로 추출하는 것이 효과적(중복 코드 방지)


   내 경운 이것을 클래스or 멤버 메서드로 뽑아내는 것만 생각했지 클래스로 추출한다는 것은 생각을 못했음.


   왜냐하면 객체지향이란, 연산의 집합이 아닌, 데이터 + 연산의 집합이기 때문.





11.프로그램군(family)를 위한 계획을 작성 (10을 다시 설명)





(ex) 수년전에 나는 보험을 파는 고객이 사용할 일련의 프로그램들을 작성하는 팀을 관리했얶다. 우리는 각 프로그


램을 작성하는 팀을 관리했었다. 우리는 각 프로그램을 고객의 보험률과 보고서 양식등에 맞추어야 했다. 하지만 프로그램의


많은 부분들이 유사했었다. 잠재적인 고객에 대한 정보를 입력하고 고객 데이터베이스에 정보를 저장하고, 보험률을 검색하고


,특정 그룹의 전체 보험료를 계산하는 클래스들이 비슷했다. 처음 프로그래밍했을 때는 석 달 정도 결렸던 것 같은데, 새로운


고객이 생겼을 때에는 새로운 고객을 위해서 새로운 클래스를 몇 개만 작성하여 나머지 코드 부분에 추가하였다.


몇일 동안 작업을 한 다음 , 소프트웨어 완성!  





=>내 이해가 부족해서 책의 내용을 그대로 옮겼음. 하지만 다수의 인스턴스를 관리하는 매니저 클래스의 연산인


   생성,삽입,조회,정렬,수정,제거,소멸은 알고 있다.





12.연관된 기능을 패키지화하자


=>정보를 숨기거나, 데이터를 공유하거나, 유연한 계획을 세울 수 없는 경우엔 관련된 기능들을 도메인 그룹으로 패키지


화 해서 묶자. 문제 발생시 전체 시스템에 파장이 적어진다. (즉 위에서 집어본 독립성과 동일한 개념)





13.특정한 리팩토링을 수행 (아직 개념이 정립이 안돼서 패스)





(ex)하나의 클래스를 두 개의 클래스로 변환하고(역할,개념적 분리?) 델리게이트(delegate=대표)를 감추고,


미들 맨 (middle man)을 제거하고, 확장 클래스를 만드는 방법으로 새로운 클래스들이 만들어진다. 





=>책의 내용 그대로 옮김(추후에 이해될듯.. 현재로선 내가 아는 범위 밖의 내용임)








<피해야할 클래스>


1.만능 클래스를 생성하지 말것


=>당연.. 코드가 더럽게 꼬이고 추후 수정도 거의 불가능





2.관련이 없는 클래스들을 제거할것


=>클래스의 위상이 아니다, 끽해봐야 내부 클래스 위상





3.동사가 따라오는 클래스를 피할것


=>다른 클래스의 루틴의 일부로








<전체 요약>


1.실세계의 객체를 모델링


2.추상객체를 모델링


3.복잡성을 줄일것


4.복잡성을 고립시킬것


5.세부적인 정보를 숨길것


6.변경의 영향을 제한할것


7.전역 데이터를 숨길것


8.매개변수의 전달을 최소화 할것


9.중앙 집중 관리할것


10.코드의 재사용을 도울것


11.프로그램군을 위한 계획을 작성할것 (이해 상당히x)


12.연관된 기능을 패키지화 할것(아주 살짝 이해)


13.특정한 리팩토링을 수행할것 (이해 전혀x)



by givingsheart 2014. 1. 1. 15:15

 

1.오전시간에 복습한 인터페이스 클래스, 추상클래스를 활용한 클래스의 설계와 구현의 분리

 

-추상클래스에서 하위 클래스들도 공통적으로 동작할 연산이면, 더이상 재정의 못하게끔

추상클래스 단에서 선언시 final을 붙여버리고 구현하는 것이 안정적이라 판단.

 

-하위클래스들이 차이를 갖는 연산의 경우 설계단(추상클래스,인터페이스 클래스)에서

인터페이스(외부에 노출시킬 연산)의 선언시 abstract을 붙여서 하위클래스에서 구현하게끔

강제 + 하위클래스에서 해당 연산을 선언시 protected로 scope를 줄여주는게 캡슐화의 관점에

서 옳다고 생각함.

 

-어제 했던 format 인터페이스클래스와 하위 구현 클래스 집합(템플릿 메서드패턴으로서 전체 시스템중 form의 역할)

 ,word 클래스(사용자로 부터 출력할 데이터, 포맷을 전달받아 출력이란 비지니스 업무를 담당)

 

  이 개념을 통해 예전 내 로또의 view 단과 control단의 꼬임을 해결할수 있을지 모르겠다고 직감이 왔었음.

  (좀더 설계와 디자인 패턴에 대한 이해가 깊어져야 함.) 그나저나 control 단이 business 단인가? 헷갈린다.

  spring 책을 빨리 봐야 do,vo,dto,layer,mvc,design pattern등 감을 잡을텐데.. 조각 조각 지식이 편재된 기분임.)

 

  내 경우엔 어제 format 인터페이스 클래스의  의미론적 개념과 ,  그것이 노출하는 인터페이스(메서드)의 이름

  ( getFormat() )에 도저히 적응을 못했음. 포맷 클래스가 String형 메세지를 전달받아 그것을 가공해 String으로

  돌려주는 것을 이해를 못했음.

 

  왜냐하면, 일반적으로 print()라는 행위를 한다고 할때, 출력할 데이터, 출력할 양식, 출력할 칼라 등은 출력이라는

  행위에서 객체가 되지, 주체적인 역할을 하지 못한다고 생각했기 때문임.

  

  결국 내 개념대로 시스템이 구현되었을 경우, 사용자는 word 객체의 print(출력할 문자열 데이터, 출력할 타입인

  열거형 포맷 스타일)   ex)  WORD.print(String data, FORMAT FORMAT::EQUAL) 이 되었을 것임.

 

  WORD 클래스의 내부 구현은 if(formatType == FORMAT::EQUAL) 서식 출력 else if(formatType == FORMAT::ETC)...

  또는 switch(formatType) case FORMAT::EQUAL  서식 출력 식이 되었을 것임.

 

  만약 고객의 요구로 출력 서식이 추가 되었을땐 WORD 비지니스 클래스의 구현이 변경되어야함. 만약 WORD 클래스가

  FORMAT외에도 COLOR , EFFECT 등등을 포함하였을 경우엔 WORD 클래스의 print()구현부가 엄청 복잡해지고 비대해

  짐.

  

  부수적으로 매개변수에 따라 사용자에게 제공할 인터페이스(메서드)가 많아 질경우 수정해야 하는 코드의 양도 더 많아

  질거라 예측됨.(실제로 안해봐서 모름) 

 

  (ETC) 객체지향적으로 사고해보아도, 포맷클래스가 데이터를 받아서 자신의 책임으로 가공한다는 역할에 알맞다고

  생각했음. 단지 인터페이스(메서드) 이름이 getFormat인게 직관적이지 않았음. makeStringByFormat() 이런 메서드 이름

  이었다면 처음에 혼란도 적었을거라 판단됨. 허나 한번 더 생각해보면 .. 포맷클래스가 자신의 개념정의대로 "자신의 정의

  (다양한 출력서식)에 따라 사용자(caller)가 전달한 데이터의 출력 양식을 처리하고 결과를 반환한다" 라고 접근해보면,

  매우 객체지향적이라 느껴짐. (추상적인 부분이라 말로 표현이 어려움)

 

 

  Format 클래스를 생성해 Word 클래스에 전달하는 것은 확실치 않지만, Strategy 패턴으로 판단됨. 어떤 포맷을 주입하냐

  에 따라 Word가 제공하는 print()메서드의 동작이 변화함으로.

 

  (ETC)기존 stratergy 패턴 설계에 따르면 Word클래스는 사용자로부터 Format 객체, Color 객체, Effect 객체를 전달받고 전달

  받은 객체들에게 순차적으로 일을 시키면  자신의 역할인 데이터의 출력을 수행할수 있다. 음.. 굉장히 멋진 설계 같음. 코드도

  깔끔할테고..

 

  그리고 Word 클래스의 print(format.getFormat(msg))하는 부분은 또다른 패턴의 효과로서 template method 패턴이라 판단됨.

  인터페이스 클래스를 통해 공통된 인터페이스(메서드)인 getFormat(String) 을 Word클래스에게 제공함으로서

  Word의 구현이 단순해짐. 즉 Word로선 Format클래스의 구체적인 타입에 따른 처리를 고민할 필요가 없어짐.(캡슐화

  ,정보은닉=>reduce dependancy? loose cupling?) 공통된 getFormat()으로 사용할수 있게 해준다는 점에 감사해야할 정도임.

 

  FormatA, FormatB, FormatC 식으로 싸지르듯 설계를 했다면, 위처럼 심플하게 처리가 불가능함. 전체 코드도 개판날테고..

 

  

2.오후 시간에 배운 예외처리

-try catch finally 등 문법적인 부분은 논외. 그외 exception이 계층트리로 구축되어 있고 구분도 됨으로 논외(api 도큐먼

  드에서 계층트리(영문판 7.0은 hierachy tree 일듯) 확인해보면, Error,Exception,RuntimeException을 수 많은 패키

  지들이 상속받아 사용하고 있음.(이러한 예외클래스를 상속구조로 체계화 함으로서 중구 난방식의 예외처리 클래스가

  아니게 되어 통일성이 있고, 타입의 계층트리라 함은 다형성을 JAVA,C++등 언어적으로 지원해주니 catch(Exception e)

  처럼 사용이 가능함.

 

- 오늘 배운것중 핵심은 문법이 아닌, 예외 발생시 제어의 흐름이라 생각함. 내 경우 예전에 input/output stream을 통해

   파일 관련 작업을 해주던중,,  익셉션이 났을때 내가 열어놓은 스트림(시스템 리소스)를 제대로 해제를 못해주는 경우

   가 발생했었음. 즉 예외 발생 가능한 코드들을 어떻게 try catch로 감싸는 지가 정말로 중요하다고 생각함.

   그나저나.. finally{} 가 return을 이긴다니.. 쇼킹했음. call stack이 unwired 될때 .. 너무 디테일하게 접근할듯 하니.. 그만 생략

 

-개인적으로 콜러->워커1->워커2->워커3->워커4  식의 클래스간 association 관계 or 메서드간(처리흐름) 의존적(?) 관계일

  때 워커 4가 throw한 예외를 워커3이 catch해서 처리가 가능한 경우 예외가 발생했다는 사실을 콜러 1에게 까지 전달해야

  하는지에 대해

  (sol)선생님 말씀으론 유저(최상위 콜러)까지 전달해주는 것이 일반적이라 말씀해주심.(simple stratergy is best)

  일단 하나는 해결이 되었고..

  (추가)jsp책을 보다가 517page void sendEmain(...)throws AddressException, MessagingException 식으로 처리함. 즉 자신이 아둥

  바둥 끙끙할바에 콜러쪽에 책임을 전가시키는 것임.


- (추가)오늘 jsp를 보다가 javax.sevelet.http.HttpSeveletRequest , Response 라는 클래스를 접해서 도큐 문서를 검색해봤지만

  찾을수 없었음. (sol) se 버전 -> ee 버전의 차이임.

 

 -콜러->워커(매개변수) 일 경우 워커의 연산이 콜러가 전달한 매개변수에 의존적일때.. 워커가 연산전에 전달받은 매개변수

  의 유효성을 검증하고 문제를 찾았을때, 해당 문제를 자신이 풀어버리고 콜러에게 적당한 결과를 줄것인지, or 문제를 풀어

  버리고 콜러에게 문제 발생을 알릴것인지, or 문제를 풀지 않고 콜러에게 바로 throw 할것인지...

 

  즉 전달 받은 매개변수에 대한 워커의 책임과 권한을 어느정도 까지 설정해야 하는지가 혼란스러웠음. 일단 정책을 잡은 것은

  전달 받은 값을 임의로 변경  caller가 0을 매개변수로 전달 -> worker(int num) -> worker의 연산 a / num; //devide by zero

  가 될것이고, 워커측에서 매개 변수에 대해 자신의 작업을 수행전에 if(숫자 범위체크) throw new NumericException 식으로

  처리를 할것임.  잘못된 매개변수에 대해 어떠한 조작및 연산도 수행하지 않고 바로 콜러측으로 책임을 전가시킴.

  =>자신의 잘못은 자신이 책임지자!    <-- 이걸 일반화 시켜도 될지 불안함.. 너무 많은 다양한 상황이 있을텐데...

 

  매개변수를 전달받은 경우의 사례에(일반화 시키면 콜러or 메인 시스템측의 잘못) 한가지 더 고민해 볼것은 콜러측에 예외

  에 대한 정보를 전달해야 하는데, 어떻게 전달할지에 대한 방식의 결정임.

  a.워커의 설계를 boolean workerMethod()로 만들어서 처리의 성공,실패란 2가지 의미의 정보를 콜러에게 전달할지

  b. int wokerMethod()로 만들어서 오류의 종류에 따라 숫자를 전달할지(콜러측이 모든 에러와 숫자를 알아야 하기에 콜러의

     부담이 커짐.)

  c. boolean werkerMethod() throws xxxException 식으로 만들어서 일반적인 수행 결과와 익셉션에 의한 수행 중지를 구분

    할지..  (콜러측이 반드시 처리를 해줘야 하게끔 강제하는 방식인데.. 만약 자신이 처리를 할수 있는 상황이라면? 그때도

    콜처측에 강요할 것인가? (sol) 선생님 정책에 따라 강제하지 않되(메서드에 throws 선언x) , 만약 자신(워커)가 lib등 각종

    api를 사용하면서 개발자가 반드시 try/catch로 처리해야할 Exception 의 하위 Exception들의 경우 워커가 처리하고 콜러

    측에 입을 다물지, 콜러측에 바로 예외를 던질지..  콜러는 워커보다 분명 시스템에서 상위의 흐름일텐데.. 역시 콜러측에

    무조건 알려야 겠다고 글을 적다보니 결정이됨.

 

    내가 이렇게 고민을 하게된 계기는 클래스 or 메소드간에 관계가 있을때 각자의 역할 정의와 책임 영역을 확실히 해야

    객체지향에 어울린다고 느꼈기 때문임. 게다가 the c++ programing language 책에서 try catch로 코드를 도배하지 말라

    고 경고했고.. (그래서 throw 해야할 상황과 아닌 상황을 구분을 해야만 했음.)

 

  -(2013/11/27추가) 콜러 1 -> 워커1 throws AExcpetion-> 워커2 가 throws 할수 있는 Exception 타입의 제한!

   트리계층 관계에서 상위타입이(or워커1) 선언한 throws Exception에 대해 하위타입(or워커2)은 Exception의 하위

   타입 or 상위타입이(or caller) 선언한 타입의 Exception만 throws 할수 있다.

   =>왜냐하면, 콜러측에선 워커1 선언된 throws 익셉션만 보고 try{} catch(){} 를 준비할텐데.. 난데 없이

     하위타입(워커의 워커= 워커2)이 전혀 다른 계통의 익셉션을 던져버리면 전체 시스템에 오류가 생긴다. 그것은 콜러의

     잘못도, 워커1의 잘못도 아닌 워커2의 잘못과 책임이다! (컴파일 타이밍에 잡아주는지는 테스트 안해봐서 모르겠음)

     (상,하위 클래스라면 잡아줄테지만, 메서드의 경우도 잡아줄지.. 흠.. 메서드는 클래스 내부 메서드니까 잡아주겠지..)

 

 -(추가) 사용자 정의 익셉션의 필요성에 대해 고민을 잠깐 했다. 그이유는 java api도큐먼트의 계층트리를 보면 

   수많은 종류의 error,exception,runtimeException 파생 클래스가 있었기 때문에 .. 사용자들이 제멋대로 추가를

   하기 보단, 상황에 맞는 익셉션을 찾아서 재정의(extends) 하는 것이 업무적 통일성(?)에서 낫다고 판단했기 때문이다.

   (sol) 수많은 구체적 익셉션 클래스가 내 상황과 100% 매치한다는 보장이 없다. 내가 구축하려는 시스템 만의

   익셉션 처리를 해야만할 독특한 상황이 있을수 있기 때문이다. 또한 팀작업으로 진행시 팀원들간 사용할 데이터

   타입에 대해 공유를 하기 때문에.. 중구난방의 익셉션 클래스는 방지가 가능할 것이다. = 단정하지 말것! 

 

  -(추가) 역시나 콜러->워커(매개변수)에서 매개변수의 유효성을 체크해야 하는 책임이 누구에게 있는가를 여전히

    고민했었다. 일반적인 메서드간의 연쇄가 아닌 내 경운 클래스간의 association으로 보니까 해결책이 어렴풋이 느껴

    졌다. 


    사례1: View 클래스 -> 사용자 입력값 전달(window app의 경우 메세지 핸들링) -> Control 클래스(내가 정의한 리스너)

    -> 사용자의 입력에 따라 적합한 비지니스 클래스를 선택하고 ,비지니스 클래스에 입력값을 전달해 비지니스 로직 수행 

     -> Business 클래스 작업수행 전에 매개변수(사용자 입력값)의 유효성 체크


     => 사용자 입력값의 유효성 처리는 coller(컨트롤러 클래스) 에서 하고 woker(비지니스클래스)는 유효한 값을 가지고 

     자신의 비지니스에 따라(ex)회원가입의 경우 -> 웹서버or 일반 서버로 request -> 서버의 입력처리 클래스(컨트롤러)가 

     적절한 비지니스클래스에 dispatch(request.detailInfo) -> 비지니스 업무가 회원가입의 경우이기 때문에 DB에 query

     request -> DB의 작업 수행후 ->response(비지니스 클래스에게? 아니면 컨트롤러 클래스에게?) -> 하여간 클라이언트

     측으로 처리 결과 전달 ... 생략


     => 사용자의 입력값에 대한 검증은 컨트롤러 클래스 단의 책임이다. (아직 프로젝트를 해본적이 없고, spring 프레임워크

     에 대한 개념이 전무해서 확실치 않다.)  


  -(추가)아.. 그러고보니 왜 sysout("에러메세지") assert 조건:xxx에러! 식으로 하지 않고 throw new xxxExcpetion을 사용하는

    지에 대한 고민이 부족했다. java ,c++ 언어적으로 지원하는 처리의 흐름 + 콜러측으로 문제에 대해 전달 + 해결이 안되면

    계속해서 상위 콜러로 타고가는 과정은 너무나 멋진 디자인이라 생각한다. 책임자&관할자를 찾아서 그 객체or루틴에 처리

    를 맡긴다라...   chian of responsibility 패턴의 아이디어와 유사하다. 


    언어적으로 오류처리에 대한 멋진 프로세스를 지원하니 당연히 사용해야 할 것이다.! (문제는 전체 코드가 try catch로 

    도배가 되면.. 알될것이다. 자신의 책임 영역에서 확실히 처리할 것! throws를 통해 콜러측에게 무리한 부담을 주지 말것!

    java api의 wrapper클래스들이 어떻게 내부적으로 예외를 처리해서 우리 개발자들의 부담을 줄여주는 지를 상기해야한다!


    =>결국 throw xxException을 적극적으로 사용하돼, 맡아서 처리할 클래스를 명확히 정의하고 서로간 책임 영역을 확실히

    해야할 것이다. 조금 더 깊은 이해와 경험이 필요할 듯 느껴진다.


 -(추가2) 커스터마이징 익셉션 클래스의 유용성. 즉 내가 재정의할 클래스이기 때문에 필요한 정보를 담아둘수 있다. 

   정보를 저장해두고, getter를 제공하면, 콜러측이 받은 익셉션에서 필요한 정보를 얻을수 있다. so good! (난 미처.. 생각을

    못했다는..) (ex)컨트롤러가 비지니스 로직에게 "사용자의 주문량"을 매개변수로 넘길때.. 비지니스 로직은 재고량을 체크

    해서 재고&주문량 tradeoff 값을 리턴해주면.. 콜러(컨트롤러)가 받아서 뷰단(사용자)으로 발송(다이얼로그 창을 띄우던지..)

     할 수 있다. 

   

    결국 컨트롤러 클래스 -요청-> 비지니스 클래스  비지니스 클래스 -응답 -> 컨트롤러 클래스란 양방향 관계에서 throw는 associ

    ation의 방법중 하나이다. 만약 throw 해서 컨트롤러 클래스에게 필요한 정보를 전달 안해줬다면, 컨트롤러 클래스는 자신의

    역할과 정의가 아닌, 재고량에 대해 어떻게든 정보를 얻어야 했을것이다. <-- 자바의 예외처리 메카니즘은 워커측이 작업

     수행불가인 상황 + 구체적인 정보를 전달해 줄수 있게 도와준다.  

     (return -10은 처리 실패, 재고량 10개   ,return 5는 처리 성공 재고량 5개  , ... ) 이것 보단 명확하지 않은가? 그럼으로 잘 사용해

     보자! 


  -커스터 마이징 익셉션을 throw한다는 것을 예외,에러 상황이라 인식하지 말고, 일반적인 상황이라 인식할것. 


   -아참 중요한건 아닌데.. java.lang.Throwable 인터페이스 클래스에 private 멤버 필드로 String detailMessage 가 존재 

     했기에 우리가 exception인스턴스.getMessage()가 하는 메서드를 통해 String 정보를 얻을수 있는것임. (grepcode.. thanks)



3.awt중 Compoenet 클래스, Toolkit 클래스 소스 코드 보기, s.o.p 소스코드 보기

 

-오늘도 대충 훑어 봤는데.. dispatch() 메서드를 분석, toolkit의 run() 메서드를 분석했음..

 

-처음엔 우리가 println()를 예외처리 없이 사용하는 이유를 알고 싶었음. (api 개발자가 우리가 편하게 사용할 수 있도록

 고민한 흔적) .. system클래스의 멤버필드인 outputstream 클래스를 상속받은 PrintStream 클래스가 제공하는 println() 

 를 grepcode.com 를 통해 파고 들어가서 버퍼에서 실제 데이터를 읽어오는 단계까지 접근했었음.

 

 PrintStream의 println(String)의 구현시 BufferedWriter,OutputStreamWriter,OutputStream 이란 멤버 필드에게 작업을 시켰는

 데.. 그중 실제 write작업은 BufferedWriter가 담당함(io과정에서 버퍼된 클래스를 사용해야 효율 증대는 논외) write()메서드

 로 이것도 파고들면 abstract 메서드니..설계가 녹아나있음. 전체적으로 이해는 못했지만.. 몇단계의 포장이(wrapper) 되어 있었

 고 내부적으로 버퍼에 입,출력하는 과정에서 발생하는 exception들을 처리했었음. 결국 내 경우(사용자) 내부 동작이 어떻게 돌

 아가는지 몰라도 간단한 인터페이스인 println()로서 편하게 사용할 수 있는 것임.

 

 자바의 in/output stream클래스들은 생성하면서 다른 스트림을 매개변수로 받게됨. decorator 패턴이었나. 해당 클래스를

 생성자를 통해 매개변수로 받아서 자신의 동일한 인터페이스로서 매개변수로 받은 그 클래스의 연산(기능)을 사용하는것.

 

-전보다는 쉽게 읽히긴 하는데.. 전체적인 클래스간 association은 너무 복잡함. Accesible, 스레드 동기화 syscronized

  등이 아직 명확치 않음.

 

-sun 사람들이 try catch를 어떤식으로 구현을 했는지 살펴보고.. 내가 느낀바에 따르면.. if(){ if(){ if(){} } } 식으로 점점

  중첩하는 방식이었음. 즉 1번 작업 수행을 try로 감싸고 catch 처리  2번 작업은 1번작업의 try내부에서 한번더 try catch

  처리 .. 식으로

 

-역시나 명확하게 감을 잡지 못하겠음.

 

4.svn(서브버전) 프로젝트 소스코드 관리 툴

 

-서버를 내 컴퓨터에서 설치후 관리하려 함

 

5.tomcat을 이용해 로컬 서버에 페이지(jsp) 띄워보기

 

-중고 서점에서 구한 jsp책.. 버전이 오래됐지만, 좋은 책이라고 선생님이 말씀해주셔서 뿌듯했음.

 

-톰캣 설치및 서버 실행까지 문제가 없었고, 지훈형님 도움으로 이클립스에 플러그인 설치함.

 

-문제는 디폴트 jsp파일을 자동으로 생성해서 서버를 실행했는데 계속해서 해당 파일을 찾을 수 없다는 404 에러 발생

(sol)문제는 jsp파일 실행시에 디폴트로 잡혀있는 j2ee preview localhost로  jsp파일을 실행했기 때문.

       내가 설치한 tomcat 7.0 server localhost로 실행을 해서 해결됨 (아무것도 아닌 문제로 약 1:30분 소요됨.)

 

-(중요)눈으로만 jsp 책을 읽는 것보다 이제부터 시간을 할애해 실습해볼 계획임

 

6.테스트 도구인 JUnit 사용해보기

 

-계기는 the c++ programing language 에서 클래스,메서드 등의 불변속성을 보던중

  (개인적으로 메서드에서 예외처리및 콜러,워커등의 관계 속에서 워커(호출된 메서드)의 책임 범위를

  어떻게 하는것이 옳은 것인지 몇일 전부터 고민했었기 때문)

  그것의 구현을 위한 방법중 하나인 단정문 assert()를 보다가 java에서 assert를 사용하기로 마음먹음

 

 -코드 테스트를 위해 assert를 사용했으나 (jvm실행 매개변수에 -ea) 

 선생님 말씀으론 테스트엔 JUnit을 사용한다는 조언을 듣고 바로 테스트해봄

 

 -프로젝트별,패키지별,클래스별,메소드별 단위테스트가 무척 간단해졌음. (메서드 선행조건,후행조건,불변속성

,클래스 선행조건,후행조건,불변속성, 각메서드별 수행 시간도 나오고.. 잘은 모르지만 자바의 annotation 도큐먼트

 태그를 이용해 스크립트처럼 테스트 처리가 가능한듯. 매우 만족. 언제 쫌더 파지..?)

 

7.현재 읽고 있는 책들,.. code complet2 , the c++ programing, web developer with javaserver pages, 자바의 정석은

 레퍼런스 북처럼 보고 있음. uml 책도 있긴 한데.. 도무지 시간도 없고.. 예전에 공부햇던 기억 + 우리 선생님이 수업

 시간에 짚어주시는 걸로 reminding.. 개발 관련 보고 싶고 알고 싶은것이 너무 많다..(목표 없는 지적 호기심 주의할것) 

 

8.집에 가서 계획: 가급적이면 code complet 1회 속독, c++ programing 너무 어렵고 디테일함.. 일단 봉인. + 각종 블로그

에서 디자인 패턴 공부

 

9.내일 할일:jsp 진행 , svn 진행, JUnit은 한동안 봉인, 예외처리에 머리싸매는 것도 일단 봉인, java awt 소스 코드중

  볼만한 메서드 2개 정도 분석, jsp 때문에 html,xml을 따로 학습할 필요는 없을듯함.(시간 부족) 글고.. 수업도 들어야지..

 

  아.. 여유 된다면, 오라클 12c는 포기하고 11버전으로 설치 + 연동 (콘솔창에서 오라클과 대화하는 명령문.. 몇일만에 머리

  속에서 증발했음.. 대책이 필요)   오라클 12c 설치된거 지우는 시간이 아까울지도;;;

 

10.윤팀장님과 게임developer 양성 과정 관해 아주 짧게 대화함. 팀장님도 바쁜일이 있으신듯.(연말 결산및 정리 땜에 내년 초에나 진행하실듯?) 내경우도 현재 여유는 없고..  흠.. 나중에 게임 개발 교육 기관및 커리큘럼등 경쟁자 조사및  게임 개발사 need 분석등의 간략 기획안 만들어서 보고하면..?

 

11.지훈이 형이 재미있는 아이디어를 두유 한잔에 내게 전해주셧음. 지훈이형 항상 고맙고.. 음..작별인사는 나중에 개별적으로

하지요~  best regard!

 

post script

시간 참 빨리가네..

by givingsheart 2014. 1. 1. 15:05

제가 여러 노트,수첩에 메모를 하는 것을 보신 분들도 계시리라 생각합니다. 이렇게 인터넷 상에 글을 남기는 목적은

여러분을 위함이 아닌, 저를 위함입니다.

 

 

이 글이 6개월의 과정중 1개월이 지난 시점에서 제가 무엇을 공부하고 고민했는지를 정리하고, 제가 공부하는 목표는 무엇인지

방향은 올바른지를 확인하기 위한 수단이자, 공개된 게시판에 글을 작성함으로서 나태해졌을때 스스로를 채찍질 하는 수단이

되길 바랍니다.

 

카페에 글을 쓰게된 계기와 그 한계, 한달간 공부한 것들, 앞으로 "가끔씩 시간이 나거나 or 필요성을 느낄 경우" 작성하게 될 글

들의 주제와 방향성 순서로 진행해봅니다.

 

1.카페에 글을 올리는 행위 = 제가 공부하며 이런 저런 생각들을 적어놓은 노트와 수첩들은 외부로 부터 객관적으로 검증및 인정

  을 못받습니다. 저를 외부에 알리는 수단인 동시에, 피드백을 받을 수 있을거라 기대합니다.

 

  강조하지만.. 제 어설프고 불완전한 지식을 65기수 여러분들과 나누고자 하는 목적이 아닙니다.

    a.저는 여러분을 도울 정도의 실력이 되지도 않을 뿐더러 책임질 의향도 없습니다. 제 코앞에 닥친 문제들은 점점 쌓여가고

     그것을 해결하기에도 시간이 벅찹니다.(저 역시 공부하러온 수강생입니다)

    b.우리 기수는 운좋게도 열정적이며 능력이 출중하신 김성환 선생님의 class 입니다. a에서 지적했듯 65기 수강 종료후 

     결과를 책임지는 몫은 첫번째는 학생 본인 자신이고, 두번째가 선생님입니다. 선생님의 관할과 책임 영역을 침범할 마음이

     전혀 없습니다. 저는 제 일만 책임지고 싶습니다.

    c.b와 연계되는데.. 제가 궁금하고 정리하고 싶은 부분에 대해 글을 작성할 것이지, 여러분이 궁금하고 정리가 필요한 부분

      을 정리하지 않을 것입니다. 저는 학생이지 교육자가 아니기 때문입니다.

    d.한편으론 글을 통해 몇몇 분들과 서로 win-win할수 있는 관계가 되기를 바랍니다. 人間은 혼자서 할수 있는 일에 한계가

      있음을 알기 때문입니다.

 

2.제가 공부하는 스타일과 한달간 제게 일어난 여러 문제에 대해 두서 없이 요약해 봅니다. (경고: 저는 1~2줄의 코드에 수십줄의

주석을 붙이는 사람입니다.)

 

     a.저는 이번 과정을 들으면서 선생님이 분기 제어문법(if,else if,switch등) 반복 제어문법(for,while등)의 수업을 진행

       하시면, 저는 그것으로 무얼 만들수 있을까를 고민했으며, 사용자의 입력을 처리하는 방법을 찾아서 '업다운 게임'을

       만들어 보자고 목표를 세웠고 빠르게 만들어 낼 수 있었습니다.

 

      "배운 개념을 바로바로 프로젝트로 적용->응용->확장시켜 다른 사람이 쓸수 있는 서비스적 가치를 창조한다"  <-- 중요

       하다고 느끼면서도 막상 공부중에 실천하긴 어려운 과제라고 생각합니다.

 

     b.2주 전인가.. 지희와 점심 식사중 게임 얘기가 나와서 콘솔 기반 입출력의 2차원 배열을 이용해 몬스터를 피해 골인 지점

        을 들어가는 아주 간단한 게임을 만들어본 경험도 있습니다. (객체지향x 막코딩)

   

     c.팀간 주제'쇼핑몰,극장등' 팀 발표자를 뽑기 위해 인터넷상 사다리 게임을 한적이 있습니다. 저는 그때 사다리 게임을 내부

        적으로 어떻게 구현을 해놨을까를 혼자 스케치 해보았습니다. (구현x)

 

     d.몇주전에 로또 프로젝트를 시작하게 된 계기도 단순했습니다. 선생님께서 Math.random()을 가르쳐 주셨고

        저는 어떻게 응용할까 고민하다 로또 번호를 생각 하였으며, 그럼으로 임의의 중복되지 않는 숫자열을 만드는 메서드를

        구현하였습니다. 그리고 실제 로또 추첨이 공바구니에서 1~45 숫자가 적힌 공을 넣고 하나씩 뽑아내는 과정을 유사하게

        구현하였습니다. (즉 중복되지 않는 숫자열을 만드는 다양한 방법중 한가지 방법을 채택)

 

        다음 단계는 실제 현실에서 사람들이 로또를 어떤식으로 하게되는지를 떠올려 보았으며(물론 시장조사는 하지 않고..)  

 

        로또 판매점에 간다->용지를 산다->번호를 기입한다->기입한 용지를 제출한다->특정 시점에 당첨 번호를 추첨한다 ->

        당첨 결과를 확인한다.->당첨되었다면 당첨금을 수령한다  

       

        처럼 일련의 과정을 각각 모듈별로 구현을 했었습니다. 이 과정은 콘솔을 기반해 구현을 하였으나, 유저의 입력과 그에

        대한 처리 로직과 그것을 유저에게 콘솔로서 보여주는 화면 처리 모듈들이 짬뽕이 되어 버려 결국 중단을 하였습니다. 

       

         (SceneManager, InputManager, DrawManager, LottoNumbers, LottoNumbersDeck, User, UsersManager..

         ,Customer,LottoMachin 등등 설계를 계속적으로 변경하면서 수많은 클래스들과 구현 코드..들이 버려졌습니다.)

 

        한마디로 하등 쓰잘데기 없는 콘솔 ui 기반으로, 클래스간 각각의 역할 구분도 모호할 뿐더러 mvc 개념이 구분 되지 못해

        입력처리,화면처리,데이터처리등이 엉망으로 꼬여버린 로직과 어떻게든 마무리를 해보려 할수록 점점 꼬여가는 코드들..

        그에 따라 지수 함수 처럼 시간소요는 늘어가고..

 

        물론 프로젝트가 잘 풀렸다면, 아마도 그 다음 단계는 웹에 로또 사이트를 개설하고 회원 가입, 이번주 로또 하기(구입+숫

        자결정+제출), 그동안의 당첨 결과 데이터를 활용해 분석및 통계하기, 자동으로 로또 번호 받기, 회원 기록 보관(파일orDB)

        등의 서비스적 가치로 확장이 되었겠지요.

        

        제게 웹 기반 기술은 없었기에 desk탑 전용이지만, 나름 서버의 역할인 로또 가게 모듈, 클라이언트 역할인 유저 모듈등을

        구현하는 도중이었고, 회원 가입시 입력처리를 '정규식'을 통해 처리를 해보려고 정규식을 반나절 정도 짧게 공부하였으며,

        유저의 현재 상태를 서버에서 .txt 파일로 java.io 클래스의 인풋,아웃풋 스트림 클래스를 통해 입,출력하는 모듈도 구현을 

        했었습니다. (다음번엔 nio패키지를 이용해볼 계획입니다.)

 

        물론 제가 관리할 데이터를 어떤 자료형을 사용해 다루어야 할까도 고민했고 결과로 나온것이 추후에 배우게될 java.util의

        제네릭 or 템플릿 컬렉션 클래스인 HashMap<String,HashMap<String,ArrayList<LottoNumbers>>> 가 되었고..  다른

        간단한? 컨테이너와는 조금 다른 해쉬맵 컨테이너의 사용 때문에 조금 애를 먹었었습니다. (entry_set의 의미가 이해가 안

        되던 상황이라..) 그후 컨테이너 클래스의 편안함에 빠져 Animal형 이런저런 컨테이너를 사용해 개,호랑이,코알라등 다양

        하게 집어넣고 관리할 수 있었습니다. (별론으로 반복자 iterator의 사용은 해당 요소에 접근해서 한번에 여러가지 작업을

        수행할 경우 임시 참조 변수에 저장후 처리를 해야하는 번거로움이 있다고 느꼈지만, 설계자들이 필요성이 없으니 반복자

        에게 현재 요소의 참조 값을 가르키게 하지 않았겠지요.(next()와 previous()만 존재..)  이와 유사한 것이 for(int i=0; i<le

        ngth; i++)  vs for(int a : intArray)  vs while(Interator<Integer>.hasNext()) 의 차이였습니다. 향상된 for, 반복자를 이용한

        while 둘다 코드는 깔끔해지지만, 제약이 존재했습니다.)

 

        다시 본론으로 돌아와 추후 지훈 형님이 학생 수준 습작에 만족하냐며 조언해주셨기에 db에 데이터를 넣었다가 빼본다고

        oracle12c 버전을 설치및 연동하는 작업을 인터넷을 찾아보며 시작했으나, 삽질이 연속되고 오라클 설치와 사용에 대한 경

        험및 개념부족으로 약 하루(24시간)정도 좌절을 겪은후 봉인했습니다. 11 버전으로 깔면 간단할 것 같은데.. 11버전과 12버

        전에서 아키텍처상 큰 변화가 있다는 기사를 접하곤 더더욱 12c 버전에 몰입했었던 기억이 납니다. (물론 업체들은 10 or

        11버전을 많이 쓰리라 추측하지만.. 12를 뚤어내면 다 잘 풀릴것이란 막연한 기대감에..) 다음주~다다음주 쯤에 우리 클래

        스도 선생님의 진두지휘 하에 설치를 해보겠지요..(우리반 진도가 계획 일정보다 늦어지는것 같다는 느낌은 제 착각일까

        요?)

 

 

       d2.위에서 짧게 거론한 do,vo,dto,dao.. 우리가 수업시간에 선생님으로 부터 배운 개념입니다. 저는 익숙치도 않았을 뿐더

        러 도메인 오브젝트의 정의가 비지니스 로직(서비스)과 다른 개념인지를 알지 못했고 웹 검색을 통해 do,vo,dto,dao,pojo

        등의 생소한 용어와 개념의 설명을 찾아 보았지만, 역시나 명확한 한가지의 정의는 없었습니다. 아직도 제 머릿 속은 뒤죽

        박죽입니다. (클라이언트측 do는 vo+업무로직 , 서버측 do는 dao + sql로 간략히 정리했는데.. 확신도 안서고 혼란스럽습

        니다;;)

 

        아참..do를 구현할때 저는 데이터의 완결성?무결성?을 보장하기 위해 모든 멤버필드를 가지는 생성자만 필요하지, 디폴트

        생성자는 필요 없을 것이라 판단하였는데.. 선생님은 관례적으로 디폴트 생성자도 포함해야 한다고 말씀해주셨고, 그 부분

        에 의문을 품은 저는 추후에 이런저런 검색을 해보다 다른 프레임워크(스프링워크였는지 기억 확실치 않음)에서 reflect를

        이용해 객체를 생성하고 초기화 할때, 디폴트 생성자로 생성을 하고 setter로 인스턴스 필드를 초기화 하기 때문에 디폴트

        생성자가 필요하다. 식으로 찾아본 기억도 있습니다. 제 경운 부가적으로 로또 번호란 vo 클래스를 설계하고 생성자를

        구현하던중 모든 필드의 파라메터를 받는 생성자의 경우 매개 변수의 유효성을 생성자 측에서 검증해야 하는지, 생성자를

        호출하는 외부에서 검증해야 하는지에 대해서도 의문을 갖게 되었습니다. 저는 생성자 내부에서 isValidParameter() 식

        으로 검증을 하는 걸로 구현을 했었지요.(책임의 소재를 콜러쪽에 둘것인가 워커쪽에 둘것인가.. 확실한 기준이 안설뿐더러

        메서드로 유효성을 체크한후 그것을 콜러쪽에 알려야 할것인지에 대해서도 확실치 않습니다. 공부할 수록 모르는게 많아

        집니다.)

 

        이 정보를 파고 들다가 spring 프레임웍 중 일부인 Dependancy Injection 문제를 접하게 되었고 -> java.lang의 class

        <T>와  값&객체를 의미하는 Object 자료형, 동작을 의미하는 Method 자료형, 데이터 타입을 의미하는 Class<?> 자료형

        의 의미, 더불어 java.lang.reflect 패키지의 역할에 대해 접근하게 되었고 추후 제 정신은 또 한번 안드로메다로 날아가버립

        니다. (제가 잡은 개념이 맞는진 모르지만.. 지금까지 클래스라는 것을 쪼갤수 없는 하나의 의미 단위로 생각했는데.. clas

        s 란 단위도 전부 쪼개져서 외부(파일or네트워크)를 통해 객체를 생성하고 객체간의 관계(resolve = 상속및,association등

        )을 연결짓고 필요한 연산을 수행할수 있다니.. 2013.11.21~22 이틀에 걸쳐 이해및 테스트 해보려 했으나, 간략하게 문자열

        을 통해서 객체를 생성하고 메서드를 수행시키는 정도만 겨우겨우 성공했습니다. 혼자서 api문서만 보고 구현하려 했으나..

        너무 어려워서 다른 분들의 블로그 참고했으며.. AccessibleObject니 ReflectPermission, Proxy등은 당장은 이해를 포기했

        습니다;;) 프레임 워크에서 말하는 layer란 개념도 이해를 못한 상태입니다.

 

        2013.11.22 어제 선생님이 modifier를 설명해주셨고 역할에 따라 acess, usage로 구분을 해주셨으며.. 칠판에 jvm메모리

        구조를 그려가며 static 키워드가 붙었을때와 아닐때 메모리에 올라가는 시점의 차이를 말씀해주셨습니다. 제가 중간에

        "생성자의 코드 정보는 어느 시점(클래스 로딩or인스턴스 로딩)에 메모리에 올라가나요"란 괴상한 질문을 던졌던 이유도

        reflecte를 이용한 객체 생성과 관련 있었습니다.

 

        reflecte 개념을 통해 1.클래스 로더->2.문자열 통해 클래스 객체 얻기->3.클래스의 생성자 객체 얻기->4.생성자 객체의

        newInstance()를 통해 실제 객체 얻기 ->5.클래스에 정의된 메서드 객체들 전부 얻기 -> 6.invoke로 메서드 실행하기

        의 과정에서 클래스 정의에 대한 정보는 메모리에 있다지만, 생성자의 구현 정보는 일반 인스턴스 메서드 처럼 객체 생성

        후에야 정보가 메모리에 올라갈테니 3의 과정이 불가능하지 않을까란 의문에서 여쭤본 것이었습니다;;  제 생각대로 라면,

       

        2.클래스 정보를 얻은후 3.클래스 정보를 토대로 newInstance() 수행해 객체를 메모리에 할당해야 4.생성자 정보를 얻을수

        있다 라고 생각했기때문입니다.. (내용이 점점 길어질까 고민되고 스스로 혼란스러워 reflect는 이만 줄입니다.)

 

       아.. 문득 우리 선생님께 감사를 드리고 싶은게.. 쉽게 개념을 이해시켜 주시려고 추상적으로 설명도 해주시지만, 디테일한

       부분도 집어주시고, 경험에서 녹아나는 이런저런 노하우도 틈틈히 말씀해주시고, uml 클래스 다이어그램 또한 살짝이나마

       집어주시니.. 그저 너무너무 감사하고 고마운 마음 뿐입니다. 학생별 수준을 고려해주시고, 교과 과정을 진행하시느라

       얼마나 고민을 많이 하실테며, 힘이 드실지 감히 짐작해 봅니다. 그럼에도 항상 학생들과 눈높이를 맞춰 농담도 주고 받으

       시는 겸손하신 모습을 보며 많은걸 느끼고 있습니다. 앞으론 제가 무지 몽매한 질문으로 선생님의 강의 의도와 흐름을 끊지

       않도록 조심하겠습니다. 그간의 민폐 용서해주시고 많이 많이 가르쳐주세요.  -선생님께 감사및 사과 끝-

      

       

       d3.생뚱 맞지만 다시 본론으로 돌아와서.. 어느순간 저는 제가 하는 프로젝트와 현업과의 괴리감을 느꼈고 지도와 나침반을

       꺼내 현재 제가 공부하는 위치를 확인하고 싶은 욕구가 생겼습니다.

 

       유저의 웹 브라우저 부터 서비스 제공업체(개발사) 사이에 어떤 기술적인 부분들이 들어 있을까? 에 대해 알고 싶었습니다.

       applet,html,,xml,asp,php, ajax, web server, web app, java script, jsp, servlet, tomcat, java bean, ibatis,jdbc, sping,

       struts2,hadoop,rinux, oracle, apach, phone gap ,css, hibenate? 등등 용어들도 생소해서 혼자서 약간이나마 용어들에

       대해 이해하고, 전체적인 그림을 그려보려 노력했습니다.

 

       (잡사이트에서 구직자 필요 기술란들을 검색해보면 연관 기술이 테크트리 처럼 목록화 되어 있습니다. 웹,서버,클라이언

        트,db,모바일,보안등 분야를 선택해 집중하더라도.. 시장에서 뜨는 기술이 뭔지, 내가 만들고픈 서비스는 전체적으로 어떻

        게 구성이 되는지를 알고 있으면 손해는 아니라고 생각합니다. 지훈 형님께서 지식을 나눠주셨기에.. 다시 한번 감사드립니

        다.)

 

        e.다시 로또 프로젝트로 넘어와서.. 건들수록 꼬여만 가는 프로젝트를 잠시 중단하고 왜 내 코드가 이렇게 엉망이(if else

        + 중복된 switch + 각종 조건식) 되어가는지 고민을 해보고 정보를 찾아 보았습니다. 어설프게 귀에만 익숙하던 mvc 모델

        링 개념이 부족해서 일까? 아니면 사용자 입력및 예외처리, 사용자의 상태별 화면처리(scene 컨트롤) 로직이 컨트롤단

        한군데에 몰려있어서 복잡해진건지.. (mvc중 v와c단이 엉킴)

       

        기존에 만들어둔 Scene(화면 클래스) 내부의 각각의 메뉴와 인터페이스들을 모두 클래스로 만들어 사용자와 interaction

        하는 부분 클래스는 메세지를 발생시키고 그것은 입력처리용 클래스가 맡아서 각각의 처리 로직으로 분배하고.. (지금

        생각해보면 이것이 awt컴포넌트에서 사용자 이벤트를 처리할때의 방식인 옵저버(구독,발행)패턴(내가 정의한 핸들러(리스

        너)를 이벤트 풀에 등록하면 이벤트 발생시 알아서 콜백되는)과 유사한 고민 이었습니다. 윈도우의 메세지 처리방식도 이와

        같지요) ( 물론 awt의 경우 각종 컴포넌트,리스너,툴킷,메세지큐,메세지 처리및 그리기 관련 작업 스레드,이벤트 클래스,이

        벤트 멀티캐스터등.. 상속 계층 구조는 기본이고, 디자인 패턴까지.. 파고 들면.. 심하게 복잡합니다.)

 

        고민해도 명확하게 풀리지 않으니.. 로또 프로젝트를 잠시 접어두고 저는 디자인 패턴 관련 자료들을 조금씩 맛을 보면서,

        동시에 저를 괴롭힌 콘솔 기반 ui를 떠나 , 자바에서 지원하는 awt라는 패키지를 이용해 gui를 공부해보게 되었습니다.

 

        =>이 부분부터 제가 말리기 시작합니다. 개념을 눈과 머리로 받아들이기는 쉽지만, 그것을 이해하고 응용력을 키우기위해

        시간이 걸리더라도 실제 저의 로또 프로젝트에 계속해서 적용을 시켰어야 했습니다. 조급한 마음과 지적 호기심에 지식만

        채워 넣고 부분별로 테스트 코드만 만들어 놓다보니, 이제와서 제가 공부했던 개념들을 프로젝트에 한꺼번에 적용시켜 보

        려 했더니 설계단부터 꽉 막혀있습니다. (처음부터 완벽하게 만들고 싶다는 강박증에 도무지 진행이 되질 않습니다;;)

 

        그래서 복잡해진 로또는 잠시 접고 선생님이 다형성 개념을 잡아주시기 위해 사용하신 동물 농장을 간단하게 동물 관리

        도메인 부터 시작해서, 동물원 관리및 경영 도메인으로 확장(고객,직원,동물,업무들이 포함되는 동물원 관리 프로그램)

        시켜 보겠다는 원대한 포부로 어제부터(11.22) 작업을 시작하던 도중.. 몇몇 이유로 하루만에  동물농장 프로젝트도 중단

        시켰습니다. (다음번 개인 프로젝트 진행시엔..어느정도 기반이 마련된 sun에서 제공해주는 sample 소스코드를 다운 받아

        서 그걸로 진행 시켜볼까 고민중입니다.)

 

        그저께 부터 진행된 동물 농장 프로젝트... 처음에는 장난식으로 Animal이란 상속 계층에서 몇몇 동물에게만 FightAble이

        란 interface를 만들어 상속시킨후 혼자 키득키득 거려가며 동물끼리 싸움을 붙이는 전투 시스템을 구현했었습니다.

        (ex) manager.fight("멍멍이1","코알라1"); "코알라완 싸울수 없습니다" (FightAble이란 인터페이스 덕분에 boolean is

        FightAble 같은 멤버 필드의 추가및 전투 관련 메소드를 코알라 클래스에 추가할 필요가 없었습니다.)..  manager.fight("멍

        멍이1","호랑이1"); -> "멍멍이1이 호랑이 1에게 10의 데미지를 입혔습니다." "호랑이 hp40" (반복).. "호랑이가 죽었습니

        다."....

 

        그러다가 공부했던 reflect를 이용해 동물의 생성과 행위를 스크립트처럼 txt에 담은 문자열을 파일에서 읽어와 제어해보자

        는 욕심이 생겼고.. 또 한번 이런저런 시행착오를 겪게 되었던 비하인드 스토리도 있습니다.

 

 

        f.awt를 접하는 본론으로 돌아와서.. 제 경운 윈도우 api를 공부 했던 오래전 경험을 통해 awt의 각종 컴포넌트들, 메세지

        처리 방식엔 쉽게 접근할수 있었습니다.

 

        문제는 제가 디자인 패턴을 awt와 동시에 공부하던중 brigde패턴을 보게 되었고, 그 문서에서 하필 자바의 awt의 컴포넌트

        클래스와 툴킷 클래스를 예로 들어 주었습니다.(이때부터 저는 제정신이 아니게 됩니다.)

 

        몇몇 분은 제가 칠판에 한가득 컴포넌트 클래스와 연관 클래스들을 클래스 다이어그램으로 서로간 관계(association,agree

        gation,composition)및 디자인 패턴을 그려 놓은것을 보셨을 것입니다. awt패키지및 관련 패키지들의 중요 클래스들의 관

        계를 허접하게 나마 정리했지만.. 보고 또 봐도 어렵습니다. (native api를 지원하는 툴킷이란 팩토리 클래스 때문에 전체적

        으로 엄청 복잡해졌습니다.  awt의 api 소스 코드들도 끝장을 보자는 마음으로 파고들고, 소스 코드가 없다면 grepcode.co

        m 을 통해 코어적인 설계와 구현을 간략하게 나마 확인 하였지만.. 복잡도가 너무 심해져 대부분 이해는 못했다고 판단됩니

        다. (언제가 될진 모르겠지만, 한번 모든 소스를 종이로 출력해서 주석을 달아가며 뽀개버리고 싶은 강렬한 충동이 있습니

        다.)

 

        맞는지는 모르겠지만, 일단 저는 component클래스와 toolkit클래스란 추상 클래스 단에서 브릿지 패턴이 적용되는 것을

        확인하였으며, 각종 리스너 클래스중 그것을 상속해 간단하게 사용하게끔 해준 어댑터 클래스(인터페이스적 의미)를 확

        인하였으며, 코드의 곳곳에서 클래스 내부에 return new (){구현}식의 익명 클래스를 통해 구현한 어댑터 패턴을 확인하

        였고, 어떤 클래스인지 이름은 잘 기억이 안나는데 command 패턴과 위임 패턴및 툴킷이란 추상 팩토리 클래스도 확인을

        했습니다. awt이벤트멀티캐스터라는 클래스는 각 리스너들과 구독&발행이란 옵저버 패턴을 사용하고 있었고..

        

        component클래스와 다른 클래스들이 어떤 식으로 associacion or agreegation or composition 하는 지를 확인하려 노력

        했습니다. (각 클래스들은 추상 클래스단(상위 클래스)에서 서로간 관계를 맺고 실제 디테일한 구현은 하위 클래스에게

        넘깁니다.)

 

        =>실제로 제 프로젝트는 설계 관련해 디자인 패턴을 고민할 정도로 복잡하진 않았고 그 결과 저의 고민도 대단치 않았습

        니다. 결국 제가 프로젝트를 만들어가며 mvc, 이벤트 처리를 위한 옵저버 패턴 정도를  제외하면 다른 디자인 패턴의 경우

        필요성을 크게 느끼지 못했고.. 그 결과로 아직도 여러 패턴들및 개념이 낯설고 막연하게만 느껴집니다. (고객의 요구사항

        변경으로 밤새 클래스를 뜯어 고쳐봐야 그때쯤 "아~ 디자인 패턴이 무엇을 지향하는지" "선배 개발자들이 무엇을 회피하고

        자 설계를 강조했는지"를 체감할 것 같습니다.)

 

        여기서 잠깐 a와 b 클래스가 있을때, 클래스간 관계를 구분해 보면

         1.a가 b의 메서드를 사용한다. (association)

         2.a는 b를 포함한다. (agreegation <-> composition 은 개념상 b가 a를 떠나 독립적으로 생존이 가능한 개념인지 여부에

                                      따라 구분하며 agreegation의 경우 a의 생성자의 매개변수로 b를 받게끔 구현하는 것이 논리적으로

                                      옳다. composition의 경운 생성과 소멸을 함께 하는 부분의 개념임으로 a의 생성자에서 b를 생성하

                                      는것이 옳다. 음.. 대략적인 개요를 목적으로 한 글인데.. 너무 디테일하게 접근이 되네요. 선생님이

                                      수업중 말씀해주신 많은 개념에 + 제가 개인적으로 찾아보는 개념들까지 포함이 되려하니.. 지금

                                      부턴 가급적 일부분만 간략히 정리 합니다.)

         3.a는 b를 관리한다. (1vsN 관계의 manager클래스로서 배열등 컨테이너를 통해 b들을 관리=생성,삭제,조회,수정)

         4.a와 b는 상속 관계이다. (트리 형태의 계층구조)

         5.a는 b의 설계 개념이다. (추상클래스,인터페이스등) -> a가 b의 인터페이스이고 b가 a에 대한 구현이라면 콜러(사용자)

                                                                                      쪽에서 는 a만 알면 될뿐 a의 내부 구현이 b인지, b'인지는 중요

                                                                                      치 않다.

 

         etc. 인터페이스와 상속의 차이점은..흠.. 전체 계층구조를 잡는것은 상속 트리, 전체 계층 구조중 서로 다른 집단간에

         공통성을 부여할땐 인터페이스 설계적인 부분은 추상 클래스와 인터페이스.. 인터페이스를 서로 다른 클래스간 관계

         (association)및 의존성(dependancy)을 줄이거나 ,이미 구현된 코드를 수정하지 않고 사용하고 싶을 경우 인터페이스를

         implements해서 메서드들을 재정의 해버리거나or 새로운 클래스가 implements해서 클래스간 중재역할(어댑터)로 감을

         잡아 두는것이..? 인터페이스란 용어가 두가지 의미(설계적인 개념, 다형성을 통해 외부와 유연한 관계성을 만들기 위한

         창구)를 가지고 있는듯 느낀다. <-- 오류같음

 

         인터페이스건 상속이건 공통점을 묶어서 그룹화해 3의 경우처럼 관리를 쉽게 해주며, 또한 인터페이스의 가장 큰 장점을

         다시 한번 생각해보면.. 프로그램을 간단하게 일반 유저에게 배포되는 클라이언트, 우리 개발자들이 작업하는 서버측으로

         나눠본다면, 서버가 관계 개념인 인터페이스만 노출해주면 클라는 인터페이스의 내부 구현이 a이던 b로 바꼇든 상관없이

         기존 코드로서 사용이 가능하다. (맞나..? 실제 프로젝트에 적용을 안해봤더니.. 개념만 붕 뜬 상태..)

                 

         "개념&역할 별로 클래스를 잘게 쪼개서 역할과 책임 영역을 만든다" "설계와 구현을 분리한다" "설계 클래스단 간의

         관계는 구현단 및 그것을 상속 받는 하위 클래스에도 적용이 된다=패턴" "공통된 부분을 추상단위(추상클래스)로 꺼내서

         관리 하는게 클래스의 변경및 확장에서 유연하다" "클래스간 관계에서는 다이렉트보다 어댑터 클래스를 중간에 사용하는

         것이  클래스간 의존을 줄여준다"  기타 등등 

 

         선생님이 5번쯤 강조하신 다형성의 장점은 디자인 패턴을 구현하는데 있어 가장 중요한 개념이라고 생각한다.

        

         물론 다형성이란 개념=동적으로 객체의 타입 식별및 바인딩 이 없었더라면.. 상위 클래스의 참조형으로 a(base)라는

         메서드를 호출시 하위 클래스들 고유의 a(child1) a(child2)가 실행되지 않고 오직 상위클래스의 a()만이 수행될 것이다.

         물론 instanceof 연산자를 통한 형변환 안정성 체크도 불가능하고.. 상속계층에 포함되는 모든 클래스.. 자바의 경운 말

         그대로 Object 클래스에서 파생한 모든 클래스.. 는 rtti클래스(클래스 이름,부모클래스 참조)를 숨은 필드로 갖고 있으며

         그 클래스가 instanceof, reflect 구현 하며 사용해본 Type type = Object.class 란 연산자를 지원하는듯 하다.

 

         모든 클래스에 .class 란게 제공되길래.. 도큐먼트에서 찾아보려 했지만 실패했었다. 지금 생각해보니 rtti관련 실제 타입

         정보,상위클래스 여부등의 정보를 담는 내부 클래스가 모든 클래스에 숨겨져 있는것 같다. 자바도 c++처럼 rtti를 구현

         했을지는 의문이다. 추가로 인터페이스 클래스의 경운 Object를 상속받지 않았는데 어떤식으로 rtti가 되는 것인진..?

        

 

         =>제 머리속이 너무 산만하여 글의 주제와 내용이 산으로,바다로,강으로 널뛰고 있지만, 제가 약 한달동안 학원 생활을 하

            며 다뤄 본것들, 배움을 통해 머리속에 채워넣은 것들을 reminding 하다 보니.. 어쩔수가 없습니다.

       

      f.아참..개인적으로 예외처리 부분도 고민을 했었습니다. 견고하고 간결한 코드를 만드는게 제 목표입니다. 제가 특정 모듈을

       구현 했을때 그내부에선 다양한 java.api 메서드를 사용했으며, 반 강제적으로 예외 처리를 해줘야 하는 경우도 있었습니다.

       (해당 메서드가 throws선언시) 

 

       외부의 입력값이 허용범위가 아닐때.. 그것에 대한 처리를 제가 만든 메서드 내부에서 해야할지 (try,catch) 혹은 제 메서드

       를 호출해서 잘못된 파라메터or 참조를 넘긴 콜러쪽에 throw new exception 해줘야 할지.. 아직도 모호하지만..제 결론은..

       java.api가 내뱉는 throw는 제 메서드(콜러) 안에서 처리하고 제 메서드에 잘못된 파라미터가 전해졌을땐, 제 메서드(워커)

       가 저를 호출한 쪽에 예외를 처리하도록 throw new xxx 시키자고 정책을 잡았습니다. 예외 처리의 책임소재;; 제 생각보다

       훨씬 복잡한 주제라 생각해봅니다.

       

      g.제가 한달간 접해본 지식들은 이게 전부가 아니지만, 기억에 남는건 겨우 요정도네요;;

 

3.앞으로 다룰 주제 영역의 방향성과 방법에 대해..

 

   앞으로 다룰 주제에서 프로그래밍의 기본적인 문법, 알고리즘, 자료구조등은 제 관심 영역 밖입니다. 올바른 프로그래밍에

   대한 고민, 각종 프레임 워크, 네트워크 관련, db관련, 웹관련, 모바일관련, 보안관련중 제가 꽂히는 부분을 평소처럼 온갖

   노트에 낙서질 해가며 공부할 것이며 특정 부분을 카페에 올려서 정리해야 겠다는 필요성이 생기고 시간이 허락하면 새롭게

   글들을 남기겠습니다. (대략적인 구성은 특정 주제에 대해 소주제로 한번더 쪼개고 what, why, how, 관계된 개념들 식으로

   정리할 것 같지만.. 제 성향과 기질상 어떤 결과물이 나올진 장담을 못합니다.)

 

   오늘은 이런저런 포커스를 다루다 보니.. 글이 엉망인데.. 다음번에 하나의 주제를 정해서 파고들면 한결 나아지지 않을까 라는

   막연한 희망을 품어봅니다.

 

4.기타

 

   a.교육후 오후 6시 부터 개별적으로 추가 공부를 하고 있는데, 제 기준에선 강의실이 너무 소란스럽습니다. 저는 방과후 

   강의실 내부가 조용한 독서실 처럼 유지되길 희망합니다. 소란스러워서 집중력이 떨어지기 때문입니다. 저 또한 조심할테니

   사회인으로서 예의는 알아서 지킵시다.

 

   서로간에 대화가 필요한 스터디등은 휴게실에 노트와 연필을 들고 가서 토론하며 풀어 냈으면 합니다. 개인적으로 알고리즘

   등 문제 풀이를 해결할때 컴퓨터와 이클립스는 필요 없다고 생각합니다. 컴퓨터는 프로젝트 작업용 or 정보 검색용 or 머리나

   노트에 정리해둔 결과를 확인하는 용도로서 충분하다고 생각하기 때문입니다.(예전에 제가 다녔던 전산학원엔 컴퓨터가 없

   었고 별문제가 없었습니다.)

 

   b.2013.11.22 회식중 윤팀장님, 박대리님께 주말에 공부하고 싶은 학생들을 위해 강의실을 오픈할 수 있는지를 문의해 보았고

   5명 이상(박대리님 조건) & 주말에 다른 강좌가 있어야 한다(윤팀장님 조건)  2가지 조건이 충족될 경우에 한해 수락을 받았습

   니다. 집에서 학습 능률이 떨어지는 분들끼리 5명 모이면 이용할 수 있음을 전해드립니다. (회식자리 였지만, 윤팀장님께선 공

   부하곘다는 학생들을 적극적으로 지원해주시겠다고 말씀해주셨기에 감사하기도 하고 든든합니다.)

 

   c.글을 써놓고 한번 쭉 읽어보니.. 제 시각에선 약 한달간 있었던 이야기들을 짧은 파노라마도 틀어놓은것 같지만, 타인이 보기

   엔 참으로 난잡할듯 합니다. 이런 글 마음에 들진 않지만 더이상 시간 붓기도 아깝기에 올립니다.

  

   뭐 한것도 없는데 시간이 빨리 흘러가네요. 다음주에 봅시다. 굿나잇!

 

post script

 

1.지피지기(현재 내 상태를 알고 목표 수립후 상대에 맞춰 방향을 틀고 준비하는 일련의 과정들)

2.공부는 선택이다(목표를 잃은 공부는 자기 만족=지적 유희일뿐 시간 낭비이다. 공부는 수단이지 목표가 아니다.)

a.취업,창업이 목표라면 공부의 방향 설정을 현재 시장(회사&소비자)의 needs에 맞출것.(전략적인 사고)

b.취업(돈)or자기적성에 따라 세부 분야를 결정한후, 시장이 필요로 하는 부분에 대해 남들보다 앞서는 기술력을 개발.

= 다시 한번 지훈이 형님께 감사를 전합니다. '칭찬과 장단 맞춰주는 것이 아닌 건설적인 비판과 채찍질'이야 말로 상대를

진정 위하는 것임을 알기 때문입니다. (win-win할수 있는 관계가 되길.. 표현이 너무 딱딱한가요?)




*********************************************************************************************


좌절.... 학생들중 아무도 미래, 다가올 현실에 고민하지 않고, 함께 문제를 풀어내려 하지 않는다. 진지하지 못하다.

외로움을 느낀다.


<2013.12.1 현재 it업계의 전반적인 issue&needs에 대해 선생님과 학생들이 논의를 해보면 어떨까요 추가>


"목표가 없는 공부는 시간 낭비일 뿐이다." "전략적으로 행동할것" "전략의 기본은 올바른 정보의 획득부터"

 

지훈 형님께서 제게 가르침을 주시길 "모바일,보안,DB쪽"이 강세일 것이라 말씀해 주셨습니다.

(보안쪽 시장과 비전 관련해 우성(제?재?)군과 잠시 얘기를 나눴는데.. 교수님을 통해 정보를 얻을 수 있다는 얘기만

있었고.. 그뒤론 무소식입니다.  ^^;)

 

오늘 아침에도 혼자서 잡사이트를 찾아보며.. 정보를 획득하고 분석을 하려했지만, 제가 무지몽매하여 바른 길을

못찾겠습니다.(접근및 분석방법에 대한 고민) 

 

개인적으로 올바른 정보 수집 & 많은 양의 정보 수집 & 여러명이 의견을 모아 가급적 정확한 결론을 도출할

필요성과 그 "방법론"에 대해 고민을 느꼈습니다. 물론 이 문제에 대해 저만 고민을 하고 있는것이 아닐테지요..

 

물론 우리가 듣고 있는 수업 과정의 개요는 아래와 같지만.. "자바 개발자"에 대한 포섭 범위가 정확치 않습니다.

(ex)현업에서 필요로 하는(erp,mobile)? 자바 엔지니어 양성..

 

<교육개요>

현재 IT에서 가장 각광받는 java Technology의 기초부터 고급기술까지 학습합니다

전자정부 프레임워크(java opensource framework)를 이용한 Enterprise Solution 설계 및 구현과 

안드로이드 및 하이브리드앱을 이용한 모바일 애플리케이션 구현을 학습하고 실무 프로젝트를 통해

"현업에서 필요로 하는 자바 엔지니어 양성"을 목표로 합니다.

 

***********************************************************************

그렇기에 65기 학생분들중 관심있는 분들과 선생님께 감히 안건을 발의 합니다.

 

1.현재 시장(it업계중 자바쪽)의 수요가 어떠한지

2.구체적 분야별 비전은 어떠한지(ex)웹,보안,si&sm,erp,db,server,mobile,security 등등등등..

3.개인별로 어떤 부분을 준비하고, 개발시켜야 할지

 

4. 1~3및 기타 안건에 대해 학생들간 정보 공유및 브레인 스토밍을 통한 결과 도출

5. 4에 관하여 우리 선생님 + 주변 지인등 현업에 종사하는 인맥을 통해 양질의 피드백 받기

 

목표는 네이버 지식in등에 널린 쓰레기,상업적 정보가 아닌 고급 정보를 획득함 입니다.

************************************************************************

 

 

ps.우리65기는 서로간 경쟁보단, 함께 머리를 싸매고 힘을 합쳐서 5개월 후에 "확실히" 다가오는

취업or창업의 난관을 현명하게 뚤어냈으면 합니다.

 

(혹시 저만 쏙 뺴놓고 이미 이런 과정을 하시는건 아니겠죠 ^^? )



***************************************************************************************


의지가 되고, 함께 공부에 매진하던 지훈이 형님은... 가셨다..

혼자 공부하고, 앞서나가다가 왕따가 되버렸음.. 하하.. 사법시험 생활과 똑같구나.. 이젠 안 말린다.

(공부 열심히 하고, 공부한 것을 나누고 공유하려 했으며, 동생들과 함께 하고자 했던.. 내 노력들..

그래도 더 참아 봐야겠다)


<2014.1.9 하핫 술취해서 그런가>


 제가 잘할께여 여러분! 이쁘게 봐주셈!!!


오늘 많이 배웠고 많이 감사해여!!!


사랑합니닷!!! 홧팅!!



ps.글고 제가 술기운에 정신이 없어서 몽롱하지만;;

우리의 고객!(클라이언트)의 웹페이지부터 -> 웹서버(ibm웹스피어or 톰캣..아님 초비싼 ejb.또는 공짜인 jboss..) -> 웹 컨텐츠 

컨테이너(톰캣등 .. ) ->(이런 저런 프레임 워크보면.. 중간에 디스패치=클라이언트의 요청에 따라 그걸담당하는 컨트롤러 객체

에 일시키기) ->서블릿(우리가 배운 비지니스 도메인에 대한 컨트롤님 개념.. 컨트롤러=유저의 웹http 프로토콜을 통해 송수신

하는 mime데이터(html폼등)의 input/output 할 데이터와 그것에 대한 url 매핑) -> 로그인등의 비지니스 서비스라면..검증을 위해

dao객체를 통해 select id from 유저 테이블 유저아이디로 아뒤가 있는지 검증후, 아뒤가 있다면.. 해당 비번과 유저가 http 요청

(로긴페이지) 을 보낸 정보를 서로 비교해가며.. 처리를 해야겠지요. -> 물론 클라이언트의 웹 브라우저에 메세지를 전달하기 위

해서 ->특정 에러 페이지를 띄운다던지..(forward or redirect) ->아니면.. "아뒤가 존재하지 않습니다" or "비번이 일치하지

않습니다,"  등등을 클라이언트에게 전달해야겠지요(response <- 아까 서블릿이 요놈을 만들고 .. 웹 서버에 전달하며

웹서버가 클라에게 응답해주는 과정은 기억하시겠져?).. ->물론 클라이언트는.. 비번을 잘못입력했으면.. 재입력을 하거나

빡쳐서 브라우저를 하던가.. 하는 다양한 시나리오가 존재할 것입니다. 우리는 이것들을 처리해야겠져.. 이 상황을 해석할수

있는 컨트롤러의 처리 등등.. 


결국 해당 로그인이란 도메인 페이지에서 클라는 입력 정보+커맨드(로그인 요청 버튼 클릭)을 통해... request 구조(웹브라우저

가 만들어주는 데이터)를 웹서버(현잰 톰캣)에게 전달하고.. 우리는 웹서버세 등록해둔 대로..(서블릿 등록 <servlet>이름,클래스

+ url 매핑(특정 url 모양.. 예전에 db에서 where절의 like배울때 % .. _ 기억하시죠? 이런.. 정규식을 통해 .  특정 페이지=url

에 대해 그 요청을 컨트롤할 서블릿(.jsp파일)을 정의해두고.. 그러면 웹 컨테이너가 알아서 해당 요청에 대해 우리가 정의한

서블릿을 호출하고 아까 사용자가 전달한 request데이터 형식에 필요 정보를 매개변수로 전달해주죠..

우린 이걸 받아서.. 그동안 했듯 비지니스 객체에게 일을 시키고.. (야! 해당 아이디,비번의 유저가 존재하냐? 비전은 맞냐?)

를 dao객체(mvc에서 모델영역=퍼시스턴스에 대한 작업을 담당하는 녀석)를 통해 결과를 얻게되고..(리절트셋이던.. int형

값이던.. 익셉션이던..) 우리의 비지니스 클래스에선 그 결과에 따라 클라이언트에게 response로서 결과를 알려줘야죠

(성공이면 성공메세지 or 성공 페이지로 href처럼.. foward라는 페이지 제어권을 넘기는 명령을 통해..)

그러면 사용자는 자신의 요청에 대한 결과를 처리받는.. 즉 해당 도메인에 대해 특정 비지니스(로긴과정)을 마치게 되는거죠..


음.. 뭐랄까.. 앞으로 배우겠지만.. 웹에서 model2, mvc 라는 개념은.. 결국 각자의 책임영역을 분리하는 개념입니다.

(물론 디커플링을 위해. 중간에 어댑터 인터페이스 클래스를 두지만요.. 아~~ 복잡하닷! 그래도 자바,c++의 다형성이란 기술을

활용하는 정말 멋진 문제 해결 방법!!)

프레임워크엔 이런 저런 디자인 패턴이 적용되지만요.. 생소하실수도 있지만 ㅠㅠ 개인이 풀어내야할 문제라 생각합니다.


결국 중요한건... 선생님이 강조하셨듯.. 클라의 웹 브라우저부터.. http라는 표준 규약을 통해 동적인(현재 시간을 본다던지..

네이버에 댓글을 남기고 확인한다던지..) 처리를 위해 웹서버->웹컨테이너-> 옵저버 패턴의 리스너처럼.. 해당 url페이지 에 대한

요청과 그것을 처리하는 컨트롤러 페이지를 연결하는 매핑.. -> 우리가 정의하는 서블릿=컨트롤터의 처리-> 서블릿은 

해당 도메인의 비지니스에 대해 그것을 처리하기 위해 우리가 낑낑 거리며 구했던 dao에게 db와 이런 저런 작업을 하라고

부탁하는거죠... 그결과를 받아 비지니스(서비스 클래스)는 유저에게 response라는 걸로 처리 결과를 유저의 웹브라우저에

표시해 줘야할테고요..



..아 졸립네요... 오늘 동생분들, 정말로 존경하고 감사하는 선생님꼐 많이 배우고, 이런저런 대화를 나눌수 있어서 

기뻤습니다. 제가 발전할수 있게 채찍질해주셔서 감사하고! 여러분의 사랑으로 알겠습니다! 저도 잘할께여~~ 홧팅!!!

글고 굿나잇!1


ps2. 아고. 취해서 그런가?.. 감히 65 동기분들꼐 조언드리자면.. 프레임 워크 들어가기 전에.. 미리미리 디자인패턴

을 조금씩 하루에 5분 씩이라도 살펴보시면.. 큰 도움이 될거라 생각합니다!


엄청 고민해도 문제가 안풀리면 1.선생님께 헬프~ 2.성제,용성이한테 헬프~ 3..최후의 보루?로.. 장호형한테 헬프~ (물론 저는 

조건이 붙습니다. 저와 함께 고민하고 풀어낸 문제는 최소 2명에게 공유할것! ㅎㅎㅎ.. 예전에 카페에 글을 남겼는데..

아무도 질문을 안하더라고요;;) 


이상입니다. 저는 후딱 해장하고 .. 우리 함께 내일 웃으면서 봐요!! 



********************************************************************************************************


동생들, 선생님의 비판을 받으며.. 술자리에서 나가 몰래 한참을 울었다. 내 선의와 진심에 대해 질투와 자신의 시선및

기준을 강요하는 사람들.. 그래도 함께 어울리려 노력했다.


<2014.1.10 아 글고.. 취해서 그런가 저한테 관심잇으면 보셈  추가>


저는 내세울것도 없고.. 여러분에 비해 하등 잘난것이 없습니다.  나이도 들었고.. 여러분보다 경쟁력이 떨어지죠 ㅠㅠ


후.. 이런 변명해봤자.. 아무 소용없지요.. 여러분께 상처 입힌게 있다면 진심으로 사과 합니다.


여기 덧붙이는 글은 제가 예전에 고시생활을 하다가.. 방구석 폐인이 되었을때.. kbs 1박2일에 남겻던 글입니다.

(저의 자살?을 방지해준.. 고마운 프로그램입죠;;)

이걸 통해 저라는 인간이 어떤 마음과 생각을 갖고 있는지.. 약간은 아실수 있을거라 생각합니다..(폐인 시절에 1박2일 게시판에 

올렸던 쬐금의 파일들 몇개 첨부합니다. 초 민망;;)


부디 저란 사람의 성향을 오해하지 말아주세요 ㅠㅠ;;(저는 제가 못난걸 알고 있고.. 여러분을 존중하며 좋아합니다!!)

ps. 항상 강조하지만.. 저를 의식해서 위축되거나.. 스트레스 받지 마세요!  <-- 요놈 바보임 ;;;


ps2.오늘 배운건..carpe diem인가 vs 집중or 선택인가 vs 좋은게 좋은건가? 인가..

하여간.. 제가 상대를 감히 가르치쳐하는 듯한 화법은 고치도록 하겠습니닷! 글고 민폐 안끼칠꼐욧!


여러분 굿나잇!!!





**************************************************************************************


아닌건 아닌거다. 내 마음에 맺힌게 발생했다. 내가 가진 동생들에 대한 불만 사항, 그간 있었던 오해를

풀기 위해 글을 싸질렀다.


<2014.1.11 카페에 마지막 글 추가>



<뒷자리로 이동한 이유>

1.제 공부 스타일상 모르거나 떠오르는 부분이 생기면 즉시 다른 책이나, 인터넷을 통해 모르는 것을 해결해야

하기에 , 저는 여러 책을 동시에 펼처놓고 공부를 합니다. 그것을 위해서 넓은 공간이 필요합니다.


2.원래 제 자리에서 앞공간의 시야가 뚤려있었는데, 제 앞자리에 성제가 와서 시야가 가려져 칠판 내용을 보려면

고개를 좌,우로 이동해야합니다.


<뒷자리로 컴퓨터를 이동한 이유>

1.공부를 위해 뒷자리로 자리를 이동했지만, 컴퓨터가 필요한 상황도 있습니다. (제가 즐겨찾기 해둔 특정사이트,

컴퓨터에 깔아놓은 svn용 서버, 이런 저런 프레임 워크의 라이브러리, 플러그인및 각종 자료들, 세팅해둔 이클립스

로 실제 실습 연습을 할 필요가 있었습니다.)


2.지난주 회식때 저는 나름 조심스럽게 앞자리,뒷자리 이동을 했다고 생각했지만.. 여러분들의 의견을 수렴했고

여러분의 집중력을 해치는 폐를 끼치기 미안했기에, 선생님의 아이디어를 통해 .. 박명진 대리님께 컴퓨터 이동을

부탁드린 것입니다. (제가 예전에 10시간 정도 투자해 이런 저런 세팅을 해두었기에 뒷자리 컴퓨터에 그것을

다시 하는 것은 시간 낭비라고 판단했습니다.)


<유표관련>

1.제 경운 그동안 유표 관련 비하인드 스토리를 알지 못헀습니다. 회식자리에서 주호를 통해 사정을 알게되었고,

문제 해결을 위해, 금요일 오전(8:30~9:00경)에 유표와 개인 면담을 하면서, 저의 입장과 유표의 입장, 그리고

문제를 해결하기 위해 서로간 조인 할수 있는 부분을 함께 고민해보았습니다. 


2.저는 유표를 위해 위 단락에서 거론한 자리문제(공간협소,시야가림)를 포기할 이유가 없습니다. (솔직히 제 입장

에선 이런 사소한 문제들까지 여러분의 감정을 고려해 이처럼 구체적으로 이유를 설명해줘야 한다는게 어처구니가 없습

니다. 다들 성인이고.. 그 행동엔 나름 이유가 있으니 그러는 것일텐데요?)


3.유표 문제 관련해 서로의 합의점은 

 ㄱ.유표에게 일단 사과(제가 인지를 못했었던 문제였을지라도 저는 우선 유표를 배려해 사과를 했습니다)

 ㄴ.앞자리의 지희,성제와 관계 맺어주기(2조 팀으로서 유표가 형,누나들에게 쉽게 물어볼수 있게끔) 

     그것을 위해서 제가 조장은 아니지만, 2조 팀원들에 대해 다음주중 술자리를 제안했고.. 나름 긍정적인

     반응을 얻었습니다.

 ㄷ.제게 부담없이 물어보라는 말을 한번 더했습니다. (저는 카페를 통해 분명 글을 남겼었습니다. 혼자 엄청 고민

     해도 문제가 안풀리면 제게 찾아오라고. 몇몇 조건이 있었지만.. 보지 않고 관심을 안둔 여러분의 잘못이라 생각

     합니다.)

 ㄹ.유표가 능동적으로 학습을 할수 있게끔.. 제가 가진 나름의 공부에 대한 방법론및 선택과 집중등.. 가급적 친절하

     게 말을 해주었고. 유표를 위해 무엇을 선물해주면 좋을까 고민햇고.. 함께 편의점에서 노트를 사고 그것을 선물

     하는 것으로 마무리 지었습니다.

 ㅁ.유표가 스스로 느끼게 하기 위해서 저는 어제 수업시간에 선생님과 실습했던 이런저런 xml설정파일,html,java코드

     에 대해 모든 라인에 주석을 달았습니다.


     주석을 단 목적은 제 어설픈 지식을 공유하려는 것이 아닌, 어떻게 공부를 해야 효과적인 지를 .. 유표가 스스로 느끼

     길 원했기에 제 시간을 투자했습니다. 정말 피곤한 쉬는 시간에도 휴식시간을 쪼개.. 유표가 무엇을 필기했는지 확인

     해보았습니다. 뒷자리에서는 원치 않지만.. 여러분들의 모든 행동이 눈에 들어옵니다. 제게 있어 어제의 관심사는

     유표의 수업시간의 모습을 가끔 관찰하는 것이엇지요.. 카톡인지 뭔지에 정신이 팔려.. 보석 같은 수업 내용을 흘린다?

     아침에 노트및 이런저런 투자를 해주었는데?  여러분.. 저의 감정은 어떠할까요? .. 유표만의 문제가 아닙니다. 제가 조언

     햇고.. 그 뒤에 여러분들은 어떤 행동으로 제게 보여주었습니까? 여러분 스스로 떳떳합니까? 자격지심에 저를 깔아 뭉개

     야 만족스럽습니까? 그리해도 저는 괜찮습니다. 근데.. 이런게 여러분께 과연 도움이 됩니까?


     제가 강조하지 않았습니까.. 저를 의식해서 휘둘리지 말아달라고.. 단지, 절대로 자포자기는 하지 말아달라고.. 여러분의 

     감정이 어떻게 될지 저의 개인적인 경험들및 이런저런 사고과정을 통해 시뮬레이션이 가능하기에..

     그리 부탁안했습니까? 더 이상 배려하는 것도 짜증납니다.(여러분은 저를 배려했다고 하시곘죠, 저 또한 나름 공동체에 

     배려를 했습니다. 이런 시간을 차라리 가능성과 성실함이 보이는 지희에게 투자해주는 것이 제 입장에선 저에게 이득입니다.)


  = 저는 문제를 풀기위해 고민했으며, 그것을 실천했습니다.(여러분은 생각하고, 판단하고, 그것을 "실천"하십니까?)

    해야 할때 힘들다고 어렵다고 안하면.. 복리이자처럼 미래의 자신에게 눈덩이가 되어 굴러온다고.. 몇몇 동생분들께 

    말하지 않았습니까? 동생 분들을 아끼기에 쓴소리 해줬지 않습니까?(감정 맞춰가며 칭찬하고.. 실실 웃어주고 .. 아파해

    주는거.. 그딴거 누가 못합니까? 문제의 본질을 파악하고 맡기로 결정했으면 "책임"있게 행동을 해야죠.)


<용성,진이 관련 +  팀 작업 관련>

1.회식자리에서 진이와 용성이의 주장을 잘 들었습니다. 저는 제 주장을 했습니다. 동생분들.. 제가 여러분들 보다 생각이

  짧고 미성숙해보이십니까?  저는 다름을 인정하고, 중간에서 win-win 할수 있는 부분을 찾지, 저의 주장만을 상대에게

  강요 하지 않습니다. 여러분의 생각 존중한다니까요? 


  저는 현업에서 팀 작업의 경험도 있으며(팀장님께 나름 이쁨 받았었습니다), 팀장의 역할도 학생때 몇번씩 해보았고(대다수 

  사람들의 책임감의 부족,유혹에 약한 성향등.. 이런 저런 실망-> 팀 작업의 경험을 통해 개인적으로 얻는 부분도 있습니다. 

   물론 거의 대부분의 날을 혼자서 밤을 세버렸었지만..)


  진이, 용성이는 제가 아래 남긴 글의 첨부 파일을 읽어보길 권합니다. 여러분은 자신의 프레임으로 저란 사람을 평가하고

  있는듯 합니다. (제가 낮추고 내세우질 않으니.) 제가 어떠한 식으로 사고(판단)하고, 행동하는지.. 제 글을 통해

  저를 조금 더 안후, 여러분의 프레임을 조금 더 키우길 바랍니다.

  (벼룩을 3cm 높이의 공간에서 사육하면 3cm만 점프할수 있지만.. 그 제한을 풀어주면 10cm던 1m이던 점프할수 있습니다.

   우물안의 개구리란 말도 똑같은 의미입니다.)


  자신의 감정을 해소하기 위한 비난인지, 선생님의 조언처럼 발전을 위한 비판과 조언인지.. 구분하세요. 

  이기심? 제가 이기적이다? 여러분.. 이기적이라는 개념의 의미에 대해 이해는 하고 계십니까?

  (진이,용성이.. 총명하고 생각이 깊은것을 알수 있습니다. 제가 여러분의 말의 의도와 취지를 귀막고 무조건 배척하는

   말귀를 못알아 듣는.. 독불장군으로 보입니까? 저의 이성적인 판단이 들어 있습니다. 존중해 주십시오)

 

  성인으로서 공동체 안에서 필요조건은. 예의와 기본적인 상식(룰).. 그외 곁가지로 상대에 대한 배려일뿐.. 이 이상도 이하도 

  아닙니다.  곰곰히 생각해보세요. (수학및 논리 용어인 필요조건.. 단어의 의미 아시리라 믿습니다.)


  (금요일 회식자리에서 동생분들과 1:1로 대화를 나누고.. 저의 행동과 태도와 그간의 함께하려는 노력에 대해 오해하는 여러분

  들을 보고.. 너무도 서글퍼지고.. 여러분이 안타까워서 .. 담배피러 몰래 나가서 한동안 펑펑 울었습니다. 제가 여러분과 함께

  하려했던 노력과 실천.. 1:1로 여러분의 아픔을 듣고, 함께 나누고 용기를 주려 했던 저의 선의들이 의미가 없어졌다고 느껴져

  서요)

   

2.개인적인 목표가 다를수 있음을 인정하고, 우리의 목표가, 공통의 목표인지 vs 개인적인 목표인지 구분할 것이며,

   목표를 이루기 위한 수단들의 선택중.. 본질이 무엇이고 곁가지가 무엇인지 구분하길 바랍니다.


  아주 쉽게 비유하면.. 대학을 가기위해 집중해야 할것, 선택해야 할것(한마디로 포기해야만 했던것) -> 대학 또한

  대부분 수단일뿐 목표는 아닙니다. 개인의 목표중 대학 보다 더욱 중요한 현재의 과정을 위해 집중해야 할것, 선택해

  야 할것.(저는 팀 프로젝트를 오래전에 지휘해 보았으며.. 리더의 역할에 대해 시행착오와 경험을 얻을수 있었습니다.

  그것을 토대로 저는 현재 이 자리 = kosta65기 자바 개발자 양성과정 에서 저의 포지션을 결정한 것이고요..)


  스스로 판단해 보길 바랍니다.(강조하지만.. 저는 여러분을 설득하지 않습니다.)


3.수업 45~50분 집중하면.. 엄청난 피로와 스트레스가 몰려옵니다. (새로 배운것들, 다시 복습한 것들, 선생님의 가르침을

  통한 개인적인 깨달음들, 암기를 위해 몇번이고 반복해서 종이쪼가리에 적고 지우고.. 개념이해를 위해 그림을 그려보고..

  조금이라도 더 발전하고 싶어서 발버둥을 치고 있습니다. 개발능력 관련해 주지하실 점은.. 저는 약 2달전 여러분과 거의 

  비슷한 수준에서 공부를 시작 했었습니다. 여러분보다 수준이 월등한 상태에서 시작한 것이 아닙니다. 허나, 이젠 차이가 

  벌어진듯합니다. 왜그럴까요?)


  제가 및에 내려가서 담배를 함께 태우며 여러분과 별 의미없는 대화를 통해 감정과 정서를 교환해야 65기 구성원의 일부

  로서 자격을 얻게 됩니까? (제가 생각하는 대인 관게의 핵심은.. 가급적 바른 판단, 노력을 통한 실천과 그것을 일관적으로 

  지키면서 상대에게 신뢰감을 주는 것이라 생각합니다.)


  조금이라도 빨리 담배를 피면서 스트레스를 풀면서, 그 짧은 시간에도 머리속으로 이런 저런 고민을 해보고, 교실에 내려와

  선 제가 읽고 있던 책 마저보기 or 피로가 쌓여 집중력이 떨어졌다고 판단되면 .. 다음 시간의 집중을 위해 가급적

  편하게 휴식..(= 선택과 집중)


  (etc)

  별론이지만, 어제 금요일날 영화를 볼떄에도.. 저는 여러분들과 다른 시각으로 접근을 합니다. 즉 소비자가 아닌 생산자(컨텐

  츠 개발자)의 시각으로 영화를 감상하죠. 이야기의 전개, 인물들간 관계, 복선, 영화가 담고있는 메세지.. 등을 분석을 하고 

  머리속에서 이런 저런 시뮬레이션을 합니다. 그러다 보면.. 정리가 되고 뒷 스토리가 대략 예측이 됩니다. 그러면 저는 그 순간

  호기심을잃어 버립니다. 제가 아직도 제대로 이해를 못하고 정리를 못하고 있는 .. 개발 관련 이런 저런 책에 당연히 관심이 

  가지요..


  일상적인 대화의 경우에도.. 게임 얘기? 여자 얘기? 저는 흥미가 없습니다. 예전 지훈 형님과 담배피러 올라가서 이런 저런

  다양한 분야에 대해 대화를 나누고 가르침을 얻었습니다. 저도 대화 하는것.. 좋아합니다. 배우는 기회가 되고, 서로의 내면을 

  조금 더 관찰할수 있는 계기가 되지요.(부족한 점을 채워줄수 있거나or호감or존경이면.. 조금 더 가까운 관계로 발전하게 될터

  이고)


  저는 집단or 군중(뭉쳐있는 그룹)의 대화에 끼지 않습니다.(이유가 있습니다. 아무 의미 없는 시간 낭비인 대화.. 말 그대로

  정서적으로 핥아주기.. 본질이 아니지 않습니까?)


  저는 1:1 대화를 좋아합니다. 단지 시간이 부족할 따름이죠. 저에게 호감이 있고.. 궁금한게 있다면 옥상으로 왜 안쫒아 올라

  옵니까? (저는 지훈형님과 대화를 통해 배웠고, 아영이와 대화를 통해 배웠습니다. 학생중에 제게 영감및 영향을 주는 사람은 

  이젠.. 모르겠습니다.. 앞자리 초학하는 지희의 발전하는 모습 정도만 흐뭇하더군요..)



4.제가 카페에 올리는 글들에 의견및, 피드백 줍니까? 강사님께 q&a에 제가 우리의 미래를 위해 함께 고민해보자고 제안한 글

  을 안읽어 봣지요?   팀카페인데.. 글들 체크 안하지요?  여러분이 팀 어쩌구를 논할 자격이 있습니까? (그래서 전에 몇몇 동생

  들과 이런 저런 대화를 나누는 자리까지 가졌지만.. 자신의 미래에 대해 별다른 애정도,그것을 풀기위한 의욕도 없는듯 느꼈습

  니다.) 


  몇몇 친구들 단기적으로 문제를 풀어주는 행위에 그리 자부심을 느끼시나요? 자신이 그나마 아는것을 좋은 곳에 사용한다?

  당연히 성취감 느끼겠지요(현재 상태에 대한 불만을 치유하는 정서적 만족감).. 현재 우리가 부딪히고 있는 웹프로그래밍의 

  전반적인 부분은 훨씬 복잡하고 어려우니까요..

  

  개인적으로 부딪히고 노력해야 하는 시간을 쪼개서.. 상대를 돕는다? 자신에게 도움이 되고, 상대에게 도움이 되야.. 위선이

  아닙니다. 여러분의 행위를 평가해드리면. 한마디로 "설레발" ,"자기 만족", "현실 도피" 입니다. 또한 저에 대해 자신의

  의견을 강요or 설득하려는 모습 또한.. 저를 엄청나게 낮은 수준으로 평가 하시기에 가능하겠지요.(or 애정의 탈을 쓴 자아

  분출이거나..)


  이 부분은 이제 제가 더이상 여러분께 쓴소리 안하겠습니다. 당연히 서로의 사고과정이 다름을 이해하고 존중하니까요..

  

 어제 학습 종료시 용성이에게 인사를 건냈고.. 용성이의 대처를 보고.. 이상한 느낌을 감지하고 저 역시 화가 조금 치밀었

 기에 제 입장에선 하등 가치 없는 이런 글을 작성하고 있습니다. (글을 쓰면서 감정이 치밀어 오르네요.. 저도 한참 멀었습니다)


5.기타..

   제가 왜 귀를 막고 있을까요? 여러분을 배척한다고 표시를 낸다고 느낍니까? 저는 집중하기 위해 귀를 막았으며, 수업시간

   에 한쪽 귀를 열어두고 있습니다. 물론 제가 귀를 막는 행동이 상대에게 전달할 감정을 저 역시 알고 있기에 들키지 않기

   위해 모자를 계속 눌러쓰고 있었습니다. 혹여 엉뚱한 오해를 받기 싫어서요.. 


   저는 여러분이 쉬는시간에 떠들고 게임하고.. 이해하며, 존중합니다. 여러분의 스트레스를 푸는 시간을 방해하고 싶지 않기

   에 제가 귀를 막고 숨긴 것이죠.

   또한 수업시간에 여러분이 잠을 자고, 따른일을 해도.. 존중합니다. 단지 공부에 방해가될 정도로 피해를 준다는것.. 그게 

   의식있는 성인의 행동입니까? 애기들 장난입니까? 기본적인 룰은 지키고 나서 상대를 비판하기 바랍니다. (제가 수업시간에

   집중을 안한다고요? 인터넷 검색만 한다고요? 선생님이 던져주시는 물음표에 대해 바로바로 해결을 하는 과정들 입니다.

   그것들이 링크를 타고 점점 확장되는 경우가 빈번할뿐이죠.)

   

   혹시나 제가 방과후에 자습을 위해 남아있어서.. 여러분들이 불편함에 남아있지 못하는것인가 걱정되어.. 그것을 물어보았

   습니다.(제가 혼자이고 저는 집에서도 학습이 가능하니.. 제가 집에가서 공부하려 했지요. 왜냐? 소란스럽기 때문입니다.)


   꽤 오래되었지만.. 조를 짜서 1주마다 교실 청소하는것.. 그 전에 3~4회 제가 아침에 혼자 빗자루질을 했었습니다. 누가 시키

   진 않았으나, 저는 스스로 판단했고 실천했고 가급적 티를 안내려고 했었습니다.(눈치를 채면 웃음으로 넘겨버렸지요)


   제 행동 하나하나에 여러분에 대한 배려를 못느낍니까? 제가 비판받아 마땅한 행동을 하고 있는 것인가요? 


   전에 kosta 직원분들과 회식자리.. 저는 특정 목적을 달성하기 위해 참여햇고.. 윤팀장님께 환심을 사려 노력했습니다.

   그 목적은 우리 65기 동료들과 주말에 강의실을 오픈해서 스터디를 하고 싶다는 마음에서 시작된 행위였지요.(다른 이유

   도 2개 더 있었지만..)


   우리 클래스.. 주말 스터디에 아무도 반응이 없었습니다. (저 개인적으론 집에서 해도 충분합니다. 여러분을 위해서 

   밑작업을 해둔것이죠..)


6.기타2

   제가 여러분을 깔아 뭉개고 65기 최고가 싶어서 이런 저런 공부를 선행하고 미친듯이 집중하는줄 아십니까?

   저는 수많은 시행착오와 아픈 경험을 통해서 겨우 삶의 목표를 찾게된 사람입니다. 그것을 이루기 위해 지금은 노력해야

   할 시간이라고 판단한 것이고요. 저는 우리65기 최고가 되고싶단 공명심 같은 건 전혀 없습니다.(저를 여러분의 프레임으

   로 가볍게 판단하지 마세요) 


   제가 이루고 싶은게 있고 그 목표가 높은 편이며, 그것에 맞추어 스케줄을 진행중입니다.


   계속 강조하지만 저에게 휘둘리지 말고.. 자신의 스타일대로 진행하십시오. 저에게 다른 동기분들과 발걸음을 맞추라는 동생

   분들의 요청?조언?협박? 도대체 의도가 무엇입니까? 그리고 여러분이 제게 팀을 강조하는 주장을 하는 그 근본적인 감정의 

   발단은 무엇입니까?

   

   제가 감히 추측해볼까요? 함께가 아니면 불안한 약자들의 감정 or 스스로 책임지기 싫어하며 상대에게 의존하고 책임을 넘기

   려는 감정->노력은 귀찮음 + 알량한 자존심 ->질투 or 자포자기 ->배척및 상대에 대한 공격을 통한 자기 만족 -> 그래봤자 

   자신이 변한것이 없음으로 위의 과정 반복..  


    저 팀프로젝트 경험 있고, 상대와 정서적 교류가 필요하다면.. 그것을 잘 해낼만큼 유연합니다. 윤팀장님께 점수를 따고 싶으면

    그분을 웃겨드릴수 있고, 그분의 관심사를 찾고 도움을 드려 점수를 딸만큼 영악한 편입니다. 위에도 말했지만.. 제가 여러분들

    에 대해 "하하 호호" 웃고, "엉엉" 울어주는 이미지 메이킹을 못할것 같습니까? 본질이 아니기에 그리고 여러분께 도움이 안되

    기에 안하는것 뿐입니다.(물론 시간도 부족하지요)


<맺음말>

  자신과 다르다고, 제게 상처를 주기위해 돌을 던져도 좋습니다. 그러나 그런 행위는 여러분께 하등의 도움이 안되다고 생각

  합니다.

  

  열정있어 향상심이 있는 사람, 정직한 사람, 자신의 업무에 대해 책임감을 가지고 성실한 사람.. 한마디로 제 입맛에 맛는 그런

  분들에게만 제가 칭찬할땐 칭찬해드리고, 못할땐 혼내드리고, 위로가 필요할땐 함께 울어드리겠습니다. 즉 제가 리딩해 드리겠

  습니다. 



ps.

 서로 다름을 인정하고, 존중하며.. 교점이 있다면 서로간 반가운 인사, 의미 있는 대화와 성과.. 

 굳이 여러분의 기준에 맞춰줘야 하며, 그것이 아니면 왕따를 시키는 듯한 판단과 행동을 하고 싶다면 그리 하십시오.

 선택을 하라고요? 공부를 하던.. 모두와 사이좋게 지내던? (이해할수 없습니다. 모 아니면 도 입니까? 윈윈 없습니까?)

 


 저는 독립적으로 사고하고 행동하는 존재이며, 사형수처럼 언제 자살할까..  그렇게 몇년의 시간을 혼자서 살아본 사람

 입니다. 


 여러분의 기반은 모르지만, 저는 정말로 다양한 분야에 대해 "공부"를 했었으며, 저의 재능을 아껴주시고 이끌어 주시는 몇몇 

 든든한 어른/선배들도 계십니다.


 아참.. 몇몇분들(상처받을까봐 뭉뚱그립니다) 제 학벌이 전문대라 기저에 저를 무시하는 마음이 자리 잡으셨나요? 

 (너는 xx 학교 이고 나는 xx학교인데도? 만약 그렇다면.. 아직 미성숙했군요.. 학벌에 대해 자부심 느끼나요? 기저에 그런 

 의식을 담고 있는듯한 느낌을 받았습니다. 참고로 저희 집안에서 저만 유니크하게 전문대를 나왔습니다. 저는 별다른 욕심및 

 불편함, 그리고 자격지심이 없기에 업그레이드 안하는것 뿐이고요.)

 

 몇몇분들의 시선으론 제가 많이 떨어져 보이죠? (일반적으로 사람을 평가하는 기준중 나름 객관적 지표중 하나가 학벌이니..)


 저는 고등학교 3년의 기간을 친구,술,여자, 폭력으로 넘겨버렸고.. 주위의 어른들도 저를 컨트롤 못할 정도로 자존감및 폭력성

 이 강했던 사람입니다.


 그 후에 별다른 목표 없이.. 공부나 한번 해볼까 하는 마음으로 1년간 재수학원을 다녔고(저녁에는 놀면서), 나름의 성과는 

 얻었습니다.(369/400) 그걸로 한양대,성대 경영학과를 지원하였으며.. 제 실력이 부족한 관계로 떨어졌습니다.

 (제가 살아오며 공부했던 부분들을 나열해 볼까요? 주식+선물및 약간의 경제학, 경영학, 경영의 파생 가지로 마케팅, 심리학

 (지희에 비하면.. 새발의 피겠지만), 전산학, 게임 컨텐츠 기획과 개발, 3d및 게임 플밍을 위한 수학(대학1년 수준 선형대수및 

  행렬수학)과 물리(대학1년 수준),  그외에 법학(대학3~5년 수준)을 자발적으로 "공부"햇습니다. 기타 어설프게 공부한건 나열

 하지도 않았습니다.)

 

 위의 과정에 대해 저는 훑는게 아닌.. "공부"를 햇습니다. 단지 자격증등을 하찮게 생각했던 거죠. (배고파 본적이 없으니..)

 

 제가 여러분께 이런걸 말해서 무엇합니까? 혹시.. 이런 내용도 저의 자격지심으로 판단됩니까? 제가 말하고 싶은것은

 중요한것이 무엇인지에 관한 것입니다. 하등 본질이 아닌것들인데.. 전 본질에만 집중합니다. 곁가지는 생략합니다.


 제 입장에선 여러분들께 마음을 열고, 좋은 영향을 주고 받고 싶지만, 저를 무시하며 배척하고 싶다면 편한데로 그리 하십시오. 

 


 제게 있어.. 이런 행위와 과정은 말 그대로.. "시간 낭비" 입니다. 단지 여러분을 아끼고 좋아하는 마음이 있었기에(고시 폐인

 시절에 사람에 대한 그리움) 글을 남기고 대화를 한 것이죠. (여러분이 이 글을 보고 저에게 내심 욕을 하던, 감동을 받던.. 

 제 이성과 감성엔 별다른 영향이 없습니다.)


ps2. 

  저는 선생님께 저의 개인적인 공부 스타일및.. 그간 있을수 있었던 각종 오해에 대해.. 술자리를 빌려 대화를 통해 풀기 위해 

  노력했고, 제가 가진 진심으로 존경및 감사하는 마음을 전달하려 노력했습니다. 물론 선생님은 이해해주시는듯 하였으며, 

  인생의 선배님으로서도 이런 저런 중요한 가르침을 주셨고, 저는 그것이 비난이 아닌, 비판임을 알고 있기에.. 감동을 받았습

  니다.(제 삶에서 가르침을 주신 감사한 분중 한분으로 기억될것입니다. 저는 은혜를 잊는 파렴치한 인간이 아닙니다.)


  저 때문에 짜증나서 선생님이 제대로 수업을 안가르쳐 주실수도 있다고요? 선생님을 과소 평가하지 마십시오. 어른으로서, 개발

  자및 교육자로서 갈고 닦은 이성과 함께 따뜻한 감성을 가지신 분입니다. 한마디로 아직 미숙한 제 행동과 태도에 휘둘려 여러

  분께 피해가 발생할리 없으니 안심 하십시오. (물론 예절의 차원에서 이런 부분을 지적해준 주호에겐 감사하는 마음입니다.

  오해 말아주세요. 저는 선생님 또한 본질을 중요시하지 허례허식에 비중을 두신다고 생각하지 않습니다. 최소한 제가 선생님에

  대해 느낀점은 그렇습니다.)


  이상입니다. 

  (다음주 금요일에 글을 전부 삭제합니다. 이 글은 오래 남길 필요도 없고.. 제 개인 블로그의 잡담 카테고리에 들어 가지도 못할

   폐기 대상입니다.)



by givingsheart 2014. 1. 1. 15:01

오늘은 폰갭 관련 좋은 교재가 있는지 확인하러 서점에 들렀었습니다.

 

대략 12시쯤 나가서 6시쯤 돌아왔는데요.. 온갖 책들의 표지만 실컷 구경하다 와버렸네요.

 

애초에 목표로 했던 폰갭 관련 도서의 경우.. 제 눈에는 "난 폰갭으로 뭔가 만들었습니다. 그러니

내 코드 한번 따라 쳐보세요" 식이라 영 구미가 안당겼습니다.

 

그다음으로 생각했던게.. spring 관련 교재였는데요.. 저는 api문서처럼 참조하는 형식의 레퍼런스

북이 아닌, 개념 이해부터 다양한 소스까지 포함된 책을 찾다보니.. 몇몇 책이 탐지 되었습니다.

 

결국 "프로 스프링3<에이콘출판>" "스프링 MVC 프로그래밍<위키북스>" 두 책을 점찍어 왔습니다.

 

이 책 괜찮을까요?  궁금합니다~

 

 

ps.오는 길에 중고 서점에 들러 code complete2 , jsp1.2버전의 java server pages란 책을 구매해

왔는데.. jsp 1.2....

 

주말에 the c++ programming language란 책을 붙잡고 있는 중인데.. 너무 어렵습니다. OTL

 

어쩌다 보니 잡담 형식이 되었네요. 흠.. 뭔가 의미 있는 정보를 넣어야 할텐데..

 

 

 

 

상위클래스타입의 참조형 변수에 하위클래스타입의 객체를 보관할수 있다는 문제에 대해 대충 고찰해 봅니다.

 

 

사용해보니 완전 편하지요? A타입,B타입,C타입 따로 배열을 만들어 보관할 필요 없이. A,B,C,의 상위 클래스

인 Base타입 배열 하나로 보관하다니.. 얼마나 행복합니까. 물론 상속(일반화&구체화 => A is a Base, B is a Base..)

라는 개념은 이해하는 걸로 전제합니다.

 

 

상위 클래스 , 하위 클래스 구분부터 합니다.

1.포함하는 멤버필드,멤버 메서드는 :상위 클래스 <= 하위 클래스 로서 한마디로 하위클래스가 덩치는 더 크거나 같습니다.

 

2.혼란이 있을수 있는 부분이 우리는 큰 자료형에 작은 자료형을 넣을때 별다른 문제가 없다고 기억합니다.

  double d = 10.f;    

 

3.하위클래스의 덩치가 크니까 상위 클래스를 넣어도 별 문제가 없어 보이지만 한가지 고려할 부분이 있습니다.

 

 

(데이터의 타입 선언(자바에선 불필요한듯?),정의,메모리 할당,초기화에 대해 설명을 드릴까 고민해 봤지만,

처음부터 개념을 잡아주려면 시간이 많이 걸릴듯 하여 생략합니다. 서적 참고 + 개별적으로 검색)

 

 

4.프리미티브타입 vs 레퍼런스타입 : 참조(레퍼런스) 타입의 변수는 메모리상의 주소 0x11212124 를 기억하기

위한 변수 입니다. Person이란 클래스 타입이 있고, 그것의 메모리상 주소를 가리킬수 있는 Person p;에서

p가 주소를 담는 참조변수입니다. (new를 통해 실제 Person 크기만큼의 메모리를 할당하고 그 주소를 레퍼런스

타입 변수명 p에 기억시키는 것은 별개의 과정입니다. 아 글고.. 프리미티브라도 배열타입은 레퍼런스타입과 같습

니다. int a; Person p; 등의 변수명은 실제 메모리 공간의 주소를 사람이 인식하고 다루기 쉽게 연결해줍니다.)

 

프리미티브형은 타입 별로 메모리상 차지하는 공간에 차이가 있습니다. 1byte,2byte,4byte..

 

레퍼런스타입은 1,2,4byte 처럼 차이가 있지 않습니다. 자바에선 4byte로 고정입니다.(64비트 운영체제에서도

그런진 모르겠습니다)

 

5.3으로 되돌아가 보면.. 결국 상위클래스와 하위클래스의 메모리(힙영역)상 위치를 가리키는 참조변수는

크기가 4byte로 동일합니다. 그럼으로 상위클래스 타입과 하위 클래스 타입간에 형변환이 가능합니다.

 

6.2에서 거론한 프리미티브간의 형변환과 레퍼런스타입중 계층트리(상속관계) 형변환은 의미상 차이가 있습니다.

데이터 사이즈가 큰쪽 vs 작은쪽      <----->   개념상 상위타입(사람) vs 하위타입(여자or남자)

 

7.자바 컴파일러는 타입간의 계층트리에 대해 많은걸 알고 있습니다. 우리가 타입들을 선언+구현=정의해주고

타입간에 관계를 알려줬기 때문이죠. extends, implements .. 그래서 6의 두가지 형변환(크기상 형변환 vs 다형적

의미의 형변환)이 컴파일러 입장에선 of course입니다.

 

8.그럼으로 형변환을 허용해주고 얼핏 크기가 달라보이는데도 하나의 컨테이너(배열= 동일한 데이터 타입의 집합)

에 담을수 있는 것입니다.

 

long l = 10(int); <-- 문제 없습니다.(물론 컴파일 오류는 뜨겠지만;;)

int i = 10L; <--문제가 있습니다. 사이즈가 큰 타입을 작은 타입에 넣어주면 데이터 손실이 있을수 있기에 명시적인

                    형변환 int i = (int)10L; 이 필요합니다. 

Base base = new Child(); <--  문제 없습니다.(개념상 상위 타입에 하위 타입을 넣었음으로)

Child child = new Base(); <--  문제가 있습니다.(데이터 손실은 없지만 마찬가지로 명시적인 형변환이 필요합니다.)

 

=>제가 틀린 부분이 있을지도 모르겠습니다만, 하여간 시간을 투자해 지식을 공유했습니다.(제가 책볼 시간을 쪼개서)

그럼으로 이제 더 이상 제가 아는 것을 남기는 설레발은 안떨겠습니다.

 

이상입니다. 이따 봅시다. 굿나잇~

by givingsheart 2014. 1. 1. 15:00
| 1 |