blocks|key|877420|text|当您的数据可以很好地结构化为对象时，OOP是正确的方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|877421|例如，对于正在处理来自传感器的字节流的嵌入式设备，可能没有什么可以明确地进行对象化。|877422|同样，在对性能的绝对控制至关重要的情况下(当每个周期都很重要时)，OOP方法可能会引入计算成本，这可能是非常重要的。|877423|在现实世界中，通常情况下，您的问题可以很好地用对象来描述，尽管不能忘记漏抽象定律！|offset|length|877424|工业界通常最终会决定，在大多数情况下，使用合适的工具来完成这项工作，而且在许多地方都可以看到OOP。高性能和低级别通常会有例外情况.当然，没有硬性规定。|877425|如果你坚持的时间够长的话，你可以把螺丝钉进去.|877426|entityMap|0|LINK|mutability|MUTABLE|url|http://www.joelonsoftware.com/articles/LeakyAbstractions.html^0|0|0|0|Z|5|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@$H|Z|I|10|1|11]]|A|$]]|$1|J|3|K|5|6|7|12|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|13|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]]]

OOP is the right approach when your data can be well structured into objects.

For instance, for an embedded device that's processing an incoming stream of bytes from a sensor, there might not be much that can be clearly objectified.

Also in cases where ABSOLUTE control over performance is critical (when every cycle counts), an OOP approach can introduce costs that might be nontrivial to compute.

In the real world, most often, your problem can be VERY well described in terms of objects, although the <a href="http://www.joelonsoftware.com/articles/LeakyAbstractions.html" rel="nofollow noreferrer">law of leaky abstractions</a> must not be forgotten!

Industry generally resolves, eventually, for the most part, to using the right tool for the job, and you can see OOP in many many places. Exceptions are often made for high-performance and low-level. Of course, there are no hard and fast rules.

You can hammer in a screw if you stick at it long enough...

blocks|key|2403319|text|No...OOP并不总是最好的方法。|type|ordered-list-item|depth|inlineStyleRanges|entityRanges|data|2403320|OOP设计是最好的方法，当您的问题可以最好地建模为一组对象时，这些对象可以通过相互通信/使用来完成您的目标。|2403321|好的question...but+--我猜科学/分析应用程序--可能是最好的例子。他们的大部分问题最好是通过函数式编程来解决，而不是面向对象的编程。|2403322|...that说，让火焰开始吧。我肯定是有洞的，我很想知道原因。|unstyled|2403323|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|M|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|N|8|@]|9|@]|A|$]]|$1|I|3|-4|5|H|7|O|8|@]|9|@]|A|$]]]|J|$]]

<ol>
<li>No...OOP is not always the best approach.</li>
<li>(A true) OOP design is the best approach when your problem can best be modeled as a set of objects that can accomplish your goals by communicating/using one another.</li>
<li>Good question...but I'm guessing Scientific/Analytic applications are probably the best example. The majority of their problems can best be approached by functional programming rather than object oriented programming.</li>
</ol>

...that being said, let the flaming begin. I'm sure there are holes and I'd love to learn why.

blocks|key|2403346|text|OOP通常是一种很好的方法，但它确实有一定的开销，至少是概念性的。例如，我不为小程序做OO。然而，这是你真正需要学习的东西，所以我可以看到，在大学的小项目中需要它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2403347|如果我必须做严肃的计划，我将使用OOP。如果不是，我就不会。|2403348|这是我一直在做的问题的类别(包括建模、几个游戏和一些随机的事情)。其他领域可能不一样，但我对它们没有经验。|2403349|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

OOP is usually an excellent approach, but it does come with a certain amount of overhead, at least conceptual. I don't do OO for small programs, for example. However, it's something you really do need to learn, so I can see requiring it for small programs in a University setting.

If I have to do serious planning, I'm going to use OOP. If not, I won't.

This is for the classes of problems I've been doing (which includes modeling, a few games, and a few random things). It may be different for other fields, but I don't have experience with them.

blocks|key|970212|text|在向系统添加新功能或维护/改进系统时，我看到了使用OOP的一些最佳结果。不幸的是，在上大学的时候获得这样的经历并不容易。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|970213|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I've seen some of the best results of using OOP when adding new functionality to a system or maintaining/improving a system. Unfortunately, it's not easy to get that kind of experience while attending a university.

blocks|key|969631|text|OOP总是正确的方法吗？|type|blockquote|depth|inlineStyleRanges|entityRanges|data|969632|不是的。|unstyled|969633|什么时候OOP是最好的方法？|969634|当它帮助你的时候。|969635|什么时候OOP是个糟糕的方法？|969636|当它阻碍你的时候。|969637|这确实是非常具体的。有时您不需要OOP，有时它在您所使用的语言中是不可用的，有时它真的没有什么区别。|969638|不过，我要说的是，在技术和最佳实践方面，你的教授对你说的话还是要重复一遍。仅仅因为他们是老师并不意味着他们是专家。|969639|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$]]|$1|E|3|F|5|6|7|U|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|V|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|W|8|@]|9|@]|A|$]]|$1|K|3|L|5|D|7|X|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|Y|8|@]|9|@]|A|$]]|$1|O|3|P|5|D|7|Z|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|D|7|10|8|@]|9|@]|A|$]]]|R|$]]

<blockquote>
 Is OOP the right approach always?
</blockquote>

Nope.

<blockquote>
 When OOP is the best approach?
</blockquote>

When it helps you.

<blockquote>
 When OOP is a bad approach?
</blockquote>

When it impedes you.

That's really as specific as it gets. Sometimes you don't need OOP, sometimes it's not available in the language you're using, sometimes it really doesn't make a difference.

I will say this though, when it comes to technique and best practices continue to double check what your professors tell you. Just because they're teachers doesn't mean they're experts.

blocks|key|877597|text|教授们的缺点是，他们不能让你使用那些持续了多年的、由许多不同程序员负责的庞大的、令人讨厌的程序。他们必须使用相当不令人信服的玩具例子，并试图诱使你看到更大的前景。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|877598|本质上，他们不得不吓唬你，让你相信，当一辆HO轨距模型列车撞到你时，它会把你的腿撕掉。只有最有说服力的教授才能做到这一点。|877599|“如果解决方案与项目进展良好，我认为这个方案也应该适用于该项目的宏版本。”|877600|这就是我不同意的地方。一个小项目适合你的大脑。它的大版本可能不会。对我来说，OO的好处是隐藏了足够的细节，这样我的脑海中仍然可以有更大的图景。如果您缺少OO，您仍然可以管理，但这意味着要找到其他方法来隐藏复杂性。|877601|关注真正的目标--生成可靠的代码。OO在大型程序中运行良好，因为它帮助您管理复杂性。它还可以帮助重用。|877602|但目标不是目标。好的代码是目标。如果程序方法有效，而且永远不会变得复杂，那么你就赢了！|877603|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

The professors have the disadvantage that they can't put you on huge, nasty programs that go on for years, being worked on by many different programmers. They have to use rather unconvincing toy examples and try to trick you into seeing the bigger picture.

Essentially, they have to scare you into believing that when an HO gauge model train hits you, it'll tear your leg clean off. Only the most convincing profs can do it.

<hr>

"If the solution goes well with the project, I believe it should be the right one also with the macro-version of that project."

That's where I disagree. A small project fits into your brain. The large version of it might not. To me, the benefit of OO is hiding enough of the details so that the big picture can still be crammed into my head. If you lack OO, you can still manage, but it means finding other ways to hide the complexity.

Keep your eye on the real goal--producing reliable code. OO works well in large programs because it helps you manage complexity. It also can aid in reusability.

But OO isn't the goal. Good code is the goal. If a procedural approach works and never gets complex, you win!

blocks|key|969688|text|我的经验是，OOP在小范围内是非常有用的--定义一个具有特定行为的类，它维护了许多不变量。然后，我实际上只是将它作为另一种数据类型用于泛型或函数式编程。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|969689|仅仅根据OOP设计整个应用程序只会导致巨大的类层次结构、意大利面代码，其中所有东西都隐藏在5层间接的后面，甚至最小的、最琐碎的工作单元也需要3秒钟才能执行。|969690|OOP是有用的--当与其他方法相结合时。|969691|但最终，每一个程序都是关于做，而不是关于存在。OOP是关于“存在”的。表示“这是一辆车，这辆车有四个轮子，这辆车是绿色的”。|969692|在您的应用程序中对汽车建模是不有趣的。做模特很有意思*汽车在做些什么。进程是有趣的，简单地说，它们就是您的程序应该围绕的内容。单独的类可以帮助您表达您的流程应该做什么(如果您想要谈论汽车方面的事情，那么拥有一个汽车对象比必须谈论它所组成的所有单独的组件要容易得多，但是您想谈论汽车的唯一原因是它发生了什么事。)用户正在驾驶它，或者出售它，或者你在模拟如果有人用锤子敲它会发生什么)。|969693|所以我更倾向于从功能的角度来思考。当然，这些函数可能对对象进行操作，但这些函数是我的程序所要处理的函数。他们不需要“属于”任何特定的阶级。|969694|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

My experience is that OOP is mostly useful on a small scale - defining a class with certain behavior, and which maintains a number of invariants. Then I essentially just use that as yet another datatype to use with generic or functional programming.

Trying to design an entire application solely in terms of OOP just leads to huge bloated class hierarchies, spaghetti code where everything is hidden behind 5 layers of indirection, and even the smallest, most trivial unit of work ends up taking three seconds to execute.

OOP is useful --- when combined with other approaches.

But ultimately, every program is about doing, not about being. And OOP is about "being". About expressing that "this is a car. The car has 4 wheels. The car is green".

It's not interesting to model a car in your application. It's interesting to model *the car doing stuff. Processes are what's interesting, and in a nutshell, they are what your program should be organized around. Individual classes are there to help you express what your processes should do (if you want to talk about car things, it's easier to have a car object than having to talk about all the individual components it is made up of, but the only reason you want to talk about the car at all is because of what is happening to it. The user is driving it, or selling it, or you are modelling what happens to it if someone hits it with a hammer)

So I prefer to think in terms of functions. Those functions might operate on objects, sure, but the functions are the ones my program is about. And they don't have to "belong" to any particular class.

blocks|key|2403507|text|OOP并不总是最好的方法。然而，在大多数应用程序中，这是最好的方法。|type|ordered-list-item|depth|inlineStyleRanges|entityRanges|data|2403508|OOP是任何系统中最适合对象和对象交互的方法。大多数业务应用程序最好是以面向对象的方式实现。|2403509|OOP对于小型应用程序来说是一种糟糕的方法，在这种情况下，开发对象框架的成本将超过当前的需求。|2403510|学习OOA、OOD和OOP技能对大多数程序员都有好处，所以大学教授OOA、OOD和OOP是非常有用的。|unstyled|2403511|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|M|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|N|8|@]|9|@]|A|$]]|$1|I|3|-4|5|H|7|O|8|@]|9|@]|A|$]]]|J|$]]

<ol>
<li>OOP is not always the best approach. However it is the best approach in the majority of applications.</li>
<li>OOP is the best approach in any system that lend itself to objects and the interaction of objects. Most business applications are best implemented in an object-oriented way.</li>
<li>OOP is a bad approach for small 1 off applications where the cost of developing an framework of objects would exceed the needs of the moment.</li>
</ol>

Learning OOA, OOD &amp; OOP skills will benefit the most programmers, so it is definately useful for Universities to teach it.

blocks|key|2403533|text|标题问一个问题，帖子问另一个问题。你想了解些什么？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2403534|面向对象(+OOP+)是一个主要的范式，它得到了广泛的关注。如果元编程变得庞大，它将得到更多的关注。Java和C#是目前使用最多的两种语言(参见:按使用次数计算的标记)。我认为，无论哪种方式，OOP都是一个伟大/可怕的范例，这是无知的。|2403535|我认为你的问题最好用一句老话来概括：“当锤子是你的工具时，一切看起来都像钉子。”|2403536|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

The title asks one question, and the post asks another. What do you want to know?

OOP is a major paradigm, and it gets major attention. If metaprogramming becomes huge, it will get more attention. Java and C# are two of the most used languages at the moment (see: SO tags by number of uses). I think it's ignorant to state either way that OOP is a great/terrible paradigm. 

I think your question can best be summarized by the old adage: "When the hammer is your tool, everything looks like a nail."

blocks|key|877727|text|把OOP的P看作是原则而不是编程可能是有帮助的。无论您是否将每个领域概念表示为一个对象，主要的OO原则(封装、抽象、多态)对于解决特定问题都非常有用，特别是在软件变得更加复杂的情况下。拥有可维护的代码比在“纯”对象层次结构中表示所有东西更重要。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|877728|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It might be helpful to think of the P of OOP as Principles rather than Programming. Whether or not you represent every domain concept as an object, the main OO principles (encapsulation, abstraction, polymorphism) are all immensely useful at solving particular problems, especially as software gets more complex. It's more important to have maintainable code than to have represented everything in a "pure" object hierarchy.

blocks|key|2403623|text|我的5美分：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2403624|OOP只是更大模式的一个实例:通过将一个大问题分解成更小的问题来处理复杂性。我们软弱的头脑被限制在他们在任何时候都能处理的少数想法上。即使是中等规模的商业应用程序，其移动部件也比大多数人一次能够完全保持完整的精神状态的部分要多。在软件工程中，一些比较成功的设计范例利用了处理复杂性的概念。无论是将架构分解成层、将程序分解为模块、对操作进行功能分解、使用预先构建的组件、利用独立的web服务，还是在问题和解决方案空间中识别对象和类。这些都是驯服复杂的野兽的工具。|2403625|OOP在几类问题中尤其成功。当你能从“事物”和它们之间的相互作用的角度来思考这个问题时，它就会工作得很好。当您处理数据、用户界面或构建通用库时，它工作得很好。这类应用的普及使得OOP变得无处不在。其他类型的问题需要其他或额外的工具。操作系统区分内核和用户空间，并在一定程度上隔离进程以避免复杂性的增加。函数编程保持数据不可变，以避免多线程时出现的依赖网格。您的经典OOP设计也不是，但它们在自己的领域是关键的和成功的。|2403626|在你的职业生涯中，你很可能会面临比你自己能完全解决的更大的问题和系统。你的老师不仅试图给你配备现有的行业工具。他们试图传达的是，当你试图模拟现实世界的问题时，你可以使用一些模式和工具。为工具箱积累一组工具，并为工作选择合适的工具，这是您最感兴趣的。OOP是一个强大的工具，但到目前为止并不是唯一的工具。|2403627|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

My 5 cents:

OOP is just one instance of a larger pattern: dealing with complexity by breaking down a big problem into smaller ones. Our feeble minds are limited to a small number of ideas they can handle at any given time. Even a moderately sized commercial application has more moving parts than most folks can fully maintain a complete mental picture of at a time. Some of the more successful design paradigms in software engineering capitalize on the notion of dealing with complexity. Whether it's breaking your architecture into layers, your program into modules, doing a functional breakdown of actions, using pre-built components, leveraging independent web services, or identifying objects and classes in your problem and solution spaces. Those are all tools for taming the beast that is complexity.

OOP has been particularly successful in several classes of problems. It works well when you can think about the problem in terms of "things" and the interactions between them. It works quite well when you're dealing with data, with user interfaces, or building general purpose libraries. The prevalence of these classes of apps helped make OOP ubiquitous. Other classes of problems call for other or additional tools. Operating systems distinguish kernel and user spaces, and isolate processes in part to avoid the complexity creep. Functional programming keeps data immutable to avoid the mesh of dependencies that occur with multithreading. Neither is your classic OOP design and yet they are crucial and successful in their own domains.

In your career, you are likely to face problems and systems that are larger than you could tackle entirely on your own. Your teacher are not only trying to equip you with the present tools of the trade. They are trying to convey that there are patterns and tools available for you to use when you are attempting to model real world problems. It's in your best interest to accumulate a collection of tools for your toolbox and choose the right tool(s) for the job. OOP is a powerful tool to have, but by far not the only one.

blocks|key|877799|text|OOP的相关性和历史可以追溯到1960年代的Simula语言，它是一种从概念上设计软件的方法，开发的代码既定义了源代码的结构，也定义了与它的一般允许的交互。明显的优点是，一个定义良好和创建良好的对象是自理的，并且始终是可重复的和可靠的；理想情况下，它也能够被扩展和覆盖。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|877800|我只知道OOP是一种“糟糕的方法”，是在嵌入式系统编程过程中，资源可用性受到限制；当然，前提是您的环境允许您访问它们(如前所述)。|877801|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The relevance and history of OOP runs back to the Simula languages back in the 1960s as a way to engineer software conceptually, where the developed code defines both the structure of the source and general permissible interactions with it. Obvious advantages are that a well-defined and well-created object is self-justifying and consistently repeatable as well as reliable; ideally also able to be extended and overridden.

The only time I know of that OOP is a 'bad approach' is during an embedded system programming efforts where resource availability is restricted; of course that's assuming your environment gives you access to them at all (as was already stated).

blocks|key|2403724|text|和大多数这种性质的问题一样，答案是“视情况而定”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2403725|弗雷德里克·P·布鲁克斯说，在"神话中的男人月“中最好的一点是，”没有任何一种策略、技术或技巧能够成倍地提高程序员的生产力。“你不会用一把宽剑来做手术切口，你也不会在剑战中使用手术刀。|offset|length|2403726|OOP有惊人的好处，但是您需要适应这种模式来利用这些好处。了解和理解OOP还允许您为解决方案创建一个更干净的过程实现，这是因为关注点分离的基本概念。|2403727|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/The_Mythical_Man-Month^0|0|G|7|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

Like most questions of this nature, the answer is "it depends."

Frederick P. Brooks said it the best in "<a href="http://en.wikipedia.org/wiki/The_Mythical_Man-Month" rel="nofollow noreferrer">The Mythical Man-Month</a>" that "there is no single strategy, technique or trick that will exponentially raise the productivity of programmers." You wouldn't use a broad sword to make a surgical incision and you wouldn't use a scalpel in a sword fight.

There are amazing benefits to OOP, but you need to be comfortable with the pattern to take advantage of these benefits. Knowing and understanding OOP also allows you to create a cleaner procedural implementation for your solutions because of the underlying concepts of separation of concerns.

blocks|key|2403760|text|我的意见，免费提供，价值不菲.|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2403761|OOD/OOP是一种工具。一个工具的好坏取决于使用它的人，在特定情况下使用它是否合适取决于问题。如果我给你一把锯子，你就会知道怎么砍柴，但你不一定能建房子。|2403762|我注意到的是，函数式编程是未来的潮流，因为它对多线程环境非常友好，所以OO可能在毕业时就过时了。;-)|2403763|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

My opinion, freely offered, worth as much...

OOD/OOP is a tool. How good of a tool depends on the person using it, and how appropriate it is to use in a particular case depends on the problem. If I give you a saw, you'll know how to cut wood, but you won't necessarily be able to build a house.

The buzz that I'm picking up on is that functional programming is the wave of the future because it's extremely friendly to multi-threaded environments, so OO might be obsolete by the time you graduate. ;-)

I started my college two years ago, and since then I keep hearing "design your classes first". I really ask myself sometimes, should my solution to be a bunch of objects in the first place! Some say that you don't see its benefits because your codebase is very small - university projects. The project size excuse just don't go down my throat. If the solution goes well with the project, I believe it should be the right one also with the macro-version of that project.

I am not saying OOP is bad, I just feel it is abused in classrooms where students like me are told day and night that OOP is the right way.

IMHO, the proper answer shouldn't come from a professor, I prefer to hear it from real engineers in the field.

Is OOP the right approach always?

When is OOP the best approach?

When is OOP a bad approach?

This is a very general question. I am not asking for definite answers, just some real design experience from the field.

I don't care about performance. I am asking about design. I know it is engineering in real life.

==================================================================================

Thankful for all contributions. I chose Nosredna answer, because she addressed my questions in general and convinced me that I was wrong about the following :
If the solution goes well with the project, I believe it should be the right one also with the macro-version of that project.

Is OOP abused in universities?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我两年前开始上大学，从那以后我一直听到“先设计课程”。有时候我真的会问自己，我的解决方案应该是一堆对象吗？有人说你看不到它的好处，因为你的代码库是非常小的大学项目。项目规模的借口别逼我。如果解决方案与项目很好，我相信它应该是正确的一个也与该项目的宏观版本。我不是说OOP不好，我只是觉得它在教室里被滥用了，像我这样的学生...

问OOP在大学里被滥用了吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问OOP在大学里被滥用了吗？EN