大虎说事

王大虎:元数据(metadata)控制模块行为

王大虎

编程是一个很苦很累的活,那怎么才能减轻我们的压力呢?答案是尽量使用元数据来控制程序的行为,减少重复开发。什么是元数据?用来描述环境和数据的数据,通俗地说就是配置参数,参数可以从文件中获得,也可以从数据库中获得。举个非常简单的例子,login方法中提供了这样的逻辑:先检查IP地址是否在允许访问的列表中,然后再决定是否需要到数据库中验证密码(如果采用SSH架构,则可以通过Struts的拦截器来实现),该行为就是一个典型的元数据控制模块行为的例子,其中达到极致的就是控制反转(Inversion of Control),使用最多的就是Spring容器,在SpringContext配置文件中,基本配置如代码清单6-11所示。

代码清单6-11 SpringContext的基本配置文件

 

* * *

 

<bean id=”father” class=”xxx.xxx.xxx.Father” /> <bean id=”xx” class=”xxx.xxx.xxx.xxx”> <property name=”biz” ref=”father”></property> </bean>

 

* * *

 

然后,通过建立一个Father类的子类Son,完成一个新的业务,同时修改SpringContext文件,修改后的文件如代码清单6-12所示。

代码清单6-12 扩展后的SpringContext配置文件

 

* * *

 

<bean id=”son” class=”xxx.xxx.xxx.Son” /> <bean id=”xx” class=”xxx.xxx.xxx.xxx”> <property name=”biz” ref=”son”></property> </bean>

 

* * *

 

通过扩展一个子类,修改配置文件,完成了业务变化,这也是采用框架的好处。

3.制定项目章程

在一个团队中,建立项目章程是非常重要的,因为章程中指定了所有人员都必须遵守的约定,对项目来说,约定优于配置。相信大家都做过项目,会发现一个项目会产生非常多的配置文件。举个简单的例子,以SSH项目开发为例,一个项目中的Bean配置文件就非常多,管理非常麻烦。如果需要扩展,就需要增加子类,并修改SpringContext文件。然而,如果你在项目中指定这样一个章程:所有的Bean都自动注入,使用Annotation进行装配,进行扩展时,甚至只用写一个子类,然后由持久层生成对象,其他的都不需要修改,这就需要项目内约束,每个项目成员都必须遵守,该方法需要一个团队有较高的自觉性,需要一个较长时间的磨合,一旦项目成员都熟悉这样的规则,比通过接口或抽象类进行约束效率更高,而且扩展性一点也没有减少。

4.封装变化

对变化的封装包含两层含义:第一,将相同的变化封装到一个接口或抽象类中;第二,将不同的变化封装到不同的接口或抽象类中,不应该有两个不同的变化出现在同一个接口或抽象类中。封装变化,也就是受保护的变化(protected variations),找出预计有变化或不稳定的点,我们为这些变化点创建稳定的接口,准确地讲是封装可能发生的变化,一旦预测到或“第六感”发觉有变化,就可以进行封装,23个设计模式都是从各个不同的角度对变化进行封装的,我们会在各个模式中逐步讲解。

王大虎

6.5 最佳实践

软件设计最大的难题就是应对需求的变化,但是纷繁复杂的需求变化又是不可预料的。我们要为不可预料的事情做好准备,这本身就是一件非常痛苦的事情,但是大师们还是给我们提出了非常好的6大设计原则以及23个设计模式来“封装”未来的变化,我们在前5章中讲过如下设计原则。

·Single Responsibility Principle:单一职责原则

·Open Closed Principle:开闭原则

·Liskov Substitution Principle:里氏替换原则

·Law of Demeter:迪米特法则

·Interface Segregation Principle:接口隔离原则

·Dependence Inversion Principle:依赖倒置原则

把这6个原则的首字母(里氏替换原则和迪米特法则的首字母重复,只取一个)X就是SOLID(solid,稳定的),其代表的含义也就是把这6个原则结合使用的好处:建立稳定、灵活、健壮的设计,而开闭原则又是重中之重,是最基础的原则,是其他5大原则的精神领袖。我们在使用开闭原则时要注意以下几个问题。

·开闭原则也只是一个原则

开闭原则只是精神口号,实现拥抱变化的方法非常多,并不局限于这6大设计原则,但是遵循这6大设计原则基本上可以应对大多数变化。因此,我们在项目中应尽量采用这6大原则,适当时候可以进行扩充,例如通过类文件替换的方式完全可以解决系统中的一些缺陷。大家在开发中比较常用的修复缺陷的方法就是类替换,比如一个软件产品已经在运行中,发现了一个缺陷,需要修正怎么办?如果有自动更新功能,则可以下载一个.class文件直接覆盖原有的class,重新启动应用(也不一定非要重新启动)就可以解决问题,也就是通过类文件的替换方式修正了一个缺陷,当然这种方式也可以应用到项目中,正在运行中的项目发现需要增加一个新功能,通过修改原有实现类的方式就可以解决这个问题,前提条件是:类必须做到高内聚、低耦合,否则类文件的替换会引起不可预料的故障。

·项目规章非常重要

如果你是一位项目经理或架构师,应尽量让自己的项目成员稳定,稳定后才能建立高效的团队文化,章程是一个团队所有成员共同的知识结晶,也是所有成员必须遵守的约定。优秀的章程能带给项目带来非常多的好处,如提高开发效率、降低缺陷率、提高团队士气、提高技术成员水平,等等。

·预知变化

在实践中过程中,架构师或项目经理一旦发现有发生变化的可能,或者变化曾经发生过,则需要考虑现有的架构是否可以轻松地实现这一变化。架构师设计一套系统不仅要符合现有的需求,还要适应可能发生的变化,这才是一个优良的架构。

开闭原则是一个终极目标,任何人包括大师级人物都无法百分之百做到,但朝这个方向努力,可以非常显著地改善一个系统的架构,真正做到“拥抱变化”。

王大虎

我是皇帝我独苗

自从秦始皇确立了皇帝这个位置以后,同一时期基本上就只有一个人孤零零地坐在这个位置。这种情况下臣民们也好处理,大家叩拜、谈论的时候只要提及皇帝,每个人都知道指的是谁,而不用在皇帝前面加上特定的称呼,如张皇帝、李皇帝。这一个过程反应到设计领域就是,要求一个类只能生成一个对象(皇帝),所有对象对它的依赖都是相同的,因为只有一个对象,大家对它的脾气和习性都非常了解,建立健壮稳固的关系,我们把皇帝这种特殊职业通过程序来实现。

皇帝每天要上朝接待臣子、处理政务,臣子每天要叩拜皇帝,皇帝只能有一个,也就是一个类只能产生一个对象,该怎么实现呢?对象产生是通过new关键字完成的(当然也有其他方式,比如对象拷贝、反射等),这个怎么控制呀,但是大家别忘记了构造函数,使用new关键字创建对象时,都会根据输入的参数调用相应的构造函数,如果我们把构造函数设置为private私有访问权限不就可以禁止外部创建对象了吗?臣子叩拜唯一皇帝的过程如类图7-1所示。

 

图7-1 臣子叩拜皇帝类图

只有两个类,Emperor代表皇帝类,Minister代表臣子类,关联到皇帝类非常简单。Emperor如代码清单7-1所示。

代码清单7-1 皇帝类

 

* * *

 

public class Emperor { private static final Emperor emperor =new Emperor(); //初始化一个皇帝 private Emperor(){ //世俗和道德约束你,目的就是不希望产生第二个皇帝 } public static Emperor getInstance(){ return emperor; } //皇帝发话了 public static void say(){ System.out.println(“我就是皇帝某某某….”); } }

 

* * *

 

通过定义一个私有访问权限的构造函数,避免被其他类new出来一个对象,而Emperor自己则可以new一个对象出来,其他类对该类的访问都可以通过getInstance获得同一个对象。

皇帝有了,臣子要出场,其类如代码清单7-2所示。

代码清单7-2 臣子类

 

* * *

 

public class Minister { public static void main(String[] args) { for(int day=0;day<3;day++){ Emperor emperor=Emperor.getInstance(); emperor.say(); } //三天见的皇帝都是同一个人,荣幸吧! } }

 

* * *

 

臣子参拜皇帝的运行结果如下所示。

 

* * *

 

我就是皇帝某某某…. 我就是皇帝某某某…. 我就是皇帝某某某….

 

* * *

 

臣子天天要上朝参见皇帝,今天参拜的皇帝应该和昨天、前天的一样(过渡期的不考虑,别找茬哦),大臣磕完头,抬头一看,嗨,还是昨天那个皇帝,老熟人了,容易讲话,这就是单例模式。

 

王大虎

7.2 单例模式的定义

 

单例模式(Singleton Pattern)是一个比较简单的模式,其定义如下:

Ensure a class has only one instance,and provide a global point of access to it.(确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例。)

单例模式的通用类图如图7-2所示。

 

图7-2 单例模式通用类图

Singleton类称为单例类,通过使用private的构造函数确保了在一个应用中只产生一个实例,并且是自行实例化的(在Singleton中自己使用new Singleton())。单例模式的通用源代码如代码清单7-3所示。

代码清单7-3 单例模式通用代码

 

* * *

 

public class Singleton { private static final Singleton singleton = new Singleton(); //限制产生多个对象 private Singleton(){ } //通过该方法获得实例对象 public static Singleton getSingleton(){ return singleton; } //类中其他方法,尽量是static public static void doSomething(){ } }

 

* * *

 

 

7.3 单例模式的应用

 

7.3.1 单例模式的优点

 

·由于单例模式在内存中只有一个实例,减少了内存开支,特别是一个对象需要频繁地创建、销毁时,而且创建或销毁时性能又无法优化,单例模式的优势就非常明显。

·由于单例模式只生成一个实例,所以减少了系统的性能开销,当一个对象的产生需要比较多的资源时,如读取配置、产生其他依赖对象时,则可以通过在应用启动时直接产生一个单例对象,然后用永久驻留内存的方式来解决(在Java EE中采用单例模式时需要注意JVMX回收机制)。

·单例模式可以避免对资源的多重占用,例如一个写文件动作,由于只有一个实例存在内存中,避免对同一个资源文件的同时写操作。

·单例模式可以在系统设置全局的访问点,优化和共享资源访问,例如可以设计一个单例类,负责所有数据表的映射处理。

 

王大虎
王大虎

王大虎

7.3.2 单例模式的缺点

 

·单例模式一般没有接口,扩展很困难,若要扩展,除了修改代码基本上没有第二种途径可以实现。单例模式为什么不能增加接口呢?因为接口对单例模式是没有任何意义的,它要求“自行实例化”,并且提供单一实例、接口或抽象类是不可能被实例化的。当然,在特殊情况下,单例模式可以实现接口、被继承等,需要在系统开发中根据环境判断。

·单例模式对测试是不利的。在并行开发环境中,如果单例模式没有完成,是不能进行测试的,没有接口也不能使用mock的方式虚拟一个对象。

·单例模式与单一职责原则有冲突。一个类应该只实现一个逻辑,而不关心它是否是单例的,是不是要单例取决于环境,单例模式把“要单例”和业务逻辑融合在一个类中。

 

 

7.3.3 单例模式的使用场景

 

在一个系统中,要求一个类有且仅有一个对象,如果出现多个对象就会出现“不良反应”,可以采用单例模式,具体的场景如下:

·要求生成唯一序列号的环境;

·在整个项目中需要一个共享访问点或共享数据,例如一个Web页面上的计数器,可以不用把每次刷新都记录到数据库中,使用单例模式保持计数器的值,并确保是线程安全的;

·创建一个对象需要消耗的资源过多,如要访问IO和数据库等资源;

·需要定义大量的静态常量和静态方法(如工具类)的环境,可以采用单例模式(当然,也可以直接声明为static的方式)。

发表评论

电子邮件地址不会被公开。 必填项已用*标注