junhong

#

Design Pattern with java (part three)

Specialized creation


  1. Prototype
    Objects are created by cloning a prototypical instance.
  2. Builder
    The goal of builder is to separate the construction from the “representation,” to allow multiple
    different representations. The construction process stays the same, but the resulting object
    has different possible representations. GoF points out that the main difference with Abstract
    Factory is that a Builder creates the object step-by-step, so the fact that the creation process is
    spread out in time seems to be important. In addition, it seems that the “director” gets a
    stream of pieces that it passes to the Builder, and each piece is used to perform one of the
    steps in the build process.
    One example given in GoF is that of a text format converter. The incoming format is RTF, and
    once it is parsed the directives are passed to the text converter, which may be implemented in
    different ways depending on whether the resulting format is ASCII, TeX, or a “GUI Text
    Widget.” Although the resulting “object” (the entire converted text file) is created over time, if
    you consider the conversion of each RTF directive to be an object, this feels to me a little more
    like Bridge, because the specific types of converters extend the interface of the base class.
    Also, the general solution to the problem would allow multiple readers on the “front end” and
    multiple converters on the “back end,” which is a primary characteristic of Bridge.
    To me, the fact that Builder has multiple steps in creating an object, and those steps are
    accessed externally to the Builder object, is the essence of what distinguishes it (structurally,
    anyway) from a regular factory. However, GoF emphasizes that you’re able to create different
    representations using the same process. They never define exactly what they mean by
    representation. (Does the “representation” involve an object that is too large? Would the need
    for Builder vanish if the representation was broken into smaller objects?)
    The other example in GoF creates a maze object and adds rooms within the maze and doors
    within the rooms. Thus it is a multistep process, but alas, the different “representations” are
    the “Standard” and “Complex” mazes – not really different kinds of mazes, but instead
    different complexity. I think I would have tried to create one maze builder that could handle

    arbitrarily complex mazes. The final variation of the maze builder is something that doesn’t
    create mazes at all, but instead counts the rooms in an existing maze.
    Neither the RTF converter nor the Mazebuilder example makes an overwhelmingly
    compelling case for Builder. Readers have suggested that the output of the Sax XML parser,
    and standard compiler parsers, might naturally be fed into a Builder.
    Here’s an example that may be a little more compelling, or at least give more of an idea of
    what Builder is trying to do. Media may be constructed into different representations, in this
    case books, magazines and web sites. The example argues that the steps involved are the
    same, and so can be abstracted into the director class.
    //: builder:BuildMedia.java
    // Example of the Builder pattern
    package builder;
    import java.util.*;
    import junit.framework.*;
    // Different "representations" of media:
    class Media extends ArrayList {}
    class Book extends Media {}
    class Magazine extends Media {}
    class WebSite extends Media {}
    // ... contain different kinds of media items:
    class MediaItem {
    private String s;
    public MediaItem(String s) { this.s = s; }
    public String toString() { return s; }
    }
    class Chapter extends MediaItem {
    public Chapter(String s) { super(s); }
    }
    class Article extends MediaItem {
    public Article(String s) { super(s); }
    }
    class WebItem extends MediaItem {
    public WebItem(String s) { super(s); }
    }
    // ... but use the same basic construction steps:
    class MediaBuilder {
    public void buildBase() {}
    public void addMediaItem(MediaItem item) {}
    public Media getFinishedMedia() { return null; }
    }
    class BookBuilder extends MediaBuilder {
    private Book b;
    public void buildBase() {
    System.out.println("Building book framework");
    b = new Book();
    }
    public void addMediaItem(MediaItem chapter) {
    System.out.println("Adding chapter " + chapter);
    b.add(chapter);
    }
    public Media getFinishedMedia() { return b; }
    }
    class MagazineBuilder extends MediaBuilder {

    private Magazine m;
    public void buildBase() {
    System.out.println("Building magazine framework");
    m = new Magazine();
    }
    public void addMediaItem(MediaItem article) {
    System.out.println("Adding article " + article);
    m.add(article);
    }
    public Media getFinishedMedia() { return m; }
    }
    class WebSiteBuilder extends MediaBuilder {
    private WebSite w;
    public void buildBase() {
    System.out.println("Building web site framework");
    w = new WebSite();
    }
    public void addMediaItem(MediaItem webItem) {
    System.out.println("Adding web item " + webItem);
    w.add(webItem);
    }
    public Media getFinishedMedia() { return w; }
    }
    class MediaDirector { // a.k.a. "Context"
    private MediaBuilder mb;
    public MediaDirector(MediaBuilder mb) {
    this.mb = mb; // Strategy-ish
    }
    public Media produceMedia(List input) {
    mb.buildBase();
    for(Iterator it = input.iterator(); it.hasNext();)
    mb.addMediaItem((MediaItem)it.next());
    return mb.getFinishedMedia();
    }
    };
    public class BuildMedia extends TestCase {
    private List input = Arrays.asList(new MediaItem[] {
    new MediaItem("item1"), new MediaItem("item2"),
    new MediaItem("item3"), new MediaItem("item4"),
    });
    public void testBook() {
    MediaDirector buildBook =
    new MediaDirector(new BookBuilder());
    Media book = buildBook.produceMedia(input);
    String result = "book: " + book;
    System.out.println(result);
    assertEquals(result,
    "book: [item1, item2, item3, item4]");
    }
    public void testMagazine() {
    MediaDirector buildMagazine =
    new MediaDirector(new MagazineBuilder());
    Media magazine = buildMagazine.produceMedia(input);
    String result = "magazine: " + magazine;
    System.out.println(result);
    assertEquals(result,
    "magazine: [item1, item2, item3, item4]");
    }

    public void testWebSite() {
    MediaDirector buildWebSite =
    new MediaDirector(new WebSiteBuilder());
    Media webSite = buildWebSite.produceMedia(input);
    String result = "web site: " + webSite;
    System.out.println(result);
    assertEquals(result,
    "web site: [item1, item2, item3, item4]");
    }
    public static void main(String[] args) {
    junit.textui.TestRunner.run(BuildMedia.class);
    }
    } ///:~

posted @ 2006-04-10 23:51 junhong 阅读(534) | 评论 (0)编辑 收藏

Design Pattern with java (part two)

Encapsulating creation


Although only the Simple Factory Method is a true singleton, you’ll find that each specify
factory class in the more general types of factories will only have a single instance.
  1. Simple Factory method
    One approach is to make the factory a static method of the base class:
    //: factory:shapefact1:ShapeFactory1.java
    // A simple static factory method.
    package factory.shapefact1;
    import java.util.*;
    import junit.framework.*;
    abstract class Shape {
    public abstract void draw();
    public abstract void erase();
    public static Shape factory(String type) {
    if(type.equals("Circle")) return new Circle();
    if(type.equals("Square")) return new Square();
    throw new RuntimeException(
    "Bad shape creation: " + type);
    }
    }
    class Circle extends Shape {Circle() {} // Package-access constructor
    public void draw() {
    System.out.println("Circle.draw");
    }
    public void erase() {
    System.out.println("Circle.erase");
    }
    }
    class Square extends Shape {
    Square() {} // Package-access constructor
    public void draw() {
    System.out.println("Square.draw");
    }
    public void erase() {
    System.out.println("Square.erase");
    }
    }
    public class ShapeFactory1 extends TestCase {
    String shlist[] = { "Circle", "Square",
    "Square", "Circle", "Circle", "Square" };
    List shapes = new ArrayList();
    public void test() {
    Iterator it = Arrays.asList(shlist).iterator();
    while(it.hasNext())
    shapes.add(Shape.factory((String)it.next()));
    it = shapes.iterator();
    while(it.hasNext()) {
    Shape s = (Shape)it.next();
    s.draw();
    s.erase();
    }
    }
    public static void main(String args[]) {
    junit.textui.TestRunner.run(ShapeFactory1.class);
    }
    } ///:~
    To encourage creation to only happen in the factory( ), the constructors for the specific
    types of Shape are give package access, so factory( ) has access to the constructors but they
    are not available outside the package.
  2. Polymorphic factories
    different types of factories can be subclassed from the basic factory,for example
    interface Shape {
    void draw();
    void erase();
    }
    abstract class ShapeFactory {
    protected abstract Shape create();
    private static Map factories = new HashMap();
    public static void
    addFactory(String id, ShapeFactory f) {
    factories.put(id, f);
    }
    // A Template Method:
    public static final
    Shape createShape(String id) {
    if(!factories.containsKey(id)) {
    try {
    // Load dynamically
    Class.forName("factory.shapefact2." + id);
    } catch(ClassNotFoundException e) {
    throw new RuntimeException(
    "Bad shape creation: " + id);
    }
    // See if it was put in:
    if(!factories.containsKey(id))
    throw new RuntimeException(
    "Bad shape creation: " + id);
    }
    return
    ((ShapeFactory)factories.get(id)).create();
    }
    }
    class Circle implements Shape {
    private Circle() {}
    public void draw() {
    System.out.println("Circle.draw");
    }
    public void erase() {
    System.out.println("Circle.erase");
    }
    private static class Factory
    extends ShapeFactory {
    protected Shape create() {
    return new Circle();
    }
    }
    static {
    ShapeFactory.addFactory(
    "Circle", new Factory());
    }
    }
    .......
  3. Abstract factories
    The Abstract Factory pattern looks like the factory objects we’ve seen previously, with not
    one but several factory methods. Each of the factory methods creates a different kind of
    object. The idea is that at the point of creation of the factory object, you decide how all the
    objects created by that factory will be used.
    As another example suppose you are creating a general-purpose gaming environment and you
    want to be able to support different types of games
    interface Obstacle {
    void action();
    }
    interface Player {
    void interactWith(Obstacle o);
    }
    class Kitty implements Player {
    public void interactWith(Obstacle ob) {
    System.out.print("Kitty has encountered a ");
    ob.action();
    }
    }
    class KungFuGuy implements Player {
    public void interactWith(Obstacle ob) {
    System.out.print("KungFuGuy now battles a ");
    ob.action();
    }
    }
    class Puzzle implements Obstacle {
    public void action() {
    System.out.println("Puzzle");
    }
    }
    class NastyWeapon implements Obstacle {
    public void action() {
    System.out.println("NastyWeapon");
    }
    }
    // The Abstract Factory:
    interface GameElementFactory {Player makePlayer();
    Obstacle makeObstacle();
    }
    // Concrete factories:
    class KittiesAndPuzzles
    implements GameElementFactory {
    public Player makePlayer() {
    return new Kitty();
    }
    public Obstacle makeObstacle() {
    return new Puzzle();
    }
    }
    class KillAndDismember
    implements GameElementFactory {
    public Player makePlayer() {
    return new KungFuGuy();
    }
    public Obstacle makeObstacle() {
    return new NastyWeapon();
    }
    }
    class GameEnvironment {
    private GameElementFactory gef;
    private Player p;
    private Obstacle ob;
    public GameEnvironment(
    GameElementFactory factory) {
    gef = factory;
    p = factory.makePlayer();
    ob = factory.makeObstacle();
    }
    public void play() { p.interactWith(ob); }
    }
    public class Games extends TestCase {
    GameElementFactory
    kp = new KittiesAndPuzzles(),
    kd = new KillAndDismember();
    GameEnvironment
    g1 = new GameEnvironment(kp),
    g2 = new GameEnvironment(kd);
    // These just ensure no exceptions are thrown:
    public void test1() { g1.play(); }
    public void test2() { g2.play(); }
    public static void main(String args[]) {
    junit.textui.TestRunner.run(Games.class);
    }
    } ///:~
    In this environment, Player objects interact with Obstacle objects, but there are different
    types of players and obstacles depending on what kind of game you’re playing. You determine
    the kind of game by choosing a particular GameElementFactory, and then the
    GameEnvironment controls the setup and play of the game. In this example, the setup and
    play is very simple, but those activities (the initial conditions and the state change) can
    determine much of the game’s outcome. Here, GameEnvironment is not designed to be
    inherited, although it could very possibly make sense to do that.

posted @ 2006-04-10 23:23 junhong 阅读(502) | 评论 (0)编辑 收藏

讨人喜欢的26个原则,让你的人际关系更上一层楼

1.长相不令人讨厌,如果长得不好,就让自己有才气;如果才气也没有,那就总是微笑。
   
   2.气质是关键。如果时尚学不好,宁愿纯朴。
   
   3.与人握手时,可多握一会儿。真诚是宝。
   
   4.不必什么都用“我”做主语。
   
   5.不要向朋友借钱。
   
   6.不要“逼”客人看你的家庭相册。
   
   7.与人打“的”时,请抢先坐在司机旁。
   
   8.坚持在背后说别人好话,别担心这好话传不到当事人耳朵里。
   
   9.有人在你面前说某人坏话时,你只微笑。
   
   10.自己开小车,不要特地停下来和一个骑自行车的同事打招呼。人家会以为你在炫耀。
   
   11.同事生病时,去探望他。很自然地坐在他病床上,回家再认真洗手。
   
   12.不要把过去的事全让人知道。
   
   13.尊重不喜欢你的人。
   
   14.对事不对人;或对事无情,对人要有情;或做人第一,做事其次。
   
   15.自我批评总能让人相信,自我表扬则不然。
   
   16.没有什么东西比围观者们更能提高你的保龄球的成绩了。所以,平常不要吝惜你的喝彩声。
   
   17.不要把别人的好,视为理所当然。要知道感恩。
   
   18.榕树上的“八哥”在讲,只讲不听,结果乱成一团。学会聆听。
   
   19.尊重传达室里的师傅及搞卫生的阿姨。
   
   20.说话的时候记得常用“我们”开头。
   
   21.为每一位上台唱歌的人鼓掌。
   
   22.有时要明知故问:你的钻戒很贵吧!有时,即使想问也不能问,比如:你多大了?
   
   23.话多必失,人多的场合少说话。
   
   24.把未出口的“不”改成:“这需要时间”、“我尽力”、“我不确定”、“当我决定后,会给你打电话”……
   
   25.不要期望所有人都喜欢你,那是不可能的,让大多数人喜欢就是成功的表现。
   
   26.当然,自己要喜欢自己。   
   
   ps:27.如果你在表演或者是讲演的时候,如果只要有一个人在听也要用心的继续下去,即使没有人喝采也要演,因为这是你成功的道路,是你成功的摇篮,你不要看的人成功,而是要你成功。
   
   28.如果你看到一个贴子还值得一看的话,那么你一定要回复,因为你的回复会给人继续前进的勇气,会给人很大的激励,同时也会让人感激你!

posted @ 2006-04-10 13:52 junhong 阅读(119) | 评论 (0)编辑 收藏

Design Pattern with java (part one)

  • Messager
    The most trivial of these is the messenger, which simply packages information into an object
    to be passed around, instead of passing all the pieces around separately. Note that without the
    messenger, the code for translate() would be much more confusing to read:
  • Collecting Parameter
    Messenger’s big brother is the collecting parameter, whose job is to capture information from
    the method to which it is passed. Generally, this is used when the collecting parameter is
    passed to multiple methods, so it’s like a bee collecting pollen.
    A container makes an especially useful collecting parameter, since it is already set up to
    dynamically add objects.
  • Object quantity:Singleton and object pool
    Singleton:The key to creating a singleton is to prevent the client programmer from having any way to
    create an object except the ways you provide. You must make all constructors private, and
    you must create at least one constructor to prevent the compiler from synthesizing a default
    constructor for you (which it will create using package access).
  • Object pool:If this is an issue, you can create a solution involving a check-out
    and check-in of the shared objects. see the following example
    //: singleton:PoolManager.java
    package singleton;
    import java.util.*;
    public class PoolManager {
    private static class PoolItem {
    boolean inUse = false;
    Object item;
    PoolItem(Object item) { this.item = item; }
    }
    private ArrayList items = new ArrayList();
    public void add(Object item) {
    items.add(new PoolItem(item));
    }
    static class EmptyPoolException extends Exception {}
    public Object get() throws EmptyPoolException {
    for(int i = 0; i < items.size(); i++) {
    PoolItem pitem = (PoolItem)items.get(i);
    if(pitem.inUse == false) {
    pitem.inUse = true;
    return pitem.item;
    }
    }
    // Fail early:
    throw new EmptyPoolException();
    // return null; // Delayed failure
    }
    public void release(Object item) {
    for(int i = 0; i < items.size(); i++) {
    PoolItem pitem = (PoolItem)items.get(i);
    if(item == pitem.item) {
    pitem.inUse = false;
    return;
    }
    }
    throw new RuntimeException(item + " not found");
    }
    } ///:~
    //: singleton:ConnectionPoolDemo.java
    package singleton;
    import junit.framework.*;
    interface Connection {
    Object get();
    void set(Object x);
    }
    class ConnectionImplementation implements Connection {
    public Object get() { return null; }
    public void set(Object s) {}
    }
    class ConnectionPool { // A singleton
    private static PoolManager pool = new PoolManager();
    public static void addConnections(int number) {
    17 z 157
    for(int i = 0; i < number; i++)
    pool.add(new ConnectionImplementation());
    }
    public static Connection getConnection()
    throws PoolManager.EmptyPoolException {
    return (Connection)pool.get();
    }
    public static void releaseConnection(Connection c) {
    pool.release(c);
    }
    }
    public class ConnectionPoolDemo extends TestCase {
    static {
    ConnectionPool.addConnections(5);
    }
    public void test() {
    Connection c = null;
    try {
    c = ConnectionPool.getConnection();
    } catch (PoolManager.EmptyPoolException e) {
    throw new RuntimeException(e);
    }
    c.set(new Object());
    c.get();
    ConnectionPool.releaseConnection(c);
    }
    public void test2() {
    Connection c = null;
    try {
    c = ConnectionPool.getConnection();
    } catch (PoolManager.EmptyPoolException e) {
    throw new RuntimeException(e);
    }
    c.set(new Object());
    c.get();
    ConnectionPool.releaseConnection(c);
    }
    public static void main(String args[]) {
    junit.textui.TestRunner.run(ConnectionPoolDemo.class);
    }
    } ///:~
  • Object decoupling:Both Proxy and State provide a surrogate class that you use in your code; the real class that
    does the work is hidden behind this surrogate class.When you call a method in the surrogate,
    it simply turns around and calls the method in the implementing class. These two patterns are
    so similar that the Proxy is simply a special case of State.

    The basic idea is simple: from a base class, the surrogate is derived along with the class or
    classes that provide the actual implementation:
    thinking in patterns with Java.bmp
    When a surrogate object is created, it is given an implementation to which to send all of the
    method calls.
    Structurally, the difference between Proxy and State is simple: a Proxy has only one
    implementation, while State has more than one. The application of the patterns is considered
    (in Design Patterns) to be distinct: Proxy is used to control access to its implementation,
    while State allows you to change the implementation dynamically. However, if you expand
    your notion of “controlling access to implementation” then the two fit neatly together.
  • State: changing object behavior
    The State pattern switches from one implementation to another during the lifetime of the
    surrogate, in order to produce different behavior from the same method call(s). It’s a way to
    improve the implementation of your code when you seem to be doing a lot of testing inside
    each of your methods before deciding what to do for that method. For example, the fairy tale
    of the frog-prince contains an object (the creature) that behaves differently depending on
    what state it’s in. You could implement this using a boolean that you test:
  • Factoring commonality
    Applying the “once and only once” principle produces the most basic
    pattern of putting code that changes into a method.
  • Strategy: choosing the algorithm at run-time
    Strategy also adds a “Context” which can be a surrogate class that controls the selection and
    use of the particular strategy object—just like State!
    thinking in patterns with Java.bmp
  • Policy: generalized strategy
    Although GoF says that Policy is just another name for strategy, their use of Strategy
    implicitly assumes a single method in the strategy object – that you’ve broken out your
    changing algorithm as a single piece of code.
    Others[6] use Policy to mean an object that has multiple methods that may vary
    independently from class to class. This gives more flexibility than being restricted to a single
    method.
    It also seems generally useful to distinguish Strategies with single methods from Policies with
    multiple methods
  • Template method
    An important characteristic of the Template Method is that it is defined in the base class and
    cannot be changed. It's sometimes a private method but it’s virtually always final. It calls
    other base-class methods (the ones you override) in order to do its job, but it is usually called
    only as part of an initialization process (and thus the client programmer isn’t necessarily able
    to call it directly).
    E.g
    abstract class ApplicationFramework {
    public ApplicationFramework() {
    templateMethod(); // Dangerous!
    }
    abstract void customize1();
    abstract void customize2();
    final void templateMethod() {
    for(int i = 0; i < 5; i++) {
    customize1();
    customize2();
    }
    }
    }
    // Create a new "application":
    class MyApp extends ApplicationFramework {
    void customize1() {
    System.out.print("Hello ");
    }
    void customize2() {
    System.out.println("World!");
    }
    }




posted @ 2006-04-09 17:15 junhong 阅读(1537) | 评论 (0)编辑 收藏

学英语怎样才能事半功倍

句子比单词重要

  中国人学英语,最常用的方法是背单词,甚至有人以能背出一本词典为荣,但是词典上的解释是死的,语言的运用却是活的,机械的理解会造成很大的误解。词典不是最重要的,关键在于语境。可以说,单词没有多少实际运用的价值,机械记忆的单词量再大,也不会真正提高你的外语水平。要养成背诵句子的好习惯,因为句子中既包含了发音规则,又有语法内容,还能表明某个词在具体语言环境中的特定含义。

  不要学“古董英语”。任何语言都是活的,每天都会发展,学习陈旧的语言毫无新鲜感,而且基本无处可用。不鲜活、不入时、不风趣幽默的语言不是我们要学的语言,多读外文报纸、多看原版影视作品才会有助于补充新词汇。

  很多人以为,把单词拆成一个个字母背熟就可以正确地拼写出来,其实,科学的方法是把读音、拼写和用法融为一体,同步进行,眼口手脑并用,并把它应用到句子里面去理解。

  听不懂也要听

  练习听力时,许多人抱怨听不懂,因而丧失了听的乐趣,往往半途而废。其实,即使听不懂也是一种学习,只不过你自己觉察不到而已。虽然暂时听不懂,但你的耳膜已经开始尝试着适应一种新的语言发音,你的大脑在调整频率,准备接受一种新的信息代码,这本身就是一次飞跃。

  所以切记:听不懂时,你也在进步。

  练习听力,要充分利用心理学上的无意注意,只要一有时间,就要打开录音机播放外语磁带,使自己处于外语的语言环境中,也许你没听清楚说些什么,这不要紧,你可以随便做其他事情,不用去有意听,只要你的周围有外语环境的发音,你的听力就会提高。

  敢于开口

  学英语很重要的一点是用来和他人交流,但开口难也是中国人学英语的一大特点。问题出在以下几点:

  一是有些人把是否看懂当成学习的标准。拿到一本口语教材,翻开几页一看,都看懂了,就认为太简单了,对自己不合适。其实,练习口语的教材,内容肯定不会难,否则没法操练。看懂不等于会说,把这些你已经学会的东西流利地表达出来,才是口语教材最主要的目标。

  二是千万不要用汉字来记英语发音。学习一门外语如果发音不过关,始终不会真正掌握一门外语,而且最大的害处是不利于培养对外语的兴趣,影响下一步学习。现在有人把用汉语发音标注英语,比如把“goodbye”记作“古得拜”,甚至把这种做法作为成果出版,这样做肯定后患无穷。

  不敢开口的第三点是怕语法有错。没有具体问题,一般不要去读语法书。超前学习语法,会使你如坠云里雾里,丧失学习外语的乐趣和信心。

  而且,语法好比游泳理论,对于没有下过水的人来说,游泳理论是用处不大的。同样,对于语言实践不够丰富的初学者,直接学习语法的用处不是很大。所以,一定要结合语言实践来理解语法,语法是学会语言后的一种理论思考。学语言不存在对错,只要能说出来,意思让人家明白就可以了,不用费尽心机考虑用什么句型,只要能选准一个单词就行。

  学口语最好的办法,不是做习题,不是背诵,也不是看语法书,而是反复高声朗读课文,这种做法的目的是培养自己的语感,只有具备了语感,才能在做习题时不假思索、下意识地写出正确答案。而且,当你熟练朗读几十篇课文后,很多常用句子会不自觉地脱口而出,所谓的“用外语思维阶段”就会悄然而至。

  “盯住”一套教材

  现在市场上学英语的材料铺天盖地,这给了大家更多的选择余地,但处理不好也会带来不良后果———今天用这个教材、明天换另一种,学习便失去了系统性。正确的做法是选中一套教材,以它为主,其余材料都作为补充。

  还有,目前市面上不少考试材料都以“真题”为卖点,不少考生把希望寄托于做“真题”上,以为这样就能通过考试。其实,很多正规的考试取材十分广泛,经过了严格的难度论证,使用过的材料绝不可能二度使用。

  面对这样的考试,仅仅以做题备战显然是治标不治本的做法,做题只能起到帮助考生了解题型的作用……对考生来说,语言能力的提高才是关键。

  不要频繁更换学校不要盲目崇拜外语学院,这些学院确实有很长的历史和经验丰富的老师,但是有时也有局限性,教材陈旧、观念陈旧、方法陈旧是他们的通病和致命缺点。

  学习英语没有“速成”之说。学好英语也没有捷径,只有方法的好坏。

  比如记英语单词,低着头拼命默写就不是一个好办法。好的方法是大声朗读,反复训练发音器官和耳朵,把声音铭刻在脑子里。这样既可以提高听力,又可以改进口语发音,还记了单词。默写只是训练了眼睛和手,可是它们不能替你听和说。这就是好学校和普通学校的差别,好学校通过学习方法的训练,能让学员在最短的时间里得到提高,但这还是需要学员的付出和努力的。不要期望高学费能回报显著的学习效果,付出比较高的学费并不意味着不要学习。

  更不要在急用英语的情形下,病急乱投医,不管学校学习方法是否适合自己,先上着再说,等觉得不合适了再换。这对于孩子尤其不好———英语学习进行不下去,就停止或换班,不但会让孩子学习英语的兴趣磨没了,而且,由于师资水平不一,孩子学到的是“夹生英语”,以后想要纠正过来都比较困难。所以,家长们选择好、决定好可信任的教学思想、方法和师资之后,不要轻易换来换去,这样只会给孩子的外语学习带来适得其反的效果。

  寻找一个学习伙伴

  学习英语还要有较大的动力。每次你坐下来学习,无论在家里还是在语言中心,都需要短期动力集中精力读和听。但更需要长期动力,保证每天经常做这样的事情———这是最难的。所以许多人开始学习英语,过一段时间很快就放弃了———我们学习英语不是一个持续的提高过程,而是通过一系列的突然提高以及间隔着似乎没有变化的阶段,这就是所谓“高原效应”。在几个月的学习中,你都可能注意不到英语的巨大提高,在这些时候,学习者最容易失去长期的动力并放弃学习。

  避免“高原效应”的好办法是,尽量不要完全一个人学习。如果你不能到语言中心学习,至少你应尝试找一个“学习伙伴”,这样,你们能够互相鼓励和支持。当然,如果能到一个好的语言中心学习就更不错了。
 
 

posted @ 2006-04-09 10:15 junhong 阅读(594) | 评论 (0)编辑 收藏

在鼠标旁动态显示内容,用javascript写的,并且可以在IE,firefox等浏览器中使用

下载 

showtip.JPG

posted @ 2006-03-22 11:23 junhong 阅读(1078) | 评论 (0)编辑 收藏

本人写的分页的标签,和.net中的datagrid标签相似,只需要设置几个属性就可以实现分页功能了

本人写的分页的标签,和.net中的datagrid标签相似,只需要设置几个属性就可以实现分页功能了,简单方便,并且效率很高。
我写的有两种分页的标签,一种是全部select 出来,然后再分页的,这个系统在第一次访问的时候可能有点慢,但是在随后的访问可是很快的,因为数据已经都缓存以来的,并且是在pageContext中的,所以不会占用很多的资源。第二种是部分select 出来的,效率很高。如果有需要的朋友,请留下Email地址。
想要源代码的朋友请和我联系。
大家可以把用的情况给我说一下,以便我做出调整。

本程序作了升级,请大家下载下边的这个连接进行下载,以便使用最新的版本。
这次升级修复了几个bugs.

请下载Splitpage.rar
testsplitpage.JPG

posted @ 2006-03-07 09:04 junhong 阅读(1564) | 评论 (32)编辑 收藏

仅列出标题
共2页: 上一页 1 2