2008-04-15
全文显示

依赖倒置(DIP)

关键字: dip oo principle 设计原则
所谓依赖，指代码中的耦合。依赖倒置，是相对于传统的面向过程的设计结构而言，面向对象的结构把依赖关系倒置了。 DIP原则： 高层模块不应该依赖于低层模块，二者都应该依赖于抽象。高层模块只应该包含重要的业务模型和策略选择，低层模块则是不同业务和策略实现。首先高层模块和低层模块都要抽象出来，高层抽象不依赖于高层和低层模块的具体实现，最多只依赖于低层的抽象。高层的实现独立于低层模块不应该依赖于低层模块，而是依赖于低层抽象。同时，低层的抽象和实现也只依赖于高层的抽象.为什么要依赖于抽象呢？因为抽象/接口都是相对稳定的，不会被频繁改动的，依赖是可以信任的。如果都依赖于具体的实现，想想吧，改动一小块代码是 ...
2008-04-08
全文显示

Salesforce与Google App深度合作

关键字: salesforce google saas
Salesforce是一家提供SaaS服务的企业，大概有十年历史。他已经与Google开展了深度合作，同时向他们的客户出售Google Docs服务，当然是集成在他们的系统中使用。现在就有可能存在双方之间的交易--Google会收购Salesforce。 一方面，Google希望把他们的应用出售给一些企业客户，另一方面，salesforce也已经使用了大约41000个Google的应用。如果交易成功，对双方都是有利的。
2008-04-01
全文显示

开闭原则(OCP)

关键字: ocp 开闭原则 open-close principle
开闭原则(OCP)是OOD常用的基本原则之一.这个原则首先由Mayer在其著作<Object Oriented Software Construction>中提出. 软件实体,包括但不限于Classes, modules, functions,应该对扩展是开放的,对修改是封闭的.换句话说,在极端的情况下,你不需要修改现有的代码,新功能通过子类,重载或通过代理来委托现有代码来完成.这样会防止你向现存的代码中引入bug,因为现存的代码不会被改动就不会产生新的问题. 首先要澄清的一点是:没有100%封闭的代码.封闭一种设计上的策略,并不是指具体的代码.代码体现并趋向于你的设计策略,这不代表 ...
2008-03-31
全文显示

使用To-Do List

关键字: to-do list 工作方法
以前做项目的时候,常常会用MS Project来安排任务与进度.后来改用Excel,记录每天要做的事情,不断地修改它,增加一些条目,删除一些条目,更新一些条目.先是一个人用它,然后有越来越多的项目组成员开始使用它.你可以根据你的项目和团队的情况决定使用哪类工具,小项目通常用Excel就够了,如果比较大的项目,涉及的成员比较多,你更应该选择使用To-Do List. 为什么要用To-Do List?整个团队都在辛苦工作,每个人都很忙,但产品总是无法完成;重要的Feature被遗忘了,需求没有被完全覆盖到,一些人在等着另一些人的代码.有些人不知道接下来该做什么,干等着.这些情况你遇到过吗?To- ...
2008-03-26
全文显示

做专业开发者

关键字: professional 专业
软件开发是一项工作,还是一份事业?它取决于你的态度.以专业的态度对待工作,那么它就是你的事业.你为这之付出,并获得回报.如果你不愿意付出,那么你只能收获痛苦. 不要以为工作只是简单的堆砌代码,完成今天的工作.代码可以从一个侧面反映出一个人的性格和态度.我们都喜欢与专业的人士合作,从而获得更高的效率.你希望与专业的同事一起工作吗?那么就做得更专业一些吧,因为专业的人更喜欢与专业的人合作. 如何判断你是否"专业"呢? 专业的态度.首先是开放的心态,其次是谦虚,还是对事不对人.在团队中大家的目标是解决问题,而不是追究责任.通过彼此合作,相互承诺来共同完成工作.出现问题首先要分析问题出在哪里,如 ...
2008-03-17
全文显示

单一职责(SRP)

关键字: oo principle 设计原则 srp single responsibility principle
Single Responsibility Principle(SRP) 单一职责,是OO原则中的基本原则之一,也是最重要的原则之一. 一个类承担一个职责的全部内容,而且只承担一个职责(Once and only once),并且要做得很好. 每个职责都应该是独立的类,因为每个职责都是变化的中轴. 一个类应该只有一个原因引起变化. 业务规则的变化所导致的类的改变,这个类不应该被数据库,GUI或其它部分的变化强制改变. 怎么去定义职责呢?通常我们称之为类所承担的职责,其实就是引起类变化的原因.如果一个类被两个以上的原因改变,那么就要重新审视这个类的职责,把不同的职责拆分到不同的类里面去.你 ...
2008-03-12
全文显示

OO 设计原则

关键字: oo 原则 设计
最近在审查(review)代码时,常常发现一大堆代码充满了各种bad smell.即使工作了三五年的同事,也不会例外.沟通时往往发现他们对OO的理解只是表现出简单的概念理解.对OO的一些原则不甚了解,或者写代码也是跟着感觉走. 我最初做开发的时候也是跟着感觉走,初次听到OCP如天外来物.使用Java或C#不代表你就是在做OO开发,熟练使用OO语言不代表已经对OO非常了解.感谢Uncle Bob的经典巨著<Agile Software Development>,坚持阅读的习惯让我接触并努力理解OO原则.一旦对这些原则有了深入的认识,写代码时就已经从更高的角度来分析问题,解决问题,力争 ...
2008-03-04
全文显示

找到你的位置

关键字: 目标管理
每个人都有自己的特长和特不长,一些人会为自己的特不长而苦恼,花费大量时间和精力做出改变.其实完全没有必要.每个人都擅长和不擅长的事情,没有例外.不要奢望去做一个全才,没有任何意义.如果你希望让自己更有效率,花费同样的时间和精力取得更多的成果,那么你最好先找到你的位置. 你对技术有兴趣,希望自己成为一个技术专家.那么专注于技术,其它的东西都可以先抛在一边.因为专,所以精.在你取得一定的成果的时候你的价值就会体现得更高. 如果你希望成为一个优秀的管理者,全身心投入到其中,不断学习和提高.从物理上讲,你的时间和精力始终是有限的,你的产出自然也是有限的.但是因为你产出的东西是有深度的,就具有更高的价值 ...
2008-02-27
全文显示

数据库命名规则

关键字: 数据库 规则
这么多年的开发,始终未离开过数据库应用.从MSSQL到Oracle,现在又要mysql,真是要命.为了不让数据库的设计工作全压在一个人身上,所有队员都可能会做一部分工作,为自己负责的需求建立表结构.于是统一数据库的表名和字段名规则就不可避免.不过在做数据库设计时常常遇到同事对表名,字段名设计规则的质疑.因为到现在为止,我确实没有发现很通用的设计规则,在不同的项目环境下可能会启用不同的规则. 我最常用的规则: 1.表名分两部分组成--前缀_主题.如库存表whs_inventory,whs是前缀,表明这是用于仓库模块的,inventory是主题,表示这个表的业务概念. 2.字段名也分成两部分-- ...
2008-02-03
全文显示

我的工具集(不断更新中...)

关键字: 效率 工具 框架 framework mock
工欲善其事，必先利其器. 人的精力是有限的,一定要专注于一些创造性的工作.那些可重复的工作就交由计算机来做吧,它通常是不会拒绝的. 下面是我正在使用或者曾经使用过的工具或者框架: -------------------------------------------------------------------- Eclipse 这个就不说了. JUnit 这个也不用说了. Ant 这个更不用说了.Spring和Hibernate这两个也不用说了. 尤其是Spring,如果你还没有使用,我建议你一定要仔细研究一下.Tapestry 我们现在用的是4.1.3,很简单, ...
2008-01-28
全文显示

提高UT质量

关键字: unit test 质量
1.选择正确的粒度.不是所有的代码都要有匹配的测试用例,有些情况下可以不用写测试用例. 机器或工具生成的代码是不需要测试的. 多数的POJO是不用测试的,除非你重写了它的hashCode和equals方法. 接口和抽象类是不需要测试的. 基于现在的开发实力,我们决定不做UI层的UT.我说的UT是指通过代码做测试. 2.选择合适的Mock工具 经常使用的就是jMock和EasyMock,两者各有所长,根据你的项目环境找到合适的Mock工具. 3.提高UT的独立性. 如果UT依赖太多,表明这个UT是很粘的,bad smell.你要做出改变.用mock objects可以有效减少依赖.如果访问数 ...
2008-01-23
全文显示

读<重构与模式>(Refactoring to Patterns)

关键字: refactoring patterns
<重构>,我几年前读过两遍,对里面提到的各类概念印象深刻,不断发出'哇,哇'. <设计模式>是我读到的关于设计的最早的书籍,当时只有一年多的开发经验,对设计模式的理解很肤浅.后来开始使用Java之后,又在网上找到J道(http://www.jdon.com)关于设计模式的一些资料,算是对设计模式有了初步的认识.之后就是每几个月就会再看看其中的一些模式,努力加深对软件设计的理解. 一次偶然的机会,我看到了<重构与模式>,又一本令人震撼的作品.我们在开发时不能合理地应用模式,有的人根本不考虑,有的人则考虑的太多了,产生了过度设计.这种情况一而再,再而三的发生,不断增加我们的挫 ...
2008-01-16
全文显示

调用VB COM

请参考MSDNMSDNhttp://search.support.microsoft.com/default.aspx/kb/259725/zh-cn.
2007-12-25
全文显示

Managing hierarchical data in mysql 实现分层数据的管理

关键字: hierarchical data 分层数据
这是一篇由Mike Hillyer写的关于如何通过数据库管理分层数据的好文章,由一个叫Yimin的人翻译的. 由于格式及图片的问题,我就直接上传附件与大家分享.
2007-11-28
全文显示

源代码加密？

关键字: java 源代码 加密 混淆
最近公司正在研究如何使用USB加密方式防止别人盗用我们程序。众所周知，java源代码被解密是一件很容易的事，而且解密后的文件也有一定的可读性。公司觉得这是非常严重的事情，如果将来我们的程序不断在各个服务器上发布，却很难去监管。于是想出来这个点子去保护所谓的版权。 我开发程序也有几年了，对所谓的版权这个东西一直很不以为然。有人跟我谈版权,通常就是在谈如何防止别人得到源代码,而我总觉得这是吃力不讨好的事情。除非你的源代码有独到之处，不然保护这个东西很难搞，最多是把源代码编译时加个混淆器。（这个东西我还要研究一下，希望能对大家有帮助。）但是有些公司因为盗用了别人的代码，所以理所当然地害怕别 ...
2007-08-08
全文显示

读<平衡敏捷和纪律>

关键字: 读书
未读完整本书，到最后还是坚持不下去了，对我来讲收获太小了。   基本上这本书已经的核心就是评估敏捷方法和传统软件工程方法的优劣，并找出彼此的相同和不同，然后相互取长补短，形成最有效的方法和过程。不过我还是无法找到想要的答案，或者是很明确的方法。其实大家早知道一定要找到适合自己的方法，不能空谈什么RUP，XP，CMM或CMMI之类。但讲到实践的层面，还是XP更实际一些，更贴近我们的工作内容。  最近工作上也常遇到类似的问题，PM或再高层的经理总是说大家要提高开发速度，大家要提高修BUG的速度，等等。听得人犯困，完全是念经，更像喊口号。提高工作效率不是光喊喊就能做的，要花很多时 ...
2007-08-08
全文显示

收藏品

关键字: 技术 创业 java
IBM developer works多数的开发人员都会浏览技术网站，阅读技术书籍和资料，希望这篇文章会帮到大家。而且我会持续更新内容，分享本人感兴趣的内容。 首先推荐的是www.theserverside.com，基本上每天都会去看看，信息量不算大，但含金量很高。如果你想了解最新的技术热点，大家关心的各类工具、架构、概念都会在这里不断更新。 软件创业者的五个误区,这是一篇译文，为软件创业者提供了更多的指导。 怎样引起风险投资家的注意创业者都希望在初期能够迅速获得风投的注资，方法有很多，就在这篇文章里。代码质量检测工具JDependhttp://www.clarkware.com/softwa ...
samuelray
搜索本博客
最近加入圈子
存档
最新评论