日历

September 2020
M T W T F S S
 123456
78910111213
14151617181920
21222324252627
282930  

成员函数的枷锁

Home Forums 《冒号课堂》讨论区 成员函数的枷锁

  • This topic is empty.
Viewing 4 reply threads
  • Author
    Posts
    • #1140
      Lumj
      Member

      大多OO语言对多态的支持,都限定了多态能力的使用方法,即,要使一个操作多态,它必须以成员函数的形式存在

      ——对了,说明:指动态的类型多态,GP不算(也就是老师你的书里说的..’inclusion poly’)

      我在最近的开发中发现这似乎很容易带来设计枷锁:

      有时,想做的仅仅是以类型为指标来作分派,但是这就(由于语言提供的接口的限制)必须走那条唯一的途径:通过成员函数.但是我想这前后两者是没有必然联系的,至少从可行性(语义的合理性,实现的可能性)上说一样可以通过游离函数来做

      假设有A,然后X,Y都继承A,现在对A类型的变量的某种操作需要多态(对X,Y有不同的做法),那么这样的限制就逼迫人把该操作写成A的成员函数,但是这有可能是违背当前的设计场合的.比如,这个操作的逻辑是使用A对象的上下文的逻辑,A对其的知情根本就没有意义,那么要么就通过成员函数被强迫耦合,要么就自己写类型判断分派

      不知我的表达是否清楚?

    • #1367
      hui
      Keymaster

      >>现在对A类型的变量的某种操作需要多态(对X,Y有不同的做法),那么这样的限制就逼迫人把该操作写成A的成员函数

      既然存在“对A类型的变量的某种操作”,那么把该操作写成A的成员函数不是很自然吗?假如该操作对X、Y有不同的做法,但又属于一类操作,将其抽象为一个成员函数不是正好吗?假如该操作在X、Y中没有统一的规范,那可以把它们看作完全不相干的两件事,不是吗?

    • #1368
      Lumj
      Member

      可是我想操作以成员函数的方式存在并不总是令人满意的吧,比如,如果不考虑多态的问题,在写一个类的时候,有时就会选择把有些’操作’写成普通的函数

      “这个操作的逻辑是使用A对象的上下文的逻辑,A对其的知情根本就没有意义”

      是指,比如,有个Complex class,现在使用者希望把Complex对象存入文件,而Complex的开发者并没有直接提供这些,因为他认为Complex还需要去了解FileStream太奇怪了(Complex.ToFile(FileStream)),Complex应该只完成它的份内事,构造,计算,等等.ToFile不是带来了不必要的耦合吗?

      在Complex类外写一个(不论是Complex的开发者还是使用者)ToFile不是更合理吗?(ToFile(FileStream,Complex))这样Complex和File就完全无关了(开发Complex的人完全不需要了解FileStream)

    • #1369
      hui
      Keymaster

      原来你说的是这个意思。没错,这种情况用自由函数(free function)(即你所说的普通函数)肯定是更好,但不是所有的OOP语言都支持的(比如Java、C#)。如果是你所说的情况,哪怕不涉及多态问题,这类操作也应作为自由函数或者某个utility类的静态方法。

      至于如何解决你提到的多态问题,《冒号课堂》430-434页其实已经给出了一个答案:在语法不支持多分派(multiple dispatch)的OOP语言中,可以采用visitor模式,既可避免不必要的耦合,又可避免类型判断。

    • #1370
      Lumj
      Member

      嗯,对,我就是觉得这带来了额外的限制,而且,这意味着语言特性设计的不正交吧

Viewing 4 reply threads
  • You must be logged in to reply to this topic.
 请您评分1星(很差)2星(不行)3星(一般)4星(不错)5星(很棒)