시험 리마인딩 + 시험 공부 안하고 80/100이면.. 괜찮은 건가?

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를 공부할 필요성이 있다고 생각함.