关于并发的详细内容我们将会在后续的文章中讨论)。
package com.javacodegeeks.advanced.construction.patterns;
public class LazySingleton {
private static LazySingleton instance;
private LazySingleton() {
}
public static synchronized LazySingleton getInstance() {
if( instance == null ) {
instance = new LazySingleton();
}
return instance;
}
}
如今,在大多数的案例中单例模式并不被考虑作为一个很好的选择,主要是因为单例模式将会导致代码很难测试。依赖注入模式让单例模式变得没有必要。
4.2 Utility/Helper类
utility或者helper类是被许多开发者所使用的相当流行的一种模式。基本来说,它所代表的是无实例( non-instantiable)类(构造器被定义成private),仅仅可以选择将方法定义成final(后续会介绍如何定义类)或者static。比如;
package com.javacodegeeks.advanced.construction.patterns;
public final class HelperClass {
private HelperClass() {
}
public static void helperMethod1() {
// Method body here
}
public static void helperMethod2() {
// Method body here
}
}
站在开发者的角度,helpers类经常所扮演的是一个容器的角色,这个容器中放了很多在其他地方找不到但是其他类需要相互共享和使用的互相不相关的方法。这种设计决定了在很多情况下要避免使用:总能找到另一种重用所需功能的方式,保持代码的简洁和清晰。
4.3 工厂模式(Factory)
工厂模式被证明是软件开发人员手中非常有用的技术。因此,Java有几种风格工厂模式,从工厂方法到抽象工厂。工厂模式最简单的例子是返回特定类的新实例的静态方法(工厂方法)。例如:
package com.javacodegeeks.advanced.construction.patterns;
public class Book {
private Book( final String title) {
}
public static Book newBook( final String title ) {
return new Book( title );
}
}
有人可能会争辩说,介绍newBook工厂方法并没有什么意义,但是使用这种模式通常会使代码更具可读性。工厂模式的另一个变化涉及接口或抽象类(抽象工厂)。例如,让我们定义一个工厂接口:
public interface BookFactory {
Book newBook();
}
依赖库类型,完成几种不同的实现:
public class Library implements BookFactory {
@Override
public Book newBook() {
return new PaperBook();
}
}
public class KindleLibrary implements BookFactory {
@Override
public Book newBook() {
return new KindleBook();
}
}
现在,Book的特定类被隐藏在BookFactory接口实现之后,BookFactory仍然提供创建book的通用方式。
4.4 依赖注入(Dependency Injection)
依赖注入(一说控制反转)被类设计者认为是一个很好的做法:如果某些类的实例依赖其他类的实例,被依赖的实例应该通过构造(比如通过设置器——setters,或者策略——strategies模式等)的思想提供给依赖的实例,而不是依赖的实例自行创建。看一下下面这种情况:
package com.javacodegeeks.advanced.construction.patterns;
import java.text.DateFormat;
import java.util.Date;
public class Dependant {
private final DateFormat format = DateFormat.getDateInstance();
public String format( final Date date ) {
return format.format( date );
}
}
类Dependant需要一个DateFormat的实例,并且它仅仅只是在构造时通过调用DateFormat.getDateInstance() 创建。最好的设计方案应该是通过构造器参数的形式去完成相同的事情。
package com.javacodegeeks.advanced.construction.patterns;
import java.text.DateFormat;
import java.util.Date;
public class Dependant {
private final DateFormat format;
public Dependant( final DateFormat format ) {
this.format = format;
}
public String format( final Date date ) {
return format.format( date );
}
}
按这种方案实现的话,类的所有依赖都是通过外部提供,这样就很容易的修改date format和为类写测试用例。
在本系列文章的这一部分中,我们一直在研究类和类的实例构造以及初始化技术,涵盖了几种广泛使用的模式。在下一部分中,我们将分析Object类以及其熟知方法的用法:equals,hashCode,toString和clone。
原文链接:https://blog.csdn.net/zyhlwzy/article/details/78937421
版权声明:本文为CSDN博主「RonTech」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
近期热文推荐:
1.1,000+ 道 Java面试题及答案整理(2022最新版)
2.劲爆!Java 协程要来了。。。
3.Spring Boot 2.x 教程,太全了!
4.别再写满屏的爆爆爆炸类了,试试装饰器模式,这才是优雅的方式!!
5.《Java开发手册(嵩山版)》最新发布,速速下载!
觉得不错,别忘了随手点赞+转发哦!