OOP思想与设计

OOP——面向对象编程。OOP思想，则是指面向对象本身的思想理念。而OOP设计，则并不是指将代码均封装成类就可以了。因为，如果那样，那仅是指面向对象编程。

OOP——面向对象编程，只是一种做法。OOP思想才是根本。重要的不是做法，而是实际要实现的目标。

JAVA语言总是能绝大部分实现面向对象的目标。原因相当简单。那是因为语言本身的限制。

JAVA的一切均需要在类中。不允许类外部的单独的函数。设计模式，即是因为JAVA的产生才有的。从这一点说，JAVA改变了软件世界的思想。

OOP的目标，是要使得代码符合SOLID原则。这些原则，在所有讲解设计模式的著作的开篇均会被介绍。

但这是理论目标。实际的目标，则是要回答，我们为什么要这么做。因为，我们对未来总是未知的。我们不清楚需求会发生什么变化。我们今天或许在有限时间之内只能提供一个简易的版本。但日后肯定要扩展。我们所做的或许在今天已经涵盖了一切，但有一天，我们会发现，还有一个部件，没有被考虑进去。

如果没有面向对象，那么，我们用最简单的switch case结构已经完成了。正因为如此，我们不得不重新修改我们的核心代码。但是，如果我们的代码符合SOLID原则，那么，我们要做的，无非是为现有代码添加一个新的CLASS。

不难发现：插件思想，源于OOP。那么，此时如果我们再看OOP，那不仅是将散乱的代码封装成类的问题了。

我们需要遵循SOLOD原则，明确何为抽象，何为具体。我们虽只提供有限的针对具体问题的代码，但它们全部依赖于整体的抽象。再有同类新的具体问题，我们就是只要添加类。这是设计模式思想的核心。

OOP设计，远非如此。代码可读性，可维护性，还在于目录于文档。表面上，这都不是重要的细节。但实际是极为重要的。特别是针对某一问题的核心模块的设计，或者，设计一个PHP开发框架。目录的可读性，或是否符合OOP，则很大程度上决定了人们对它的理解的速度，以及愿意接受的程度。比如SYSMFONY的目录结构就不是很好。尽管是老牌的，早期占领市场较大。但仍然被一些新的框架所瓜分市场。回过头来，那些代码设计得并不是相当优秀的，比如KOHANA，CI却相当易于被人接受，关于也是与它的目录结构有关。这也是国内一些框架能够被用户接受的原因。并不是单一的因为，它是中文版的。

由此可见，OOP设计的思想，并不只是在代码方面，而是架构，设计的全方位。

Php框架的问题，绝大多数是因为，开源的系统，没有真正经历过超大项目的有足够经验的人作为架构师。这是相当情有可原的。但是，如果一个企业做开源，运作多年后，系统越做越大，则越做越复杂，而不能够有一个明确的易于上手易于维护的架构，则是一种悲哀。

有人说，这些企业可以利用这一点，针对那些需要进行二次开发的客户挣钱。其实，挣这样的钱，永远是有限的。因为，一个好的核心架构，将会带来真正的软件产业化。并且会节省大量成本。

其实，把话说回来，开发框架实际是相当的简单的东西。简单到可以用一两句话来概括：一是提供不同的类库供用户调用，让用户少写代码。二是让用户轻松增加自己需要的插件，减轻用户的开发。这实际上是相互调用的关系统。MVC系统中，纯OOP的框架，后者就是框架调用用户的代码。而这一方面，最为突出的即是用户界面组件。PHP在大量的这一类的框架。但都是非常的初级。没有一个能与JAVA中的FCS，或TYPESTRY相比的。甚致一些初学者还能发布一个200KB不到的标签引擎。代码不用看，就可以想象得出来，绝不会有设计模式，更不可能遵循SOLID原则。那么，扩展，维护都将是相当大的问题。

于是我们想到，有多少互联网企业，他们的网站是PHP的，表面上来看，PHP似乎会降低成本，但能降低到多少？关键还是在于从OOP代码到OOP架构，OOP架构的层次，决定了技术部门开发的效率与成本。