为什么要先说设计模式?因为设计模式在这些概念中是最基本的,而且也比较简单。那么什么是设计模式呢?说的直白点,设计模式就是告诉你针对特定问题如何组织类、对象和接口之间的关系,是前人总结的经验。比如我要在代码中实现一个全局唯一的配置类,那么就使用Singleton模式。设计模式在实际编码工作和设计框架时会被使用到,而更高层的架构和平台则不会太关注它。
做WEB开发接触到最多的框架可数ORM框架,ORM框架只是所有数据关系映射框架的统称,具体的如NHibernate、ActiveRecord等,框架是为了解决特定问题而存在的,其它诸如模板框架、缓存框架,框架不能直接使用,需要二次开发。
从大的层面来说,比如针对公司业务的B2C网站系统架构,里面可能会用到多种解决各方面问题的框架,关注的是技术整合、扩展、可维护性。换个角度,在框架中也会涉及到架构问题,比如开发NHibernate框架,也需要考虑如何进行设计。
平台的概念类似框架,但又结合的架构的考虑,它是更高层面上的“框架”,准确说是一种应用。它是针对企业用户,为解决企业业务需要而形成的产品。
设计模式(Design pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问,设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石,如同大厦的一块块砖石一样。项目中合理的运用设计模式可以完美的解决很多问题,每种模式在现在中都有相应的原理来与之对应,每一个模式描述了一个在我们周围不断重复发生的问题,以及该问题的核心解决方案,这也是它能被广泛应用的原因。
总体来说设计模式分为三大类:
创建型模式,共五种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
结构型模式,共七种:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
行为型模式,共十一种:策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
其实还有两类:并发型模式和线程池模式。用一个图片来整体描述一下:
开闭原则就是说对扩展开放,对修改关闭。在程序需要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果。所以一句话概括就是:为了使程序的扩展性好,易于维护和升级。想要达到这样的效果,我们需要使用接口和抽象类,后面的具体设计中我们会提到这点。
里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说,任何基类可以出现的地方,子类一定可以出现。 LSP是继承复用的基石,只有当衍生类可以替换掉基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现,所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科
这个是开闭原则的基础,具体内容:真对接口编程,依赖于抽象而不依赖于具体。
这个原则的意思是:使用多个隔离的接口,比使用单个接口要好。还是一个降低类之间的耦合度的意思,从这儿我们看出,其实设计模式就是一个软件的设计思想,从大型软件架构出发,为了升级和维护方便。所以上文中多次出现:降低依赖,降低耦合。
为什么叫最少知道原则,就是说:一个实体应当尽量少的与其他实体之间发生相互作用,使得系统功能模块相对独立。
原则是尽量使用合成/聚合的方式,而不是使用继承。
java框架:三大框架详解,其发展过程及掌握的Java技术慨括
简单点说:框架就是能完成一定功能的半成品软件,现在的结构是,Struts负责显示层,Hibernate负责持久层,Spring负责中间的业务层,这个结构是目前国内最流行的Java Web应用程序架构了。
就其本质而言,框架是一个软件,而且是一个半成品的软件。所谓半成品,就是还不能完全实现用户需要的功能,框架只是实现用户需要的功能的一部分,还需要进一步加工,才能成为一个满足用户需要的、完整的软件。因此框架级的软件,它的主要客户是开发人员,而不是最终用户。
有些朋友会想,既然框架只是个半成品,那何必要去学习和使用框架呢?学习成本也不算小,那就是因为框架能完成一定的功能,也就是这“框架已经完成的一定的功能”在吸引着开发人员,让大家投入去学习和使用框架。
能完成一定功能,加快应用开发进度
由于框架完成了一定的功能,而且通常是一些基础的、有难度的、通用的功能,这就避免我们在应用开发的时候完全从头开始,而是在框架已有的功能之上继续开发,也就是说会复用框架的功能,从而加快应用的开发进度。
给我们一个精良的程序架构
框架定义了应用的整体结构,包括类和对象的分割,各部分的主要责任,类和对象怎么协作,以及控制流程等等。现在Java界大多数流行的框架,大都出自大师手笔,设计都很精良。基于这样的框架来开发,一般会遵循框架已经规划好的结构来进行开发,从而让我们开发的应用程序的结构也相对变得精良了。
基于框架来开发,事情还是那些事情,只是看谁做的问题
对于应用程序和框架的关系,可以用一个图来简单描述一下,如图1所示:
如果没有框架,那么客户要求的所有功能都由开发人员自己来开发,没问题,同样可以实现用户要求的功能,只是开发人员的工作多点。
如果有了框架,框架本身完成了一定的功能,那么框架已有的功能,开发人员就可以不做了,开发人员只需要完成框架没有的功能,最后同样是完成客户要求的所有功能,但是开发人员的工作就减少了。
也就是说,基于框架来开发,软件要完成的功能并没有变化,还是客户要求的所有功能,也就是“事情还是那些事情”的意思。但是有了框架过后,框架完成了一部分功能,然后开发人员再完成一部分功能,最后由框架和开发人员合起来完成了整个软件的功能,也就是看这些功能“由谁做”的问题。
软件体系结构通常被称为架构,指可以预制和可重构的软件框架结构。架构尚处在发展期,对于其定义,学术界尚未形成一个统一的意见,而不同角度的视点也会造成软件体系结构的不同理解,以下是一些主流的标准观点。
ANSI/IEEE 610.12-1990软件工程标准词汇对于体系结构定义是:“体系架构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织结构以及知道上述内容设计与演化的原理(principle)”。
Mary Shaw和David Garlan认为软件体系结构是软件设计过程中,超越计算中的算法设计和数据结构设计的一个层次。体系结构问题包括各个方面的组织和全局控制结构,通信协议、同步,数据存储,给设计元素分配特定功能,设计元素的组织,规模和性能,在各设计方案之间进行选择。Garlan & Shaw模型[1]的基本思想是:软件体系结构={构件(component),连接件(connector),约束(constrain)}.其中构件可以是一组代码,如程序的模块;也可以是一个独立的程序,如数据库服务器。连接件可以是过程调用、管道、远程过程调用(RPC)等,用于表示构件之间的相互作用。约束一般为对象连接时的规则,或指明构件连接的形式和条件,例如,上层构件可要求下层构件的服务,反之不行;两对象不得递规地发送消息;代码复制迁移的一致性约束;什么条件下此种连接无效等。
关于架构的定义还有很多其他观点,比如Bass定义、Booch & Rumbaugh &Jacobson定义、Perry & Wolf模型[7]、Boehm模型等等,虽然各种定义关键架构的角度不同,研究对象也略有侧重,但其核心的内容都是软件系统的结构,其中以Garlan & Shaw模型为代表,强调了体系结构的基本要素是构件、连接件及其约束(或者连接语义),这些定义大部分是从构造的角度来甚至软件体系结构,而IEEE的定义不仅强调了系统的基本组成,同时强调了体系结构的环境即和外界的交互。
java是一个可以在不同操作系统(例如windows,unix等)上运行的编程语言,java平台是指运行在各种终端(如pc、服务器、移动设备、嵌入式设备)的系统软件。PC机上的java程序是用javaSE开发出来的,服务器端的java程序是用javaEE开发出来的,移动设备的java程序是用javaME开发出来的。
J2ME(Java 2 Micro Edition)是Java 2的一个组成部分,它与J2SE、J2EE并称。根据Sun的定义:J2ME是一种高度优化的Java运行环境,主要针对消费类电子设备的,例如蜂窝电话和可视电话、数字机顶盒、汽车导航系统等等。J2ME技术在1999年的JavaOne Developer Conference大会上正式推出,它将Java语言的与平台无关的特性移植到小型电子设备上,允许移动无线设备之间共享应用程序。
J2SE商业版本,标准版本 (Java2 Standard Edition) 定位在客户端,主要用于桌面应用软件的编程。J2SE 包含那些构成Java语言核心的类。
J2EE Java2平台企业版(Java 2 Platform,Enterprise Edition),J2EE是一套全然不同于传统应用开发的技术架构,包含许多组件,主要可简化且规范应用系统的开发与部署,进而提高可移植性、安全与再用价值。J2EE核心是一组技术规范与指南,其中所包含的各类组件、服务架构及技术层次,均有共通的标准及规格,让各种依循J2EE架构的不同平台之间,存在良好的兼容性,解决过去企业后端使用的信息产品彼此之间无法兼容,导致企业内部或外部难以互通的窘境。
框架不是构架(即软件体系机构)。体系结构确定了系统整体结构、层次划分,不同部分之间的协作等设计考虑。框架比架构更具体。更偏重于技术涉嫌。确定框架后,软件体系结构也随之确定,而对于同一软件体系结构(比如Web开发中的MVC),可以通过多种框架来实现。
设计模式和框架在软件设计中是两个不同的研究领域。设计模式研究的是一个设计问题的解决方法,一个模式可应用于不同的框架和被不同的语言所实现;而框架则是一个应用的体系结构,是一种或多种设计模式和代码的混合体虽然它们有所不同,但却共同致力于使人们的设计可以被重用,在思想上存在着统一性的特点,因而设计模式的思想可以在框架设计中进行应用。
框架和设计模式存在着显著的区别,主要表现在二者提供的内容和致力应用的领域。
1)从应用领域上分,框架给出的是整个应用的体系结构;而设计模式则给出了单一设计问题的解决方案,并且这个方案可在不同的应用程序或者框架中进行应用。
2)从内容上分,设计模式仅是一个单纯的设计,这个设计可被不同语言以不用方式来实现;而框架则是设计和代码的一个混合体,编程者可以用各种方式对框架进行扩展,进而形成完整的不同的应用。
3)以第二条为基础,可以得出设计模式比框架更容易移植:框架一旦设计成形,虽然还没有构成完整的一个应用,但是以其为基础进行应用的开发显然要受制于框架的实现环境;而设计模式是与语言无关的,所以可以在更广泛的异构环境中进行应用。
总之,框架是软件,而设计模式是软件的知识体,提升框架的设计水平。