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 閱讀(554) | 評論 (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 閱讀(525) | 評論 (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 閱讀(126) | 評論 (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 閱讀(1553) | 評論 (0)編輯 收藏

          學英語怎樣才能事半功倍

          句子比單詞重要

            中國人學英語,最常用的方法是背單詞,甚至有人以能背出一本詞典為榮,但是詞典上的解釋是死的,語言的運用卻是活的,機械的理解會造成很大的誤解。詞典不是最重要的,關鍵在于語境。可以說,單詞沒有多少實際運用的價值,機械記憶的單詞量再大,也不會真正提高你的外語水平。要養成背誦句子的好習慣,因為句子中既包含了發音規則,又有語法內容,還能表明某個詞在具體語言環境中的特定含義。

            不要學“古董英語”。任何語言都是活的,每天都會發展,學習陳舊的語言毫無新鮮感,而且基本無處可用。不鮮活、不入時、不風趣幽默的語言不是我們要學的語言,多讀外文報紙、多看原版影視作品才會有助于補充新詞匯。

            很多人以為,把單詞拆成一個個字母背熟就可以正確地拼寫出來,其實,科學的方法是把讀音、拼寫和用法融為一體,同步進行,眼口手腦并用,并把它應用到句子里面去理解。

            聽不懂也要聽

            練習聽力時,許多人抱怨聽不懂,因而喪失了聽的樂趣,往往半途而廢。其實,即使聽不懂也是一種學習,只不過你自己覺察不到而已。雖然暫時聽不懂,但你的耳膜已經開始嘗試著適應一種新的語言發音,你的大腦在調整頻率,準備接受一種新的信息代碼,這本身就是一次飛躍。

            所以切記:聽不懂時,你也在進步。

            練習聽力,要充分利用心理學上的無意注意,只要一有時間,就要打開錄音機播放外語磁帶,使自己處于外語的語言環境中,也許你沒聽清楚說些什么,這不要緊,你可以隨便做其他事情,不用去有意聽,只要你的周圍有外語環境的發音,你的聽力就會提高。

            敢于開口

            學英語很重要的一點是用來和他人交流,但開口難也是中國人學英語的一大特點。問題出在以下幾點:

            一是有些人把是否看懂當成學習的標準。拿到一本口語教材,翻開幾頁一看,都看懂了,就認為太簡單了,對自己不合適。其實,練習口語的教材,內容肯定不會難,否則沒法操練。看懂不等于會說,把這些你已經學會的東西流利地表達出來,才是口語教材最主要的目標。

            二是千萬不要用漢字來記英語發音。學習一門外語如果發音不過關,始終不會真正掌握一門外語,而且最大的害處是不利于培養對外語的興趣,影響下一步學習。現在有人把用漢語發音標注英語,比如把“goodbye”記作“古得拜”,甚至把這種做法作為成果出版,這樣做肯定后患無窮。

            不敢開口的第三點是怕語法有錯。沒有具體問題,一般不要去讀語法書。超前學習語法,會使你如墜云里霧里,喪失學習外語的樂趣和信心。

            而且,語法好比游泳理論,對于沒有下過水的人來說,游泳理論是用處不大的。同樣,對于語言實踐不夠豐富的初學者,直接學習語法的用處不是很大。所以,一定要結合語言實踐來理解語法,語法是學會語言后的一種理論思考。學語言不存在對錯,只要能說出來,意思讓人家明白就可以了,不用費盡心機考慮用什么句型,只要能選準一個單詞就行。

            學口語最好的辦法,不是做習題,不是背誦,也不是看語法書,而是反復高聲朗讀課文,這種做法的目的是培養自己的語感,只有具備了語感,才能在做習題時不假思索、下意識地寫出正確答案。而且,當你熟練朗讀幾十篇課文后,很多常用句子會不自覺地脫口而出,所謂的“用外語思維階段”就會悄然而至。

            “盯住”一套教材

            現在市場上學英語的材料鋪天蓋地,這給了大家更多的選擇余地,但處理不好也會帶來不良后果———今天用這個教材、明天換另一種,學習便失去了系統性。正確的做法是選中一套教材,以它為主,其余材料都作為補充。

            還有,目前市面上不少考試材料都以“真題”為賣點,不少考生把希望寄托于做“真題”上,以為這樣就能通過考試。其實,很多正規的考試取材十分廣泛,經過了嚴格的難度論證,使用過的材料絕不可能二度使用。

            面對這樣的考試,僅僅以做題備戰顯然是治標不治本的做法,做題只能起到幫助考生了解題型的作用……對考生來說,語言能力的提高才是關鍵。

            不要頻繁更換學校不要盲目崇拜外語學院,這些學院確實有很長的歷史和經驗豐富的老師,但是有時也有局限性,教材陳舊、觀念陳舊、方法陳舊是他們的通病和致命缺點。

            學習英語沒有“速成”之說。學好英語也沒有捷徑,只有方法的好壞。

            比如記英語單詞,低著頭拼命默寫就不是一個好辦法。好的方法是大聲朗讀,反復訓練發音器官和耳朵,把聲音銘刻在腦子里。這樣既可以提高聽力,又可以改進口語發音,還記了單詞。默寫只是訓練了眼睛和手,可是它們不能替你聽和說。這就是好學校和普通學校的差別,好學校通過學習方法的訓練,能讓學員在最短的時間里得到提高,但這還是需要學員的付出和努力的。不要期望高學費能回報顯著的學習效果,付出比較高的學費并不意味著不要學習。

            更不要在急用英語的情形下,病急亂投醫,不管學校學習方法是否適合自己,先上著再說,等覺得不合適了再換。這對于孩子尤其不好———英語學習進行不下去,就停止或換班,不但會讓孩子學習英語的興趣磨沒了,而且,由于師資水平不一,孩子學到的是“夾生英語”,以后想要糾正過來都比較困難。所以,家長們選擇好、決定好可信任的教學思想、方法和師資之后,不要輕易換來換去,這樣只會給孩子的外語學習帶來適得其反的效果。

            尋找一個學習伙伴

            學習英語還要有較大的動力。每次你坐下來學習,無論在家里還是在語言中心,都需要短期動力集中精力讀和聽。但更需要長期動力,保證每天經常做這樣的事情———這是最難的。所以許多人開始學習英語,過一段時間很快就放棄了———我們學習英語不是一個持續的提高過程,而是通過一系列的突然提高以及間隔著似乎沒有變化的階段,這就是所謂“高原效應”。在幾個月的學習中,你都可能注意不到英語的巨大提高,在這些時候,學習者最容易失去長期的動力并放棄學習。

            避免“高原效應”的好辦法是,盡量不要完全一個人學習。如果你不能到語言中心學習,至少你應嘗試找一個“學習伙伴”,這樣,你們能夠互相鼓勵和支持。當然,如果能到一個好的語言中心學習就更不錯了。
           
           

          posted @ 2006-04-09 10:15 junhong 閱讀(610) | 評論 (0)編輯 收藏

          在鼠標旁動態顯示內容,用javascript寫的,并且可以在IE,firefox等瀏覽器中使用

          下載?

          showtip.JPG

          posted @ 2006-03-22 11:23 junhong 閱讀(1089) | 評論 (0)編輯 收藏

          本人寫的分頁的標簽,和.net中的datagrid標簽相似,只需要設置幾個屬性就可以實現分頁功能了

          本人寫的分頁的標簽,和.net中的datagrid標簽相似,只需要設置幾個屬性就可以實現分頁功能了,簡單方便,并且效率很高。
          我寫的有兩種分頁的標簽,一種是全部select 出來,然后再分頁的,這個系統在第一次訪問的時候可能有點慢,但是在隨后的訪問可是很快的,因為數據已經都緩存以來的,并且是在pageContext中的,所以不會占用很多的資源。第二種是部分select 出來的,效率很高。如果有需要的朋友,請留下Email地址。
          想要源代碼的朋友請和我聯系。
          大家可以把用的情況給我說一下,以便我做出調整。

          本程序作了升級,請大家下載下邊的這個連接進行下載,以便使用最新的版本。
          這次升級修復了幾個bugs.

          請下載Splitpage.rar
          testsplitpage.JPG

          posted @ 2006-03-07 09:04 junhong 閱讀(1611) | 評論 (32)編輯 收藏

          僅列出標題
          共2頁: 上一頁 1 2 
          主站蜘蛛池模板: 宁阳县| 大港区| 聊城市| 金乡县| 迁安市| 闽侯县| 尚义县| 特克斯县| 安徽省| 石城县| 瑞金市| 安图县| 肥西县| 奈曼旗| 阿克苏市| 隆德县| 惠州市| 镶黄旗| 剑阁县| 广灵县| 巴中市| 白沙| 汕尾市| 温宿县| 鄄城县| 蒲江县| 朔州市| 海丰县| 哈密市| 普兰店市| 九江县| 墨江| 东城区| 吉水县| 桐柏县| 临泉县| 五莲县| 海城市| 平遥县| 易门县| 梁河县|