前言本文将介绍与AspectJ以及与其相关的内容，各方面内容的侧重点会有所不同，AspectJ将会进行详细的介绍，而其他方面的内容则重点在于辅助理解AspectJ的原理，便于更好地掌握AspectJ。 在Android中你要使用AspectJ，那么你就要懂得注解，要理解AspectJ的实现你就要懂得APT与动态代理，为什么要使用AspectJ你就要理解AOP与OOP的区别，这些不仅仅是学习AspectJ的基础，同时也是深入理解AspectJ必须掌握的要点。同时AspectJ只是一个框架，一个帮助你更好地实现AOP的框架，所以重点不仅在于学习框架的语法和应用，更应该包括框架中所蕴含的思想。 注解概述由于本文重点在于介绍AspectJ，所以这里就只着重讲解注解在AspectJ中应用。关于注解的详细介绍，我有写了另一篇文章Java注解的基础与高级应用。 在开发Java程序，尤其是Java EE应用的时候，总是免不了与各种配置文件打交道。以Java EE中典型的S(pring)S(truts)H(ibernate)架构来说，Spring、Struts和Hibernate这三个框架都有自己的X ...

概述在开发Java程序，尤其是Java EE应用的时候，总是免不了与各种配置文件打交道。以Java EE中典型的S(pring)S(truts)H(ibernate)架构来说，Spring、Struts和Hibernate这三个框架都有自己的XML格式的配置文件。这些配置文件需要与Java源代码保存同步，否则的话就可能出现错误。而且这些错误有可能到了运行时刻才被发现。把同一份信息保存在两个地方，总是个坏的主意。理想的情况是在一个地方维护这些信息就好了。其它部分所需的信息则通过自动的方式来生成。JDK 5中引入了源代码中的注解（annotation）这一机制。注解使得Java源代码中不但可以包含功能性的实现代码，还可以添加元数据。注解的功能类似于代码中的注释，所不同的是注解不是提供代码功能的说明，而是实现程序功能的重要组成部分。Java注解已经在很多框架中得到了广泛的使用，用来简化程序中的配置。 因为注解大多都有自己的配置参数，而配置参数以名值对的方式出现，所以从某种角度来说，可以把注解看成是一个XML元素，该元素可以有不同的预定义的属性。而属性的值是可以在声明该元素的时候自行指定的。在 ...

前言最早开始写个人博客是在14年的8月，那时候大三刚结束正在实习的阶段，用的平台是csdn，那时候csdn博客的排版还只能繁琐地选择标题一标题二标题三，断断续续写了二十几篇便弃坑了。后来接触了简书、WordPress等平台，在接触了MarkDown之后便踏上了一条不归路，如果在世上只能用一种方式排版，那我选择MarkDown，还有现在csdn也支持mardown，可能两年多前也支持只是我不知道？但是作为一个爱折腾的程序员，什么事情都想自己来，更倾向于拥有完全可定制化的独立博客，如果还有一个个人域名就更酷了，无疑是让自己坚持更新博客的最大动力。本篇文章将会从开始打算创建一个独立博客开始到实现几乎你想要的所有定制化功能为止，详细地罗列出各个步骤。如果你对默认配置满意，只需几个命令十几分钟便可以搭出一个个人博客；如果你喜欢折腾，那么几小时到几个月都可以让你玩得尽兴。大致的步骤就是建议Github Pages上的个人主页，然后再本地使用hexo进行博客的初始化构建，这样就可以开始写博客了，其他的如绑定自己的域名，定制化自己的更多需求则属于锦上添花的事情。 Github Pages首先你需要到G ...

前言本文将结合实际谈谈23种设计模式，每种设计模式涉及 定义：抽象化的定义与通俗的描述，尽量说明清楚其含义与应用场景 示例：如果项目中有使用过该模式，则会给出项目中的代码，否则会给出尽可能简单好理解的java代码 Android：该设计模式在Android源码框架中哪些地方有使用到 重构：项目中是否存在可以用该模式进行重构的地方，如果已经进行过重构会给出重构前与重构后的代码，没有就给出思路 用这种方式进行介绍设计模式，旨在结合每天都在接触的内容来更好地理解设计模式，拉近与设计模式的距离，同时在实际项目中，思考可以应用的重构手段与设计模式，既能保证写出复用性与可靠性更高的代码，也是对如何利用重构与设计模式进行优雅编程的最佳实践与总结。同时一次性以这种方式介绍23种设计模式，也是出于既然要使用一个模式，那么就应该要先知道这么一个模式的想法，当然也可以在平常开发中自我总结，毕竟设计模式很大程度上也是对经验的归纳，但是有四人帮等巨人托着你上去，又何必自己再摸黑造梯子。 重构不是本章的重点，因为这也是一个非常大的话题，这边只讨论实际项目中是否有存在一些能用设计模式进行改善的地方。关于重构，这 ...

什么是重构所谓重构是这样一个过程：在不改变代码外在行为的前提下，对代码作出修改，以改进程序的内部结构。本质上说，重构就是在代码写好之后改进它的设计。重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。重构（动词）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。重构的目的是使软件更容易被理解和修改。重构不会改变软件可观察的行为——重构之后软件功能一如既往。而重构技术就是以微小的步伐修改程序，如果你犯下错误，很容易便可以发现它。 为何重构 重构改进软件设计 只为了短期目的或者在完全理解整体设计之前编写出来的代码，会导致程序逐渐失去自己的结构。这时如果没有重构，程序的设计会逐渐腐败变质，程序员愈来愈难通过阅读源码而理解原本设计。重构很像是在整理代码，你所做的就是让所有东西回到应该的位置上。代码结构的流失是累积性的。愈难看出代码所代表的设计意涵，就愈难保护其中设计，于是该设计就腐败得愈快。经常性的重构可以帮助代码维持自己该有的形态。 重构使软件更容易理解 所谓程序设计，很大程度上就是与计算机交谈：你编写代码告诉 ...

前言该文为自己在公司做Android单元测试分享时的概要描述，可能缺少一些必要的描述，后续整理 什么是单元测试一般的定义，尤其是是在OOP领域，是一个类的一个方法。在此，我们也这样理解：单元测试，是为了测试某一个类的某一个方法能否正常工作，而写的测试代码。常见的Java单元测试框架有JUnit、TestNG等等。我们使用Junit。 单元测试不是集成测试集成测试也是有他的必要性的，然而这不是我们每个程序员应该花多少精力所在的地方。 集成测试的缺点：集成测试设置麻烦，运行速度慢，发现bug少，在保证代码质量，改善代码设计方面起不到作用。集成测试往往不能测试到其中每个环节的每个方面，某一个集成测试通过了，不代表另一个集成测试也能运行正确。而单元测试会比较完整地测试每个单元各种不同状况、临界条件等等。一般来说，如果每个环节都对的，那么很大概率上，整个流程就是对的。 再来谈谈为什么 对软件质量的提升 方便重构 节约时间 提升代码设计 。。。 自己为什么写单元测试？ 如果有一个工具可以告诉自己每次写的新代码或者改动的代码哪里会有问题，可以为自己代码的质量提供保障，那就可以增加自己对所写代码的 ...

前言关于重构的一些话该文章可以作为项目初期架构选型时的参考，也可作为项目开展一些阶段之后进行重构的参考，所以首先扯点题外话：为什么我们需要重构？ 重构改进软件设计只为了短期目的或者在完全理解整体设计之前编写出来的代码，会导致程序逐渐失去自己的结构。这时如果没有重构，程序的设计会逐渐腐败变质，程序员愈来愈难通过阅读源码而理解原本设计。重构很像是在整理代码，你所做的就是让所有东西回到应该的位置上。代码结构的流失是累积性的。愈难看出代码所代表的设计意涵，就愈难保护其中设计，于是该设计就腐败得愈快。经常性的重构可以帮助代码维持自己该有的形态。 重构使软件更容易理解所谓程序设计，很大程度上就是与计算机交谈：你编写代码告诉计算机做什么事，它的响应则是精确按照你的指示行动。你得及时填补“想要它做什么”和“告诉它做什么”之间的缝隙。这种编程模式的核心就是“准确说出我所要的”。除了计算机外，你的源码还有其他读者：几个月之后可能会有另一位程序员尝试读懂你的代码并做一些修改。我们很容易忘记这第二位读者，但他才是最重要的。计算机是否多花了几个小时来编译，又有什么关系呢?如果一个程序员花费一周时间来修改某段代 ...

简介自动化测试：一般是指软件测试的自动化，软件测试就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。黑盒测试：黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。白盒测试：白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白 ...

为什么需要并发并发其实是一种解耦合的策略，它帮助我们把做什么（目标）和什么时候做（时机）分开。这样做可以明显改进应用程序的吞吐量（获得更多的CPU调度时间）和结构（程序有多个部分在协同工作）。 对于并发的误解和正解最常见的对并发编程的误解有以下这些： 并发总能改进性能（并发在CPU有很多空闲时间时能明显改进程序的性能，但当线程数量较多的时候，线程间频繁的调度切换反而会让系统的性能下降） 编写并发程序无需修改原有的设计（目的与时机的解耦往往会对系统结构产生巨大的影响） 在使用Web或EJB容器时不用关注并发问题（只有了解了容器在做什么，才能更好的使用容器） 下面的这些说法才是对并发客观的认识： 编写并发程序会在代码上增加额外的开销 正确的并发是非常复杂的，即使对于很简单的问题 并发中的缺陷因为不易重现也不容易被发现 并发往往需要对设计策略从根本上进行修改 并发编程的原则和技巧单一职责原则分离并发相关代码和其他代码（并发相关代码有自己的开发、修改和调优生命周期）。 限制数据作用域两个线程修改共享对象的同一字段时可能会相互干扰，导致不可预期的行为，解决方案之一是构造临界区， ...

简介单元测试是先mock一些正常边界异常条件来对接口进行操作，并且期望接口返回什么内容，最后接口实现了之后再重新测试一遍。TDD：Test-Driven Development，测试驱动开发模式——旨在强调在开发功能代码之前，先编写测试代码。开发未动，测试先行。为什么我们要进行单元测试：最后才修改一个 bug 的代价是在 bug 产生时修改它的代价的10倍。——《快速软件开发》测试任何可能的错误。单元测试不是用来证明您是对的，而是为了证明您没有错。单元测试是编写测试代码，用来检测特定的、明确的、细颗粒的功能。单元测试并不一定保证程序功能是正确的，更不保证整体业务是准备的。单元测试不仅仅用来保证当前代码的正确性，更重要的是用来保证代码修复、改进或重构之后的正确性。 JUNITJUnit 是由 Erich Gamma 和 Kent Beck 编写的一个回归测试框架（regression testing framework）。JUnit 测试是程序员测试，即所谓白盒测试。它是一个 Java 语言的测试框架，多数 Java 的开发环境都已经集成了 JUnit 作为单元测试的工具。 特性 用于测 ...