OOP思维与设计

OOP——面向对象的编程. OOP思维是指面向对象本身的思想. OOP设计并不意味着所有代码都封装在类别中. 因为，如果这样的话，它仅指面向对象的编程.

OOP——面向对象编程只是一种实践. OOP思维是基础. 重要的不是实践，而是实际要实现的目标.

JAVA语言始终可以实现大多数面向对象的目标. 原因很简单. 那是因为语言本身的局限性.

JAVA中的所有内容都必须在课堂上. 类之外不允许有单独的函数. 由于产生了JAVA，因此设计模式是独特的. 从这一点来看，JAVA改变了软件世界的思维.

OOP的目标是使代码符合SOLID原则. 这些原理将在解释设计模式的所有作品的开头介绍.

但这是一个理论目标. 实际目标是回答我们为什么这样做. 因为，我们永远对未来一无所知. 我们不知道需求会发生什么. 今天我们也许只能在有限的时间内提供一个简单的版本. 但是它肯定会在将来扩展. 我们所做的可能已经涵盖了今天的所有内容，但是有一天我们会发现仍然有一个未被考虑的组件.

如果没有面向对象，那么我们已经完成了最简单的开关案例结构. 因此，我们必须修改我们的核心代码. 但是，如果我们的代码符合SOLID原则，那么我们要做的就是在现有代码中添加新的CLASS.

不难发现: 插件思想源自OOP. 好吧，如果我们现在看一下OOP，不仅是将分散的代码封装到类中的问题.

我们需要遵循SOLOD原则，并明确什么是抽象的，什么是具体的. 尽管我们仅针对特定问题提供有限的代码，但它们都取决于总体抽象. 如果存在同一类的新的特定问题，我们只需要添加类. 这是设计模式思考的核心.

OOP设计远非如此. 代码的可读性和可维护性还在于对文档进行分类. 从表面上看，这些都不是重要的细节. 但是现实非常重要. 特别是对于设计核心模块的某个问题，或设计一个PHP开发框架. 目录的可读性或是否符合OOP，在很大程度上决定了人们对其理解的速度以及接受该目录的意愿程度. 例如，SYSMFONY的目录结构不是很好. 尽管它是老式的oop设计，但早期却占领了更大的市场. 但是，市场仍被一些新框架所分割. 回想起来，这些代码的设计不是很好，例如KOHANA，CI很容易被接受，并且还与其目录结构有关. 这就是为什么一些国内框架可以被用户接受的原因. 它不是单个的，因为它是中文.

可以看出，OOP设计的思想不仅在于代码，还在于体系结构和设计.

Php框架的大多数问题是由于以下事实造成的: 开放源代码系统没有经验丰富的人员，这些人员曾作为架构师经历过大型项目. 这是完全合理的. 但是，如果一个企业是开源的，而且经过多年的经营，越做越大的系统，更复杂的是oop设计，这是可悲的不能够有一个明确的架构，易于上手，易于维护.

有人说，这些公司可以利用它为需要二次开发的客户赚钱. 实际上，挣这样的钱总是很有限的. 因为，好的核心架构将带来真正的软件产业化. 它将节省大量成本.

实际上，说回来，开发框架实际上非常简单. 它非常简单，可以用一两个句子来概括: 一个是为用户提供不同的库供用户调用，从而使用户可以编写更少的代码. 第二个是允许用户轻松添加所需的插件以减少用户开发. 这实际上是一个相互调用的系统. 在MVC系统中，纯OOP框架，后者是框架称为用户的代码. 在这方面，最突出的是用户界面组件. PHP在此类中有很多框架. 但是它们都很基础. 没有人可以与JAVA中的FCS或TYPESTRY进行比较. 甚至有些初学者也可以发布小于200KB的标签引擎. 如果不看代码，您可以想象永远不会有设计模式，并且不可能遵循SOLID原则. 好吧，扩展和维护将是一个相当大的问题.

所以我们想到了多少家互联网公司，他们的网站是PHP，从表面上看，PHP似乎可以降低成本，但是多少呢？关键仍然是从OOP代码到OOP体系结构，OOP体系结构的级别决定了技术部门开发的效率和成本.

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-242528-1.html