面向对象类设计的一些原则

最新推荐文章于 2022-07-03 18:34:42 发布

johnsonTj

最新推荐文章于 2022-07-03 18:34:42 发布

阅读量2.9k

点赞数

分类专栏： UmL学习文章标签：文档项目管理 function 敏捷工作 intervals

UmL学习专栏收录该内容

1 篇文章 0 订阅

订阅专栏

《敏捷软件开发－原则，模式与实践》一书中的面向对象类设计的一些原则：

单一职责原则：
对一个类而言，应该仅有一个引起它变化的原因

开放，封闭原则：
软件实体（类，模块，函数等等）应该是可以扩展的，但是不可修改的。

Liskov替换原则
子类型必须能够替换掉它的基类型。

依赖倒置原则
a.高层模块不应该依赖于低层模块，二者都应该依赖于抽象。
b.抽象不应该依赖于细节，细节应该依赖于抽象

接口隔离原则：
不应该强迫客户依赖于他们不用的方法。

英文文章可以在ObjectMentor的网站上找到
中文的可以在C++ View站点的电子杂志上找到

《敏捷建模》读后感

这本书买了有一段时间了，可是最近才算真正过了一遍，书不算厚，300页左右，但是看完后感觉收获颇多。

这本书并没有教给你具体的建模技术，比如UML，模式等的使用，或者手把手的教你一个例子，而是首先提出敏捷建模的原则，实践来解释什么是敏捷建模和其关键部分。然后展开说明敏捷建模中各制品，和统一过程，XP的结合等。

对于我自己来说读这本书最大的收获不是获得了某些技术，而是明白了一个道理，在软件开发过程中，对“度”的掌握的重要，从传统的重型软件开发过程到现在的敏捷开发，最重要的不是测试驱动，不是结对编程，最最重要的是对软件开发中的“度”的重新定义，在过多过少之间寻求平衡。我们常提的“过度设计”，“过多的文档”等等，无一不是对“度”的掌握出了问题，而这些东西本身并没有过错，相反它们的作用是无法替代的。

对“度”的掌握直接延伸到“合适”，“没有最好，只有更好”，根据自己的项目规模，团队组成，行政组织机构，找到适合自己的过程。否则即时你现在很“敏捷”了，但是仍然面临项目失控的危险。

“过犹不及”，“物极必反”，要保持在平衡点上实在是一种理想，在软件开发中只能时时的调整方向，虽然不是最正确的方向，但是保证我们不要偏离太远。

读《敏捷建模》时看到的一段文字，深有感触，摘抄下来

在书中270页

有权力的催着要纸的人

??????? 在比较大型的的组织机构里，这样的IT专家是很普遍的：他们已经有好几年的时间没有直接参与国软件开发了－编程、建模、测试或管理。这些人通常担任基础设施服务的角色，例如软件过程管理，复用管理或者程序管理，并且经过了一段时间他们的角色已经退化到了这样的地步：他们工作的中心就是“催纸”。这些人通常要求个人或团队提供进度报告，由他们进行检查并提供反馈；举行进度会议以便他们能知道项目进展的如果；要求项目团队提供他们关注的专门领域的度量或评估，例如复用度量、安全评估、数据标准符合程度等。这并不是说担任这些角色的人都是催纸的，我与能够积极支持我的项目团队的复用、安全和数据专家有很多非常愉快的合作经历，但同样也有非常糟糕的经历。我发现根本的区别在于，那些愿意并且能够卷起袖子帮助我的项目团队的人对我非常有价值，而那些只是要求文档或举行评审会议的催纸的人几乎没有任何价值，并且常常是严重的障碍。
???????? 不幸的是，那些是障碍的人经常不能轻易的置之不理，因为他们掌握着权力。拒绝填报他们的表格常常会导致他们的经理沿着公司组织机构向上面告状，然后表格再一次回到你的项目组。每当遇到掌握权力的催纸的人，我会依次采用下列策略：

?????? ?1.交流。我首先会尝试与对方交谈，找出他们认为重要的而需要优先考虑的事情，然后商谈出一个符合他们要求的更有效的方法。我发现这个方法很少管用，因为他们非常固执，而且有抱有太多偏见，但不管怎样值得一试。
?????? ?2.转向寻求帮助。与其它项目关系人交谈，让他们了解催纸人的要求对团队的负面影响，并请他们帮我处理这个问题。
?????? ?3.逃走或抗争。决定团队是应该勉强接受催纸人的要求，还是跟他们用政治斗争来解决。斗争解决的问题在于这样作你需要花费精力和政治资本，可能会在政治上树敌，并且催纸人在政治上通常要比你更加机智。

对项目目标的一点想法

公司已经有一个比较成熟的产品了，而且销售情况也不错。现在作的项目是该产品的后续产品，但是并不是简单的升级，如果仅仅是用.net来把以前的VB作的东西来实现一遍，就没有什么实际的意义了。由于要和先前的产品相比有质的飞跃，所以从结构和业务上几乎都是重新设计，但是由于新的架构的实现难度比较大，造成现有的人力和技术实力无法完成具体的实现。形成了一种高不成，低不就的情况，一方面，目标太高，达不到，另一方面，如果调整目标，前面作的很多工作都要推倒重来。最终，项目变成了“鸡肋”，高层也不关心，把精力都放到了赚钱的项目上，但是由于前期投入了大量的人力物力，在一些方面作了很多的探索，放弃又不甘心。但是实际的情况是，如果不作调整，砍掉一些不切实际的功能，那么只能是越走越远，最后只有失败一个结果。

所以，我觉得：
1.定位很重要，在项目启动前明确这个软件到底是什么，一个升级版本？一个新的产品？他的价值是什么，不要说启动就启动。
2.这个软件的核心功能应该是什么，在架构上实现的难点是什么，可行性如何，这些部分对其它部分的影响有多大。如果风险太高，就砍掉，用其它的简化的办法来代替。
3.在开发中放弃对一些不切实际的功能。一些需求有可能会出现，但是在实际中几乎不会出现或出现的机率很小，更重要的是实现它的难度较高，要耗费大量的人力，时间，而且还有可能影响到其它部分的设计。
4.在开发过程中对管理层提出的新的功能要更加谨慎。管理层有时提出一个新的功能需求不是经过深思熟虑的，但是你一时还找不到理由来反驳他，因为他说的也有道理。但是，因为这些需求，你不得不一再调整计划，同时修改现有的东西来兼容。到最后你却发现这个东西根本就没什么用或者向第三点所说的，提高了项目的风险，得不偿失。虽然现在都在说“拥抱变化”，但是“拥抱”前先看看代价。

写了这么多，还是言不达意。
总结一下：从真正的实际出发，放弃对完美的追求。

文档，又是文档

文档，又是文档，《敏捷建模》中关于文档的一段文字，觉得非常好。

害怕失去所有的人而导致过度的文档

很多组织机构害怕失去他们的软件开发团队，因为一旦团队全部或大部分的人离开，非常重要而且常常没有几率的知识会和他们一起离开。常见的失去团队的原因有：

有竞争者从你那里掘走了团队，以便启动他们自己的项目
有的开发人员习惯性的跳来跳去，从不在任何公司久留。
在团队刚刚完成项目之后你有意解散了他们。

为了解决这个问题，高级管理层常见的策略就是要求大量的文档，他们相信一旦失去了这个团队，可以简单的组成另一个团队，并把文档交给新组成的团队。这个办法听起来不错，但在实际工作中常被证明起不了什么作用。第一，尽管文档可能对当前的情况有帮助，但新来的团队不大可能会相信它，他们宁愿通过它得到关于系统的一个“地势走向”，然后钻进代码以获得细节。换句话说，他们使用详细文档可能只是为了包含在其中的一小部分概览文档。第二，这个策略经常会变成一个自我实现的预言，因为害怕他们会离开，你强制开发人员写过量的文档，而正因为你的官僚主义、缺乏对他们的信任和缺少对软件开发的关注，他们会真的决定离开。

在这种情况下，我会和要求文档的人一起工作，尝试商议出一个更敏捷的方法。我的经验是，由简洁的概览文档和适当的契约模型支持的高质量源代码，就能为将来需要维护和增强系统的开发人员提供一个足够好的系统描述。

IT能够解决所有的商业问题吗？

为什么有“对国内企业来说，不上ERP等死，上ERP找死”的说法？
为什么系统开发完了，实施不起来？
为什么有的企业用着信息系统还不如按照原来的流程来的好？
为什么用户的需求总是变来变去？可能因为他们自己也不知道他们想要什么。

Can IT Solve All Business Problems?

或许正如文中所说："Information technology is not a stand-alone system; rather, it is a great facilitator."
如果你已经作的很好，上个企业信息系统可能会锦上添花。如果本身就已经奄奄一息，那么最好还是理智些。

我们的口号是“不求时髦，只求合适”

项目管理者的尴尬

近来项目基本处于停顿状态，所以有时间停下来好好总结下。

由于项目进行中经历了项目经理的更换，所以对不同的管理方法有一些自己的看法。
试着从程序员的角度来看看项目管理。

先看两个问题：
1.文档
很多程序员都有一样的想法，就是很讨厌写文档（起码是过多的文档），可是项目管理者偏偏最看重这个，他们整天催你交他认为必须的文档，拿到手后又这也不对，那也不对，吹毛求疵。程序员讨厌这样，但是却不能表现出什么不满，抵触情绪自然会影响到工作。

2.进度
一般项目开发都会有一个进度安排，用Project也罢，用其它的也罢，但是都会精确到
某一段时间内完成什么任务。程序员都按照这个来工作，进度落后了要加班，超前了会休息一下，看看书，学习学习。但是偏偏项目管理人员天天来问你，有时甚至一天几次：进度怎么样了？能完成吗？这时候开发人员会极度反感。“进度怎么安排的，我心里清楚，干嘛跟催命似的，我又不是奴隶，长工！！”但是有苦不能言啊，只能憋心里。

为什么出现这样的情况？
有的项目管理者在项目刚开始的时候作需求，作计划，估算等等，忙的不亦乐乎，但是随着设计，编码工作的展开，他们的职能似乎就退化了，不参与设计，更不要说编码了，他们的任务逐渐变的就只剩催交文档和进度跟踪了，而对于真正的软件不闻不问。不去了解设计，更不要说去看代码，看也是在评审的时候看你是不是遵守编码规范，或界面上的一些bug。而对设计和怎么实现的毫不关心。但是对文档却是一个也不能少，而且还在格式上费尽心机。他们以为这样就可以很好的证明项目还在自己的控制中，而且这些开发人员也很听话，可以向老板表明他也很忙，也作了很多事情。所以我认为这种现象的根本原因就在于项目管理人员认为他们作的是管理（而不是真正的参与），只要有文档，有可控的进度，项目就尽在掌握；更甚者，他们除了文档和进度就再也无事可作，变成了一个真正的”闲事主任“，他知道别人的进度，但却不知道自己的进度。

解决的办法就是真正的参与到项目的开发中，设计，编码，不需要很多精力，但是已经足够在开发中树立你的威信，在别人碰到问题的时候能够和他们进行更深层次上的讨论，交流。在评审时才能够看到问题的本质，而不是些细枝末节。一方面增加了自己在项目中的作用，另一方面能和开发人员真正成为一个团队，消除对立的情绪，和开发者的关系由“你们”变为“我们”，尽管立场和根本出发点仍然不同，但是已经可以互相理解，协作。更重要的是，知道项目当前最需要的是什么，文档？交流？或是一次“站立会议”？
而不是想当然的“瞎指挥”。

我并无意贬低项目管理在开发中的作用，更无意贬低项目管理人员，只是就我自己在开发中碰到的我觉得不合理的情况发表一点自己的看法（顺便发点牢骚），希望我的偏激没有冒犯那些真正出色的项目管理者，并且非常希望能看到来自项目管理者的观点。

敏捷开发的原则

Principles behind the Agile Manifesto

We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity--the art of maximizing the amount
of work not done--is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

johnsonTj

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
面向对象类设计的一些原则

function StorePage(){ d=document; t=d.selection?(d.selection.type!=None?d.selection.createRange().text:):(d.getSelection?d.getSelection():); void(keyit=window.open(http://www.365key.c
复制链接

扫一扫

专栏目录