程序代码与OOP代码

19

我已经用程序样式完成了一个PHP的13000+行的项目[因为我对此非常熟悉，尽管我知道OOP]，并且该项目运行得很好。

但是我应该将其转换为OOP吗？[ 因为世界上正忙着OOP ]

我的代码不需要OOP的任何功能[封装，基本上是继承...]！

所以我该怎么做？

如果将其转换为OOP，将会获得什么样的帮助？

programming-languages programming-practices

— 苏拉夫
source

21

如果您必须更改此项目，请及时通知我们。知道您是高兴还是做出这个决定还是后悔，这将是很有趣的。

— JeffO

2

您需要封装。OO是获得它的一种方法。也许您有另一种适合您的方法，但是您需要一种或多种方式来控制代码依赖性。

— Marcin

关于您的轶事怎么样：几年前，我开发了一个中型Web应用程序，该应用程序主要使用JavaScript编写（不要问）。编码风格主要是程序性的。当项目接近完成时，我发现自己对代码的编写方式不满意，并在OOP-JavaScript中重写了很大一部分代码。这导致了完成项目的延迟，我们后来在项目上进行的维护相对较少。我一直想知道所有这些编码是否值得努力；-)

— Pandincus 2011年

是的，值得。保持可重用性的门永远值得。

— Chani

1

问题是：您期望进一步发展吗？当您完全知道自己需要什么并且不会改变时，过程编程是最简单，最快的方法。程序代码的任何更改都会很痛苦，在OOP中会容易得多。

— 卡米尔·汤姆斯克（KamilTomšík）2011年

52

我的代码不需要任何OOP功能

您已经回答了自己的问题-如果在这种情况下不需要OOP 并且您的项目正在运行，请不要进行转换。

但是，您应该考虑将OOP用于下一个项目-但前提是适当的时候。

只要在适当的地方使用程序，程序编程就没有本质上的错误。

— ChrisF
source

2

+1同意“您应该考虑将OOP用于下一个项目”。

— Cary Chow

11

+1是，如果它可以正常工作，请不要修复它。

— setzamora 2011年

4

我要说的是，如果它现在可以正常工作，请不要更改它，但是您永远不会知道下一个功能请求是什么。

— JeffO 2011年

7

“您应该考虑将OOP用于下一个项目”，但是除非有道理，否则不要使用它。有些事情在程序上写得更好，有些更适合OOP。使用适当的任何东西。

— TMN

@TMN-这是隐含的-我应该明确指出。

— 克里斯·

16

不，不仅仅是因为您不需要OOP。

如果您的程序已经完成并且可以令人满意地工作，那么在90％以上的时间中，无论出于何种原因，都要浪费时间重写完成的代码。

OOP并非功能强大，在很多地方都不应该使用OOP，所以不要仅仅使用OOP，因为OOP是趋势。

— 斯凯思
source

1

“完成代码”是指它有效吗？

— JeffO 2011年

@eff O是的，先生！非常完美：)

— Sourav

他说他已经完成了该项目，并且运行良好。对我来说，这意味着它已经准备好交付给客户，或者假设已经交付给客户。所谓完成，是指经过测试并准备发货，当然，如果出现重大错误，则可能需要重写。

— Skeith

请详细说明“不应使用OOP的许多地方”。

— 猎鹰

3

@Falcon，无论您的OOP代码设计得如何好，但是，如果问题域本身无法很好地映射到OO模型，则您的OOP设计势必会变得糟糕。存在很多问题域，绝不能用OOP表示。

— SK-logic

8

我对范式的一般理解（以及为什么三个主要范式都不是正确的编程方式还是错误的编程方式）：

当您遇到一个在较高层次上很简单的问题（尽管在较低层次上可能很复杂）并且想要编写相应的简单线性代码时，过程编程非常有用。如果不需要在任何地方进行强大的去耦，则可以说比OO和功能更容易编写和理解。示例：一旦使用OO或函数分解了内容，数字代码，大多数小笔录，大多数小子问题。

当您需要强烈分离关注点时，面向对象的代码是很好的选择，因为您可能有多个关注点的实现。示例：大多数大型商业软件。例如，您可能希望将业务逻辑与表示逻辑强烈分离，因为它们可能需要独立更改。

当您需要将机制与策略强烈分离时，函数式编程非常有用。具有接受策略功能的机制功能是一个很好的模式。（我通过查看D编程语言的std.algorithm模块了解了这一点。）在策略和机制代码之间的边界上抽象出可变状态通常会使API易于推理。如果可变状态在任何一个中私下使用，则这是一个实现细节。出于不言而喻的原因，函数式编程的另一个优势是并发性。

— dsimcha
source

感谢您对描述每种类型的编程范例并提供何时/如何使用它们的示例的出色回答。

— 凯文·佩诺

7

代码从不“需要OOP”。正是程序员以他们能够以不同的方式思考的方式，预见到这个或那个特定问题“需要” $ PARADIGM或以这种方式最好地解决。

通常，仅了解一种范例的程序员认为他们的范例是最伟大的。一种尺寸适合所有人，并且无论当前是否流行，我们都必须睡在Procrustes的床上。

— 印吾
source

5

仅当有明确指示需要OOP时，才应将项目转换为OOP。可能发生这种情况的可能性是（其他）：

扩大项目
为团队增加更多开发人员

即使在这些情况下，也仍然没有必要将您的项目转换为OOP。

— 蒂莫西·格罗特（Timothy Groote）
source

很好，但是您能告诉我，如果是程序代码，为什么扩大项目规模或在团队中增加更多开发人员会造成问题？

— Sourav

扩大项目规模可能需要向应用程序模型中添加复杂的关系结构，在这种情况下，切换到OOP可能会有利可图。如果应用程序一点一点地扩展，并且从长远来看会更容易在OOP中实现或理解，那么如果代码是OOP，新开发人员可能会更快地“赶上”。当项目变得更大时，留下非OO代码的遗留物可能会成为问题。其中的另一种情况是“事物之所以如此，是因为事物以这种方式获得”

— Timothy Groote

3

这正是我阅读问题时想到的。他说他已经写了13K行代码。我希望它不会因为只使用一次而浪费。如果必须重新使用它，oop将成为必须。否则，这将成为新开发人员的噩梦

— Chani

4

两者都可以是好的，两者都可以是坏的。但是，改型为其他外观绝不是一个好主意。

— 温廷
source

2

如果您回想一下为什么发明OO的原因，您会发现根本不需要 OOP，但是有时它会使您的生活变得更加轻松。

早在C编码的年代，一个非常大的程序可能变得非常凌乱，并且很难继续使用。因此，他们发明了将其拆分为模块块的方法。OOP采用这种方法并使它更加模块化，将数据与程序逻辑的这些块一起放置，从而使它们与其余代码更加分离。

这样一来，您就可以编写越来越大的程序，并且可以确保将一个庞大的任务变成了一百个鼠标大小的任务。额外的好处是您可以使用其中的一些“老鼠”，并将其在其他程序中重复使用！

当然，现实世界并非如此，对象重用从未像预期的那样流行，但这并不意味着它是一种无用的范例。

没有用的是过分依赖两种编码方式。用一千个很小的，无关紧要的类进行OO的人并没有真正做到这一点-他们正在为自己（或其他人）做维护的噩梦。任何编写只有三个功能的程序应用程序的人也会使生活变得艰难。最好的方法是在中等地面的大型对象（有时称为组件，这是我们曾经想去过的地方），它可以提供大量独立代码和数据，并且很有可能被重用与您的应用程序其余部分隔离。

下次我的建议是：尝试编写常规的过程代码，但创建主数据结构的单个对象。看看如何使用它比在函数之间传递数据要容易得多。

— gbjbaanb
source

0

我的代码不需要OOP的任何功能[封装，基本上是继承...]！

你怎么知道？

您需要维护这个项目吗？有没有计划中的新功能？会有其他人与您一起发展吗？你重复了吗？代码难于掌握吗？

如果答案是“是”，那么也许您应该开始考虑设置OOP框架并采用这种方式。

— 维胡斯
source