设计模式之心得

时间:2019-05-13 03:42:41下载本文作者:会员上传
简介:写写帮文库小编为你整理了多篇相关的《设计模式之心得》,但愿对你工作学习有帮助,当然你在写写帮文库还可以找到更多《设计模式之心得》。

第一篇:设计模式之心得

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

在学过的几种设计模式中(目前为止,本人只学过创建性模式),每一种设计模式都会有一种具体的应用场景,每一种场景描述的都是一种需求变化。设计模式就是用来解决这些变化的。

只要客户有新的需求,你的程序就要发生改变,不管你用什么方法,这个改变是避免不了的。关键是你如何是解决这种变化!设计模式就是寻求一种通用的较好的方法来解决这种变化而不是避免这种变化,并不是你应用了设计模式,你的系统就不会发生变化了。

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

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

首先是“转移变化”。

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

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

然后是“转化变化”。

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

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

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

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

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

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

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

1.可重复性。解决方案应该对应于外部的场景。

2.可传授性。一个解决方案应该可以移植到问题的不同情况中(绝大多数模式的可传授性都建立在“约束”和“效果”的基础上)。

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

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

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

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

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

2.规格视角。“只看软件的接口,而不看实现”

3.实现视角。就是现在的我唯一使用的视角——置身于代码之中。

看到这里我更加肯定了这本所讲的是我从来没有注意过的东西,但是我对这些东西应该非常感兴趣,而我也深深地感慨:我为什么现在才看到这本书。

在书中作者回顾了它从前的一个设计,通过不断修改得出的优秀设计,逐步展现出设计模式的强大威力。书中有句话很经典——如果你只有一把锤子,那你会发现所有的东西都像钉子。意思是说如果你只知道一种解决问题的办法,那你只会想用这个方法解决所有问题。我觉得这很像现在的我,在面向对象的设计中我几乎只会“类继承”,结果是我的毕设——过高的继承体系导致紧耦合、低内聚。

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

第三篇:JAVA设计模式之创建模式

设计模式之Builder

Builder模式定义: 将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示.Builder模式是一步一步创建一个复杂的对象,它允许用户可以只通过指定复杂对象的类型和内容就可以构建它们.用户不知道内部的具体构建细节.Builder模式是非常类似抽象工厂模式,细微的区别大概只有在反复使用中才能体会到.为何使用?

是为了将构建复杂对象的过程和它的部件解耦.注意: 是解耦过程和部件.因为一个复杂的对象,不但有很多大量组成部分,如汽车,有很多部件:车轮 方向盘 发动机还有各种小零件等等,部件很多,但远不止这些,如何将这些部件装配成一辆汽车,这个装配过程也很复杂(需要很好的组装技术),Builder模式就是为了将部件和组装过程分开.如何使用?

首先假设一个复杂对象是由多个部件组成的,Builder模式是把复杂对象的创建和部件的创建分别开来,分别用Builder类和Director类来表示.首先,需要一个接口,它定义如何创建复杂对象的各个部件: public interface Builder {

//创建部件A 比如创建汽车车轮

void buildPartA();

//创建部件B 比如创建汽车方向盘

void buildPartB();

//创建部件C 比如创建汽车发动机

void buildPartC();

//返回最后组装成品结果(返回最后装配好的汽车)

//成品的组装过程不在这里进行,而是转移到下面的Director类中进行.//从而实现了解耦过程和部件

Product getResult();} 用Director构建最后的复杂对象,而在上面Builder接口中封装的是如何创建一个个部件(复杂对象是由这些部件组成的),也就是说Director的内容是如何将部件最后组装成成品: public class Director {

private Builder builder;

public Director(Builder builder){

this.builder = builder;} // 将部件partA partB partC最后组成复杂对象 //这里是将车轮 方向盘和发动机组装成汽车的过程 public void construct(){

builder.buildPartA();

builder.buildPartB();

builder.buildPartC();

} } Builder的具体实现ConcreteBuilder: 通过具体完成接口Builder来构建或装配产品的部件;定义并明确它所要创建的是什么具体东西;提供一个可以重新获取产品的接口: public class ConcreteBuilder implements Builder {

Part partA, partB, partC;public void buildPartA(){

//这里是具体如何构建partA的代码

};public void buildPartB(){

//这里是具体如何构建partB的代码 };public void buildPartC(){

//这里是具体如何构建partB的代码 };public Product getResult(){

//返回最后组装成品结果 };} 复杂对象:产品Product: public interface Product { } 复杂对象的部件: public interface Part { }

我们看看如何调用Builder模式: ConcreteBuilder builder = new ConcreteBuilder();Director director = new Director(builder);

director.construct();Product product = builder.getResult();Builder模式的应用

在Java实际使用中,我们经常用到“池”(Pool)的概念,当资源提供者无法提供足够的资源,并且这些资源需要被很多用户反复共享时,就需要使用池.“池”实际是一段内存,当池中有一些复杂的资源的“断肢”(比如数据库的连接池,也许有时一个连接会中断),如果循环再利用这些“断肢”,将提高内存使用效率,提高池的性能.修改Builder模式中Director类使之能诊断“断肢”断在哪个部件上,再修复这个部件.设计模式之Factory

定义:提供创建对象的接口.为何使用?

工厂模式是我们最常用的模式了,著名的Jive论坛 ,就大量使用了工厂模式,工厂模式在Java程序系统可以说是随处可见。

为什么工厂模式是如此常用?因为工厂模式就相当于创建实例对象的new,我们经常要根据类Class生成实例对象,如A a=new A()工厂模式也是用来创建实例对象的,所以以后new时就要多个心眼,是否可以考虑实用工厂模式,虽然这样做,可能多做一些工作,但会给你系统带来更大的可扩展性和尽量少的修改量。我们以类Sample为例,如果我们要创建Sample的实例对象: Sample sample=new Sample();可是,实际情况是,通常我们都要在创建sample实例时做点初始化的工作,比如赋值 查询数据库等。

首先,我们想到的是,可以使用Sample的构造函数,这样生成实例就写成: Sample sample=new Sample(参数);但是,如果创建sample实例时所做的初始化工作不是象赋值这样简单的事,可能是很长一段代码,如果也写入构造函数中,那你的代码很难看了(就需要Refactor重整)。为什么说代码很难看,初学者可能没有这种感觉,我们分析如下,初始化工作如果是很长一段代码,说明要做的工作很多,将很多工作装入一个方法中,相当于将很多鸡蛋放在一个篮子里,是很危险的,这也是有背于Java面向对象的原则,面向对象的封装(Encapsulation)和分派(Delegation)告诉我们,尽量将长的代码分派“切割”成每段,将每段再“封装”起来(减少段和段之间偶合联系性),这样,就会将风险分散,以后如果需要修改,只要更改每段,不会再发生牵一动百的事情。

在本例中,首先,我们需要将创建实例的工作与使用实例的工作分开, 也就是说,让创建实例所需要的大量初始化工作从Sample的构造函数中分离出去。

这时我们就需要Factory工厂模式来生成对象了,不能再用上面简单new Sample(参数)。还有,如果Sample有个继承如MySample, 按照面向接口编程,我们需要将Sample抽象成一个接口.现在Sample是接口,有两个子类MySample 和HisSample.我们要实例化他们时,如下: Sample mysample=new MySample();Sample hissample=new HisSample();随着项目的深入,Sample可能还会“生出很多儿子出来”, 那么我们要对这些儿子一个个实例化,更糟糕的是,可能还要对以前的代码进行修改:加入后来生出儿子的实例.这在传统程序中是无法避免的.但如果你一开始就有意识使用了工厂模式,这些麻烦就没有了.工厂方法

你会建立一个专门生产Sample实例的工厂: public class Factory{

public static Sample creator(int which){

//getClass 产生Sample 一般可使用动态类装载装入类。if(which==1)

return new SampleA();else if(which==2)

return new SampleB();

} } 那么在你的程序中,如果要实例化Sample时.就使用 Sample sampleA=Factory.creator(1);这样,在整个就不涉及到Sample的具体子类,达到封装效果,也就减少错误修改的机会,这个原理可以用很通俗的话来比喻:就是具体事情做得越多,越容易范错误.这每个做过具体工作的人都深有体会,相反,官做得越高,说出的话越抽象越笼统,范错误可能性就越少.好象我们从编程序中也能悟出人生道理?呵呵.使用工厂方法 要注意几个角色,首先你要定义产品接口,如上面的Sample,产品接口下有Sample接口的实现类,如SampleA,其次要有一个factory类,用来生成产品Sample,如下图,最右边是生产的对象Sample:

进一步稍微复杂一点,就是在工厂类上进行拓展,工厂类也有继承它的实现类concreteFactory了。抽象工厂

工厂模式中有: 工厂方法(Factory Method)抽象工厂(Abstract Factory).这两个模式区别在于需要创建对象的复杂程度上。如果我们创建对象的方法变得复杂了,如上面工厂方法中是创建一个对象Sample,如果我们还有新的产品接口Sample2.这里假设:Sample有两个concrete类SampleA和SamleB,而Sample2也有两个concrete类Sample2A和SampleB2 那么,我们就将上例中Factory变成抽象类,将共同部分封装在抽象类中,不同部分使用子类实现,下面就是将上例中的Factory拓展成抽象工厂: public abstract class Factory{

public abstract Sample creator();

public abstract Sample2 creator(String name);} public class SimpleFactory extends Factory{

public Sample creator(){

.........return new SampleA } public Sample2 creator(String name){

.........return new Sample2A } } public class BombFactory extends Factory{

public Sample creator(){

......return new SampleB } public Sample2 creator(String name){

......return new Sample2B } }

从上面看到两个工厂各自生产出一套Sample和Sample2,也许你会疑问,为什么我不可以使用两个工厂方法来分别生产Sample和Sample2? 抽象工厂还有另外一个关键要点,是因为 SimpleFactory内,生产Sample和生产Sample2的方法之间有一定联系,所以才要将这两个方法捆绑在一个类中,这个工厂类有其本身特征,也许制造过程是统一的,比如:制造工艺比较简单,所以名称叫SimpleFactory。在实际应用中,工厂方法用得比较多一些,而且是和动态类装入器组合在一起应用,举例

我们以Jive的ForumFactory为例,这个例子在前面的Singleton模式中我们讨论过,现在再讨论其工厂模式: public abstract class ForumFactory {

private static Object initLock = new Object();

private static String className = “com.jivesoftware.forum.database.DbForumFactory”;

private static ForumFactory factory = null;

public static ForumFactory getInstance(Authorization authorization){

//If no valid authorization passed in, return null.if(authorization == null){

return null;

}

//以下使用了Singleton 单态模式

if(factory == null){

synchronized(initLock){

if(factory == null){

......}

}

} try {

//动态转载类

Class c = Class.forName(className);

factory =(ForumFactory)c.newInstance();} catch(Exception e){

return null;}

//Now, 返回 proxy.用来限制授权对forum的访问

return new ForumFactoryProxy(authorization, factory,factory.getPermissions(authorization));

}

//真正创建forum的方法由继承forumfactory的子类去完成.public abstract Forum createForum(String name, String description)

throws UnauthorizedException, ForumAlreadyExistsException;

....}

因为现在的Jive是通过数据库系统存放论坛帖子等内容数据,如果希望更改为通过文件系统实现,这个工厂方法ForumFactory就提供了提供动态接口: private static String className = “com.jivesoftware.forum.database.DbForumFactory”;你可以使用自己开发的创建forum的方法代替com.jivesoftware.forum.database.DbForumFactory就可以.在上面的一段代码中一共用了三种模式,除了工厂模式外,还有Singleton单态模式,以及proxy模式,proxy模式主要用来授权用户对forum的访问,因为访问forum有两种人:一个是注册用户 一个是游客guest,那么那么相应的权限就不一样,而且这个权限是贯穿整个系统的,因此建立一个proxy,类似网关的概念,可以很好的达到这个效果.看看Java宠物店中的CatalogDAOFactory: public class CatalogDAOFactory {

/**

* 本方法制定一个特别的子类来实现DAO模式。

* 具体子类定义是在J2EE的部署描述器中。

*/

public static CatalogDAO getDAO()throws CatalogDAOSysException {

CatalogDAO catDao = null;

try {

InitialContext ic = new InitialContext();//动态装入CATALOG_DAO_CLASS //可以定义自己的CATALOG_DAO_CLASS,从而在无需变更太多代码 //的前提下,完成系统的巨大变更。

String className =(String)ic.lookup(JNDINames.CATALOG_DAO_CLASS);

catDao =(CatalogDAO)Class.forName(className).newInstance();

} catch(NamingException ne){

throw new CatalogDAOSysException(“

CatalogDAOFactory.getDAO: NamingException while

getting DAO type : n” + ne.getMessage());

} catch(Exception se){

throw new CatalogDAOSysException(“

CatalogDAOFactory.getDAO: Exception while getting

DAO type : n” + se.getMessage());

}

return catDao;

} } CatalogDAOFactory是典型的工厂方法,catDao是通过动态类装入器className获得CatalogDAOFactory具体实现子类,这个实现子类在Java宠物店是用来操作catalog数据库,用户可以根据数据库的类型不同,定制自己的具体实现子类,将自己的子类名给与CATALOG_DAO_CLASS变量就可以。

由此可见,工厂方法确实为系统结构提供了非常灵活强大的动态扩展机制,只要我们更换一下具体的工厂方法,系统其他地方无需一点变换,就有可能将系统功能进行改头换面的变化。

设计模式之Prototype(原型)

定义: 用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象.Prototype模式允许一个对象再创建另外一个可定制的对象,根本无需知道任何如何创建的细节,工作原理是:通过将一个原型对象传给那个要发动创建的对象,这个要发动创建的对象通过请求原型对象拷贝它们自己来实施创建。如何使用? 因为Java中的提供clone()方法来实现对象的克隆(具体了解clone()按这里),所以Prototype模式实现一下子变得很简单.以勺子为例:

public abstract class AbstractSpoon implements Cloneable {

String spoonName;

public void setSpoonName(String spoonName){this.spoonName = spoonName;}

public String getSpoonName(){return this.spoonName;}

public Object clone()

{

Object object = null;

try {

object = super.clone();

} catch(CloneNotSupportedException exception){

System.err.println(“AbstractSpoon is not Cloneable”);

}

return object;

} } 有两个具体实现(ConcretePrototype): public class SoupSpoon extends AbstractSpoon {

public SoupSpoon()

{

setSpoonName(“Soup Spoon”);

} } public class SaladSpoon extends AbstractSpoon {

public SaladSpoon()

{

setSpoonName(“Salad Spoon”);

} } 调用Prototype模式很简单: AbstractSpoon spoon = new SoupSpoon();AbstractSpoon spoon = new SaladSpoon();当然也可以结合工厂模式来创建AbstractSpoon实例。

在Java中Prototype模式变成clone()方法的使用,由于Java的纯洁的面向对象特性,使得在Java中使用设计模式变得很自然,两者已经几乎是浑然一体了。这反映在很多模式上,如Interator遍历模式。

设计模式之Singleton(单态)

定义: Singleton模式主要作用是保证在Java应用程序中,一个类Class只有一个实例存在。在很多操作中,比如建立目录 数据库连接都需要这样的单线程操作。

还有, singleton能够被状态化;这样,多个单态类在一起就可以作为一个状态仓库一样向外提供服务,比如,你要论坛中的帖子计数器,每次浏览一次需要计数,单态类能否保持住这个计数,并且能synchronize的安全自动加1,如果你要把这个数字永久保存到数据库,你可以在不修改单态接口的情况下方便的做到。

另外方面,Singleton也能够被无状态化。提供工具性质的功能,Singleton模式就为我们提供了这样实现的可能。使用Singleton的好处还在于可以节省内存,因为它限制了实例的个数,有利于Java垃圾回收(garbage collection)。

我们常常看到工厂模式中类装入器(class loader)中也用Singleton模式实现的,因为被装入的类实际也属于资源。如何使用?

一般Singleton模式通常有几种形式: public class Singleton {

private Singleton(){}

//在自己内部定义自己一个实例,是不是很奇怪?

//注意这是private 只供内部调用

private static Singleton instance = new Singleton();

}

第二种形式: public class Singleton {

private static Singleton instance = null;public static synchronized Singleton getInstance(){

//这个方法比上面有所改进,不用每次都进行生成对象,只是第一次

//使用时生成实例,提高了效率!if(instance==null)

instance=new Singleton();return instance;} //这里提供了一个供外部访问本class的静态方法,可以直接访问

public static Singleton getInstance(){

return instance;

} }

使用Singleton.getInstance()可以访问单态类。

上面第二中形式是lazy initialization,也就是说第一次调用时初始Singleton,以后就不用再生成了。

注意到lazy initialization形式中的synchronized,这个synchronized很重要,如果没有synchronized,那么使用getInstance()是有可能得到多个Singleton实例。关于lazy initialization的Singleton有很多涉及double-checked locking(DCL)的讨论,有兴趣者进一步研究。

一般认为第一种形式要更加安全些。使用Singleton注意事项:

有时在某些情况下,使用Singleton并不能达到Singleton的目的,如有多个Singleton对象同时被不同的类装入器装载;在EJB这样的分布式系统中使用也要注意这种情况,因为EJB是跨服务器,跨JVM的。

我们以SUN公司的宠物店源码(Pet Store 1.3.1)的ServiceLocator为例稍微分析一下:

在Pet Store中ServiceLocator有两种,一个是EJB目录下;一个是WEB目录下,我们检查这两个ServiceLocator会发现内容差不多,都是提供EJB的查询定位服务,可是为什么要分开呢?仔细研究对这两种ServiceLocator才发现区别:在WEB中的ServiceLocator的采取Singleton模式,ServiceLocator属于资源定位,理所当然应该使用Singleton模式。但是在EJB中,Singleton模式已经失去作用,所以ServiceLocator才分成两种,一种面向WEB服务的,一种是面向EJB服务的。

Singleton模式看起来简单,使用方法也很方便,但是真正用好,是非常不容易,需要对Java的类 线程 内存等概念有相当的了解。进一步深入可参考:

Double-checked locking and the Singleton pattern When is a singleton not a singleton?

第四篇:英语教学模式心得

英语教学模式心得

我校“以学导教,三精两清”的教学模式,三年的探索与总结,几近成熟,结合我们进行了三年课堂教学改革的课题,针对我校实际,英语组老师提出了“预习新知、展示交流、知识点拨、堂清反馈”创新模式。课改对学生的自信心也有了一定的提高,班级课堂活动参与率大大提升。许多之前不敢发言的同学在小组活动中,也能大胆的参与到课堂讨论学习中来,学生的学习兴趣和积极性得到了充分的提高。我们通过实践论证,一致认为:好的教学模式可以充分调动学生学习的积极性、充分发挥学生学习的自主性、探究性,有机地让学生的创造性思维在综合探究的学习过程中得到充分的展示,实践后和同行们进行了反复论证,并进行反思和总结。经过一段时间的实践,收到良好的教学效果。

我作为一名一线教师开始在教学中摸索尝试、使自己能进一步把理念和实践合二为一,下面就把我一些体会和方法和大家一起探讨一下。

(一)成功之处:

1、让课改悄悄走进学生的课堂,从而潜移默化地改变学生学习的方式。

首先,自从课题改革实施以来,我们改变了以往课堂上一成不变的教学模式,通过各种形式的教学环节改革,极大地调动了学生学习的积极性与主动性,激发了学生学习英语的自主性和兴趣。

当我们把“预习新知、展示交流、知识点拨、堂清反馈”这些任务交给学生来完成时,没想到收到了许多意想不到的惊喜。例如,以前的课前检查都是由老师亲自检查学生作业、练习的完成情况,于是有个别学生就会抄袭别人的作业,以应付检查。而现在我们在课前安排了“自主学习”这一环节,由小组长检查并帮助组内的“学困生”完成基础练习,这样以来,基本上能够杜绝抄袭,“学困生”在组长的帮助下主动完成不会的部分,并搞懂了不会的原因,这比起以前的抄袭就要有效得多。

课前热身时,采用每组抽一个学生上黑板展示单词或句子,而其他同学在老师听写时,大声站起来抢答的模式,对课前预习进行一个小小的汇报,并同时给予优胜者一颗红星奖励。通过这样的“自主学习展示”,也使得学生的学习完全是自愿的和积极主动的,而且具有强烈的自主学习的愿望,而且还养成了良好的课前预习的好习惯。学生的学习也就不再是被动的而是变得较为主动,可以尽情的展示他们自学的收获。往往是学生主动要求老师早上课,尽快检查他们准备好的表演和展示。而教师也可以通过学生的展示较为充分地了解学生的预习情况,并有针对性的进行预设,很好的使用教材。

其次是更多的关注了学生学习过程的情感态度价值观———停下来倾听学生的心声。在讲完了某一知识点后可以用更多的时间来让学生展示自己对学习内容的理解。如:展示交流、知识点拨等。通过学生的汇报,给他们提供了自我表达的空间与交流的平台,树立了他们学习英语的自信心,同时也检测了同学们对知识掌握的深与浅,便于及时调控课堂,及时关注学生学习的情况。“堂清反馈”则是学生对知识的整合,是对自己学习的检验、总结。他们的畅所欲言让学生有了充分展示自我的机会,给他们带来了学习的希望,让他们感受到了学习的快乐。

2.、课改走进了学生的课堂,也转变了教师的教学理念,使我们不断地改进了教学方法,激活了学生的自主思维,一切皆源于学生自愿的学习与努力。

首先,预习新知打破了以往循规蹈矩的听写与检查,它给学生以自由表达的愿望,通过学生自我小结式的汇报,激发了他们自主学习的愿望。教学时,教师设置课前任务:明确学习目标、生成本课题的重点、难点并初步达成学习目标。其基本过程是:学生根据自学后对课本内容的把握,教师根据对课程标准的把握,通过师生共同讨论,预设学习目标。然后,学生在通过自学、生生互动、师生互动等形式初步达成预设的目标,并对自己找出的重点、难点问题进行深入的探究,并在此基础上不断生成新的学习目标,为展示课做准备。学生提前搜集资料,整理资料,形成文字材料,上课时让学生展示劳动成果。通过设计任务,有助于学生扩宽英语视野,提升信息的判断能力和信息的运用能力。同时,课前准备由人物入手,有利于激发学生的学习热情和兴趣,对理解教材内容也很有帮助。如:对某个单词用法的认识,是通过他们的自主学习去完成的,他有了学习的愿望,就有兴趣去记忆它,分析它,辨别它。这样通过自己的认知再将自己的所获展示出来就有一种骄傲感和自豪感。诸如对短语的理解也是一样,对课文的朗读以及应用都是通过自愿的方式来完成学习的任务,所以说我们更多的是关注了学生的情感和态度。其次,利用情景教学模式,积极营造学生学习的英语情景,围绕教学目标,谴用词汇、图片、声音、动画、视频等不同形态的信息对所授教学内容和意境进行生动的再现,拓展学生视野。

通过精心编写 “情境营造” 和一个个由浅入深、力度大的问题设计,充分调动了学生的学习情绪,强化了学生不断进行探究的内在动机,让学生自主探索解决问题的方法与步骤,并建构知识体系。在学生展示后,针对每位学生的表现,作适当的点评;在学生探究问题过程中,及时给予相应的引导和启发,尤其是加强对学习方法的指导。

我校的堂清环节教师能从学情出发,从教育教学的规律出发,使教学内容、方法等符合学生的认知规律和特点,我觉的很好,但在实施一段时间中我发现堂清练习优秀生吃不饱后进生堂清不了,我计划今后在堂清环节中进行分层练习,在当堂训练环节中设置必做题、选做题、思考题3类题型。尖子生不仅要完成必做题,还必须完成选做题,最好能做思考题。这样让不同层次的学生都能在在课堂上全身心投入,积极地实践,认真地思考,让差的变好,让好的更好;用“成功更是成功之母”的思想来教育学生,从而让每位学生在自学、互助中发展,达到培优补差的目的。

(二)需要改进之处:

1、注意选择整合各种资料,恰当地加以实际运用。

通过教改我们发现,必须对教材和一些有用的信息进行进一步的整合,才能有效的加以利用,以方便实际操作运用。

2、注意课堂教学的调控,灵活把握课堂教学的进程。

在教学的实际过程中,有时因预设不足,可能会导致教学任务不能按计划完成,那么在运用时就应该酌情将教学内容中的一些训练型问题典型化,将其他的题目留待辅导课时再做处理,不要一味贪多,反而不能达到预期的教学目标。

3、加强对学生情感、态度、价值观的拓展和渗透。尽管素质教育一直是我们追求的教育目标,但在教改中,我个人认为更应该注重学生的情感、态度、价值观的拓展和渗透。在新的教育理念当中,首先应该做做人的教育,其次才是做事以及学习的教育。这一点至关重要。

4、充分发挥学生自身作用,使其认识自己和英语课堂的密切关系。总之,经过近一年来有计划、有目的的教学研究,我们对英语课堂的教学模式已经有了一定的认识,从中学到了不少行之有效的教学经验。当然,一切的革新都是建立在不断的学习和反思的基础上的,只有不断的反思并总结经验、改进不足,才能在有限的课堂教学时间内获取最大的教学效果,真正实现有效教学。

第五篇:学习小学英语教学设计之心得

学习小学英语教学设计之心得

小学英语课堂活动的设计就是英语教师根据正确的教学思想和英语教育原理,按照一定的教学思想和英语教育原理,按照一定的教学目的和要求,针对具体的教学对象和教材,对英语教学的整个程序、具体环节及有关曾面所作出的预期的行之有效的策划和设计。在学习《小学英语教学活动设计》这门课程时,自己做了很详细的笔记,特别是专家布置的作业,自己也是思考了很久才提交的,“功夫不负有心人”,花了近一个月时间完成的作业取得了理想的成绩,获得了“优秀”的等级。虽说在完成作业时确实花了不少时间和心思,但是在这个过程中自己也得到了很大的收获。

英语教学不仅是一门学科,也是一门艺术,形成英语教学艺术特色的重要因素之一就是教学设计(instructional planning)。古人说:“凡事预则立,不预则废。”强调无论做什么事都要预先谋划,事前设计。现代教学尤其注重设计,科学的教学设计,既是体现教育目的性、计划性、针对性和预习性所必需,又是顺利实施教学方案、调控教学过程的前提,也是确保教学效果、提高教学质量的保证。

英语教学设计就是英语教师根据正确的教学思想和英语教育原理,按照一定的教学目的和要求,针对具体的教学对象和教材,对英语教学的整个程序及其具体环节、总体结构及其有关层面所作出的预期的行之有效的策划。它是英语教师教育思想、思维流程和教学艺术的体现。众多的教学实践告诉我们,在学校教学条件有限的情况下,只要教师有心,同样可以进行朴素却生动的有效的教学设计;一个教师的基本功的精湛同样是成就教学精彩的基本元素,如清爽明了的简笔画和教师动听的歌喉也能使教学充满诗意,吸引孩子们的眼球并提升语言能力。

新课程的课堂是具体的,动态生成的,它不是教师完全预设的。所以,我们教师在进行小学英语教学设计时,应认真思考以下几个层面的问题:

观念层面:是否充分领会现代教育理念和现代教育技术的核心要素。内容层面:教学设计是否有明确的问题情景和学习路径。操作层面:是否将学习空间最大限度的留给学生。

综上所述,以“学生”为主体的教学设计应充分重视学习者的自主学习,教师在设计教学预案时,要学会主动把自己当成“鱼”,只有这样学会了“换位思考”,能够预想“鱼”的各种感受,才会在观念上和方法上得到自我提升,也才会真正创造出适合学生发展的教育活动。

在实际教学中,以下几点英语教学设计的技巧,或许对我们的教学有帮助,可以提高教学效率。

一、因材设计

所谓因材设计,就是能根据教材内容来设计教学环节,确立教学的重难点。在具体的教学过程中要始终围绕这个重点来安排教学活动,让活动的每一个环节既精彩又有实效。

二、因人设计

由于学生之间具有明显的差异性,底子不一,接受能力也不同。在设计教学活动时,教师必须潜心研究各个学生,设计出多层次的教学活动,让全体学生都能在原有的基础上学有所得、各展其长。

我觉得,在作业设计方面尤其应该考虑学生的实际,让作业适合不同层次学生的学习能力。第一层,设计面向成绩较差学生的基础题;第二层,设计面向全体学生的巩固题;第三层,设计面向“尖子生”的创新题。

三、因难设计

小学生学习英语最怕“难学”,而教师最担心“难教”。在“难”字解决之后,教学中的其他问题马上会迎刃而解。因此,在英语教学设计中,难点的处理尤为重要。处理得当,有事半功倍之效.以上简短的语言其实不足以全面概括教学设计的方方面面,要做到教学设计的科学,全面,还需要我们去多多的亲身实践

下载设计模式之心得word格式文档
下载设计模式之心得.doc
将本文档下载到自己电脑,方便修改和收藏,请勿使用迅雷等下载。
点此处下载文档

文档为doc格式


声明:本文内容由互联网用户自发贡献自行上传,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任。如果您发现有涉嫌版权的内容,欢迎发送邮件至:645879355@qq.com 进行举报,并提供相关证据,工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。

相关范文推荐

    市场运作模式之圆桌会议

    市场运作模式之圆桌会议 在市场运作的过程中,圆桌会议是一种在保证安全的情况下又行之有效的市场运作模式,目前广东团队已经运作的非常成功! 圆桌会议的表现形式: 第一种:一到两......

    惠之林模式

    在竞争中学习成长 广东中山大学EMBA硕士“雅丽洁模式”推广会议高级讲师 广西惠之林化妆品有限公司总经理 雅丽洁“百年名店”工程理事会常务副会长 中国化妆品商业领袖......

    设计模式心得体会

    设计模式心得体会 第一篇:设计模式 7月初的一个周末,准确的说应该是7月1号周六,在网上看到一本《大话设计模式》的书,而且看到很多很好的评论,于是乎,下载了电子书看看,一下子看了......

    设计模式小结

    -----摘自设计模式之禅 一、创建类模式: 包括工厂方法模式、建造者模式、抽象工厂模式、单例模式和原型模式,提供对象的创建和管理职能。 1、单例模式是要保持在内存中只有......

    教学设计模式

    教学设计模式——迪克-凯瑞模式 迪科-凯利(Dick & Carey)模式(如下图)是典型的基于行为主义的教学系统开发模式。该模式从确定教学目标开始,到终结性评价结束,组成一个完整的教学......

    教学设计模式大全

    浅谈教学设计模式 作者:谷利红 于媛来源:《学园》2013年第01期【摘 要】教学设计模式是教学设计理论向教学实践转化的桥梁。传统教学设计模式解决设计中“做什么”的问题,而以......

    教学设计模式[精选合集]

    模式比理论更具体,比实践更抽象,介于理论和实践之间,是一种比较简约的理论。教学设计模式是教学设计理论的一种简洁再现。比较典型的设计模式有科拉克的动态教学设计模式、肯普......

    特许加盟模式,设计

    如家特 许 酒店 加 盟 模 式 设 计 报 告 指导老师:吴红迪 制 作 者:尤思宁 黄春富 班 级:连锁3141/2 小组成员:张慢慢 尹莉 尤思宁 孙玉玉 黄春富 陈可 目录 一、如家酒店发展......