2013-01-22 15:49:28 46486***(46486***)
class A
{
B Parent;
}
class B:A
{
} 各位老大,看一看这样一个类的设计合理不?
2013-01-22 15:51:04 lingshuai(375372***)
这样必须得有前置声明,否则可能编译通不过。
2013-01-22 15:51:53 灯火阑珊(58727***)
这个很正常,组合模式
2013-01-22 15:53:14 46486***(46486***)
程序的本意好像是这样一个意思,A是基本元素,B也是一个元素,但是又是一个容器,可以包含A
2013-01-22 15:54:14 46486***(46486***)
也就是程序运行时首先要有一个B的实例,然后产生A的实例,他们的父项是B
2013-01-22 15:55:51 深圳-Stupig(503685***)
现在是父类依赖于子类
2013-01-22 15:55:56 小武哥(757611140)
容器是所包含对象的子类,逆天吧
2013-01-22 15:56:35 瑶妖(24165***)
public abstract class Equipment {
private String name;
//实价
public abstract double netPrice();
//折扣价格
public abstract double discountPrice();
//增加部件方法
public boolean add(Equipment equipment) { return false; }
//删除部件方法
public boolean remove(Equipment equipment) { return false; }
//注意这里,这里就提供一种用于访问组合体类的部件方法。
public Iterator iter() { return null; }
public Equipment(final String name)
{ this.name=name; }
}
这个是 compsite
2013-01-22 15:56:37 46486***(46486***)
我感觉要加两个接口 interface iA
{
iB Parent;
}
interface iB:iA
2013-01-22 16:06:21 瑶妖(24165***)
感觉像 编译不过去的 组合
2013-01-22 16:06:21 46486***(46486***)
interface iA;
interface iB:iA;
class A
{
iB Parent;
}
class B:A,iB
{
}
这样可以吗?
2013-01-22 16:06:52 海东青(33202***)
这个什么也不是,在基类(超类)中依赖子类的具体实现
2013-01-22 16:06:52 46486***(46486***)
interface iA;
interface iB:iA;
class A:iA
{
iB Parent;
}
class B:A,iB { } 这样可以吗?
2013-01-22 16:08:36 海东青(33202***)
class A
{
A Parent;
}
class B:A
{
}
2013-01-22 16:10:32 46486***(46486***)
class x
{
arraylist items;
a()
{
(A)items[1].Parent.xxx();
}
}
2013-01-22 16:10:57 46486***(46486***)
xxx()的方法在B类中实现
2013-01-22 16:11:12 46486***(46486***)
x的代码根本编译不过去啊
2013-01-22 16:12:50 瑶妖(24165***)
成 编译器 的 测试程序了,看 编译器 纠错能力 [表情]
2013-01-22 16:25:59 潘加宇(3504847)
这个不对的
2013-01-22 16:28:20 潘加宇(3504847)
领域有它的规律,设计要捕获领域内涵,这样才能以最小成本跟随着领域规律变化。不仅是说能否写出代码或画出图的问题,爱怎么写怎么画都可以,说人是狗的一种也没问题。
2013-01-22 16:53:37 46486***(46486***)
class A
{
private B b;
}
class B
{
}
A和B具体是啥关系呢?
2013-01-22 16:54:29 46486***(46486***)
依赖、关联还是组合呢?
2013-01-22 16:57:08 龙盘虎踞(615875***)
这种问法是不太合理的,先从类图映射到代码,就不会存在这样的问题
2013-01-22 17:13:40 深圳-Stupig(503685***)
类的关系不能通过代码确定,类的关系表达出领域概念的关系,领域概念跟代码不能一一映射
2013-01-22 17:14:06 深圳-Stupig(503685***)
同一段代码,对应的类图可以有多种画法,同一个类图,代码可以有多种写法
2013-01-22 17:16:09 潘加宇(3504847)
不是这样了
2013-01-22 17:18:43 潘加宇(3504847)
代码有了,类的关系是确定的。之所以"类的关系不能通过代码确定"不是因为从代码不能倒推类图,而是因为我们要的是"反应领域内涵的类和关系",而不是随便的"类和关系"
2013-01-22 17:20:08 潘加宇(3504847)
有时我对开发人员说:这个不应该是泛化。开发人员瞪大眼睛"老师,是泛化啊,不信我拿代码给你看!"
2013-01-22 17:21:16 杭张凯(80447***)
关联和依赖不需要分的那么清楚,即使不理解那么透彻也行的!这个属于关联,不是依赖!关联一般以属性或成员变量的方式体现!可以用两个词语百度,不过也容易搞晕!还是把业务逻辑搞清楚,不要形成循环调用
2013-01-22 17:22:44 深圳-Stupig(503685***)
问个问题,根据类图写出代码后,再通过代码反推类图,能保证类图前后一致吗?
2013-01-22 17:24:04 龙盘虎踞(615875***)
老师想说的是 不能随便把随便从代码中反应的类关系 归结为领域内涵的关系,此关系非彼关系?
2013-01-22 17:24:06 京吴维(348010***)
我想不能吧,不然干嘛先要设计,才落地代码呢?
2013-01-22 17:25:26 杭张凯(80447***)
一般都有差别!我们这么干,获得的类图比较标准!存在的问题就是, 编写代码的时候,会修改原来设计的类图,甚至是关系!如果严格按照类图编写的,肯定一样的!
2013-01-22 17:26:24 杭张凯(80447***)
一个人考虑到所有情况,做出来类图!在编辑阶段,不做一点修改的, 太少了!尤其现在需求一直变
2013-01-22 17:27:23 龙盘虎踞(615875***)
一般核心领域的类图 八九不离十的
2013-01-22 17:28:22 潘加宇(3504847)
要通过案例反复培训,编码人员能够选择一致的实现套路
2013-01-22 17:27:42 深圳-Stupig(503685***)
这个涉及到另一个概念:UMl能否成为编程语言?UML能否像编程语言一样精确
2013-01-22 17:29:02 潘加宇(3504847)
群共享里答疑记录已经回答过这个问题。或者看《软件方法》第一章
2013-01-22 17:30:57 潘加宇(3504847)
另外,设计工作流推荐的做法是不需要画UML图,"代码就是设计"。要注意这里的"设计"的含义,代码是设计,但不是分析,不是需求,不是业务建模。反过来,"设计就是代码"也是成立的,例如用带有设计级调试和强大代码生成能力的Rational Rhapsody开发实时嵌入系统。对UML不了解的人经常问我的一个问题是:UML能代替编码吗?其实源代码(也就是人脑需要编辑的介质)的形式一直在变化,从最初的机器语言到汇编语言、过程式高级语言到现在流行的面向对象语言。"模型就是源代码"不是可不可能的问题,而是合不合算的问题。真实世界中,涉众对许多系统的质量要求并不高,电商网站、银行系统出个故障,人们习以为常,能够接受,反正出了故障再恢复呗。这样的系统,充分的建模没有必要性,也无可能性(类太多,工期不允许),只需要对关键的类充分建模。如果做一个心脏起搏器,通过充分的建模尽可能减少人工编码导致的偶发错误是必要的,也是可能的(类的个数少)。2013-01-22 17:32:31 潘加宇(3504847)
不同工作流之间首先是内容的区别,不是形式的区别。了解了这一点,用Java照样可以描述需求,UML也可以编码。只不过不同的内容,用不同的形式表达更高效。
2013-01-22 17:34:15 京吴维(348010***)
好像有点懂了,分析,设计,代码,其实都是用不同形式来描述同一样东西,代码太抽象.
2013-01-22 17:34:57 潘加宇(3504847)
"分析,设计,代码,其实都是用不同形式来描述同一样东西"--不对呀
2013-01-22 17:35:21 潘加宇(3504847)
既然是同样的东西,干嘛要用N种形式描述呢
2013-01-22 17:37:10 深圳-Stupig(503685***)
有不同的内容,和不同的形式,内容A、B都可以用形式C、D表达,只是是否高效实用的问题?潘老师是这个意思吗?
2013-01-22 17:38:15 潘加宇(3504847)
参见《软件方法》第一章
2013-01-22 17:41:13 潘加宇(3504847)
出问题出在分析(领域内涵没有把握住),不是出在类图代码的映射