Coolyu0916
2007-03-02 13:33
siberian , state模式并不暴露state的

我们使用的统一的方法,给用户也是统一的接口

不过在不同的state下我们引用不同的state类

用户使用的时候肯定是 woman.setAge(30); woman.procreate();

如果不给出age 就采用默认的age,这种接口不对么??

我们平时说女人生孩子,一般来说我们都是认为是年轻的妇女

但是当你告诉他是一个小女孩或者老太太的时候,调用生孩子的方法必然是一个空或者是一个异常(你告诉别人她不能生孩子,或者你跟别人说这是开玩笑)

定义接口的时候你不需要关心这些问题,因为问题只有真的发生才有意义(说女人生孩子没有意义,必须说某个女人生孩子才有意义)

你在考虑问题的时候只要让其具备功能,当你认为某个方法可能存在疑义或者可能出现问题的时候,要在子类或者方法中进行控制。

Coolyu0916
2007-03-02 13:48
checkcode 说实话,我一直到现在还不明白你说的意思

我们举例

如果一个对象 x 继承了正方形 比如说 (x为边大于5的正方形)我们称之为大正方吧

你要对图形计算面积,或者周长

那么你有什么不能定义那??

利用长方形的方法就可以了

子类不使用父类的实现不可以么??

siberian
2007-03-02 14:10
toCoolyu0916

咱们在说类之间的关系.这个时候还处在从需求得到分析类的时刻,而没有到后面设计时运用某种技巧,某种模式的时候.

这个时候,那些职责是他本身的.那些职责是外在的.和state还扯不上关系。

比如说,一个女人类他有哪些行为,那些约束。那么state模式只不过是在确定了这个分析类之后的优化处理,希望把女人类某些东西外包了。

Coolyu0916
2007-03-02 14:51
那么我们就从需求方面走

首先我们确定了人的行为

我们不可能设计一个万能的persion class

我们只要实现有限的功能,在系统中用到的,比如eat() sleep()

现在要在性别上进行区分

这时候我们应当考虑需要怎样区分了,这个区分是为了标识还是为了实现

比如只是为了表示一个身份,一个证件,而不需要一些女人特定的动作,完全就不必需要子类,或者只是为了添加一些附加功能,也是不需要的。

这个必须从逻辑上说的通,你不能说 persion.procreate(),这个不符合逻辑,用你这个接口的人也会晕的,必须是woman.procreate(),这个时候你说不需要继承,使用组合么??或者是简单的引入一个方法么??

至于具体能不能procreate,需求的时候会告诉你,当女人在20-50的时候可能会生育,但是是20还是50是在运行中才会体现的,不是你设计接口时考虑的问题。那是到了详细设计的时候你才要关心的。

siberian
2007-03-02 15:32
类的约束,我们创建一个Person,那么作为一个顶级类,它可以没有约束,作为一个空泛的类而存在,因为它处在抽象的顶级。

但是我们一旦有了一个子类,并且子类的相对于父类有了约束,比如长方形中长和宽可以随便数值,但是到了正方形中不行了。他们要相等,不相等的就不是正方形。这个子类很明显是靠增加约束来建立的,而不是功能的扩展。

我们在需求中挖掘出子类之后,(注意不是为了方便而创造出来的,而是现实中有了子类),就要确定它是否有了约束,还是只是扩展了。

在你举的例子中,如果生育期妇女这个概念常常出现,那么它就应该是一个类,它成立的约束条件就是年龄在20-50,性别女。不满足这个约束,这个类就不成立。它并不是一个运行时的问题,而是一个类本身的,与生俱来的东西。你可以再后来的设计中,把它放到配置文件中,但是不能回避的是,它是类本身的东西。不符合这个约束,他就不是这个类。

接口设计还要排在分析类获取的后面。至于是否方便也不是考虑的问题。我们在这个阶段是要做到完美的映射。

猜你喜欢
9Go 上一页 1 2 3 4 5 6 ... 9 下一页