学习设计模式的一些感想

第一篇：学习设计模式的一些感想

设计模式在编程中的应用

我们在发现问题到解决问题这个过程中，常会发现很多问题是重复出现的，或是某个问题的变体，外在不同，而本质相同，建筑学上如是，软件行业也是，这些问题的本质就是模式。有人说，设计模式并不是一日两日能够理解的，当编程经验到了一定程度，便迫切的需要设计模式来完善自己的代码、优雅自己的设计，以及减少重复编码，这句话也是蛮有道理的，以自己的亲身经历来说，当刚开始编程时，没有一点设计理念，等到开设这门课以后再细读理解，把里面的思想带到自己的项目中，就会觉得有很多值得深思的地方。本文以我在以往项目中遇到的三个编码问题来谈谈学习设计模式的必要性。

一、代码量激增、程序可维护性面临挑战

我想这样的代码我们从学习C语言就开始接触，现在很多地方还在用，以后工作可能用的更多但是，大家都写的东西，我们自己的优势在哪里呢？

1.过多的if„else判断 if(type == 1){ //调用获取信息方法1 } else if(type == 2){ //调用获取信息方法2 „„.} else { //调用获取信息方法7 } 这是我在做一个项目中看到的一段代码，那个条件判断非常之长，有7个条件分支，而且其他有些地方也有根据类型来做不同处理的情况。

2.多次载入资源（例如配置文件的读取），引起资源损耗

public static String getProperty(String propKey)throws Exception...{ Properties prop = new Properties();InputStream propConfFile = Util.class.getClassLoader().getResourceAsStream(“configure.properties”);//载入propConfFile到prop中，从prop中获取propKey的值，并将其返回 }

该段代码是我以前在一个项目中写的一段代码，该段代码用于读取配置文件的属性，但该段代码是存在一些问题的，因为在每次获取属性时，它都重新载入资源，造成了资源的过多损耗。

3.过多依赖实现类

1）水果接口类—Fruit.java public interface Fruit { public void grow();}

2）水果的实现类—Apple.java、Strawberry.java //略

3）测试类—Test.java public class Test { public static void main(String[] args){ Fruit apple = new Apple();Fruit strawberry = new Strawberry();} } 在我们的项目中尚未采用Spring时，类似这样的程序很多，与实现类的过度耦合是这段代码存在的一个主要问题。

在我编码的过程中，遇到的问题还有很多。不够优雅的代码、过于僵硬的设计，等等，通过改进如上编码来认识学习设计模式给我们的编码带来的好处。

二、借“设计模式”之力冲出代码包围圈

如上的三段代码，都是存在不少问题的，让我们一一讨论，通过在其中应用设计模式，来优化我们的这三段代码，提高其扩展性和易维护性。

1.解决过多的if„else判断问题

如果在一段代码中，不少地方需根据某类型或状态等做出不同的处理，那当类型或状态增加时，这些代码将会过于僵硬，扩展性差，只有在各个分布了if„else的再增加一个else if，可维护性可想而知。设计模式中有一种模式可以解决该问题，即状态模式。状态模式给我们带来的好处如下：

1）状态模式需要对每一个对每一个系统可能取得的状态创立一个状态类（State）的子类，当系统的状态变化时，系统改变所选的子类。与一个特定的状态有关的行为都被包装在一个特定的对象里，而且当需要增加新的状态时，可以以子类的方式将它加到系统里，从而提高了易维护性和可扩展性；

2）由于每一个状态都被包装到了类里面，避免了使用过多的条件转移语句。

下面我们对该例进行演示性的改进。我们可以定义一个类型接口，该类相当于状态模式中的状态类。

public interface Type { /** * 获取信息 */ public Object getInfo();/** * 获取结果 */ public Object getResult();} 类型

1、类型2等可以实现该接口，代码略：

2.解决过度资源损耗问题

在该例中，每次通过getProperty(„)方法获取某属性时，都会重新载入文件中的所有内容，造成资源的不必要损耗。该设计模式中，对于此种情况，可以通过单例（Singleton）模式来优化处理。import //略

public class PropertiesUtil...{ private static Map propertiesMap = null;public static String getProperty(String propKey)throws Exception...{ if(propertiesMap == null)...{ //当propertiesMap为空时，载入文件，将其键值对放入propertiesMap中(略)} //在propertiesMap中获得propKey属性，并将值返回（略）} }

可以考虑实现单例模式的地方还有很多，例如：

1）对于计算机的外部资源打印机的情况，因只有一个Printer Spooler，为避免两个打印作业同时输出到打印机中，可考虑用单例模式实现。

2）Window的回收站在整个系统中只有唯一的一个实例，而且回收站自行提供自己的实例，回收站也是单例模式的应用

3、解决过多依赖实现类问题

在该例的测试类Test.java中，通过Fruit apple = new Apple();来获得对象，造成了程序过多的依赖实现类，与实现类过度耦合，学习设计模式后，我们可以考虑采用工厂模式来实现,可对代码进行如下改进：增加工厂类FruitGardener.java，该类的工厂方法如下： public static Fruit factory(String fruitType)...{ if(fruitType.equalsIgnoreCase(“apple”))...{ return new Apple();} else if(fruitType.equalsIgnoreCase(“strawberry”))...{ return new Strawberry();} else...{ return null;} }

增加了水果工厂类后，测试类也要做对应修改，修改后的Test.java的main方法如下： Fruit apple = FruitGardener.factory(“apple”);Fruit strawberry = FruitGardener.factory(“strawberry”);

在进行了对应修改后，测试类大大减少了对水果实现类的依赖，由直接new实现类变成了通过传入字符串来获得需要的实例，工厂模式应用很广泛，例如在现在红得似火的spring也在不少地方用了工厂模式，它本身就是一个很大的bean工厂，不过它在代码上进行了更大的改进，各实现类可以通过配置文件设置。

三、设计模式 –––– 由优秀迈向卓越的阶梯

从以上三个例子中我们可以看出，通过使用设计模式，优化了我们的代码。这样的例子在我们日常的编码过程中有很多，在我们刚开始学习编码时，写这样的代码还说得过去，但随着经验的增长，我们需要更进一步，现有的设计模式给我们提供了解决大多数问题的好方案，当然，在实践的过程中，我们甚至可以探索出新的设计模式，来解决遇到的某类问题。

学习设计模式不是一蹴而就的，很多人叹息设计模式似乎很不错，然而在自己的编码设计生涯中用得极少，我想主要原因是因为对设计模式的学习还不够，还没将其变成属于自己脑袋里的东西，所以当问题变着面孔出现时，认识不到问题的存在，因为不能正确的分析问题、认识问题，当然也不可能很好的解决问题。

还未学习过设计模式或对其知之甚少的程序员们，努力学习设计模式吧，那将使你由一个优秀的程序员(Coder)成为一个卓越的软件设计师(Developer)。

第二篇：分之合经营模式学习感想

分之合经营模式学习感想

3月14日到3月16日，我有幸参加了集团公司组织的分之合经营模式的学习培训，受益良多，分之合经营模式是一种非常科学的管理方式，接下来我想谈谈我个人的一些想法。

随着中国企业的规模化发展，企业管理变革成为新的课题，这种管理变革不是原有经营模式的简单叠加，而是一种员工活力的持续创造。那么如何创造这种活力呢？分之合模式的本质是将企业分割成众多小的组织体，各个组织体独立核算、独立经营，并培养具有经营意识的领导人，让全体员工参与到企业经营中，实行类似家庭账本式管理，是一种团结的经营模式，全体员工共同经营。

首先，划分分之合经营单元规模大小的原则主要是每个组织体必须能独立完成任务，有独立的核算组织，同时，又不能因为组织的拆分影响公司的整体目标和经营计划。划分的决策权力在于其直接的上级管理者，只要管理者认为有必要且该团体满足成为组织体的条件就可以进行划分。把原本属于企业的事，变成每个部门每个人的事情，大大激发全员的潜能。

其次，企业的利润是来源于生产经营的各个部门、各个环节。各部门独立经营、独立核算的经营管理模式，就像土地改革将集体生产与管理模式变成了承包到户生产管理模式，产量、质量、积极性会大幅度提高；而成本、费用、浪费会大幅度降低。让每个员工找到了当老板的感觉，实现企业每个人为自己干、为自己经营与管理。

最后，通过推行分之合经营，能够使老板在与不在一个样，各级管理者在与不在一个样，大家都在认真、埋头自己的工作，忙而不乱，老板们一直期望的理想管理模式真正变成了现实。现在如果工作达不到日清日毕，大家会主动愉快的偷着加班。所以说分之合经营模式是从骨髓里给管理者和员工注入了疯狂为自己工作的基因。经营企业最终是经营人才，经营人才的核心是经营人心，当企业规模扩大，员工人数增加，员工的思想统一是企业能够产生合力的基础。分之合经营模式虽然是将企业划分成很多小经营单元，但是这些小单元不是各自为政，而是有着统一思想的同心力。它可以充分发挥企业管理的两种力量：无形力量——企业文化；有形力量——自主经营，实现员工群策群力，上下同欲，并发挥每个员工的积极性和创造性。

要真正认知和实现分之合管理还需要很多工作去做，毕竟现在的管理模式较分之合还存在较大的差距。必须要让全体的员工认识这种管理模式的好处，让全体自动自发的进行改革和探索，逐渐排除职工的抵触情绪。为此我部门计划完成以下相关的工作：

一、组织本部门员工对分之合经营模式进行系统的学习，加深对分之合经营模式的了解；

根据集团公司要求，在3月31日前完成全员学习分之合管理模式文字版本和视频内容的学习，全员贯彻分之合的管理理念，利用部门例会时间对学习的效果进行随机的抽查提问。

二、根据分之合管理模式对本部门人员及岗位设置情况进行重新划分，现场巡检及资料管理区分，明确个人工作职责，后续制定相应的考核。

三、对办公室进行整理、整顿，对现场3s落实情况进行监督； 更换办公室后，对办公室物品摆放进行定位，有用的物品分类放到指定位置，闲置的退回仓库，根据实际情况将办公室布置用图表的形式表达出来，为实现目视化管理奠定基础，日常巡检中对现场区域卫生、设备等清扫情况进行监督检查。

分之合管理模式对多数人来说是一个全新的管理模式，改变需要有一个过程，并且现阶段对于分之合流程内的好多概念还很模糊，真正实现起来还有一定的难度。但我们有信心在集团公司的指导下，在化工各部门的配合下，通过部门协作和配合将分之合经营管理落实到实处，为集团公司实现分之合管理做好基础和铺垫。

第三篇：设计构成 学习感想

设计构成一转眼间，设计构成的课已经结束了。平面构成，色彩构成，立体构成，三大构成已经都学完了。

在学习习近平面构成的过程中，知道了构成平面的元素是点。线。面。重复，近似，渐变，发射，突变，集结，对比是基本的构成形式。每一个都做了相应的练习，更加深刻了解了每一个形式。重复

骨骼与基本形都具有重复性质的构成形式，称为重复构成。在这种构成中，组成骨骼的线都必须是相等比例的重复组成。骨骼线可以有方向和宽窄等变动，但必须是等比例的重复。对基本形的要求，可以在骨骼内重复排列，也可以有方向、位置的变动

近似

骨骼与基本形变化不大的构成形式，称为近似构成。近似构成的骨骼可以是重复或是分条错开的，但近似主要是以基本形的近似变化来体现的。

渐变

骨骼与基本形具有渐次变化性质的构成形式，称为渐变构成。渐变构成有两种形式，一种是骨骼渐变，通过变动骨骼的疏密比例取得渐变效果；另一种是基本形渐变，通过基本形的有规律的变动(如方向、大小和位置等变动)而取得渐变效果

发射

骨骼线和基本形呈发射状的构成形式，称为发射构成。这种类型的构成是骨骼线和基本形用离心式、向心式、同心式及其他几种发射形式相叠而成的。

突变

在重复、渐变等规律性骨骼或基本形中一种特异变化的构成形式称为突变构成，这种构成是有意识地在规律性变化中出现轻微的差异或是局部的突破，而产生几个不规则的变异，但又大致保持某种规律。密集

密集构成是比较自由性的构成形式，包括预置形密集与无定形密集两种。

预置形密集是依靠在画面上预先安置的骨骼线或中心点组织基本形的密集与扩散，即以数量相当多的基本形在某些地方密集起来，而从密集地又逐渐散开来。

无定形的密集不预置点与线，而是靠画面的均衡。即通过密集基本形与空间、虚实等产生的轻度对比进行构成。

对比

有一种较之密集构成更为自由性的构成称为对比构成，这种构成不以骨骼线而仅依靠基本形的形状、大小、方向、位置和色彩等的对比，以及重心、空间、有与无、虚与实的关系元素的对比，给人以强烈且鲜明的感觉。

接下来学习了立体构成。立体构成是一门研究在三维空间中如何将立体造型要素按照一定的原则组合成赋予个性的美的立体形态的学科。

整个立体构成的过程是一个分割到组合或组合到分割的过程。任何形态可以还原到点、线、面，而点、线、面又可以组合成任何形态。

立体构成的探求包括对材料形、色、质等心理效能的探求和材料强度的探求，加工工艺等物理效能的探求这样几个方面。

立体构成是对实际的空间和形体之间的关系进行研究和探讨的过程。

半立体是以平面为基础将其部份空间立体化，是介于平面与立体之间的形状，即一般所称的“浮雕”。半立体的主要特性表现在凹凸的层次感和光影的效果上，它足以使单调的平面产生各种不同的变化。

半立体是在有限的空间(浅浮雕)中充分发挥想像力，强调层次感和多种手法及技巧，用折、曲、切、接、编等技巧尽可能地创造出变化的立体形态。

练习了点线面的立构体形式，运用了泡沫，钢丝，木头，毛线等工具，做了立体作业。

立体构成教学是设计的专业基础课程，它是立足于对立体造型可能性的探索，而完全不考虑造型的功能等因素．旨在讨论、研究立体造型的原理、规律和构造训练。立体构成的学习、训练不是目的，而是提高、完善现代设计能力的重要手段。对某些立体造型设计的内容做些简单的介绍和分析．从而进一步了解立体构成在各类设计中的运用，加强认识立体构成学习的重要性。

设计是包括立体构成在内、并考虑其它众多要素，使之成为完整造型的活动。设计的领域非常广泛，它可分为商业设计、工业设计、环境艺术设计等门类，而这些艺术门类还可以细分为广告设计、书籍设计、包装设计、广告设计、展示设计、服装设计、染织设计、室内外环境设计等专业门类。

立体构成与设计是有区别的。立体构成研究的内容是将涉及到各个艺术门类之间的、相互关联的立体因素，从整个设计领域中抽取出来，专门研究它的视觉效果构成和造型特点，从而做到科学、系统、全面地掌握立体形态。

立体构成与具体的艺术门类区别很大，在整个立体构成的训练过程中没有具体目的的条件限制（如专为某一种产品设计造型）。因此，每一项练习就必须从立体造型的角度去研究形态的可能性和变化性。

立体构成能为设计提供广泛的发展基础。立体构成的构思不是完全依赖于设计师的灵感，而是把灵感和严密的逻辑思维结合起来，通过逻辑推理的办法，并结合美学、工艺、材料等因素，确定最后方案。立体构成可以为设计积累大量的素材。立体构成的目的在于培养造型的感觉能力、想象能力和构成能力，在基础训练阶段，创造出来的作品可成为今后设计的丰富素材。立体构成是包括技术、材料在内的综合训练，在立体的构成过程中，必须结合技术和材料来考虑造型的可能性。因此，作为设计者来讲，不仅要掌握立体造型规律，而且还必须了解或掌握技术、材料等方面的知识和技能。

人们生活在各种三维的形态环境中，从日常使用的各种物品，到所居住的环境，乃至人类自身和整个宇宙，无一不是三维形态。因此，与二维空间相比，三维空间与人类更加息息相关。人们虽然生活在三维形态中，但常常习惯于从平面的角度去思考、在平面上表现造型，无形中具有平面的造型观念和意识。因此，从平面到立体，从二维到三维必须要有立体的空间意识和观念，掌握三维造型的基本原理和知识。

作为艺术设计基础之一的立体构成，就是培养人的空间想象能力和意识，研究和探讨在三维空间中如何用立体造型要素和语言，按照形式美的原理创造出富有个性和审美价值的立体空间形态的学科。通过对立体形态进行科学、系统的分析和研究，掌握立体造型的基础知识和表现手法，从而创造出新的艺术形态。

立体构成由于自身的构成性，因而具有极强的理性特征，并运用分解与组合的方法予以体现。所谓分解就是将一个完整的造型对象分解为若干个基本造型要素，实际上是将形态还原到最原始的基本状态；而组合则是直接将最基本的造型要素按照立体造型原理重新组合成新的形态的设计。

第四篇：哪些设计模式最值得学习

回想起来，这几年在园子里发布的有关设计模式的随笔都有一个共同的特点。那就是

Factory和Singleton居多，如果是系列的，也往往是从这两个模式开始的。由于能够坚持把《设计模式》中所有模式都写完的非常少，所以基本上也很少见到有关其它模式的随笔。这种情况也很好理解，因为《设计模式》这本书就是按照这个顺序来的。最先讲述的就是Abstract Factory模式，于是它排第一也无可厚非；排第二的Builder基本不太容易见到；第三的Factory Method由于也叫“Factory”所以往往和Abstract Factory放在一起，或者干脆就混淆了； 第四的Prototype也不是太容易见到；第五位的Singleton简单易懂，易学易用。而再往后的模式，恐怕作者们就没什么耐心学下去了……这可能就是为什么Factory和Singleton出现频率如此之多的原因吧。

《设计模式》已经出版超过15年了，到今天已经不是什么新鲜的东西了，可以说正在由“绝招”慢慢向着“基本功”转变着。然而，这种学习模式的方式方法却实在令人担忧。Abstract Factory在实际中并不常见，因为它需要你有两套并行的继承体系，需要对同一个抽象有多于一种的实现方式。这种复杂的系统可以说不是每个领域，每个开发人员都能遇到的。在某些特定的领域可能很常见，但是在大多数领域并不需要这么复杂的对象创建方法。这就造成了很多人“杀鸡用宰牛刀”，用复杂的方式，解决不那么复杂的问题。后果是增加了不必要的复杂度，给系统维护增加了困难。

另一个模式Singleton，由于实现简单，意图“似乎”也很明显。被很多人用来作为“优化”的一种方式。通过这种方式来节省内存空间，减少对象实例。但是单一实例本身就等同于全局变量，而全局变量在几十年前就已经被证明是“反模式”了，用另一种形态的全局变量来代替另一种形态的全局变量有什么好处么？问题在与，Singleton的“意图”并不在于优化，而是在于“妥协”。Singleton的目的在于保证对象有单一的实例，这是因为对象必须要有单一的实例，如果存在多个实例，可能会引发错误。也就是说，Singleton以牺牲程序的清晰

和可维护性，来达到保证程序正确的目的。这跟本就和优化八竿子打不着，这完全是一种设计上的妥协，牺牲一些好处来获取更大的好处。如果仅仅是为了节省几个对象实例，而非程序的正确才使用Singleton，那就是丢了西瓜拣芝麻。况且节省那几个实例也跟本就不可能对程序的性能有太大的影响（特殊领域除外）。

人的时间是有限的，23个模式也不是都那么常用，哪些模式才是最经常用到的，才是最值得学习的呢？

第一梯队：Iterator，Observer，Template Method，Strategy

Iterator：LINQ，foreach这不都是Iterator么。

Observer：MVC的核心，.NET中事件就是Observer。

Strategy：对同一个行为有不同实现的时候，如果考虑将行为的实现委托（不是.NET中的委托）给另一个类，那就用到了Strategy。通过这种方式，可以简单的替换算法的实现类，来达到更换算法的目的。

class Foo

{

private IBar bar;

public Foo(IBar bar)

{

this.bar = bar;

}

public void DoSomething()

{

//some code

bar.DoWhatYouWant();

//some code

}

}

class A : IBar

{

public void DoWhatYouWant()

{

//do in A's way

}

}

class B : IBar

{

public void DoWhatYouWant()

{

//do in B's way

}

}

Template Method：一个算法的同一个步骤有不同的实现，通过继承来实现。这种方式通过创建子类来改变算法的实现和行为。ASP.NET WebForm中Page的OnInit，OnLoad等事件，就是Template Method。

class Foo

{

public void DoSomething()

{

//some code

DoWhatYouWant();

//some code

}

protected abstract void DoWhatYouWant();

}

class A: Foo

{

protected override void DoWhatYouWant();

{

//do in A's way

}

}

class B: Foo

{

protected override void DoWhatYouWant();

{

//do in B's way

}

}

面向对象的一个重要特点就是多态，也就是对于同一个动作有不同的行为。Strategry通过委托的方式，将一个算法的不同实现委托给其它类；Template Method通过继承的方式，让子类实现算法的可变部分，基类则处理算法的流程和不变部分。近年来组合优于继承的观点已经成为主流，因此Strategy的处境频率相对高一些，但是Template Method在解决简单问题的时候更好用，只要注意继承层次不要太多（<=3）就好。

第二梯队：Adapter，Facade，Decorator

Adapter：当你需要使用第三方库，但是又不想太依赖于它的API，以便于今后在需要时可以方便的切换到另一个库的时候，你就需要在你的代码和第三方API之间放置一个抽象层，也就需要用Adapter模式了。比如你想使用log4net，如果直接在代码中到处引用log4net的API，将来有一天需要切换到另一个库比如EntLib，你的改动量可就大了去了。如果在一开始就自己设计一个API，在代码中使用自己的API，再用Adapter模式将log4net的API包装到自己的API中，如果有一天想要切换到Entlib，只要为EntLib在写一个Adapter就行了。对于IoC框架也是一样的。不过需要注意的是，如果第三方库的API接口非常庞大，使用Adapter就会很麻烦，因为你需要包装太多的东西，那么使用Adapter可能就不是一个太好的主意。或许谨慎考虑确定一个不太可能会变化的第三方库更好一些。

Facade：基本上用于简化API，隐藏细节，在一个系统中，高层模块调用低层模块时，如果低层模块API比较复杂，而高层模块并不需要这种复杂度，那么加一个Facade，可以简化高层模块使用API的难度。

Decorator：为一个类的行为增加行为，比如ASP.NET MVC中的Action Filter。第三梯队：Command，State，Composite

Command：统一接口，Undo/Redo。

State：当你的model有多种状态，model的行为在每种状态下并不一样的时候，就需要用State。如果你有多个相似的Switch，那也可能意味着需要用State来代替Switch。

Composite：ASP.NET WebForm的Page和Control就是一个例子。

这些模式和分类只是凭我的感觉，并没有任何实际的数据做支持，而我的感觉也只来源于我所接触到的领域和代码。希望同学们也可以提供自己接触到的代码中，最常见到和用到的模式。

第五篇：JAVA学习书籍- 设计模式

谈到设计模式很多人多会推荐GOF 的那本，该书在Amzon上是五星级的推荐书籍。不过对于学习java 没多久的、特别是java 初学者，我很不推荐这本书。主要是该书的例子基本都是C++的，很多细节没有讲述得足够清楚。

我给大家推荐的第一本是阎宏博士的《Java 与模式》，它是第一本中国人自己写的关于设计模式的书籍，写的比较有趣，融合了很多中

华民族的文化和观念，例子、类图都比较多，且相对简单！非常不错的入门书籍――又是大块头哦！

其次我推荐Wiley 出版社出版的《Pattern In Java》一套三本，我才看了第一本，好像第二本不怎么样，第三本还不错！

第三本是中文翻译版的关于多线程模式的（很难得的中文翻译版）中国铁道出版社2003 年出版的《Java 多线程设计模式》，将多线程模

式讲得非常浅显，配有大量的图例，每章都有习题，最后有答案！我研究多线程模式就是由它开始的！

第四本，今年出版的Head First 系列的《Head First Design Pattern》，秉承Head First 系列图书的优点，大量的类图、丰富的实例、有趣的注解，值得购买！

其次在J2EE 方向你可以研究阅读Addison Wesley 2002 年出版的《Patterns of Enterprise Application Architecture》，众多大腕的作品，讲企业消息集成的！Sun 提供的《J2EE PATTERNS SL500》也很好！晚了推荐那一本Amzon 4 星半的《Holub on patterns》，大师的作品，提供了，很值得研究的例子，不过对上面四本不是很熟悉的读者，最好不要读它！可能会让你比较累！

我学习设计模式经过一段很曲折的路线，前前后后大约看了20 本，阎宏博士的《Java 与模式》我看了4 遍，还排除我第一次基本没看

懂的看！记得研一时老师给我们讲了GOF 的那本，作为选修课，我和它们计算机系的硕士、博士们一起，到最后一个班40－50 个人，不

超过3 个人明白，我也没有明白任何一点（基础差吧――主要我对C++语言一点都不了解），凭我不伏输的性格，我认为我对java 语言理

解还可以，我就借了《Java 与模式》，结果还是基本没看懂。很有幸的是读研三时，听过了上交大饶若楠老师关于Java OOP 语言的讲座，我懂了组合书籍模式等三种设计模式后，对其它模式有了强烈的兴趣和要征服它的愿望！工作后我买的第一本就是《Java 与模式》，第一遍花了2 个月研究了这个1000 多页的大块头，后来第三遍15 天左右就可以搞定，笔记记了一大本！从此一发不可收拾。

选对书、埋头研究。相信很快就会入门的！

学习Java 语言8 个简单的部分，这只是我们研究Java 语言的开始！这些都懂了充其量一个java 程序员而已，后面的路很长很长！我们

可以继续研究数据库实现的源代码、Servlet 服务器的源代码、RMI、EJB、JNDI、面向方面编程、重构、ANT 工具、Eclipse 工具、Spring

工具、JBoss、JOnAS、Apache Geronimo 等J2EE 服务器！研究了这些你可能会成为一个出色的J2EE Architecture！你可以继续研究剖

析器、编译器、JNODE（java 写的操作系统）