查这个好笑否？其实是有缘由的，当然也有些用处，我慢慢道来

1.      编程中，总是很频繁的要实现对数据进行搜索，查找的代码。以搜索举例，要给定开关条件，比如写一个函数，找到login_begin到login_end之间的帐户。如果这样的代码写得很多了，就会犯糊涂，这里给的条件login_begin到login_end，到底有没有包含login_begin和login_end啊？不确定，然后翻代码一看，噢，原来没有包含呀。不确定包含与否的原因，是因为没有使用统一的开闭区间规则。

2.      STL的容器和算法的实现，都有一个共性： 迭代器构成的区间是前闭后开的, 如[vector::begin(), vector::end() )，这样在使用的时候就不会犯糊涂了；

3.      C++举例，for(int i= 0; i < 10; ++i)这样的迭代过程，使用的也是一个前闭后开区间，[0， 10），如果这样写for(int i= 0; i <= 9; ++i)，虽然等价，但已不是一个良好的格式了；

4.     最后所说的吸取养分，总结成如下这句话：在业务逻辑上和项目代码里使用统一的开闭区间规则，推荐使用前闭后开“[ ）”，为什么？因为所以没原因。

////////////////////////////////////////////////////////////////////////

设 a, b 是两个实数, 且 a ≤ b.

1）满足 a ≤ x ≤ b 的实数 x 的集合,
      表示为 [ a, b ], 叫做闭区间;

2）满足 a ＜ x ＜b 的实数 x 的集合,
      表示为 ( a, b ), 叫做开区间;

3）满足 a ≤ x ＜b， a ＜x ≤ b 的实数 x 的集合,
      分别表示为 [ a, b ), ( a, b ], 叫做半开区间.

这里实数 a, b 叫做区间的端点.

1、编码的工作性质就是操作文本；

2、总是在做大量的相似的工作，编写大量可类比的代码，毫无效率；

3、人工写代码，往往引入更多的错误，雷同的错误；

4、总是花费太多时间在编码上，成了打字员，程序员难道就是做文本处理工作的？；

5、找不到适合自己的代码分析处理工具，需求往往和领域挂钩，和个人挂钩，个性化的；

6、语言的特性能够在编码上做到一定的智能，简化，比如宏，模版。但是受的限制太多，并且不可能实现你所想要的那种智能，代码自动生成，扩展预处理效果，最后是你会深陷纠缠其中，可能后来却一无所获；

7、清澈和运用语言的特性需要大量的经验，实践，耗费大量的时间，倒不如做个代码处理工具吧，就是一个文本分析工具而已，从另一面入手，把编码就看作文本操作，化繁为简；

8、自己写的，才是最适合自己，是能够与时俱进的。

2、Log与业务逻辑分离的问题；

3、聚合导致接口冗余的问题。

2、从XML的序列化，装载；

3、从HTML的序列化，装载；

4、打印POD；

5、POD多键值比较；

6、从文件导入导出POD

7、基本上依靠保留POD信息，可以实现一个数据库了

2、如果这个函数只是一个过程，没有私有数据，那么他应该属于一组类似过程的一个成员，这一组类似过程就应该是一个类，一个功能或者逻辑单元；

3、因此，每当需要增加一个全局函数的时候，就需要考虑它应该是一个什么样的类中间的一个成员函数，于是增加这样的一个类。达到了集中管理的而不是分散而为的模式。

2、业务逻辑对象，是一组处理过程的集合，一组函数组合成的类，这组函数组合能够代表系统中的一个处理单元或者功能模块，因为不包含数据，所以不需要锁；

3、业务逻辑对象需要引用数据对象里面的数据来完成整个流程；

4、简单的模块，数据对象和业务逻辑对象可以综合在一个类里面完成，当然这是一种耦合；

5、复杂的模块，或者系统由多个模块构成，那么数据对象和业务逻辑对象分离是降低复杂度的好办法，这是一种解耦合；

6、一个数据与业务逻辑完全分离的事例是：数据库 + 业务层。数据库是数据的持久，不涉及业务，业务层是逻辑的执行不关心数据的存储。这是一种完全的松耦合；

7、从目前所经历以及吸取的教训与经验来看：从开始就做到数据的的归数据，业务的归业务，会大大降低复杂度，简化系统，降低耦合，十分必要！

2、DLL包装后的工厂；CManagerDLL

3、上游参与者的调用接口，Command of calling；CAdminCmd

4、下游参与者的包装，Ask for doing sth；CSysDataBase

5、纯粹的容器，一般是比较大的容器，因为数据种类较多，其中不含执行逻辑；CCommonData

6、容器与逻辑的结合体，数据单一，逻辑只关心容器里的数据；COrderFilter

7、纯粹的逻辑；CClientCmdCheck

8、静态的。CErrorDescription

9、对系统API的包装， CNetFuncs

那么其实还有另外一种更加重要的信息，以前忘了记录：代码需要重构地方，比如类的分解，以及如何重构。(这个需要持久保留，所以最好写在电脑里成.txt，而不是纸上)

1、小class模式，让人的关注点集中了，关注并作好一个小class容易许多；

2、小class模式，让一个类的代码不会那么多，容易查找，修改；

3、分来开来后，关注减少，更不容易引入错误，把功能拆封到人的思维能力能够控制的规模之内。

我找的一个参考原型是：SQL Server + SQL Admin

1、SQL Server是服务器，它只有业务逻辑，没有界面；

2、SQL Admin是SQL Server的界面，没有业务逻辑；

3、SQL Server与SQL Admin通过TCP交互，它们是彻底分离的，影射成就是：这是一种业务逻辑与界面彻底分离的完美形式；

他们是如何彻底分离？其实很简单：

SQL Server提供了SQL Admin的一个TCP命令调用接口，也就是Command模式来完成，影射成就是：程序的业务逻辑应该提供给界面一个Command接口，界面只能够通过Command接口来执行命令，而不能直接操作业务逻辑里面的数据。

当然，如果考虑到界面需要不挂起，若Command执行是阻塞模式就有些问题，需要变换成回调返回的异步模式，这会复杂少许。

2、对于界面之流，他要Change什么我要管，不能让他调用能够改变模型的接口，因为改变肯定是业务逻辑的部分，界面中直接调用方法来改变，意味着业务逻辑存在耦合到界面中的部分，这是不允许的。

3、总结，任何Change都必须通过UserCommand，让UserCommand这个抽象层来完成这个事情，一个参与者会有一系列的命令接口。

==============================================================================

备注：后来的一点领悟，任何改变和执行都是业务逻辑的部分。如果能够确保界面只能够调用Get?，可以通过const来解决。

a、界面得到一个const object* 或者const object&;

b、const对象或者指针，只能调用const方法，const 方法意味着no change

2、小类模式，会不会增加复杂性？答案是部分增加，部分降低。小类模式增加了类的个数，一个项目抽象体越多，复杂度越高，这不容置疑，所有者一部分增加了复杂性。另一方面小类模式，表明一个类只完成需要的功能，所以在层次划分上更加的清晰，这在一个层面上降低了复杂性。

观点一：深度带来复杂性

模式1为5级深度，模式2为2级深度；

观点二：深度带来耦合

模式1中，A耦合了BCDE, B耦合了CDE, C耦合了DE，D耦合了E, 耦合数目为：10；

模式2中：控制器耦合了ABCDE，耦合数据为：5。

观点三：串联改并联，提取控制逻辑到独立模块，减低复杂度。

      比如：数据存储模块、价格发生器、价格过滤器、交叉盘价格合成器、价格发布器、视图模块；

2、根据数据流图，拆分出来的独立模块，设计类；

3、类的分别原则是：属于流程不同模块，即使功能相似或者相近，也不能合成一个类；

4、一个类只做有限的事情，大而全的类虽然有可能是一种方案，但决不是最好的方案，它增加了耦合和复杂性，维护性也很低；

5、类的实现部分，尽量不要直接调用类成员以外的数据，比在类的函数中，直接对某个全局对象调用方法，这样类函数执行的前提是：这个全局对象必须存在，而这是一种耦合。解耦是简单的，那就是把这个全局对象作为类函数的参数传入；

6、类的方法接口，应该只接受能够完成类方法所需要的数据，如果传递一个指针，这个指针包含的内容，可能远远超过类方法所需要的；

7、关于上一点的解决办法是：构建类需要参数的POD，不要怕转换，不要怕生成临时对象，事实上我需要这样做。

===========================================================================================

改进后的版本

1、界面视图本来可以承担控制器的作用，也就是MVC简化成MV。但是这样就必须让视图来处理命令，试图必须具备双向的能力：即解析命令，并向下执行同步到模型（数据)；根据模型（数据)，同步视图，向上更新界面；

2、控制器和视图集中在视图里面，增加了视图的复杂性，如果增加一个命令控制器，最终变成MVC，那么视图就只需要具备向上更新UI的能力，向下执行命令更改模型（数据)的能力交给了命令控制器。这样就实现了一上一下，各司其职的架构；

3、形成视图的经常不只是一种数据流，往往多种数据流共同形成一个视图：比如下面的结构中，视图是由：配置流，价格流，日志流三种组合而成的；

4、增加命令控制器的作用的事显而易见的，它让业务控制的接口可以脱离视图而存在。反过来理解，如果用视图来同时充当用户命令接口，那么用户命令接口存在的前提是视图必须存在。而视图是多变的，或者说可以根本不存在，那么把用户命令接口放在其中极其不合适。试想一下，一个项目它可以是个对话框，可以是个多文档，也可以是个控制台，多变的界面，多变的视图，但是用户命令接口确实不便的，把用户命令耦合到视图的实现里面去，就不合适了；

5、把命令控制器抽离出来的另一个好处是：集中管理用户的命令，便于维护。试想一个如果对用户命令的处理分散在若干个.cpp文件，几十个C***Dailog的On***Button()消息相应函数里面，理解，调试，维护起来，将是一件多为痛苦的事情；

6、更多想写的一句话，就是业务逻辑，不要和界面耦合起来，界面需要做的就是：显示视图，接受用户命令两个功能，其他的都没必要在界面里面存在。举个例子，用得很多的MFC OnTimer()函数，事实上定时操作应该是业务逻辑的部分，放在界面里执行就不合适了；

7、检测界面与业务逻辑耦合程度的一个标志就是：把程序里界面代码剥离后，业务逻辑依然完整，程序依然可以运行。如上面所说的，界面中处理OnTImer()函数，则去掉界面代码后，业务逻辑就不完整了，少了执行定时业务处理的部分，这就是一中明显的界面与业务逻辑耦合。

8、程序可以分为很多功能模块，命令控制器能够控制这些功能模块的行为是应该，这些功能模块输出信息到视图里面也是应该的。

===========================================================================================

struct ViewResult
{
    struct ViewSource
    {
        char  symbol[12];
        int        digits;
        double minprice;
        double minspread;
        double peerminm;
        BOOL    usepremium;
        double premiumex;
        char   session_current;
        char    remark[256];
        BOOL   session_enable;
    } view_source;
    struct ViewTrans
    {
        BOOL   b_bid_success;
        BOOL    b_ask_success;
    }view_trans;
    struct ViewPrice
    {
        double bid;
        double ask;
    }view_price;
};

    BOOL UpdateViewSource(int index, const ViewResult::ViewSource& vs);
    BOOL UpdateViewTrans(int index, const ViewResult::ViewTrans& vt);
    BOOL UpdateViewPrice(int index, const ViewResult::ViewPrice& vp);
    BOOL UpdateViewMsg(const ViewMsg& vm);
p

到处拷贝，粘贴绝对不是一个好的办法，保存一个备份，而不是多个备份；

只有一个备份，也就意味着代码需要达到通用级别的复用，不知不觉，你的设计就会改善。

原帖由 "albcamus" 发表：
我感觉那种遇到大型项目问题，觉得目前的开发环境不够完美，从而为此设计一种语言的，都是顶尖级的牛人。一般?.........

最近新闻:面向语言的程序设计.

QUOTE:

借助工具的帮助，允许开发者创建自己的DSL。这样的DSL当然能够最贴切地描述领域问题，从而大大提高开发效率。

[quote]原帖由 "aero"]那种为项目开发语言的事情，应该是计算机的传说了吧。感觉现在，语言足够了。[/quote 发表：
“为项目”确实太奢侈了。
不过好的通用产品大多都有一套自己的脚本语言。
毕竟单纯的 .ini 配置文件的功能太弱了，
不能适应客户们无穷无尽的需求。
因此，要想做一个通用的、面向各种客户的产品，
必须要把业务有关的部分从核心里边剥离出来，以便于灵活配置。
我这段时间就天天在编这种破脚本，烦死了。

2、尽一切减少关联，降低耦合；

3、努力不要调用其他对象，变量，仅仅完成自己的功能，如果要调用，应该作为变量传入；

4、一点涉及到与具体应用相关的对象，那么这个源码的复用就是一句屁话。

5、函数的调用规则应该是控制逻辑里的事情；

6、耦合的模块很难进行自动化的单元测试。

3、系统内的数据应该属于业务逻辑层还是数据层？关键的一点就是看这个数据对象是否需要持久性，是不是只是运行时存在。举个例子来说，数据库属于数据层，但是从数据库内取出数据缓存在系统内，用作判断就属于业务逻辑层内的东西。业务逻辑层的东西可以灵活构造，但是数据层的数据就相对稳定，也只要支持少量的接口，比如增、 删、修等。不能在数据层加入业务逻辑判断的代码，否则导致数据层和业务层耦合。业务逻辑如果需要判断数据层内部的一些东西，应该把这些数据缓存到业务层的零时对象内。