Design Principles and Design Patterns

本文探讨了软件设计中的关键原则,如开闭原则、依赖倒置原则等,这些原则有助于提高软件的可维护性和灵活性。

设计原则解读。

设计原则是对设计模式的约束性要求,属于设计中基本的四项特征,不符合此四项特征的设计,不具有生命力。

设计模式也是在此四项设计原则上的具体化实例化衍生物。

 

Martin原文:

http://www.cvc.uab.es/shared/teach/a21291/temes/object_oriented_design/materials_adicionals/principles_and_patterns.pdf

 

Architecture and Dependencies

软件最开始的的设计,一般都是完美的,但是往往在软件后续的开发维护过程中,一点点的恶化掉,导致软件软件无法维护。

软件开发维护过程中,对软件的修改又是必不可少的,因为需求的变化是必可避免的,又是变化多样的, 对设计框架的冲击也最大。

后期维护者,由于项目需求的紧急程度,可能在不理解的原始设计的背景下,添加新的需求实现,违背了原始设计,则设计被破坏,后续维护者更加迷惘。

 

Symptoms of Rotting Design -- 设计恶化的特征

Rigidity - 修改困难

新的需求,不好在现有实现上添加代码实现。

Fragility - 脆弱性

新的修改, 牵扯到多个模块,且容易引入bug,导致一连串的修改,又继续扩散, 产品不再信任。

Immobility - 不可移植性

一个大项目,包括若干子功能, 功能见有复用的地方, 但是开发者却无法复用,因为依赖不清晰,拆分功能对原有功能产生影响。

Viscosity - 粘性

设计的粘性 和 环境的粘性

当保持设计的成本比较大, 则设计具有粘性,开发者往往会选择hack的方法,这种方法更加具有破坏性,设计的不好呗。

开发者开发的功能依赖开发环境,难于移植的生产环境,则产生环境的粘性。

 

Changing Requirements -- 变化的需求

不说了, 产品经理被打了,就说名需求的变化到底有多么剧烈。

 

Dependency Management -- 依赖管理

不恰当的模块依赖,加重的系统间的耦合, 导致源码更加难于管理。

合理的依赖防火墙,可以防止系统的设计的恶化。

 

 

Principles of Object Oriented Class Design

  The Open Closed Principle (OCP) -- 开闭法则

A module should be open for extension but closed for modification.

 

Dynamic Polymorphism -- 动态多态

定义抽象的接口,具体的类实现此方法。 高层的逻辑操作逻辑对接口对象进行编程,不对具体类编程。

Static Polymorphism -- 静态多态

编译阶段使用的模板,在编译完成后,静态绑定待操作对象。

 

 Architectural Goals of the OCP

开闭法则,要求设计者具有深刻的洞察力, 分辨出系统中那些部分是变化的,那些部分是不变的, 并将变化的内容,设置出扩展的机制。 例如虚拟接口,虚拟类,允许使用者实现或者替换接口,通过接口添加新的功能, 当然此功能早已经在设计之内,非设计之外的功能不能此类接口的职责之内,如果有则表明,现有设计并不全面。

 

The Liskov Substitution Principle (LSP)

Subclasses should be substitutable for their base classes

 子类可以随时被父类替换。

对于父亲类暴露出去的接口,其实现的功能,  子类应该无条件完全实现, 不多也不能少。

Design by Contract -- 基于契约的设计

理解为面向接口的设计,接口就是使用方 和 实现方的公约,不容变化。

 

  The Dependency Inversion Principle (DIP)

Depend upon Abstractions. Do not depend upon concretions.

 

一般实现,高层依赖中层,中层依赖底层:

每一层的直接依赖,不应该直接产生,应该给予抽象产生,即高层的底层都不应直接产生依赖,

已该生成出一个抽象层,类似接口契约, 高层依赖抽象层的接口,

底层实现抽象层的接口。

 

 

 

 

  The Interface Segregation Principle (ISP)

 Many client specific interfaces are better than one general purpose interface

 对于接口的设计,不要整一个大而全的接口, 因为每个接口都具有不同组织的属性, 更加细分接口更加有利于管理接口, 并实现接口。

统一实现一个接口,则任何接口的变动,都将引起所有使用接口客户端的变动。

 

生动解释见:

https://www.jianshu.com/p/184a90eb3349

 

领域驱动设计(Domain-Driven Design,DDD)是一种软件开发方法论,旨在帮助开发团队更好地理解业务需求,并将其映射到软件设计中。"Patterns, Principles, and Practices of Domain-Driven Design" 是一本介绍DDD的书籍。 该书包含了许多相关的模式(patterns),原则(principles)和实践(practices)。模式指的是可重复应用的最佳实践,通过使用这些模式可以更好地解决一些常见的设计问题。原则则是指导设计决策的基本原则,这些原则有助于开发团队构建可维护、灵活和可扩展的软件。实践则是指在DDD中应用这些模式和原则的具体方法和技巧。 在"Patterns, Principles, and Practices of Domain-Driven Design" 中,作者将介绍如何使用DDD来进行软件开发,并详细解释了DDD的核心概念和重要组成部分。这包括战略设计(Strategic Design)和战术设计(Tactical Design)。战略设计关注领域的整体架构和组织,它定义了领域的边界、聚合根(Aggregate Roots)以及他们之间的关系。而战术设计则关注如何实现具体的业务逻辑,使用领域模型(Domain Model)来表达领域的核心概念。 该书强调了领域专家和开发团队之间的合作,推崇的是通过持续对话和深入理解业务,来捕捉业务需求和规则。它提倡使用通用语言(Ubiquitous Language)来统一业务和开发团队的沟通,避免因为术语不清晰而导致的误解和问题。 总之,"Patterns, Principles, and Practices of Domain-Driven Design" 提供了一个全面的指南,帮助开发团队理解和应用DDD的模式、原则和实践,以构建高质量、符合业务需求的软件系统。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值