07 2013 档案

摘要:单元测试(unit testing),是指对软件中的最小可测试单元进行检查和验证。开发者编写一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。JUnit的主要用途即是单元测试使用eclipse自动生成JUnit4的测试代码:public class Math { public Math(){ System.out.println("init"); } public int add(int a,int b){ return a+b; }}右键需要测试的java类 -> New - 阅读全文
posted @ 2013-07-31 13:58 心意合一 阅读(178) 评论(0) 推荐(0) 编辑
摘要:状态模式:允许对象在内部状态改变时改变它的行为,对象看起来好像修改了它的类考虑如下场景,自动售票机:每一个方格表示自动售票机的一种状态,每一个箭头线表示自动售票机由一个状态转换到另一个状态所需要的操作状态抽象为自动售票机类的参数,操作抽象为自动售票机类的方法创建一个实例变量持有状态值,方法内增加条件代码处理不同状态public class TVM { final static int noCoin = 1; final static int hasCoin = 2; final static int ticketOut = 3; private int state = noCoin; p... 阅读全文
posted @ 2013-07-29 17:25 心意合一 阅读(152) 评论(0) 推荐(0) 编辑
摘要:"==":1,如果两表达式的类型不同,则试图将它们转换为字符串、数字或 Boolean 量。 2,NaN 与包括其本身在内的任何值都不相等。 3,负零等于正零。 4,null 与 null 和 undefined 相等。 5,相同的字符串、数值上相等的数字、相同的对象、相同的 Boolean 值或者(当类型不同时)能被强制转化为上述情况之一,均被认为是相等的。 6,其他比较均被认为是不相等的。 "===":除了不进行类型转换,并且类型必须相同以外,这些运算符与相等运算符的作用是一样的。 阅读全文
posted @ 2013-07-25 11:44 心意合一 阅读(143) 评论(0) 推荐(0) 编辑
摘要:Stack是一个后进先出(last in first out,LIFO)的堆栈,在Vector类的基础上扩展5个方法而来Deque(双端队列)比起Stack具有更好的完整性和一致性,应该被优先使用 E push(E item) 把项压入堆栈顶部。 E pop() 移除堆栈顶部的对象,并作为此函数的值返回该对象。 E peek() 查看堆栈顶部的对象,但不从堆栈中移除它。 boolean empty() 测试堆栈是否为空。 int search(Object o) 返回对象在堆栈中的位置... 阅读全文
posted @ 2013-07-22 17:05 心意合一 阅读(184) 评论(0) 推荐(0) 编辑
摘要:组合模式定义:组合模式允许你将对象组合成树形结构来表现“整体/局部”层次结构,组合能让客户以一致的方式处理个别对象以及对象组合。当涉及到如:菜单,子菜单之类的问题时,会自然而然的想到使用树形结构类之间的关系确如上图所示,但是这种设计复用性和扩展性都很低:1,所有的菜单都有各自的add、remove以及getChild实现,复用性很低2,类型转换问题,菜单完全不知道其包含的子元素的具体类型,这是个大问题(List)针对上述2个问题:1,抽象出共同的父类,以实现一些基本方法的复用2,隐藏菜单与菜单项之间的差异,在这点,我们可以借鉴装饰者模式,将菜单和菜单项都当做一个菜单,如此一来,共同的父类也出现 阅读全文
posted @ 2013-07-22 11:41 心意合一 阅读(219) 评论(0) 推荐(0) 编辑
摘要:迭代器模式定义:Iterator Pattern提供一种方法顺序访问一个聚合元素中的各个元素,而又不暴漏内部方法酒吧提供beer和wine:public class Bar { private List barMenu; public Bar(){ barMenu = new ArrayList(); barMenu.add("beer"); barMenu.add("wine"); } public List getMenu(){ return barMenu; }}餐厅提供rice、soup和noodles:public class Restaura 阅读全文
posted @ 2013-07-16 11:08 心意合一 阅读(198) 评论(0) 推荐(0) 编辑
摘要:转眼工作2年了,记录一些工作中遇到的问题,不断审视,不断反思:1,可扩展性:对于一个普通功能,也许只需要500行代码,但是如果考虑到后期的扩展,可能需要5000行代码,算上时间成本,究竟改如何取舍如果时间充裕,当然使用更具扩展性的设计,但是在敏捷开发这种快速迭代的开发模式中,是要追求功能最小化还是更强的扩展性比如:快速开发出原型,然后快速迭代的开发模式,此时,是不是更应该以功能为基本单位,不要过多的关注扩展性?如果是的话,后期扩展岂不是需要消耗数倍精力?可扩展性与复用性好像有着必然的冲突,提高扩展性的同时貌似必然会带来一定的亢余十分纠结,期待有人指点一二,不胜感激!敏捷开发只适合成熟的团队,需 阅读全文
posted @ 2013-07-11 09:37 心意合一 阅读(131) 评论(0) 推荐(0) 编辑