: tinlans 说的没有错，物件导向并不是要我们做无意义的继承，但是物件导向也没有 : 说一定要套封装、继承、多型。 : 光就「物件导向」这四个字的意义只是以「物件」为基础来模拟 (Model) 真实世界的 : 东西，所以物件导向的分析第一步就是找出有哪些「物件」要被建立，尽管这个例子 : 简单到物件少到只有两三种：河内塔、盘子、或者柱子，但是这个问题是做练习还是 : 无意义什麽的我不管，在这边就是讨论如何以「物件」的角度来设计这样的一个软体。 基本上最古典的 OOP 定义就是指封装、继承、多型， 而仅有封装这类， 一般被称为 Object-based Programming 或 ADT programming， 它的设计精神与 OOP 差别就在於继承和多型， 实际上它们的目的也有所不同； 以这个题目为例子， OOP 可以说是几乎派不上用场， 事实上它也没有必要派上用场， 套 ADT 就可以搞定， 甚至传统的 procedural 就很足够了； 这些状况也是为什麽某语言很坚持支援 multi-paradigm， 而不要变成一个纯 OOPL 的原因之一。 以最後写出的程式来看， 如果不含继承与多型， 我们只能说它是「以物件为基础」设计而成的， 也就是 object-based 或 ADT。 : 在找出所有要被建立的「物件」之後，下一步就是找出每个物件之间的关系。当您了解 : 每个物件之间如何交流互动之後，才有办法决定「物件」拥有哪些「成员」，而这些「 : 成员」也就是所谓的「属性」和「方法」，尽管这个例子简单到有些物件可能连一个「 : 方法」都没有，但是河内塔摆明了就是在做练习而已，我尽可能地描述「物件导向」的 : 精神在哪边，它是以何种思维来开发软体的，如此而已。 这段做法事实上在 ADT 的年代就存在了， 只是大部分的教科书故意举了 well-known 的东西， 譬如 stack 和 queue 之类的， 它们的定义已众所皆知， 所以教科书直接将它们的定义当作 spec， 然後说明怎样怎样弄就会符合 ADT 的要求； 如果一个人的 knowledge 里面并没有 stack、queue、list 这些东西， 那麽他们找寻一个功能与之相同的物件所拥有的属性和操作， 过程其实就是这样子的， 而为它们设置一个名词以及详列规格 (也就是定义) 则是後来的事。 : 话说回来，河内塔问题用一个函式 (function) 就可以解决，它的复杂度低到不适合用 : 物件导向来模拟 (Model) 每个物件，它的所有变化也只有柱子的数目和盘子的数目，这 : 两个变数的改变并不会使河内塔的问题用物件导向就比较好解决，所以真正要解决河内 : 塔问题的话，还是建议写成一个函式就足够了！ 所以我觉得， 如果出这题目的是老师， 这位老师可能并不是一位很理想的教师， 如果是自己给自己练习的， 那麽建议是换个题目比较好； 物件导向的用意是程式码再利用、应付多变的需求等等， 并不适合用在这种 case。 -- Ling-hua Tseng ([email protected]) Department of Computer Science, National Tsing-Hua University Interesting: C++, Compiler, PL/PD, OS, VM, Large-scale software design Researching: Software pipelining for VLIW architectures Homepage: https://it.muds.net/~uranus --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 61.230.221.133 ※ 编辑: tinlans 来自: 61.230.221.133 (04/08 02:12)