前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >设计模式概述及架构设计中应该注意的事情

设计模式概述及架构设计中应该注意的事情

作者头像
進无尽
发布2018-09-12 17:13:05
3390
发布2018-09-12 17:13:05
举报
文章被收录于专栏:進无尽的文章進无尽的文章

设计模式概述

说起设计模式,我想不得不说的是 GOF的23种设计模式。

《Design Patterns: Elements of Reusable Object-Oriented Software》(设计模式:可重用面向对象软件的要素)(即《设计模式》一书),由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 合著(Addison-Wesley,1995)。这几位作者常被称为"四人组(Gang of Four)"。 虽然 GOF是基于Java语言提出的,但是同样是面向对象语言的OC/Swift 在设计之时都是有借鉴意义的。

设计模式(Design pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式使代码编制真正工程化,设计模式是软件工程的基石,如同大厦的一块块砖石一样。只有精通了设计模式,才敢说真正理解了软件工程。可以说,设计模式是每一个架构师所必备的技能之一。

设计模式的起源是面向对象程序设计思想,是面向对象设计的精髓——抽象。面向对象通过类和对象来实现抽象,实现时产生了面向对象的三个重要机制:封装、继承、多态。正是这三个机制衍生出了各种各样的设计模式。

只有精通了设计模式,才敢说真正理解了软件工程。可以说,设计模式是每一个架构师所必备的技能之一。

个人总结:架构设计就是给软件系统搭一个架子,这个架子最后是钢筋结构(抗腐蚀性)而不是木头结构。模块的粒度不能太小,也不能太大,要大小适中,而且要高聚合低耦合,最终的效果就像一块块的砖利用简单的链接沿着架子可以搭建成型。 对修改关闭对扩展打开,不过扩展也属于修改吧,修改的话尽量在小模块中修改,能多小就多小,因为大的模块中逻辑复杂,你改了一点点就可能影响整个大模块的正常运行(因为有可能手误,动了不该动的东西,对大模块引入了风险)。

iOS 中的 21 种设计模式 大话设计模式之oc实现23种模式

如何避免过度设计

设计模式是为了封装变化,让各个模块可以独立变化。精准地使用设计模式的前提是你能够精准的预测需求变更的走向。我们都知道大部分人是做不到的,所以大部分人就算精通设计模式也多少会做错点什么东西。所以这其实不怪设计模式,怪产品狗。

所以说如何避免过度设计,这就要求你深入的理解你的程序所在的领域的知识,了解用户使用你的软件是为了解决什么问题,这样你预测用户的需求才会比以前更加准确,从而避免了你使用设计模式来封装一些根本不会发生的变化,也避免了你忽视了未来会发生的变化从而发现你使用的模式根本不能适应需求的新走向。

所以,在你满足了【知道所有设计模式为什么要被发明出来】的前提之后,剩下的其实都跟编程没关系,而跟你的领域知识和领域经验有关系。

架构设计中应该注意的事情

我的观点是,一切隐藏都是对代码复杂性的增加,除非它带来了好处,例如达到了代码复用,提高了代码的可维护性等,否则,没有好处的封装只会给代码阅读理解带来成本。 ——唐巧 所以,在这份理所当然的SDK的背后,蕴藏着大牛门几十年的设计智慧。当中应该能够看到很多门道。这次就UIView和CALayer来分析,就可以得出一些东西。

  • 机制与策略分离
  • 更多的不可变
  • 各司其职
  • 漏的更少
机制与策略分离

Unix内核设计的一个主要思想是——提供(Mechanism)机制而不是策略(Policy)。编程问题都可以抽离出机制和策略部分。机制一旦实现,就会很少更改,但策略会经常得到优化。例如原子可以看做是机制,而各种原子的组成就是一种策略。CALayer也可以看做是一种机制,提供图层绘制,你们可以翻开CALayer的头文件看看,基本上是没怎么变过的,而UIView可以看做是策略,变动很多。越是底层,越是机制,越是机制就越是稳定。机制与策略分离,可以使得需要修改的代码更少,特别是底层代码,这样可以提高系统的稳定性。

更多的不可变

稳定给你的是什么感觉?坚固?不可形变?稳定其实就是不可变。一个系统不可变的东西越多,越是稳定。所以机制恰是满足这个不可变的因素的。构建一个系统有一个指导思想就是尽量抽取不可变的东西和可变的东西分离。水是成不了万丈高楼的,坚固的混凝土才可以。更少的修改,意味着更少的bug的几率。

各司其职

即使能力再大也不能把说有事情都干了,万一哪一天不行了呢,那就是突然什么都不能干了。所以仅仅是基于分散风险原则也不应该出现全能类。各司其职,相互合作,把可控粒度降到最低,这样也可以是系统更稳定,更易修改。

漏的更少

接口应该面向大众的,按照八二原则,其实20%的接口就可以满足80%的需求,剩下的80%应该隐藏在背后。因为漏的少总是安全的,不是吗。剩下的80%专家接口可以隐藏与深层次。比如UIView遮蔽了大部分的CALayer接口,抽取构造出更易用的frame和动画实现,这样上手更容易。

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2018.07.03 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 设计模式概述
  • 如何避免过度设计
  • 架构设计中应该注意的事情
    • 机制与策略分离
      • 更多的不可变
        • 各司其职
        领券
        问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档