推荐书籍
架构整洁之道、敏捷之道、整洁的程序员、面向模式的软件架构、设计模式等……
编程的道与术
问题——
“人法地，地法天，天法道，道法自然。”
大泥团架构：业务行的代码和技术性的代码混合在一起。没有什么封装。缺乏清晰的结构。难以理解、测试、维护、扩展。
复杂性：多样、耦合（长耦合，宽耦合，空间耦合，实践耦合），变化。
方法：多样：单一职责。耦合：面向接口编程。
架构需要解决的：多样，耦合，变化。
有序的复杂性
软件开发和扩展过程总是倾向混乱的。
通过定义和维护架构来时系统保持井然有序。
架构设计为复杂性引入秩序。
结构比组成更重要。
庖丁解牛：模块化。
架构视图
逻辑视图：对系统进行业务分解。
开发视图：对系统进行子系统分解。
物理视图/部署视图：
进程视图：
场景视图/用例视图
（想起了大学侯爱民教授教的《面向对象与设计》、UML的课程、以及其中的知识点和思想……）
聚合原则、耦合原则、抽象、封装与分解……（六大设计原则（着重讲到了依赖倒置原则）、设计模式）
分离业务与技术
通过一个适配器层，使用技术组件中的类实现业务组件中定义的接口？具体怎么做？
分离礁石与浮沙：稳定与异变
1.接口/抽象类是稳定的，具体类是异变的。两者应该分解道不同的组件中。
（个人思考：一个类，稳定的和异变的分开。那么整个要怎么凭借起来。使用builder模式建造起来，或者使用一个装饰着，再或者用一个中介者，或者用一个适配器，（嗯嗯，又想到了啥，没错，还是设计模式。））
2.策略是稳定的，机制是异变的。两者应该分解到不同的组件中。
分离大理石与木头：纯粹与杂合
1.要让基础组件尽可能保持纯粹。相互之间不要直接耦合。
2.创建一个杂合的组件，耦合到两个基础组件。
3.在一个杂合的组件中建模实现两个基础组件的关联关系。
例子：雇员，用户，雇员用户类（继承用户，同时关联雇员）。
例子：订单，流水账，展示数据和余额。
分离策略与细节（策略模式）
抛出问题：什么是实现细节？
然后，杨教师开始说到以下的点：
维度、层级与范围；业务与技术之间、领域特定与领域无关。
依赖关系：扇入依赖与扇出依赖。
他说了一个我从来没有意识到的点：“数据库是实现细节。”他说，数据库不应该是一个架构搭建最先考虑的问题。
架构风格
从N层架构到Clean架构——从上下结构到内外结构。
从微服务架构——对齐开发视图、逻辑视图、部署视图和进程视图。
架构分离：横向（技术）——纵向（业务）——横向（技术）
个人理解：比如，在Android项目中，MVP/MVVM包裹整个项目——模块化、组件化开发——业务module开发——MVC/MVP/MVVM模式包裹每个module——通过各种设计模式再具体分离业务和技术。
文尾个人总结
1.教授所说的，其实更多是从后端的架构的角度阐述。当然，很多思想都是互通的。确实，对我的编程思想影响挺大。
2.那么，从Android开发的角度，我该怎么做呢？其实，我们现在流行的MVP/MVVM以及其他的几种设计模式和设计原则熟练到精通掌握，然后，多读Android 的源码，暂且就够我现在使用（毕业一年多了）。
3.得找个时间，需要花点精力，将文首提到的一些书籍学习一下。
4.“世界是很简单的，就如同爱因斯坦最出名的公式:E=mc²。”将问题复杂化，然后再抽象化，多思考，多总结，继续提升自己，加油。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
