Head First Object-Oriented Design and Analysis学习笔记（四）

第四章

Analysis

Taking your software into the real world

前言：

 

案例分析：

案例描述：

       第三章也解决了客户的需求问题，但是当程序在现实环境中运行时，问题出现了，其他的狗的叫声也能使得这个门自己打开。。。

问题提出：

1 让门可以根据自家狗的叫声开门给它

 

问题解决：

1 根据错误更新我们的use case，并且要检查更新时是否会衍生出新的use case，因为每个use case只可以解决某个目标，而如果更新后多了其他目标，那么就要把那些内容独立出来作为一个新use case,书里面的解决方法是，从use case的更新过程中发现一个新的use case，RecordBark。

原来的代码结构为：

public class Remoter   //原来用户所用的遥控器，当他们听到狗叫时就可以用这个遥控器开门

{

private:

     DogDoor door;

     //.....

public:

     void pressButton();

     //....

};

public class DogDoor   //给狗出去的门

{

private:

     bool open;

     //.....

public:

     void open();

     void close();

     bool isOpen();

     //.....

};

public class BarkRecognizer //根据用户的需求变化增加的新类，一听到狗叫就会自动把门关了

{

private:

     DogDoor door;

     //..

public:

     recognize(String bark);

     //...

};

例子中给了两个不同的基于上面这些代码的解决方案

第一个解决方案如下

public class DogDoor

{

private bool open;

private String allowedBark;

     //.....

public DogDoor()

{

        open=false;

}

public void setAllowedBark(string bark)

{

    this.allowedBark=bark;

}

public string getAllowedBark()

{

    return allowedBark;

}

public   void open();

public   void close();

public   bool isOpen();

     //.....

}

在DogDoor类中保存类一个allowedBark串来保存狗叫，然后通过对这个属性的获取和设置来完成相应的功能。

第二种解决方案：

public class Bark

{

    private String sound;

 

    public Bark(String sound)

    {

        this.sound = sound;

    }

 

    public String getSound()

    {

        return sound;

    }

 

    public bool equals(Object bark)

    {

        if(bark instanceof Bark)

        {

            Bark otherBark=(Bark)bark;

            if(this.sound.equals(otherBark.getSound()))

            {

                return true;

            }

        }

        return false;

    }

}

增加一个新类Bark来保存叫声，返回叫声，比较叫声。

这两种解决方案的代码很相似，DogDoor的代码更新也很相似，但第一种解决方案直接拿bark串来比较，而第二种解决方案则通过Bark类实现委托，来完成比较（这又是用到了第一章的知识，通过将对bark的比较委托给Bark对象，我们将“比较的实现”脱离了需要得到比较结果的上下文，这样一来在修改比较方法时就只需要改动Bark类中的比较方法而不会影响到其他对象或者上下文，）。

 

Important Point：

1 your software has a context(告诫我们要考虑系统运行时的真实环境-上下文)

2 each use case details one particular user goal

3 delegation shields your object from implementation changes to other object

4 Looking at the nouns and verbs in your use cases to figure out classes and methods is called textual analysis

5 textual analysis tells you what to focus on, not just what classes you should create(所以很多时候我们对某个问题关注的对象是错误的，而textual analysisi能帮助我们应该focus on哪些对象)

6 in class diagram, the name of the attribute in the source class is written at the end of the association pointed to the target class. (when one class refers to another class, that represents an attribute)(即在类图中，有向关联的箭头终点的类应该是起始端的类的一个属性成员)

7 noun analysis: you do this to your use case to figure out what classes you need to your system

 Multiplicity: describe how many of a specify type can be stored in an attribute of a class

 Attribute: equivalent to a member variable in a class

Class Diagram: list all the code-level constructs along with their attributes and operation

Operation: this is a UML term that usually represents a method in one of your classes

Association: visually show that one class has a relation to another class, usually through an attribute

Verb analysis: help you figure out the candidates for methods on the objects in your system

小结：这一章也是通过简单的例子来说明主题---在现实情况下运行系统分析系统，以防止不必要的错误发生，大部分内容看起来没有什么新意，很多都是学过的，包括在前面学过的，而且所谓的现实情况下运行可能就是软件工程中的过程把握质量，在过程中测试，而这种测试不能在理想的环境下进行，应该考虑到不同的“恶劣”环境

杂记：我们一直都在一个理想的情况下进行我们的项目，但是项目最终要在现实世界里运行，所以我们要考虑我们的系统在不同上下文运行时的状态。

只有通过分析-analysis，我们才可以得到potential problems

文章还介绍了通过use case中的nouns来发现class，并且even if the nouns in your use case don’t get turned into classes in your system, they are always important to making your system work like it should