一个 Java 编程老手的设计语录

核心提示：1.有必要TO和对象进行分离吗？为什么要分离？分离实现了数据与功能的分离，在传递数据时没有必要传递功能接口，一个 Java 编程老手的设计语录，仅仅是数据的传递，为什么要把功能接口暴露给web层？web层见到的只有数据，有必要用面向对象那么复杂吗？不就是把信息更新到数据库吗？粒度细化以后，使用面向对象的东西能够带来重用

　　1.有必要TO和对象进行分离吗？为什么要分离？
　　分离实现了数据与功能的分离。在传递数据时没有必要传递功能接口。仅仅是数据的传递，为什么要把功能接口暴露给web层？web层见到的只有数据。避免了的web层程序员的调用接口冲动。而实际上在web层调用是错误的。
　　
　　这个理解有问题，功能接口的控制可以通过访问控制要害字来控制，比如只有包权限。
　　
　　2.但是TO和对象分离以后，有重复的数据。那为什么不避免重复？
　　思路是TO只携带必须的数据，抛弃一切多余的数据，提高传输性能。
　　
　　有必要吗？就那么一点点性能
　　
　　似乎没有必要。但是web层在构造数据的时候，他不可能传递也没有必要传递id之外的任何数据。
　　
　　这很轻易解决阿，让id之外的数据空着好了。
　　
　　3.为什么不让业务对象继续TO？
　　防止业务对象和TO耦合太紧。
　　
　　但是TO作为成员变量实际上也是一种紧耦合？
　　
　　相对来讲继续的耦合性比成员变量的耦合性要强一些，比如我完全可以换掉成员变量，使用别的方式来保存数据。
　　
　　不对吧，你构造函数本来就使用了TO，这是一种强耦合
　　
　　但是成员变量方式要写大量的重复代码，比如我要改变一个属性的值，你就要提供set方法，他只是进行了传递，这是一种重复。
　　
　　这个问题我可以提供getTO方法，让人调用，然后让客户使用TO的set方法。
　　
　　呵呵，这样岂不是又让耦合性增强了？我使用继续的方式可以让业务对象很轻易的用于sPRing架构中。
　　
　　1.TO中的引用TO为什么要数组？
　　这样就不用类型转换了阿。
　　
　　但是你在增加删除等操作数据的时候岂不是很麻烦？使用数组只是在读取的时候比较方便。而增加删除的操作要频繁得多。读取的麻烦可以通过转换为数组来简化，List等转换为数据并不难。而且业务对象可以直接使用这些List作为容器，不用再引入其他List做容器，避免了代码重复。
　　
　　2.简单的增删改查，有必要用面向对象那么复杂吗？不就是把信息更新到数据库吗？
　　
　　粒度细化以后，使用面向对象的东西能够带来重用啊，今后不用老改。