Spiga

突然发现一篇很受用的帖子~面向行为

2007-08-01 10:04 by 土星的狗狗, 2449 visits, 收藏, 编辑
http://www.cnblogs.com/zengezenge/archive/2007/07/31/837860.html
引用:我们一直以来都从“Is A”的角度来对对象进行归类,但是仔细的想一想,“Is A”的标准是什么?我们怎么样才能判定一个对象“Is A”另外一个对象呢?大家是不是基本靠猜测或者凭经验在做?这也是软件设计一直被当作是一种艺术行为的原因。

        是啊,这个IS A到底是指的什么,我们为什么没有想到ACT FROM A。
        从开始接触面向对象到现在,真正用到它的地方并不多,而只是把它当做一个理念在推广,朋友曾经说过一句话:你这样太累了吧,全部面向对象设计不现实。其实不是不现实,而是我们没有充分理解这种理念,而导致现在很累。

        抽象出来一个类,抽象出来一个方法,实现一个接口并不能说明就在使用面向对象,如果这种实现让本来很简单就可以完成的工作变得异常复杂,还是不用的好。一个好的设计是从一个基类开始的,就像.NET,OBJECT是一个多么好的抽象。
        我长期从事财务系统的开发,其它从这里面也能看出很多可以抽象的单位,比如:报表这个单位就可以做为一个总的基类,他可以抽象出取数,布局,打印,预览,导出接口四个部分,在不同的模块里可以有不同的实现,而现在我经历的系统中都没有这些,具体业务具体实现。
        我只是举一个例子,也许里面有说的不对的地方请大家指教。
        其实在我接触到的这些模块里面,有一个给我感触很深,那就是凭证模块,其实这个模块最可以用面向对象的理念去实现了,可以抽象的东西很多,接口也很多,其中方法属性又是异常的复杂,如果可以合理的设计真的可以达到事倍功半的效果,有这方面经验的朋友一起讨论一下吧~
Add your comment

17 条回复

  1. #1楼 deerchao      2007-08-01 10:26
    如何抽象,抽象到什么程度--由需求决定.
     回复 引用 查看   
  2. #2楼[楼主] 土星的狗狗      2007-08-01 10:37
    现在从需求的角度上已经很难以个人的意愿去设计,很多东西在中国都不太现实啊。
    只要能实现最基本的,易于开发与修改的抽象就OK啦
     回复 引用 查看   
  3. #3楼 随风流月      2007-08-01 11:05
    不是为了面向对象而面向对象,正如不是为了科学而科学一样。
    各种设计方法,设计模式,设计理念的目的都是为了封装变化。
    实质上,它们的目的都是为了简化程序员的工作。不要认为开发时简单就是简单,还要考虑日后的维护,需求变化与升级工作。
     回复 引用 查看   
  4. #4楼 OK_008      2007-08-01 11:22
    新手弱弱的问:太抽象会怎么样?
     回复 引用 查看   
  5. #5楼 随风流月      2007-08-01 11:32
    @OK_008
    类爆炸。。。
     回复 引用 查看   
  6. #6楼 航天奇侠2007-08-01 12:10

    我觉得大伙的思路有问题。

    面向对象并不是面向抽象概念,而是面向对象实体。
    先有实体,再有抽象,从而能够以抽象概念进行编程。

    是这么的一个过程,而不是相反的先有抽象概念,然后推出另一个抽象概念,这完全是无源之水,无稽之谈。

    就好像博主所引用的那个帖子,就是犯了这么一个错误。首先出现鱼类这个抽象概念,然后再来想当然的分类:能爬树的,不能爬树的~~~

    鱼类这个概念是存在自然概念中,而不是特定的程序概念中的,这是很大的区别。要开发首先应该看到的是程序概念的特定的鱼,而不是自然概念的鱼。否则你就添加一堆的无用特性吧。

    因此我觉得面向对象,并不是一种概念游戏,而是一种根据具体来进行归纳的,是狭义的,有局限的抽象概念。这个程序的概念,就是这个程序适用,而不是放到所有程序都能使用的万能概念。所谓的扩展,是指在原来的基础上进行修补,而不是制作一个万能的抽象概念,放之四海皆准多功能基类。

    面向对象不是一种万能灵药,设计也并非要面面俱到,适用千年。有经验可以设想远一点,没有经验就少考虑这些将来的事情。但是不能预见未来,却要设计一种面向未来的概念,这反而是一种无用功与负担。


     回复 引用   
  7. #7楼 Sigmazel      2007-08-01 12:51
    航天奇侠

    你说到点子上了。一个复杂事物刚一开始是不能有一个清淅的概念的,要一点点的了解它的属性和行为,然后再进行分类,分层次等等。
     回复 引用 查看   
  8. #8楼 Anytao      2007-08-01 13:53
    类设计,也就是在封装变化的原则下,不断重构的过程,抽象出接口和继承关系是一步一步更加具体实体和业务需求来的,设计的目的是以最简单的方法解决问题,而过度设计出来的抽象只能起到反作用.
     回复 引用 查看   
  9. #9楼[楼主] 土星的狗狗      2007-08-01 15:32
    @航天奇侠

    如果按照人的正常想法,就是先抽象然后再去具体实现的,如果每一个都有实现之后才会去考虑抽象,这样会太累,而且让设计也变得没有了规则。
    但有一点我是很赞成的,很多事是要有一个清淅的概念之后才会去抽象,就象一个需求,只有我们深入的了解了,不仅仅是从编程语言的角度,是从那个行业,把每一个涉及到的元素抽象出来,包括里面的动作和动作涉及的属性等所有元素,不知道我说的对不对,但现在我的水平也只能这样去考虑了!
     回复 引用 查看   
  10. #10楼 Arthur Chen[未注册用户]2007-08-01 16:55
    粗略的感受,几个事物有个某个共同点就可以抽象了,然后逐渐添加更多的事物,抽象也会逐渐变大,然后大到一个适度的尺度,就分离,演变出一个另一个抽象...直到实现所有的需求为止,说到底这是个不断重构的过程.
     回复 引用   
  11. #11楼 losang[未注册用户]2007-08-01 17:08
    【报表这个单位就可以做为一个总的基类,他可以抽象出取数,布局,打印,预览,导出接口四个部分,在不同的模块里可以有不同的实现,而现在我经历的系统中都没有这些,具体业务具体实现。】

    你没做怎么会有,服了你了
     回复 引用   
  12. #12楼 cnblogs[未注册用户]2007-08-01 17:18
    @航天奇侠
    说的没错,楼主不要被那些冒充nb的家伙忽悠了
     回复 引用   
  13. #13楼[楼主] 土星的狗狗      2007-08-01 18:08
    re:all body

    其它在CNBLOGS看东西就是为了打开集思广益,让大家都围着一个棘手的问题讨论,把自己的疑问说出来,一起来解开,不是吗?

    看着大家都为了OOP再说着自己的看法,其实最终还不是OOP嘛~只不过对象成了行为或者什么其它的东西,也许只有这样想,这件事儿便也通了!


    不管是抽象生物也好,元器件也好,什么其它任何东西都好,最终通过OOP来实现了优秀的设计是目的。

    我个人还是喜欢把对象抽象成行为的,大对象也许是实体,但具体的元素还是行为嘛!呵呵,说着说着,还是把自己又饶进去了
     回复 引用 查看   
  14. #14楼 金色海洋(jyk)      2007-08-01 19:33
    @航天奇侠
    同意。
    自然界是很复杂的,有很多的特例。
    客户的业务流程(业务逻辑)也是很复杂的,也有很多的特例。
    我们要面对一般的,先实现一般的需求,再去考虑特殊的,不要一上来就把所有的特里都考虑进来。
     回复 引用 查看   
  15. #15楼 土星的冰人      2007-08-01 19:38
    看看行了,但不要过于极端,这篇帖子的内容我并不完全认同。这种思路,至少这种表达形式有点太......
    同意航天奇侠的观点.
     回复 引用 查看   
  16. #16楼 木野狐(Neil Chen)      2007-08-02 10:00
    建议大家看看 “正方形和长方形”的例子:
    http://blog.joycode.com/lostinet/archive/2004/08/12/30442.aspx
     回复 引用 查看   
  17. #17楼 徐少侠      2007-09-06 17:50
    第一,没必要抽象的时候绝不抽象
    第二,当需求造成出现有可以被抽象的时候,必须抽象

    似乎是以前敏捷开发里头的思想

    也就是说不要一上来就先自己给自己弄好几十个类,N层的继承
    好东西够用就是了
    哪天用不下去了,记住,不是去修改原有的类内部的代码。而是进行OOA和OOD
    最后利用OO的思想来解决需求变更的问题

    没必要还没下雨就先打伞
    没必要在不需要基类的时候先准备个在那里,然后说:这样可以增加扩展性
     回复 引用 查看   
Creative Commons License
It's my life