寻求抽象对象与抽象对象的交互的解决方案

[品铭工作室]

我在做一个项目， 视图层使用的是抽象对象，而逻辑层是抽象的具体实现，在开发中期，发现很多问题，而最根本的问题是抽象与具体实现之间发生冲突。
要解决的问题：
任何事物在不同的人(角色)看来，都有不同的观点(关注点不一样)，我们可以用多态的行为来解决，但在开发中引发的问题的我们想即想减少视图与逻辑的紧密度，同时又要保持其自身重定性和可扩展性，也就是逻辑的具体实现或改变不影响视图，但同时又要体现同一事物的多面性和发展性
举例：(C# 伪代码)
抽象父类
public abstrct class A ｛ A.New( tag ); ｝ //依据tag值 A.New方法返回不子类实例的抽象对象 ，
子类
private class A1：A ｛ Name1{ get;set; } ｝
private A2：A { Name2{ get;set; } }.
.....后期依据需求会延伸出不同的子类

public abstrct class B (实现形式同上)
private class B1:B ,B2:B ...(子类)
抽象类与子类及子类之间有细节上的差异 ， 另外父类与子类可能不存在于同一个物理位置 （ 就是所在的DLL不是同一个）

类之间的访问规则（父类之间、子类之间、父子类之间，同类型之间与不同类型之间）：
1.在视图层只识别父类型，不知道子类型，
2.在逻辑层，
同一个类型下的父子类 之间可以相互访问或类型转换如A -> A1,A2.. ，B1->B,B2,B3...
但不同类型的父子关系只能通过抽象类进行交互(或说不同类型的子类是不能直接进行交互的),如：
B<->A ， A1-> B，B1>A , 但不能 A1,A2->B1,B2 , B->A1

视图代码：
A a = A.New("A1");
B b = B.New( "B2" )
//需要对a与b内的某个拓展属性进行值的交互 ,
运行时的代码的样子： a.Name1 = b.Name2 ; 可能后期的子类还会出现其它新的属性和方法(不一定是Name1,Name2...不要固化思维或形而向上来才考虑问题)，我是说在运行时的样子，但在编码时只知道A和B的类型，不知道其具体实现子类的扩展部分的元素(属性或方法)，这种情况下如何实现抽象对象与抽象对象 （父对象与父对象）之间的交互？？换句话说我需要确定具体的子类才可以交互。

原来我是实现个性化接口来实现 （每个子类实现唯一的接口），但这种方案行不通，最终还是间接的对子类型的依赖而且这种方案很笨不灵活，另外这个和反射没有关系，不要以为可以通过反射解决问题，一点关系都没有

最后，也许我在思路上出了问题，或也许进了牛角尖，但不管怎么样，还是请大家给点主意。多提点！

[以专业开发人员为伍]

抽象不代表着没有内涵。你不要用什么“万能的”编程来想着做一些具体事情。 但凡能够抽象出实用、可扩展的系统的人，都是有着非常坚实的对各种具体实现的理论基础，然后才能抽象。如果看不出实际，那么所谓“抽象”就是“设计比较空洞”的借口。 此时，你应该把空洞放在一边，先做一些具体的工作。

[以专业开发人员为伍]

抽象其实很朴实的东西。如果你喜欢做文章，或者有天花乱坠的功力，可能可以写出一些文章到大学生杂志获奖。但是我是站在程序开发角度，来看“何时、为何”抽象。我们进行程序设计，自然是希望代码少写一些，class或者接口少定义一些，这跟那些只是为了写个“看上去挺厉害的理论文章”的人出发点肯定不同。只是为了编程更有价值，才进行抽象扩展。绝不是为了教条而抽象。

[wanghui0380]

额，玄学啊 居然在管理类需要依赖到具象子类了，这个设计已经不太友好了 不过已经成这样了，直能采用映射表去搞了。大体是这么描述把 1.需要在每一个对象上有一个获取扩展元数据的方法，这个你可以自己写一个，也可以直接使用反射获取自有属性列表 2.需要有一个注册表，去注册任意类型A到类型B的映射关系，大体上类似： 注册<A,B>(func<A,B> fun) 3.查询注册表，调用里面的convert运算委托 额，我怎么觉着我是在描述automapper/EmitMapper滴基本设计呢？ ps：作为抽象管理类本来应该只依靠抽象工作才符合依赖倒置原则，为啥你这个管理类会去依靠具体实现才能工作呢？如果是数据交互，那么数据交互本身就是一个抽象，他应该自成管理类，所以才有automapper/EmitMapper这类东西的出现

[rtdb]

加多一个通用方法： GetDataByName(string Name); a.Name1 = b.Name2 可转换为： a.Name1 = b.GetDataByName(Name2); a就不在需要知道b的具体方法了

[品铭工作室]

对大家给出的意见，我表示非常高兴。 我想解释一下问题的背景，原来的系统已经用了很多年了，整个结构设计比较单一，由于用户越来越多，提出了很多个性化的需求，并在原来的系统上不断的扩展其功能，而扩展中有没有做重构，随着时间的推移，导致整个系统很臃肿(业务逻辑复杂，改一处地方，会影响到其它的功能)，表现为维护困难(维护成本高于预期)，大的扩展功能根本没法加上去，核心表的字段很多高达几十个以上(某个功能只会用到其中几个)，且没有统一性，后来进行了重新开发(重构已尝试过，成本高于重新开发) 我提出的问题的确是站在纯技术的角度进行表述的，而这种问题之前几个项目开发时也有遇到过，由于赶工期或影响不大，也就不没去解决，而这次是收集了一些普遍问题（都是些纯业务问题，如果说业务问题大家也不一定都了解，同问题都表现在局部的功能点上，也没有必要把问题的上下文都拿出来讲），通过这些普遍的问题的分析找到共性，才发现这个问题， 大家有些误解也是理所当然的，对这个问题解决时间有限，#3的看法我都想过，我觉得不是最优的解决方案，不过我也没有想到更优的方案，我也是上来试下运气，由于时间有限我也不深究了，做为我个人我觉得如果能很好的解决这个问题，对很多普遍的业务需求转化为软件实现问题是一个很大的进步（对于那编程设计原则应用到实际的开发还是会存在很多未知的领域，必竟社会在进步）。 同时，#1我也非常认同，做技术的人往往为犯为技术而技术的错误，我希望自己尽量不会犯这样的错误(有时候还真的身不由已) 我依然会关注这个问题，希望有人给出更优的方案，期待中....

[缪军]

相互以来的对象间的交互可以call来call去, 但是,现实世界中确实存在而且是很普遍的:对象间在没有关联和依赖的情况下相互交互, 他们之间仅仅共同依赖通信的方式, 从设计层面,我觉得楼主的设计缺少对消息的描述, 从实现层面,微软的委托和事件为我们轻松地实现消息机制提供了可能

[缪军]

引用 6 楼 microtry 的回复:

相互以来

更正为:相互依赖

[joyhen]

引用 7 楼 microtry 的回复:

引用 6 楼 microtry 的回复:

相互以来

更正为:相互依赖

大手，我可否理解，依赖其实也是约束的表现呢

[缪军]

引用 8 楼 Joyhen 的回复:

大手，我可否理解，依赖其实也是约束的表现呢

在UML中,依赖(dependency)的语义(比较含糊)大致是: 提供者(Supplier)的修改可能影响到消费者(Client)的修改,或者说如果没有提供者,消费者的语义就不完整; OOAD中的消息用来描述和实现依赖 而你说的约束是什么,我不大清楚, 如果指的是UML中的规约specification或者对象约束OC,那是对对象的详细说明,肯定是两码事

[品铭工作室]

其实这个问题我也想通过，这不表示我已找到了解决方案，这个问题我依然找不到很直接的方法解决，如果还订着这个问题不放，就很容易沦陷于为技术而技术的黑洞。我基本放弃了对它的求解，人总是想追求完美，但现实际事物却总是有缺点的。 说回技术： 这种依赖(安楼上的说法)会有两种依赖状态：运行时过程的依赖和编码过程的依赖。而运行时又依赖于编码 在编码时，既然想持有父类而又想拥有所有子类的不一样的方法或属性，同时又不想增加额外的功能(如：接口或消息等标识性的功能)，这已违背了常理了，既然象一个父类对象(实际是一个子类对象)，在编码(静态)状态环境下，就要象一个父类的样子，不然就不是面象对象的编码了(直接写二进制代码)，类型也无法发挥它应有的作用了。 运行时，象一个父类，实际是一个子类，那就需要明确的指定他是那一种子类对象，或类型转换，或接口，或消息都可以明确这一点，再去在这个子类对象中找到你想要的。 最后想说：黄金无足色，白璧有微瑕 ，但依然有价值，依然很漂亮