我的设计模式之旅(1)——学习的原则和一些笔记
2006-06-27 08:59 努力学习的小熊 阅读(1164) 评论(2) 编辑 收藏 举报首先,这是我自己的旅程,学了1年多的C#,好多问题还是无从下手,希望跟随着
面向对象设计模式解决的是“类与相互通信的对象之间的组织关系,包括他们的角色、职责、写作方式几个方面。”
所谓“好的面向对象设计”是那些可以满足“应对变化,提高复用”的设计。
模式是通过不断的重构得来的。觉得这句很重要,模式是当多次重复劳动后,返回来评估观察的时候(重构),才会慢慢发现的。以前自己很不重视重构的问题,甚至没有思考过,现在发现重构是能提高质量的一个重要方法。
设计模式不是用来写代码例子的,而是用来设计软件的。个人理解其实设计也不是一上来就用模式来设计,因为软件的应用情况千差万别,一些“特色”需求也比较多,所以像编码实现一样,对于设计也进行阶段评审和测试,重新考虑软件的设计才会发现其中的一些模式。
从编程语言直观了解面向对象
对面向对象三大机制的支持,即:“封装、继承、多态”
1.封装,隐藏内部实现
2.继承,复用现有代码
3.多态,改写对象行为
设计原则:
这里以我原来的一个项目为例
1.针对接口编程,而不是针对实现编程
项目中是这样的,原来属于同一类的物品,例如药品,在开始录入系统全部都是药品,但是经过一段时期后,经过一些处理流程,其中一些药品被分成了几类,进入不同的处理流程。当时的处理就是在同一张表里作类别字段,然后用SQL语句筛选,而且药品读出后再按类别字段在程序里坐判断,像
还有一点就是权限的设计,规定了3级角色,结果就写死了关系,以后如果结构变化需要调整权限这是一个不可维护的模块。现在想来,其实返回3种类型的对象,然后定义好3种对象能干什么就OK了,这是我理想的设计。但是有一点比较讨厌的是,用户还要根据每个人设置不同的权限,这一点就不太好办了,总不能有多少个人就实例化多少种对象返回吧,虽然是一个比较好的结构,以后也是可以维护的,但是感觉不是很好的方案,现在也没有想到比较好的解决方案。经过一段时间CRM3.0的研究,发现微软CRM3.0的权限设计比较不错,是一个四维的设置,可以实现权限控制到记录级别,首先第1维是不同的模块的设置,分为销售、营销和服务等几大模块,然后再每个模块中先建立一个2维的概念,纵坐标是不同的角色,横坐标是在该模块中不同的操作,这里已经有了3维的设置,第4维就是提供了一个权限的级别,例如:企业级、部门级、个人等,在前面的那个3维表里进行设置,意思就是如果设置企业级,允许这个角色在这一模块下的这个操作可以操作企业中的所有记录,例如读取,他就可以看到企业级别下的所有记录。
2.优先使用对象组合,而不是类继承
为了实现低耦合。只有很强的is a的关系才用类继承。
3.封装变化点
单一职责原则(SRP):
– 一个类应该仅有一个引起它变化的原因。
开放封闭原则(OCP):
– 类模块应该是可扩展的,但是不可修改(对扩展开放,对更改封闭)
Liskov 替换原则(LSP):
– 子类必须能够替换它们的基类
依赖倒置原则(DIP):
– 高层模块不应该依赖于低层模块,二者都应该依赖于抽象。
– 抽象不应该依赖于实现细节,实现细节应该依赖于抽象。
接口隔离原则(ISP):
– 不应该强迫客户程序依赖于它们不用的方法。
三大基本面向对象设计原则
– 针对接口编程,而不是针对实现编程
– 优先使用对象组合,而不是类继承
– 封装变化点
以上是观看
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
· 上周热点回顾(2.17-2.23)