反模式设计

① struts+spring+hibernate分别用到了什么设计模式

Spring 的AOP 体现了动态代理模式
IOC 是工厂模式
OpenSessionInViewFilter是一种反模式
struts的里面用到了工厂模式
struts2的拦截器那里有一个内Proxy也是代理模式
Hibernate没怎么分析容过 但是对每个数据库都适用应该有策略模式

② 软件架构师需要掌握哪些知识

架构师首先必须具有丰富的开发经验，是个技术主管。因为他必须清楚什么是可以实现的，实现的方式有哪些，相应的难度怎么样，实现出来的系统面对需求变化的适应性等一系列指标。另外，需要对面向过程、面向对象、面向服务等设计理念有深刻的理解，可以快速的察觉出实现中的问题并提出相应的改进（重构）方案（也就是通常说的反模式）。这些都需要长期的开发实践才能真正的体会到，单从书本上很难领会到，就算当时理解了也不一定能融会到实践中去。 在技术能力上，软件架构师最重要也是最需要掌握的知识是构件通信机制方面的知识，包括进程内通信（对象访问、函数调用、数据交换、线程同步等）以及进程外（包括跨计算机）的通信（如RMI、DCOM、Web Service）。在WEB应用大行其道的今天，开发者往往对服务器间的通信关注的比较多，而对进程内的通信较少关注。进程外跨机器通信是构建分布式应用的基石，它是架构设计中的鸟瞰视图；而进程内的通信是模块实现的骨架，它是基石的基石。如果具体到一个基于.Net企业级架构设计，首先需要的是语言级别的认识，包括.NET的CLR、继承特性、委托和事件处理等。然后是常用解决方案的认识，包括ASP.NET Web Service、.NET Remoting、企业服务组件等。总之，丰富的开发实践经验有助于避免架构师纸上谈兵式的高来高去，给代码编写人员带来实实在在的可行性。 其次，具有足够的行业业务知识和商业头脑也是很重要的。行业业务知识的足够把握可以给架构师更多的拥抱变化的能力，可以在系统设计的时候留出一些扩展的余地来适应可能来临的需求变化。有经验的设计人员可能都碰到过这样的事，一厢情愿的保留接口在需求变化中的命中率非常低。也就是说，在系统设计之初为扩展性留下来的系统接口没能在需求变化的洪流中发挥真正的作用，因为需求的变化并没有按照预想的方向进行，到最后还是不得不为变化的业务重新设计系统。这就是因为对业务知识的理解和对市场或者商业的判断没有达到一个实用的、可以为架构扩展性服务的水平。 再次，架构设计师对人的关注必须提升到架构设计之初来纳入考虑的范围，包括沟通以及对人员素质的判断。软件过程是团队协作共同构建系统的过程，沟通能力是将整个过程中多条开发线粘合在一起的胶水。大家都应该碰到过事后说“原来是这样啊，我不知道啊”或者某个开发人员突然高声呼喊“为什么这里的数据没有了”之类的。沟通的目的就是尽量避免多条开发线的混乱，让系统构建过程可以有条理的高效进行。另外，对人的关注还表现在对团队成员的素质判断上，比如哪些开发人员对哪些技术更熟悉，或者哪些开发人员容易拖进度等。只有合理的使用人力资源，让合适的人做合适的事情才能让整个软件过程更加高效。 架构师应时刻注意新软件设计和开发方面的发展情况，并不断探索更有效的新方法、开发语言、设计模式和开发平台不断很快地升级，软件架构师需要吸收这些新技术新知识，并将它们用于软件系统开发工作中。但对新技术的探索应该在一个理性的范围内进行，不能盲目的跟风。解决方案提供商永远都希望你能使用它提供的最新技术，而且它们在推广自己的解决方案的时候往往是以自己的产品为中心，容易给人错觉。比如数据库，往往让人觉得它什么都能做，只要有了它其它什么都不重要了。但事实上并不是如此，对于小型应用可以将许多业务逻辑用script的方式放入数据库中，但很少看到大型应用采用这样的做法。对于新东西需要以一种比较的观点来判断，包括横向的比较和纵向的比较，最后得出一些性能、可移植性以及可升级等指标。另外，新入行的开发人员往往关心新技术动向而忽略了技术的历史，而从DOS时代一路杀过来的开发者就对现在的技术体系有较全面的把握。

③ WEB UI设计师都看什么书

一、《众妙之门——网站UI设计之道2》

来自全球的知务设计师无私地分享了他们多年积累的宝贵经验。书中涵盖了网站UI设计相关的不同的领域，覆盖面非常广，具有很强的操作性和专业性。全书逻辑严密、言简意赅，设计人员可以快速地找到自己想要的东西。

二、《认知与设计:理解UI设计准则(UI领域大师力作)》

张一宁 自称“一个认为写代码就是做与人打交道的设计的工程师”。拥有二十多年编程经验，从事过系统集成、金融行业应用的中间件和服务产品的研发，以及电信与互联网服务的开发和管理。

三、《移动应用UI设计模式(简易的UI模式参考书)》

《移动应用ui设计模式》是一本移动应用ui 设计模式参考书，分10 大类介绍了70 个移动应用设计模式（包括反模式），用400 多个屏幕截图和图解帮助读者理解和利用ui 设计模式，以解决常见的设计难题，同时提供了“即学即用”式的技巧和经验。

四、《用户体验要素:以用户为中心的产品设计(原书第2版)(UI设计丛书)(全彩印刷)》

《用户体验要素:以用户为中心的产品设计(原书第2版)》用清晰的说明和生动的图形分析了以用户为中心的设计方法（ucd）来进行网站设计的复杂内涵，并关注于思路而不是工具或技术，从而使你的网站具备高质量体验的流程。

五、《UI进化论：移动设备人机交互界面设计（国际著名界面设计师沥血之作！全彩印刷，正文铜版纸）》

④ 大话设计模式中哪些模式比较重要

应该来说，大话设计模式或者其他类似设计模式中的模式没有哪个是更重要的。只专能说各自的适属用场合或解决的问题有差别而已。

而且，学习这些设计模式的书籍，最重要的不是掌握哪几个设计模式，而是理解设计模式的本质，从而在今后的软件开发中可以灵活的运用相关模式，创造更加合适的模式，甚至如果有必要，采用反模式。

⑤ 介绍几本关于UI设计的书籍

设计个QQ表情，可以用ui来实现；设计个微信小程序，也可以用ui做；做个海报，也是缺不了；还有我们钟爱的“农药”，更是仰仗UI……可谓是，ui的用处是很多的，你是不是也想找UI设计入门的图书学习下？
UI设计近几年发展时态一片良好，ui设计师也顺势成了热门行业，但是行业专业技能人才还是很缺失的，所以我们需要必要的充电。在这里小编整理了一些UI设计入门书籍，希望能帮到大家。
Ui设计入门数据推荐：
《Photoshop CS6平面设计自学视频教程》
本书书共分为24章，在内容安排上基本涵盖了平面设计中所使用到的全部工具与命令。其中前16章主要从平面设计的角度出发，循序渐进地详细讲解了Photoshop的相关知识，主要内容包括Photoshop的基本操作、图像编辑、选区的编辑与应用、文字的应用、矢量工具与形状、图层的相关知识、蒙版、通道、滤镜、Web图形处理与自动化操作等核心功能与应用技巧。《Photoshop CS6平面设计自学视频教程》后8章则从Photoshop在平面设计中的实际应用出发，着重针对标志设计、海报招贴设计、版式与书籍装帧设计、包装设计和创意合成等8个方面进行案例式的针对性和实用性实战练习，不仅使读者巩固了前面学到的Photoshop中的技术技巧，更是为读者在以后实际学习工作进行提前“练兵”。
《UI设计手绘表现从入门到精通》
以UI设计为核心，系统全面地讲解了UI设计手绘各个方面的知识。全书分为9章，第1章介绍了UI设计概论；第2章介绍了UI设计手绘基础；第3章介绍了UI设计材质表现；第4章介绍了UI中基本元素的表现；第5章介绍了UI图标设计；第6章介绍了网站UI设计；第7章介绍了游戏界面设计；第8章介绍了数码产品主题界面设计；第9章为作品赏析，搜集了一些好的UI设计作品，以供读者参考学习。
《Photoshop移动UI设计从入门到精通》
内容包括：移动UI的设计常识，移动UI设计的布局原则，移动UI视觉交互设计法则，移动UI的构成元素，Photoshop移动UI快速上手，UI的色彩与风格设计，移动UI文字的编排设计，移动UI图像的抠取与合成，移动UI图像特效质感设计，图标、图形、按钮设计，常见苹果系统UI设计，常见安卓系统UI设计，常见微软系统UI设计，社交与免费WiFi登录UI设计，影音与游戏UI设计。全书使用自带素材，通过对素材的不同处理，制作出精美的界面效果。制作界面过程已被录制为视频，刻录为光盘，在手机与网络中进行分享，读者学后可以融会贯通、举一反三，从而完成自己的作品。
新入门的朋友可以线上商城查看，当然，还需要大家了解一些关于软件使用的书籍，上网查一下很多官网商店都有推荐。PS，AI等。
然后关于自学的问题，自学软件的使用，基本上是没有问题的，主要是产品问题。自学的学员大多存在的一个问题就是脱轨，闭门造车大家都听过吧，大概就是这种感觉，而且自己心里也没底，不知道自己学到的有没有实际作用。

⑥ 什么是网站架构师

网站架构师是网站系统、功能、模块、流程的设计师，架构师，好比版是高楼大厦的设计人权员，通常一座大厦在建之前，都先由设计师将蓝图描绘出来，包括其形状、结构、尺寸、材料等等，然后建筑工程师带领工人们按照蓝图将大厦一层一层地建起来。

架构师首先必须具有丰富的开发经验，是个技术主管。因为他必须清楚什么是可以实现的，实现的方式有哪些，相应的难度怎么样，实现出来的系统面对需求变化的适应性等一系列指标。另外，需要对面向过程、面向对象、面向服务等设计理念有深刻的理解，可以快速的察觉出实现中的问题并提出相应的改进（重构）方案（也就是通常说的反模式）。
在技术能力上，软件架构师最重要也是最需要掌握的知识是构件通信机制方面的知识。

⑦ 如何系统地进行架构和应用设计

软件架构设计的目的 对于外包业务类型的项目，软件架构设计的目的与产品类型的项目有所不同，在这里主要讨论外包类型项目的软件架构设计目的。 1、为大规模开发提供基础和规范，并提供可重用的资产，软件系统的大规模开发，必须要有一定的基础和遵循一定的规范，这既是软件工程本身的要求，也是客户的要求。架构设计的过程中可以将一些公共部分抽象提取出来，形成公共类和工具类，以达到重用的目的。 2、一定程度上缩短项目的周期，利用软件架构提供的框架或重用组件，缩短项目开发的周期。 3、降低开发和维护的成本，大量的重用和抽象，可以提取出一些开发人员不用关心的公共部分，这样便可以使开发人员仅仅关注于业务逻辑的实现，从而减少了很多工作量，提高了开发效率。 4、提高产品的质量，好的软件架构设计是产品质量的保证，特别是对于客户常常提出的非功能性需求的满足。 软件架构设计的原则 软件架构设计必须遵循以下原则： 1、满足功能性需求和非功能需求。这是一个软件系统最基本的要求，也是架构设计时应该遵循的最基本的原则。 2、实用性原则，就像每一个软件系统交付给用户使用时必须实用，能解决用户的问题一样，架构设计也必须实用，否则就会“高来高去”或“过度设计”。 3、满足复用的要求，最大程度的提高开发人员的工作效率。 软件架构设计的几种视图 我们常常在讨论架构设计该做些什么的时候，或是在架构设计评审的会议上，会提出各种各样的问题，例如开发人员该如何记录Log，事务如何控制？怎样才能提高我们的开发人员的工作效率，即在单位时间内更有品质的完成更多的功能？怎样满足客户的非功能性需求？怎样让生产环境的平台管理人员更好的维护系统？ 上面这些问题，实际上是软件系统的不同的干系人站在不同的角度上提出的问题，要回答上面这些问题，我们就得从不同的视角来看待软件架构设计这项工作。 1、逻辑架构视角，从系统用户的角度考虑问题，设计出来的软件架构能够满足业务逻辑的需求，能够处理现在越来越复杂的业务逻辑需求。 2、开发架构视角，从系统开发人员的角度来考虑问题，设计的架构要易于理解，易于开发，易于单元测试，最好做到让开发人员可以用最少的代码行数完成功能的开发。 3、运行架构视角，从系统运行时的质量需求考虑问题，特别关注于系统的非功能需求，客户常常都会要求我们系统的功能画面的最长响应时间不超过4秒，能满足2000个用户同时在线使用，基于角色的系统资源的安全控制等。 4、物理架构视角，关注系统安装和部署在什么样的环境上，例如现在最流行的企业应用服务解决方案IBM Http Server ＋ WebSphere Application Server ＋ DB2，WebLogic + Oracle等。 5、数据架构视角，如今我们开发的各类系统，如MIS，ERP，SAP，基本上都是对各类数据的操作，把一堆不太好懂的数据展现成用户容易看懂的数据，自动处理各类数据的运算等，所以数据的持久化是十分重要的一件事情。1、分析需求和理解业务模型（或领域建模），并选定关键Use case。 软件的需求，可以分为从用户视角和开发人员视角来看，从用户的角度看，又可以分为功能性和非功能性需求，我们必须从不同的视角和级别去全面的认识需求并分析需求，理解业务模型。实践表明，常常被我们忽视的非功能性需求常常会导致整个项目失败。 理解业务需求最好的方式莫过于进行领域建模，领域建模与需求分析往往是交替穿叉进行的，领域建模主要有以下三个方面的作用： ◆探索复杂问题，弄清领域知识。Martin Fowler曾经说过，他采用面向对象方法最大的好处就是它有助于解决更为复杂的问题。领域建模本身作为辅助思维的工具，帮助我们将注意力始终保持在最为重要的业务概念及其关系上，使我们能够不断深入地，系统的对需求进行分析和认识。领域建模往往是一个从模糊到清晰，从零散到系统的过程。 ◆决定功能范围，影响可扩展性。任何模型都是对现实世界某种程序的抽象，这种抽象就会忽略某一些东西，例如忽略对象的属性和对象间的关系，而这些忽略往往都是带有一定的目的性的，这种忽略就决定了功能的范围。模型揭示了各种功能背后的结构，如果说定义功能相当于“拍照片”的话，那么领域建模就相当于“做透视”，更加关注问题领域的内在结构，相当于对问题领域进行了一定的抽象，良好的领域模型不仅能很好的支持现有的功能，而且还可以在一定程度上支持未来可能出现的新需求，体现良好的可扩展性。 ◆提供交流基础，促进有效沟通。领域建模通常会使用UML图作为呈现的方式，这样为我们的沟通提供了方便。当然，有时候文字在描述某些特定领域的问题时可能更适合，可以灵活运用。 在我们公司的实际软件开发流程中，往往领域建模缺少这一环节，这可能是在以后的工作中需要进一步提高之处。 虽然我们总是期望架构设计师能全面掌握需求，但由于时间和精力的限制，摆在我们面前的现实就是架构设计师没有时间对所有需求进行深入分析，所以我们的策略就是“把好钢用在刀刃上”，即把大部分时间和精力花在对决定架构最重要的关键需求上。在选择关键需求时要注意：高优先级的需求往往是从用户的角度来看的，可能并不是真正的关键需求。在《RUP实践者指南》一书中向我们讲述了如何确定关键功能需求？A.作为应用程序的核心或实现了系统的主要接口的功能，B.必须被实现的功能，即如果这些功能不被实现，则开发出来的软件就失去了价值，C.覆盖了系统架构的一些方面，但没有被其他重要的Use case覆盖到的功能。 2、分别从各个视角来考虑软件架构的方方面面。 软件的架构设计必须考虑到各方面，根据前期工作确立的领域模型，关键需求，系统约束等进行设计，必须从系统用户，开发人员，系统管理员，部署管理员，数据管理员等人员的角度去分析并解决问题。比如说，如果我们的运行架构采用Cluster方式时，就必须小心Cache和Session等的使用；如果我们的业务逻辑要求我们要操作多个数据库时，就要考虑采用支持二阶段事务提交的方式。 只有将这些方方面面的问题都考虑到了，这样的架构设计才是完整的。至于每一个视图中，我们应该设计到什么细节这一问题，实际上与整个项目的过程定义有关。例如，如果我们有专门安排数据库概要设计的活动，那我们在架构设计的过程中就可以只需要关注更高层次的数据库特性及数据库之间的关系，而每一张表的数据字典可以在后续的相关活动中进行设计，但如果没有这样的活动，那我们就要细化到每一张表的每一个栏位，以及表之间的关系。 3、解决技术面的重点问题和难题 在软件架构设计的过程中，我们往往会需要攻克一些技术面的重点问题和难题，这完全是一项极其需要扎实的理论知识和丰富的实践经验支撑的工作。例如，我们如何提高整个系统的性能？如何能很好的导出极其复杂的“中国式报表”（一般比西方国家产出的报表要复杂很多，而且很多开源的BI类的框架并不能完全解决问题）？ 当遇到确实是很困难的问题，可以去网络一下或Google一下，也可以去请教公司的资深技术人员或专家，或者召开小范围的技术专题讨论会议，采用脑力激荡的方法试着找找答案，这样才能提高工作的效率。 4、召开架构设计评审会议进行同行评审。 架构设计评审是极其重要的一环，我曾将其形容为“七种武器”中的离别钩，就是因为在会议上，同行们可能会提很多问题或意见，而且很多意见很尖锐，所以一定要虚心接受，并做好记录，正所谓“良药苦口利于病，忠言逆耳利于行”。 在评审会议之前，我们要完成很多准备工作，最好是能准备一份简明扼要的电子简报，把最重要的问题列出来，这样在进行评审会议时，就不会漫无目的，在会议前就将这些资料发给与会人员，请他们抽空先了解一下，在会议进行时，要学会控制会议的进度，提高会议的效率。 5、针对关键Use case在设计的架构上实现功能来验证架构。 对于架构设计的验证也是一项十分重要的工作，其验证技术有很多种，在我们公司通常会采用Sample的形式，即XP中所说的迭代0，RUP中所说的切片。这样做的好处是既可以从实际的产品角度出发来有效的验证架构是否满足要求，又可以比抛弃型原型验证技术节省成本。 这个Sample绝不是我们在解决架构设计中的问题时拿来做实验的一些代码的拼凑，而是完整的实现某一关键Use case的符合架构设计和一系列规范的可交付的代码及相关文档。同时，这个Sample可以作为你在给大家讲解或培训架构时的教材，也可以作为开发人员使用此架构进行开发的蓝本，甚至是只需要复制粘贴，加上简单的修改即可。 6、交付给客户Review。 这一环节，在很多公司可能并不存在，因为他们的软件架构并不一定需要客户Review，但像我们这种做服务的公司，最重要的就是客尊，落实到软件架构设计这一活动，就是让客户理解并接受你的架构设计方案，同时，客户也会起到帮你验证架构的作用。通常，我们的架构得到客户的认可后，便可进入大规模的开发。 在交付给客户Review时，通常可能会以会议的形式进行Review，所以我们可以参照评审会议时好的做法来召开会议，在这里就不再冗述。软件架构设计的常见误区及解决办法 1、架构设计的常常会“高来高去”。所谓高来高去，实际上就是我们的架构设计仅停留在模型阶段，但也绝不是产生第一支样例程式。 2、架构设计时常常会在某些方面过度设计（Over engineering）。为了一些根本不会发生的变化而进行一系列复杂的设计，这样的设计就叫过度设计，往往会带来资源的浪费并且会增加开发的工作量或难度。虽然我们必须考虑到系统的扩展性，可维护性等，但切忌过度设计。有时候或许你并不能判断出哪些设计是过度设计，此时你可以请教你的PM，让他站在整个项目的高度来帮你决策一下。 3、架构（Architecture）不是框架(Framework)，也不是简单的将几种框架或技术的组合，框架本身也是有架构的。框架一般是针对于某一方面或领域的重用性和可扩展性非常好的半成品，我们可以用一句较为经典的话来总结：框架是软件，架构不是软件，框架是一种特殊的软件。我们在工作中通过将许多方面的可重用的工具类，公共类，基础类等抽象出来，即可形成一些可重用的框架。 4、架构设计绝不是新技术展示平台，合适的技术才是对于项目有利的技术，必须考虑到开发人员的能力和维护人员的能力。作为一名架构设计师应该更多的考虑如何平衡业务需求，织织运作（主要指团队中的协作）和技术三者的关系，而不仅仅是去关注那些技术细节。 5、架构设计的成功与否决定着系统品质的好坏，因为架构设计不好而导致交付的系统Bug过多，无法满足客户非功能性需求等问题，从而导致项目取消的案例时有发生。架构设计不是架构设计师一个人的事情，也不是几天就能完成的一项工作，必须是架构设计师付出大量辛勤劳动后的成果，其成败往往与组织、主管、项目经理的支持有着密切的关系。 关于架构设计的一点通用技巧 1、分层（Layer）规则。这里的层是指逻辑上的层次（Layer），并非指物理上的层次（Tier）。目前的绝大多数的企业级应用系统中都分为三层，即表现层，领域层和数据层。在对各层次进行划分时，主要可以从以下几个方面来考虑：A、每一层是一个相对独立的部分，可以作为一个整体，无需对其它层了解；B、将层次间的依赖性降到最低，即降低耦合；C、可以从某种程度上替换掉某一层，而对其它层不会产生过多的影响；D，层次并不能封闭所有的东西，假如用户界面上增加了一个栏位，那么领域层就要增加一个数据域，数据层就要增加一个相应的字段。同时，过多的分层可能会对性能造成一定的影响。 2、包（package）之间不要产生循环依赖。通常包的划分会先按不同的逻辑层来划分，在层的包下面再按功能来划分。避免包间的循环依赖是一个比较通用的规则，这样的规则一定有其存在的价值和道理，之所以这样主要是出于以下原因：A、循环依赖会使分层失去意义；B、循环依赖会带来许多潜在的风险，如可能会产生嵌套事务（nested transaction，JavaEE标准中并不支持这种事务）的现象，我就曾遇到过这样的问题，在一个项目中，事务放在业务逻辑层统一控制，但由于开发人员忽视了架构中这样的原则，在持久层调用了展现层的公用类，形成了回圈的现象，导致了嵌套事务的发生。 3、设计模式的应用。在很多人的观念里，提供设计模式就等同于GOF的设计模式，其实设计模式是个广泛的概念，比如需求模式、领域模式、反模式等都属于设计模式。模式其实是一门工具，是人们对于过去解决某一类问题的经验总结，所以我们可以在设计活动中应用各种设计模式，但是在应用这些模式之前一定要先分析清楚问题，否则就可能出现“牛头不对马嘴”的现象。 成功的项目总有相似之处，失败的项目却各有各的失败之处。好的软件架构设计必定是成功项目的相似之处，我们有什么理由不把软件架构设计做好了？

⑧ 反模式的设计反模式

反抽象：需要的功能并不暴露给用户，导致用户要在较高层次重新实现一些功能。
四不像：往往一个设计模型可以暴露不同的接口给用户，不同的接口表现了模型的不同方面。然而把不同方面的功能混在一起是常见的不良设计。
乱麻球：系统没有可辨认的结构，就像一团乱麻一样。
万应灵：一个对象了解的东西太多，或者要做太多的事情，就好像无所不能一样。
屠龙术：没有必要的复杂设计。
竞争危害(Race Hazard): 缺乏预见事件以不同顺序发生的后果。
面向对象设计上的反模式
万能类︰在一个类的设计中，聚集了太多的函数。
吵闹鬼︰建立某对象的目的只是为了传送讯息给其它的物件。
溜溜问题︰因结构（例如继承）极度破碎冗长，而必须花费极大力气来了解它。

⑨ 响应式用户界面与设计模式 是什么书

本书是Andriod UI设计领域的经典著作，Amazon五星级畅销书。不仅从Android应用设计者的角度系统讲解了要从事Android UI设计必须要掌握的Android平台的所有技术和特性，还从Android应用开发者的角度全面总结了Android UI设计的方法、技巧、模式、反模式，以及如何实现响应式用户界面设计。本书共21章，分为四部分。第一部分（第1～4章）讲述用户界面设计、用户界面设计的工具、移动设备和触摸设备的设计，并探讨Android平台；第二部分（第5～11章）介绍 Android的应用架构和在线指南、Android的意图系统、Android应用的导航结构、主界面应用小部件、通知、物理按键、输入法和传感器设计，以及平台用户界面组件设计；第三部分（第12～16章）讨论 Android资源的管理、Android应用的布局、可缩放的图形、响应式设计，以及如何实现响应式用户界面；第四部分（第17～21章）阐述用户界面设计模式、用户操作设计模式、导航和布局设计模式、数据设计模式以及用户界面设计的反模式。

⑩ 软件设计模式的相近术语

对某个问题经常出现的、在设计中应该尽量避免的、坏的设计方案被称为反模式。 基础模式
委托模式
接口模式
代理模式 抽象工厂模式(Abstract Factory) ,提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
生成器模式 (Builder)，将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
工厂方法模式(Factory Method) ，定义一个用于创建对象的接口，让子类决定将哪一个类实例化。Factory Method使一个类的实例化延迟到其子类。
原型模式 (Prototype) ，用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。
单例模式(Singleton)，保证一个类仅有一个实例，并提供一个访问它的全局访问点。 适配器模式 (Adapter) ，将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
桥接模式(Bridge) ，将抽象部分与它的实现部分分离，使它们都可以独立地变化。
组合模式(Composite) ，将对象组合成树形结构以表示“部分-整体”的层次结构。它使得客户对单个对象和复合对象的使用具有一致性。
容器模式
修饰模式 (Decorator) ，动态地给一个对象添加一些额外的职责。就扩展功能而言， 它比生成子类方式更为灵活。
扩展性模式
外观模式
享元模式
管道与过滤器模式
代理模式(Proxy) ，为其他对象提供一个代理以控制对这个对象的访问。 责任链模式 (Chain of Responsibility) ，为解除请求的发送者和接收者之间耦合，而使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。
命令模式 (Command) ，将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。
柯里化模式
事件监听器模式
解释器模式
迭代器模式
中介者模式
备忘录模式 (Memento) ，在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到保存的状态。
观察者模式(Observer) ，定义对象间的一种一对多的依赖关系,以便当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并自动刷新。
状态模式 (State) ，允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类。
策略模式 (Strategy) ，定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法的变化可独立于使用它的客户。
模板方法模式
访问者模式 (Visitor)，表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
层次访问者模式 模式 Action at a distance
模式 Balking
模式 Guarded suspension
模式 Scheler
模式 Read write lock
模式 Double checked locking
模式 Disable job requests while running job 模式 Scheled task
模式 User interface
模式 Disable job requests while running job 此原则是由Bertrand Meyer提出的。原文是：Software entities should be open for extension,but closed for modification。就是说模块应对扩展开放，而对修改关闭。模块应尽量在不修改原(是原，指原来的代码)代码的情况下进行扩展。那么怎么扩展呢？我们看工厂模式factory pattern:假设中关村有一个卖盗版盘和毛片的小子，我们给他设计一光盘销售管理软件。我们应该先设计一光盘接口。如图：【pre】______________|<>|| 光盘 ||_____________||+卖() || ||_____________|【/pre】而盗版盘和毛片是其子类。小子通过DiscFactory来管理这些光盘。代码为： publicclassDiscFactory{publicstatic光盘getDisc(Stringname){return(光盘)Class.forName(name).getInstance();}}有人要买盗版盘，怎么实现呢？
public class 小子{ public static void main(String【】 args){ 光盘 d=DiscFactory.getDisc(盗版盘); 光盘.卖(); } }
如果有一天，这小子良心发现了，开始卖正版软件。没关系，我们只要再创建一个光盘的子类正版软件就可以了。不需要修改原结构和代码。怎么样？对扩展开放，对修改关闭。开-闭原则 工厂模式是对具体产品进行扩展，有的项目可能需要更多的扩展性，要对这个工厂也进行扩展，那就成了抽象工厂模式。 就是说要少用继承，多用合成关系来实现。我曾经这样写过程序：有几个类要与数据库打交道，就写了一个数据库操作的类，然后别的跟数据库打交道的类都继承这个。结果后来，我修改了数据库操作类的一个方法，各个类都需要改动。牵一发而动全身!面向对象是要把波动限制在尽量小的范围。
在Java中，应尽量针对Interface编程，而非实现类。这样，更换子类不会影响调用它方法的代码。要让各个类尽可能少的跟别人联系，不要与陌生人说话。这样，城门失火，才不至于殃及池鱼。扩展性和维护性才能提高
理解了这些原则，再看设计模式，只是在具体问题上怎么实现这些原则而已。张无忌学太极拳，忘记了所有招式，打倒了玄幂二老，所谓心中无招。设计模式可谓招数，如果先学通了各种模式，又忘掉了所有模式而随心所欲，可谓OO之最高境界。呵呵，搞笑，搞笑！（JR）
依赖倒转原则抽象不应该依赖与细节，细节应当依 类为子类继承，一般包含这个系的共同属性和方法。注意：好的继承关系中，只有叶节点是具体类，其他节点应该都是抽象类，也就是说具体类是不被继承的。将尽可能多的共同代码放到抽象类中。 7 迪米特法则最少知识原则。不要和陌生人说话。