※ 引述《seagal (会长绕跑了)》之铭言： : 例如FAQ跟News是两个不同的类别 : 而同样继承module这个类别 : 我之前曾做过ㄧ个EIP(企业入口网站) : 就是这样设计的 : 而如果要对应回去SQL的话 : 一样要弄出FAQ table & News table : 因为SQL没办法表现继承 : 所以最底层的那些类别还是都得帮助她们生出表格(关联) : 然後在逻辑层跟资料存取上再加以处理 : 让SQL读出来的资料能够转成OO的方式 喔对,关於继承,一开始我画出的Class Diagram是有个继承的事情, 刚开始想得很简单,继承部份实作成关联资料库的表格,只是复制出另一份表格, 而属於子类别的表格延伸的属性,就是在复制的表格上多加一些栏位. 但後来一看,问题多多,网站大部份区块都存资料在父类别的表格, 而极少数例外区块则存资料在子类别的表格, 这表示我用这个新资料库来写程式的时候, 有一部份的程式实作要引用较一般化的观点,另一部份却得引用较特殊化的观点... 修正的办法是将Class Diagram的观点层级弄得一样深,也就是不使用继承. 原本衍生的子类别就打散到父类别中... 我意思是Object类别衍生了Conference类别,在图上是以继承关系这样画, 但做成表格的时候,则是将Conference原应有的表格合并到Object表格, Conference表格则取消. 这样子虽然没有OO感,但是程式才好写啊! 接下来,撰写系统的想法是, 先在底层撰写资料介面,也就是一些非常低阶的程式,负责处理与资料库纲要 有密切关系的工作,包含资料列的输入,读取,删除,修改或调整等等. 高一点的层面,写一些模组,将底层基本功能包装起来,各模组提供介面以达成高阶功能. 然後是顶层的应用程式架构介面,这个部份是一些提供选项设定的程式, 程式设计者/系统架构者可以使用这些程式,选项选一选, 就产生一些他们所需要的特定资讯区块,譬如News啦,FAQ啦. 这个应用程式架构介面的内部运作,就是呼叫或组合前段所提到的高阶模组, 来制造系统的各功能区块. 概念归概念,实际上该整理哪些规格,仍相当不清楚. 不晓得有没有人写论文整理这方面的架构. --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 61.231.65.165