??xml version="1.0" encoding="utf-8" standalone="yes"?>
查这个好W否Q其实是有缘qQ当然也有些用处Q我慢慢道来
1. ~程中,L很频J的要实现对数据q行搜烦Q查扄代码。以搜烦举例Q要l定开xӞ比如写一个函敎ͼ扑ֈlogin_begin?span lang=EN-US>login_end之间的帐戗如果这L代码写得很多了,׃犯糊涂,q里l的条glogin_begin?span lang=EN-US>login_endQ到底有没有包含login_begin?span lang=EN-US>login_end啊?不确定,然后M码一看,噢,原来没有包含呀。不定包含与否的原因,是因为没有用统一的开闭区间规则?span lang=EN-US>
2. STL的容器和法的实玎ͼ都有一个共性: q代器构成的区间是前闭后开?span lang=EN-US>, ?strong style="mso-bidi-font-weight: normal">[vector::begin(), vector::end() )Q这样在使用的时候就不会犯糊涂了Q?span lang=EN-US>
3. C++举例Q?span lang=EN-US>for(int i= 0; i < 10; ++i)q样的P代过E,使用的也是一个前闭后开区间Q?strong style="mso-bidi-font-weight: normal">[0Q?10Q?/span>Q如果这样写for(int i= 0; i <= 9; ++i)Q虽然等P但已不是一个良好的格式了;
4. 最后所说的吸取dQȝ成如下这句话Q?strong style="mso-bidi-font-weight: normal">?font color=#ff0000>业务逻辑上和目代码里用统一的开闭区间规则,推荐使用前闭后开“[ Q?/span>”Qؓ什么?因ؓ所以没原因?span lang=EN-US>
////////////////////////////////////////////////////////////////////////
?/span> a, b 是两个实?/span>, ?/span> a ≤ b.
1Q?span style="COLOR: maroon">满 a ≤ x ≤ b 的实?/span> x 的集?/span>,
表示?/span> [ a, b ], 叫做闭区?/span>;
2Q?span style="COLOR: maroon">满 a Q?/span> x Q?/span>b 的实?/span> x 的集?/span>,
表示?/span> ( a, b ), 叫做开区间;
3Q?span style="COLOR: maroon">满 a ≤ x Q?/span>bQ?/span> a Q?/span>x ≤ b 的实?/span> x 的集?/span>,
分别表示?/span> [ a, b ), ( a, b ], 叫做半开区间.
q里实数 a, b 叫做区间的端?/span>.
1、编码的工作性质是操作文本Q?/p>
2、L在做大量的相似的工作Q编写大量可cL的代码,毫无效率Q?/p>
3、h工写代码Q往往引入更多的错误,雷同的错误;
4、Lp太多旉在编码上Q成了打字员Q程序员N是做文本处理工作的Q;
5、找不到适合自己的代码分析处理工P需求往往和领域挂钩,和个人挂钩,个性化的;
6、语a的特性能够在~码上做C定的Q简化,比如宏,模版。但是受的限制太多,q且不可能实C所惌的那U智能,代码自动生成Q扩展预处理效果Q最后是你会深陷U缠其中Q可能后来却一无所P
7、清澈和q用语言的特性需要大量的l验Q实践,耗费大量的时_倒不如做个代码处理工具吧Q就是一个文本分析工兯已Q从另一面入手,把编码就看作文本操作Q化JؓQ?/p>
8、自己写的,才是最适合自己Q是能够与时p的?/p>
2、Log与业务逻辑分离的问题;
3、聚合导致接口冗余的问题?/p>
2、从XML的序列化Q装载;
3、从HTML的序列化Q装载;
4、打印PODQ?/p>
5、POD多键值比较;
6、从文g导入导出POD
7、基本上依靠保留POD信息Q可以实C个数据库?/p>
2、如果这个函数只是一个过E,没有U有数据Q那么他应该属于一l类DE的一个成员,q一l类DE就应该是一个类Q一个功能或者逻辑单元Q?/p>
3、因此,每当需要增加一个全局函数的时候,需要考虑它应该是一个什么样的类中间的一个成员函敎ͼ于是增加q样的一个类。达C集中理的而不是分散而ؓ的模式?/p>
2、业务逻辑对象Q是一l处理过E的集合Q一l函数组合成的类Q这l函数组合能够代表系l中的一个处理单元或者功能模块,因ؓ不包含数据,所以不需要锁Q?/p>
3、业务逻辑对象需要引用数据对象里面的数据来完成整个流E;
4、简单的模块Q数据对象和业务逻辑对象可以l合在一个类里面完成Q当然这是一U耦合Q?/p>
5、复杂的模块Q或者系l由多个模块构成Q那么数据对象和业务逻辑对象分离是降低复杂度的好办法Q这是一U解耦合Q?/p>
6、一个数据与业务逻辑完全分离的事例是Q数据库 + 业务层。数据库是数据的持久Q不涉及业务Q业务层是逻辑的执行不兛_数据的存储。这是一U完全的松耦合Q?/p>
7、从目前所l历以及吸取的教训与l验来看Q?font color="#ff0000">从开始就做到数据的的归数据,业务的归业务Q会大大降低复杂度,化系l,降低耦合Q十分必要!
2、DLL包装后的工厂QCManagerDLL
3、上游参与者的调用接口QCommand of callingQCAdminCmd
4、下游参与者的包装QAsk for doing sthQCSysDataBase
5、纯_的容器Q一般是比较大的容器Q因为数据种c较多,其中不含执行逻辑QCCommonData
6、容器与逻辑的结合体Q数据单一Q逻辑只关心容器里的数据;COrderFilter
7、纯_的逻辑QCClientCmdCheck
8、静态的。CErrorDescription
9、对pȝAPI的包装, CNetFuncs
那么其实q有另外一U更加重要的信息Q以前忘了记录:代码需要重构地方,比如cȝ分解Q以及如何重构?q个需要持久保留,所以最好写在电脑里?txtQ而不是纸?
1、小class模式Q让人的x炚w中了Q关注ƈ作好一个小classҎ许多Q?/p>
2、小class模式Q让一个类的代码不会那么多Q容易查找,修改Q?/p>
3、分来开来后Q关注减,更不Ҏ引入错误Q把功能拆封Ch的思维能力能够控制的规模之内?/p>
我找的一个参考原型是QSQL Server + SQL Admin
1、SQL Server是服务器Q它只有业务逻辑Q没有界面;
2、SQL Admin是SQL Server的界面,没有业务逻辑Q?/p>
3、SQL Server与SQL Admin通过TCP交互Q它们是d分离的,影射成就是:q是一U业务逻辑与界面彻底分ȝ完美形式Q?/p>
他们是如何彻底分?其实很简单:
SQL Server提供了SQL Admin的一个TCP命o调用接口Q也是Command模式来完成,影射成就是:E序的业务逻辑应该提供l界面一个Command接口Q界面只能够通过Command接口来执行命令,而不能直接操作业务逻辑里面的数据?/p>
当然Q如果考虑到界面需要不挂vQ若Command执行是阻塞模式就有些问题Q需要变换成回调q回的异步模式,q会复杂许?/p>
2、对于界面之,他要Change什么我要管Q不能让他调用能够改变模型的接口Q因为改变肯定是业务逻辑的部分,界面中直接调用方法来改变Q意味着业务逻辑存在耦合到界面中的部分,q是不允许的?/p>
3?font color="#ff0000">ȝQQ何Change都必通过UserCommandQ让UserCommandq个抽象层来完成q个事情Q一个参与者会有一pd的命令接口?/font>
==============================================================================
备注Q后来的一炚w悟,M改变和执行都是业务逻辑的部分。如果能够确保界面只能够调用Get?Q可以通过const来解冟?/p>
a、界面得C个const object* 或者const object&;
b、const对象或者指针,只能调用constҎQconst Ҏ意味着no change
2、小cL式,会不会增加复杂性?{案是部分增加,部分降低。小cL式增加了cȝ个数Q一个项目抽象体多Q复杂度高Q这不容|疑Q所有者一部分增加了复杂性。另一斚w类模式Q表明一个类只完成需要的功能Q所以在层次划分上更加的清晰Q这在一个层面上降低了复杂性?/p>
观点一Q深度带来复杂?/p>
模式1?U深度,模式2?U深度;
观点二:深度带来耦合
模式1中,A耦合了BCDE, B耦合了CDE, C耦合了DEQD耦合了E, 耦合数目为:10Q?/p>
模式2中:控制器耦合了ABCDEQ耦合数据为:5?/p>
观点三:串联改ƈ联,提取控制逻辑到独立模块,减低复杂度?/p>
比如Q数据存储模块、h格发生器、hD滤器、交叉盘h合成器、h格发布器、视图模块;
2、根据数据流图,拆分出来的独立模块,设计c;
3、类的分别原则是Q属于流E不同模块,即功能怼或者相q,也不能合成一个类Q?/p>
4、一个类只做有限的事情,大而全的类虽然有可能是一U方案,但决不是最好的ҎQ它增加了耦合和复杂性,l护性也很低Q?/p>
5、类的实现部分,量不要直接调用cL员以外的数据Q比在类的函CQ直接对某个全局对象调用ҎQ这L函数执行的前提是Q这个全局对象必须存在Q而这是一U耦合。解耦是单的Q那是把这个全局对象作ؓcd数的参数传入Q?/p>
6、类的方法接口,应该只接受能够完成类Ҏ所需要的数据Q如果传递一个指针,q个指针包含的内容,可能q远过cL法所需要的Q?/p>
7、关于上一点的解决办法是:构徏c需要参数的PODQ不要怕{换,不要怕生成时对象,事实上我需要这样做?/p>
===========================================================================================
改进后的版本
1、界面视图本来可以承担控制器的作用,也就是MVC化成MV。但是这样就必须让视图来处理命oQ试囑ֿd备双向的能力Q即解析命oQƈ向下执行同步到模型(数据)Q根据模型(数据)Q同步视图,向上更新界面Q?/p>
2、控制器和视N中在视图里面Q增加了视图的复杂性,如果增加一个命令控制器Q最l变成MVCQ那么视囑ְ只需要具备向上更新UI的能力,向下执行命o更改模型Q数?的能力交l了命o控制器。这样就实现了一上一下,各司其职的架构;
3、Ş成视囄l常不只是一U数据流Q往往多种数据共同Ş成一个视图:比如下面的结构中Q视图是由:配置,h,日志三U组合而成的;
4、增加命令控制器的作用的事显而易见的Q它让业务控制的接口可以q视图而存在。反q来理解Q如果用视图来同时充当用户命令接口,那么用户命o接口存在的前提是视图必须存在。而视图是多变的,或者说可以Ҏ不存在,那么把用户命令接口放在其中极其不合适。试想一下,一个项目它可以是个对话框,可以是个多文档,也可以是个控制台Q多变的界面Q多变的视图Q但是用户命令接口确实不便的Q把用户命o耦合到视囄实现里面去,׃合适了Q?/p>
5、把命o控制器抽d来的另一个好处是Q集中管理用L命oQ便于维护。试想一个如果对用户命o的处理分散在若干?cpp文gQ几十个C***Dailog的On***Button()消息相应函数里面Q理解,调试Q维护v来,是一件多为痛苦的事情Q?/p>
6、更多想写的一句话Q就是业务逻辑Q不要和界面耦合hQ?font color=#ff0000>界面需要做的就是:昄视图Q接受用户命令两个功能,其他的都没必要在界面里面存在。D个例子,用得很多的MFC OnTimer()函数Q事实上定时操作应该是业务逻辑的部分,攑֜界面里执行就不合适了Q?/p>
7?font color=#ff0000>界面与业务逻辑耦合E度的一个标志就是:把程序里界面代码剥离后,业务逻辑依然完整Q程序依然可以运行?/font>如上面所说的Q界面中处理OnTImer()函数Q则L界面代码后,业务逻辑׃完整了,了执行定时业务处理的部分,q就是一中明昄界面与业务逻辑耦合?/p>
8、程序可以分为很多功能模块,命o控制器能够控制这些功能模块的行ؓ是应该,q些功能模块输出信息到视N面也是应该的?/p>
===========================================================================================
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
到处拯Q粘贴绝对不是一个好的办法,保存一个备份,而不是多个备份;
只有一个备份,也就意味着代码需要达到通用U别的复用,不知不觉Q你的设计就会改善?/font>
原帖?"albcamus" 发表Q?/i>
我感觉那U遇到大型项目问题,觉得目前的开发环境不够完,从而ؓ此设计一U语a的,都是尖U的牛h。一?.........
最q新?面向语言的程序设?
QUOTE:
借助工具的帮助,允许开发者创qDSL。这LDSL当然能够最贴切地描q领域问题,从而大大提高开发效率?
[quote]原帖?"aero"]那种为项目开发语a的事情,应该是计机的传说了吧。感觉现在,语言_了。[/quote 发表Q?/i>
“ؓ目”确实太奢侈了?br>不过好的通用产品大多都有一套自q脚本语言?br>毕竟单纯?.ini 配置文g的功能太׃Q?br>不能适应客户们无Ih的需求?br>因此Q要惛_一个通用的、面向各U客L产品Q?br>必须要把业务有关的部分从核心里边剥离出来Q以便于灉|配置?br>我这D|间就天天在编q种破脚本,烦死了?/p>
]]>
2、尽一切减关联,降低耦合Q?/p>
3、努力不要调用其他对象,变量Q仅仅完成自q功能Q如果要调用Q应该作为变量传入;
4、一Ҏ及到与具体应用相关的对象Q那么这个源码的复用是一句屁话?/p>
5、函数的调用规则应该是控刉辑里的事情Q?/p>
6、耦合的模块很难进行自动化的单元测试?/p>
3、系l内的数据应该属于业务逻辑层还是数据层Q关键的一点就是看q个数据对象是否需要持久性,是不是只是运行时存在。D个例子来_数据库属于数据层Q但是从数据库内取出数据~存在系l内Q用作判断就属于业务逻辑层内的东ѝ业务逻辑层的东西可以灉|构造,但是数据层的数据q对稳定,也只要支持少量的接口Q比如增?删、修{。不能在数据层加入业务逻辑判断的代码,否则D数据层和业务层耦合。业务逻辑如果需要判断数据层内部的一些东西,应该把这些数据缓存到业务层的零时对象内?/p>