一个程序员对设计模式的理解:　　&不懂&为什么要把很简单的东西搞得那么复杂。后来随着软件开发经验的增加才开始明白我所看到的&复杂&恰恰就是设计模式的精髓所在，我所理解的&简单&就是一把钥匙开一把锁的模式，目的仅仅是着眼于解决现在的问题，而设计模式的&复杂&就在于它是要构造一个&万能钥匙&，目的是提出一种对所有锁的开锁方案。在真正理解设计模式之前我一直在编写&简单&的代码.　　这个&简单&不是功能的简单，而是设计的简单。简单的设计意味着缺少灵活性，代码很钢硬，只在这个项目里有用，拿到其它的项目中就是垃圾，我将其称之为&一次性代码&。
--&要使代码可被反复使用,请用'设计模式'对你的代码进行设计.
很多我所认识的程序员在接触到设计模式之后，都有一种相见恨晚的感觉，有人形容学习了设计模式之后感觉自己好像已经脱胎换骨，达到了新的境界，还有人甚至把是否了解设计模式作为程序员划分水平的标准。
　　我们也不能陷入模式的陷阱，为了使用模式而去套模式，那样会陷入形式主义。我们在使用模式的时候，一定要注意模式的意图（intent），而不 要过多的去关注模式的实现细节，因为这些实现细节在特定情况下，可能会发生一些改变。不要顽固地认为设计模式一书中的类图或实现代码就代表了模式本身。
设计原则：(重要)1.逻辑代码独立到单独的方法中，注重封装性--易读，易复用。不要在一个方法中，写下上百行的逻辑代码。把各小逻辑代码独立出来，写于其它方法中，易读其可重复调用。2.写类，写方法，写功能时，应考虑其移植性，复用性：防止一次性代码！是否可以拿到其它同类事物中应该？是否可以拿到其它系统中应该？3.熟练运用继承的思想：找出应用中相同之处，且不容易发生变化的东西，把它们抽取到抽象类中，让子类去继承它们；继承的思想，也方便将自己的逻辑建立于别人的成果之上。如ImageField extends JTextField；熟练运用接口的思想：找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
把很简单的东西搞得那么复杂，一次性代码，设计模式优势的实例说明：（策略模式）说明：模拟鸭子游戏的应用程序，要求：游戏中会出现各种颜色外形的鸭子，一边游泳戏水，一边呱呱叫。
第一种方法：（一次性代码）直接编写出各种鸭子的类：MallardDuck//野鸭，RedheadDuck//红头鸭，各类有三个方法：quack()：叫的方法swim()：游水的方法display()：外形的方法
第二种方法：运用继承的特性，将其中共同的部分提升出来，避免重复编程。即：设计一个鸭子的超类（Superclass）,并让各种鸭子继承这个超类。
public class Duck{
public void quack(){
System.out.println("呱呱叫");
public void swim(){
System.out.println(" 游泳");
abstratact void display(); /*因为外观不一样，让子类自己去决定了。*/
对于它的子类只需简单的继承就可以了，并实现自己的display()方法。
public class MallardDuck extends Duck{
public void display(){
System.out.println("野鸭的颜色...");
public class RedheadDuck extends Duck{
public void display(){
System.out.println("红头鸭的颜色...");
不幸的是，现在客户又提出了新的需求，想让鸭子飞起来。这个对于我们OO程序员，在简单不过了，在超类中在加一
个方法就可以了。
public class Duck{
public void quack(){
System.out.println("呱呱叫");
public void swim(){
System.out.println(" 游泳");
abstract void display(); /*因为外观不一样，让子类自己去决定了。*/
public void fly(){
System.out.println("飞吧！鸭子");
对于不能飞的鸭子，在子类中只需简单的覆盖。
public class DisabledDuck extends Duck{
public void display(){
System.out.println("残废鸭的颜色...");
public void fly(){
//覆盖，变成什么事都不做。
其它会飞的鸭子不用覆盖。
这样所有的继承这个超类的鸭子都会fly了。但是问题又出来了，客户又提出有的鸭子会飞，有的不能飞。
&&&&&&点评:对于上面的设计，你可能发现一些弊端，如果超类有新的特性，子类都必须变动，这是我们开发最不喜欢看到的，一个类变让另一个类也跟着变，这有点不符合OO设计了。这样很显然的耦合了一起。利用继承--&耦合度太高了.
第三种方法：用接口改进.我们把容易引起变化的部分提取出来并封装之，来应付以后的变法。虽然代码量加大了，但可用性提高了，耦合度也降低了。
我们把Duck中的fly方法和quack提取出来。
public interface Flyable{
public void fly();
public interface Quackable{
public void quack();
最后Duck的设计成为：
public class Duck{
public void swim(){
System.out.println(" 游泳");
abstract void display(); /*因为外观不一样，让子类自 己去决定了。*/
&而MallardDuck,RedheadDuck,DisabledDuck 就可以写成为：
public class MallardDuck extends Duck
implements Flyable,Quackable{
public void display(){
System.out.println("野鸭的颜色...");
public void fly(){
//实现该方法
public void quack(){
//实现该方法
public class RedheadDuck extends Duck implements Flyable,Quackable{
public void display(){
System.out.println("红头鸭的颜色...");
public void fly(){
//实现该方法
public void quack(){
//实现该方法
//残废鸭 只实现Quackable（能叫不能飞）
public class DisabledDuck extends Duck implements Quackable{
public void display(){
System.out.println("残废鸭的颜色...");
public void quack(){
//实现该方法
&&&&&&点评:好处:这样已设计，我们的程序就降低了它们之间的耦合。不足:Flyable和 Quackable接口一开始似乎还挺不错的，解决了问题（只有会飞到鸭子才实现 Flyable），但是Java接口不具有实现代码，所以实现接口无法达到代码的复用。
第四种方法：
对上面各方式的总结:继承的好处:让共同部分,可以复用.避免重复编程.
继承的不好:耦合性高.一旦超类添加一个新方法,子类都继承,拥有此方法,
&&&&&&&&&&&&&&&&&&&&&&& 若子类相当部分不实现此方法,则要进行大批量修改.
&&&&&&&&&&&&&&&&&&&&&&&& 继承时,子类就不可继承其它类了.
接口的好处:解决了继承耦合性高的问题.
&&&&&&&&&&&&&&&&&&&&&&&& 且可让实现类,继承或实现其它类或接口.
接口的不好:不能真正实现代码的复用.可用以下的策略模式来解决.
------------------------- strategy(策略模式) -------------------------我们有一个设计原则：找出应用中相同之处，且不容易发生变化的东西，把它们抽取到抽象类中，让子类去继承它们；找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。 --&important.
现在，为了要分开&变化和不变化的部分&，我们准备建立两组类（完全远离Duck类），一个是"fly"相关的，另一个
是&quack&相关的，每一组类将实现各自的动作。比方说，我们可能有一个类实现&呱呱叫&，另一个类实现&吱吱
叫&，还有一个类实现&安静&。
首先写两个接口。FlyBehavior(飞行行为)和QuackBehavior（叫的行为）.
public interface FlyBehavior{
public void fly();
public interface QuackBehavior{
public void quack();
&我们在定义一些针对FlyBehavior的具体实现。
public class FlyWithWings implements FlyBehavior{
public void
//实现了所有有翅膀的鸭子飞行行为。
public class FlyNoWay implements FlyBehavior{
public void
//什么都不做，不会飞
针对QuackBehavior的几种具体实现。
public class Quack implements QuackBehavior{
public void quack(){
//实现呱呱叫的鸭子
public class Squeak implements QuackBehavior{
public void quack(){
//实现吱吱叫的鸭子
public class MuteQuack implements QuackBehavior{
public void quack(){
//什么都不做，不会叫
点评一:这样的设计，可以让飞行和呱呱叫的动作被其他的对象复用，因为这些行为已经与鸭子类无关了。而我们增加一些新
的行为，不会影响到既有的行为类，也不会影响&使用&到飞行行为的鸭子类。
最后我们看看Duck 如何设计。
public class Duck{
---------&在抽象类中,声明各接口,定义各接口对应的方法.
FlyBehavior flyB//接口
QuackBehavior quackB//接口
public Duck(){}
public abstract void display();
public void swim(){
//实现游泳的行为
public void performFly(){
flyBehavior.fly();
--&由于是接口,会根据继承类实现的方式,而调用相应的方法.
public void performQuack(){
quackBehavior.quack();();
看看MallardDuck如何实现。-----&通过构造方法,生成'飞','叫'具体实现类的实例,从而指定'飞','叫'的具体属性
public class MallardDuck extends Duck{
public MallardDuck {
flyBehavior = new FlyWithWings ();
quackBehavior = new Quack();
//因为MallardDuck 继承了Duck，所有具有flyBehavior 与quackBehavior 实例变量}
public void display(){
&这样就满足了即可以飞，又可以叫，同时展现自己的颜色了。
这样的设计我们可以看到是把flyBehavior ，quackBehavior 的实例化写在子类了。我们还可以动态的来决定。& 我们只需在Duck中加上两个方法。
在构造方法中对属性进行赋值与用属性的setter的区别：
构造方法中对属性进行赋值：固定，不可变；
用属性的setter，可以在实例化对象后，动态的变化，比较灵活。
public class Duck{
FlyBehavior flyB//接口
QuackBehavior quackB//接口
public void setFlyBehavior(FlyBehavior flyBehavior){
this.flyBehavior = flyB
public void setQuackBehavior(QuackBehavior quackBehavior
this.quackBehavior= quackB
更多请移步原文：
阅读(...) 评论()学习设计模式前需要知道的事情 - 简书
学习设计模式前需要知道的事情
为什么要学习设计模式？
做事情之前问个为什么总是好的。关于设计模式的好坏，我在知乎上也看过一些讨论，有知友对其提出过一些疑问，里面有一些关于设计模式的观点:
任何事物的出现都有其道理，任何语言都有其不足之处，设计模式是对语言不足的补充（Peter Norvig)。设计模式也是编程经验的总结，我想学习它对像我这样的前端新手的能力会有很大的提升。
使用设计模式的好处
《Head First 设计模式》一书举了一个非常有意思的例子，
两个人点餐,一个人说:
"我要一份涂了奶酪及果酱的白面包，加了香草冰淇淋的巧克力汽水.."；
另外一个人说:
“给我一份C.J怀特，一个黑与白”
表达同样的意思，效果却完全不同，这里就说到一个比较大的概念“共享词汇”。
共享词汇就是一组概念，行为，方法等等的集合，这个在任何行业都有用，就像中文菜名“回锅肉”，厨子知道什么是回锅肉，你也知道什么是回锅肉，如果没有回锅肉这个共享词汇，我好像真的想不到一个合适的描述来点这道菜。
回到设计模式，各种设计模式就是一个个的共享词汇，它不仅仅是一个名称，更是一整套模式背后所象征的质量，特征，约束。
细说说它的好处：
设计模式能让你用更少的词汇做更充分的沟通；
谈话在模式层次时，不会被压低到对象和类这种琐碎的事情上；
懂设计模式的团队，彼此之间对于设计的看法不容易产生误解；
共享词汇能帮助初级人员快速成长。
总结一下设计模式的作用：
帮助我们将应用组织成容易了解，容易维护，具有弹性的架构，建立可维护的OO系统，要诀在于随时想到系统以后可能需要的变化以及应付变化的原则。
设计模式的使用方法
关于使用方式，像我这种初学者最容易犯的错误就是生搬硬套，但是模仿本来也是学习的一个过程，最重要的事情是在模仿中要学会思考。我也是设计模式的初学者，所以我会常用这句话来提醒自己，看过一句关于如何最好的使用设计模式的话:
“把模式装进脑子里，然后在你的设计和已有的应用中，寻找何处可以使用它们”。
这就有点像是张无忌练习太极拳了，忘了所有的模式吧，你已经在潜移默化的使用它了。当然如果你不学设计模式，你可能也在无意识的使用一些设计模式了，但是这个在跟学过以后再无意识的使用设计模式，应该隔着两重境界吧。
当然要达到这个境界，少不了大量的练习，当然也不能忘了设计是一门艺术，总有许多可取舍的地方。
设计模式的一些原则
找出应用中可能需要改变之处，把它们独立出来，不要和哪些不需要改变的代码混在一起（低耦合）；
针对接口编程，而不是针对实现编程；
关键在于多态，程序可以针对超类型编程，执行时会根据实际状况执行到真正的行为，不会被绑死在超类型的行为上（在JavaScript中并没有超类型的概念。）我的理解是，接口可以理解为一个动作，而动作的具体实现则不用确定。这一点在下文讲解多态时会有一个更加具体的例子。
多用组合，少用继承
可能还有一些其它的原则，目前，我还没有涉及到，在之后的学习过程中，再补充。
需要了解的一些其它概念
要真正的理解设计模式，需要了解面向对象的一些基础概念：抽象，多态，封装和继承。
就JavaScript而言，由于是一门动态语言，在此不考虑抽象这一概念。
概念：同一操作作用于不同的对象上时，可以产生不同的解释和不同的执行结果。
比如说有两只动物，鸡和鸭，当发出命令“叫”时，鸡会“咯咯咯“，鸭会”嘎嘎嘎“；
多态背后的思想是将“做什么”和“谁去做以及怎么去做”分离开来，也就是将“不变的事”和“可变的事物”分离开来。
多态的实现：归根到底是要消除类型之间的耦合关系，JS的变量类型在运行时是可变的，这意味着JS对象的多态性是与生俱来的。
多态的作用：通过把过程化的条件分支语句转化为对象的多态性，从而消除这些条件分支语句。
看一个例子来理解多态：
// 只使用谷歌地图
var googleMap = {
show: function() {
console.log('开始渲染谷歌地图');
var renderMap = function() {
googleMap.show();
renderMap(); //输出：开始渲染谷歌地图
// 好吧，谷歌在某些地方不好用，在某些要换成百度地图了，
var googleMap = {
show: function() {
console.log('开始渲染谷歌地图');
var baiduMap = {
show: function() {
console.log('开始渲染百度地图');
var renderMap = function(type) {
if (type === 'google') {
googleMap.show();
} else if (type = 'baidu') {
baiduMap.show();
renderMap('google'); //输出：开始渲染谷歌地图
renderMap('baidu'); //输出：开始渲染百度地图
// 上述代码有一点的弹性，但是如果在更换地图，改变的地方太多了，这里就可以运用多态性这个理念了,这里也把做什么和怎么做分开了
// 抽象出相同部分,条件分支语句转化为对象的多态性
var renderMap = function(map){
if (map.show() instanceof Function) {
map.show();
renderMap('google'); //输出：开始渲染谷歌地图
renderMap('baidu'); //输出：开始渲染百度地图
// 再添加一个搜搜地图
var sosoMap = {
show: function() {
console.log('开始渲染搜搜地图');
renderMap('soso'); //输出：开始渲染搜搜地图
// 本例来自于《JavaScript设计模式与开发实践》
封装的目的是将信息隐藏,包括隐藏数据，隐藏实现细节，设计细节以及隐藏对象的类型等。
封装分为四类：封装数据，封装实现，封装类型和封装变化
封装数据：
在许多面相对象系统中，封装数据是由语法解析来实现的（private public proctected）;
JavaScript中没有对这些变量的支持，只能利用变量的作用域来实现封装，只能模拟出public.private两种封装性。（ES6可用let），一般用函数来创建作用域。
封装实现：
使得对象内部的变化对其他对象而言是不可见的，对象对其自己的行为负责，使得对象之间的耦合变得松散，对象之间只通过暴露API接口来通信，修改一个对象时，可以随意地修改它的内部实现，只要对外的接口没有变化，就不会影响到程序的其它功能。
封装类型：
对静态语言而言，是一种重要的封装方式，把对象的真正类型隐藏在抽象类或者接口之后，Javascript没有这方面的支持，因此也没有这方面的需要；
封装变化：
把系统中稳定不变的部分和容易变化的部分隔离开来，在系统的演变过程中，我们只需要替换那些容易变化的部分，如果这些部分是已经封装好的，替换起来也相对容易，这可以最大程度的保证程序的稳定性和可扩展性
说到继承，JavaScript最重要的概念可能在于原型链。
基于原型链的委托机制就是原型继承的本质。
所有的数据都是对象，JS的根对象是Object.prototype对象，它是一个空对象；
要得到一个对象，不是通过实例化类而是找到一个对象作为原型来克隆它；
对象会记住它的原型；就JS而言，对象的原型其实是其构造器的原型（new），包含在其隐藏属性_proto_中；
如果对象无法响应某个请求，它会把这个请求委托给自己的原型。
JavaScript的原型最初都是由Object.prototype对象克隆而来；
对象构造器的原型并不限于Object.prototype,可以动态的指向其他对象； A.prototype=obj
原型链并非无限长，到顶（Object.prototype）以后，如果没有找到就会返回undefined；
本文是我学习设计模式的第一篇笔记，里面若有不恰当的地方，欢迎随时指出，也希望您看完本文，跟我一样有所收获。
前端\摄影\阅读\好奇。
面向对象的JavaScript 1.1 动态类型语言和鸭子类型 按照数据类型，编程语言可以分为两大类：静态类型语言和动态类型语言 。 静态类型语言在编译时就已确定变量的类型，而动态类型语言要在程序运行时，等变量被赋值后，才确定数据类型。 静态类型语言的优点：可以帮助开发者在...
《JavaScript设计模式与开发实践》作者：曾探 系统的介绍了各种模式，以及js中的实现、应用，以及超大量高质量代码，绝对值得一读 面向对象的js 静态类型：编译时便已确定变量的类型 优点： 编译时就能发现类型不匹配的错误，编辑器可以帮助我们提前避免程序在运行中可能发生...
面向对象的JavaScript JavaScript 没有提供传统面向对象语言中的类式继承，而是通过原型委托的方式来实现对象与对象之间的继承。JavaScript 也没有在语言层面提供对抽象类和接口的支持。正因为存在这些跟传统面向对象语言不一致的地方，我们在用设计模式编写代...
博客内容：什么是面向对象为什么要面向对象面向对象编程的特性和原则理解对象属性创建对象继承 什么是面向对象 面向对象程序设计即OOP（Object-oriented programming），其中两个最重要的概念就是对象和类。 JS中的对象都是基于一个引用类型创建的，这个引用...
工厂模式类似于现实生活中的工厂可以产生大量相似的商品，去做同样的事情，实现同样的效果;这时候需要使用工厂模式。简单的工厂模式可以理解为解决多个相似的问题;这也是她的优点;比如如下代码：function CreatePerson(name,age,sex) {var obj ...
第一次见她，以接替同事的工作过来实习。长得有点儿萌胖萌胖的，虽然印象不深，起码都有点感觉小可爱。只是很快就令我不快了。午饭时间走起，毕竟我不知道她是谁，尽管多一个人多一碗筷也没什么，但是，毫无准备的预留份量，一下子不请自来，可有多尴尬？要命的还自作主张邀请上一个刚放下外卖擦...
你曾说有个你有个温暖的家，父母待你回家。 你曾说你会去见那朋友，如今还走吗？ 直到再出现在远方，独自想念她。 他们到底都在哪儿呀，我们回去吧。
三金 1那天招新面试我迟到了 从历史来看，念书确实不是我擅长的一件事情，因为努力的高中三年最终未能如愿迈入重点名校的大门，只能让我来到苏北的“淮海工学院”，从此开启了我的四年本科生涯。 生活和时间并轨，时间过去了尚且如东流之水难复回，生活每一段成为历史的时候也是难以追寻的，...
1、当五百年的光阴只是一个骗局,虚无时间中的人物又为什么而苦,为什么而喜呢? 2、生我何用？不能欢笑。灭我何用？不减狂骄。 3、“我要这天，再遮不住我眼，要这地，再埋不了我心，要这众生，都明白我意，要那诸佛，都烟消云散！” 4、 明知道是不可能相见的，为什么还要记住？ 5、...
因为工作中使用了SOAP进行两个系统的接口调用，所以私下学习一下两种实现，粗略记录于此。本文侧重于实际实现操作，而不是理论原理。 个人简单理解：SOAP（Simple Object Access Protocol 简单对象访问协议）是基于XML和HTTP的用于实现网络连通的...设计模式&&最熟悉的陌生人。
很多人应该都有这种感受，早就知道设计模式，也能随口说出几种，但是不知道每种是怎么回事。或者说只知道工厂模式等几个常用，简单的。估计那也是靠记忆，而不是真正的理解。
我也有这种亲身体会，在好几年之前就知道设计模式。之前也一直抽时间学，但总是学了就忘。而且学习过程很枯燥，完全是背诵式的记忆那些类图，不是真正的理解，更别提应用了。
2. 关于&设计&
设计，就是为了更好的应对变化。没毕业时候不知道软件系统怎么会有变化，但是工作之后慢慢就会发现，变化，那叫一个天马行空。。。
一提到&设计&，大部分人可能会直接想到设计模式，而且是23种设计模式。其实这是错误的。其实学会设计、应用设计，应该分为四个层次：
2.1 面向对象&
首先要了解面向对象，什么是面向对象？什么是封装、继承和多态，以及三个特点的表现形式。基础很重要。
要想充分了解面向对象，三个特点，最好还是按部就班的参考一本权威书籍，看看书上说的你是不是真的理解。看看继承和多态的表现形式你是否都知道。
如果没按部就班看过书，就不要以为自己都会了。借用某相声演员一句话：&你以为你以为的就是你以为的？&。。。
2.2 抽象与具体
如何更好的解决&变化&问题？答案是&提取抽象、隔离具体&。&
什么是&抽象&？ 抽象就是不变的东西，一个数据表的操作，总会有增删改查，把他们作为接口，这是不变的。
什么是&具体&？ 具体是实际执行的，一个数据表的增删改查，用sqlserver、access还是oracle？可能会有变化。
我们应该依赖于抽象编程，而不是依赖于具体编程。应该把程序中的共性抽象出来，并且把具体实现的部分隔离开来，让他们都依赖于抽象，并且互不影响。这其实就是设计。
只有理解了&抽象&、&具体&、&隔离&这几个词儿，你才能真正理解设计模式。否则就别指望。
2.3 SOLID五大原则
系统设计的5大原则，简写分别是S、O、L、I、D。
S - 类职责单一原则： 即职责划分要清晰，不同职责的不要搅和在一起。每个类应该只有一个让他发生改变的原因。
O - 开放封闭原则： 对扩展开发，对修改封闭。即如果系统要变化，就去扩展、新增新类，不要修改现有的类。
L - LISKOV原则： 子类应该能充分覆盖父类，并且让使用者分不出差别。
I - 接口分离原则：每个接口只管一个功能，不要出现&胖接口&。增加功能时，要加接口，而不是改接口
D - 依赖倒置原则：具体应该依赖于抽象，而不是抽象一来于具体，即低层要依赖于高层。
对于以上5大原则，此处不详细解释，有兴趣的可以查阅《你必须知道的.net》第二版，里面讲的非常详细。
如果详细分析这5大原则，其实他们都是围绕着&提取抽象、隔离具体&来的。
S - 类职责单一原则： 隔离
O - 开放封闭原则： 依赖于抽象，隔离具体
L - LISKOV原则：抽象
I - 接口独立原则：隔离
D - 依赖倒置原则：依赖于抽象
2.4 设计模式
最后才是设计模式，设计模式其实是一些工具而已。
是&术&，不是&道&。如果你不明白以上那些&道&，而直接去学&术&，肯定是学一次忘一次。
在看每个设计模式的时候，你都要去向着这个方向去思考：它是不是提取了抽象、分离了具体、依赖于抽象、封装了具体？ 这样一来，你就会明白了。
3 例子：工厂模式
工厂模式在设计模式中分三种：简单工厂、工厂方法和抽象工厂，其实这三种对应了不同的抽象程度。 下面简单分析前两种。
3.1 简单工厂：
看上图，很明显是&提取抽象，分离具体&。将数据操作的接口提取出来，交给不同的实现类来实现。
工厂类返回的是IDBHelper接口，即客户端会调用IDBHelper接口，而不需要关心具体实现，这就是&依赖于抽象，而不是依赖于具体&。
还符合&开放封闭原则&，例如现在又要用DB2数据库，那么再加一个实现类就行，无需改其他地方。客户端也不会察觉后台的变化。这就是：对扩展开放，对修改封闭。
简单工厂之所以叫&简单&，是因为它的工厂类还依赖于数据操作实现类，这违反了&依赖倒置原则&，那么该怎么办呢？
3.2 工厂方法：
上文说了，简单工厂类依赖与数据操作实现类，当前有3个实现类，那么工厂类肯定需要判断，免不了有if else或者swicth case语句，
switch (type)
case "sqlserver":
return new SQLDBHelper();
case "oracle":
return new OracleDBHelper();
case "access":
return new AccessDBHelper();
throw new Exception("type参数错误");
而这些语句，就是设计模式重点要改进的地方。
如何让工厂类不依赖于数据操作实现类？ 答案还是&提取抽象，分离具体实现&。
将工厂类的具体职责抽象出来，然后分离一些实现类，分别实现各自的功能。
学设计模式不容易，需要熟悉语言、面向对象、理解设计原则。。。。即便是都看会了，理解了，到了应用又是个麻烦事儿。
有一位大牛说过：《设计模式》这本书，我们要像字典一样经常拿出来翻翻看看，而不是通篇看完就算了。
可见，它需要我们长期的&学习 - 应用 - 总结 - 学习&，才能更好的理解。
另外，我感觉在系统设计中，也没有必要非得去套用设计模式，只要符合设计原则，符合开发、运行效率，怎样设计都行，不要为了用而用，滥用不如不用。
话又说回来，还是对设计大原则，对&道&的理解。
阅读(...) 评论()