In many other languages like C++ and Javascript, OOP is optional. Procedural code is ok. But in languages like Java and C#, OOP is somewhat enforced. Everything is to be a part of a class or an object. What are the benefits?
Tell me more
×
Programmers Stack Exchange is a question and answer site for
professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
|
closed as not constructive by Jarrod Roberson, Yannis Rizos♦ Jul 11 '12 at 7:22
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.
|
Both C# and Java are marked as languages known not for what they enable, but what they disable, in terms of the feature set they use. (C# less so these days with LINQ but that's a whole different can of worms) Both of these languages are designed such that it's more difficult to create bad designs, at the expense of some freedom to the programmer. Generally speaking, object oriented design produces more reusable and maintainable designs than non object oriented design. (Note: I say "generally" here -- some designs are of course more easily expressed using (for example) functional programming primitives) Therefore, OO is the default paradigm supported in these languages. (Again C# is a bit of an oddball here because it supports functional programming style) |
|||||||||||||||||
|
|
It isn't so much that OOP is enforced, as that an OOP framework is enforced. It's possible to write procedural programs in Java, although it's easier if they're only one file. The advantage is uniformity. There are several different types of functions and data in C++, and this does cause some problems and confusion sometimes, and at the very least is more to learn. With Java, you've got member functions (class or object based) and similar data, and that's it. This is intended to make Java easier to read and write, by specializing the language somewhat. |
|||||||||||||||
|
|
Could be "they thought it was a good idea at the time", i.e. having no free functions. 10-15 years ago the development world was excited by "Object Oriented" (just as they all seem to be excited by "Agile" right now). Even so, I am not sure if every class should derive from Object, but without generics where you need to cast all the time, it does help and it might be the practicality that the VM they built at the time was able to handle it better. Microsoft's MFC had a concept of CObject too at the top of a big hierarchy. |
|||||||||||
|
|
In my experience, the most horrible examples of crappy code I've seen is written in Java or C#. I've seen some bad stuff in less strict languages, but it's nothing compared to the absolute horrors of staring into the abyss of 1.000.000 lines of copy-pasted static ball-of-mud C# code. I don't know why that is, but my guess is because it's easier, even possible, to just keep adding more and more (and more...) code in Java/C#, safe in the knowledge that the compiler will tell you when your syntax is wrong. Unfortunately it doesn't tell you when your design is wrong. I'm not saying Java/C# is bad or anything, quite the opposite. It's just that all this helping, enforcing type-safety makes it possible to mess things up far more than in more flexible, non-enforcing languages. So I can't really say this "enforcing" policy has improved code quality overall. It has improved the amount of code though, that's for sure. |
|||||||||||||||||||||
|
|
A lot of people think that OOP is the best way to write code. They're either right, wrong, or its open for opinion/debate...doesn't matter. Those that wrote Java/C# obviously believe the first. It's easier to enforce OOP as a coding standard if the language itself imposes it. This is also why languages like Java force you to do other things too, like one public class per file. They do have somewhat of a point there. It's hard to get people to do things the way you want. Give them too much freedom and they do it their way and hope it makes it through review. If the tools themselves force them into a certain way of doing things then you don't have to argue and/or get team consensus (which everyone promptly ignores anyway). On the other hand, I never really agreed with anything Java enforced. For one, there are exceptions to every rule and Java simply doesn't provide for that. |
|||
|
|
|
It isn't enforced, after all, as the saying goes: a real developer can write FORTRAN code in any language. But I have to admit, I don't understand the gist of the question. Well, why not? There are so many languages out there, so Gosling and his friends set out to create one that is based on classes and objects only (okay, and a few primitive types). The idea wasn't entirely groundbreaking, but they also wanted readability, C-like syntax and solid, abstract foundations. Every lagnuage represents a trade-off between freedom and strict enforcement of a set of principles that help avoid errors. Assembly gives you total freedom and also every possible opportunity to shoot yourself in the foot. Ada was designed to give you very little freedom but fewer opportunities of self-destruction too. One isn't intrinsically better than the other. Java is just a language leaning towards the stricter end of the spectrum, stricter than C++ but not plunging into the true depths of strong typisation. C# is somewhat easier to explain, it was Microsoft's reply to the popularity of Java (and their failed attempts to sneak proprietary classes into their implementation of the applet framework :)). |
|||
|
|
|
To fulfill the buzzword-compliance requirement. (This is only partly meant as a joke, but it's true). These languages are aimed at businesses, and the average decision maker in BigCorporation has no understanding of programming techniques, but he reads everywhere that OOP is the future. At least, this used to be true 5-15 years ago. Nowadays, a lot more products are being produced by startups rather than big corporations, so Java and C# ended up losing (in a way). Because they aimed to please the clueless middle manager, the more technical and hackery types of people went on to use different technologies (php, ruby, python, and more recently: node.js). |
|||||||
|
|
C++ was built (originally) on top of C, which is procedural. C++ programs still have a 'main' function as the entry-point of a program, which is a procedural legacy. JavaScript is object-oriented, but is based on the prototype-and-delegation model rather than a class-and-inheritance model (these models are functionally equivalent and equally valid). The OO framework within JavaScript is implicit. Just because you can write does not mean you are actually using procedural code; under the hood you have implicitly created an anonymous method belonging to the Document object [caveat: I'm guessing based on debugging the DOM; JavaScript experts please correct] Java and C# were design to be object-oriented using the class-and-inheritance model, hence every program must have a (static) class and Main entry point. Beyond that, though, you are free to be as procedural as you like. |
|||
|
|
|
C# 2.0 added support for OOP is often encouraged, but it's certainly not enforced. You'd be surprised how much of the .NET libraries are implemented as static classes. |
|||
|
|
|
Your question isn't why do these languages support OOP so much as why they disallow OOP. In particular, I guess that means why they don't allow bare functions that aren't a member of any class. It seems like the simplest answer is that supporting that would make those languages more complex (consider that things like namespaces and overload resolution would have to be able to handle bare functions and those features are already complex) in return for little benefit: you can always just do procedural programming using static functions. What real benefit would non-class functions give you? |
|||
|
|
It isn't about "forcing" things. It's merely that some solutions can be expressed purely in OO concepts, so the language provides only OO concepts. |
|||
|
|
|
This is a wild guess, but one reason might be that it makes IDE magic like IntelliSense easier/more helpful. In C++ every function of the C standard library is in the global namespace. Every C++ standard library class and function is in the |
|||
|
|
A language is just an abstraction above the assembly code. The choice of abstraction is simply there to help you solve a problem ( making targeted tasks easier to get right, and certain problems harder to get wrong ). They had to pick an abstraction. And as I see it ( ignoring all the business reasons ) C# was the conceptual abstraction over C++ which was the abstraction over C except with classes ( OO ). C# simply tried to re-enforce the OO model, and solve problems like memory leaking and abstracting away some of the low level complexities. If it is not suitable for your problem domain, then simply pick the appropriate language with the best abstraction for you problem domain. |
|||
|
|
|
As stated by others. It isn't! If you want to know why it is (or nearly is), then look at Eiffel. It is well worth a look at; you can learn Eiffel quicker than C# or Java. You will finally understand OO, Design by contract, Inheritance, C# properties, and much more. |
||||
|
|
|
One point which hasn't been mentioned is that in many garbage-collection-based object-oriented framework, it is absolutely 100% imperative that the system know the whereabouts of every single object reference--not just every object, but every reference as well--at any time when garbage collection may occur; if there is any thread The above requirement is much stricter than anything which exists for C or C++. In C or C++, one can construct a union which combines an integer numeric type with a pointer, and provided the code keeps track of whether the thing holds an integer or a pointer, it won't matter whether the runtime framework can tell what type the thing is. Such an approach wouldn't work in a garbage-collected language. If interpreting the content of a union as a pointer would reference an object which is being relocated, then it's absolutely imperative that the content of the union be updated to hold the new address if the last thing stored there was a pointer, but it's equally imperative that it be left alone if it's supposed to be holding an integer. There's simply nothing the runtime can do safely if it can't require object-references be stored in storage locations of object-reference type and nowhere else. |
|||||||
|
