继往开来 吐故纳新
日历
网志分类
· 所有网志 (990)
· 个人作品 (62)
· 软件设计 (33)
· 面向对象编程 (22)
· JavaAPI (39)
· Java开源工具 (31)
· Swing (34)
· Java语法细节 (39)
· 样式表CSS (12)
· XML (10)
· J2EE(JavaEE) (23)
· 算法数据结构 (64)
· 正则表达式 (4)
· 软件知识 (6)
· Java线程 (9)
· Web开发.Jsp/Servlet/Struts (20)
· 程序随想录 (7)
· Spring (5)
· Hibernate (7)
· J2SE 高级 (2)
· J2SE 高级 (0)
· Web开发.Ajax (16)
· Web开发.JavaScript (43)
· DB4O (2)
· Web开发.CSS/Html (22)
· C# (20)
· ERP (4)
· JDBC (1)
· 编程资源 (16)
· 编程感悟 (29)
· DB/Sql (13)
· VB (29)
· VC (2)
· 桌面脚本 (3)
· 新兴软件 (3)
· 英语学习 (21)
· 网文转载 (159)
· 职场风云 (39)
· 诗词歌赋 (32)
· 生活感言 (77)
· 奇文共赏 (13)
· 财经纵横 (6)
· 未分类 (11)
站内搜索
友情链接
· 歪酷博客
· 我的歪酷 非非共享界
· 偶要雷锋
· 豆瓣
· nczonline
· 当当网
· easyjf中文站
· Donews
· 天极Java文章列表
· W3CSchool
· taiten的BLOG
· Dojo中国
· Dojo
· Extjs.com
· Lifehack中文网志
· JaveEye的一个AS专题
· Banq's JDon
· Java 中文网址大全
· 梦想Java
· 360Doc个人图书馆
· java开源大全
· 我在硅谷动力的软件下载站
· 站长中国
· 随意贴
· CSS教学素材站
· java 参考中文站
· 面向构件与SOA社区
· 彩字生成
· 派派小说论坛
· 如坐春风
· 英语学习网
· BBC CHina
· www.dlbang.com
· 古文竖排格式在线转化工具
· 免费家谱
· 图片上传基地
· 风景壁纸
· 和风细雨
· MyC#BlogInCsdn

订阅 RSS

0207341

歪酷博客

开此博一为经验积累,二为资料收集,三为同道交流,四为资源共享.
2008/05/22 - 2008/05/31 浏览全部日志
辟邪堂主人 @ 2008-05-31 16:08

《推背图》在人们心目中曾经是一种很神秘的东西,好像它真的包含着什么“天机”,预言着未来的社会变迁,而且有诗又有图,在中国大陆以外被一些人称为“中国七大预言”之首,所以在我们没有见到它的时候,倒是颇能耸动一些好奇心。但是建国以来,《推背图》一直被当成禁书,不要说市面上不能出售,就是家里收藏也是违法的。人们有一种毛病,越是不让看的东西就越是感到神秘,一来二去,不少人心里真的以为《推背图》中藏着什么天机,不然的话,为什么政府不让我们看呢?记得在“四人帮”快垮台的那年,有人就对我说过:“那伙人快完了。某县某村里有位老先生,用《推背图》推出来的。”大家现在都知道了,《推背图》并没有关于“四人帮”的“信息”。但当时人们可以这么说,一是因为民众对“四人帮”的灭亡已有预感,二是正因为谁都不知道《推背图》是什么东西,所以才可以用它来做“证明”。尽管民众仇恨“四人帮”的情绪是合理的,但用这种方式来证明终究还是不对头。事情很明显,这种谁也不知何物的《推背图》是谁都可以利用的。要破除人们对《推背图》的迷信,制止一些人利用它图谋不轨,最有效的办法是让大家知道《推背图》究竟是什么东西。近几年国内的书摊上陆续出现了几种版本的《推背图》,大多是从港台“引进”过来的,一时很抢手,但一哄而后,便被冷落,看过的人不禁恍然:原来不过是这样!这就证明它并没有那么可怕,我们老百姓也不是那么容易上当的。  
但是如果只是把《推背图》印出来,那还是不够的。国外已经有了专门研究《推背图》的专家,他们当然不是想从中找出什么“预言”,而是把它当成一种文化现象来研究。我们眼下还做不到这一点,因为世界上到底有多少种版本的《推背图》我们都不知道,更不用说想看一看了。所以我们在这篇文章中只能“将就材料”地介绍一下《推背图》的知识,这样比单纯地用一句话把它骂倒更合情合理一些。 

说起《推背图》的缘起,倒是很神秘。唐朝有个叫李淳风的术士,精通天文历算,曾经因为预感到不久将有武则天乱唐的灾难,便推算起来。他推算得忘了情,一直推演下去,直到被另一位术士叫袁天罡的推了一下



 
Junglesong @ 2008-05-28 09:25

功能代码的多余枝节

当我们书写执行一个功能的函数时,经常需要在其中写入与功能不是直接相关但很有必要的代码,如日志记录,信息发送,安全和事务支持等,以下代码是一个用户注册类的代码:

/**
 * 用於用戶注冊的服務類
 * 
@author: sitinspring(junglesong@gmail.com)
 * @date: 2008-5-27-下午09:15:25
 
*/

public class RegisterService{
  
/**
   * 注冊一個用戶
   * 
@param name 用戶名
   * 
@param pswd 用戶密碼
   * 
@param email 用戶郵件地址
   
*/

  
public void register(String name,String pswd,String email){
    Logger.log(
"將注冊一個新用戶"+name);
    
    
// 真正的,应该由本函數擔負的處理
    System.out.println("存儲用戶信息到數據庫");
    
    MailSender.send(email, 
"歡迎"+name+"注冊為本系統的用戶");
  }

}


Logger类代码

/**
 * 模擬記錄器
 * 
@author: sitinspring(junglesong@gmail.com)
 * @date: 2008-5-27-下午09:17:56
 
*/

public class Logger{
  
/**
   * 模擬記錄信息到文件中
   * 
@param str
   
*/

  
public static void log(String str){
    System.out.println(getCurrTime()
+"INFO:"+str);
  }

  
  
/**
   * 取得當前時間
   * 
@return
   
*/

  
private static String getCurrTime() {
    Date date 
= new Date();
    Format formatter 
= new SimpleDateFormat("HH时mm分ss秒");
    
return formatter.format(date);
  }

}


MailSender类代码

/**
 * 模擬郵件發送器
 * 
@author: sitinspring(junglesong@gmail.com)
 * @date: 2008-5-27-下午09:23:31
 
*/

public class MailSender{
  
/**
   * 模擬發送郵件
   * 
@param title
   * 
@param msg
   
*/

  
public static void send(String email,String concept){
    System.out.println(
""+email+"發送郵件 內容為:"+concept+"的郵件");
  }

}



枝节性代码给功能性代码带来的麻烦

诸如日志记录,信息发送,安全和事务支持等枝节代码虽然是必要的,但它会带来以下麻烦:
1.枝节性代码游离在功能性代码之外,它们不是函数的目的,这对OO是一种破坏。
2.枝节性代码会造成功能性代码对其它类的依赖,加深类之间的耦合度,而这是OO系统所竭力避免的。
3.枝节性代码带来的耦合度会造成功能性代码移植困难,可重用性降低。
4.从法理上说,枝节性代码应该“监视”着功能性代码,然后采取行动;而不是由功能性代码“通知”枝节性代码采取行动。这好比吟游诗人应该是主动记述骑士的功绩而不是骑士主动要求诗人记录自己的功绩的。

如何两种代码分离开来

毫无疑问,枝节性代码和功能性代码(主干性代码)需要分离开来才能降低耦合程度,符合现代OO系统的要求,而java提供的动态代理机制可以帮助我们实现这一点。
动态代理机制主要的类是java.lang.reflect.Proxy,它从一诞生就受到了重视,并在RMI,EJB和AOP中都得到广泛的应用,其重要程度唯有反射能与之相比。

Proxy代理模式

在讲述动态代理之前我们可以回顾一下代理模式,它的定义是这样的:代理可以提供对另一个对象的访问,同时隐藏实际对象的具体事实。代理一般会实现它所表示的实际对象的接口。代理可以访问实际对象,但是延迟实现实际对象的部分功能,实际对象实现系统的实际功能,代理对象对客户隐藏了实际对象。客户不知道它是与代理打交道还是与实际对象打交道。
如果我们使用代理模式,把枝节性代码放入代理类中,这样主干性代码保持在真实的类中,这样不就能有效降低耦合度吗?这种通过在耦合紧密的类之间引入一个中间类是降低类之间的耦合度的常见做法。
具体来说就是把枝节性代码放入代理类中,它们由代理类负责调用,而真实类只负责主干的核心业务,它也由代理类调用,它并不知道枝节性代码的存在和作用,因为这本不是它的任务。对外来说,代理类隐藏在接口之后,客户并不清楚也不需要清楚具体的调用过程。通过这样的处理,主干与枝节之间的交叉解开了,外界的调用也没有复杂化,这就有效降低系统各部分间的耦合度。
下面让我们先看看代码

消除了枝节代码的注册类

/**
 * 用於用戶注冊的服務類
 * 
@author: sitinspring(junglesong@gmail.com)
 * @date: 2008-5-27-下午09:15:25
 
*/

public class RegisterService implements IService{
  
/**
   * 注冊一個用戶
   * 
@param name 用戶名
   * 
@param pswd 用戶密碼
   * 
@param email 用戶郵件地址
   
*/

  
public void register(String name,String pswd,String email){
    
// 真正的,該由本函數擔負的處理
    System.out.println("存儲用戶信息到數據庫");
  }

}



注册类的代理类,枝节性代码都被转移到了这里

/**
 * 注冊服務代理類
 * 
@author: sitinspring(junglesong@gmail.com)
 * @date: 2008-5-27-下午09:45:10
 
*/

public class RegisterServiceProxy implements InvocationHandler {
  
// 代理對象
    Object obj;
    
    
// 構造函數,傳入代理對象
    public RegisterServiceProxy(Object o) {
        obj 
= o;
    }


    
/**
     * 调用被代理对象的将要被执行的方法,我们可以在调用之前進行日誌記錄,之后执行郵件發送
     
*/

    
public Object invoke(Object proxy, Method m, Object[] args) throws Throwable {
        Object result 
= null;
        
try {
          
// 進行日誌記錄
            String name=(String)args[0];
          Logger.log(
"將注冊一個新用戶"+name);

          
// 調用Object的方法
            result = m.invoke(obj, args);
            
            
// 执行郵件發送
            String email=(String)args[2];
            MailSender.send(email, 
"歡迎"+name+"注冊為本系統的用戶");
        }
 catch (InvocationTargetException e) {
        }
 catch (Exception eBj) {
        }
 finally {
            
// Do something after the method is called 
        }

        
return result;
    }

}


代理类RegisterServiceProxy的解释

该代理类的内部属性为Object类,实际使用时通过该类的构造函数RegisterServiceProxy(Object obj)对其赋值;此外,在该类还实现了invoke方法,该方法中的
method.invoke(obj,args);
其实就是调用被代理对象的将要被执行的方法,这是通过反射实现的,方法参数obj是实际的被代理对象,args为执行被代理对象相应操作所需的参数。通过动态代理类,我们可以在调用之前或者之后执行一些相关操作。

如何生成一个代理类的实例

代理类的实例需要特殊的方式生成,代码如下:

  public static IService genereteService(){
    
return (IService)Proxy.newProxyInstance(
        IService.
class.getClassLoader(),
            
new Class[]{IService.class},
            
new RegisterServiceProxy(new RegisterService()));
  }

Proxy即为java中的动态代理类,其方法Static Object newProxyInstance(ClassLoader loader, Class[] interfaces, InvocationHandler h):返回代理类的一个实例,其中loader是类加载器,interfaces是被代理的真实类的接口,h是具体的代理类实例。

所谓动态代理是这样一种class:它是在运行时生成的类,在生成它时你必须提供一组接口给它,然后该类就宣称它实现了这些接口。你当然可以把该类的实例当作这些接口中的任何一个实现类来用。当然啦,这个动态代理类其实就是一个代理,它不会做作实质性的工作,而是在生成它的实例时你必须提供一个真实的类的实例,由它接管实际的工作。

工厂方法的作用

对于代理类生成的细节,客户(需要使用RegisterService的程序员)是没有兴趣也没有必要知道的,我们可以让它隐藏在一个工厂方法中,对外返回一个接口,这样在调用时用户就不知道他是与代理打交道还是与实际对象打交道了。使用RegisterService类时示例代码如下:

IService service=RegisterServiceFactory.genereteService();    
service.register(
"sitinspring","123456","junglesong@gmail.com");

执行完的结果和前面的代码的是一样的。

动态代理在AOP中的应用

Spring的AOP支持可以被用于从系统核心逻辑中分离交叉业务(cross-business)如日志,事务管理和安全等,使用AOP,你可以用各种功能层来覆盖核心业务层,这些功能层可以灵活的应用到你的系统中,甚至核心业务层都不知道它们的存在,这是一个强大的概念。
AOP(aspect-oriented programming)的核心就是动态代理,掌握它对于理解AOP尤为重要,犹如反射对理解IoC一样。

代码下载:
http://www.blogjava.net/Files/sitinspring/DynamicProxySample20080527235441.rar



 
http://www.blogjava.net/zhip @ 2008-05-28 08:25

转载地址:http://www.blogjava.net/zhip/archive/2008/05/27/203340.html 

网站导航 site map

公司简介 PROFILE or COMPANY Profile or Company

公司设备 EQUIPMENT Equipment

公司荣誉 GLORIES Glories

企业文化 CULTURE Culture

产品展示 PRODUCT Product

资质认证 quality certification

企业规模 SCALE Scale

营销网络 Sales Network

组织机构 orGANIZATION organization

合作加盟 Join in Cooperation

技术力量 TECHNOLOGY Technology

经理致辞 Manager`s oration

发展历程 Development history

工程案例 Engineering Projects

业务范围 Business Scope

分支机构 Branches

供求信息 Supply & Demand

经营理念 Operation Principle

产品销售 SALES Sales

联系我们 CONTACT US Contact Us

信息发布 INFORMATION Information

返回首页 HOMEPAGE Homepage

产品定购 orDER order

分类浏览 Browse by category

电子商务 E-Business

公司实力 STRENGTH Strength

版权所有 Copy right

友情连结 Hot link

应用领域 Application Fields

人力资源 Human Resource HR

领导致辞 Leader`s oration

企业资质 Enterprise qualification

行业新闻 Trade news

行业动态 Trends

客户留言 Customer Message

客户服务 Customer Service

新闻动态 News & Trends

公司名称 Company Name

销售热线 Sales Hot-line

联系人 Contact Person

您的要求 Your requirements

建设中 In construction

证书 CERTIFICATE Certificate

地址 ADD Add

邮编 POSTAL CODE Zipcode

电话 TEL Tel

传真 FAX Fax

产品名称 Product Name

产品说明 DESCRIPTION Description

价格 Price

品牌 Brand

规格 Specification

尺寸 Size

生产厂家 MANUFACUTURER Manufacturer

型号 Model

产品标号 Item No.

技术指标 Technique Data

产品描述 Description

产地 Production Place

销售信息 Sales Information

用途 Application

论坛 Forum

在线订购 On-line order

招商 Enterprise-establishing

招标 Bid inviting

综述 General

业绩 Achievements

招聘 Join Us

求贤纳士 Join Us

大事 Great Event

动态 Trends

服务 Service

投资 Investment

行业 Industry

规划 Programming

环境 Environment

发送 Delivery

提交 Submit

重写 Reset

登录 Enter

注册 Login

中国企业网技术支持 Powered by xxx.com

社区 Community

业务介绍 Business introduction

在线调查 Online inquiry Inquiry

下载中心 Download

会员登陆 Member Entrance

意见反馈 Feedback

常见问题 FAQ

中心概况 General Profile

教育培训 Education & Training

游乐园 amusement park

在线交流 Online communication

专题报道 Special report




 
Junglesong @ 2008-05-27 17:15

这是个人对程序员生涯的一孔之见,只代表作者的个人想法,其中疏漏甚至错误之处在所难免,希望大家多提宝贵意见。

前言

丰厚的薪水,高端的职位和有成就感的事业是人人都想要的,而这些都取决于你每天的认真工作,努力学习和灵活做人上。日子就像一块块砖,你就像是一个泥瓦匠每天在堆砌着你的人生,最终砌出一个宏伟的大厦或是一幢低矮的小屋甚至是堆成一堆瓦砾全取决于你自己。

程序员是一碗青春饭吗?

程序界和软硬件一样都要遵守摩尔定律,也就是说当前的技术知识很快会被替代,你需要不断学习新的东西,否则就会面临着被淘汰的危险。然而,一个人的学习动力和欲望都是有限的,记忆力还会随着年龄的增长而衰退,从这个道理上来说,年龄大的迟早会被年龄小的超过,成为鸡肋并最终将被无良的公司抛弃。难道程序员这个职业做不过三十五岁,永远是一碗青春饭吗?

根基是决定一个人会不会被淘汰的关键

我刚进入IT业就听说过这种说法,不过当时的年龄限度是30岁,当工作一段时间后,这个限度上调了五岁,而且还有陆续上调的趋势,而在各个公司中,超过35的程序员并不罕见,在外国做了一辈子软件的人也屡见不鲜。难道“程序员是吃青春饭的”是一个谬论吗?那么为什么很多人持有并宣扬此论调呢?
其实这个结论既正确也不正确,它的结果取决于要评判的人。一个人如果根基扎实,他就更容易学习新的事物新的知识,年轻和精力相对于扎实牢靠的根基是微不足道的,对于别人是一座山的障碍,对于他也许就是一张纸的隔阂,这样的人是不会面临着被超越被淘汰的危机的,青春饭的论调对他完全不适用;而一个人如果根基不牢,只是靠精力和年龄勉强立足,每次新事物新知识出现都在和年轻人拼体力拼精力,那么他迟早将被淘汰,优胜劣汰的社会就是这样残酷无情,但很公平 。

什么是程序员的根基

面向对象的思想。MVC,分层架构,按接口编程,依赖注入,OR Mapping,面向方面,SOA等都是OO的发展,不从根本上领会它,程序员就难以把握程序发展进化的趋势,永远停留在老窠臼中无法自拔,自我提高升华进化当然更是一句空话。
数据结构。程序的核心目的是收集,整理和展示数据,而数据的核心就是数据结构,它的重要性不言而喻。线性表、栈/队列、串、多维数组、广义表、树、图这些数据结构你都需要认真掌握,掌握的程度越深,日后学习的阻力就越小,相对于他人将更有优势。
算法。如果缺乏好的算法,程序架构得再完美数据再贴切都无济于事,犹如一台法拉利却用牛来拉一样。迭代法、穷举搜索法、递推法、贪婪法、回溯法、分治法、动态规划法都是你需要掌握的,不要以为这很难,读透一本算法导论就足够了。
基础API。只有思想,数据结构和算法只是一条腿,要健步如飞还得两条腿走路。程序员的另一条腿就是基础API,你需要认真掌握TCP/IP协议详解,Socket通信,线程,文件读写等每种语言和技术都需要的基础知识,一个新事务即使再绚烂夺目也是利用这些基石搭建而成的,如果你彻底了解了它们将永处不败的境地,甚至觉得新技术也不过如此。

如何打好根基

多学。从项目中学,从书本中学,从别人哪里学,从失败中学习,掌握基础API就是需要多学习,如果有已有的知识总结可以起到事半功倍的效果。
多想。学习OO和算法都需要理解,光是死记硬背毫无用处,子曰“学而不思则罔”,OO和算法的学习都需要一个理解消化的过程,只有彻底理解了,你才真正掌握了它们。
多练。经过代码的历练,程序员才能百炼成钢,成功的项目能告诉你什么是正确的,失败的项目会暗示它为什么会失败,下次你就能更进退有据。更重要的一点是,不做项目,不做多个项目,不做大项目,程序员对“度”的把握总是缺乏经验,不是过就是不及。真正亲手手写过10-20万行代码的是成为一个成熟程序员的必要条件(但不是充分条件)。
多见。眼光狭窄,目光短浅,固步自封只能造就一只井底之蛙,你的眼光必须超越自己所在的环境才能取得真正的进步,现在有许多开源社区和软件都是你应该涉足的地方,和什么样的人在一起你自然也会成为什么样的人。“蓬生麻中,不扶而直,白沙在涅,与之俱黑“说的就是这个道理。


程序员的身价是由什么决定的

如果一个程序员有良好的根基,充满智慧的头脑,积极主动的精神和锲而不舍的毅力,他就一定能有丰厚的薪水吗?答案是否定的。原因在于薪水不光取决于自身的水平,还取决于周围的环境。
程序员的身价首先决定于他能给雇主带来多大的利益,如果带不来利益,程序员再有本事也是白搭,这就要求程序员一定要根据自己的特点寻找合适自己发展的公司,在你的职业生涯之初就要研究自己和世界,逐步选择一个合适自己的方向发展,永远记住,方向比努力更重要。
其次,程序员的身价也取决于他的不可替代性,即使一个人能带来很多的利益但身后有大批的后备军资源,干不好立即就有人顶替你,这样的人薪水也不会高,反正你不干有的是人干,资本家就是这样无情。这告诉我们要使自己不可替代,就要努力向高处走,一定和众人拉开差距才能彰显自己的价值。

程序员生涯能给我们带来什么

IT是一个朝阳产业,正处于蓬勃发展中,选择这一行比其它行业拥有更多的发展机会。
相对于其它职业,程序员对自己命运的把握程度更大。”荣辱自取,不求于人“,这是一种非常好的感觉,在别的职业中是难以找到的。
只要人们还在使用计算机,程序员这个职业就永远不会消亡,因为计算机运行永远需要软件。
在信息时代,程序是一个非常有效的收集或发布信息的工具,如果利用得当,它能直接带来巨大的收益。

程序员事业发展的方向

架构师,CIO。对于热衷于技术的程序员来说这是一个不错的方向,架构师这个职位的必要条件是有优秀的技术功底和丰富的设计经验,此外还需要有某个领域的深入知识。对于CIO要求更高,他需要对未来五年内的技术走势把握得比较清楚。
项目经理,部门经理。人际关系处理良好,语言能力出众的程序员适合走这条路。这也是大连大多数程序员的理想选择。
做自己的网站,当一个给自己发薪水的人。网站做好了收入颇丰,低端如hao123,高端如google的例子都摆在眼前。其实做网站初期投入并不巨大,但需要持之以恒的毅力尤其是敏锐的市场嗅觉,它决定了你是否能从网站中盈利。此外,拥有自己的网站对于自我宣传,建立个人品牌有很大的好处。这条路适合于热衷于网络技术的程序员。
开公司创业。制作软件并不难,难得是是否能接到活,能否接到长期的活,如果能做到的话,你就可以选择创业。拿工资致富是不可能的,而一次项目的利润可能就等于你前期的工资总和。

后语

相对于永恒的宇宙,我们确实非常渺小,应该有谦卑之心;但是跟别的任何生命相比,我们的尊严,我们的价值,我们的可能性,是一样的;就算人家确实是牡丹玫瑰,自己只是小小的,角落里的一朵苔花,也应该灿烂地绽放,把自己涨圆,并且自豪地仰望苍天,说:“我也能!”



 
Junglesong @ 2008-05-26 15:53

转载地址:
http://sonicbbs.eastday.com/SonicBBS/Topic/310-2237100.html 

  从产生高级语言以后,我们就不断地需要站队选择,从选择高级语言,到选择IDE平台,从选择Java还是.Net,到选择何种中间件平台。现在又出现了RIA和SOA的队列,无穷无尽。。。。。

  正因为有了这些才会有语言之争、使用不同语言不同IDE平台程序员的对立,JAVA VS .NET PHP VS RUBY ON RAILS。在站队和选择中,很多很多程序员迷失了,也许框架、语言确实给我们带来了便利,也许我们有选择或无选择的使用着软件提供商开发的IDE拖拉着控件开发程序也感觉没有什么不好,也许你认为这样是天经地义的也是大势所趋的,但是 BUT 你在站队 选择中失去了自我。

  我承认ruby on rails的确很酷,Ajax实现的效果也确实很棒,GOOGLE MAP 开放出来的API让我们实现了很多很多以前无法做到的效果,当你和朋友说我又买了一本诸如《C#3.5 FrameWrok揭秘》的经典书籍时略显满足的表情也许会让朋友暗叹你真上进。

  我们总是在何种技术何种平台上去选择着,去努力研究着规则、标准,去祈祷着她的长久,因为她是你的饭碗。

  是的!作为开发者,我们总要去选择去排队,即便精通诸多语言诸多开发工具,也要去选择现在用什么。

  世界上最可悲的是永远都在梦里而自始至终不知道真相的人,很不幸我们也许就是梦中人。

  写了这么多,您可能也不知道我要说什么,那么我通过几个问题来表述我要说什么。

  1、您买的书中是否有诸如 图论、概率论、统计学、数据挖掘、TCP/IP协议详解、现代数学手册、等等底层并且基础的书?这些书占您所有书的多少比例?

  2、有迭代法、穷举搜索法、递推法、贪婪法、回溯法、分治法、动态规划法中您掌握了哪些?

  3、线性表、栈/队列、串、多维数组、广义表、树、图、排序、查找、文件 这些数据结构的基本概念您是否都了解和明白?

  在站队、选择时这些才是我们的根本,而往往真正缺失又不在意的却是它们........

  假如我们连这些真正该掌握的都缺失了,那么我们自以为拥有的就不叫拥有,我们也只能盲目或自认为的在选择中选择、在站队中站队,直到有一天因为年纪的增长跟不上技术的革新而被淘汰掉。