-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Design Patterns 设计模式汇总 #220
Comments
创建型模式:筹工建单元,筹(抽象工厂)工(工厂方法)建(建造者)单(单例)元(原型) |
2009 年系统架构师考试科目一:综合知识
A.Command B.MenuItem C.Open D.ButktinBoardScreen 【解析】 对于题目所给出的图,与“Invoker”角色相对应的类是 MenuItem,与“Concrete Command”
A.桥接模式 【解析】
A.适配器模式 【解析】 |
2010 年系统架构师考试科目一:综合知识
A.责任链模式 B.桥接模式 C.装饰模式 D.适配器模式 【解析】
A.备忘录模式 B.中介者模式 C.访问者模式 D.迭代器模式 【解析】
A.代理模式 B.外观模式 C.桥接模式 D.组合模式 【解析】 |
2011 年系统架构师考试科目一:综合知识
(1) A.Company 【解析】 【答案】A、D。
A.抽象工厂模式 【解析】
A.单例模式 【解析】
A.责任链模式 【解析】 |
2012 年系统架构师考试科目一:综合知识
A.工厂模式 B.责任链模式 C.中介者模式 D.命令模式 【解析】 本题主要考查设计模式知识。题干描述了某软件公司一款图像处理软件的需求分析与设 计过程,并明确指出采用设计模式实现关键需求对系统灵活性与扩展性的要求。
【解析】 |
2013 年系统架构师考试科目一:综合知识
(1)A.外观 B.单体 C.装饰 D.模板方法 【解析】 |
2014 年系统架构师考试科目一:综合知识
A.解释器(Interpreter) B.策略(Strategy) C.中介者(Mediator) D.迭代器(Iterator) 【解析】 解释器(interpreter)模式。解释器模式属于类的行为型模式,描述了如何为语言定义一个 文法,如何在该语言中表示一个句子,以及如何解释这些句子,这里的“语言”是使用规定 格式和语法的代码。解释器模式主要用在编译器中,在应用系统开发中很少用到。
【解析】 |
2015 年系统架构师考试科目一:综合知识
A.Shape B.Drawing C.Rectangle D.V2Drawing 【解析】 图中与 Bridge 模式中的“Abstraction”角色相对应的类是 Shape,与“Implementor”角
A.开闭 B.里氏替换 C.最少知识 D.依赖倒置 【解析】 |
2016 年系统架构师考试科目一:综合知识
A.合成型 B.组合型 C.结构型 D.聚合型 设计模式包括:创建型、结构型、行为型三大类别。 Singleton 是单例模式,属于创建型设计模式。 Memento 是备忘录模式,属于行为型设计模式。 Bridge 是桥接模式,它的特点是实现接口与实现分离 |
2017 年系统架构师考试科目一:综合知识
【解析】 设计模式包括:创建型、结构型、行为型三大类别。 Singleton 是单例模式,属于创建型设计模式。 Adapter 是适配器模式,属于结构型设计模式。 |
2018 年系统架构师考试科目一:综合知识
(54)A. 组合型 B. 结构型 C. 行为型 D. 创建型 【解析】 抽象工厂模式是一种类创建型模式。 |
设计模式速记速记关键词:动态生产对象 |
有一个编程原则叫做 DRY(Don't repeat yourself,不要重复自己),指的是尽量不要有重复的代码。 更好的名字应该是 SPOT(Single Point Of Truth,单点事实)。代码需要修改时,你只需要在一个地方修改,而不必改动多个地方。 |
谈谈我工作中的 23 个设计模式序从基础的角度看,设计模式是研究类本身或者类与类之间的协作模式,是进行抽象归纳的一个很好的速成思路。后面阅读设计模式后,为了加深理解,对相关图片进行了描绘和微调。 抽象工厂(Abstract Factory):多套方案抽象工厂模式是对创建不同的产品类型的抽象。对应到工作中,我们的确应该具备提供多套方案的能力,这也是我们常说的,要提供选择题。当你有这样的前瞻意识,一般也会被打上思考较多的标签,但是内在来说,的确想问题更加全面了。 生成器(Builder):善于分解生成器模式是对一个个体的创建过程进行细分,拆解为不同的创建部分。这个对应到工作中,作为一些项目管理人员或者团队管理者,需要将一个大泥球一样的事务,合理分解,让大家各司其职,充分发挥才能。同样,我们对日常的工作内容,也可以按照结构去进行划分,从而更有调理。 工厂方法(Factory Method):抽象思考工厂方法模式是说将提供某一产品的过程进行抽象,通过接口的模式去规范出来。类似的,我们很多做事的过程,都是面向过程,没有抽象提炼一下。如果经过进一步思考,那么可以往上再提炼一个层次,发现事物的本质:到底在做什么,我们的职责是什么,提供什么样的价值。想的更清楚,做的也会更加准确。 原型(Prototype):传承知识原型模式是说,利用拷贝对象的方法,减少一些复杂的创建过程。这里我们能够学到的是,需要做好日常的积累,很多方案不是每次来都重写,是可以在原来的方案上进行拷贝复用的。这个 clone 的过程,往往也是知识传承的过程。如果有比较好的传承机制,那么会大大提升服务效率。 单件(Singleton):专注单件模式是说在多线程的情况下,要保证对象只创建一遍,作为独一无二的资源。这个我觉得,应该去 review 一下我们的工作模式,虽然我们常常要并发很多事情,但是如果处处被打断,每件事都想干好,那么可能每件事都干不好。我们要确保在某个时间段竭力地做好一件事。事件是一件件有效解决的,不是一起慢慢解决的。 适配器(Adapter):适应能力适配器是为了结合原来的能力,适配新的接口服务,比如适配不同的协议入口。工作的时候,其实需要适应不同的人和事,有不同的工作方法方式,但是我们的核心能力是一样的,都是解决对应的问题域。 桥接(Bridge):合理关系桥接模式是将原来相互依赖的部分,通过上层接口再往抽象层提一下,减少类之间的直接合作,形成间接关系。这个到对应到工作中来说,有一种场景是,常常开发对开发去 case by case 解决问题。如果往产品逻辑层走一下,开发对产品,产品层面可能有更好的抽象。当然为了更好的服务体验,这样的解耦是不多见的,但是这样的思考我们可能要 get 一下。 组合(Composite):递归思考组合模式通过继承和孩子节点,可以递归地去描述一个对象层次。这个对我们工作来说,要加深思考的层次,可以某个点拆开去再去思考,同时如果能够在递归分解过程中抽象一些共性的点,就能找到一些规律。比如我们的需求分解,每个需求可以分解为子需求,子需求再往下看又可以递归分解。分解完之后,每个部分有这部分的 owner 去驱动他的下游,形成一个层次结构。 装饰(Decorator):增量价值装饰模式是将原来的能力进行包装,并提供新的行为。其实每次功能迭代,我们大多是在原来的基础上添加新的功能。我们要定义好新的能力,首要前提是继承、理解好原来的逻辑。这里还想提的是,很多时候,我们只看到了我们复用了庞大的基础能力,但是也要看到我们在项目中增量的贡献,这是我们的闪光点。不要把 “拧螺丝” 真的看成了拧螺丝。 外观(Facade):深入浅出外观模式是说我们不需要理解复杂的系统,而是通过一个外观去操作。这里我们的工作思路是,我们不用展示复杂的细节,我们要提供一些高层的理解,汇报如此,系统的包装也是如此。就比如,服务功能孤立来看,可能很多、很杂,但如果有一个统一的站点去引导包装,那么感觉会好很多,也会看上去有点收口和聚焦的感觉。 享元(Flyweight):善于链接享元模式是说,当我们已经存在一些内容的时候,可以通过缓存复用,而不是重新创建,减少开销。我们在工作中也要做好积累,但是更要做好缓存的 key,通过怎么样的手段去链接到我们的工作中,是需要我们做好类目管理和持续积累的。 代理(Proxy):理解保护代理是为了包装一个类,对相关操作进行二次转发或者进行一些管控。工作中来说,有些工作模式下,有时候我们可能会抱怨管理者代理了我们的决策等操作,但是换个角度想,他们保护了你不用直接被暴露在业务方侧,能够按照预期内的节奏提供服务,不会被主动设置一些预期外操作或私活。 责任链(Chain of Responsibility):能力与责任责任链是说将请求让队列内的处理器一个个执行,直到找到可以执行的。这里对我们工作的启示是,我们常常抱怨我们得到的机会少,不能成为队列内优先可以处理的处理器,总是处理人家不需要的。但是换个角度看,首先责任链里面的处理器应该是正交的,大家应该各司其职。退一步来说,如果真的有重叠,那么你应该努力提升自己,成为能力强的,从而提高队列内的优先级。 命令(Command):加强合作命令模型是说将请求包装为命令,这样在执行的时候可以与具体的执行逻辑解耦。工作中来说,我们有时候不应该太关心一个事情是怎么完成的,当交给别人完成时,信任他们即可,就是从解决问题的角度来看,不用事事亲为,事事较真。但是这并不妨碍我们主动养成全局视角,了解每个细节。合作才能影响更多的事情。 解释器(Interpreter):加强理解解释器模式是说针对一套上下文,形成一套语言,可以通过解释表达式含义的方式完成对应的任务。这里来说,我们可以形成某个团体的领域语言,内部交流通过相关领域语言交流,可以增加交流效率。此外,其实不同层次都有不同层次的专业术语,有时候一个术语的解释是一个方面的顿悟,还是要多了解工作内容本身。 迭代器(Iterator):横向职责迭代器模式是将集合的访问功能独立出来,通过迭代的模式去访问。这种独立职责的操作,工作中我们常常会看到,我们会将需求管理,缺陷管理,资金安全的一些事情独立出来看。一个方面是这些功能块从主体来说是比较内聚的,另一个来方面说,对工作职责的细分,可以让大家把自己的事情干好,发挥团队作战的效能:开发把开发干好,测试把测试干好,资损防护同学把资损防护干好,整体也就做好了。 中介者(Mediator):协调能力中介模式是说:当多个类之间要协调的时候,往往引入中介者进行协调,减少大家的知识成本。这个我们常常需要一些 PM、PMO 这样的角色去管理项目,系统中也需要一些协调层去协调各个域。因此我们也注重培养协调事务、具备全局观的能力。 备忘录(Memento):小步快跑备忘录模式是对操作的一些记录,已被可以恢复到之前的版本。在日常工作中,我们常常需要及时备份、及时保存、及时提交等操作,这样在程序崩溃的时候可以快速恢复到之前版本。但从抽象来说,一些比较长时费力的事情,我们应该分解来做,及时锁住部分收益。 观察者(Observer):主观能动性观察者模式是说我们通过注册、回掉这样的协作设计,完成变化通知的协作机制。这个工作中来说,换个角度思考,我们可以将一些被动的工作,变成主动的思考。比如:我需要干某部分工作,从工作的角度来说,不得不做,从主动的角度来说,就是需要培养某块的能力。如果对工作内容不太满意,也可以沟通协调,而不是事后爆发,凡是都是可以主观驱动的。 状态(State):管理自己状态模式是说在不同的状态下,有不同的处理行为。对工作中来说,我们可能有状态好的时候,有状态不好的时候,主观的处理的手段是调整状态。但是如果调整不过来,我们应该进行不同的操作。比如,脑子好的时候,想一些复杂问题;脑子嗡嗡的时候,做一些简单整理。 策略(Strategy):理解决策策略模式是说完成一个事情有不同的算法,可以进行相关切换。我们在工作中,常常会提供不同的方案,不同的方案有不同的成本和收益,但是这些方案的选择时候,往往不是我们能决定的,而是客户 client 主动判断的。 模板(Template):标准化能力模版模式是说对一个执行过程进行抽象分解,通过骨架和扩展方法完成一个标准的主体逻辑和扩展。我们很多时候,做 xxx 平台也都是这样的:对过程进行标准化,对变化进行定义,形成一个平台逻辑和业务扩展,完成一个产品模版。只是说这个模版是站点,还是扩展点,还是其他的展示形式。这样标准化的能力也是需要长期训练的。 访问者(Visitor):学会放手访问者模式是说把对元素的访问操作交给访问者来操作,因为对访问者来说常常有不同的访问行为。在工作中,往往我们只能陈述事实,这个内容消化后,每个人都有自己的理解。代码协作也是一样,比如:页面到底长什么样,其实还是要交还给业务本身,我们应该专注于提供基础的能力。 总结作为开发者,我们对于如何写出优雅的代码,表示疑惑。因为常常背后是复杂的问题域,优雅的设计往往产生于局部,很难整体都很优雅。 |
Interface Segregation PrincipleWhyWhen working with interfaces, you may find that you have an interface that is implemented by various clients, but we're not all clients need to implement all the methods of the interface. This is bad because you’re forcing clients on to implement methods they don’t need, leaving empty methods like this: func (c Client) MethodTheClientDontNeed() {
panic("implement me")
} WhatThe Interface Segregation is part of the SOLID principles, and what it says is that the clients of an interface must implement only the methods that they need, or else you must split your interface into more specific ones, so the clients only implement the methods that they need. |
23 种 GoF 设计模式
这个网站讲解各种设计模式的含义和用法,有英文版和中文版,每一种设计模式都配上了插图讲解。
The text was updated successfully, but these errors were encountered: