Computing 2017년 03월 14일의 Onggi 2017/03/14 02:07 by WSID


안녕하십니까. 이번에도 어김없이 WSID입니다. 'u' ;;;

구상을 하다 보니 머릿속이 많이 복잡해서, 진척이 그리 많지 않았습니다.


1. OnggiMOContainer

OnggiModuleObject 들은 포함 관계를 통해 계층 구조를 이루고 있습니다.
  • OnggiModule은 OnggiTable을 포함하고 있으며,
  • OnggiTable은 OnggiColumn을 포함하고 있습니다.
OnggiModule, OnggiTable은 OnggiMOContainer입니다. OnggiMOContainer는 다른 OnggiModuleObject를 포함하여 계층 구조를 형성하며, 추가로 OnggiConstruction과 잘 묶일 수 있는 연관된 기능을 제공합니다.
  • 이름이나 경로로 계층 구조에서 OnggiModuleObject를 얻습니다.
    이 기능은 OnggiConstruction에서 이미 있는 객체를 찾을 수 있도록 합니다.

  • 같은 이름의 객체가 추가되는 것을 막습니다.

  • OnggiMOContainer에 OnggiModuleObject를 추가하는 구체적인 함수를 제공합니다.
    OnggiMOContainer에서 OnggiConstruction에 함수를 등록해 놓았으므로, OnggiModule이나 OnggiTable에서 OnggiConstruction에 함수를 등록해 두지 않아도 됩니다.

하지만, 하나의 OnggiMOContainer에 다른 종류의 OnggiModuleObject들이 추가될 가능성이 있습니다. 예를 들면 OnggiTable이 OnggiColumn, OnggiFKey를 포함할 수 있다는 점입니다. 따라서 각각의 종류별로 관리가 필요하다는 생각이 들어, OnggiMOContainer에서 객체의 추가를 구현하지 않고, 각각의 하위클래스들 (OnggiModule이나 OnggiTable)에서 객체의 추가를 구현하고자 하였습니다.

하지만 이렇게 되면, 위에서 언급된 기능들을 각각 따로 구현해 주어야 한다는 번거로움이 생깁니다. 더구나, 이러한 번거로움은 새로이 추가되는 클래스에서도 나타나므로 이러한 방식을 적용하지 않도록 할 생각입니다.

일단은 그냥 데이터의 중복을 감수하고, 종류별로 따로 리스트나 셋에 추가하도록 할 계획입니다.
그리고 잠수함 패치 (...)로 일부 종류에 따라 이름 없는 OnggiModuleObject를 추가할 수 있도록 했습니다.

(이런 고민을 했다는 것이 큰 그림에 문제가 있을지도 모른다는 신호일지도 모르겠군요... 다시 말하면, 큰 그림에 문제로 인해 여러 문제가 나왔고, 고심을 했지만 결국은 미봉책일지도 모른다는 점이겠군요.)


2. OnggiCompound와 OnggiField

객체 타입을 저장하는 기능은 어느정도 갖추고 있습니다. 예를 들면 사람에 대한 객체를 저장할 때 이름, 성별, 생년월일을 저장할 수 있습니다.

그러나 복합적인 "값 타입"을 저장하는 면에서 OnggiColumn은 한계를 보였습니다. 예를 들면 2차원 좌표는 X, Y 좌표로 구성되어 있어서, 2개의 컬럼에 따라 배치가 되어야 하지만, OnggiColumn은 1개의 컬럼에 묶여 있기 때문에 문자열로 변환하여 저장을 하거나 커스텀 접근 함수를 사용해야 하는 불편함이 따릅니다. 따라서 이러한 복합적인 부분을 포용할 수 있는 OnggiField를 구상하고자 하였습니다. 하지만 이런 구상에는 또 많은 시간이 걸렸습니다.

처음에는 단순히 OnggiField 하나만으로 쉽게 구성이 될줄 알았습니다. 처음엔 하나의 기능만 고려가 되었었습니다.
  • (1) 복합적인 타입의 값과 단순한 타입의 값들을 서로 변환
    2차원 좌표는 바로 저장이 안되기 때문에, REAL 형의 값 2개로 분화합니다.
그러나 구조체와 객체의 구조를 나타내는 OnggiCompoundData와 OnggiCompoundObj를 고려하다보니 OnggiField에 추가로 필요한 기능이 생겼습니다.
  • (2) 구조체나 객체에서 값을 읽거나 쓰는 방법 제공.

  • (3) OnggiField가 단순히 여러 컬럼이 아니라, 다른 OnggiField들로 분화되면서 계층을 이룹니다.
따라서 이러한 기능들을 지원해 줄 수 있어야 합니다. 그러나 각각의 기능들이 서로 다른 만큼 하나의 클래스로는 표현하지 못하고, 3개의 타입으로 분화 되었습니다.

일단은, 저는 (2)를 OnggiField의 하위 클래스를 통해서 제공할 구상을 했습니다. (2)의 항목은 OnggiCompoundData와 OnggiCompoundObj에서만 사용되는 기능이며, 해당 기능에서 값을 읽거나 쓰는 방법이 교체되는 일이 일어나지 않기 때문입니다.

(3)의 경우는 OnggiFieldHierarchy라는 간이 구조체를 통해 제공하고자 합니다. (2)와는 달리 (3)의 경우는 다른 종류의 OnggiCompound에도 영향을 미치고, 하나의 OnggiField가 여러 계층 구조에 나타나는 경우도 생깁니다. 즉, 동일한 계층 구조가 여러 군데에서 나타날 수 있습니다. 따라서 쉽게 복사가 될 수 있는 간이 구조체를 사용하기로 하였습니다.

(1)의 기능은 OnggiFieldContent라는 인터페이스를 통해 제공하기로 하였습니다. OnggiField의 하위 클래스로 구성하는 것도 나쁘진 않습니다만, 인터페이스를 구성하면OnggiCompound의 하위 클래스도 구현이 가능하여, 불필요한 클래스를 줄일 수 있습니다.



3. OnggiTable과 OnggiColumn

OnggiTable과 OnggiColumn은 OnggiCompoundTable과 OnggiField로 대체할 예정입니다. 만일 특정한 테이블이 필요하다면 OnggiCompoundTable을 제공할 수 있고, 특정 컬럼이 필요하다면 OnggiFieldHierarchy를 제공할 수 있을 것입니다. (OnggiField의 경우는 계층 정보가 없기 때문에...)

이러한 결정을 내린 이유는 OnggiTable과 OnggiColumn에 맞추어 이에 맞는 반대편 클래스가 필요했었기 때문입니다. 만일 OnggiIndex라는 클래스가 추가된다면, OnggiCompoundTable를 위해 다른 클래스가 추가되어, OnggiIndex로 분화하는 기능을 갖추어야 합니다. 이러한 중복을 줄이기 위해 OnggiTable과 OnggiColumn은 제거될 예정입니다.



흠... 쓰다보니까 제가 봐도 많이 복잡하군요... (...)
원래는 추가된 점이나 바뀐점을 적어야 하는데, 이번에는 구상한 점들을 적어놨군요..;;

Computing 2017년 02월 26일의 Onggi 2017/02/26 12:16 by WSID

안녕하십니까. 이번에도 Onggi를 수정하였습니다.



특별한 기능 추가는 없었지만, 이번에도 내부 구조 변경 등이 있었습니다.

1. ModuleFactory, ModuleFactoryGroup에서 ModulePool로 변경

Module이 Store별로 상태를 가지고 있어야 할 경우를 대비하여, 아예 각 Store별로 Module 객체를 생성하도록 하였습니다. 그러나 Module이 Store별로 따로 가지고 있어야 할 상태가 없어서, Store 하나 마다 Module을 생성하는 것은 낭비가 되었습니다.

따라서 Store마다 Module을 생성해줄 ModuleFactory 또한 불필요해 졌습니다. 대신 Module을 직접 등록할 수 있는 ModulePool을 구성하였습니다.



ModuleFactory을 생성한 다음 ModuleFactoryGroup에 추가

Module을 생성한 후, ModulePool에 추가


ModuleFactoryGroup에서 ModuleFactory를 찾은 후 ModuleFactory에서 Module 생성

ModulePool에서 Module을 찾는다.



2. 앞으로

OnggiField, OnggiCompound

현재 OnggiColumnInstance와 OnggiTableObj을 통해 객체를 저장하고 있습니다. 그러나 OnggiColumnInstance에 기반한 방법은 독특한 타입을 저장할 때 사용할 수 있지만, 구조체와 같이 한 컬럼에 넣기 어려운 복잡한 타입을 다룰 때에는 한계를 곧잘 드러냅니다.

따라서, 지난 글에서 이야기 한 것과 같이, OnggiColumn을 단순화 하고, OnggiColumnInstance에서 추가된 역할을 새로이 OnggiField로 옮겨 보려고 합니다.
또한 OnggiTable이 OnggiField를 받을 수 있으면 좋겠지만, 일단은 어려울 것 같으므로, OnggiCompound도 추가하고자 합니다.

주로 1:n, n:n을 처리하기 위해 OnggiRelation도 추가할 생각을 하고 있지만, 일단 이것부터 처리하는 것이 우선이 될 듯 합니다.


이상입니다. 'u'

Pictures 한밤중에 끄적이는 낙서.. 2017/02/21 01:30 by WSID

가끔씩 낙서를 그려주니 재밌고 좋군요.

피로하다는 것이 문제지만...;;



Computing 2017년 02월 15일의 Onggi 2017/02/15 03:17 by WSID



안녕하십니까. 다소 타이밍이 늦였지만, 이렇게 글을 올려봅니다.

1. 2주간 한 것들 ...


지지난주부터 진행된 일이라고는...

유감스럽게도 (...) 빼먹은 단위 테스트를 집어 넣거나 하진 않고, 소스코드를 다듬는 수준에서 끝났습니다.
전반적인 구조를 변경할 생각을 하니 (착하신 여러분들은 따라하시면 안됩니다.) 힘이 빠져서입니다.


2. 구조 변경


구조의 변경이 작은 부분이 아니라, 다양한 부분을 변경하기 때문에 하위로 2부분을 나누게 되었습니다. 전반적인 구조는 이 글에서 설명해 놓았습니다.

(다시한번 말하지만, 착하신 여러분들은 따라하시면 안됩니다. 시간을 들여 열심히 만든 탑을 스스로 무너트려야 하는 고통을 받게 됩니다.)




가. ModuleFactory, ModuleFactoryGroup

Module과 이를 구성하는 ModuleObject가 혹여나 Store별로 따로 저장해야 할 값이 생길 경우를 대비하여, 각각의 Store별로 Module 객체를 생성하여 가지고 다니는 형식으로 구성하였습니다. (다시 말하면, 열어놓은 파일마다, Module 객체가 생성되는 것입니다.)

Store별로 Module에 따로 저장할 값을 가질 필요가 없고, 파일을 열 때마다, Module들을 생성하는 것은 부적합하다고 생각하였습니다. Store 하나를 위해 생성될 Module이 한 둘이 아니기 때문입니다.

따라서 ModuleFactoryGroup에서 ModuleFactory를 얻은 뒤 Module을 생성하지 않고, ModulePool에서 Module을 얻는 방식을 사용할 예정입니다.

나. Field와 Compound

Onggi에서는 테이블과 컬럼을 조작하기 쉽도록 Table과 Column 객체를 생성하였습니다. 그리고 이러한 역할에서 더 나아가, 다른 객체에 대한 정보를 저장할 수 있는 TableObj와 객체에서 값을 얻어내는 기능을 추가한 ColumnInstance를 추가하였습니다.

하지만, 이러한 기능 확장은 추가된 특성치가 테이블이나 컬럼에 묶여 버린다는 단점을 가지고 있습니다. 가령 예를 들면, 저장할 객체의 하위 필드가 구조체일 경우, 해당 구조체에 2개 이상의 컬럼을 배치하기 쉽지 않습니다. (물론 일부 DBMS의 경우 구조체 타입을 만들 수 있지만, 주 타겟인 SQLite는 지원하지 않는군요...)

따라서 테이블이나 컬럼보다는, 여러 컬럼들을 아우르는 Field와 이들을 모은 Compound로 나타내고자 합니다. (Compound가 테이블의 집합이 아닌건, 단순한 구조체의 경우 테이블을 만들기보단, 다른 테이블 내에서 여러 컬럼에 걸친 형태로 표현되는 것이 더 낫기 때문입니다.)


3. 객체간 관계

일반적으로 객체는 단순한 데이터가 아닌 이상 다른 객체 (같은 종류일 수 있고, 다른 종류일 수 있습니다.) 와 연관되어 있습니다. C를 비롯한 언어에서는 이러한 참조가 "포인터"의 형태로 나타나지만, 데이터베이스에서는 외래키(컬럼의 값은 항상 참조되는 테이블의 컬럼의 값으로 존재해야 하는 제약조건)의 형태로 나타납니다.

이러한 것을 중간에서 처리할 수 있도록 하는 Relation 객체를 만들고자 합니다.


+

글을 쓰고 지우고 쓰고를 반복하니 확실히 지난번에 썼다가 지워버린 글보단 나아진 듯 하군요... 역시.. 글을 안쓰다보니 글쓰기 능력이 퇴화......

2017년 1월 24일의 근황 2017/01/24 14:02 by WSID

[ 위 그림은 예전에 그린 그림입니다. ]

오랫만입니다.. =ㅂ=;;;
비슷 비슷한 날들을 지내홨었지만, 그러한 날들이라도 쌓이고 쌓이다 보면 뭔가 이야깃거리가 되는 것 같습니다.

1. Onggi

일단 얼추 기본적인 뼈대는 갖춘것 같으니, 기능의 추가는 잠시 멈추고, 일단 내부 정리를 하면서 0.2를 준비해야 할 것 같습니다. 아직 Pencilator에 필요한 기능을 갖춘건 아니지만, (서로 연관된 객체를 저장 및 불러오기 등..) 지금껏 급히 작성해온 감이 있고 많은 기능들이 추가되어 복잡해지기도 하였습니다. 또 불완전한 기능을 제거하는 시간도 될 것 같습니다.

일단은 이번주와 다음주를 통해 정리 작업을 마치고 0.2라고 딱지를 붙여야 할 것 같습니다.



2. Haskell의 겉을 핥아보기

제가 주로 쓰는 언어가 C이고 가끔씩 만지작 거리는 언어는 Vala를 비롯하여, 객체지향적 성질을 가지고 있는 언어입니다. 하지만, 함수형 언어가 대두되고 있는 상황인지라, 저는 이 중에서 Haskell의 겉을 핥아 보았습니다. 하지만, 역시나 크게 다른 문제 해결 방식에 너무 적응하기 어렵군요... 객체가 중심이 아니라, 함수가 중심이 되다보니 힘든 것 같습니다.

"함수형 사고"라는 책이 도서관에 있어서 한번 읽어본 적이 있는데, 다시 한번 읽어보면 어떤 느낌일지..



3. Astroneer

행성의 자원을 채취해서 기지와 차량 등을 건설하고, 더 깊은 곳의 자원을 캐러 가거나, 아니면 다른 행성의 자원을 캐러가는 게임인 Astroneer를 구매햐여 플레이 하였습니다. 높은 컴퓨터 사양을 요구하는 것만 빼면, 극 초기 버전임에도 재밌게 플레이 하였습니다.

일단 해볼껀 다 해보았기 때문에, 어느정도 업데이트가 있기 전까진 당분간은 덮어둘 듯 싶습니다.. (...)




4. "The Lost" in Binding of Isaac: Afterbirth

Binding of Isaac: Afterbirth에서 The Lost를 언락하여 플레이 하고 있습니다. 옛날 보다는 많이 언락이 쉬워져서 언락을 할 수 있었습니다만, 한방만 맞아도 죽는 특성도 있지만, 기본 성능이 이를 벌충해 주지 못하기 때문에 플레이 자체도 많이 어렵습니다.

(어떠한 공격 1회에도 사망, 빨간 하트 충전 불가, 소울 하트 등은 즉시 증발)

하지만 이 캐릭터로 보스 클리어시 좋은 아이템이 언락되기도 하기 때문에 일단은 플레이 하고 있습니다.

(그리고 나중에 그리드도 언락을)



5. Lollypop 음악 플레이어


음악 플레이어로 Gnome Music을 써보았다가, Lollypop 음악 플레이어를 써보았습니다. 둘다 제목 표시줄에 버튼 등을 달고 있지만, 자세히 보면 다른 모양을 하고 있습니다. 개인적으로 제일 맘에 드는 부분은 창을 최소한으로 줄이면 미니모드로 작동하는 점이었습니다.

[좌측: Gnome Music  ...  우측: Lollypop]
[아래: Lollypop 창을 아주 작게 줄였을 때]



1 2 3 4 5 6 7 8 9 10 다음