简单实现设计模式

6spring

instemast: Re:简单实现设计模式

这个很有意思：

Observer 观察者：

目的：
为了实现一种一对多的关系，当一个对象发生变化，那么所有...

这些都是方法，不是算法，具体实现方法的办法会很多。

比如说

Observer ，转换一下概念，变成一个回调列表对象，内部包含回调Obj指针，回调函数指针。如此，数据对象对此Observer调用一下CallBack，即可影响通知到所有需要依赖他的对象。这就是Observer模式，这个回调列表对象就是Observer

Mediator，例如 COM 就有它的思想

6spring

补一句，之所以叫“设计模式”，私下以为，它用于“设计”领域，是一些能解决你问题的“模式”，是一种设计思想。

PS：还记得大学时E文极烂的我，捧着该书E文原版前前后后看了大半年，也经历过为了模式而模式的阶段，工作3年多，参与了些实际项目，才真正体会到书中为什么从来只是描述思想，只提供伪码，甚至伪码都萎的厉害，它想强调的就是它是介绍一些设计上的前人经验，而不是算法。设计模式，只是把这些经验模式概括总结理论化出来，便于将至书面化罢了。

instemast

6spring: Re: Re:简单实现设计模式



这些都是方法，不是算法，具体实现方法的办法会很多。

比如说

Observer ，转换一下概念，变成一个...

所谓的“设计模式”实际上是“编程技巧”“编程方法”，
而不是“系统”。

在我看来，“设计模式”，“编程语言”是无所谓的。
这些都不是事物的根本问题，只是“编程技巧”。
------------------------------------------------------
试问，
如果 不 编程，那么如何描述一个系统呢？
------------------------------------------------------

此外，传统的“软件工程方法”“面向对象方法”
自身就存在一些自相矛盾的地方。
（比较罗索，本帖就不提了）

instemast

6spring: Re:简单实现设计模式

补一句，之所以叫“设计模式”，私下以为，它用于“设计”领域，是一些能解决你问题的“模式”，是一种设计...

你如果去独立开发一个拥有复杂游戏逻辑的大型游戏，
就知道一些东西了。。。

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

还有，在“面向对象”模式下，
很多人直接拿程序代码来当作系统，
这是不对的。

程序系统，和你要实现的系统，是不同的 pattern。

**真实系统的特点是，方程式。（==）
**程序系统的特点是，赋值。（==）

尤其是，在面向对象模式下，更容易迷惑。
认为，设计某个类，创建某个对象，就是我要实现的系统了。

6spring

感觉 instemast 兄弟的思路方向错了，建议找书来看下前言。

摘抄部分

“本书的目的就是将面向对象软件的设计经验作为设计模式记录下来。每一个设计模式系统的命名、解释和评价了面向对象系统中一个重要的和重复出现的设计。我们的目标是将设计经验以人们能够有效利用的形式记录下来。”

书中如何描述一个设计模式
模式名和分类
意图
别名
动机
适用性
结构
参与者
协作
效果
实现
代码示例
已知应用
相关模式
（PS：你可以看到代码实现所占比例）

PS：此书主要作者之一Grady Booch是Rational（现在好像IBM收购了）的首席科学家，他们所作的工作无疑就是在描述设计，而不是纠缠什么什么编程技巧之类。（不了解的，可以先了解下UML之类的东西）

PS2：虽然可能算不上大型系统，不过我独立完成了一套10W+行代码的系统，已用于商业项目1年多。做的东西越多，尤其是提供使用接口的工作做得越多，才能越发感觉一些“标准”所带来的优越。

instemast

首先我绝对不是对上述设计模式有任何不好的意见。

那些书中所说的思想，固然是十分优秀的东西！


我只是去追求，更好，更轻松的东西。有两个问题：

< A > 我的意思是，在一种十分宽松的伪代码下面，会有什么“设计模式”呢？

在这种情况下面，上述很多“设计模式”就不存在了，因为没有涉及到具体的程序语言。


下面举例说明，在宽松的伪代码下面，  一些  不存在的“设计模式”：


(1) 接口，虚函数。
在伪代码下，你可以随性调用想要调用的同名方法，而不需要声明为“virtual”。
这就有点像，IDispatch。是不是呢？ 实际上VB6,VBS都可以这样用，更不用说伪代码了吧。

(2) iterator 迭代器
（在list只有一种实现的情况下）
如果用C++等面向对象语言封装了list，那么list的遍历就比较消耗时间了。这是面向对象的坏处。
为了修正这个问题，只好引入iterator。而如果用面向过程，根本不需要iterator。更不用说伪代码了。
（在list有若干种实现的情况下）
问题归结为上面的(1)，实际上伪代码不需要写出具体的实现，只要表达意思即可。

(3)Adapter 适配器
因为是伪代码，所以  可能  不需要，如果接口“相似”，那就直接调用吧。

(4)继承和包含
在伪代码下，他们没有什么区别，这主要看你喜欢什么样的伪代码了。


< B > 使用“设计模式”过程中，我的担忧：
设计模式的贯彻，是否“严格”？是否“统一”？
不能说，“这几个系统用这几种模式”“那几种系统用那几种模式”

比如说，

某几个 大 系统，用函数调用；另几个 大 系统，用消息队列。中途也会有所更改。

这是不对的，因为函数调用，消息队列，在本质上 完全 不同的。
一些程序员，（包括去年之前的我）都意识不到这一点，认为
这两种模式，也就是具体的编码细节而以。
具体可以参考我其他的相关帖子。

instemast

关于中介者的问题，不妨可以参考“面向对象所带来的“陷阱”--以矩阵乘法为例”
如果使用C来编写代码，就不会遇到不好处理的耦合问题。因为方法定义在结构的外部。
你并不需要决定，我是否需要用“中介者”，如何设计“中介者”，每个中介者包括哪些方法？
你只需要精心设计一个个全局函数，为他们传入所需要的结构体即可。

UML图还是和具体的编程语言相关的。他不是描述一个系统的图。