首页 > 代码库 > 数据的封装和隐藏原则

数据的封装和隐藏原则

这是我第一篇文章,总结了网上牛人的经验,以及我在实践中的思考,记录总结,以便日后回顾。

1.尽量降低耦合

1.1.原理:

  Martin Fowler写到“任何全局数据通常都是有问题的,除非可以证明它确实没有问题”。多种原因 导致Java中的全局变量和其他类似的全局结构被认为是一种糟糕的做法。

全局数据的本质和含义违背了数据的封装和隐藏原则。
理想的情况下,

一个对象应该仅仅与那些通过构造函数或方法调用传入的对象交互一个对像的实现应当对它的使用者完全隐藏实现细节。(封装隐藏)

所有使用到了这个全局数据的functions都会受到影响,于是所有的这些代码都要被检测、修改、重新测试,
而且,修改所有使用了这个变量的function影响到的其它地方,就这样,
一个变量值的改变影响了一个方法,又造成另一个方法的错误。在程序中,这样问题实在是可怕。

OO系统的一个基本原则是一个Object不应暴露它的实现细节,这样,当你改变了实现细节,就可以不用改变使用了该对像的的代码部份。所以,你应当避免getter 和 setter 函数,

因为它们主要用来访问实现细节。

1.2.实践:

尽可能地减少可变状态。特别是在并发程序中。总之,尽可能地减少可变状态。

1.2.1.减少全局数据的使用;而对于一个对象而言,尽量减少成员变量的使用。

1.2.2.尽可能少地暴露对象自已的状态,即不能够使用(或尽可能少地使用)get/set方法。一个状态的改变,应该采用一个有外部对象作为参数的方法,在该方法中进行改变(该状态)。

例如,一个对像的实例变量(非静态的域成员),应当是private,这一点没有疑义。
(你也可以偶尔用protected会更高效,但是protected实例变量是令人讨厌的),
同样原因,你也应当不用get/set 方法---它们使一个public域变的过度复杂。

 

1.3.若方法中,需传递大量参数,可以考虑传递对象,作为参数。

当然我更不喜欢在不同方法间传递大量参数,但是我们可以使用参数对象(比如 包范围内的类 )来减少参数,并在方法间传递这个对象而不是大量参数。

 

1.4.model中的大量的getter/setter方法,存在着巨大的隐患:

a.很容易忘记设置某个必须的属性,因为除了JavaBean规范外,对于编译器来说没有办法强制设置所有必须的属性。

b.set 方法的存在表示类的属性不能是 final,整个对象都极易变化。

改进办法:

1.在构造函数中,初始化所有的字段;(提供两个构造函数,一个构造函数是没有参数的,一个构造函数是带有所有字段,作为参数)
2.将所有字段都设置为final.
3.Bloch推荐在对象构造中使用builder模式。

1.4.When is an accessor okay?当返回一个接口时。

First, as I discussed earlier, it‘s okay for a method to return an object in terms of an interface
that the object implements because that interface isolates you from changes to the implementing class.

1.5.只要有可能,你就应当避免实现继承。

In general, it‘s best to avoid concrete base classes and extends relationships in favor of interfaces and implements relationships.

数据的封装和隐藏原则