按照计划，题目中本来是要写两篇相关的文章的，但是考虑到每一篇的内容可能会很少。 索性就凑到一起了。
aop面向切面编程。 之前的笔记中写过它的一些相关的介绍。 不知道准不准确的一个自己的直观的理解就是： 动过动态代理，使得一个接口的设计能够与它的实现类异步进行。 它不是一种新的技术，而是一种开发遵循的规范。 其所折射的是一种整体观。
更加抽象一下就是所谓的框架，或者架构吧！ 。
这里想要说的就是这种规范对我们所带来的影响，或者对于我们开发的重要性：
1.当我们有了一个项目后，可以从整体上考虑，同时又能尽量细化，比如它对应功能的接口有哪些， 这些接口和交互方式是怎样的等。 其实也就是接口开发了。
2.当我们发现有需求需要变更时，可以从接口入手，也是一个健壮的程序开发者必须考虑，应该考虑到的问题。 并且通过反射机制，我们已经极大程度的进行了解耦，修改起来不至于太过痛苦。
3.不遵循好的设计规范的话，可能会出现几种情况：
对工期预算出错，导致定期安排的计划交不出成果，最终酿成苦果只能自己尝；
如果没有外部压力的话，自己可能会放弃。 因为要完成的工作量具有未知性，和逻辑不清晰。
对于开发中某一个步骤之后将要进行的步骤之前知道，但是由于过了一段时间后忘了。咋办。
如果项目将要进行功能的修改，或者重构，或者debug。 如何快速定位将要操作的块。
然后说说自己在实践中遇到的阻力：
有些接口如果直接拿出的话可能比较愁，因为很细，很多。 尤其是对于我们这些菜鸟。 没有见过大世面的。
1.想到的处理方法有： 将项目进行分解，按照子系统的方式划分给 同等级（广义，指知识体系，实践能力等）的合作者进行协作，否则还不如自己一个子系统子系统的进行开发。 只不过这样的必要的就是延长工期，宇宙人都知道，这也符合 能量守恒定律吧。 然后根据单个子系统进行接口的架构设计
2. 找到各种理由，（比如Money,零食，美女啥的)说服自己，进行接口开发。
3.不进行接口开发，就从局部入手，有能力与信心完成整个项目，（针对于具有丰富开发经验的人员），或者具有足够的准备做好了一旦做不好就跑路的准备（针对于我们这种菜鸟）。
当然以上的问题对于实际在职场真刀真枪上阵杀敌的前辈来说自然不是什么问题，但是对于我来说却还是认为至关重要的。 因为到目前为止我都不知道自己有多少个想做些什么，最后一阵激情之后就放弃的情景了。 甚至怀疑自己能不能好好做成功一件事情了，这也存在一个悖论，那就是我们之所以不断尝试，不断切换，是因为没找到最适合自己的。 所以啊，人啊。 尤其是年轻人啊！
女人：呵，男人！
----------------------------------------------------------------------------------------------------------------------------------
下一个主题就是：作为网站开发中，java语言的被替换性：ruby,python,php等
现在用的较多主流的网站开发的架构为：MVC,即模型，视图，控制器。
控制器统筹着模型 和 视图同步，使得形成一个网站系统架构。
看看java中的担任该体系的各个层次，采用的架构比较著名的有：
SSH:Struts 做控制器，spirng做模型（不知道是不是），Hibernate做持久层orm框架的实现，视图应该就是Html吧。
SSM:SpringMvc做控制器，spring做模型（或者说容器吧，不知道准确不），Mybatis做orm框架的实现。 视图依然是html。
springBoot,因为它网站开发的时候会依赖spring-webmvc，所以应该也是符合该设计规范的。
（不遵循MVC的就不说了。）
很久以前有幸用过SSH,进行了一些实例的练习，不过那会自己实在是太白了，所以跟没用过么啥两样。
比较近的一段时间用过 SSM,并且进行了较为详细的配置。以及基于此的一些练习。
spirngBoot就更加不说了。 因为它简化配置，算是一个比较良心的产品了，也很好用，自然用的不少。
众所周知，它们将后台开发中分为了三个部分（controller,service,dao),或者说（controller,service，mapper)。（当然对于没有前后端分离的架构中来说，视图分发的部分自然不考虑了）。 它们进行了一个比较细的划分，逻辑上面也很好分，并且通过spring的ioc容器实现了很好的解耦效果。 但是怎么说呢，可能还是自己的见识比较少的原因，当人数较少或者说团队不够成熟，或者说公司不够大时，但是面临的开发任务又相对较大时，心情总是十分的压抑 与 沉重。
因为此时有一些前提条件哈，公司不够大，团队不够成熟，面临的开发任务相对较大，想以一己之力来进行开发，有些吃力了。 并且换个角度来说，网站开发为了什么？？ 、 将之抽筋扒皮，不就是将一些json以我们想要的方式存进数据库，然后从数据库取出，以我们想要的方式显示给页面嘛。。如果可以的话，我们希望用户直接操作它自己的数据库就好了（当然这在实际运用中几乎不可能）。 所以才有了这些中间的处理，转换，控制等。
但是最终不就是为了实现效果吗? 尤其针对一些不是很大的企业，就像我们学校之于211，985高校一样，显得那么的懦弱与 苍白。 但是毕竟占大多数啊。。 所以从需求来说，这部分需求是要远高于大型企业的大型项目的。
其实最近已经火了好一段时间的敏捷开发，不正是基于此吗？（猜的）。就是以最小的代价，最快的速度达到需要的效果。 php，大家应该听的比较多，它的执行时基于解释执行的好像，它的执行依赖于一个php的解释器运行，在页面中嵌入php语句，以达到动态原因效果。 跟jsp有点像，但是又有区别。 因为jsp最终是要被编译成servlet的，就是不知道php会不会经过编译了。 应该不会吧，比较它是解释执行的呢。 没细了解。如果错误万望见谅。 因为太晚了有点疲，就懒得查资料。 同时它提供了数据库的相关操作类，以及实现了一些网络编程的一些东西。 另外两个 ruby,和python也是比较红的语言了，各自都有自己的历史。 它们即是面向对象，又是面向过程的语言。 并且它们的也提供了一套网站开发的完整生态。 （如数据库的操作，网络编程等支持）。 同时它们还有各自的框架，如python的django,ruby的rails，使得单人完成大型系统成为了可能。 并且本身作为一门高级语言来讲，它能存在这么久，并且能别人们熟知，本身已经说明了它们各自的科学性，可行性。 所以不用担心诸如崩溃，暂停更新之类的问题。
当然，它牺牲了哪些呢？ 所谓有得必有失嘛！ 首先解耦能力降低，可扩展性，可维护性降低。 对于大型企业来说，或者说对于网站要求比较严苛的企业应该是不能接受的。 其次，它的可读性降低，不易进行二次开发。 然后，它所获得第三方支持应该是没有Java丰富的。
但是不可否认，在某些场合下，javaEE开发还真有被代替的可能性。 其它不说吧，就说找工作方面，php的工作还是好找的，毕竟java憎多粥少嘿嘿。 可惜的是自己还没有着手去练习这方面的技术。 实在是知识的海洋太宽广，前辈的智慧太精妙。
以上言论纯属一家之言，十分片面。 如有冒犯或者错误，万望见谅！