关于Java的一些看法

要在JAVA技术上突破普通的层面，并拥有一翻设计理念的高度，除了要有很好的设计思维之外，反射在适当的使用下，将会把框架做得非常清晰，并且代码编写也非常简便。
动态代理的意义
从个人的语言来说，动态代理机制是每一门语言的基础，没有动态代理什么也做不了，也就是动态代理是运行语言的代码，在JAVA中请最先记住一个invoke()，后面会细节说明，其实在面向对象的设计中，实现了继承、封装、多态三大特征，不过仅仅是使用这些功能，你会发现和C语言没有什么区别，使用其充分的扩展性才能体现面向对象的好处，而其扩展性在诸多方面有所体现，而扩展性的基础来源于总体的设计和架构，动态代理将会提供非常好的机制统一总控管理和分发代码片段，将逻辑层抽象成模型，将判定作为分发方式，便于相应模型扩展就变成了配置，而不是代码片段（因为代码需要全线跟踪，全局观念很低就会导致整篇修改的迹象，而且修改任何一个小问题需要重新测试、发包、上线周期很长而且会导致很多BUG），也就是说做配置的目的就是把逻辑层抽象为模型，将模型的类型进行分解进行配置化，这样的代码下即可实现产品化，又可以实现个性化，当然总有一个限度，至于到达何种程度，关键看设计者的境界了。

以前我在部分博客上有人写道：如果你发现你的代码中几乎没有if else的时候，你面向对象的设计思想就达到一个境界了，其实他说得很多方面也是很有道理的，因为这类层套层的判定逻辑，是很难维护的，除非编写非常复杂的算法，业务上是不太可能有这样的情况。因为很多写代码的人都是从C过来的，其算法学得不错，而分析问题的方式和JAVA完全不一样（其实我也是那样走过来的，我曾经写代码也是那样），JAVA最重要的就是先业务问题抽象化，抽象为模型去解决，而不是只想到这段代码怎么去写，然后开始棒棒棒的写起来，也许你写的代码很长，你觉得很牛，而且写得很快，不过当软件逐渐做大做复杂的时候，麻烦就要开始了。

软件设计中，并不是不让你用if else，而是业务层不应该这样使用，业务千变万化，无穷无尽，除非这个软件周期很短或者根本就只是为了应付而不想做出什么好的产品出来，那可以这样，因为这样在开发小软件的时候周期非常快。模型在业务设计中不断抽象和寻找最佳切入点后，你会发现在复杂的业务，也可以抽象为几种简单的模型，而模型变化的可能性很小，没有大的动作就是那么一些东西，一旦将这些模型抽象出来后，逐渐产品化就可以实现界面配置化，甚至于提取抽象层次和自动化管理，现在比较经典的就是工作流（用硬编码去写工作流会死人，除非没有业务可说），工作流就是将运行过程中的业务过程的环节、路由、资源、岗位、人员、权限等信息抽象出来，并相应组织，利用驱动引擎将配置信息跑起来的一个过程，不过细节追踪就是技术问题了，如何让他可以并行运行和加快速度，我只能说这还是设计问题（技术设计），设计得好就会成倍提速，设计得不好往往会适得其反。

其实要一个进步的诀窍，就是不要妄下结论，不论达到什么境界，遇到任何问题都要想一下，思考一下全局观，将逻辑层抽象，大部分系统的业务层其实并不复杂（业务和逻辑并不完全一样，可以说业务包含逻辑吧，我们要做的就是首先将业务中的逻辑抽象出来，并将相应逻辑进行合并和再次抽象，反复思量才下手，时间长了你会发现，你写一行代码就可以搞定一堆事情，而不是写一堆代码搞定一件事情，这样的JAVA层次其实不用多说了，至少是入道了）；其次，一定要coding，优秀的架构师一定要coding（估计这也算是国内和国外的一个区别吧，国内的架构师普遍不做coding），因为只有摸着，而且摸得恨透，设计的时候才会得心应手，而且coding的能力要远远超越普通程序员。

5、书写框架中的一些技巧

上面说了那么多其实对于框架的编写都是废话，因为在框架编写中有诸多技巧性的东西，而反射只是帮助我们解决其中一部分问题，而框架编写中到底有哪些技巧可言呢，这就个人经验和其理论功底而论了，因为经验会在不同行业上产生不同的问题，让人在按照现在所在公司的规范去解决这些问题，而功底是看人悟性以及对于问题的看法是否有把技术抽象出来。

就我个人来说一般有以下一些小经验，请多指教：

编写公司级别的框架：

编写公司级别的框架应当是轻量级的，而不是非常重的框架，这类框架适合开发商做公司业务上的绝大部分项目的基础平台，其包含大量的工具和基础类库，这些代码最好由高手来写，因为它的每一行代码将会决定后来扩展框架的性能和稳定性的基础，这些里面大部分类都是后来要完成的系统的顶层父类、统一接口、组件包、工具等。

编写业务级框架：

在公司级框架基础上不可能一层不变的搬过来照常用，除非公司的框架是按照工具进行开发的，这种产品化容易做到，但是整体体系容易分散，关键看管理了。根据通用框架编写业务级别的框架的扩展，这些普遍应用于一个行业领域，根据行业领域有一个实践性的分析，在业务框架中包含大量对于行业内的通用业务处理，并建立业务体系和大量的基层数据结构，并将数据分类，定义相应的缓存和交换法则在框架中实现，在实际的项目中在依赖于业务框架基础上几乎不用做太大的变化就可以实现。

产品化的软件：

软件产品化一般指一个小的子系统，整个体系的产品化需要进一步整合，产品化的软件就是为了以最小的代价实现绝大部分行业类的响应软件需求，开发模式一般以一个集中的方式来方便版本的控制，如果抽象得很好的，会将各个层次抽象为模型，进行设计和研发，在现场基本全是配置化的管理，而没有代码的开发，若弄不好，代码冗余程度很高，还不如不这样做；也有个性化强度很高的，就是做一个基础版本，各个现场使用基础产品来完成实际软件的研发。

性能和稳定性：

在抽象层次的基础上，软件的扩展性很多还要靠程序员的配合来完成，也就是最终还是落实到程序员，但是性能呢？

从系统的层面，系统的性能主要决定于：应用系统的设计、数据库结构设计、数据库架构以及硬件选型、SQL优化等。

在应用开发层面主要关心的是应用系统设计、数据结构设计、SQL优化，而应用系统设计主要就是框架的设计，哪些是做缓存处理、如何做缓存处理、输出压缩、提供共享操作高效且低BUG的代码、如何充分利用多线程、如何通过框架降低BUG的概率、如何充分利用CPU、如何解决IO瓶颈（从代码策略和配置两方面）、如何负载均衡、失败切换等都是我们需要考虑的问题，如果有必要还会去考虑内存通信等。

其次就是数据结构设计，数据结构设计将会决定在绝大部分情况下数据库的查询性能的长期目标，如果结构设计得不好，数据量一上来，马上非常慢，怎么优化SQL也都是治标不治本的方法，通常这个需要在结合业务经验的基础上，要有一些数据库体系结构思想。

最后才是SQL优化，当然对于程序员来说这是最重要之一，因为前面的不管程序员的事情，除了编写一点多线程（最好在框架中分出来，而不是让程序员去编写），程序员只关心业务过程的编写，以及如何使用框架提供的基础类库来完成这些业务编码。而SQL呢，SQL程序员是必备掌握的，而且也是一门很深的学问，可以说简单，也可以说复杂，要研究进去很多事情很不好解释，不研究这些东西就显得就那么回事，SQL基本要达到从开始掌握语法会写SQL开始、如何变换SQL改善性能、如何查找复杂SQL中的逻辑可合并的部分进行合并、如何通过体系结构的学习通过本质和提供的方案来解决、如何从设计角度规范化统一优化方法等等，逐步的一个过程。
———————————————
原文链接：https://blog.csdn.net/xieyuooo/article/details/5717073