OO设计的重要原则(以供参考,欢迎讨论)
1．开闭原则 (Open-Closed Principle)
模块在开放性方面应该是开放的（易于扩展），在更改性方面应该是封闭的（易于修改而不需要更改类的源代码）。
实现OCP的技术主要有多态和模板，均基于抽象。我们应该努力实现OCP以高效地复用和维护代码。
2．Liskov替换法则 （Liskov Substitution Principle）
使用指向基类B（抽象类或者接口）引用的模块（方法或者类），必须能够接受任何继承或实现B的具体类S，仍然能够正常工作而不需要知道具体类的实现细节。
3．针对接口编程
组件之间应该尽可能使用接口进行通讯，具体的业务逻辑由子类去实现不变的接口。
4．将可变的部分和不可变的部分分离
任何时候都将不变的接口与可变的实现分离。 如果使用继承的复用技术，我们可以在抽象基类或接口中定义好不可变的部分，而由其子类去具体实现可变的部分。如果使用对象组合，我们可以定义好不可变的部分，而可变的部分可以由不同的组件运行时动态配置。
5．优先使用对象组合，而不是类继承
优先使用黑箱复用（对象组合）而不是白箱复用（类继承）。利用对象组合我们可以在运行时动态配置组件的功能，并防止类层次规模的爆炸性增长。
6．高内聚，低耦合
很简单的一句话却是软件设计的精华所在：一个模块包含的功能彼此相关，相互依赖，而与外界很少关联，并且没有承担过多的责任，这样的模块（子系统或者类）称之为高内聚的(High Cohesion)。如果一个模块为实现自身的功能，并不需要了解或者依赖太多外部的知识，则该模块是低耦合的(Low Coupling)。
7．使用多态机制消除大量的IF/CASE语句
大量的IF/CASE使得代码难于维护和扩展，我们应该用多态来取代条件判断逻辑，状态和策略模式都可以帮助实现这一机制。
8．在多线程程序中谨慎地使用Singleton模式
Singleton模式在多线程应用中的不恰当使用会导致性能问题，在用到该模式时尽可能使用lazy initialization 方法。
问题点数：100、回复次数：121Top
1 楼OnlyFor_love（『勾勾手指头 一辈子不分手』）回复于 2005-11-17 15:39:55 得分 2
楼主理解的很深刻，向你学习Top
2 楼OnlyFor_love（『勾勾手指头 一辈子不分手』）回复于 2005-11-17 15:43:14 得分 2
我觉得代码的复用也是很重要的。
也就是说写出来的程序的可扩展性要好，以后的话只需要添加少量的代码就可以。Top
3 楼jxdn_yang（(我不想做IT了)）回复于 2005-11-17 15:43:17 得分 2
学习,楼主有没有示例让我们更直观的学习Top
4 楼gemouzhi（^_^）回复于 2005-11-17 15:44:15 得分 2
使用多态机制消除大量的IF/CASE语句
请问这句话是不是你自己总结的？Top
5 楼jxdn_yang（(我不想做IT了)）回复于 2005-11-17 15:45:00 得分 2
关于接口的问题,一般是使用抽象类好还是接口??Top
6 楼ASPserver（即便你从不绽放,淹没在花团似锦的芳香,她也会千百度中寻至你气息,只蓦然回首间,只回首间的一眼,你便知）回复于 2005-11-17 15:48:28 得分 2
帮顶Top
7 楼silverend（偶尔转转）回复于 2005-11-17 15:56:51 得分 2
UP!Top
8 楼majy（)Oo.冲天剑.oO()(为这个国家做点什么吧）回复于 2005-11-17 16:06:14 得分 2
纯接分Top
9 楼kingofhawks（蓝鹰）回复于 2005-11-17 16:12:11 得分 0
OnlyFor_love(【光在哪里，荣耀就在哪里】) :
我觉得代码的复用也是很重要的。
也就是说写出来的程序的可扩展性要好，以后的话只需要添加少量的代码就可以。
----------
是的,一个好的设计应该使得在应用中不出现冗余代码,并且易于扩展.Top
10 楼kingofhawks（蓝鹰）回复于 2005-11-17 16:13:31 得分 0
jxdn_yang(张婷) ( )
学习,楼主有没有示例让我们更直观的学习
---------
呵呵，设计这东西很难说举个例子就能说得清楚，我想需要经验以及在项目中不断地运用才能够有更深的体会.Top
11 楼kingofhawks（蓝鹰）回复于 2005-11-17 16:17:54 得分 0
gemouzhi(gemouzhi) ( )
使用多态机制消除大量的IF/CASE语句
请问这句话是不是你自己总结的？
------------
这个观点很多大师早就提出来了,当然也要看项目具体需要，如果条件语句本身就很简单,而且也没有太多的逻辑操作,那可能也没有必要非得使用多态甚至State,Strategy等模式,因为那样会增加应用的复杂度,也使得代码的理解相对困难,因为你不可能指望任何一个人都能很容易弄懂这些技术。Top
12 楼jxdn_yang（(我不想做IT了)）回复于 2005-11-17 16:26:14 得分 2
如果我没有记错的话,楼主的家人身体是否抱恙,现在可好了??如果记错,请见谅,我只是关心下Top
13 楼kingofhawks（蓝鹰）回复于 2005-11-17 16:26:46 得分 0
jxdn_yang(张婷) ( )
关于接口的问题,一般是使用抽象类好还是接口??
---------------
抽象类本身已经位于很高的层次,一般在以下情况下会考虑用抽象类而不用接口.
(1)有公共的一些instance变量必须在顶层类加以抽象;
(2)在你的类层次中可能会有一些模板操作,或者固定的实现.
其他情况下一般考虑用接口,因为接口具有最大的灵活性.
例如,在我设计的一个类层次中需要定义三个接口
public void f1();
public void f2();
public void f3();
而f3()的功能是先后执行f1,f2,如果你用接口就没有办法把这些定义完全表达出来
而用abstract class 则可以
abstract class Test
{
abstract public void f1();
abstract public void f2();
public void f3()
{
f1();
f2();
}}
在这个例子中是一个典型的模版模式的实现,在基类中定义确定的操作序列,而不同的序列则由具体子类实现.
Top
14 楼kingofhawks（蓝鹰）回复于 2005-11-17 16:28:21 得分 0
jxdn_yang(张婷) ( )
如果我没有记错的话,楼主的家人身体是否抱恙,现在可好了??如果记错,请见谅,我只是关心下
-----------------
非常感谢,那个帖子我已结掉.还好没有大恙,经过调养身体应该能慢慢好起来的吧,我想过几天再回家看看.Top
15 楼jxdn_yang（(我不想做IT了)）回复于 2005-11-17 17:28:08 得分 2
^_^Top
16 楼gemouzhi（^_^）回复于 2005-11-17 18:34:39 得分 2
gemouzhi(gemouzhi) ( )
使用多态机制消除大量的IF/CASE语句
请问这句话是不是你自己总结的？
------------
这个观点很多大师早就提出来了,当然也要看项目具体需要，如果条件语句本身就很简单,而且也没有太多的逻辑操作,那可能也没有必要非得使用多态甚至State,Strategy等模式,因为那样会增加应用的复杂度,也使得代码的理解相对困难,因为你不可能指望任何一个人都能很容易弄懂这些技术。
---------------------
---------------------
你误解我的意思了，我再问一下，（呵呵，我是不是有些烦。）
是哪位大师或文章中提到过这样的观点？
thanks for the reply,能给我些英文的文章是最好了，thank you so much.
至于那些模式消除大量的IF/CASE语句文章就不用了，我读过很多了，希望你能提供
一些关于多态机制消除大量的IF/CASE语句的文章．Top
17 楼gemouzhi（^_^）回复于 2005-11-17 18:40:22 得分 2
或者某个人，或一些线索，我能google的到就ＯＫ了Top
18 楼kingofhawks（蓝鹰）回复于 2005-11-17 19:09:10 得分 0
To gemouzhi(gemouzhi)
呵呵，不烦拉~~本来开这个帖子就是大家讨论的,我的经验也并不丰富呀,偶今年刚毕业的.
Refactoring: Improving the Design of Existing Code
一书中chapter 9 Replace Conditional with Polymorphism
其实,state/strategy的实现方法不也是基于多态的吗?
Top
19 楼taoyuming（知识就是财富）回复于 2005-11-17 19:09:16 得分 2
我懂的不多,但是我还是觉得复用很重要.
Top
20 楼mnbvc874（Java EE）回复于 2005-11-17 22:17:23 得分 2
昨天刚学，哈哈Top
21 楼gemouzhi（^_^）回复于 2005-11-18 00:02:29 得分 2
恩，我主要想找一篇类似于Martin的Replace Conditional with Polymorphism的文章
Martin这个老好人（同感的姐妹们回个话啊），老是提一些“大家都好”的观点。
因为在有些业务逻辑下，条件是非常复杂，需要大幅度的Refactoring。
如case和if嵌套，我都不用举什么业务逻辑，就说把12个月case掉，但2月需要if。
按这种逻辑下去，就会出现一个类的继承体系结构出来。有时因为条件的复杂，还需要
划分类的粒度，或多重继承，这并没提高我的代码的质量，所以我怀疑这个Refactoring
的意思，又如在windows操作系统下，case本身就在消息处理上工作的很好，而且消息众多。
在DefWindowProc全部吃掉，而我们在WndProc可以吃掉我们想要的。要是真把消息做成子类
对象，扩展性未必好。所以我对eliminate if/switch by Polymorphism只抱着一半信任的
态度。
我也是初学的小朋友，所以想多看看文章，无奈，你给我的是书，不过，还是谢谢Top
22 楼kingofhawks（蓝鹰）回复于 2005-11-18 08:43:25 得分 0
gemouzhi(gemouzhi)
是的,对于扩展性和复杂性来说,应该在具体项目之间做折衷的选择吧,如果更多的复杂性并不能换来理想的扩充性,那还是保持原有风格为好,程序风格良好的话,代码维护也不至于成为噩梦.
呵呵,楼上的你是做Windows Application,MFC还是什么的?Top
23 楼flmn（川流不息）回复于 2005-11-22 00:03:43 得分 2
楼主说的和我上周六晚上听的课讲的一样，呵呵Top
24 楼atila1978（上帝之鞭）回复于 2005-11-22 02:58:20 得分 2
MArkTop
25 楼mascotzhuang（基督山伯爵）回复于 2005-11-22 08:28:43 得分 2
3/4/5还是蛮好的……Top
26 楼kingofhawks（蓝鹰）回复于 2005-11-22 08:42:09 得分 0
flmn(战斗鸡、争气鸡、喜伊鸡) ( )
呵呵,这些都是最基本的一些原则拉,你们上的什么课呀?大学里边感觉很多课要么讲语言层面,要么就是软件工程层面的,我们那时候都没有专门讲OOA/OOD的课程啊.Top
27 楼EdwinYeah（Edwin）回复于 2005-11-22 10:18:59 得分 2
楼主，转载大师的文章要注明“转载”二字。Top
28 楼onemonth（CSDN真烦）回复于 2005-11-22 10:27:05 得分 2
to 楼主：
1,6 基本是一个意思。
2,3,7 基本是一个意思。
4，5 基本是一个意思。
to gemouzhi(gemouzhi)：
如case和if嵌套，我都不用举什么业务逻辑，就说把12个月case掉，但2月需要if。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
消除if，case 不是在这些地方。
Top
29 楼007JavaKing（乖乖咙的咚）回复于 2005-11-22 10:53:01 得分 2
java与模式 里的吧Top
30 楼zczyh（）回复于 2005-11-22 11:12:54 得分 2
这小子纯属抄袭Top
31 楼kingofhawks（蓝鹰）回复于 2005-11-22 11:18:46 得分 0
EdwinYeah(Edwin) ( )
楼主，转载大师的文章要注明“转载”二字
-------文中所述都是最常见的思想,我等小人物自也不足提出什么新观点,本来就只是整理总结而已,但是也不是照般某位大师的所有观点,如兄台见过一样的,不妨告之,谢过.
007JavaKing(猛将兄) ( )
java与模式 里的吧
--------
不好意思,鄙人不曾看过java与模式,如有雷同,也属正常,因为这些原则本来就是最基本的,在此帖出,本意即略作整理,以供众友参考而已.Top
32 楼kingofhawks（蓝鹰）回复于 2005-11-22 11:20:52 得分 0
看起来这个帖子没意思了，本来是希望能有高人进来相互探讨,共同提高,结果...Top
33 楼kingofhawks（蓝鹰）回复于 2005-11-22 11:33:09 得分 0
onemonth(CSDN真烦) ( )
to 楼主：
1,6 基本是一个意思。
2,3,7 基本是一个意思。
4，5 基本是一个意思。
----------------
1强调某个模块的可扩展性和更改性,而6侧重于阐述模块之间的耦合关系以及如何为模块赋予责任.
2关注的是同一个类层次应该能够不让客户知道细节而灵活地选择实现,而3关注的则是任何组件之间的通讯应该基于接口,实际上3是更高一个层次的抽象,所以3经常被称为OO设计的第一准则。
至于7更是实现细节上的问题,与2,3不可混为一谈,7的目标主要是追求程序的可维护性和理解性,当然也有扩展性。
最后一个问题,4,5基本一个意思,更让人无法理解.
4强调的是分离抽象和实现,这就是接口的作用,而5则是着重于对象复用的角度.
呵呵，所以请兄台指正的同时,也请把意见描述清楚,谢谢!
Top
34 楼otoexpert（【行进中开火】∈∑≯┈┈┈┈┈⊙）回复于 2005-11-22 12:30:06 得分 2
楼主抄的就是抄的,别不好意思承认.
------------------------------------------------
引用自
《敏捷软件开发：原则、模式与实践》,Robert C. Martin
《Java与模式》，阎宏
Open-Closed Principle(OCP)
一个软件实体应当对扩展开放，对修改关闭。
Liskov Substitution Principle(LSP)
子类型(subtype)必须能够替换它们的基类型。
Dependence Inversion Principle(DIP)
要依赖于抽象，不要依赖于具体。
Interface Segregation Principle(ISP)
使用多个专门的接口比使用单一的总接口总要好。
Composite/Aggregate Reuse Principle(CARP)
优先使用合成/聚合，而不是继承。
Law of Demeter(LoD)
一个对象应当对其它对象有尽可能少的了解。
Top
35 楼otoexpert（【行进中开火】∈∑≯┈┈┈┈┈⊙）回复于 2005-11-22 12:36:36 得分 2
第6条是面向过程时代的模块设计原则，可以参考一下《敏捷软件开发：原则、模式与实践》中包的设计原则。
第7、8条只能算是建议。Top
36 楼xdop（鸿飞处）回复于 2005-11-22 12:45:25 得分 2
知之为知之，不知为不知
批判的继承，辩证的学习
不懂的可以向别人请教，懂得要讨论正确与否，如果是对的，就讨论如何应用
（不要嘈杂喧哗说什么什么是抄的，没意义）Top
37 楼kingofhawks（蓝鹰）回复于 2005-11-22 13:01:25 得分 0
otoexpert(【行进中开火】∈∑≯┈┈┈┈┈⊙) (
------------
这位兄台说话真够尖刻。
文中早就说明所有观点都是大师们提出来的，我在此只是略作整理，并加上自己的一些理解贴出来大家讨论而已，这有什么不可承认的，但是帖子并不是在网上转载而来，所以并未加转载两字，不知你可理解否？
至于你所说第6条是面向过程时代的模块设计原则
-----------
我只能付之一笑了，如果您真的是这样认为，那我也无话可说呵呵。
Top
38 楼kingofhawks（蓝鹰）回复于 2005-11-22 13:03:23 得分 0
xdop(鸿飞处) ( )
---------
楼上兄弟所言甚是，开此帖本来就是让大家结合自己的项目经验讨论一些设计问题，以更好的理解OO设计的精髓，结果却变成追究这些观点的出处了，呵呵可笑哉。Top
39 楼jxdn_yang（(我不想做IT了)）回复于 2005-11-22 13:48:44 得分 2
嗯,东西好就拿来用,不管是抄袭的还是转贴的~~~难道鸡蛋好吃就非得知道那只鸡叫社么???呵呵,也抄袭来个~~Top
40 楼henryfan1（http://henryfan.cnblogs.com）回复于 2005-11-22 14:11:48 得分 2
楼主写的东西《敏捷软件开发：原则、模式与实践》基本都有.
那个代码的例子有问题.
本来你想用f3来规范内部执行方法，但你确把f1,f2写成公有的。
这样的模板类很不明确（如果楼主的想法是这样倒没问题）
以时是平时编写模板方法类的大概情况。
abstract class Test
{
abstract protected void f1();
abstract protected void f2();
public void f3()
{
doF3();
这里可以添加对所有派生类有影响的代码。
}
protected virtual doF3()
{
派生类可以重写实现自己比较特别的功能
f1();
f2();
}
}
Top
41 楼kingofhawks（蓝鹰）回复于 2005-11-22 14:40:20 得分 0
henryfan1(每天好心情(*_*）
那个例子只是随手举的拉，至于访问控制这些没去考虑，你所修改的代码是用C++写的？java里边没有virtual阿。Top
42 楼kingofhawks（蓝鹰）回复于 2005-11-22 14:41:47 得分 0
大家都说《敏捷软件开发：原则、模式与实践》里都有，那本书我没有看过，哪里有电子书下载阿，我也找来学习学习一下~Top
43 楼gaoxiangyu123（忧郁的风）回复于 2005-11-22 17:04:41 得分 2
学习Top
44 楼henryfan1（http://henryfan.cnblogs.com）回复于 2005-11-22 17:25:36 得分 2
virtual 为虚方法,我写的是C#代码.
这些东西都已经是大师们的经验之谈了,拿出来讨论必要性不大.
还倒不如针对某一项是如何实现来交流一下.
Singleton模式在多线程应用中的不恰当使用会导致性能问题,
为什么会导致这情况?那设计时要注意什么情况?
优先使用对象组合，而不是类继承
对于使用组合有那些组合方法?
Top
45 楼gemouzhi（^_^）回复于 2005-11-22 17:29:25 得分 2
回复人： onemonth(CSDN真烦) ( ) 信誉：100 2005-11-22 10:27:00 得分: 0
to 楼主：
1,6 基本是一个意思。
2,3,7 基本是一个意思。
4，5 基本是一个意思。
to gemouzhi(gemouzhi)：
如case和if嵌套，我都不用举什么业务逻辑，就说把12个月case掉，但2月需要if。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
消除if，case 不是在这些地方。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
是用在什么地方？Top
46 楼EdwinYeah（Edwin）回复于 2005-11-24 14:31:36 得分 2
回复人： kingofhawks(蓝鹰) ( ) 信誉：105 2005-11-22 11:18:00 得分: 0
EdwinYeah(Edwin) ( )
楼主，转载大师的文章要注明“转载”二字
-------文中所述都是最常见的思想,我等小人物自也不足提出什么新观点,本来就只是整理总结而已,但是也不是照般某位大师的所有观点,如兄台见过一样的,不妨告之,谢过.
---------------
to楼主：
如果你一开始这样说明，我就不会说出上面的话。因为从你开始的一些回帖看，感觉你有点当是你自己原创的思想一样(如果我感觉错了请见谅)，所以，我才说你转载，当然，其实我应该是说你转载思想，而非文章。
这些法则确实是最常用的，大家都要知道的，楼主提出这样的讨论确实有意义。
其中部分原则，我最早是从这文章看到的：http://www.chinaitpower.com/A/2002-10-30/39436.html
Top
47 楼AFer198215（甜咖啡）回复于 2005-11-24 15:29:46 得分 2
7．使用多态机制消除大量的IF/CASE语句
大量的IF/CASE使得代码难于维护和扩展，我们应该用多态来取代条件判断逻辑，状态和策略模式都可以帮助实现这一机制。
请问怎样使用? 他又如何取代if/case? 谢谢...Top
48 楼wtiancai（博学,审问,慎思,明辨,笃行.）回复于 2005-11-24 16:01:08 得分 2
看來差距太大暸，我都看不懂啊Top
49 楼kingofhawks（蓝鹰）回复于 2005-11-24 17:31:46 得分 0
EdwinYeah(Edwin) ( )
呵呵，可能也怪我开始就贴了个帖子,什么都没说吧~~
所以楼上几位曾说《敏捷软件开发：原则、模式与实践》都有，去下载过来一看,果然很多讲得非常详细,确实是本好书,强烈建议大家都去看看.
Top
50 楼kingofhawks（蓝鹰）回复于 2005-11-24 17:34:20 得分 0
AFer198215() ( )
-------
关于多态以及用状态/策略模式消除条件语句,请参看
Refactoring: Improving the Design of Existing Code
一书中chapter 9 Replace Conditional with Polymorphism
该电子书在
www.netyi.net
www.infoxa.com都有下载,这是非常不错的两个IT电子书籍网站.Top
51 楼DTWUJP（建平.net）回复于 2005-11-24 17:53:44 得分 2
mark,Top
52 楼byrybye（阿水）回复于 2005-11-25 08:38:24 得分 2
MARK 很不错哦Top
53 楼PPower（月亮光光，照地堂）回复于 2005-11-25 09:59:08 得分 2
消除if，case 是指固定的邏輯。
對於可變的業務邏輯的封裝可能不在此列Top
54 楼otoexpert（【行进中开火】∈∑≯┈┈┈┈┈⊙）回复于 2005-11-25 12:56:10 得分 2
前几天心情乱,说话语气尖锐了一点,在此向楼主公开致歉!
对于第6条,不知道楼主有没有看完《敏捷软件开发：原则、模式与实践》包的设计原则,如果仅是"强内聚弱耦合"作为OO设计原则是不恬当的，记得Bob大叔在前三个原则的总结那里指出过类似的观点。Top
55 楼zouxinfox（Read the source,Use the force）回复于 2005-11-25 13:10:40 得分 2
小弟想问一下，多态用的越多越好吗，我在读开源软件时发现有的软件大量运用多态性（有时根本不必用），这样是为了有更好的扩展性吗？Top
56 楼didoleo（冷月无声）回复于 2005-11-25 14:17:10 得分 2
学习学习
《敏捷软件开发：原则、模式与实践》,这本书要去看一下
Top
57 楼kingofhawks（蓝鹰）回复于 2005-11-25 15:53:49 得分 0
PPower(月亮光光，照地堂) ( )
消除if，case 是指固定的邏輯。
對於可變的業務邏輯的封裝可能不在此列
----------
这两句话不大容易理解哦,多态不正是用来处理可变的业务逻辑吗?Top
58 楼kingofhawks（蓝鹰）回复于 2005-11-25 16:03:07 得分 0
otoexpert(【行进中开火】∈∑≯┈┈┈┈┈⊙) ( )
前几天心情乱,说话语气尖锐了一点,在此向楼主公开致歉!
对于第6条,不知道楼主有没有看完《敏捷软件开发：原则、模式与实践》包的设计原则,如果仅是"强内聚弱耦合"作为OO设计原则是不恬当的，记得Bob大叔在前三个原则的总结那里指出过类似的观点。
____________
呵呵没有关系拉,本来大家都是相互学习嘛.
实际上高内聚,低耦合应该是整个软件工程都应该重视的课题,而不仅局限于面向过程或者面向对象.敏捷软件开发：原则、模式与实践》中包的设计原则主要针对OO(尤其是Java)设计,当然他提出包的组织要考虑到可重用性,可开发性等,特别是对于那些与业务逻辑相关的包,因为它们总是会处于不断的变化演进中,但是这并不违背我们在设计包的时候仍然会把高内聚作为重要的原则啊.Top
59 楼kingofhawks（蓝鹰）回复于 2005-11-25 16:09:06 得分 0
zouxinfox(Read the source,Use the force) ( )
小弟想问一下，多态用的越多越好吗，我在读开源软件时发现有的软件大量运用多态性（有时根本不必用），这样是为了有更好的扩展性吗？
-----------------------------
应该说多态主要是提供我们一个手段,使得我们可以灵活地去应付用户不停地变更或者新提出需求,所以它也必然导致了更高的可扩展性,当然也有利于代码重用,提高可读性以及可维护性.但是多态有的时候也会引入过度的复杂性,滥用多态与忽视多态一样问题严重,我想应该结合项目具体需要吧,如果你应用的某个部分需求根本就不可能会有变更,或者应用也非常之少,那么在复杂的设计与简单的实现之间我们应该倾向与后者,一个按时提交,能够正常工作的产品在很多时候都比任何因素要重要的多.Top
60 楼czlc（小凡）回复于 2005-11-26 00:09:08 得分 2
mark,明天来看。Top
61 楼Fusuli（傻强）回复于 2005-11-26 10:15:21 得分 2
8．在多线程程序中谨慎地使用Singleton模式
Singleton模式在多线程应用中的不恰当使用会导致性能问题，在用到该模式时尽可能使用lazy initialization 方法。
-------------------------------------------------------
多线程程序中使用Singleton的问题在于线程安全，如果是多线程就不要用Lazy Load!直接在声明的时候就实例化。
例如：
单线程你可以这样写：
class Foo
{
private static Foo _instance;
private Foo(){}
public static getInstance()
{
if(_instance==null)_instance = new Foo();
return _instance;
}
}
但是在多线程程序中，为了保证线程安全，就不能用LazyLoad了
class Foo
{
private static Foo _instance = new Foo();
private Foo(){}
public static getInstance()
{
return _instance;
}
}
Top
62 楼onemonth（CSDN真烦）回复于 2005-11-26 16:49:31 得分 2
PPower(月亮光光，照地堂) ( )
消除if，case 是指固定的邏輯。
對於可變的業務邏輯的封裝可能不在此列
--------------------------------------------
恰好说反了。已知的用if case没问题，未知的用if case就有问题了。Top
63 楼zdnetchina（天天向上）回复于 2005-11-26 19:59:15 得分 2
不错
Top
64 楼gemouzhi（^_^）回复于 2005-11-26 20:05:34 得分 2
onemonth(CSDN真烦) 你应该具体说一下，不要说半截话，这样你举一个if case你认为有问题的
例子，OK？
Top
65 楼gemouzhi（^_^）回复于 2005-11-26 20:13:11 得分 2
HOHO,我给onemonth(CSDN真烦) 发消息了，等待高人解释一下，顺便把你上边回我的帖子的话也 解释一下。
[1]
to gemouzhi(gemouzhi)：
如case和if嵌套，我都不用举什么业务逻辑，就说把12个月case掉，但2月需要if。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
消除if，case 不是在这些地方。
[2]
PPower(月亮光光，照地堂) ( )
恰好说反了。已知的用if case没问题，未知的用if case就有问题了。
等待高人解释一下。
我再加100分，HOHO。
而且这贴收藏一下，下周发布一下。HOHO。Top
66 楼onemonth（CSDN真烦）回复于 2005-11-28 10:15:45 得分 2
就举月份的问题，如果把这个当作类来做，如下：
class Month
{
public int GetDays()=0; virtual;
};
由于有4种天，28,29,30,31，那么最少得派生4个类
class Month_28 : public Month
{
public:
Month_28(datetime dt): _datetime(dt)
{
}
int GetDay()
{
Return 28;
}
private:
datetime _datetime;
};
调用方式：
datetime dt;
Month * m = new Month_28(dt);
int d = m->GetDays();
如果换成每月一个类，同样避不开闰年问题。
看看这个调用，构造函数必须得传入正确的时间，而这个时间怎样得到？只有通过计算，显然，这样做没有任何价值。如果把整个时间当作一个类，就有价值了。大致如下：
class DateTime
{
int GetDays();
};
之所以可以这么做，是因为这些问题域都是确定的，没有任何例外的。这种情况吓用if，case就很自然了。
再看一个很泛滥的例子，这个例子已经讲解了以上的内容，看来很多人都没过关啊：-)))
class TShap
{
virtual void Draw()=0;
};
class TCircle : public TShap
{
void Draw();
}
class TRect : public TShap
{
void Draw();
}
看看调用：
void Draw(shap:TShap)
{
shap->Draw();
}
这样做很自然，显然不会用如下代码：
void Draw(TShap * shap)
{
if shap is circle then TCircle(shap)->Draw else
if shap is rect then TRect(shap)->Draw else
...
}
从上面两个例子看到，if，case主要是用来处理数值类型，而不会用来处理类型，这个任务应该有编译器来完成。
当然，在某些特殊的情况下，比如COM对象，内部是用rtti来辨别类型，因为COM并不知道怎样来完成类型辨别。如果用if来辨别类型，会产生潜在的问题：如果两个类是派生关系，if的顺序是相当重要的，特别是在GP中，如果用if，简直就是不可能。GP里面，是用traits来解决这个问题。
这个就是我说的“已知的用if case没问题，未知的用if case就有问题了”
Top
67 楼gemouzhi（^_^）回复于 2005-11-28 14:43:24 得分 2
如果换成每月一个类，同样避不开闰年问题。
---------------------
不，你已经把条件上移了，是你自己在把条件上移，因为你的例子是基于一年的，但，你说的
同样避不开闰年问题就成了：每年的了。这不是一个层面的例子。
你还是没理解我说的意思。因为我在强调复杂度上，并不是你的例子。了解？
是复杂度下的构造, 而你是用了范围缩小的例子说明了范围扩大后的例子, 这当然有问题.
我所说当然是每月一个类, 但往往商业的逻辑比这要复杂的多, 我只好来举这个12个月的例子
因为我不可能举一个真实的复杂的case, 而这个例子恰恰又符合31,30,28,29这种分类
所以,你划分为4个子类当然不可以.
我不知道你同不同意这样的理论: Polymorphism可以refactoring掉任何if/switch
如果同意, 你没有说具体的用途(哪里能用,哪里不能用?), 上面我的问的问题也在这里啊.
如果不同意, 你可否构造一个不能refactoring掉的例子.
这才是根本, 而不是抓在月份的例子上.Top
68 楼PPower（月亮光光，照地堂）回复于 2005-11-28 15:34:15 得分 2
所謂的業務邏輯就是沒有邏輯，很難封裝的。往往得用if elseif這類產生式邏輯來定制
所謂固定的邏輯就是邏輯關系明確的
我的理解：
如果對象被細化且存在繼承關系，多态才可以消除if elseif。所謂“盡量使用多态机制消除大量的IF/CASE语句”是指如果可能就使用面向對象編程並抽象出共同的父類。
如果無法抽象出共同的父類,談什麼多态。是否該分化出一個對象這與領域相關，如果不使用領域模型來編程，對象也就會走樣，多態也不常出現。
對於這句話：“已知的用if case没问题，未知的用if case就有问题了。”是不是希望用多態來封裝未知的邏輯，那不是if 或case的問題了吧。
Top
69 楼gemouzhi（^_^）回复于 2005-11-28 15:41:52 得分 0
如果對象被細化且存在繼承關系，多态才可以消除if elseif
-------------------
消除if/case是基于条件的，是条件决定对象，不是对象决定条件。
不是为抽象出父类，是为了层次的立体。Top
70 楼bilujun（编程低手）回复于 2005-11-28 15:52:35 得分 2
理论必须跟实践相联系。我有个程序设计的问题，请大家分析分析，该如何用oo方法,采用哪些设计模式来设计。
http://community.csdn.net/Expert/topic/4418/4418141.xml?temp=8.997744E-02
Top
71 楼kingofhawks（蓝鹰）回复于 2005-11-28 17:40:24 得分 0
基本同意gemouzhi(gemouzhi) ( )的观点,在消除IF/CASE的问题上最关键的还是应该根据项目需要拉,如果引入复杂的实现并没有得到相应的报酬,那还是用简单的实现为好,毕竟按时提交,可以工作的产品才是最重要的.Top
72 楼tramp73（梦☆★星）回复于 2005-11-28 23:05:58 得分 2
markTop
73 楼onemonth（CSDN真烦）回复于 2005-11-29 10:30:48 得分 0
不，你已经把条件上移了，是你自己在把条件上移，因为你的例子是基于一年的，但，你说的同样避不开闰年问题就成了：每年的了。这不是一个层面的例子。
―――――――――――――――――――――――――――――――――――――――――
“如case和if嵌套，我都不用举什么业务逻辑，就说把12个月case掉，但2月需要if。”
这个条件显然包含了闰年问题，就只能按照这样来设计。这里面没有用“范围缩小的例子说明了范围扩大后的例子”。你没有明白我这个设计的意图。仔细看看派生类，看看基类，想想我为什么要这样设计，想想是不是你说的这个样子。同样，你也可以看看，为甚么我说“最少得派生4个类”，而不是“划分为4个子类”。还是仔细看看我说的话。当然，如果是说对某一年设计月，当然与这个设计是完全不一样的，那也就不存在2月问题了。这个例子里面已经包含很多设计的内容，并不是在“抓例子”。
我不知道你同不同意这样的理论: Polymorphism可以refactoring掉任何if/switch
―――――――――――――――――――――――――――――――――――――――
理论很正确，但是实际是另一回事。这个关系到粒度，实现难度的问题。如果非要这么做，我无话可说。我举的例子和后面的论述，很清楚的说的这个问题，也说了设计要考虑的问题。仔细看看回贴。
最后说一句：如果还停留在只使用继承派生来设计，那就没有什么好讨论了。这样的设计，应该是在3、4年前进行讨论的东西，是在没有兴趣再出来说了。现在这么多讲设计的好书，好的开源代码，该怎样设计都在里面了。我呢，只不过是从里面抓了一点，没有自己的东西的。各位信与不信，笑过骂过都好，就当我张口瞎说好了。
Top
74 楼PPower（月亮光光，照地堂）回复于 2005-11-29 11:38:03 得分 0
Polymorphism可以refactoring掉任何if/switch
以前沒聽過有這理論，現在看到了。不過沒有哪個人笨到要這麼做。
這有什麼用處呀。就好象用遞歸可以實現任何函數過程，n次多項式可以表示任何函數一樣，只有理論的指導作用，而沒多大的使用價值。
Top
75 楼superslash（开始用功学习）回复于 2005-11-29 11:53:35 得分 0
来晚了Top
76 楼gemouzhi（^_^）回复于 2005-11-29 12:41:32 得分 0
晕，不知道你们在说什么，我感觉我理解能力还可以的，我说的＂Polymorphism可以
refactoring掉任何if/switch＂就是这本书Refactoring: Improving the Design of Existing
Code，书中chapter 9 Replace Conditional with Polymorphism的意思啊，
这种Refactoring具体的用途(哪里能用,哪里不能用?）您还是没说．只说了＂这个关系到粒度，
实现难度的问题。如果非要这么做，我无话可说＂，不是非要这么做的问题，这是个好事情，但
好到什么地步的问题？嘎嘎，感觉自己已经无法表达了，这是3、4年前的东西？几乎晕倒
我是想了解如何把握这种Refactoring，但是现在无法表达了，哈哈．希望kingofhawks(蓝鹰)能
了解我说的意思吧．
to PPower(月亮光光，照地堂)
Polymorphism可以refactoring掉任何if/switch
以前沒聽過有這理論，現在看到了。不過沒有哪個人笨到要這麼做。
－－－－－－－－－－－－－
对您的话我也是快笑出来了，您还不知道讨论的什么．这你应该去问问Martin Fowler．他经常这么做，您也太强了．用繁体字的人．
哈哈，为了避免楼太高，kingofhawks(蓝鹰)，我就不再发言了，看来我的问题问不清楚．
如果你能了解，希望有时间再讨论．
谢谢各位的讨论，尤其感谢 onemonth(CSDN真烦)的指教， PPower(月亮光光，照地堂) 和kingofhawks(蓝鹰)的指教Top
77 楼kingofhawks（蓝鹰）回复于 2005-12-14 14:04:58 得分 0
其实上边列出的一些原则都是为了使我们能够面对需求的变化而不至于让我们的程序逐渐地退化而难以维护.当我们在做系统设计的时候没有办法把需求100%弄清楚，所以我们应该让我们的设计保持足够的灵活性，使得用户需求改变或者有新的特性加入时，我们的设计仍然可以方便地支持。 这些原则就是用来帮助我们实现这一目标，同时需要注意的是，在设计中引入过多的抽象只会带来软件设计的复杂性以及潜伏的延长开发周期，成本加大的风险，所以一个基本的原则是我们只应该在变化频繁的部分引入抽象。当然，当一个项目开始的时候我们很难判断哪些部分会面临变化，我们应该做的是以最简洁的方式去实现，当第一次变化出现的时候我们才把变化的部分抽象出来，因此在需求以及设计阶段，我们应该尽量去揭露系统中需要变化的部分，多次迭代并提交给用户测试是一种发现需求变更的手段。敏捷软件开发这本书确实不错,诸友可以多多研读,相信可以令大家的设计能力上一台阶.Top
78 楼kingofhawks（蓝鹰）回复于 2005-12-15 16:00:00 得分 0
9．消除程序中的任何冗余代码
更多地复用代码而不是通过Copy/Paste在程序中留下很多相同代码的副本，这将是软件维护的噩梦。在J2EE应用中尤其需要注意不要使业务逻辑与表示层对象如HttpServletRequest等耦合，这将极大地降低代码的可复用性，并刺激程序员进行Copy/Paste.公共的JavaScript代码放在.js文件中，在JSP页面尽可能少写scriplet,taglib对于消除JSP页面的java 代码是一个很好的解决方案。
Top
79 楼asiaec（星星是你看我的眼睛）回复于 2005-12-16 12:56:36 得分 0
抄书请注明原作者！
这些都是 oo construction 里面的内容。。。。sighTop
80 楼kingofhawks（蓝鹰）回复于 2005-12-16 13:14:26 得分 0
关于这个问题前边早有提及,楼上这位怎这么肤浅呢...Top
81 楼QWERT520（痛苦并快乐着）回复于 2005-12-16 18:10:25 得分 0
只能接分Top
82 楼best_threewood（ Do it ！）回复于 2005-12-16 18:23:58 得分 0
收藏Top
83 楼xxqq0824（赛跑）回复于 2005-12-18 14:22:24 得分 0
jxdn_yang(张婷) ( )
关于接口的问题,一般是使用抽象类好还是接口??
---------------
抽象类本身已经位于很高的层次,一般在以下情况下会考虑用抽象类而不用接口.
(1)有公共的一些instance变量必须在顶层类加以抽象;
(2)在你的类层次中可能会有一些模板操作,或者固定的实现.
其他情况下一般考虑用接口,因为接口具有最大的灵活性.
例如,在我设计的一个类层次中需要定义三个接口
public void f1();
public void f2();
public void f3();
而f3()的功能是先后执行f1,f2,如果你用接口就没有办法把这些定义完全表达出来
而用abstract class 则可以
abstract class Test
{
abstract public void f1();
abstract public void f2();
public void f3()
{
f1();
f2();
}}
在这个例子中是一个典型的模版模式的实现,在基类中定义确定的操作序列,而不同的序列则由具体子类实现.
楼主刚才举的例子其实在C#里用的多重委托就可以搞定，在C#里，委托还是个好东西。Top
84 楼kingofhawks（蓝鹰）回复于 2005-12-19 08:49:58 得分 0
楼上兄台,请教多重委托是指?我没有用过C#,不知道那个是不是跟语言相关的一个概念?请指教,谢谢.Top
85 楼yiyi0518（世上的盐和光）回复于 2005-12-26 16:42:58 得分 0
楼主拜读了《JAVA与模式》吧！Top
86 楼poiunet（1 1）回复于 2005-12-26 16:54:08 得分 0
UPTop
87 楼crazycy（崔毅，blog:http://www.blogjava.net/crazycy/）回复于 2005-12-27 13:59:53 得分 0
8．在多线程程序中谨慎地使用Singleton模式
Singleton模式在多线程应用中的不恰当使用会导致性能问题，在用到该模式时尽可能使用lazy initialization 方法。
这个好Top
88 楼crazycy（崔毅，blog:http://www.blogjava.net/crazycy/）回复于 2005-12-27 14:00:12 得分 0
8．在多线程程序中谨慎地使用Singleton模式
Singleton模式在多线程应用中的不恰当使用会导致性能问题，在用到该模式时尽可能使用lazy initialization 方法。
这个好Top
89 楼kingofhawks（蓝鹰）回复于 2005-12-27 16:23:04 得分 0
10.为了避免类的爆炸性增长,以及给对象动态地增加职能,我们应该考虑Decorator模式,而不是使用类继承.而且使用Decorator模式,可以使我们的客户代码保持最小甚至不需要改动,从而使我们可以更容易地维护升级代码,并将影响局限在很小的范围之内,我觉得这对于保持程序的结构以及不引入新的Bug具有非常重要的作用.
Top
90 楼kingofhawks（蓝鹰）回复于 2005-12-27 16:24:23 得分 0
关于Singleton在多线程中对性能的影响问题网上有很多文章的,基本上都是因为同步所致,如果多线程不存在同步问题,那也就不存在性能问题了.Top
91 楼spiderboy（spiderboy.fuck(Beauty anotherHotGirl)）回复于 2005-12-28 22:37:48 得分 0
这些原则在设计的书籍里面都有总结,我认为关键是咋们在实际应用中能不能有足够的sense来识别出这些原则的应用场景.这可能就是所谓的经验的定义吧Top
92 楼plokmmm（人从众）回复于 2005-12-29 15:30:05 得分 0
总之，一个简单工厂可以帮助我们实例化各种子类对象，使用简单工厂我们就不需要熟悉子类的具体结构，只需要了解父类就可以了，而且当子类产生变化时（增加或减少子类），我们的程序不会受到影响。Top
93 楼I_Iverson（迷路的蚂蚁）回复于 2006-01-18 11:43:30 得分 0
7．使用多态机制消除大量的IF/CASE语句
大量的IF/CASE使得代码难于维护和扩展，我们应该用多态来取代条件判断逻辑，状态和策略模式都可以帮助实现这一机制
--------------------------------------------
我对这个保持怀疑的态度，因为我觉得只是把判断挪到别的地方去（如子类，xml文档，或者数据库里，或者调用段代码）了，实际的效果并不是很好，有时反而增加代码的复杂程度。
Top
94 楼I_Iverson（迷路的蚂蚁）回复于 2006-01-18 11:46:18 得分 0
据说它的好处是符合开闭原则，有新的逻辑只需要增加，不需要修改原有的代码。。。可是增加新的代码难道就一定比修改if(case)简单？Top
95 楼kingofhawks（蓝鹰）回复于 2006-01-19 09:17:14 得分 0
据说它的好处是符合开闭原则，有新的逻辑只需要增加，不需要修改原有的代码。。。可是增加新的代码难道就一定比修改if(case)简单？
----------
事实上是可以做到把IF-CASE完全消除而不是挪到别处，你可以把变化的部分放在配置文件里阿，那样就保持了极高的灵活性了，甚至可以让你在运行时选择替换,最近在维护一个项目，里面就是遍布嵌套的IF-ELSE,看得真是头痛啊，不过迫于进度压力，也只能硬着头皮修改了，这样的代码以后的维护难度增加了不是一丁点阿。。。Top
96 楼tfp（tfp）回复于 2006-01-19 22:01:34 得分 0
AOP 是怎么实现的？
模式实际都很长时间了，Top
97 楼caiyi0903（willpower）回复于 2006-01-20 13:32:46 得分 0
真正理解的不多！Top
98 楼niko7（掠水无痕）回复于 2006-01-21 22:46:05 得分 0
做个记号。Top
99 楼jacbo（今天你坚持了没有）回复于 2006-01-21 23:04:42 得分 0
学习了Top
100 楼best_threewood（ Do it ！）回复于 2006-01-22 00:09:20 得分 0
studyTop
101 楼super_zzw（之支吾）回复于 2006-01-22 02:09:17 得分 0
这些论点都很不错， 并且在架构设计中使用才有意义，项目开发中如果到了应用开发阶段写业务逻辑的人还需要考虑这些问题，那么整个软件的开发就比较危险了。也就是说考虑结合使用这些技术点的目的就是为了简化应用开发同时加强软件的可维护性能可扩展性。
AOP是个非常值得在实际架构中使用的技术， 利用一下jdk的动态代理就行， 在某个层上插入一个切面，比如权限验证， 事务处理等。Top
102 楼I_Iverson（迷路的蚂蚁）回复于 2006-01-23 22:18:35 得分 0
事实上是可以做到把IF-CASE完全消除而不是挪到别处，你可以把变化的部分放在配置文件里阿，那样就保持了极高的灵活性了.
-------------------------------------------------
这其实就是挪到配置文件里，虽然它消除了硬编码。这是另一种形式的if-case.Top
103 楼I_Iverson（迷路的蚂蚁）回复于 2006-01-23 23:57:57 得分 0
举个例子，著名的"4个程序员的一天 ":
周一，刚打开电脑，老板就跑到你们组的办公座面前：“好吧，伙计们，现在有个function需要你们来搞定。具体是这样的：用户输入2个数，并输入一个操作符。你根据输入的情况来得出相应的运算结果。“
Example： Foo(+, 1, 2) = 3; Foo(*, 3, 6) = 18; Foo(/, 2, 4) = 0.5
Ceer最先作出反应：简单嘛，判断一下输入的操作符就好了。说着，他很快在白板上写出如下代码：
public class CStyle_Calculator
{
static public double Foo(char op, double x, double y)
{
switch(op)
case '+': return x + y; break;
case '-': return x - y; break;
case '*': return x * y; break;
case '/': return x / y; break;
default: throw new Exception(”What the Hell you have input?");
}
}
-------------
下面是java的oo:
Jally只看了一遍，就捂着鼻子连连摇头：好一股的代码臭味【注1】。还不如看我用OO的方法来解决：
public interface I操作符 //谁说代码不能写中文的？恩恩
{
double 运算(double x, double y);
}
public class OO_Calculator
{
private I操作符 m_op;
public OO_Calculator(I操作符 op)
{
this.m_op = op; //依赖注入【注2】
}
public double Foo(double x, double y)
{
return this.m_op.运算(x, y);
}
}
public class 加法:I操作符
{
public double 运算(double x, double y)
{
return x + y;
}
}
public class 减法:I操作符
{
public double 运算(double x, double y)
{
return x - y;
}
}
public class 乘法:I操作符
{
public double 运算(double x, double y)
{
return x * y;
}
}
public class 除法:I操作符
{
public double 运算(double x, double y)
{
return x / y;
}
}
public class TheMainClass
{
static public void Main()
{
I操作符 我的加法 = new 加法();
OO_Calculator 我的加法器 = new OO_Calculator(我的加法);
double sum = 我的加法器.Foo(3, 4);
System.Console.WriteLine(sum);
//sum = 7
//其他3个我就不废话了
}
}
Top
104 楼I_Iverson（迷路的蚂蚁）回复于 2006-01-24 00:06:44 得分 0
第二个例子我认为其实是把判断放在void Main()里了，如果是加法，我就new 加法();
减法我就 new 减法();
相对来说，对于这种情况，我宁愿选择第一个例子里的case,因为我不想那么繁琐，其实第二个例子它的好处在于 I操作符 操作符 = new ...之后，操作符.Foo()在客户端可以统一使用，因为它实现了一个接口，而不是避免了case语句的臭味。Top
105 楼kingofhawks（蓝鹰）回复于 2006-01-24 08:50:09 得分 0
I_Iverson(迷路的蚂蚁) ( ) ：
楼上说的挺有道理的，当用If-case实现非常简洁，而且需求也并不是频繁变动，滥用多态并不是好主意。但如果逻辑非常复杂，需求经常变动，想想看那时候的If-case要复杂到什么程度，也许你认为还是没关系，是的，如果代码是你本人在维护，你也能很快去做改动，但问题是应用并不是都由开发者来维护阿？那时候维护的成本就会高的恐怖了，我想有过维护人家程序的人都有这种感觉吧，一个遍布嵌套判断的程序只会让人头晕，新手甚至都不敢去修改人家的程序。Top
106 楼I_Iverson（迷路的蚂蚁）回复于 2006-01-24 10:19:53 得分 0
遍布嵌套判断语句是不提倡的，但我说的是比较简单，变化不大的情况下，就像简单的系统不一定需要领域模型去实现，而采用事物脚本可以更快开发性能更好，太过复杂的情况另当别论。
至于说维护，在很多情况下，使用第二个例子的做法维护难度不一定就比使用if-case简单，至少说我还没见过if-case得让我头晕的系统，或许我见过的系统都不太复杂吧:)
就算是虚拟工厂方法，它的目的也并不是说为了避免if-case,它的好处在别的地方，说来就复杂了，改天再说，如果有兴趣，可以好好讨论一下。。。Top
107 楼I_Iverson（迷路的蚂蚁）回复于 2006-01-24 10:23:06 得分 0
我在实际工作中，对于有一定相似逻辑，但有改动要求的需求，一般是在数据库里用一张表去配置，可以避免在程序里面频繁修改。Top
108 楼FreeFice（庄鱼）回复于 2006-01-24 11:18:19 得分 0
说说软件维护：程序并不是想改就可以改的！
程序的代码维护，依赖于对文档的维护，如果有统一完整的文档，那么对代码的维护，If/Case远比使用多态要简单，尤其是在关联到比较底层的变更时，当然如果仅仅是添加功能或筛选属性的话，选择哪种方式，完全是个人喜好了。
使用多态的好处，在于抽象及屏蔽一些概念与实现间的关系，从这方面上讲，使用if/case远没有使用多态来的直观明了。Top
109 楼asiaec（星星是你看我的眼睛）回复于 2006-01-24 11:26:12 得分 0
我只想说。。。。。tooooo old。。。。。
Top
110 楼I_Iverson（迷路的蚂蚁）回复于 2006-01-24 11:37:28 得分 0
回复人： asiaec(星星是你看我的眼睛) ( ) 信誉：89 2006-01-24 11:26:00 得分: 0
我只想说。。。。。tooooo old。。。。。
--------------------------------------------
设计模式就是这几十种，我倒想知道你研究的是哪种new的模式？
汉字也有几千年了，更tooooo old....Top
111 楼kingofhawks（蓝鹰）回复于 2006-01-24 13:17:37 得分 0
I_Iverson(迷路的蚂蚁) ( )
---------------
你的观点我也基本赞同，确实在IF-CASE以及多态之间作选择是要根据具体项目的复杂程度，以及需求的变更情况，还有一些其他因素综合考虑，我也是认为在系统的开始阶段应该用最简单的方式实现，这点在之前也都已经明确提及了，事实上过度设计也是带来了更高的维护成本，而且对于进度也是一种考验，我们在工作中应该避免滥用模式呵呵。Top
112 楼kingofhawks（蓝鹰）回复于 2006-01-24 13:21:33 得分 0
回复人： asiaec(星星是你看我的眼睛) ( ) 信誉：89 2006-01-24 11:26:00 得分: 0
我只想说。。。。。tooooo old。。。。。
--------------------------------------------
BTW,这位兄弟确实比较可爱的说，很多软件思想都是很老套了，但是难道我们都深刻理解了么？而且，这些思想不是仍然在影响着我们今天的设计和编码吗？Top
113 楼boltzjf（Bolt晶峰）回复于 2006-01-24 13:31:01 得分 0
支持楼主
从楼主写下的话可以看出来，楼主是有自己的理解和认识的，而且尤其是第七条，很实际，是实践过的，我也使用过同样的方法来处理某些不定扩展条件下的case和if的问题，这个很好。
希望大家不要纯一味批评或者是追究人家是否抄袭，这里是论坛而已，又不是出版社，^_^
希望各位大大们能留下一些自己的领悟，大家共同研究进步，这样，我们才能够摆脱“一个中国人是龙，几个中国人就是虫”的状况了……
大家一起加油！好好学习，天天向上！Top
114 楼zouxinfox（Read the source,Use the force）回复于 2006-01-27 15:20:06 得分 0
在顶一下Top
115 楼Dragon_tlb（幻海星语）回复于 2006-02-04 21:58:53 得分 0
好贴Top
116 楼windbey（北风）回复于 2006-02-07 09:55:47 得分 0
markTop
117 楼classjava（原始野人）回复于 2006-02-07 10:48:17 得分 0
^_^,难道组合出来就不好么,硬要自己提出一些新的表述来说明同一个意思^_^
中立Top
118 楼sjjf（水晶剑锋）回复于 2006-02-07 11:13:26 得分 0
markTop
119 楼cnyxlxw（黑夜给了我黑色的眼睛我用他来寻找光明）回复于 2006-02-08 13:06:55 得分 0
mark!!!!!!Top
120 楼shazi_pig（傻子）回复于 2006-02-08 15:35:00 得分 0
对楼主追求技术的态度赞佩不止。。。
向楼主学习。。。。。Top
121 楼boby198339（世序）回复于 2006-02-19 18:31:50 得分 0
8．在多线程程序中谨慎地使用Singleton模式
Singleton模式在多线程应用中的不恰当使用会导致性能问题，在用到该模式时尽可能使用lazy initialization 方法。
-------------------------------------------------------
多线程程序中使用Singleton的问题在于线程安全，如果是多线程就不要用Lazy Load!直接在声明的时候就实例化。
例如：
单线程你可以这样写：
class Foo
{
private static Foo _instance;
private Foo(){}
public static getInstance()
{
if(_instance==null)_instance = new Foo();
return _instance;
}
}
但是在多线程程序中，为了保证线程安全，就不能用LazyLoad了
class Foo
{
private static Foo _instance = new Foo();
private Foo(){}
public static getInstance()
{
return _instance;
}
}
-------------------------------------------------------
我也认为没有性能问题！Top
相关问题
关键词
得分解答快速导航
- 帖主：kingofhawks
- OnlyFor_love
- OnlyFor_love
- jxdn_yang
- gemouzhi
- jxdn_yang
- ASPserver
- silverend
- majy
- jxdn_yang
- jxdn_yang
- gemouzhi
- gemouzhi
- taoyuming
- mnbvc874
- gemouzhi
- flmn
- atila1978
- mascotzhuang
- EdwinYeah
- onemonth
- 007JavaKing
- zczyh
- otoexpert
- otoexpert
- xdop
- jxdn_yang
- henryfan1
- gaoxiangyu123
- henryfan1
- gemouzhi
- EdwinYeah
- AFer198215
- wtiancai
- DTWUJP
- byrybye
- PPower
- otoexpert
- zouxinfox
- didoleo
- czlc
- Fusuli
- onemonth
- zdnetchina
- gemouzhi
- gemouzhi
- onemonth
- gemouzhi
- PPower
- bilujun
- tramp73
相关链接
广告也精彩
反馈
