EEPW论坛

从前C语言的出现大大地推动了结构化编程思想，函数式的体系将许多需求转化为数学问题，本人深感其伟大，也亲密接触了“电子猪脑”的奇妙。但随着软件工程和软件需求的极速发展，猪脑面对很多事情渐显无耐，而计算机也慢慢有了一定的自主性，不再是个只能听命程序员的猪脑。由此从“怎么做”到“做什么”的转变也促成结构化到对象化的前进。程序中主要有变量、常量和函数，而面向对象则全部凝结到了类和对象，其它的都是细节可以暂时忽略甚至让电脑自己处理。伴随面向对象的是UML等一系列的配套技术和理论，这巨大的提升了软件的生产效率，程序和语言表现出了前所未有的智慧，而我们开发者们反而开始沦为“瓶颈”。 　　我眼见很多同仁们大喊OO但却编程及设计是努力地重用各种函数，更有高手画着一手漂亮的UML图，但代码中仍在为一些方法设定无数的参数，并给出使用此函数的参数组合的全面说明。另有一些人认为C等一些技术已经是古董级的文物，那是与面向对象不相容的，可实际上当前的很多OO语言平台都是用C写的。所以我认为对象不只是口号、标准、方式或手段，而是一种理念，你看他明白了! 　　现在说点实际的，面向对象的精华是类和对象，并由此派生出属性、方法、继承、多态、组合、接口等等不尽的概念，其实所有这些不过都是想让“猪脑”能趋向智能来节省我们的一些简单重复工作。软件是为了解决特写的实际问题，这些是在社会生活中存在的并可能在从前是由人工来完成，我们写软件来教电脑怎么做。以前的结构化是把计算机看成一头猪，并要告诉它先怎么做，再怎么做，如果遇到什么就怎么做，通常只有由一个人来训练。但面向对象认为一项工作就由多头猪完成，这样我们先确定一些猪，然后分别训练每头猪相互认识并进行合作，如果你是高级人员则可以让程序员去训练每只猪。 　　由些看来，类说是一种猪，它有一定的特点并且会做一些工作，而对象则就是一只活生生的猪。所有具体细致编码工作全浓缩到了猪的内部，因而重用性、鲁棒性、扩展性等自然会相当好。依据这样的逻辑那将一种猪再配以其它的特性和技能就是所谓的继承了，比如给瘦肉型的猪配以警服再教它如何咬人就出现了传说中美国的 “警猪”，当然这其中能减少许多相当的工作。现在我们再进一步让一群猪合作进行表演并让其作为一团队，此即专业上所谓的组合了，这时它们是以前的一只 “猪”，也不是单纯的“合”，而是受各模式理论推崇且时下流行的“猪合”，常被 认为是优于继承的。 有这么一种猪的泛指，它不会有成一个实际的猪也是就不能实例化，抽象类是一定要被继承的。例如“肥猪”就是抽象的，但我们可以以此定义各种各样的具体化的肥猪。有时我需要猪有一些技能细节不要被定死，而是让其它用它的来定，就是要有一种接口。比方说，猪是要吃过才睡的，但吃什么、什么时候吃不能确定，那就留个接口让不同程序员去定。有人一定会说猪还会繁衍，的确我们的电子猪目前只会克隆，长得壮的和吃得少的猪会生下什么宝宝很难说，况且还要考虑性别，也许就因此而很多OO语言不支持多重继承。 　　综合上面的歪理，看来作个真正的IT养猪专业人事还是有些麻烦的。但有几点是能够肯定的，我们首先要知道我们要做什么，然后要确定需要有哪些较小的工作，接着对各工作再分析直到较为独立，最后才是完成特定的每个小部分。这是大的方面和流程。千万不要过多沉沉溺于地具体的技巧，否则你永远只是个饲养员要面对痛苦的代码。软件工程没有固定的对错和明确答案，只要能完成既定的要求，我们的目标是“让猪工作的尽量简单些，让猪干的尽量多一些”