讨论：主管将上百个Form一层层地继承，弄得做个界面都很麻烦，可行不？(100分)

W

wpy020327

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-07-27

• #1

为了做个界面，不得不一层层地回溯分析，也不知道哪段可以继承、哪个又必须重载、覆盖。对于各个祖先类有哪些属性、事件、方法缺少手册、资料，大都需要自己去了解。假如你自己直接从TForm开始做界面，就不行！结果，做个界面就耗去了工程开发的很多时间。大家讨论一下，OOP思想用在这样的场合适宜吗？我个人认为，OOP应该尽量用于对应用对象的类化、抽象化，而不应该用在象Form这种本来就已经抽象化得很好的场合，各位认为如何？

 

T

tseug

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-07-27

• #2

凡事都有个度，过犹不及

 

K

kkyy

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-07-27

• #3

凡吃都要有个肚,吃多了不行

 

X

xstdljj

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-07-27

• #4

普通界面搞啥子继承嘛，偶尔几个界面搞个继承就很管用了，主管为什么要化简求繁？脑子进水了，个人觉得delphi开发里面用到继承的主要在业务逻辑上面，这些方面有些实现会带给我们方便

 

G

gaobangsheng

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-07-27

• #5

继承是必须的,但是,一般不要超过五层的,这是delphi编程的原则<br>继承可以实现在进行一些统一修改方面的方便性,比如语言的支持.权限的控制....<br>一些用于统一处理的部分放到父类中,减少了工作量.

 

D

dirk

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-07-27

• #6

关键是有没有使用手册，和设计的是否合理，和继承层数又有什么关系？

 

W

wpy020327

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-07-27

• #7

关键是界面上的继承之后，并不能保证基类窗体设计的合理性，比如，界面元素的布局合理性、界面的优美程度、功能的适用性等等，而从精细化设计的角度来说，通用的东西，往往不能兼顾继承它的各个子类的特殊性，界面上因此不可能做到完美，而且，随着版本的升级，界面问题随时会出来，再者，继承方式实现之后，模块之间的联系反倒更加复杂，整个程序因此搞得更加复杂、结构的清晰性降低了很多，为后续的维护、改进、团队协同开发等带来一系列的问题。因此，我觉得oop用在界面设计上是用错了地方，有点故步自封之嫌。

 

徐

徐艳成

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-07-27

• #8

可行,虽然开发时马烦点,不过后期维护会很方便多!特别是较大的系统工作

 

L

lizhijie98

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-07-27

• #9

不光是界面集成，就是代码上面的集成，层数高了，谁都受不了的。

 

L

lngdtommy

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-07-28

• #10

继承是可以的，不过需要针对不同的业务做不同的分析，也不是说一味的往下继承，可以分成N个模块，根据业务需求不同，而继承不同的基类。

 

C

ch2001023

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-07-28

• #11

你们主管好强呀

 

D

danng

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-07-28

• #12

做基类Form是完全必要的，只是一个继承深度问题，就像前面的兄弟所有：凡事都有个度，过犹不及 。<br>如果你不做基类，直接从Form继承来写程序，那么你每写一个功能可以不受任何约束，但是后期你的程序将变得不可维护。因为那时你想改一点小小的内容，哪怕是一个字体的更换，你都要把你写的所有Form全都改一遍，这是不是很可怕。<br>如果继承层次很深，那么就会导致我们不能很好的理解前面几层基类的属性、方法，也可能致使误用，给使用带来难度。<br>一般情况下，最好使用的基类应控制在三层之内，每一层的基类都需要明确做一种职责的事情，如：第一层基类做权限控制，第二层基类做数据的增、删、改动作的控制，还有什么特殊公用的功能可以再做一个第三层基类。做继承时可以选择符合要求的基类做父类，那么不但自己可以少写很多非业务代码，而且今后维护程序非常方便。

 

B

ball_cao

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-07-28

• #13

我做过类似的项目<br>可以想见楼主的问题是从何而来的<br>最初由于几个功能类似就搞了一个form做基类实现了功能，后来越来越多的东西加到基类里，这个form就会越来越“重”也就形成了楼主说的情况。<br>要根本解决，应该是将这个很重的form的功能划分为多个，不是用继承 而是用组合的模式来解决问题。<br>但是这样的重构成本是很高的，尤其是在delphi中，多数delphi开发的程序没有良好的单元测试做支撑（相对于java的主流框架vcl不便于做单元测试）。<br>所以，我建议楼主能忍则忍，不能忍就自己花时间重构吧

 

X

xiaoli1740

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-07-28

• #14

关键是继承也得划分清晰，有固定的分层标准，否则就是灾难～

 

W

wpy020327

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-07-31

• #15

晕死，这样还搞啥程序？<br>主管一定要按照这样的方法做，程序员自己不能有一点的主观能动性，效率低下，<br>简单的还行，复杂的需要弄来弄去，这儿补一块，那儿屏蔽一下，这儿加个按钮，<br>那儿又屏蔽两个按钮，界面粗糙，很不美观。<br><br>哎，这可咋办，关键是你不能提异议，否则够你喝一壶的

 

5

555a

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-07-31

• #16

呵呵，看样子楼主刚接触这种模式，熟悉了就好了

 

不

不能没有你

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-07-31

• #17

如果你们主管只会用一层一层继承的方法来实现设计<br>那么他的设计模式学的太差了