充血模式即领域驱动设计(Domain Driven Design, 简称 DDD)
贫血模式 在之前我们写一篇关于贫血模式的文章, 点击查看.
贫血模式是目前主流的一种开发模式, 基于MVC结构的开发模式.
MVC三层架构中
M 表示 Model 即数据层 V 表示 View 即展示层 C 表示 Controller 即逻辑层 做为后端开发MVC有所调整
1. Model 层 负责数据访问
2. Service层 负责业务逻辑
3. Controller层 负责暴露接口让.皮亚杰 瑞士人，近代最有名的发展心理学家，他的认知发展学成为了这个学科的典范。
20世纪最伟大的心理学家. 与弗洛伊德称为心理学史上两位巨人。
主要贡献是对儿童的心理发展做了全面的解释, 不同于成熟论与外铄论, 这些理论都不足以让人信服, 直到让.皮亚杰提出认识发展理论提出.也称之为建构主义.
皮亚杰认为孩子的认知不是被动的,而是个体与环境相互交互的时候形成的, 孩子们都是天生的科学家与哲学家. 他们有一套非常神奇的认识外界的方法. 就象小树苗一样是有所选择的接受外界的营养.
理论 图式理论 认知发展的核心理论.
孩子从婴儿时期什么也不懂, 只知道喝奶, 这叫遗传图式, 而有一个人总是给他喂奶, 建立起妈妈的概念, 妈妈就是总喂奶的那个人. 就这样通过外界不断刺激下建构成自己的一个一个的图式.
图式主要是通过外界对自身的刺激在自己的大脑里形成一个个概念, 即是建构图式
Tip: 图式具有对客体信息进行整理,归类.改造和创造功能,以使主体有效地适应环境.
同化理论 同化过程是对图式量的提升
同化是指遇到外界刺激后他们尝试着使用自己的这个图式去理解外界, 希望把外界纳入到原有的图式之中. 这个过程称之为同化
例: 如对狗的认识, 如吉娃娃狗的图式概念, 知道他长着四条脚, 一个尾巴, 会旺旺的叫, 下次遇到哈士奇, 就会使用这个图式解释他,也就是说他会把这个图式进行同化成为之前图式的一部分, 图式也得到的发展与巩固. 但是遇到一只猫时, 他使用同样的方式解释时, 妈妈告诉他这不是一条狗, 是一只猫. 这个时候孩子就混乱啦, 然后旁边的妈妈解释给他听, 猫的嘴巴上有长长的胡须, 还会喵喵的叫, 这个叫猫. 此时孩子会在大脑中重新构建新的图式概念, 这个过程是一种顺应.
同化是一个非常重要的概念, 只有对一个图式不断的同化,得到量的积累, 才会得以建立更加完善, 更加巩固. 成年人学习一个新知识也是一样, 需要不断的同化过程, 也就是需要做相关练习, 多加应用, 得到更多的同化过程, 你的知识图式才会更加牢固完美.
同化过程是对图式量的提升
Tip: 中国俗语称: 熟能生巧.
顺应理论 构建新图式的过程
外界的刺激不可能永远可以用同样的图式去解释，顺应是指同化失败后, 产生混乱时重新构建新的图式的一个过程. 如上面所说的猫的认识过程.朴实定律 程序应该熟悉的常用定律法则
二八定律 二八定律是指在任何一组东西中, 最重要的只占其中一小部分, 约20%. 其余80%尽管是多数, 却是次要的.
如世界上的财富分配也属于二八定律, 20%人的撑握着世界80%的财富.
工程定律 海恩法则 是德国飞机涡轮机的发明者德国人帕布斯.海恩提出的一个在航空界关于飞行安全的法则.
海恩法则: 指任务不安全事故都是可以预防的.
海恩法则强调两点:
一是事故的发生是量的积累的结果 二是再好的技术, 再完美的规章, 在实际操作层面, 也无法取代人自身的素质和责任心. Tip: 软件行业也是如些, 生产上的程序出现故障, 也符合海恩法则.
墨菲定律 事情往往会向你所想到的不好的方向发展.只要有这个可能性.
比如你衣袋里有两把钥匙, 一把是房间的, 一把是车的, 如果你现在想拿车钥匙, 会发生什么呢?是的, 你往往是拿错了房间钥匙.
Tip: 如果做某项工作有多种方法, 而其中一种方法将导致事故, 那么一定有人会按这种方法去做.
康威定律 设计系统的架构受制于产生这些设计的组织的沟通结构
— M.Conway
即系统设计本质上反映了企业的组织机构.
系统各个模块间的接口也反映了企业各个部门之间的信息流动和合作方式.
Tip: 系统设计的结构必定反映其团队的组织结构
管理定律 SMART 原则 Smart 原则是目标管理中的一种方法.
由五个字母组成
S (Specific) 明确性: 指目标必须是明确的, 具体的.不能笼统. M (Measurable) 可衡量: 目标可以量化, 有计划的, 数据支撑. A (Achievable) 可达成: 付出努力的情况下可以实现你的目标, 避免设立过高或过低的目标. R (Relevant) 相关性: 指目标与那些还有关联, 需要配合, 辅助你完成目标.技术书籍 推荐参考: «豆瓣编程图书TOP10»
程序员修炼之道(第2版) 豆瓣分:9.0
原英文名«The Pragmatic Programmer» 直译为: 务实的程序员, 即靠谱的程序员.
这是一本如同航海的指南般的书, 被一代代开发者奉为圭臬.
已经出版20年啦, 当之无愧的"道", 可惜在国内出现各种修炼之道相关的书籍, 内容干货少之又少, 实在汗颜.
深入理解计算机系统(第2版) 豆瓣分: 9.7
原英文名Computer Systems: A programmer’s Perpective
工程师人人必读之书, 没有之一.
本书最大的优点是从程序员的视角详细阐述计算机系统的本质概念.
主要包括: 1. 信息的表示和处理 2. 程序的机器级表示 3. 处理器体系结构 4. 优化程序性能 5. 存储器层次结构 6. 链接 7. 异常控制流 8. 虚拟存储器 9. 系统级I/O 10. 网络编程 11. 并发编程
Tip: 书比较厚, 读之前做好心理准备, 打硬仗.
代码大全(第2版) 豆瓣分: 9.3
原英文名称«Code Complete» 完成代码, 是一种教你如何一步一步完成开发.
这本书覆盖了软件全过程, 从需求分析, 系统架构,设计到具体编码规范, 编码技巧, 整个项目的生命周期. 是一部软件构建的百科全书.
重构:改善即有代码的设计(第2版) 豆瓣分:9.有一种非常经典的设计原则: 组合优于继承, 多用组合少用继承
为什么少用继承 继承是面向对象的四大特性之一, 表示类之间的 is-a 关系. 支持多态特性, 可以解决代码复用问题.
如果继承层次过深, 过复杂, 会影响到代码的可维护性, 可读性.
如上面, 继承带来的后果就是代码变得复杂, 因为层次过深, 继承关系过于复杂, 影响到代码的可读性与可维护性.
组合的优势 可以利用组合(composition), 接口(interface), 委托(delegation) 三个技术手段解决继承的问题.(如上面的问题)
利用接口实现多态特性
利用组合和委托实现代码复用问题
通过组合, 接口, 委托三个技术手段完全可以替换掉继承.
Tip: 在项目中不用或少用继承关系, 特别是一些复杂的继承关系 .
什么时候使用继承还是组合 一个技术的出现, 一定是有他的用武之地, 并非一无是处.
当类之间的继承结构稳定, 继承层次比较浅(最多有两层继承关系), 我们可以大胆使用继承.
当类之间的继承结构不稳定, 复杂, 继承层次又深,我们尽量考虑使用组合来替代继承
哪些设计模式使用了继承?
装饰者模式(decorator pattern) 策略模式(strategy pattern) 组合模式(composite pattern) 哪些设计模式使用了组合?
模板模式(template pattern)何为"接口"编程 基于接口而非实现编程.
英文: Program to an interface, not an implementation
这条原则是一条比较抽象,泛化的设计思想.
接口的本质: 接口就是一组协议或者约定, 是功能提供者给使用者的一个"功能列表"
接口编程 这条原则能非常有效地提高代码质量.
接口编程是将接口与实现相分离, 封装不稳定的实现, 暴露稳定的接口.
上游系统面向接口而非实现编程, 不依赖不稳定的实现细节. 当实现发生变化的时候, 上游系统基于上不需要做改动, 以些来降低耦合性,提高扩展性.
在软件开发中, 最大的挑战之一就是需求的不断变化, 这也是考验代码设计的好坏的一个标准.
越抽象, 越顶层,越脱离具体某一实现的设计, 越能提高代码的灵活性, 越能应对未来的需求变化.
好的代码设计, 不仅能应对当下的需求, 而且在将来需求发生变化的时候,仍然能够在不破坏原有代码设计性况下奶灵活应对.
而抽象就是提高代码扩展性, 灵活性, 可维护性最有效的手段之一
接口编程要点 函数的命名不能暴露任何实现细节 封装具体的实现细节 为实现类定义抽象接口. Tip: 做开发的时候, 一定要有抽象意识, 封装意识, 接口意识. 在定义接口的时候, 不要暴露任何实现细节.
接口的定义只表明做什么, 而不是怎么做.
什么时候使用接口 任何事物都有两面, 一味使用接口编程会导致不必要的开发负担.具体要搞清楚我们为了解决什么问题.
如果业务场景中, 某个功能只有一种实现方式, 未来也不可能被其它实现方式替换,则我们没必要设计接口.也没必须基于接口编程.直接使用类即可.
如果业务场景中, 某个功能可能被两种以上, 不贫血开发模式 传统的MVC结构分为: Model 层, Controller 层, View层.
而做为前后端分离的MVC变为后端被分为: Controller, Service, Model 层.
Controller 层负责暴露接口给前端调用. Service 层负责核心业务逻辑 Model 层负责数据读写 以上为典型的面向过程的编程风格.也称为分血模式的开发模式
这也是我们现在非常常用的一个 Web项目的开发模式.
Tip: 与之相对是充血开发模式即DDD, 也称领域驱动设计
面向过程VS面向对象 面向过程编程风格是一种符合我们人脑思维方式. 如同在生活中, 你去完成一个任务:
先做什么 后做什么 最后完成整个任务 面向对象编程风格是一种自底向上的思维方式, 它不是先去按照执行流程来分解任务:
先将任务翻译成一个一个小的模块(也就是类) 然后设计类之间的交互 最后按照流程将类组装起来 完成整个任务 面向过程与面向对象是互相协作完成整个项目的
面向过程编程是面向对象编程的基础 面向对象编程离不开基础的面向过程编程. 如一个方法的实现逻辑即是一个面向过程的逻辑. Tip: 我们编程最终的目的是写出易维护, 易读, 易复用, 易扩展的高质量代码.
面向对象编程常见的坑 面向对象的封装特性的本质就是通过设置访问权限隐藏代码
随意设置 Public 权限
解决方法: 慎重使用 Public , 使用之前询问自己 为什么要开放 开放会带来哪些后果. 滥用全局变量和全局方法
从分配内存空间: 全局变量, 静态局部变量, 静态全局变量都在静态存储区分配空间, 而局部变量在栈分配空间. 从作用域来看: 破坏边界, 不利后续调试等. 常用的面向过程场景 编写Shell 脚本. 数据处理 算法为主, 数据为辅.封装, 抽象, 继承, 多态 是面向对象编程语言的四大特性. 而它们又分别承担什么职责呢. 实际编程中起什么作用呢.
封装 (Encapsulation) 封装也称信息隐藏或者数据访问保护. 通过对变量, 函数或类进行设置访问权限.控制它们的对外访问限制.从而保护它们不被随便修改.
作用 封装如同一把智能锁
隐藏信息 保护数据 提高易用性 防止恶意修改 抽象 (Abstraction) 抽象是指如何隐藏方法的具体实现, 让调用者只关心方法提供了哪些功能, 并不需要知道这些功能是如何实现的.
抽象并不需要非得依靠接口类或抽象类这些特殊语法机制来支持. 如类的方法是通过编程语言中的"函数"这一语法机制来实现的, 通过函数包裹具体的实现逻辑, 这本身就是一种抽象. 调用者在使用函数时,只需要了解函数命名, 注释或者文档, 不需要研究函数内部具体实现. 直接就可以使用.
作用 抽象无处不在
简化复杂逻辑 隐藏具体实现 Tip: 抽象是一个非常通用的设计思想, 并不单单用在面向对象编程中, 也可以用来指导架构设计等
继承 (Inheritance) 继承是用来表示类之间的is-a关系.
继承分两种模式:
单继承 一个子类只继承一个父类 多继承 一个子类可以继承多个父类 作用 继承并非一剂良药, 请勿过度使用. 更加推荐"多用组全少用继承"的思想.
代码复用 多态 (Polymorphism) 多态是指子类可以替换父类.
实现多态特性
继承+方法重写 接口类语法 duck-typing 只有一些动态语言才支持, 如python, javascript 作用 多态会72变
提高扩展性 提高复用性 Tip: 多态也是很多设计模式,设计原则,编程技巧的代码实现基础, 如策略模式, 基于接口而非实现编程, 依赖倒置原则, 里式替换原则, 利用多态去掉冗长的if-else语句等等.学习之前先罗列一下学习框架地图. 方便今后的学习.
三种编程范式 面向过程
面向对象(最主流)
函数式编程(如go语言)
面向对象7大知识点 面向对象的四大特性: 封装, 抽象, 继承, 多态 面向对象编程与面向过程编程的区别和联系 面向对象分析, 面向对象设计, 面向对象编程 接口与抽象的区别以及各自的应用场景 基于接口而非实现编程的设计思想 多用组合少用继承的设计思想 面向过程的贫血模型和面向对象的充血模型. 设计原则 SRP 单一职责原则 OCP 开闭原则 LSP 里式替换原则 ISP 接口隔离原则 DIP 依赖倒置原则 其它原则 DRY 原则 Don’t repeat yourself 不要重复自己 出现两次或多次的重复代码就需要提取出来 KISS 原则 Keep It Simple, Stupid 保持简单, 愚蠢 KISS原则使代码简单、清晰、易于理解 编程语言是为人类所理解的 保证你的方法尽量很小； 每个方法都不应该超过40-50行代码 每个方法应该只解决一个小问题，而不是实现很复杂的功能 YAGNI 原则 You aren’t gonna need it 你不会需要它 这是“极限编程”提倡的原则，指的是你自以为有用的功能，实际上都是用不到的。 LOD 原则 迪米特法则（Law of Demeter）又叫作最少知识原则 不和陌生人说话 迪米特法则的初衷在于降低类之间的耦合 门面模式（Facade）和中介模式（Mediator），都是迪米特法则应用的例子 设计模式 经典设计模式有23种.评价常用词汇 描述代码质量所有常用词汇
最常用的评价标准 评价属于主观, 主观的准确度与工程师自身经验有极大的关系. 接下来我们从以下几个维度评价代码, 也是更为常见的维度.
其中可维护性, 可读性, 可扩展性最重要的三个评价标准
1. 可维护性 (maintainability) 易维护的代码是指在不破坏原有的代码设计, 不引入新的Bug的情况下, 能够快速地修改或者添加代码.
不易维护的代码是指修改或者添加代码需要冒着极大的引入新Bug的风险,并且需要花费大量很长的时间才能完成
2. 可读性 (readability) 软件设计大师 Martin Fowler 金句: “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
任何傻瓜都会编写计算机能理解的代码, 好的程序员能够编写人能够理的代码
代码的可读性是评价代码质量最重要的指标之一
我们编写代码的时候, 时刻要考虑到代码是否易读, 易理解.
除此之外, 代码的可读性在非常大程度上影响代码的可维护性.
以下为评介一段代码的可读性的几个维护
编码是否规范 命名是否达意 注释是否详尽 函数是否长短合适 模块划分是否清晰 是否符合高内聚合低耦合 Tip: Code review 是一个很好的测验代码的可读性手段.
3. 可扩展性 (extensibility) 可扩展性也是一个评价代码质量非常重要的标准
它表示我们的代码应对未来需求变化的能力.
易扩展是指在不修改或少量修改原有的代码情况下, 通过扩展方式添加新的功能代码.
不易扩展是指添加一个功能而大动干戈, 改动大量的原始代码.