삶이란 긴 이야기 - SungMin

자 이제 내가 하려고 했던 이야기중에 하나인 DB 클래스에 대해서 계속 살펴보도록 하자.

우리가 연결해야 하는것들은..

 

Excel

MDB

Oracle

Ms-sql

My-sql

 

등 아주 많은… 개체들이 있다.

그럼 어떻게 해야할까?

뭐 어쩌겠나 각각의 개체들을 모두다 만들어 줘야 한다는것이다.

하지만 내가 앞에서 적었듯이 내가 만든게 점점기억이 나지않게 된다는 사실이다.

결국 이런문제를 해결하기 위해서는 우리는 "표준"이란것을 재정할 만한 필요가 생긴것이다.

(앞에서 적은 USB를 생각해보라.)

우리가 만든 클래스를 상기해 보자.(내가 만든것이였나)



우리가 만든것의 표준을 callSP와 callSQL을 생각해 보자.

즉 우리는 ms-sql을 접속을 해도 callSQL이란걸 쓰고 오라클도 그리고 심지어 Excel파일도 저렇게 사용을 하고 싶은것이다.

앞에 코딩을 봐서 알겠지만 저렇게 만들어 주는것은 사실은 큰 문제가 아니다.

20줄 정도 되었나?

그럼 이번에는 그 ms-sql의 코딩을 가지고 인터페이스를 상속한채로 만들어 보자.

그리고 앞에서 적은 코드와 비교해 보자.



이게 앞서 작성한 코드이다.

20줄은 좀 넘는것 같긴하다. 이것을 인터페이스를 상속받아 사용하면 어떻게 되는가?

아쉽게도..



겨우 이것만 달라질 뿐이다.

단지 위에 인터페이스를 선언해주고 클래스에 상속자만 적어줄뿐이다.

뭐하자는 겜인가? 싶지 않나.. 그렇다 별게 없다.

그럼 우리는 왜 인터페이스를 사용하는가? 아까 말했듯이 그냥 표준이라는것이다.



왼쪽의 인터페이스를 오른쪽의 클래스가 상속했다고 위에 동그라미가 그려지는게 아마도 다인듯 싶다.

인터페이스를 만들지 않고도 우리가 만들 개체들이 모두 callSP와 callSQL이라는 함수만 만들면 되는것이 아닐까? 그러게 말이다.

하지만 그렇게 한다면 다른이가 또는 우리가 나중에 클래스를 사용할때 그렇게 한것인지 아닌지를 구분하기에는 시간이 걸릴것이다. 그러니 귀찮더라도



이렇게 상속한다고 적어주는게 좋을듯 싶다.

그럼 이번에는 오라클용 클래스를 하나 만들어 보도록 하자.



이렇게 두개의 클래스가 인터페이스를 상속받고



이렇게 구현이 될것이다. Ms-sql보다는 조근 더 긴것 같다.

원본 위치 <http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=18&MAEULNO=8&no=1590&page=1>

자. 이제는 인터페이스에 대한 낙서를 적어보자.

미리 말해두지만 정말 낙서이다.

예전에 처음 인터페이스를 접하게 되었을때 난 이런생각을 했다. 내가 만드는 모든 클래스들은

만드는클래스 xx = new 만드는클래스();

Xx.open();

Xx.close();

같이 하면 무조건 그 클래스가 작동하는것을 말이다.

하여간.. Open 으로 시작해서 close로 끝나고자 했던 기억이 난다.

그시절에도 물론 지금도 크게 생성자에다 뭘 집어 넣는걸 좋아하지 않았던 이유로 왜 생성자를 좋아하지 않았는지는 나도 모르겠지만..

그냥 왠지 생성자에 넣는게 좀 그랬더랬다..

하여간 그건 그런거고.. 저런 인터페이스를 가지겠다는 생각을 종종하곤 했다.

문제는 세상이 그리 만만할 수준이 아니란것과 너무 많은 형태의 클래스들이 생겨나니 저런것이 힘들다는것들을 알게되고 두번째 생각한것은

인터페이스군을 만들자는 생각이였다. 네트웍에 따른 인터페이스 / DB에 따른것 / …..

이런식으로 표준 인터페이스를 만들어서 거기에 맞도록 다른것을 끼워 맞추는것이다.

왜냐면 난 내가 만들어 놓은 클래스 마저 사용법이 기억이 나지 않기 때문이다.

그럼 결국 아무런 클래스나 내가 만든것들은 무조건

Open해주면 되고 나중에 close 해주면 된다고 생각해 봐라..

즉 그렇게 한다고 정의했다면 만약 그 클래스가 특별히 인자를 요구하지 않는다면 사실상 클래스의 사용법을 알지 않아도 된다는 이야기가 된다.

두번째 문제는 필요없는 인자를 넘기기 위한 코딩을 괜히하게 되거나 할 수도 있겠지만..

하여간 이런생각들이 자꾸만 들게 됨으로 인해서 닷넷에서 제공하는 것마져 내 방식에 맞도록 하고자 하는 생각들이 들게 되고 그렇게 하는게 Adapter라는 패턴을 이야기 하는줄 나중에 알게 되었다.

하지만 문제는 말이다. 나같은 단순한 사람도 그런생각을 하듯이 닷넷을 만든이도 그런 생각을 했다는 것이다. 그럼에도 불구하고 그러지 못하는것은 너무 나도 필요한게 많기때문일지라.

하여간 그 인터페이스에 대한 이야기를 해보도록 해보자.

처음 닷넷이거나 또는 자바이거나 아님 c++이거나 객체지향이란 언어를 접해서 하나의 난관이라고 이야기 할수 있는게 이넘의 인터페이스다.

문제는 인터페이스가 어려워서가 아니라 이걸 설명하는 책이 더럽게 어렵다는 것이다.

아님 내가 머리가 나쁘거나.

하여간 지금도 이해를 못하니 어쩌겠니.. 그냥 그러려니 하고 살아야 될듯 싶다.

인터페이스란

한마디로 "표준" 이다.

앞에서 내가 이야기 한것 처럼 난 open으로 시작해서 close로 끝내고 싶다고 생각한것 처럼 이런 표준을 정한다는것이다.

그것이 전부라고 생각하면 된다. 이 표준이란것에 대해서 이야기를 해보자.

우리는 예전에 24pin의 핸드폰 충전기 이전에는 항상 그 핸드폰에 맞는 충전기를 가지고 있어야 했다. 그래서 다른회사의 핸드폰충전기로는 충전자체가 불가했다.

하지만 지금은 어떤가? 24pin으로 정통부가 표준을 정하니 모든 핸드폰이 같은라인에 충전이 가능하게 되지 않았는가?

그 24pin이란게 표준이다. 그게 인터페이스고

또 다른이야기를 해보자.

USB는 이제 기본적 인터페이스가 되어 버렸다. 이것을 통해서 우리는 프린터, 랜도 연결하고, 하드도 연결한다.

Usb가 하드는 아닐진데 말이다.

개체와 컴퓨터를 연결하는 인터페이스가 USB인것이다.

이런 인터페이스가 생성되면 어떤가? 왠지 어떤장비를 만나게 된다고 생각을 해보자.

예를 들어서 디카를 샀다고 보자. 그런데 이녀석이 USB연결포트가 있는것이다. 그럼 우리는 어떤가? 왠지 자신감이 생긴다. 이녀석의 자료는 일단은 컴퓨터에 연결하면 뭐가 될것같은것 말이다.

당신이 빔프로젝트를 샀는데 USB잭만 있다.

느낌이 좀 색다르지 않나.. 당신은 무슨장치인가보다 단지 연결할것이 USB라는 이유만으로도 일단 그 장비에 대해서 일말의 자신감(?)인지를 느낄수 있게되는것이다.

그리고 왠지 모르겠지만.. 당연히 연결잭에 꼽기만 하면 다 알아서 될것같은것들..

그런 기분이 바로 인터페이스이고.. 그렇게 하기 위해서 표준이란 걸 만드는것이다.

자… 이제 이분위기를 이어서 계속 이야기를 해보면

"I"라고 시작하는것들은 모두 인터페이스라고 하자고 정의했다. (그냥 묵시적이다. -_-;;)

Iysm 이란 인터페이스가 있다고 치자. (ysm은 나의 이니셜이다.)

이 인터페이스는 open으로 시작해서 close로 끝나는것이다.

처음 만나는 xyz라는 클래스가 있는데 이녀석이 Iysm이란 인터페이스를 가지고 있다고 생각해 보라. 단지 우리는 싱긋 미소를 짓고 이유없는 open과 close를 때리면 그녀석은 알아서 동작을 하게 될것이다. (close하다가 끼이면 정말 괴롭다. -_-;; 이런농담을 알아듣는 인간이 있을까?)

마치 usb를 이용해 컴퓨터에 디카를 연결하면 뭔가가 되는것 처럼..

인터페이스란 이런것들이다.

Ienumerable 같은것은 우리는 쉽게 접하는데 일단 이녀석이 구현되면 foreach가 가능하다는 생각이 들지 않는가?

인터페이스란 여하튼 구현되어 있다는 사실만으로 상당히 좋은것이다.

내가 가지고 있는 노트북은 "블루투스"가 안된다.

구현되어 있다면 난 핸드폰에 있는 "블루투스" 기능을 통해서 서로 연결하지 않아도 통신이 될텐데 말이다.

우리가 만드는 클래스는 위와같은 노트북, 핸드폰 처럼 하나의 객체이고

그 객체끼리의 표준을 구현해 둔다면 우리는 좀 더 유용한 클래스를 만들게 될것이다.

CF)

http://www.simpleisbest.net/archive/2008/06/23/2423.aspx

원본 위치 <http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=18&MAEULNO=8&no=1589&page=1>

일단은 앞서 보았듯이 콤보박스는 셋팅이 가능하다

그럼 콤보의 사촌인 리스트 박스는 어떻게 될까?

listBox1.DataSource = DT;

listBox1.DisplayMember = DT.Columns["Expression"].ToString();

listBox1.ValueMember = DT.Columns["Value"].ToString();



당연히 이런방식으로 처리가 될것이다.

----------------------------------

자 여기서 숙제 하나 !



이런 체크 리스트 박스를 가지고



이런식으로 테두리를 없게 하고 화면을 바탕을 같게하면.. 이런방식으로 처리가 된다.

즉 가끔 황당(?) 하다기 보다는 체크박스를 일일이 손으로 끌어다 배열하는 경우가 있던데 물론 그게 나쁘다는게 아니라.

양이 많게되면 감당이 안된다는 것이다.

또한 문제는 어쩌다 그 항목이라도 하나 늘게되면 얼마나 많은 수정을 해야하는가?

그런건 어떻게 하면 쉽게 할수 있을까?

이런방식은 프로그램의 옵션을 줘야 할때 매우 유용할수도 있다.

-----------------------------------

자 이제는 트리뷰를 한번 보자.

트리뷰의 경우는 일반적으로 인간의 머리로는 생각할수가 없다.

실수다.. 내 머리로는 힘들다. 아마도 당신의 머리로는 크게 문제가 없을듯 하다.

http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=18&MAEULNo=8&no=1224&ref=1224

이런글이 있는데.. 나쁘지 앟은듯 하다.

필요하신분은 참고를 하도록 하고..

문제는 이런경우에는.. 또 하나의 필드를 늘려야 하거나.. 한정적이게 마련이다.

하지만 인간이 보기에는 좋을듯 싶다.

문제는 자유롭게 배치하기 위해서는 어떻게 해야할까?

즉 어쩔수 없이 우리는 부모노드에 대한 값을 가지고 있는 형태로 DB를 설계해야 될것이다.

또 ER-win을.. ㅠ.ㅠ 안습이다.

트리뷰에 대한것은 우리에게 너무나도 친숙한 디렉토리의 개념을 이해하면 된다.

모두들 한번씩은 겪어야지만 하므로 대부분 전체 디렉토리의 파일을 구하는것들을 한번씩 작성해 보았다고 생각이 든다.

거의 절대라고 해야할정도로 재귀호출을 피할수 없으므로 트리뷰또한 이 재귀호출을 피할수 없다고 보면 된다 마치 이녀석은 당연히 그래야 한다는것처럼 말이다.

또는 아래에 내가 적은 폼내부의 그룹박스안에 포함된 컨트롤을 다시금 조사하기 위해서도 재귀호출을 사용했듯이 이녀석 또한 입력에도 재귀호출을 사용해야지만 한다는 이야기다.

또한 적어줄지 안적어줄지(?)는 모르지만 우리에게 친숙한 "메뉴"구조도.. 이와 유사한 방식으로 대부분 코딩을 한다.(아닌가 나만 그런거야 그랬던거야?)

뭐 이미 정석(?)적인 코딩이라서 뭐라고 할만한게 없다고 본다.

요약하자면. // 계층적 구조 = 재귀호출 알고리즘

이라는 공식이 있다.(내가 만들었던가?)

이미 널리(?) 알려져 있기도 하고 대부분 알고 있는 내용이라 대충 하고 가자.



이런식의 모양을 만들고

다시금 물리테이블을 만들자..

물론 실제적인 프로젝트에는 좀 더 많은 정보를 넣기도 한다. 게다가

몇가지 체크박스라든지 옵션을 주기위한것을 미리 정의해두기도 한다. 그런것들은 어차피 프로젝트에서 실제적인 공통모듈을 만드는 사람들의 이야기니 대충 생략하자.



대충 이렇게 또 만들기로 하자.

CREATE TABLE TreeView

(

Seq int identity NOT NULL ,

TreeViewID varchar(20) NULL ,

Expression varchar(100) NULL ,

Parent int NULL ,

Memo varchar(1000) NULL ,

ViewSeq char(18) NULL ,

UseBool char(1) NULL ,

image image NULL

)

Execution Successful

ALTER TABLE TreeView

ADD CONSTRAINT XPK트리뷰 PRIMARY KEY NONCLUSTERED (Seq ASC)

Execution Successful

Schema Generation Complete

2 query succeeded.

"XPK트리뷰 " 이라니.. ER-win은 확실히 버그가 좀 있다.

뭐 버그야 있던말던.. 예제야 무슨 상관이겠는가.

자 계속 되는 삽질을 해보도록 하자.

폼은.



이런식의 트리뷰와 오른쪽은 그냥 데이타뷰이다.

왜냐면.. 데이터가 어떻게 나오는지는 봐야되지 않겠는가 콤보박스처럼 말이다.

자 이제는 예제를 위한 데이터를 넣어야 할것이다.

Insert를 또 때려야 하나 ㅜ….ㅠ

젠장.. 예제 하나 하는데도 이렇게 손질이 많이 가다니

근데 정말 내가 왜 이걸 적고 있는지..

나중에 책이라도 하나 써야겠다. 문제는 바닥권의 실력이라 누가 사볼가 싶다만..

Insert를 때리려고 보니 위에 테이블이 다 null허용을 했네 흐흐.. 귀차니즘이다.

자 insert를 어케 적어볼까?

insert into treeview(expression,parent) values('아파트',-1)

insert into treeview(expression,parent) values('111동',0)

insert into treeview(expression,parent) values('222동',0)

insert into treeview(expression,parent) values('333동',0)

insert into treeview(expression,parent) values('444동',0)

insert into treeview(expression,parent) values('1호',2)

insert into treeview(expression,parent) values('1호',1)

insert into treeview(expression,parent) values('1호',5)

뭐가 뭔지는 모르겠고 대충 적자.



이렇게 그려지게 될것이다.

이 소스는

닷넷 프로그래밍 정복의 "김상형"씨의 소스를 적당히 수정한것임을 미리 밝힌다.



사용법은



이런식이 될것이다.

원본 위치 <http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=18&MAEULNO=8&no=1588&page=1>