是否值得将我的函数式 JavaScript 代码转换为面向对象的设计？
我目前正在构建一个小型 Web 应用程序，其中包含大量 JavaScript。 当我对最初的想法进行原型设计时，我只是将一些函数组合在一起，以演示应用程序最终的行为方式，并打算以面向对象的方式重新编写 JavaScript。
现在我正进入实现阶段，我发现为了面向对象而创建面向对象的 JavaScript 似乎有点过分了——该项目将来不太可能需要任何重大修改，而这将保证和面向对象的设计。 相反，我发现一组简洁、内聚的功能运行良好。
那么，话虽如此，并试图遵守 KISS 原则，当一组函数为问题提供合适的解决方案时，是否还有其他原因值得考虑将我的代码转换为面向对象的设计？
I'm currently building a small web application that includes a fair amount of JavaScript. When I was prototyping the initial idea, I just hacked together a few functions to demonstrate how the application would eventually behave intending to go forward re-writing the JavaScript in an object-oriented nature.
Now that I'm getting into the implementation phase, I'm finding that creating object-oriented JavaScript for the sake of being object-oriented seems overkill - the project isn't likely to require any major modifications in the future that would warrant and object-oriented design. Instead, I'm finding that a set of concise, cohesive functions are working well.
So, with that said and with attempting to adhere to the KISS principle, when a set of functions are providing a suitable solution to a problem, are there any other reasons worth considering to convert my code into an object-oriented design?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
不，虽然我个人觉得 OOP 更美味，但它只是达到目的的一种手段，而不是目的本身。 在很多情况下，过程式编程比 OOP 更有意义，为了转换而转换，正如您所说，可能是矫枉过正。
No, although I personally find OOP more tasty, it is a means to an end, and not an end in itself. There are many cases where procedural programming makes more sense than OOP, an converting for the sake of converting, could be, as you said, overkill.
不，顺其自然，继续前进——我认为这样更有成效。
No, let it be and move forward - that is more productive in my view .
如果您的代码结构良好、布局良好、注释良好，并且完成了所需的工作，那么出于添加功能以外的任何原因对其进行修改都是不明智的。
虽然可以说该程序很好地面向对象编程等，但如果不需要更改它即可工作，那么我肯定会保持原样。
如果它没有坏，请不要摆弄它:)
If your code is well structured, well laid out, and well commented, and does the job that is required of it, then messing with it for any reason other then to add features is ill-advised.
While it might be nice to say that the program is nicely OOP etc, if it doesn't need to be changed to work then I would definetely leave it as it is.
If it aint broke, dont fidgit with it :)
如果此代码已经实现并且不需要维护或（更好的是）升级，请坚持使用。 如果您现在要实现它并且它可能会变得复杂，请考虑面向对象的方法。
经验告诉我，编写和维护过程性代码非常容易，同时复杂性较低，但是在达到一定阈值之后，在使用过程性编程时开始变得指数级地增加复杂性，而 OOP 虽然开始更难，但复杂性要高得多易于管理。
底线：如果任务足够简单或已经实施，请保持简单。 如果它可能变得更复杂，请考虑 OOP。
If this code is already implemented and won't require maintenance or - better yet - upgrades, stick with it. If you are going to implement it now and it could get complex, consider the OO approach.
Experience has shown me that it's pretty easy to write and maintain procedural code while complexity is low, but after a certain threshold it starts getting exponentially more difficult to increase complexity while using procedural programming, whereas OOP, although harder to begin, keeps complexity much more manageable.
Bottom line: if the task is simple enough or has already been implemented, keep it simple. If it might grow more complex, consider OOP.
我想说，在做出决定之前，仍然值得检查您的代码。 “重写”代码的明显缺点是需要测试成本来确保代码与以前一样工作。 你们有单元测试吗？ 如果没有，那么您的测试成本会更高。 因此，总的来说，我反对重写工作代码，除非它有另一个目的，即让您更轻松地编写现在需要的新功能（即重构常见功能等），
但是，任何时候有人说“我一起黑客攻击”，我建议您的代码总是值得再看一遍。 为什么它首先被黑客攻击在一起？ 我知道很多人说面向对象代码本身并不是目的，但它是一种以后也不必考虑的方法。 你会很自然地开始这样做。
也许你的js比较简单，因此OO脚手架确实是额外的开销。 美好的。 但我仍然建议您始终对您称为“黑客”的任何代码进行代码审查（尤其是让其他人审查）。 也许这是弗洛伊德式的失误……但它确实失误了。
I would say that it is still worth reviewing your code before making a decision. The obvious downside to "re-writing" code is that there is a testing cost to ensure that your code works the same as before. Do you have any Unit tests? If not, then your testing cost is even higher. So in general, I'm against re-writing working code unless it serves another end, which is to allow you to more easily write new functionality that is now required (i.e. refactoring common functions, etc.)
HOWEVER, any time a person says "I hacked together", I suggest it is always worth a second look at your code. Why was it hacked together in the first place? I know plenty of people say that Object Oriented code isn't an end in and of itself, but it is a methodology that after while doesn't have to be thought about either. You just sort of naturally start doing it.
Maybe your js is relatively simple, and therefore OO scafolding is truly extra overhead. Fine. But I still suggest that you should always code review (and especially have someone else review) any code you call "hacked". Perhaps it was a Freudian slip... but it did slip.
从现在开始将其视为遗留代码。 当您想要更改某些内容时，请对其进行重构，以便代码变得更容易理解。 如果您需要一点 OOP，请使用它。 如果你不这样做，就不要这样做。
OOP是一把锤子，请不要把螺丝问题当成钉子。
Treat it as legacy code from now on. When you want to change something, refactor it so the code becomes easier on the mind. If you need a bit of OOP, use it. If you don't, don't.
OOP is a hammer, please don't treat a screw-problem as a nail.
如果它有效，并且易于维护，我就不会为了转换而转换它。 一定还有更多有趣的事情要做。
If it works, and it's easy to maintain, I wouldn't bother converting it for convertings sake. There must be more interesting things to do.
请记住，在 javascript 中创建对象是相当昂贵的。
将物体的构造保持在最低限度。
Just bare in mind Objects are rather expensive to create in javascript.
Keep construction of objects to a bare minimum.