Java Dynamic的专栏

覆盖equals方法貌似很简单，但是有许多覆盖方式会导致错误，所以们应该做到要么不覆盖equals方法，要么覆盖时就要遵守通用约定。一、什么情况下可以不覆盖equals方法如果不覆盖equals方法，那该类的每个实例都只与它自身相等，而有时候这就是我们需要的。1、类的每个实例本质上都是唯一的对于代表活动实体如Thread而不是值(Value)的类来说确实如此，Object提供的eq

终结方法(finalizer)通常是不可预测的，也是很危险的，一般情况下是不必要的。一、终结方法VS析构器熟悉C++的都知道，析构器是用来回收一个对象所占用资源的常规方法，是构造器所必需的对应物。在JAVA中，当一个对象变得不可达时，垃圾回收器会回收与该对象关联的存储空间，这不需要我们操心。对于非内存资源的回收，C++析构器是可以管理的，而JAVA的垃圾回收器是不会管理这些非内存资源的，我

一、覆盖hashCode在每一个覆盖equals方法的类中必须覆盖hashCode方法，如果你想让该类能够用于基于散列的集合中，如HashMap，HashSet和Hashtable。Object.hashCode通用约定1、在应用程序的执行期间，只要对象的equals方法的比较操作所用到的信息没有被修改，那么对这个同一对象调用多次，hashCode方法必须始终如一地返回同一个整数。在同

一、序言程序设计的几条基本原则：1、清晰性和简洁性最为重要，模块的用户永远也不应该被模块的行为所迷惑，所以写良好的注释是必需的。2、模块要竟可能小，但也不能太小，好一个深奥的哲学问题。3、代码应该被重用，而不是应该被拷贝，拷贝的代码哪天就是你的灾难。4、模块的依赖性应该尽可能地降到最小，低耦合是必须的。5、错误应该尽早被检测出来，最好是在编译时刻，否则你的这次运行就白费了。

一、静态工厂方法与构造器共同的局限性不能很好的扩展到大量的可选参数，这个很悲剧的，我一般使用java bean，不管合适不合适，没考虑线程安全哈。二、有多个可选参数对象的实例化方法1、重叠构造器：提供一个只有必要参数的构造器，第二个构造器有一个可选参数，第三个构造器有两个可选参数，以此类推，最后一个构造器包含所有的可选参数。/** * 食品营养成分标签类 */publi

一、Cloneable接口与Object.clone方法Cloneable接口的目的是作为对象的一个mixin接口(混合型接口)，表明这样的对象允许克隆(clone)。遗憾的是Cloneable接口里并没有clone方法，其实它什么方法都没有，跟Serializable接口一样，都是占着茅坑不拉屎。它只是声明该对象可以被克隆，具体行为由类设计者决定。如果类设计者忘记提供一个良好的clone方法

一、私有构造器与SingletonSingleton设计模式就是确保类只被实例化一次，那如何保证类只被实例化一次呢？最好的办法就是阻止客户端自己创建类实例，也就是把创建类实例的构造器给私有化。这样，客户端需要类实例时，我们就可以给它返回已经创建好的实例。这就是私有构造器与Singleton的不解之缘。创建Singleton的方式：1、将实例做成公有静态成员且是final型的。pub

一、Java的String对象java中String对象很特殊，因为它是个不可变对象。每次对String进行截取，拼接都会返回一个新的String对象。正因为这个原因，初学者经常陷入对字符串操作的误区，包括我，呵呵。两种生成字符串的方式：String s = new String("strubgette"); //每次执行都会创建一个新的String实例，即使它们在功能方面是等同的。何

一、Java的垃圾回收大学时学过C和C++，后来学JAVA，感觉最爽的就是System.gc()，哈哈，java的垃圾回收，真有点不可思议。以为Java就是神，垃圾回收就是神的权杖，然后我只需敬仰他，信奉他。殊不知垃圾回收不是万能的，看看下面的这段代码就知道了。public class Stack { private Object[] elements; private