2008-07-04
全文显示

通用职责分配模式的其中的３模式

通用职责分配模式(GRASP)一共有９个模式，下面是其中的３个模式： 创建者模式： 创建对象是面向对象系统中最常见的活动之一，因此应该有一些通用的原则以用于创建职责的分配，如果分配的好，设计就能够支持低耦合，提高清晰度，封装性和可复用性。 如果下列条件之一为真，将创建类A的实例的职责分配给类B： a.B包含或组成聚集A b.B记录A c.B直接使用A d.B具有A的初始化数据，并且在创建A时会将这些数据传递A。因此对于A的创建而言，B是专家。 e.B是对象A的创建者 如果有一个以上的选项适用，通常首选聚集或包含A的类B。 创建者模式指导我们分配那些与创建对象有关的职责。基本意图是寻找在任何情况 ...
2008-06-23
全文显示

软件模块的职责与设计的臭味

每一个软件模块都应具有三个职责: 1.第一职责是它运行起来所完成的功能.这也是该模块得以存在的原因. 2.第二职责是它要应对变化,几乎所有的模块在它们的生命周期中变化,开发者有责任保证这种改变应该可能的简单.一个难以改变的模块是拙劣的,即使可以工作,也需要对其进行修正. 3.第三职责是要和阅读它的人进行沟通,对该模块不熟悉的开发人员应该能够比较容易的阅读并理解它.一个无法沟通的模块也是拙劣的,同样要进行修改. 当软件出现下面任何一种气味时,说明软件正在腐化 1.僵化性:很难对系统进行改动,因为每个改动都会迫使许多对系统其他部分的其他改动. 2.脆弱性:对系统的改动会导致系统中和改动的地方在概念 ...
2008-06-10
全文显示

领域模型

领域模型 领域模型是对领域内的概念类或现实世界中对象的可视化表示,领域模型也称为概念模型、领域对象模型和分析模型。而非软件对象的表示。 领域模型专注于特定领域，应用UML表示法，领域模型被描述为一组没有定义操作的类图，他提供了概念透视图，它可以展示： 1)领域对象或概念类 2)概念类之间的关联 3)概念类的属性 以下元素不使用于领域模型 1)软件制品 2)职责或方法 领域模型不是数据模型，所以在领域模型里，并不会排除需求中没有明确要求记录其他相关信息的类，也不会排除没有属性的概念类。例如，没有属性的概念是合法的，或者在领域内充当纯行为角色而不是信息角色的概念类也是有有效的。 创建领域模型的原因 ...
2008-05-28
全文显示

系统架构采用分层的优点和缺陷以及其层次

1.将系统按照层次分解有很多的好处:1) 在无需过多了解其他层次的基.础上,可以将某一层作为一个有机整体理解. 2) 可以替换某一次的具体实现. 3) 可以将层次间的依赖性减到最低. 4) 分层有利于标准化工作. 5) 一旦构建好了某一层次,就可以用它为很多上层服务提供服务. 但其也存在一些缺陷: 1) 层次并不能封装所有东西. 2) 过多的层次会影响性能. 2.系统分三个基本层次: 表现层:表现逻辑处理用户与软件的交互,其职责是提供服务,显示信息. 领域层:做的所有领域相关的工作:包括根据输入数据或已有数据进行计算,对从表现层输入的数据进行验证,以及根据从表现层接收的命令来确定应该调 ...
2008-05-21
全文显示

敏捷开发的宣言与原则

敏捷宣言： 个体和迭代，超越过程和工具 工作的软件，超越完整的文档 客户协作，超越合同谈判 响应变更，超越履行计划 敏捷原则： 1. 优先级最高的是，通过早期和持续交付有价值的软件来满足客户。 2. 欢迎变更需求，即使在开发的后期提出。敏捷过程为客户的竞争优势而控制变更。 3. 以两周到两月为周期，频繁地交付可运行的软件，首推较短的时间定量。 4. 在整个项目过程中，每一天开发人员都要和业务人员合作。 5. 由个体推动项目的建设，为个体提供所需的环境，支持和信任。 6. 在开发团队中或开发团队间传递信息的最为有效和高效的方法是面对面的交谈。 7. 衡量进展的重要尺度是可 ...
2008-05-21
全文显示

迭代开发的优点

１.它允许需求的变化。需求的变化和“进一步的蔓延” — 技术和客户驱动的特性的累加 — 一直是项目中导致麻烦、延期交付、令客户不满意和使开发人员泄气的主要原因。为了解决这些问题，使用迭代开发方法的团队应该在项目开发的几周里就关注生成和演示可执行的软件，这样就强制了需求的检查并可以帮助减少需求从而反映系统的本质。 ２.集成不是在项目的尾声进行的"大动作"。将系统的集成留到项目的结尾几乎总是会导致耗时的返工 — 有时这种返工会花费整个项目工作量的百分之四十的时间。为了避免这种返工，每一次迭代都以集成构建系统各部分结束；这样不断的积累将最小化日后的返工。 ３.早期的迭代可以暴露风险。迭代的开发方 ...
2008-05-14
全文显示

Flex DataGrid 数据上下移动

<?xml version="1.0" encoding="utf-8"?> <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" xmlns:window="com.diaztorres.window.*" xmlns:log="com.log.*"> <mx:Script> <![CDATA[ import mx.collections.IList; import mx.collections.ArrayCollect ...
2008-05-08
全文显示

对设计模式—Composite模式的认识

Composite模式定义: 将对象以树形结构组织起来,以达成“部分－整体” 的层次结构，使得客户端对单个对象和组合对象的使用具有一致性. Composite好处: 1.使客户端调用简单，客户端可以一致的使用组合结构或其中单个对象，用户就不必关系自己处理的是单个对象还是整个组合结构，这就简化了客户端代码。 2.更容易在组合体内加入对象部件. 客户端不必因为加入了新的对象部件而更改代码 　如一棵树有树枝和叶子，树枝也有叶子，叶子为最小的部分．从大到小顺序Tree->Limb->Leaf public abstract class Component { public Strin ...
2008-04-29
全文显示

对设计模式—Command模式的认识

今天抽空看了一下Command 模式,Command 模式涉及了五个角色它们分别是： 客户（Client）角色：创建了一个具体命令(ConcreteCommand)对象并确定其接收者。 命令（Command）角色：声明了一个给所有具体命令类的抽象接口。这是一个抽象角色。 具体命令（ConcreteCommand）角色：定义一个接受者和行为之间的弱耦合；实现Execute()方法，负责调用接收考的相应操作。Execute()方法通常叫做执方法。 请求者（Invoker）角色：负责调用命令对象执行请求，相关的方法叫做行动方法。 接收者（Receiver）角色：负责具体实施和执行一个请求。任 ...
2008-04-22
全文显示

对设计模式—Template模式的认识

Template 模式其实是在抽象类中定义业务逻辑了和方法，具体的方法在子类中去实现。 一个集团下属有几个公司，年底到了公司的财务结算的时候，最后几个下属公司把利润送到集团的财务科报帐，具体怎么财务结算的由几个下属公司去操作。 public abstract class Template { protected abstract void checkFinance(); public final void doTotal() { checkFinance(); System.out.println("Compa ...
flysnail
搜索本博客
最近加入圈子
存档
最新评论