Tag/
共56个网摘 [
1 2 ]
下一页 |
sunjiahaoz收录，使用标签：面向对象，时间：2008-6-13 19:29:18 | 相关网摘，我也收藏
“接口是完全抽象的成员集合，它的成员都无法在接口定义时实现，我们可以将它看作是为操作定义合同，接口的实现完全留给开发者去做。它们之间的区别，如果认真分析，还是有不少的：在JAVA中，类只能是从一个基类继承，所以如果要使用抽象类为一组类提供多态性，这些类必须都是从那个类继承的；接口就不一样了，它不但可以用一个类或结构实现多个接口，一个接口还可以有多个实现。”
抽象类是一种不能实例化而必须从中继承的类。抽象类可以完全实现，但更常见的是部分实现或者根本不实现，从而封装继承类的通用功能，它可以提供已实现的成员，因此，可以用抽象类确保特定数量的相同功能，但不能用接口这样做。
“也就是说，它们在提供多态性的问题上是有差别的？”我好象听懂了点什么。
“如果预计要创建组件的多个版本，我们应该创建抽象类。这是因为，抽象类提供简单易行的方法来控制组件版本。通过更新基类，所有继承类都随更改自动更新。这是好处，当然也是问题.另一方面，接口一旦创建就不能更改。如果需要接口的新版本，必须创建一个全新的接口。所以，如果创建的功能将在大范围的全异对象间使用，则使用接口。”------：“能不能这样说，抽象类主要用于关系密切的对象，而接口最适合为不相关的类提供通用功能。”
我上午跟你说，要创建控件，首先就是要对一些接口进行实现以让系统能够识别（详见前文《接口》）。而各个控件之间的联系其实关联性并不大。所以，它们的基础大都是接口。但是，我们要注意一点，在组件设计时，如果要在组件的所有实现间提供通用的已实现功能，则使用抽象类。这是因为我们刚才说过的原因，抽象类允许部分实现类，而接口不包含任何成员的实现。”
“唔，明白了，它们之间的区别有点明白了。”我默默地点了点头。
“另外，有个通用的设计思想，如果要设计小而简练的功能块，则使用接口。如果要设计大的功能单元，则使用抽象类。”
“看来设计的问题还是蛮大的，一般来说，怎么设计接口呢？”我接着问。
“为什么你所看到的编程书籍也好，程序例程也好，极少有对接口的描述，而对类实现继承的例子比比皆是？这就从一个侧面给我们提了一个醒，如果使用适当，接口可以成为很有用的工具。但如果使用不当，它们会变得非常棘手，甚至妨碍有效的编程。接口的设计与使用其实是一项高明的艺术。”
，“通过接口与实现的方式，我们可以将同一类型的程序运用在不同的对象上面，而且不必修改原有类，相对子程序必须通过修改源程序代码才能够达到重用的目的，接口与实现不仅是伟大的进步，也是境界极高的程序设计艺术。”
“但是，最大的问题还是集中在接口设计上。接口一旦被定义和接受，就必须保持不变，以保护为使用该接口而编写的应用程序。接口发布后，就不能对其进行更改。这是我们进行组件设计的一个重要原则，叫做‘接口不变性’。”
“我已经反反复复强调过，创建一个接口就是在创建一个定义，接口定义发布后则永远不能更改。接口不变性，就是为了保护为使用接口而编写的现有系统。当接口设计与需求有所出入，确认需要大幅度变更时，我们应该创建新的接口。一般命名方式是，新接口可以通过在原来的接口名称后追加一个数字‘2’来命名，以显示出它与现有接口的关系。然后通过接口继承来创建新接口。”
“可是，如果需求分析得不好，岂不是会出现一大堆的派生接口了？”我不免有点顾虑。
“这是肯定的，而且过于频繁地生成新接口，会因未使用的接口实现而使组件变得很庞大。有经验的设计师，在充分分析需求后，设计出的接口往往很小且相互独立，减少了性能问题发生的可能。”
“这种分解能力倒真的是艺术呀！”我不禁为之叹服。
“当然，一般来说，我们会把确定哪些属性和方法属于接口的设计过程称为‘接口分解’。基本准则是，应在一个接口中将紧密相关的几个功能聚合为一组。功能太多会使接口不便于运行，而过于细分功能将导致额外的系统开销并降低使用的简易性。掌握分解的这个度的能力是需要不断的在技术上进行磨炼，以及在对每个项目深入分析与理解的基础上才能得到的。”
接口与类实现继承相比，好处有什么？”：“我试着说一下吧，总体而言，接口是一种非常有效的编程方法，它让对象的定义与实现分离，从而可以在不破坏现有应用程序的情况下使对象得以完善与进化。接口消除了实现继承的一个大问题，就是在对设计实施后再对其进行更改时很可能对代码产生破坏。即使实现继承允许类从基类继承实现，在类首次发布时仍然会使我们不得不为设计做很多的抉择。如果原有的设想不正确，并非总可以在以后的版本中对代码进行安全的更改。比如，我们定义了一个基类的方法，它需要一个 Integer 参数，而后来又确定该参数应该为 Long 数据类型。我们无法安全更改原始类，因为为从原始类派生的类所设计的应用程序可能无法进行正确编译。这一问题会扩大化，因为单个基类会影响几百个子类。”
“那用重载原始类并采用一个Long类型的参数，不就能解决这个问题了吗？”大李提了个问题。
“这个么？”我想了一下，“可是，这样不一定能达到满意的效果，因为一个派生类可能需要对采用整数的方法进行重写，如果取 Long 数据类型的方法不能被重写，该派生类可能无法正常运行。”
“那用接口怎么做？”大李不依不挠地继续问。
“办法就是发布接受新数据类型的更新接口。”我一下子就回答出来了。
“看来你已经掌握了接口操作的基本环节了。”大李的评语真让我高兴。“我再帮你总结一下，使用接口继承而不用类继承的主要原因有：在应用程序要求很多可能不相关的对象类型以提供某种功能的情况下，用接口适用性会更强；接口比基类更灵活，因为可以定义单个实现来实现多个接口；在无需从基类继承实现的情况下，接口更好；在无法使用类继承的情况下接口是很有用的。例如，结构无法从类继承，但它们可以实现接口。”
本文来自: IT知道网(http://www.itwis.com) 详细出处参考：http://www.itwis.com/html/java/j2se/20070919/237.html
http://www.itwis.com/html/java/j2se/20070919/237.html
nlz137收录，使用标签：java, 面向对象，时间：2008-5-22 11:34:16 | 相关网摘，我也收藏
“你不必严格遵守这些原则，违背它们也不会被处以宗教刑罚。但你应当把这些原则看成警铃，若违背了其中的一条，那么警铃就会响起。”
----------Arthur J.Riel
(1)所有数据都应该隐藏在所在的类的内部。
(2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。
(3)尽量减少类的协议中的消息。
(4)实现所有类都理解的最基本公有接口[例如，拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。
(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。
如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。
(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。
(7)类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。
(8)类应该只表示一个关键抽象。
包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响 .
(9)把相关的数据和行为集中放置。
设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。
(10)把不相关的信息放在另一个类中(也即：互不沟通的行为)。
朝着稳定的方向进行依赖.
(11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。
(12)在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。
(13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。
规划一个接口而不是实现一个接口。
(14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。
(15)对包含太多互不沟通的行为的类多加小心。
这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。
(16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。
(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。
(18)从你的设计中去除不需要的类。
一般来说，我们会把这个类降级成一个属性。
(19)去除系统外的类。
系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。
(20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。
http://seagar.javaeye.com/blog/159362
haozhixin1224收录，使用标签：java, 面向对象，时间：2008-5-20 16:29:25 | 相关网摘，我也收藏
“你不必严格遵守这些原则，违背它们也不会被处以宗教刑罚。但你应当把这些原则看成警铃，若违背了其中的一条，那么警铃就会响起。”
----------Arthur J.Riel
(1)所有数据都应该隐藏在所在的类的内部。
(2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。
(3)尽量减少类的协议中的消息。
(4)实现所有类都理解的最基本公有接口[例如，拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。
(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。
如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。
(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。
(7)类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。
(8)类应该只表示一个关键抽象。
包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响 .
(9)把相关的数据和行为集中放置。
设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。
(10)把不相关的信息放在另一个类中(也即：互不沟通的行为)。
朝着稳定的方向进行依赖.
(11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。
(12)在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。
(13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。
规划一个接口而不是实现一个接口。
(14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。
(15)对包含太多互不沟通的行为的类多加小心。
这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。
(16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。
(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。
(18)从你的设计中去除不需要的类。
一般来说，我们会把这个类降级成一个属性。
(19)去除系统外的类。
系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。
(20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。
http://seagar.javaeye.com/blog/159362
luohg666收录，使用标签：java, 面向对象，时间：2008-5-20 16:05:34 | 相关网摘，我也收藏
“你不必严格遵守这些原则，违背它们也不会被处以宗教刑罚。但你应当把这些原则看成警铃，若违背了其中的一条，那么警铃就会响起。”
----------Arthur J.Riel
(1)所有数据都应该隐藏在所在的类的内部。
(2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。
(3)尽量减少类的协议中的消息。
(4)实现所有类都理解的最基本公有接口[例如，拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。
(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。
如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。
(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。
(7)类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。
(8)类应该只表示一个关键抽象。
包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响 .
(9)把相关的数据和行为集中放置。
设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。
(10)把不相关的信息放在另一个类中(也即：互不沟通的行为)。
朝着稳定的方向进行依赖.
(11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。
(12)在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。
(13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。
规划一个接口而不是实现一个接口。
(14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。
(15)对包含太多互不沟通的行为的类多加小心。
这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。
(16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。
(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。
(18)从你的设计中去除不需要的类。
一般来说，我们会把这个类降级成一个属性。
(19)去除系统外的类。
系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。
(20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。
http://seagar.javaeye.com/blog/159362
共56个网摘 [
1 2 ]
下一页