不管是不是OO,写程式都该保有通用性,循「以较少做最多」的原则. 有一些功能是当需要时执行,另一些却是当物件存在就要执行. 大家支持神物的理由是:拜托不要把物件装得太中规中矩. 反对神物的理由就是:不要让一件东西包山包海. 我想神物所犯的问题就是让一件通用的物件变得太具有特殊性. 若有人写一个物件在建构时同时做了A功能与B功能, 别人用此物件就必须做「建构 - 挡A功能 - 挡B功能 - 呼叫物件另外存在的C功能」 才能单纯使用物件的C功能. 此例,对原case是做了最少,对其他人却要做更多. 神物也让沟通变得麻烦,因为只有作者知道此物件建构时同时会做A功能与B功能, 却让其他人感到疑惑,如果不知道物件建构子的副作用,反而遇到所谓难以维护与了解 的程式码. 想要神物,多弄个带参数的神物建构子不很麻烦,且满足通用与特殊二方面的需求. 仅保留之前引文;没有反对哪一位. ※ 引述《H45 (!H45)》之铭言： : ※ 引述《greatroy (雪碧猪)》之铭言： : : OOP应该是帮助我们建构系统的一种手段, : : 而不应是为了OO而OO才是, : : 能写出高深精简的程式码固然是件好事, : : 但已经看过太多为了突显技术, : : 而写出一堆往後连自己都难以了解及维护的程式码, : : 这样似乎有些本末倒置, 不是吗? : : 另外, OO的另一个目的就是让Team work更加顺畅, : : 没人能维护的程式码, 对Team而言, : : 不过是一团垃圾. : 一个好的程式码，固然着重於容易阅读与容易修改 : 自己写出来的程式码，不只要让未来的自己看得懂，也要让别人也看得懂 : 撰写完整的注解以及说明文件是其中一个解决办法 : 但是物件导向分析与设计的主要目标仍然是为了满足使用者的需求 : 所有的分析以及设计都是源於需求而发展出来的 : 以物件导向做这些事情，与过去的功能导向呈现明显的对比 : 功能导向是把整个需求看成是一条一条的功能 : 做出了所有的功能就等於满足了所有的需求 : 物件导向是把整个需求看成是一个一个的物件 : 做出了所有的物件就等於满足了所有的需求 : 而物件导向优於功能导向的原因是物件比较容易被模型化、比较容易被人类理解 : 以此概念衍生出来的 UML, 帮助程式设计师建立软体模型 : 在实作之前就先设计好软体蓝图，可以让程式发展得更顺畅 : 比起功能导向的设计方式，物件导向似乎更适合塑模呢！ --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 59.112.227.69