|
锁定老帖子 主题：阿Q:革命了，革命了！（也谈IOC的好处）
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-03-18
引用 xml知道一切和类职责单一有矛盾么？ 你这是在用xml编程，只是文件名不一样！.xml和.java 创建A就是要用xml配置A的构造情况 ABG*CDEFG， 创建Z就是用xml配置C的构造情况ZFGHJK.... xml本省的指责很重。 再者我用到A的时候一定要用BG*CDEF么？可能在某种情况下用，某种情况下用DWQE,你是一次构造？还是写branch？会越来越复杂的。 |
| 返回顶楼 | |
|
发表时间：2005-03-18
TO：frankensteinlin
关于A要B帮他买电脑的事。 首先，A要办一件事，肯定要依赖于某个事物，但不能依赖于固定的某个人（如：B），你所提到的C应该是一个interface而不是class，可以看作是可以帮A买到电脑的任何人或组织。 这样就不至于哪天B归西了A就买不到电脑了。 |
| 返回顶楼 | |
|
发表时间：2005-03-18
xml 和container 归西了整个系统就崩溃了，这种ioc其实就是一个主控系统，完全依靠在单节点上，那个更危险？
|
| 返回顶楼 | |
|
发表时间：2005-03-18
建议大家 不要在再同 frankensteinlin 辩论 ioc 的好处，我看的都累
|
| 返回顶楼 | |
|
发表时间：2005-03-18
jvm挂了的话，我们所有的java应用都挂了，你用不用IoC都一样
所以你还是移驾去研究分布式系统的好:-) frankensteinlin 写道 xml 和container 归西了整个系统就崩溃了，这种ioc其实就是一个主控系统，完全依靠在单节点上，那个更危险？
|
| 返回顶楼 | |
|
发表时间：2005-03-18
pufan 写道 这是用继承实现变化的典型例子，pc子类的多少完全取决于档次的多少，或者说取决于pc内可更换零件的组合的个数，这样可更换零件的种类增加时，子类将会成爆炸指数增加。 当然这也没什么不好，只要你不觉得繁琐，但我更倾向于用接口聚合的方式实现变化。 final class PC
{
CPU _cpu;
Memory _memory;
void setCPU(CPU cpu);
{
_cpu=cpu;
}
void setMemory(Memory memory);
{
_memory=memory;
}
}
这样不同档次的pc只需要更换不同的CPU或Memory就能获得。 如果仅仅是从单个对象的角度来考虑的话，无论是使用接口聚合或者是继承都不会有太大的关系，最多只是向左走或者向右走的不同选择而已。但是在进行系统架构设计的时候，则必须从全局角度来进行规划，要么全部向左走，要么全部向右走，各行其是只会损害整体利益。 无论是在哪一个领域，层次问题都是非常重要的，任何一个复杂的流程都必须有统一、清晰、明确的层次划分，每个层次都必须是各司其职业、责任清晰明确，保持单向的依赖和控制是避免系统陷入混乱至关重要的手段。 就以PC市场为例，最终用户、销售商、PC制造商、部件生产商形成了一个完整的供应链。最终用户是PC使用者，销售商根据客户的需求从合适的PC制造商那里购买PC，PC制造商根据本公司的产品策略从部件生产商那里购买合适的部件并装配成PC，部件生产商则根据市场需求不断研发新产品。 所以我们的供应系统由销售商、PC制造商、部件生产商构成，商品则由PC及各种部件构成，在这里我们将供应系统简化为三种供应商各只有一个，PC产品只分高、中两档，PC部件也只有cpu和memory两种、各自有两档。
部件供应商层次：
class Memory;
class CPU;
class 大容量Memory : Memory;
class 普通Memory : Memory;
class 高速CPU : CPU;
class 普通CPU : CPU;
class 部件供应商
{
static public CPU GetCPU(string 档次);
{
case "高档": return new 高速CPU();;
default: return new 普通CPU();;
}
static public Memory GetMemory(string 档次);
{
case "高档": return new 大容量Memory();;
default: return new 普通Memory();;
}
}
PC制造商层次：
class PC;
class 高档PC : PC
{
protected override void ConstructMe();
{
m_cpu = 部件供应商.GetCPU("高档");;
m_memory = 部件供应商.GetMemory("高档");;
}
}
class 中档PC : PC
{
protected override void ConstructMe();
{
m_cpu = 部件供应商.GetCPU("中档");;
m_memory = 部件供应商.GetMemory("中档");;
}
}
class PC制造商
{
static public PC GetPC(string 档次);
{
switch(档次);
{
case "高档": return new 高档PC();;
default: return new 中档PC();;
}
}
}
销售商层次:
class 销售商
{
static public PC PC GetPC(string 档次);
{
PC制造商.GetPC(档次);;
}
}
就普通的最终用户而言，可见的只有PC以及销售商，如果部件提供商升级了部件，其影响范围完全局限在部件供应商那层，同理，任何一个供应商的改变其影响被严格的限制在某个层面、甚至仅仅是某个对象。 如果最终用户是个专家，他非常了解PC的构造，完全有能力自己DIY一部出来那也没问题。
class MyPC : PC
{
override void ConstructMe();
{
m_cpu = new 高速CPU();;
m_memory = new 普通Memory();;
}
}
在这种规模的系统中，如果使用接口内聚，只会使系统结构复杂化。 |
| 返回顶楼 | |
|
发表时间：2005-03-18
to age0
其实你的代码已经需要ioc了.
PC制造商层次：
class PC;
class 高档PC : PC
{
protected override void ConstructMe();
{
m_cpu = 部件供应商.GetCPU("高档");;
m_memory = 部件供应商.GetMemory("高档");;
}
}
有多个部件供应商的时候,而高档pc这个类并不依赖于具体的部件供应商时. 这个部件供应商就要注射进去,怎么注射?一种, PC制造商决定,那么就是
class PC制造商
{
static public PC GetPC(string 档次);
{
switch(档次);
{
case "高档": return new 高档PC(new 供应商b(););;
default: return new 中档PC(new 供应商a(););;
}
}
}
另一种, PC制造商也决定不了(就如电脑城的小摊,它需要客户自己来决定) 下面是一种方法
class 小摊PC制造商
{
private static 部件制造商 shang;
public 小摊PC制造商(部件制造商 shang);{
}
public PC GetPC(string 档次);
{
switch(档次);
{
case "高档": return new 高档PC(shang);;
default: return new 中档PC(shang);;
}
}
}
客户的代码
new 小摊PC制造商(new 联想(););;
其实ajoo说的已经很明白了,可惜了ajoo的那么一大段文字. |
| 返回顶楼 | |
|
发表时间：2005-03-18
youcai 写道 to age0
其实你的代码已经需要ioc了. 其实ajoo说的已经很明白了,可惜了ajoo的那么一大段文字. 不用急啊，老兄，我们举例的时候已经说明了这只是考虑单一供应商时候的情况，将系统结构由单一供应商向多层次多供应商进行平滑过渡的情况等一下再来仔细讨论。 |
| 返回顶楼 | |
|
发表时间：2005-03-18
to youcai
你的代码有一个非常严重的问题，就是你假设PC的所有部件都是由同一个部件供应商提供的，但实际情况并非如此，我们的销售策略是非常灵活的，任何需要的时候我们都可以从不同的厂家选取不同的部件组装成一台PC，比如高档机的CPU由Intel提供，内存则由kingMax提供，中挡机的CPU由AMD提供，内存则由现代提供，你该不会是想把这些供应商都注射进去吧。 |
| 返回顶楼 | |
|
发表时间：2005-03-18
引用 class 大容量Memory : Memory; class 普通Memory : Memory; 我再次觉得这个讨论真的应该锁掉算了。我们压根说的都不是同一种语言。这种事情在我们这通常都这么描述： class Memory {
public long getSize();;
}
连“大容量Memory”这种class都设计出来了，还讨论什么OO什么设计呢？还是别讨论了，趁早把这帖子封了大家省事。 |
| 返回顶楼 | |
