优雅编程之这样使用类和接口,你就“正常”了(三十)
2016-10-06 20:21
351 查看
开心一笑
【悬崖上一只小老鼠挥舞着短短的前爪,一次又一次跳下去,努力学习飞翔,旁边母蝙蝠看着它摔的头破血流,忧心的说:它爹,要不告诉它,它不是咱亲生的!】视频教程
大家好,我录制的视频《Java之优雅编程之道》已经在CSDN学院发布了,有兴趣的同学可以购买观看,相信大家一定会收获到很多知识的。谢谢大家的支持……视频地址:http://edu.csdn.net/lecturer/994
提出问题**
项目中如何使用类和接口???解决问题
[b]使类和成员的可访问性最小化[/b]
要区别设计良好的模块与设计不好的模块,最重要的因素在于,这个模块对于外部的其他模块而言,是否隐藏其内部数据和其他实现细节。
第一原则很简单:尽可能地使每个类或者成员不被外界访问。换句话说,应该使用与你正在编写的软件的对于功能相一致的,尽可能最小的访问级别。
对于顶级的类和接口,只有两种可能的访问级别:包级私有的(package-private)和公有的(public)。
对于成员,有四种访问级别,具体的就不说了。
实例域决不能是公有的,特别是指向一个可变对象的。
例如:
//错误的
public static final Thing[] VALUES = { … }
解决方法:
private static final Thing[] PRIVATE_VALUES = { .... } public static final List<Thing> VALUES = Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES));
另一种解决方法是:添加一个公有方法,返回私有数组的一个备份:
private static final Thing[] PRIVATE_VALUES = { .... } public static final Thing[] values(){ return PRIVATE_VALUES.clone(); }
总而言之,你应该始终尽可能地降低可访问性。除了公有静态final域的特殊情形之外,公有类都不应该包含公有域。并且要确保公有静态final域所引用的对象都是不可以变得。
[b]在公有类中使用访问方法而非公有域[/b]
错误的:
class Point{ public double x; public double y; }
正确的:
class Point{ private double x; private double y; public Point(double x, double y) { this.x = x; this.y = y; } 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; } }
总而言之,公有类永远都不应该暴露可变得域,虽然还是有问题,但是让公有类暴露不可变得域其危害性比较小。
[b]使可变性最小[/b]
为了使类成为不可变,要遵循下面5条规则:
不要提供任何会修改对象状态的方法
保证类不会被扩展(做法:让类成为final类型)
使所有的域都是final的
使所有的域都成为私有的
确保对于任何可变组件的互斥访问
不可变对象优点:
不可变对象比较简单
不可变对象本质上是线程安全的,它们不要求同步。
不可变对象可以被自由分享
[b]复合优先于继承[/b]
不用扩展现有的类,而是在新的类中增加一个私有域,它引用现有类的一个实例。这种设计称做“复合”。
总结:继承的功能非常强大,但是也存在很多问题,因为它违背了封装原则。只有当子类和超类之间确实存在子类型关系时,使用继承才是恰当的。即使如此。如果子类和超类处在不同的包中,并且超类并不是为了继承而设计的,那么继承将会导致脆弱性。为了避免这种脆弱性,可以用复合和转发机制来代替继承,尤其是但存在适当的接口可以实现包装类的时候。包装类不仅比子类更加健壮,而且功能也更加强大。
具体例子可以看《Effective Java》书中的例子。
[b]要么为继承而设计,并提供文档说明,要么就禁止继承[/b]
关于程序文档有句格言:好的API文档应该描述一个给定的方法做了什么工作,而不是描述它是如何做到的。
标题说的挺明确的,用的比较少,具体就不多说明了。
[b]接口优于抽象类[/b]
[b]类层次优于标签类[/b]
例如下面是一个标签类:
class Figure{ enum Shape{RECTANGLE,CIRCLE} final Shape shape; double length; double width; double radius; Figure(double radius){ shape = Shape.CIRCLE; this.radius = radius; } 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(); } } }
标签类过于冗长,容易出错,并且效率低下。
改正后的代码,下面是类层次:
abstract class Figure{ abstract double area(); } class Circle extends Figure{ final double radius; Circle(double radius){ this.radius = radius;} double area(){ return Math.PI * (radius * radius);} } class Rectangle extends Figure{ final double length; final double width; Rectangle(double length,double width){ this.length = length; this.width = width; } double area(){ return length * width;} }
[b]用函数对象表示策略[/b]
感觉工作用的比较少,具体可以看书本例子。
[b]接口只用于定义类型[/b]
当类实现接口时,接口就充当可以引用这个类的实例的类型。因此,类实现类接口,就表明客户端可以对这个类的实例实施某些动作。为了任何其他目的而定义接口是不恰当的。
常量接口:接口没有包含任何方法,它只包含静态final域。
public interface ObjectStreamConstants { /** * Magic number that is written to the stream header. */ final static short STREAM_MAGIC = (short)0xaced; /** * Version number that is written to the stream header. */ final static short STREAM_VERSION = 5; /* Each item in the stream is preceded by a tag */ }
常量接口模式是对接口的不良使用。
解决方案:
如果这些常量与某个现有的类或者接口紧密相关,就应该把这些常量添加到这个类或者接口中。
简而言之,接口应该只被用来定义类型,它们不应该被用来导出常量。
[b]优先考虑静态成员类[/b]
嵌套类:是指被定义在另一个类的内部的类。嵌套类有四种:静态成员类,非静态成员类,匿名类和局部类,除了第一种之外,其他三种都被称为内部类。
总结:如果一个嵌套类需要在单个方法之外仍然是可见的,或者它太长了,不适合于放在方法内部,就应该使用成员类。如果成员类的每个实例都需要一个指向其外围实例的引用,就要把成员类做成非静态的;否则做成静态的。假设这个嵌套类属于一个方法的内部,如果你只需要在一个地方创建实例,并且已经有了一个预置的类型可以说明这个类的特征,就要把它做成匿名类;否则,就做成局部类。
读书感悟
来自亦舒《叹息桥》做不到是你自己的事,午夜梦回,你爱怎么回味就怎么回味,但人前人后,我要你装出什么都没有发生过的样子。你可以的,我们都可以,人都是这般活下来的。
人生就像一座桥,我们从彼处来,往那边去,一边走一边不住叹息,因恨事太多。
这是我廿一年生命中前所未有的感觉,我高兴到极限,耳边有奇异的嗡嗡声,内心涨涨地饱满,十分难以形容,但是,我没有笑,我竟想哭,要尽很大的努力才把眼泪留在眼眶内。发生了什么事?
没有人爱我,会比你爱我更多。
其他
如果有带给你一丝丝小快乐,就让快乐继续传递下去,欢迎转载,点赞,顶,欢迎留下宝贵的意见,多谢支持!相关文章推荐
- 优雅编程之这样使用对象,你就“正常”了(三十二)
- 优雅编程之这样使用对象通用方法,你就“正常”了(三十四)
- 优雅编程之这样使用CollectionUtils,你就“正常”了(三十五)
- 优雅编程之这样使用枚举和注解,你就“正常”了(二十九)
- 优雅编程之这样使用工具,你就“正常”了(十三)
- 优雅编程之这样使用Map,你就“正常”了(三十六)
- 优雅编程之这样使用CollectionUtils,你就“正常”了
- 优雅编程之这样使用泛型,你就“正常”了(三十三)
- 优雅编程之这样注释代码,你就“正常”了!
- 优雅编程之这样处理系统,你就“正常”了
- 优雅编程之这样设计通用程序,你就“正常”了(二十七)
- 优雅编程之这样考虑字符性能,你就“正常”了(二十二)
- 优雅编程之这样处理继承关系,你就“正常”了(二十六)
- 优雅编程之这样重构函数(续),你就“正常”了(二十)
- 优雅编程之这样创建类,你就“正常”了!
- 优雅编程之这样组织数据,你就“正常”了(二十五)
- 优雅编程之这样编写代码,你就“正常”了(十五)
- 优雅编程之这样写测试用例,你就”正常“了!
- 优雅编程之这样格式代码,你就"正常了"!
- 优雅编程之这样编写代码,你就“正常”了(十六)