关于设计模式的经典文章

第一篇：关于设计模式的经典文章

追MM与设计模式 创建型模式

1、FACTORY—追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽 然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行 了。麦当劳和肯德基就是生产鸡翅的Factory

工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如 ：如何创建及如何向客户端提供。

2、BUILDER—MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的 方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我 只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松 搞掂，这就是我的“我爱你”builder。（这一定比美军在伊拉克用的翻译机好卖）

建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有 不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道 产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。

3、FACTORY METHOD—请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一 件烦人的事情，我一般采用Factory Method模式，带着MM到服务员那儿，说“要一个汉堡 ”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。

工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去 做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产 品类应当被实例化这种细节。

4、PROTOTYPE—跟MM用QQ聊天，一定要说些深情的话语了，我搜集了好多肉麻的情话，需 要时只要copy出来放到QQ里面就行了，这就是我的情话prototype了。（100块钱一份，你 要不要）

原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原 型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产 品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。缺点 是每一个类都必须配备一个克隆方法。

5、SINGLETON—俺有6个漂亮的老婆，她们的老公都是我，我就是我们家里的老公 Sigleton，她们只要说道“老公”，都是指的同一个人，那就是我(刚才做了个梦啦，哪 有这么好的事)

单例模式：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个 实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。

结构型模式

6、ADAPTER—在朋友聚会上碰到了一个美女Sarah，从香港来的，可我不会说粤语，她不 会说普通话，只好求助于我的朋友kent了，他作为我和Sarah之间的Adapter，让我和 Sarah可以相互交谈了(也不知道他会不会耍我)

适配器（变压器）模式：把一个类的接口变换成客户端所期待的另一种接口，从而使原本 因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个 合适的实例给客户端。

7、BRIDGE—早上碰到MM，要说早上好，晚上碰到MM，要说晚上好；碰到MM穿了件新衣服，要说你的衣服好漂亮哦，碰到MM新做的发型，要说你的头发好漂亮哦。不要问我“早上 碰到MM新做了个发型怎么说”这种问题，自己用BRIDGE组合一下不就行了

桥梁模式：将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强 关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而 不是继承关系，从而使两者可以独立的变化。

8、COMPOSITE—Mary今天过生日。“我过生日，你要送我一件礼物。”“嗯，好吧，去商 店，你自己挑。”“这件T恤挺漂亮，买，这条裙子好看，买，这个包也不错，买。”“ 喂，买了三件了呀，我只答应送一件礼物的哦。”“什么呀，T恤加裙子加包包，正好配 成一套呀，小姐，麻烦你包起来。”“„„”，MM都会用Composite模式了，你会了没有 ？

合成模式：合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式 就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合 成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。

9、DECORATOR—Mary过完轮到Sarly过生日，还是不要叫她自己挑了，不然这个月伙食费 肯定玩完，拿出我去年在华山顶上照的照片，在背面写上“最好的的礼物，就是爱你的 Fita”，再到街上礼品店买了个像框（卖礼品的MM也很漂亮哦），再找隔壁搞美术设计的 Mike设计了一个漂亮的盒子装起来„„，我们都是Decorator，最终都在修饰我这个人呀，怎么样，看懂了吗？

装饰模式：装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。动态给一个对象增加功能，这些功能可以再动态的撤消。增 加由一些基本功能的排列组合而产生的非常大量的功能。

10、FACADE—我有一个专业的Nikon相机，我就喜欢自己手动调光圈、快门，这样照出来 的照片才专业，但MM可不懂这些，教了半天也不会。幸好相机有Facade设计模式，把相机 调整到自动档，只要对准目标按快门就行了，一切由相机自动调整，这样MM也可以用这个 相机给我拍张照片了。

门面模式：外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一

个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门面类 只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。

11、FLYWEIGHT—每天跟MM发短信，手指都累死了，最近买了个新手机，可以把一些常用 的句子存在手机里，要用的时候，直接拿出来，在前面加上MM的名字就可以发送了，再不 用一个字一个字敲了。共享的句子就是Flyweight，MM的名字就是提取出来的外部特征，根据上下文情况使用。

享元模式：FLYWEIGHT在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大量 的细粒度对象。享元模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态存储在 享元内部，不会随环境的改变而有所不同。外蕴状态是随环境的改变而改变的。外蕴状态 不能影响内蕴状态，它们是相互独立的。将可以共享的状态和不可以共享的状态从常规类 中区分开来，将不可以共享的状态从类里剔除出去。客户端不可以直接创建被共享的对象，而应当使用一个工厂对象负责创建被共享的对象。享元模式大幅度的降低内存中对象的 数量。

12、PROXY—跟MM在网上聊天，一开头总是“hi,你好”,“你从哪儿来呀？”“你多大了 ？”“身高多少呀？”这些话，真烦人，写个程序做为我的Proxy吧，凡是接收到这些话 都设置好了自动的回答，接收到其他的话时再通知我回答，怎么样，酷吧。

代理模式：代理模式给某一个对象提供一个代理对象，并由代理对象控制对源对象的引用。代理就是一个人或一个机构代表另一个人或者一个机构采取行动。某些情况下，客户不 想或者不能够直接引用一个对象，代理对象可以在客户和目标对象直接起到中介的作用。客户端分辨不出代理主题对象与真实主题对象。代理模式可以并不知道真正的被代理对象，而仅仅持有一个被代理对象的接口，这时候代理对象不能够创建被代理对象，被代理对 象必须有系统的其他角色代为创建并传入。

行为模式

13、CHAIN OF RESPONSIBLEITY—晚上去上英语课，为了好开溜坐到了最后一排，哇，前 面坐了好几个漂亮的MM哎，找张纸条，写上“Hi,可以做我的女朋友吗？如果不愿意请向 前传”，纸条就一个接一个的传上去了，糟糕，传到第一排的MM把纸条传给老师了，听说 是个老处女呀，快跑!

责任链模式：在责任链模式中，很多对象由每一个对象对其下家的引用而接

起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。客户并 不知道链上的哪一个对象最终处理这个请求，系统可以在不影响客户端的情况下动态的重 新组织链和分配责任。处理者有两个选择：承担责任或者把责任推给下家。一个请求可以 最终不被任何接收端对象所接受。

14、COMMAND—俺有一个MM家里管得特别严，没法见面，只好借助于她弟弟在我们俩之间 传送信息，她对我有什么指示，就写一张纸条让她弟弟带给我。这不，她弟弟又传送过来 一个COMMAND，为了感谢他，我请他吃了碗杂酱面，哪知道他说：“我同时给我姐姐三个

男朋友送COMMAND，就数你最小气，才请我吃面。”，命令模式：命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任 和执行命令的责任分割开，委派给不同的对象。命令模式允许请求的一方和发送的一方独 立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否执行，何时被执行以及是怎么被执行的。系统支持命令的撤消。

15、INTERPRETER—俺有一个《泡MM真经》，上面有各种泡MM的攻略，比如说去吃西餐的 步骤、去看电影的方法等等，跟MM约会时，只要做一个Interpreter，照着上面的脚本执 行就可以了。

解释器模式：给定一个语言后，解释器模式可以定义出其文法的一种表示，并同时提供一 个解释器。客户端可以使用这个解释器来解释这个语言中的句子。解释器模式将描述怎样 在有了一个简单的文法后，使用模式设计解释这些语句。在解释器模式里面提到的语言是 指任何解释器对象能够解释的任何组合。在解释器模式中需要定义一个代表文法的命令类 的等级结构，也就是一系列的组合规则。每一个命令对象都有一个解释方法，代表对命令 对象的解释。命令对象的等级结构中的对象的任何排列组合都是一个语言。

16、ITERATOR—我爱上了Mary，不顾一切的向她求婚。

Mary：“想要我跟你结婚，得答应我的条件”

我：“什么条件我都答应，你说吧”

Mary：“我看上了那个一克拉的钻石”

我：“我买，我买，还有吗？”

Mary：“我看上了湖边的那栋别墅”

我：“我买，我买，还有吗？”

Mary：“你的小弟弟必须要有50cm长”

我脑袋嗡的一声，坐在椅子上，一咬牙：“我剪，我剪，还有吗？”

„„

迭代子模式：迭代子模式可以顺序访问一个聚集中的元素而不必暴露聚集的内部表象。多 个对象聚在一起形成的总体称之为聚集，聚集对象是能够包容一组对象的容器对象。迭代 子模式将迭代逻辑封装到一个独立的子对象中，从而与聚集本身隔开。迭代子模式简化了 聚集的界面。每一个聚集对象都可以有一个或一个以上的迭代子对象，每一个迭代子的迭

代状态可以是彼此独立的。迭代算法可以独立于聚集角色变化。

17、MEDIATOR—四个MM打麻将，相互之间谁应该给谁多少钱算不清楚了，幸亏当时我在旁 边，按照各自的筹码数算钱，赚了钱的从我这里拿，赔了钱的也付给我，一切就OK啦，俺 得到了四个MM的电话。

调停者模式：调停者模式包装了一系列对象相互作用的方式，使得这些对象不必相互明显 作用。从而使他们可以松散偶合。当某些对象之间的作用发生改变时，不会立即影响其他 的一些对象之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多的相互 作用转化为一对多的相互作用。调停者模式将对象的行为和协作抽象化，把对象在小尺度 的行为上与其他对象的相互作用分开处理。

18、MEMENTO—同时跟几个MM聊天时，一定要记清楚刚才跟MM说了些什么话，不然MM发现 了会不高兴的哦，幸亏我有个备忘录，刚才与哪个MM说了什么话我都拷贝一份放到备忘录 里面保存，这样可以随时察看以前的记录啦。

备忘录模式：备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模 式的用意是在不破坏封装的条件下，将一个对象的状态捉住，并外部化，存储起来，从而 可以在将来合适的时候把这个对象还原到存储起来的状态。

19、OBSERVER—想知道咱们公司最新MM情报吗？加入公司的MM情报邮件组就行了，tom负 责搜集情报，他发现的新情报不用一个一个通知我们，直接发布给邮件组，我们作为订阅 者（观察者）就可以及时收到情报啦

观察者模式：观察者模式定义了一种一队多的依赖关系，让多个观察者对象同时监听某一 个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使他们能够自 动更新自己。

20、STATE—跟MM交往时，一定要注意她的状态哦，在不同的状态时她的行为会有不同，比如你约她今天晚上去看电影，对你没兴趣的MM就会说“有事情啦”，对你不讨厌但还没 喜欢上的MM就会说“好啊，不过可以带上我同事么？”，已经喜欢上你的MM就会说“几点 钟？看完电影再去泡吧怎么样？”，当然你看电影过程中表现良好的话，也可以把MM的状 态从不讨厌不喜欢变成喜欢哦。

状态模式：状态模式允许一个对象在其内部状态改变的时候改变行为。这个对象看上去象 是改变了它的类一样。状态模式把所研究的对象的行为包装在不同的状态对象里，每一个 状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其内部状态 改变的时候，其行为也随之改变。状态模式需要对每一个系统可能取得的状态创立一个状 态类的子类。当系统的状态变化时，系统便改变所选的子类。

21、STRATEGY—跟不同类型的MM约会，要用不同的策略，有的请电影比较好，有的则去吃 小吃效果不错，有的去海边浪漫最合适，单目的都是为了得到MM的芳心，我的追MM锦囊中 有好多Strategy哦。

策略模式：策略模式针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从 而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。策略模式把行为和环境分开。环境类负责维持和查询行为类，各种算法在具体的策略类中 提供。由于算法和环境独立开来，算法的增减，修改都不会影响到环境和客户端。

22、TEMPLATE METHOD——看过《如何说服女生上床》这部经典文章吗？女生从认识到上 床的不变的步骤分为巧遇、打破僵局、展开追求、接吻、前戏、动手、爱抚、进去八大步 骤(Template method)，但每个步骤针对不同的情况，都有不一样的做法，这就要看你随 机应变啦(具体实现)；

模板方法模式：模板方法模式准备一个抽象类，将部分逻辑以具体方法以及具体构造子的 形式实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的 方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。先制定一个顶级逻辑框架，而 将逻辑的细节留给具体的子类去实现。

23、VISITOR—情人节到了，要给每个MM送一束鲜花和一张卡片，可是每个MM送的花都要 针对她个人的特点，每张卡片也要根据个人的特点来挑，我一个人哪搞得清楚，还是找花 店老板和礼品店老板做一下Visitor，让花店老板根据MM的特点选一束花，让礼品店老板 也根据每个人特点选一张卡，这样就轻松多了；

访问者模式：访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这 些操作需要修改的话，接受这个操作的数据结构可以保持不变。访问者模式适用于数据结 构相对未定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集 合可以相对自由的演化。访问者模式使得增加新的操作变的很容易，就是增加一个新的访 问者类。访问者模式将有关的行为集中到一个访问者对象中，而不是分散到一个个的节点 类中。当使用访问者模式时，要将尽可能多的对象浏览逻辑放在访问者类中，而不是放到 它的子类中。访问者模式可以跨过几个类的等级结构访问属于不同的等级结构的成员类。

第二篇：我写的设计模式的文章总结

设计模式

设计模式的理解

研读GOF的“设计模式”和阎宏博士的“Java 与模式”已经有一段时间，自己颇有一些体会，自己面向对象和软件设计模式有了一些深入的理解，下面就一步一步开始自己的模式历程吧，从最简单的工厂模式到适配器模式，从 State模式到Decorator模式，一直到最复杂难懂的visitor模式，没有一个模式不体现了前辈的聪明才智，需要我们大家用心去体会和理解

恰当地使用设计模式，能使软件系统的架构更合理，能使将来的维护和修改更方便，能使数据库表结构的设计更合理，恰当的冗余和数据关联，能使我们的软件更多地适应变化，总之，它的的作用是不可低估的！

1，简单工厂，工厂方法和抽象工厂模式

对于简单工厂来说，它的工厂只能是这个样子的 public class SimplyFactory { /** * 静态工厂方法 */ public static Prouct factory(String which)throw NoSuchProductExcption {

if(which.equalIgnoreCase(“product1”))

{

return new Product1();

}

else if(which.equalsIgnoreCase(“product2”))

{

return new Product2();

}

else if(which.equalsIgnoreCase(“product3”))

{

return new Product3();

}

else throw NoSuchProductExcption(“NoSuchProduct”);

} } }

而对产品Product1,Product2,Product3,可以执行接口Product,也可以不执行接口Product（当然这样不好），这个Product接口只是用来抽象具体product用的

public interface Product {

第三篇：网评文章写法模式

网评文章写法模式

“终身负责”将冤假错案带进“春天里”

昨日，最高人民检察院发布了《关于完善人民检察院司法责任制的若干意见》全文（下称《意见》）。意见规定，检察官必须在司法一线办案，并对办案质量终身负责，一旦确认发生冤假错案，将一律启动问责机制。（9月29日，人民网）

《意见》中指出，检察人员在职责范围内对办案质量终身负责。倘若被告人被宣告无罪，国家承担赔偿责任，确认发生冤假错案，一律启动问责机制，核查是否存在应予追究司法责任的情形。此举无疑将法治社会的进程推上了一个新的台阶，将冤假错案带进“春天里”。说起冤假错案，都是让人深恶痛绝的事情。倘若这类发生在案件的当事人身上，对于一个人、一个家庭所带来的打击是沉痛的。而发生这类事情的概率也不是想象中的千分之几或者万分之几，对于当事人来讲都是百分之百的不幸。记得曾经轰动一时的呼格吉勒错杀案，到头来才知道是错杀、错判所致。而人死不能复生，用再多的忏悔、再多的金钱都无法挽回逝去生命。

事实上，谁都不愿意一手制造冤假错案，出于良心、出于公心、出于职责，每一位检察官都想将案件办好、办实、办细。然而，有些时候，一些检察官为了所谓的办案数量、办案结案率以及办案时间等诸多指标和考核，往往会忽略了最重要的办案质量。在可办可不办的情况下，给办了；在可追究可不追究的情况下，追究了。看起来是从重、从快，给检察官增添了诸多业绩和政绩，实际上却给当事人带来了诸多“难言之隐”，极易造成冤假错案，也让检察官的形象不会因此而变得高大。

而“终身负责”，定能助力告别冤假错案。试想，万一哪个案件办错了，冤枉了好人、杀错了好人，哪怕是检察官已经退休或者是花甲之年，都难逃曾经办错案所带来的不利后果，那么，作为检察官，哪头重哪头轻，如何做到严密、谨慎办案，更是首先要考虑和必须具备的基本条件。我们有理由相信，检察官办案“终身负责”定能将冤假错案带来一个崭新的春天。作者口2733740549长期兼职代写党建类时评，保证原创，长期合作

发展农村淘宝，岂能靠政府强制网购？

据报道，24日，网上传出的一张有扶风县人大常委会办公室公章及落款的“通知”中写道：“机关各位领导和同志：我县农村淘宝项目定于9月23日启动运营，按阿里集团业绩目标，运营首日全县36个村淘宝点订单要求达到一万单。”通知最后称，“请机关各位同志近期准备所需购买物品清单，每人消费暂定1000元。” 据了解，扶风县阿里巴巴“农村淘宝”项目是在本月23日正式启动的，县级服务中心和第一批35个村级服务点也在同日开始运营。当天，前往35个村级服务点参与网络代购的有5000多人，购买单量3440笔，成交额达到306万元。

这样的“强制消费”行为受到网友、媒体痛扁。压力之下，扶风县人大做出解释称，他们只是“倡议”，而非“强制”。可是，我们确实很难从字里行间嗅出有“倡议”的气味。

发展农村淘宝，是当今各级政府的一个新课题。确实，农村淘宝既能足不出户就能淘到优质廉价的宝贝，又能为自己增加一条致富的通道，同时解决地方就业及经济发展的问题。在全国近几年盛行的淘宝县、淘宝村的大氛围之下，很多地方政府纷纷效仿，争取能够凭借过国家鼎力支持的东风，能够分得一杯羹。

可是发展农村淘宝，仅仅靠政府的强制消费就可以确保走上正轨吗？阿里巴巴对业绩的要求，从来就没有首日成交必须有多少金额的限制？懂行的人都知道，首日上线运营不可能有上百万元的成交，除非是亏本销售。政府这样的行为，无非是为了给自己的政绩画上一个美丽的符号，可是这样的符号确实中看不中用。

其次，政府不能以行政手段干预市场行为，甚至实行地方保护主义。政府在推动当地农村淘宝发展中，要注重因地制宜，根据自己地区的特色来策划自己的特色产品，要聘请优秀的网购运营商来指导如何发展农村电商。实地经营也好，电商也罢，说白了都是一场生意。生意场上都是实战，不是花拳绣腿，不是敷衍作秀，确实需要地方政府的引导，但是更重要的是要凭借实力才能站住脚跟。

第四篇：写景文章的教学模式

写景类文章的教学模式初探

翻开苏教版的语文课本，你会发现许多文章都是文质兼美，生动有趣。特别是写景的文章语言优美,意境深远,展现了一幅幅栩栩如生、令人陶醉的画面。那么如何引领学生走进文中的精彩世界，感受到语言文字的魅力，体会到文章所要表达的情感。基于自身肤浅的认识，我对写景类课文进行了课堂教学初步探究，从中揣摩到一些关于写景类课文的有效教学模式。

一、课前预习，促求新知，储备美

课前预习，即是让学生带着已有的知识基础走进课堂，这是实施有效教学策略的首要任务。在进行写景类文章教学前，教师要根据课文内容提前布置预习，让学生观察、搜集有关文本内容的图片、文字和影像等资料，以促进学生探求新知的兴趣，激发阅读期待。

比如，在执教苏教版第七册《九寨沟》一课时可以布置学生课前搜集有关九寨沟的图片和文字资料。学生搜集资料有最基本的三个途径：第一，询问父母关于九寨沟的知识；第二，浏览图书查阅关于九寨沟的图片和文字资料；第三，上网搜集关于九寨沟美景的影像资料。在课堂教学中，因学生对九寨沟已经有了初步的了解和认识，因而对文本的理解就起了良好的铺垫作用。由此，我们认识到学生搜集资料的过程实际就是对课文内容的初次认知、储备的过程，在搜集资料的过程中，学生对文本内容产生了强烈的阅读期待，这是促进学生自主探求新知的一种有效教学策略。

二、创设情境，直观导入，激发美

写景类的文章，学生很难在头脑中建立起课文所描绘的景物的整体形象，因而就无从把握景物所体现的内容、思想和情感。为此，教师在教学写景文章时，特别是在导入新课时，应恰当运用多媒体教学手段，创设教学情境，形象、直观、生动地再现课文。如在新授《泉城》一课时，教师可运用多媒体、挂图等手段，为学生展示一幅幅与文本相关的泉水，并配以悦耳的音乐，带学生走进泉城——济南，初步领略泉城的美丽、闻名，从而唤起学生进一步感受的欲望，为下一步深入文本的学习做好充分的心理准备。

三、初读课文，整体感知，感受美

1、检查预习让学生带着初步的感性认识自由地朗读课文，扫清生字障碍。这是阅读的最低要求，也是最基础的要求。在学生预习课文的基础上，从词语的认读、生字的读音、整篇课文的正确流利朗读三方面来检查学生的预习效果，掌握学生的预习情况，便于做到以学定教。语言障碍解决了，这就为进一步从语言文字入手来理解课文打下了基础。

2、整体感知

检查预习之后，应引导学生从整体入手进行阅读感知，对课文内容有一个大概地了解。如：课文写了哪里的美景？你能不能用一句话或几个词语来概括一下这里的美景？使学生对课文的主要内容有个全景式的整体感知，了解课文主要写了什么，初步感受到景物的美。

3、质疑问难

鼓励学生独立思考，质疑问难，这是提高学生提出问题和解决问题的好办法，同时问题的提出也可以相应地为课堂精彩地生成而做好准备。

四、精读文本，品读评析，欣赏美

1、批注阅读

在学生对文本整体感知的基础上，教师可以设计一个统领全文的问题作为切入点，引导学生带着问题批注阅读。如：你是从哪些句段体会到九寨沟是个充满诗情画意的人间仙境？你是从哪儿感受到荷兰田园风光的如诗如画？„„写批注就是在圈点的基础上，在旁边写下自己对文章的思索、感悟。批注的方式多种多样。它可以是自己对文章内容的理解，也可以是自己对文章内容的反思、怀疑，还可以是对文章表达的情感所产生的共鸣，甚至可以是自己对文章内容的重新举例等。再通过小组交流——小组汇报——教师相机引导，体会景物特征，指导感情朗读，理解课文内容。

2、品读欣赏

每一篇写景课文都有重点的段落，要么文字优美，词汇丰富，用语精当，要么是最能体现景物的特色，要么是最能表达作者丰富的情感„„不管是哪一类型的段落，我们都可以引导学生边读边想象，透过语言文字的表述进行情感体验、想象创造。

在这一环节，教师一定要引导学生品词析句，学习作者遣词造句的方法，适当进行词句的理解和扩展训练，以丰富学生语言，丰厚学生文化底蕴，这是有效教学策略之一。教师可以根据课文中的重点词语进行词语的拓展练习，比如学生对“色彩斑斓”一词并不难，但要引导学生积累它的近义词，如五彩缤纷、五颜六色、万紫千红、姹紫嫣红和五光十色等，以进一步夯实语文基础。

五、回归整体，梳理写法，升华美

读评析，欣赏过景物的美之后，教师还应该引导学生回顾全文，在诵读中从整体上把握文章的主要内容、思想感情，升华对美景的热爱之情。同时还要把交流中感悟到的作者的表达方法加以系统地梳理，体会这样写的好处，内化为自己的语言，为作文打基础。

六、读写结合，拓展练笔，创造美

写景的文章中蕴藏着极其丰富的读写结合的资源，教师可以依据学生的不同水平设计出不同层次的片段练笔，使学生学以致用，举一反三，及时巩固所学的表达方法，不断提高习作能力。

第五篇：设计模式心得体会

设计模式心得体会

第一篇：设计模式

7月初的一个周末，准确的说应该是7月1号周六，在网上看到一本《大话设计模式》的书，而且看到很多很好的评论，于是乎，下载了电子书看看，一下子看了几章之后，对设计模式有了个了解，于是继续上网搜些其他资料，进一步了解设计模式。最终结论：设计模式是个好东西，具体怎么好，一两句话是无法概括的，也是从那天起，我就决定学习设计模式，于是就看《大话设计模式》，至七月十多号，大概看了一百多页后，感觉有点难，有点看不下去的感觉，于是上网找其他的好方法，无意间发现了李建忠老师的《c#设计模式纵横谈》系列讲座，微软的webcast课程，主要讲解gof的xx个设计模式，每个一讲，加上一头一尾，共xx讲，试听了一节课后，感觉很有用，于是就抽时间去边听课边看书，并在我的博客里写下笔记，依赖加深印象，二来可以督促我的进度。

三个月以来，总算把设计模式学完一遍了，原计划是两个月学完（一星期三个模式），由于。计划两个月学完实际花了三个月，感触多多，收获多多——对c#语言有了更进一步的认识，对oo的思想有了更全面的了解。下一步在设计模式方面的计划：巩固并运用设计模式，巩固：把《大话设计模式》，《设计模式》，《设计模式——可复用的面向对象基础》，《敏捷软件开发：原则、模式与实践》这些书再结合起来系统的看一看，当然还会去买一些我手头上没有的关于设计模式的书；运用：部门前几天也提倡用c#来改版vb程序，我想这是一个很好的平台，正好有机会把理论的东西在实际中应用，理论加实际——唯一的学习方法。

下面对各个模式再简单总结一下：

1、创建型模式：

singleton：解决的是实例化对象的个数的问题，比如抽象工厂中的工厂、对象池等，除了singleton之外，其他创建型模式解决的都是new所带来的耦合关系。

abstractfactory：创建一系列相互依赖对象，并能在运行时改变系列。

factorymethod：创建单个对象，在abstractfactory有使用到。

prototype：通过拷贝原型来创建新的对象。

factorymethod，abstractfactory,builder都需要一个额外的工厂类来负责实例化一边对象，而prototype则是通过原型（一个特殊的工厂类）来克隆易变对象。

如果遇到易变类，起初的设计通常从factorymethod开始，当遇到更多的复杂变化时，再考虑重构为其他三种工厂模式（factorymethod，abstractfactory,builder）。

2、结构性模式

adapter：注重转换接口，将不吻合的接口适配对象，用于旧代码复用、类库迁移等。

bridge：注重实现抽象和实现的分离，支持对象多维度的变化。

composite：注重同意接口，将一对多的关系转化为一对一的关系，屏蔽对象容器内部实现结构，实现对象和对象容器使用的一致性。

decorator：注重稳定接口，在此前提下为对象扩展功能，实现对象功能的扩展，避免子类膨胀。

facade：注重简化接口，屏蔽各子系统的复杂性，提供更高层接口供客户访问。

flyweight：注重保留接口，在内部使用共享技术对对象存储进行优化（通过共享大量细粒度对象，提供系统性能）。

proxy：注重假借接口，通过增加间接代理，实现更多控制，屏蔽复杂性。

3、行为型模式

templatemethod：封装算法结构，定义算法骨架，支持算法子步骤变化。

strategy：注重封装算法，支持算法的变化，通过封装一系列算法，从而可以随时独立于客户替换算法。

state：注重封装与状态相关的行为，支持状态的变化，通过封装对象状态，从而在其内部状态改变时改变它的行为。

memento：注重封装对象状态变化，支持状态保存、恢复。

mediator：注重封装对象间的交互，通过封装一系列对象之间的复杂交互，使他们不需要显式相互引用，实现解耦。

chainofresponsibility：注重封装对象责任，支持责任的变化，通过动态构建职责链，实现事务处理。

command：注重将请求封装为对象，支持请求的变化，通过将一组行为抽象为对象，实现行为请求者和行为实现者之间的解耦。

iterator：注重封装特定领域变化，支持集合的变化，屏蔽集合对象内部复杂结构，提供客户程序对它的透明遍历。

interpreter：注重封装特定领域变化，支持领域问题的频繁变化，将特定领域的问题表达为某种语法规则下的句子，然后构建一个解释器来解释这样的句子，从而达到解决问题的目的。

observer：注重封装对象通知，支持通信对象的变化，实现对象状态改变，通知依赖它的对象并更新。

visitor：注重封装对象操作变化，支持在运行时为类结构添加新的操作，在类层次结构中，在不改变各类的前提下定义作用于这些类实例的新的操作。

正确对待模式：

设计模式建立在对系统变化点的基础上进行，哪里有变化，哪里就应用设计模式。

设计模式应该以演化的方式来获得，系统的变化点往往是经过不断演化才能准确定位。

不能为了模式而模式，设计模式是一种软件设计的软力量，而非规范标准，不应夸大设计模式的作用。

设计模式心得体会（2）：

从一开始学习设计模式至今已半年有余了，第一次接触设计模式是一次不经意间在网上看到《大话设计模式》一书，看了前言了第一章后，就感觉到其诱惑力对于一个程序员来说，是无比巨大的。大概是去年十月份的时候，部门决定成立读书会，系统学习设计模式。

通过学习设计模式，除了学习到一些设计模式，还让我进一步熟悉、巩固了面向对象思想，进一步熟悉了c#语言。我曾多次设想，我们如果引入面向对象思想，并结合设计模式来重写或改善我们的系统（必须重写，虽说设计模式只是一种思想，语言只是实现而已，但是选择一门好的语言，无疑也是非常重要的，而vb6在面向对象方面却有很大欠缺甚至不具备其条件），那么我们的系统将会像目前一样需要那么多人来维护吗？

《大话设计模式》一书其实是对gof的《设计模式——可复用面向对象软件的基础》一书的翻译，让人更容易理解，用通俗易懂的语言阐述软件设计过程中的一些模式，在某种特定环境下，用最好的设计方法（代码高内聚，低耦合，使其有良好的可扩展性和可维护性）达到我们的目的，或许其方法有很多很多，但是寻找到最好的方法却不是件容易的事，设计模式是对前人的设计经验的一个总结，告诉我们在某种特定的环境下，这样的设计师最好的，学习设计模式有助于我们在设计软件的过程中少走很多弯路。

我对gof的xx个设计模式虽然都有看过，但是只有理解，实现，应用及思考之后，才能真正体会其精妙之处，至今体会较深的有以下几个模式：1strategy——封装系列算法，让它们之间可以相互替换，算法并不是单指数据结构中的算法，在实践中，它几乎可以封装任何类型的规则，这使得策略模式的运用极其广泛；2templatemethod——有人说是用的做多的模式，只要有抽象类的地方，都可以看到这个模式，它通过把不变行为移到父类中去，去除子类中的重复代码，从而提供了一个很好的代码复用平台；3facade——提供了对基础架构的统一访问，减少复杂性，在web编程者中的三层架构，就是此思想，每一层都封装好一部分功能，提供给上一层统一的方法调用，整个framework体系就是facade模式的封装，随着xx升级到xx，越来越多复杂的高级功能被封装，可以说facade无处不在；4abstractfactory——提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类，咋一看，太抽象了，说个例子，在三层架构中，bll层对dal层的调用会直接用到dal层中的类，如果dal层是分别对sqlserver，oracle的访问，bll层需要根据实际情况决定实例化哪一个dal层中的类，我们又希望在两种dal层切换时，bll层和ui层都不做改变，那么可在bll层和dal层中增加接口层（体现了抽象的精神，或者说是面向接口编程的最佳体现）和抽象工厂（dalfactroy），让它来实例化dal层中的实例；5singleton——确保一个类仅有一个实例，并提供一个访问它的全局访问点，如单件窗体，点一下menu，弹出一个窗体(实例)，在关闭这个新窗体之前，再次点击该menu，不会再次出现同样的弹出窗体(实例)。篇幅有限，其他模式或多或少都有点感觉。

最后，引用《设计模式解析》书中的一句话：设计模式体现的是一种思想，而思想是指导行为的一切，理解和掌握了设计模式，并不是说记住了xx种（或更多）设计场景和解决策略（实际上这也是很重要的一笔财富），实际接受的是一种思想的熏陶和洗礼，等这种思想融入到了你的思想中后，你就会不自觉地使用这种思想去进行你的设计和开发，这一切才是最重要的。

第二篇：设计模式初学心得

以前没有接触过设计模式，那其实也是因为以前没有真正经历过面向对象的设计。这样的情况在我经历了本科毕业设计，并且遵循我们实验室的一位师兄的建议看了《设计模式精解》（[美]alanshal(转载请注明来源：)loway&jamesrtrott著，熊节译）后有了根本的改变，我开始意识到一个程序员和一个设计者的区别，我也开始意识到在同学眼中“编程很强”的我只是——至少现在只是一个程序员。

我做的本科毕设是基于java-swing设计一个类似绘图程序的系统，最终我设计出来的程序，在别人看来很不错。但是只有我自己知道，我的设计其实是糟糕了，最明显的就是低内聚、紧耦合，那些代码甚至连我都不愿意去维护。于是当我看到书中的一句话：“几乎百分之百的软件都不是由它最初的设计者去维护的??”，更让我感到这次设计的失败（就连它的设计者都不原意去维护）。

《设计模式精解》的出现可以说让我眼前一亮，这也是第一本让我想再读一次的书（即使现在我还没有读完）。究竟什么是模式？书中的解释是“模式是针对特定场景下的特定问题的可重复、可表达的解决方案”，除此之外模式还必须有三个要点：

1．可重复性。解决方案应该对应于外部的场景。2．可传授性。一个解决方案应该可以移植到问题的不同情况中（绝大多数模式的可传授性都建立在“约束”和“效果”的基础上）。

3．用来表示这个模式的名称。

模式不限于面向对象，不限于设计阶段，甚至不限于软件开发领域。设计模式只是模式的一个子集。

在前言中作者说在他对现有的设计模式的指导原则及策略都非常清楚之后，这些原则帮助他决定开始过一种为人解惑的生活??虽然我第一次看到“为人解惑的生活”这个词语，但是我立刻感到这也是我所向往的一种生活。

书中介绍了软件开发过程中的三个不同视角：

1．概念视角。这个视角“展现了问题领域中的概念??一个概念模型可以在对实现软件有很少或毫无注意的情况下画出??”

2．规格视角。“只看软件的接口，而不看实现” 3．实现视角。就是现在的我唯一使用的视角——置身于代码之中。

看到这里我更加肯定了这本所讲的是我从来没有注意过的东西，但是我对这些东西应该非常感兴趣，而我也深深地感慨：我为什么现在才看到这本书。在书中作者回顾了它从前的一个设计，通过不断修改得出的优秀设计，逐步展现出设计模式的强大威力。书中有句话很经典——如果你只有一把锤子，那你会发现所有的东西都像钉子。意思是说如果你只知道一种解决问题的办法，那你只会想用这个方法解决所有问题。我觉得这很像现在的我，在面向对象的设计中我几乎只会“类继承”，结果是我的毕设——过高的继承体系导致紧耦合、低内聚。

当我学到书中介绍的第一个设计模式：facade模式，我立刻对这些设计模式产生了浓厚的兴趣，我发现自己像一个“完美主义者”，在试图追求结构完美的程序代码（可读性好、易于维护），而设计模式给我提供了这样的可能，尽管我仅仅看到了它的一点点部分。设计模式就像一个漂亮的女孩，而且你知道她不仅外表很漂亮，也很有内涵，那你想做的事情还有什么呢？当然是尽快接近并了解她?? 第三篇：设计模式之心得

刚学几天就有一些浅薄的心得了。

在学过的几种设计模式中（目前为止，本人只学过创建性模式），每一种设计模式都会有一种具体的应用场景，每一种场景描述的都是一种需求变化。设计模式就是用来解决这些变化的。只要客户有新的需求，你的程序就要发生改变，不管你用什么方法，这个改变是避免不了的。关键是你如何是解决这种变化！设计模式就是寻求一种通用的较好的方法来解决这种变化而不是避免这种变化，并不是你应用了设计模式，你的系统就不会发生变化了。

面向对象的编程有三大机制，我个人认为，设计模式很好的利用了其中的“封装与多态”（当然并不是所有的设计模式都是这样的，也不是说继承就没用，继承在三大机制排第一呀，是基本的），比如工厂方法模式和生成器模式。“封装”的意义不仅仅在于封装代码的实现，更重要的是“封装”系统中变化的部分。设计模式回答了怎么样去“封装”这种变化。

在一个系统中，总会有一部分经常发生变化，相对的，也总有一个部分是改变频率较低的，我们可以在某种范围内将其理解为不改变的部分。设计模式要作的事情就是把“变化”的部分封装起来，实现将“变化”的部分与“不变化”的部隔离，这样，“变化”的部分在发生变化时，不会影响到“不改变”的部分。如果你也学过设计模式，那你可能跟我有同感。设计模式解决变化的途径可以概括为两步（纯属个人见解）：一是转移变化，二是转化变化。

首先是“转移变化”。简单的说就是把a部分的变化转移到b部分，请b去变化，让a不发生变化。在程序中就是将变化从调用者转移到被调用者。比如，你有一个类scene，这个类用于显现一种风格的游戏场景，调用程序实例化这个类并使用它。如果有一天，需求改变了，当前风格的游戏场景颜色太冷了，我需要改变当前场景的颜色。这个时候你要决定，要让谁去发生变化？是让客户调用程序去改变scene类的颜色属性呢，还是让你的类scene发生变化？设计模式回答的是，请scene发生变化，调用者不发生变化。

为什么要这样回答，因为这个时候，你的系统可能已经交付用户了，如果让调用者发生变化，那整个系统都要发生变化。（这里讨论只是一个简单的应用，实际情况中往往没有这里简单。如果实际情况是这么简单的话，设计模式估计就没有用处了。）

然后是“转化变化”。

确定了要改动scene，那要怎么样去改scene呢？直接改吗？当然不行，如果是这样改，那还不如让调用者去设置scene的某个属性呢，反正都要重新部署。那要怎么改？“扩展”，把这种“改变”转化为“扩展”。你不是要另外一种

scene吗？那我重新为你设计一个sence并生成dll交付你，然后让现有的程序去调用这个scene。当然，这时可能需要调用者稍微的发生一下变化，比如开始调用者是直接调用scene来呈现场景的，现在将其改为根据配置文件来决定要呈现那种scene。但是如果之前你已经考虑到这个问题了，那调用者是不需要发生任何变化的，因为调用者是根据配置来决定所呈现的场景，需求发生弯化，只需要改变配置文件（可能是一个ｘｍｌ），把调用者与新添的scene关联即可，这样一来，“改动”就变为“扩展”，其带来的好处也是显而易见的，这也就是所谓的“开闭”原则。

以上文字完全是本人理解，随着不断的学习，我想这么文章估计要被改好多次，这是一个学习的过程。理解错了、写错了都不要紧，关键是你怎么样去面对这种错误！是拒绝承认错误还是正视错误？这也是设计模式回答的问题。

第四篇：洋思模式心得体会 洋思模式心得体会

从学习杜郎口到学习洋思已经好几年了，每年每学期都要进行大规模的听课活动，可谓轰轰烈烈，但学习了好几年时间，我心中仍然一塌糊涂，一知半解，难以灵活运用，尝试着运用时，也是提襟见肘，顾此失彼。所以成功的经验很少，只能有一点粗略的感受。我觉得目标设计尽量的要简洁明了，通俗易懂，要让绝大多数学生能够完成，如果太难或过于简单，都不利于学生的学习。目标设计应控制在1----3条为宜，如果目标太多，一节课根本无法完成，那就白设计了，从学生的角度来说，当看到很多的目标时，心中会产生恐惧和排斥情绪，不利于学习。

由于条件限制，当堂训练时只能采用课后练习和配套练习，缺少灵活性，对于在电子白板上做练习题，我总觉得效果不太好，因为一道题目看过后，印象不深，只有亲手做过，才能记忆深刻。

其它环节，我正在努力尝试、探索。第五篇：模式心得体会 教学模式心得体会

近几年，我们在校领导的带领下，实施了有本校特色的四大模块，八大环节的课堂教学模式。通过我们几年来的努力专研，现在，我们都可以很流畅的把我校的教学模式运用到我们的课堂教学中了，当然，在这几年的专研中，我也有了自己的体会，现在，我就谈谈我个人的一些看法。

一、改变旧观念，接受新模式 对于一个新的事物，需要通过不断地学习去了解它，新的教学模式也是这样。这学期，学校组织我们进行了多次学习，深入了解新模式的内涵、原则及实施细则，并组织我们通过数多次的教学研讨课，让我们真正了解这种模式的操作方法。不管是讲座还是听课教研，我都积极参加，积极与同行进行研究，认识到了新模式的确有助于培养学生自主学习的能力，有助于培养学生的合作意识，有助于学生学习能力的提高，有助于切实提高课堂效率。于是，我就积极在自己的课堂上进行尝试，努力实现学生主体、教师主导的高效课堂。

二、把课堂还给学生

每节课上，我都不断地提醒自己：“要放手，还给学生更多的学习时间。学生会的，教师不讲；学生能说出来的，教师不说；学生通过谈论能解决的，就让学生讨论解决。”有了这样的意识，课上，学生活动的机会多了，学生读书的时间有了，学生合作的机会有了，学生自主学习、独立解决问题的能力提高了。课上，我只挑关键性的问题、共性问题组织教学，充分发挥激励的作用，让学生尽情地

展示自己。这样，学生的学习热情高涨，谁都想表现自己，谁都想得到大家的认可，学习效果有了提高。

三、把课前的准备做充分

每节课的教学，都需要教师事先的精心准备。我们的教学模式更是如此，哪怕就是指导学生怎样预习。我刚开始带的学生第一次接触预习，学生不知道该怎样下手，所以，手把手地教给方法就显得尤为重要。我为了让学生学会预习，我不怕耽误课堂时间，亲自在课堂上对学生预习的每一步进行指导，比如，我告诉学生要通过自己拼读音标来学会读单词，要通过英汉互译来熟练掌握单词。我还要亲自在课堂上指导学生如何写预习笔记，如此反复，虽然学生的预习还是不能完全放手，但是，看到相当一部分学生已经开始自主地预习下一单元时，我还是感到很欣慰，毕竟小进步也比原地踏步强。

针对这几年的英语教学，我也有点自己的看法：

一、靠持续不断的语言知识，而不是“玩”来培养学生持久的兴趣初中英语教学是要重视培养兴趣，但单靠唱歌游戏不能培养学生持久的兴趣。新鲜劲儿一过，孩子们就会厌倦。所以，唱歌游戏应该作为初中学生学习英语语言知识、技能的一些手段，而不是培养兴趣的手段。我们可以采用多种手段帮助学生在记忆力强的时期多记单词，多学习语言规则，并尽可能多创造模仿的机会，提高学生的语音和语调。在英语学习中，听、说、读、写、译五种能力是可以互补的。真正做到听说先行，读写跟上。光听说不读写，很难收到高效。只靠模仿不培养学习能力，也难减轻学习负担。所以初中学生还是应

当认真进行语言学习。

二、英语应用能力需要相应的词汇。“不学习语言规则、不掌握相当数量的词汇，英语应用能力就是空中楼阁”。目前在中学的低年级的英语教学中，不要求学生掌握词汇，而只要求学生能根据提示或图片说出该单词，其本质无非是要学生们死记硬背，鹦鹉学舌。由于学生们没有相应的读音规则训练，不熟悉词汇的拼写规则，单词的音、形、意三者不能有效的结合在一起，因而导致了单词记忆的困难，并成了中学生学英语的瓶颈。

三、中学英语教师应有发展意识一向以来，人们中学英语教师的语言知识能力要求不高，认为中学英语简单，不需要太好的语言功底，只要有良好的教学技能就可以了。其实时代在进步，社会在发展，同样英语作为人们最广泛的交际用语之一，更是随着高科技的迅猛发展而日新月异地变化着。如果我们的英语教师故步自封，不求进取，那么不但自己的语言知识很快陈旧落伍，误人子弟，而且会被时代所淘汰。“changingenglishinthechangingworld”。现代英语的变化，特别是口语方面的变化可从以下几个方面体现出来：

1、随着人们生活节奏的不断加快，更因为国际互联网的形成，人们之间的交际变得越来越简捷。说话简单快捷，是现代人生活的一大特征。现代英语在这方面的变化表现为“一字多用”。

2、随着现代科学技术的迅猛发展，现代英语词汇急剧增加，并且我们发现，现代英语词汇有相当一部分是取得新义的旧词，如，“input”(输入电子计算机的数据)，“store”(电子计算机的储存器)，“drive”(计

算机驱动器)等。

3、英国英语和美国英语之间的距离越来越小。也许是美国对世界政治、经济影响日益强大的原因，美国英语的影响也越来越大，特别是对青少年的影响越来越大，他们以使用美语和发美国音为时髦。

当然，在实施新的教学模式的过程中我也有些困惑，譬如说学生由于作业量的增多而忽略了预习，导致课堂上不下去课的情况，我想，学校会为我们的教学模式的实施创造很好的条件的，相信在不久的将来，我们可以把教学模式变成我们自己的模式，在教学上更上一层楼