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)
出问题出在分析（领域内涵没有把握住），不是出在类图代码的映射