Lighthouse

前言文大部分内容翻译总结自《Software Engineering at Google》 第10章节 Documentation,一直坚持写技术文档，进步一直不大。每次书写相关工具类或者三方sdk配套文档，草草写完，阅读量也少的可怜。科学学习书写文档，做好日常技术积累，定期进行输出很多技术人自己非常轻视技术文档的书写，然而又时常抱怨文档不完善、质量差、更新不及时…… 这种在程序猿间普遍存在的矛盾甚至已经演变成了一个段子。文档的重要性高质量的文档对于一个组织或团队来说有非常多的益处，比如让代码和AP

前言基础架构好坏直接决定所开发项目未来的稳定性、可伸缩性。在jetpack 框架出来之前应用架构大部分是从网络上东拼西凑出来的产物，没有考虑日后维护.对于google官方提供的应用架构原则，应该认真研读。应用架构定义了应用的各个部分之间的界限以及每个部分应承担的职责架构务必要能允许应用扩缩、提升应用的稳健性并且方便对应用进行测试常见的架构原则如果您不应使用应用组件存储应用数据和状态，那么您应该改为如何设计应用呢？随着 Android 应用大小不断增加，您定义的架构务必要能允许应用扩缩、提升应用的

前言很多项目中进行会出现，一个状态对应一种现实样式。是统一在一个界面处理，还是分开n多页面处理呢， 这篇给出了一点个人建议，及是实现方案。效果图方案一： 一个activity 全部进行控制。所有的状态。完全靠堆代码。（不推荐） 方案二 一个activity 中包含BaseFragment 然后 subfragment中实现不同状态。（推荐） 方案3 … …方案

通过前面两篇，我想各位朋友对“面向接口编程”的思想有了一定认识，并通过第二篇的例子，获得了一定的直观印象。但是，第二篇中的例子旨在展示面向接口编程的实现方法，比较简单，不能体现出面向接口编程的优势和这种思想的内涵。那么，这一篇作为本系列的终结篇，将通过分析几个比较有深度的模式或架构，解析隐藏其背后的面向接口思想。这篇我将要分析的分别是MVC模式和.NET平台的分层架构。 这篇的内容可能

问题的提出定义：现在我们要开发一个应用，模拟移动存储设备的读写，即计算机与U盘、MP3、移动硬盘等设备进行数据交换。 上下文（环境）：已知要实现U盘、MP3播放器、移动硬盘三种移动存储设备，要求计算机能同这三种设备进行数据交换，并且以后可能会有新的第三方的移动存储设备，所以计算机必须有扩展性，能与目前未知而以后可能会出现的存储设备进行数据交换。 各个存储设备间读、写的实现方法不同，U盘和移

前言 做app开发也几年时间了，一直徘徊在初中级阶段，对一些架构知识很欠缺，尤其是设计模式和java 三大特性深入理解，封装、继承、多态。这几篇文章的确很有启发，每次看都会有新的理解，在此分享出来，一起进步。我想，对于各位使用面向对象编程语言的程序员来说，“接口”这个名词一定不陌生，但是不知各位有没有这样的疑惑： 接口有什么用途？ 它和抽象类有什么区别？ 能不能

1.Adapter复用，项目中需要写很多的 adapter 适配器 重复代码，就想着可以进行代码复用，减少重复码代码的时间。 2.参照之前的版本进行优化。先贴上 版本1代码。public abstract class NyBaseAdaper<T> extends BaseAdapter { protected List<T> list = new ArrayList<>(); pr