对象责任职责协作

     

Golang链模式

91 3K

链模式( Chain Pattern)是用于编写更好、更健壮的代码的众多设计模式之一。这种模式的工作原理类似于链式生产,链中的每个环节都负责一项具体任务。当链启动时,第一个执行其任务,然后,如果没有错.

高内聚低耦合的集中决策设计

583 2

假设,我们正在构建另一个电子商务平台。其关键业务流程之一当然是处理订单。付款成功后,订单模块(域)必须异步调用仓库,准备购买的货物。然而,这些货物可能并不在那里。通常情况下,这不是什么大问题,因为我们.

经典OOD书籍《对象设计:角色、责任和协作》PDF免费下载

1826 3

经典 OOD 书籍《对象设计:角色、责任和协作》( Object Design: Roles, Responsibilities, and Collaborations )可从 Pearson 的网站.

幽默:能否将人类群体视为神经元集合的延伸?

857

当前人们对大脑自身的认识深入促进人工智能和认知科学等方面发展,仿真人类的大脑思考模型称为启发很多创新方法研究的源泉,例如人其实是神经元交互聚合的产物,人类群体是否可视为神经元集合的延伸?如何借鉴神经元.

花费优秀程序员95%时间精力的事情 - MICHAEL JACKSON

1 1489 3

软件开发人员最常犯的错误是:把东西放在错误的地方。将本来应该分离的责任与概念耦合在一起。对我来说,这占据软件开发中95%。只是弄清楚*事物所属的地方。其他观点:1. 我担心开发人员会强调并花费很长时间.

GRASP之受保护的变化 - Kamil Grzybek

1375

问题:如何设计对象,子系统和系统,以便这些元素的变化或不稳定性不会对其他元素产生不良影响?解决方案:确定预测变化或不稳定的点,分配责任以围绕它们创建稳定的接口。在我看来,这是与其他GRASP原则间接相.

GRASP之纯粹的制作模式 - Kamil Grzybek

1243 2K

问题:什么对象应该有责任,当你不想使高凝聚力和低耦合时,但其他原则提供的解决方案不合适?解决方案:将一组高度凝聚力的责任分配给脚手架或帮助类之类工具,这些工具并不代表问题域中的概念。有时候很难弄清楚应.

GRASP之多态性模式 - Kamil Grzybek

1707 1

问题:如何根据类型处理替代方案?解决方案:当相关的替代或行为因类型(类)而异时,将行为(使用多态操作)的责任分配给行为变化的类型。多态性是面向对象设计的基本原则。在这种情况下,原则与(以及其他)战略策.

GRASP之间接模式 - Kamil Grzybek

1653

问题:在哪里指定责任以避免两件或更多件事之间的直接耦合?解决方案:将责任分配给中间对象以在其他组件或服务之间进行调解,以使它们不直接耦合。这是Mediator Pattern的用武之地。而不是直接耦合.

GRASP之高凝聚模式 - Kamil Grzybek

1283

问题:如何保持对象集中,易于理解,易于管理以及作为副作用支持低耦合?解决方案:分配责任,以保持凝聚力。用凝聚力大小来作为分配职责的判断标准。凝聚力衡量元素的所有责任的相关程度。换句话说,元素内部的部分.

GRASP之低耦合模式 - Kamil Grzybek

1472

问题:如何减少变化的影响?如何支持低依赖性和增加重用?解决方案:分配职责以使(不必要的)耦合保持低水平。使用此原则来评估替代方案。耦合是衡量一个元素如何与另一个元素相关的度量。更高的耦合意味一个元件更.

GRASP之控制器模式 - Kamil Grzybek

1710 2K

问题:UI层之外的第一个对象是否接收并协调“控制”系统操作?解决方案:将责任分配给表示以下选项之一的对象: - 表示整个“系统”,“根对象”,运行软件的设备或主要子系统(这些都是外观控制器的变体) -.

GRASP 之创建者Creator模式 - Kamil Grzybek

1339

问题:谁创建对象A?解决方案:如果下面情况其中一个为真,则为B类分配创建对象A的责任(越多越好) - B包含或复合聚合A  - B记录A  - B密切使用A  - B具有A 的初始化数据 例子:pub.

GRASP 之信息专家模式 - Kamil Grzybek

3138 2

问题:将责任分配给对象的基本原则是什么?解决方案:将责任分配给具有实现它所需信息的类。在下面的示例中, Customer类引用了所有客户 订单,因此很自然地负责计算订单的总价值:public clas.

比SOLID更重要的与DDD设计相关的GRASP原则 - Kamil Grzybek

2 3214 3 7K

我最近注意到很多注意力都集中在SOLID原则上。这是非常好的事情,因为它是面向对象设计(OOD)和编程的总体基础。对于面向对象语言的开发人员,SOLID原则的知识是编写具有良好质量特征的代码的要求。关.

Michael Feathers:编程的艺术

1 906

编程是一次只做一件事的艺术.

上下文映射关系中如何解耦特定和通用的领域? - Nick Tune

1491 5 3K

您正在构建一个新系统,并且您的团队的两名成员各自提出了用于发送通知的两种架构,哪一个是正确?如何选择? 第一个开发人员提出的是推送模型:有界上下文应指示通知上下文发送通知。专门的通知上下文应该只是遵循.

什么是GRASP模式?

4415 3 11K
GRASP模式(一般责任分配软件模式)描述了对象设计和责任分配的基本原则和模式。 确定需求并创建领域模型后,如何将方法添加到Class类中,并定义对象之间的消息传递以满足要求。GRASP模式是一种学习.

IBM观点:SOA与微服务区别?

1 4818 1 2K

微服务是SOA的发展演进,但是来自IBM一篇博客文章好像将两者完全置于平等的角度进行比较,本文翻译中加入了本人的批判观点。如果你在IT部门工作,可能已经听过SOA与微服务的争论。毕竟,现在每个人都在谈.

Arch-orchestrator是Node.js流式架构指挥家

2155 1 2K
Arch-orchestrator是一个用于管理大型Node.js应用的类似SOA Orchestrator 开源的流程指挥器。管理大型Node.js架构面临挑战,使用orchestrator指挥家架.

领域模型的行为设计

22 17357 16 2K
领域模型的行为设计是面向对象领域建模设计的重要部分。在没有设计的朴素的情况下,领域模型一般是一个数据对象(DTO等),其中只有setter/getter方法,是一种纯粹的数据结构,然后将很多数据结构的.

重新认识“对象”和“行为”之间的关系

2 2002 1

  DDD中强调“领域对象是拥有行为的”。这句话我觉得说法是正确的,但是其做法难道就是“在领域对象里写方法”这么简单吗?   我们常说“类应该具有生命的”,但我不认为“把方法写到类里.

质疑"我的大脑不能再处理面向对象了"

3 3189 10

一篇译文:我的大脑不能再处理面向对象了,作者认为他的大脑更适合处理面向过程,也就是函数式编程。我个人观点:面向对象号称以适合人的大脑来思考软件,而面向函数或面向过程,则是让人的大脑以CPU方式去思考。.

模型中业务方法寻求解惑

7 2150 5

我们现在有一个模型Member,我想输出Member的性别,比如先生、女士。是否可以在模型中有这么一个方法@Transientpublic String getSexLang() { return.

以JiveJdon案例说明对象职责和SOLID原则应用

19 6029 5 2K

最近我和oojdon讨论给帖子加上浏览阅读次数这个功能,起初我们并没有从职责角度来考虑阅读次数这个功能,就简单地在Service中获得Thread方法时,添加一些代码,用来统计次数。因为我们这时重点是.

SOLID原则

9 11304 12 2K

由 Robert Martin提出的S.O.L.I.D 原则,用来更好编写面向对象程序,更灵活应对变化。S - Single Responsibility Principle 单一职责,简称SRP这个.

如何从职责和协作中发现丰富对象?

9 12040 17 3K
DDD领域驱动设计给我们指出统一建模统一语言的方向,从辨识角度提出区分实体和值对象的方法,如果说DDD只是给出了领域建模的方向,也就是WHAT部分,那么,对象设计:角色、责任和协作"(Object D.

对象的责任与职责

13 15923 21 2K

对象和数据的主要差别就是对象有行为,行为可以看成责任职责(responsibilities以下简称职责)的一种,理解职责是实现好的OO设计的关键。“Understanding responsibili.

从“贫血”和“充血”说起

14 2960 1 2K

从“贫血”和“充血”说起这两个词对我来说也是很新鲜的,看看我在Jdon的注册日期也就是从那时候开始才有所耳闻的。这两天看到有人在讨论于是整理了一下思维。看到网络上很多的讨论中对于充血和贫血的看法往往是.

充血模型与贫血模型的再论

5 2011

充血模型有什么实际的好处么? 难道就为了好听 完美(数据和行为统一)?过于复杂的需求还是用贫血 ,一般需求用充血 ,这样做正确吗?项目中用的更多的哪个模型呢。比较困惑。。.