提出问题**

项目中如何使用类和接口???

解决问题

使类和成员的可访问性最小化

要区别设计良好的模块与设计不好的模块,最重要的因素在于,这个模块对于外部的其他模块而言,是否隐藏其内部数据和其他实现细节。

第一原则很简单:尽可能地使每个类或者成员不被外界访问。换句话说,应该使用与你正在编写的软件的对于功能相一致的,尽可能最小的访问级别。

对于顶级的类和接口,只有两种可能的访问级别:包级私有的(package-private)和公有的(public)。

对于成员,有四种访问级别,具体的就不说了。

实例域决不能是公有的,特别是指向一个可变对象的。

例如:

  1. //错误的
  2. public static final Thing[] VALUES = { }
  3. 解决方法:
  4. private static final Thing[] PRIVATE_VALUES = { .... }
  5. public static final List<Thing> VALUES = Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES));

另一种解决方法是:添加一个公有方法,返回私有数组的一个备份:

  1. private static final Thing[] PRIVATE_VALUES = { .... }
  2. public static final Thing[] values(){
  3. return PRIVATE_VALUES.clone();
  4. }

总而言之,你应该始终尽可能地降低可访问性。除了公有静态final域的特殊情形之外,公有类都不应该包含公有域。并且要确保公有静态final域所引用的对象都是不可以变得。

在公有类中使用访问方法而非公有域
错误的:

  1. class Point{
  2. public double x;
  3. public double y;
  4. }

正确的:

  1. class Point{
  2. private double x;
  3. private double y;
  4. public Point(double x, double y) {
  5. this.x = x;
  6. this.y = y;
  7. }
  8. public double getX() {
  9. return x;
  10. }
  11. public void setX(double x) {
  12. this.x = x;
  13. }
  14. public double getY() {
  15. return y;
  16. }
  17. public void setY(double y) {
  18. this.y = y;
  19. }
  20. }

总而言之,公有类永远都不应该暴露可变得域,虽然还是有问题,但是让公有类暴露不可变得域其危害性比较小。

使可变性最小

为了使类成为不可变,要遵循下面5条规则:

  • 不要提供任何会修改对象状态的方法
  • 保证类不会被扩展(做法:让类成为final类型)
  • 使所有的域都是final的
  • 使所有的域都成为私有的
  • 确保对于任何可变组件的互斥访问

不可变对象优点:

  • 不可变对象比较简单
  • 不可变对象本质上是线程安全的,它们不要求同步。
  • 不可变对象可以被自由分享
  • 复合优先于继承

不用扩展现有的类,而是在新的类中增加一个私有域,它引用现有类的一个实例。这种设计称做“复合”。

总结:继承的功能非常强大,但是也存在很多问题,因为它违背了封装原则。只有当子类和超类之间确实存在子类型关系时,使用继承才是恰当的。即使如此。如果子类和超类处在不同的包中,并且超类并不是为了继承而设计的,那么继承将会导致脆弱性。为了避免这种脆弱性,可以用复合和转发机制来代替继承,尤其是但存在适当的接口可以实现包装类的时候。包装类不仅比子类更加健壮,而且功能也更加强大。

具体例子可以看《Effective Java》书中的例子。

要么为继承而设计,并提供文档说明,要么就禁止继承
关于程序文档有句格言:好的API文档应该描述一个给定的方法做了什么工作,而不是描述它是如何做到的。

标题说的挺明确的,用的比较少,具体就不多说明了。

接口优于抽象类
类层次优于标签类
例如下面是一个标签类:

  1. class Figure{
  2. enum Shape{RECTANGLE,CIRCLE}
  3. final Shape shape;
  4. double length;
  5. double width;
  6. double radius;
  7. Figure(double radius){
  8. shape = Shape.CIRCLE;
  9. this.radius = radius;
  10. }
  11. Figure(double length,double width){
  12. shape = Shape.RECTANGLE;
  13. this.length = length;
  14. this.width = width;
  15. }
  16. double area(){
  17. switch (shape){
  18. case RECTANGLE:
  19. return length * width;
  20. case CIRCLE:
  21. return Math.PI * (radius * radius);
  22. default:
  23. throw new AssertionError();
  24. }
  25. }
  26. }

标签类过于冗长,容易出错,并且效率低下。

改正后的代码,下面是类层次:

  1. abstract class Figure{
  2. abstract double area();
  3. }
  4. class Circle extends Figure{
  5. final double radius;
  6. Circle(double radius){ this.radius = radius;}
  7. double area(){ return Math.PI * (radius * radius);}
  8. }
  9. class Rectangle extends Figure{
  10. final double length;
  11. final double width;
  12. Rectangle(double length,double width){
  13. this.length = length;
  14. this.width = width;
  15. }
  16. double area(){ return length * width;}
  17. }

用函数对象表示策略

感觉工作用的比较少,具体可以看书本例子。

接口只用于定义类型

当类实现接口时,接口就充当可以引用这个类的实例的类型。因此,类实现类接口,就表明客户端可以对这个类的实例实施某些动作。为了任何其他目的而定义接口是不恰当的。

常量接口:接口没有包含任何方法,它只包含静态final域。

  1. public interface ObjectStreamConstants {
  2. /**
  3. * Magic number that is written to the stream header.
  4. */
  5. final static short STREAM_MAGIC = (short)0xaced;
  6. /**
  7. * Version number that is written to the stream header.
  8. */
  9. final static short STREAM_VERSION = 5;
  10. /* Each item in the stream is preceded by a tag
  11. */
  12. }

常量接口模式是对接口的不良使用。

解决方案:

如果这些常量与某个现有的类或者接口紧密相关,就应该把这些常量添加到这个类或者接口中。

简而言之,接口应该只被用来定义类型,它们不应该被用来导出常量。

优先考虑静态成员类

嵌套类:是指被定义在另一个类的内部的类。嵌套类有四种:静态成员类,非静态成员类,匿名类和局部类,除了第一种之外,其他三种都被称为内部类。

总结:如果一个嵌套类需要在单个方法之外仍然是可见的,或者它太长了,不适合于放在方法内部,就应该使用成员类。如果成员类的每个实例都需要一个指向其外围实例的引用,就要把成员类做成非静态的;否则做成静态的。假设这个嵌套类属于一个方法的内部,如果你只需要在一个地方创建实例,并且已经有了一个预置的类型可以说明这个类的特征,就要把它做成匿名类;否则,就做成局部类。