类和接口

最新推荐文章于 2023-08-26 18:52:36 发布

发飙的蜗牛咻咻咻~

最新推荐文章于 2023-08-26 18:52:36 发布

阅读量281

点赞数 3

分类专栏： ★ Java 编程规范文章标签： Effective Java 开发干货实用经验读书笔记

huadong

本文链接：https://blog.csdn.net/qq_36221788/article/details/95751740

版权

★ Java 编程规范专栏收录该内容

4 篇文章 0 订阅

订阅专栏

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

设计良好的模块会隐藏所有的实现细节，把它的API与它的实现清晰的隔离开来。然后，模块之间只通过他们的API进行通行，一个模块不需要知道其他模块的内部工作情况。这个概念就被称为封装。
信息隐藏之所以非常重要有许多原因，其中大多数理由都源于这样一个事实：它可以有效地解除组成系统的各模块之间的耦合关系，使得这些模块可以独立地开发、测试、优化、使用、理解和修改。

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

第14条在公有类中使用访问方法而非公有域

公有域，该类的数据域可以直接访问

class Point {
	public double x;
	public double y;
}

私有域，提供公有访问方法

public class Point {
    private double x;
    private double y;

    public Point(double x, double y) {
        this.x = x;
        this.y = y;
    }
    public Point() {}

    public double getX() {return x;}
    public void setX(double x) {this.x = x;}

    public double getY() {return y;}
    public void setY(double y) {this.y = y;}
}

让公有类直接暴露域虽然从来都不是种好办法，但是如果域是不可变的，这种做法的危害就小一些。

public final class Time {
    private static final int HOURS_PER_DAY = 24;
    private static final int MINUTES_PER_HOURS = 60;

    public final int hour;
    public final int minute;

    public Time(int hour, int minute) {
        if (hour < 0 || hour >= HOURS_PER_DAY) {
            throw new IllegalArgumentException("Hour: " + hour);
        }
        if (minute < 0 || minute >= MINUTES_PER_HOURS) {
            throw new IllegalArgumentException("Minute: " + minute);
        }
        this.hour = hour;
        this.minute = minute;
    }
}

第15条使可变性最小化

为了使类成为不可变，要遵循下面五条规则：

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

不可变类的优缺点：

不可变类本质上是线程安全的，它们不要求同步
不仅可以共享不可变对象，甚至也可以共享它们的内部信息
不可变对象为其他对象提供了大量的构件
不可变类唯一的缺点是，对于每个不同的值都需要一个单独的对象。

保证类不会被扩展，就是为了防止子类实例化，一般做法是是这个类成为final类，另一种办法是让类的所有构造器都变成私有的或者包级私有的，并添加公有的静态工厂来代替公有的构造器。

public class Complex {
    private final double re;
    private final double im;

    private Complex(double re, double im) {
        this.re = re;
        this.im = im;
    }
    public static Complex valueOf(double re, double im) {
        return new Complex(re, im);
    }
}

除非有很好的理由要让类成为可变的类，否则就应该是不可变的。不可变的类有许多优点，唯一缺点是在特定的情况下存在潜在的性能问题。你应该总是使一些小的值对象成为不可变的，在Java平台类库中，有几个类如java.util.Date和java.awt.Point，他们本应该是不可变的，但实际上却不是。你也应该认真考虑把一些较大的值对象做成不可变的，例如String和BigInteger。只有你确认有必要实现令人满意的性能时，才应该为不可变的类提供公有的可变配套类，就像String的可变配套类StringBuilder。

第16条复合优先于继承

在包的内部使用继承是非常安全的，在那里，子类和超类的实现都处在同一个程序员的控制之下。然而，对普通的具体类进行跨越包边界的继承，则是非常危险的。
继承打破了封装性。使用了继承，子类必须要跟着其超类的更新而演变。
使用复合而非继承的方式，就是现有类变成一个新类的组件，新类中的每个实例方法都可以调用被包含的现有类实例中对应的方法，并返回它们的结果。这被称为转发。这种设计可以让类获得健壮性，也带来了格外的灵活性。
只有当子类真正是超类的子类型时，才适合用继承。
如果在适合于使用复合的地方是用了继承，则会不必要地暴露实现细节。这样得到的API会把你限制在原始的实现上，永远限定了类的性能。
继承的功能非常强大，但是也存在诸多问题，因为它违背了封装原则。
当两者之间确实存在“is-a”关系的时候，才应该用继承。否则就优先考虑复合，“has-a”。

第17条要么为继承而设计，并提供文档说明，要么就禁止继承

首先，该（被继承）类的文档必须精确地描述覆盖每个方法所带来的影响。换句话说，该类必须有文档说明他可覆盖的方法的自用性。为了允许继承，类还必须遵守其他的一些约束。构造器决不能调用可被覆盖的方法，无论是直接调用还是间接调用。如果违反这条规则，很可能导致程序失败，比如下面这个例子：

public class Super {
    public Super() {
        overrideMe();
    }
    
    public void overrideMe() {
    }
}

public class Sub extends Super {
    private final Date date;

    public Sub() {
        date = new Date();
    }

    @Override
    public void overrideMe() {
        System.out.println(date);
    }

    @Test
    public void test() {
        Sub sub = new Sub();
        sub.overrideMe();
    }
}

看看结果：

null
null
Sun Jul 14 16:07:25 CST 2019

这段代码，final域处于两种不同的状态，而且如果overrideMe中调用了任何date相关的方法的话，会直接报空异常。

第18条接口优于抽象类

接口和抽象类这两种机制之间最明显的区别在于：

抽象类允许包含某些方法的实现，但是接口不允许。
为了实现由抽象类定义的类型，类必须成为抽象类的一个子类。然而因为Java只允许单继承，所以，抽象类作为类型定义受到了极大的限制。

现有的类可以很容易被更新，以实现新的接口。
接口是定义mixin（混合类型）的理想选择。
接口允许我们构造非层次结构的类型框架。

一般来说，要想在公有接口中增加方法，而不破坏实现这个接口的所有现有的类，这是不可能的。
简而言之，接口通常是定义允许多个实现的类型的最佳途径。这条规则有个例外，即当演变的容易性比灵活性和功能更为重要的时候。应该使用抽象类来定义类型，但前提是必须理解并且可以接受这些局限性。

第19条接口只用于定义类型

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

有一种接口被称为常量接口，如下：

public interface PhysicalConstants {
    double AVOGADROS_NUBER = 6.022214199e23;
    double BOLTZMANN_CONSTANT = 1.3806503e-23;
    double ELECTRON_MASS = 9.10938188e-31;
}

常量接口模式是对接口的不良使用。接口本来目的知识提供常量，但是要是用户不慎实现了该接口，会导致把这样的实现细节泄漏到该类的导出API中。类实现常量接口，这对于这个类的用户来讲并没有什么价值。

在java平台类库中有几个常量接口，例如java.io.ObjectStreamConstants。这些接口应该被认为是反面的典型，不值得效仿。

如果要导出常量，可以有几种合理的选择方案。比如说可以使用不可实例化达工具类来导出这些常量：

public class PhysicalUtilsConstants {
    private PhysicalUtilsConstants() {
    }

    public static final double AVOGADROS_NUBER = 6.022214199e23;
    public static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
    public static final double ELECTRON_MASS = 9.10938188e-31;
}

工具类通常要求客户端要用类名来修饰这些常量名。如果大量利用工具类导出的常量，可以通过利用静态导入机制。

第20条类层次优于标签类

先来看看这个类，它能够表示圆形或者矩形：

public class Figure {
    
    enum Shape {RECTANGLE, CIRCLE};

    final Shape shape;
    
    double length;
    double width;
    
    double radius;

    public Figure(double radius) {
        shape = Shape.CIRCLE;
        this.radius = radius;
    }

    public Figure(double length, double width) {
        shape = Shape.RECTANGLE;
        this.length = length;
        this.width = width;
    }

    double area() {
        switch (shape) {
            case RECTANGLE:
                return length * width;
            case CIRCLE:
                return Math.PI * (radius * radius);
            default:
                throw new AssertionError();
        }
    }
}

这种标签类有着许多缺点。他们中充斥着样板代码，包括枚举声明，标签域以及条件语句。由于多个实现乱七八糟地挤在了单个类中，破坏了可读性。而且，标签类过于垄长、容易出错，并且效率低下。

辛运的是，面向对象的语言例如Java，就提供了其他更好的方法来定义能表示多种风格对象的单个数据类型：子类型化。标签类正是类层次的一种简单的效仿。先来看看类层次改造后的代码：

public abstract class Figure {
    abstract double area();
}

public class Circle extends Figure {
    final double radius;

    public Circle(double radius) {
        this.radius = radius;
    }
    
    @Override
    double area() {
        return Math.PI * (radius * radius);
    }
}

public class Rectangle extends Figure {
    final double length;
    final double width;

    public Rectangle(double length, double width) {
        this.length = length;
        this.width = width;
    }

    @Override
    double area() {
        return length * width;
    }
}

这个层次类纠正了前面提到过的标签类的所有缺点。这段代码简单且清楚，没有包含在原来的版本中所见到的所有样板代码。每个类型的实现都配有自己的类，这些类都没有受到不相关的数据域的拖累。

类层次另一种好处在于，它们可以用来反映类型之间本质上的层次关系，有助于增强灵活性，并进行更好的编译时类型检查。

简而言之，标签类很少有适用的时候。当你想要编写一个包含显示标签域的类是，应该考虑一下这个标签是否可以被取消，这个类是否可以用类层次来代替。当你遇到一个包含标签域的现有类时，就要考虑将它重构到一个层次结构中去。

第21条用函数对象表示策略

其实这一条可以用Java8的Lambda表达式替代

第22条优先考虑静态成员类

嵌套类是指被定义在另一个类的内部的类。嵌套类存在的目的应该只是为了它的外围类提供服务。如果嵌套类将来可能会用于其他的某个环境中，他就应该是顶层类。嵌套类有四种：静态成员类、非静态成员类、匿名类和局部类。其中除了第一种之外，其他三种都被称为内部类。

静态成员类是最简单的一种嵌套类。最好把它看作是普通的类，只是碰巧被声明在另一个类的内部而已，它可以访问外围类的所有成员，包括哪些声明为私有的成员。

静态成员类的一种常见用法是作为公有的辅助类，仅当与它的外部类一起使用时才有意义。

尽管，静态成员类和非静态成员类之间唯一的区别是，静态成员类的声明中包含修饰符static。但是，这两种嵌套类有很大的不同。非静态成员类的每个实例都隐含着与外围类的一个外围实例相关联。在非静态成员类的实例方法内部，可以调用外围实例上的方法，或者利用修饰过的this构造获得外围实例的引用。如果嵌套类的实例可以在他外围类的实例之外独立存在，这个嵌套类就必须是静态成员类：在没有外围实例的情况下，要想创建非静态成员类的实力是不可能的。

非静态成员类的一种常见用法是定义一个Adapter，它允许外部类的实例被看作是另一个不相关的类的实例。例如，Map接口的实现往往使用非静态成员类来实现他们的集合视图，这些集合视图是用Map的keySet、entrySet和Values方法返回的。同样地，诸如Set和List这种集合接口的实现往往也使用非静态成员类来实现他们的迭代器

public class MySet<E> extends AbstractSet<E> {
    @Override
    public Iterator<E> iterator() {
        return new MyIterator();
    }

    private class MyIterator implements Iterator<E>{
    }
}

如果声明成员类不要求访问外围实例，就要始终把static修饰符放在他的声明中，使它成为静态成员类，而不是非静态成员类。

发飙的蜗牛咻咻咻~

关注

3
点赞
踩
0

收藏

觉得还不错? 一键收藏
打赏
0
评论
类和接口

类和接口是Java程序设计的核心，它们也是Java语言的基本抽象单元。Java语言提供了许多欠打的基本元素，供程序员用来设计类和接口。本章阐述的一些指导原则，可以帮助更好地利用这些元素，设计出更加有用、健壮和灵活的类和接口。
复制链接

扫一扫