OOP在大学里被滥用了吗？[英] Is OOP abused in universities?

问题描述

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.

推荐答案

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.

"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!

其他推荐答案

OOP is a real world computer concept that the university would be derelict to leave out of the curriculum. When you apply for jobs, you will be expected to be conversant in it.

That being said, pace jalf, OOP was primarily designed as a way to manage complexity. University projects written by one or two students on homework time are not a realistic setting for large projects like this, so the examples feel (and are) toy examples.

Also, it is important to realize that not everyone really sees OOP the same way. Some see it about encapsulation, and make huge classes that are very complex, but hide their state from any outside caller. Others want to make sure that a given object is only responsible for doing one thing and make a lot of small classes. Some seek an object model that closely mirrors real world abstractions that the program is trying to relate to, others see the object model as about how to organize the technical architecture of the problem, rather than the real world business model. There is no one true way with OOP, but at its core it was introduced as a way of managing complexity and keeping larger programs more maintainable over time.

其他推荐答案

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 law of leaky abstractions 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...