Feed on Posts or Comments 21 November 2008

日志 猫米格格巫 on 28 Sep 2008

Bridge Pattern

桥接模式。
形如电路并联的开关控制各条并联电路通行的情况。
我们可以把
各路开关映射为abstraction Interface–接口类;
各条并联电路上的设备映射为Implementations类。
即通常所说的把行为(Implementations)和对象(Object)分成2个class。

设计2个class,表示为“各条并联电路上的设备”,即我们需要implemented 2个行为

然后,再来设计abstract的部分,即”开关“

最后的客户端的实施部分,


clsOthtask objOthtask = new clsOthtask;
clsBatchprint objBatchprint = new Batchprint;
classswitch objSwitch = new classswitch;
objSwitch.setTask(objOthtask);
objSwitch.on()
objSwitch.off()
objSwitch.setTask(objBatchprint);
objSwitch.on()
objSwitch.off()

习惯过程式编程的人,可能还是不容理解,这段代码在过程式语言中表达为:


switch case(expression)
{
case "othertask": doothertask();
case "Barchprint":doBarchprint();
default:
}

这里,Switch —>  Interface ISwitch
Case (expression) —> ClassSwitch, 即Interface ISwitch的Implementation
Case “othertask”…—>clsOtherTask,interface ITask的Implementation
至于doothertask…等函数方法,都已经写在对象clsOtherTask中。

从表面上看,过程式语言似乎更加简洁,但是具体到实际开发中,你会遇到很多种混合
选择,你需要不断破坏式的修补客户端代码。

日志 猫米格格巫 on 26 Sep 2008

Use Case

需求文档中的用例为什么不适合用户看,为什么用户看不懂? 作者为学生登记这个事件所引用的
用例的确不适合用户看,因为它根本不是UML 所要求的、在需求文档中的用例,而是一种建立
在需求分析之上的,抽象了的系统设计文档,它的读者应该是程序员,而不是用户。

用例–UseCaseOO设计时,United Modeling Language中用于需求分析的一种图表。以用
户的视角来说明系统的运作内容,比如我做过什么,我需要做什么。

它由下面三种属性和一个说明表格组成:
场景(Scenario):用户在系统中发生一系列操作(事件)的序列
角色(Actor):系统的使用者,分为主要角色(Primary actor)和次要角色。主要角
色直接和系统发生关系
案例(Use Case):用户需要执行的任务或目的

需求文档中的用例为什么不适合用户看,..? 中的大学生入学登记为例事例说明,
你所提出的需求问题应该是:新生登记,需要办理什么手续?
至于学校管理部门指责划分,这不是在需求分析所讨论的。用户在跟你说明他的工作时,
一般只会说明我负责做什么,有什么依据。比如学籍处,学生凭证件来填表登记,学籍
处检查无误,发给学生证件。

那么这个Use Case,主角Actor是学生。场景是办理入学登记,案例是注册学籍、交费、领取
生活用品。
用简单的Use Case 图表示:

在需求分档里,再加入一个表格说明以上用例。

[TABLE=2]

各个案列的发生次序可以用Sequence图表表示。

2个图表几乎可以在和用户谈需求时完成,而且可以给用户看,胜过任何语言解释。它很清晰
的表述了《
用例为什么不适合用户看》所说的通过流程描述注册过程。

回过头看看《用例为什么不适合用户看》,他能“通过流程描述的设计里清晰的表述登记过程
的用户需求,却在用例设计里描述一段划分的
系统内部逻辑管理结构的划分,这是在
系统设计时
,程序员为用户需求所构造的系统模型,是程序员的需求,程序员设计文档;而不是用户需求,
用户所阅读的文档。

作者所说的“通过流程描述”的方法,其实就是面向过程的设计方法,一样能够清晰描述这个
记需求,我们为神马还
要用UML,面向对象的设计呢?

面向过程的方法,如作者设计的登记”用例“,是把一个事物看成平面,然后根据事物内部的不
同属性,象切蛋糕一样划分,形成一个
个系统孤岛,当然所有孤岛都有线性(1条过程)关系联
系,平面上的线条象蜘蛛网一样分布,在需求不
断的改变的条件下,不可避免的导致系统缠结、
崩溃。

面向对象或者面向方面的思维里,是把一个事物看成立体,不急于受系统的结构性实体,而是
横向作一个切片,找出里面所有类似功能的”事物“,实现从需求到“对象”“类”的转变。
如学生登记过程中,抽象出用户类:(学生类、
职员类),学籍登记、交费、发生活用品三个
事物共同特征:申请、提交、验证、确认,发证明、物品等。这里可以有一个验证类、事物流
程处理类(包括三个方法:Request,Submit,Approvl),当所有的类定义好后,再划分系统
结构,根据应用属性,重用类。

日志 猫米格格巫 on 06 Sep 2008

Chrome - Browser war or Platform war

Chrome –  Browser or Platform

Not to compare to Firefox,IE.   It has nothing to do with the browser at all.

Chrome is platform.  There has everthing to do with the platform.

Web will become real platform.  And Web will become real Operating System

日志 猫米格格巫 on 06 Aug 2008

ReadySET Pro Document Map

日志 猫米格格巫 on 03 Aug 2008

Learn from your mistakes

与其说software development是”Art”,不如说是种“craft”
熟能生巧的事情。
Coding Horror 说,

  • Stop theorizing.
  • Write lots of software.
  • Learn from your mistakes.对于国内高层设计人员来说,最欠缺的是Write lots of software,对于普通 Learn from your mistakes,最重要的Learn from your mistakes。哪怕是很小一段代码,都应该学会总结。”粗心“的实质是思维量不到位。
  • 日志 猫米格格巫 on 30 Jul 2008

    思维敏捷和不假思索

    如题

    日志 猫米格格巫 on 23 Jul 2008

    项目总结会

              项目经验总结会上,Team成员发言

    A   由于User不到位,Data Initialization  时间无法预估,Timetable上需要预留较长时间

    B   由于User个人原因,Trainning参加人数不足,迟到早退多,影响学习效果。

    C    TestPlan 应更全面,拟定标准的测试数据,保证UAT顺利

    D    每周一次的Project Progess Meeting 非常重要,跟踪成员进度、相互了解面临困难,及时调整计划。

    同是负责项目某一分项任务的组员,D 成员以项目管理人员角度看问题,其他人保持普通程序员的眼光。

    日志 猫米格格巫 on 10 Jul 2008

    边界

    技术问题实质是让人了解技术边界的问题

    有的技术人员,通过与人沟通,围绕技术边界制定规则,解决技术问题

    有的,则从纯技术角度找突破口,但是最终操作者是人,机器与人之间的控制与反控制,永远是个悖论。

    日志 猫米格格巫 on 26 Jun 2008

    practice drills

    practice drills- Steve’s article

    1、Write your resume , List all your relevant skill, then note the ones that will still be needed in 100 years. Give yourself a 1-10 rating in each skill.

    了解自己,确立目标

    2、Make a list of programmers who you admire.Try to include some you work with, since you’ll be borrowing them for some drills. Make one or two notes about things they seem to do well — things you wish you were better at.

    学习他人

    3、 Go to Wikipedia’s entry for computer science, scroll down to the “Prominent pioneers in computer science” section, pick a person from the list, and read about them. Follow any links from there that you think look interesting.

    培养兴趣

    4、 Read through someone else’s code for 20 minutes. For this drill, alternate between reading great code and reading bad code; they’re both instructive.

    开阔思维

    5、 Make a list of your 10 favorite programming tools: the ones you feel you use the most, the ones you almost couldn’t live without. Spend an hour reading the docs for one of the tools in your list, chosen at random. In that hour, try learn some new feature of the tool that you weren’t aware of, or figure out some new way to use the tool.

    善于提问

    6、 Pick something you’re good at that has nothing to do with programming. Think about how the professionals or great masters of that discipline do their practice. What can you learn from them that you can apply to programming?

    日志 猫米格格巫 on 26 Jun 2008

    Ten Years

    Teach Yourself Programming in Ten Years
    Peter Norvig

    对于我来说,最需要改进的是,

    1、Talk to other programmers;

    2、Do Program。

    3、Work on projects after other programmers.

    4、 Understand how the hardware affects what you do.

    Next Page »