﻿<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>BlogJava-delvin-随笔分类-面向对象</title><link>http://www.blogjava.net/devin/category/45570.html</link><description /><language>zh-cn</language><lastBuildDate>Sat, 17 Jul 2010 05:38:07 GMT</lastBuildDate><pubDate>Sat, 17 Jul 2010 05:38:07 GMT</pubDate><ttl>60</ttl><item><title>Java类设计</title><link>http://www.blogjava.net/devin/archive/2010/07/16/270046.html</link><dc:creator>delvin</dc:creator><author>delvin</author><pubDate>Fri, 16 Jul 2010 00:47:00 GMT</pubDate><guid>http://www.blogjava.net/devin/archive/2010/07/16/270046.html</guid><wfw:comment>http://www.blogjava.net/devin/comments/270046.html</wfw:comment><comments>http://www.blogjava.net/devin/archive/2010/07/16/270046.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/devin/comments/commentRss/270046.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/devin/services/trackbacks/270046.html</trackback:ping><description><![CDATA[<p>想要把类，接口和模块设计好是一项高难度的工作。前人对此有过很好的研究和总结，在此仅把我自己设计类的方法归纳下：<br />
<br />
<strong>设计类的步骤？</strong><br />
1.定义类的职责<br />
<span style="color: red">Note：</span><br />
&nbsp;&nbsp;&nbsp;&nbsp; 1）一个类的职责是这个类存在的价值，若你不能清晰的给这个类定义职责，那么很可能意味着这个类没有存在的价值。<br />
&nbsp;&nbsp;&nbsp;&nbsp; 2）从职责的角度去定义类，选择类比单纯的什么从业务术语中找名词来做类名要有效的多.<br />
&nbsp;&nbsp;&nbsp;&nbsp; 3)&nbsp; 在设计类的时候，我经常用CEO设计企业组织机构来比喻。在设计企业架构时，需要考虑企业做的事，划分不用的职责和角色，<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 再设计不同的部门和岗位来承担这些职责。部门类似我们软件的package，岗位就类似我们类，具体的人就类似对象。<br />
<br />
2.找个好名字来作为类名，这个类名基本可以暗示该类的职责。<br />
<span style="color: red">Note</span>：<br />
&nbsp;&nbsp;&nbsp; 1）对人来说，一个有意义的名字，胜过千言万语。好名字的标准就是用名字表达意图。<br />
&nbsp;&nbsp;&nbsp; 2）若不能找到一个好名字，也可能暗示这个类的职责没有定义清楚，这个类存在的价值值得怀疑。<br />
&nbsp;&nbsp;&nbsp; 3）一般我们选择英文名词作为类名，比如converter就是convert好。若把软件系统比喻成机器系统，那个类就是部件，而部件一般都是用名词&nbsp; 的。当然这也不能绝对化，有些情况例外。<br />
&nbsp;&nbsp; <br />
3.定义对外接口<br />
&nbsp; <span style="color: red">Note</span>：<br />
&nbsp;&nbsp; 1）类的职责最后要转化为可供外部使用的接口，具体来说就是公共方法集。<br />
&nbsp;&nbsp;&nbsp;2）接口尽量有完备的方法（是它做的事，都应该有对应方法来做，或组合来做），同时尽量使接口小（最小化），能用接口已有方法组合来做的，就不提供其他方法，但有例外，若这种组合用法很普遍，那最好提供一个冗余方法。Java&nbsp;中的List类是一个很少的例子，本身用List.size（）== 0 方式可以达&nbsp;到判断是不是空的效果，但这种情况太普遍了，类库的设计者提供了一个isEmpty（）方法。但要注意这种的便利方法，不易太多，这些方法没有提高类的能力，只是提高了便利性。<br />
<br />
4.撰写类或接口的规范<br />
<span style="color: red">Note</span>：<br />
&nbsp; 1.撰写的类或方法规范本身也是设计的一部分工作。在Java中可以用javadoc来做。<br />
&nbsp; 2.很多人忽略撰写接口规范，实际上类设计的很大一部分工作就是定义这个接口规范。<br />
<br />
5.使用自己设计接口<br />
Note：<br />
&nbsp;1）类设计完一定要自己先去使用，站在使用者的角度去评价这个类的好坏。<br />
&nbsp;2）现在的测试驱动开发，就是一种用测试驱动设计的好办法，测试代码就是客户代码的一种。在测试过程中就能知道类设计的怎么样，若感觉不好，就需要返回去再设计。<br />
<br />
<br />
&nbsp;&nbsp; <br />
一个设计良好的类具有的一般特征：<br />
1.类接口具有完备性和最小化，适当提供冗余方法<br />
<br />
2.使类和成员的可访问性最小话<br />
理由：满足软件设计的基本原则之一封装（Encapsulation）或信息隐藏（information hiding）<br />
<br />
Java语言提供的机制：访问控制（Access Control）。<br />
如何达到：请参考Effectvie Java 中第13条。<br />
<br />
3.在共有类中使用共有方法而非共有域<br />
理由：共有域属于实现细节的东西，不应该暴露出去，这样就违背了封装原则。<br />
<br />
4.使可变性最小化<br />
理由：类是具有职责的实体，根据单一职责原则，一个类应该只有一个或一类职责，也就是说只有一个引起类变化的原因。导致类可变性越小，修改这个类的机会就越小，从而提高了维护性和减少Bug。<br />
<br />
5.接口命名具有一致性<br />
理由：设计一个接口类似在设计一个简单的语言，若接口命名不一致，就会导致使用者的困惑和费解。<br />
<br />
<br />
<br />
</p>
<img src ="http://www.blogjava.net/devin/aggbug/270046.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/devin/" target="_blank">delvin</a> 2010-07-16 08:47 <a href="http://www.blogjava.net/devin/archive/2010/07/16/270046.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss>