2008年（787）
分类：
2008-10-09 10:24:11
好的程式, 好的软件, 在规模不大的情况下, 你可以随意发挥你自己的想法, 做出你想做的东西.
[@more@]代码如果组织的很糟糕, 但是功能实现了之后, 整个软件就成型了, 如果幸运的话, 软件跑起来没有问题, 那么恭喜你, 你可以在后续版本中修正你的代码或者有毅力的话, 你可以完全重写大部分的代码, 因为毕竟, 这是一个小规模的软件, 也费不了多少的时间.
但是如果一套类库, 或者一个大型的软件, 代码组织的很糟糕, 那就会是你的地狱.
或许这样的说法, 很多人都明白, 但是真正做起来, 却很难.
所有我们有了这样那样的工具, 来架构我们的软件, 来架构我们的底层实现, 可是最终的, 还是不如我们的大脑和我们的经验来的有效.
一套组织糟糕的类库, 要扩展和调试简直是如入泥沼, 糟糕的类库和糟糕的软件代码组织, 耦合性一定比较高, 在调试的情况下, 你不得不在无数的函数调用中倒下, 于是重写或者放弃就是你唯一需要选择的.
要做到好的设计, 以我目前的修为, 还不能谈出一个深刻的东西来, 但是在写类库和几年的C++代码累计中, 只能说有一点浅薄的理解.
以下便是我想说的一些关于在一套类库和软件架构过程中所需要考虑的问题.
首先, 你会发现如果你要写 N 多的 .h 文件是多么痛苦的事情, 而且如何组织在 .h 文件里面的代码以及 .cpp 该做一些什么.
什么实现该写在 cpp 里, 什么直接写在 .h 的 class 里就可以了呢?
两个模块是否需要合并在一个 .h 里呢? 还是拆开写.
构架其实并不需要很多的文件, 有时候, 一个简单的 .h 就可以包含几乎一切的架构, 例如最简单的, define 掉所有你会重复用的代码, 会提高很多的效率, 例如在这个 h 里面你可以将所有的思想都模块化, 或者 OO 化, 或者独立化, 都可以在这一刻决定, 你也可以以 template 为主, 以 policy base 的方式来延伸整套系统.
一套完善的架构于是就延伸了开来.
但是. 你的思维会被局限, 也就是拘泥于一种形式.
你会发现你的很多的思路其实来自于你的经验, 如果你以前是写 OO 为主的, 那么你的整篇代码里, 能看到的都是 virtual 的东西, 如果你以前是写 template 为主, 那么你的开拓思想, 会围绕着 template 转, 即使再方便的代码, 为了保证框架的统一, 你不得不用 template 的方式来延伸.
这是很要老命的, 至少我目前是这么认为, 因为或许有更好的选择被你给抛弃掉了.
那么回头, 我想问的就是, 设计是否需要统一最初的那个架构.
一个好的架构设计并不容易, 因为你要考虑到极多的部分, 我最欣赏的就是 STL, 纵览整个 STL, 那就是一套精美的组建, 几乎任何的搭配都能完成, 耦合度相当相当地低, 使用 STL 的人或许只是为了 STL 的某些算法而用, 但是真正认真仔细的看一遍整套 STL, 会发现 STL 并不是那么简单, 整个架构, 看似紧密, 其实相当松散, 只要接口统一, 你可以随意搭配你自己的类库, 来延伸他.
那么回头再来回答一下我自己提的问题, 设计是否需要统一最初的那个架构, 答案应该是: 是, 但我认为并非全部必须.
我认为一个好的设计, 架构明确, 算法与框架分开, 在不失代码紧凑的情况下, 可以最大限度的延伸, 那是最好的设计, OO 是最漂亮的设计方法, 简单, 清晰, 而且易于扩充, 但是如果 OO 能配合 policy 的方法, 那么搭配的效果将会更高.
举例, 如果我需要写一段事件处理的代码(事实上也正是我目前正在做的), 我需要做一段 2 个函数不停调用(时间片轮巡), 直到完成函数为止, 那么我首先会想到函数的注册, 以及保证不受限制的函数参数的填入.
但是任何东西都需要取舍, 如果你用 template 来写这段代码的话, 你会将 template 的参数用作返回值或者将参数用作填入 functor 的地址, 然后在内部具现化并调用, 但是这样的方法相当的黑客, 你也可以用 OO 来写这段代码, 不去考虑函数参数的问题, 直接从基类派生下来, 任何需要注册的函数都从该基类派生, 这就为统一管理注册函数提供了相当方便的接口, 但是你不得不为了做一个注册函数而去写一个 class 来完成你的作业.
任何东西都没有最方便的一面, 只有通过取舍, 如果你想让接口变得方便, 那么你可以使用函式指针, 将所有函数参数压入一个容器里面, 用 void* 保存, 然后弹出来进行转换, 然后调用之, 接口是方便了, 代码却不易管理和理解, 如果是一套成熟的类库, 和成熟的架构, 那么 "代码看起来尽可能简单" 和 "接口用起来尽可能方便" 的原则下, 我个人以为 OO 的方法是最适合管理的.
以上只是我举例来说明我个人在其中的一点点浅薄之见, 不敢说有什么大的理解, 很多的东西, 只有在实战中才能体会到"该用什么"和"该扔什么".
还有一点, 千万不要让自己被以前的经验所"拘泥", 那将会是致命的.
