OOP

Recommended Posts

Zaku    100
is non OOP generally easier then OOP, cause in java, OOP is giving me a headache :(.

Share on other sites
TheTroll    883
I prefer OOP over top-down or state programing. I just think in OOP. What problems are you having? It just takes learning how to think the right way and it is pretty easy.

theTroll

Share on other sites
Agony    3452
I find that it is generally easier to write very small simple programs without OOP, but for anything that's beyond just a small test or practice, OOP becomes a major help at keeping things organized and easier to manage, even as the project becomes pretty large.

But it's still easy to make atrocious OOP designs that break at every turn and are nightmares to manage. It takes practice and experience to design a good program that scales well, OOP or no OOP. <personal_opinion>Though I still think OOP helps out more than a procedural style (usually what OOP is contrasted with) when designing large projects.</personal_opinion>

Share on other sites
MumbleFuzz    188
Quote:
 Original post by AgonyBut it's still easy to make atrocious OOP designs that break at every turn and are nightmares to manage. It takes practice and experience to design a good program that scales well, OOP or no OOP.
Agony is right.

I don't think OOP is any more or less easy than any other high-level programming style. It's well-suited to certain problems, adequate for others, and in some cases is a bit rubbish.

As ever, it's simply a case of practicing, and of learning how best to use the tools which are available. OOP is certainly a very widespread paradigm, so you probably ought to get used to it.

Share on other sites
MaulingMonkey    1730
Quote:
 Original post by Zakuis non OOP generally easier then OOP, cause in java, OOP is giving me a headache :(.

Java is Object Obsessed Programming. This is counter-productive.

Object Oriented Programming -- using objects where they make sense -- is a useful timesaver if you've got a good grasp of the concept, and it's pros and cons.

Share on other sites
Vorpy    869
Proponents of OOP agree that it is very useful. Detractors of OOP agree that no one can really agree on what OOP is.

Share on other sites
Degra    212
Quote:
 Original post by MaulingMonkeyJava is Object Obsessed Programming. This is counter-productive.Object Oriented Programming -- using objects where they make sense -- is a useful timesaver if you've got a good grasp of the concept, and it's pros and cons.

Very well said. OO should not be used all the time, not everything can be objectified.

Degra

Share on other sites
gunning    749
Quote:
 Original post by Zakuis non OOP generally easier then OOP, cause in java, OOP is giving me a headache :(.

Define easy. Time to write? Time to manage? Ability to understand? Ability to explain to others? Modularity? Resusability? Features?

Quote:
 Original post by MaulingMonkeyJava is Object Obsessed Programming. This is counter-productive.Object Oriented Programming -- using objects where they make sense -- is a useful timesaver if you've got a good grasp of the concept, and it's pros and cons.

That's just plain bad advice. You're implying that OOP should be used only when its useful, and functional procedural programming elsewhere? You should strive for code consistency, and mixing paradigms is possibly the worst thing you could do in that area. Just because C++ and other high-level languages ALLOW you to mix programming paradigms does NOT mean it's a good idea.

[Edited by - skittleo on March 4, 2007 6:08:23 PM]

Share on other sites
mikeman    2942
Quote:
 That's just plain bad advice. You're implying that OOP should be used only when its useful, and functional procedural programming elsewhere?

No, that's very good advice. Why, you're implying that OOP(or any other paradigm) should be used everywhere, even when it's not useful?

Meh... People have so mixed ideas about what OO is, that personally I don't care any more. Most think that the difference between OO and procedural is the difference between foo.proc() and proc(foo). I won't even try to argue that,in many cases, proc(foo) enhances encapsulation(Scott Meyers). I just try(as much as I can) to keep some important design principles. Whether I do it with classes or non-member functions or templates or anything, I don't really care... Even SC++L mixes different paradigms, like OO(say,std::list),"procedural"(say,std::sort) or functional(say,std::for_each).

Share on other sites
gunning    749
Quote:
Original post by mikeman
Quote:
 That's just plain bad advice. You're implying that OOP should be used only when its useful, and functional procedural programming elsewhere?

No, that's very good advice. Why, you're implying that OOP(or any other paradigm) should be used everywhere, even when it's not useful?

Again, code consistency. I'm only arguing the case of OOP and Procedural programming, and obviously everywhere is probably an ideal, but nevertheless it is still extremely important. If this needs explaining, let me quote Enterprise Application Development with Visual C++ 2005:

Quote:
 The importance of a coding standard is often downplayed by developers and incorrectly regarded as an unnecessary complexity. This is fundamentally wrong. Quite the contrary, following a rigid coding standard is a necessary prerequisite for developing quality code because coding standards enforce consistency, which is an essential component of making comprehension of logic represented by the source code easy and transparent.You can tell a lot about a developer by looking at his code. If the code is inconsistent and messy, the developer is undisciplined and disorganized regardless of how brilliant he may be. In the course of my IT career, I have met many software developers who were sharp and quick thinking but produced terrible-looking code. Even though they produced code that worked, it was incredibly hard to comprehend by anybody else but the original author. On top of that, such code frequently contains internal inconsistencies and hidden interdependencies, which usually result in unexpected errors arising from subsequent code modification conducted even by the original author himself. What's worse, since it is virtually impossible for another developer to comprehend such code, the lack of coding standard creates dangerous dependence of the project on the original code authors, which may or may not be available for further software development or maintenance tasks. Therefore, rigid adherence to a coding standard is essential for success of a software development project especially when a team of developers is involved. Consequently, an average but disciplined developer is ultimately more valuable than a brilliant yet undisciplined one. In the end, it is the simplicity and clarity of code and its underlying logic that ensures the project's success.

Share on other sites
Washu    7829
Quote:
Original post by skittleo
Quote:
 Object Oriented Programming -- using objects where they make sense -- is a useful timesaver if you've got a good grasp of the concept, and it's pros and cons.

That's just plain bad advice. You're implying that OOP should be used only when its useful, and functional procedural programming elsewhere? You should strive for code consistency, and mixing paradigms is possibly the worst thing you could do in that area. Just because C++ and other high-level languages ALLOW you to mix programming paradigms does NOT mean it's a good idea.

Wrong, wrong, wrong. The fact that you would even suggest this makes me shudder at the thought of the kind of code you must write. Object orientation deals with a domain of problems, mostly relating to inter and intra module relationships. Using it outside of the domain its for ends up producing code that is hard to maintain, buggy, and just plain dirty. You mix paradigms for the simple fact that not all paradigms are appropriate solutions to the problem domain at hand. Suggesting that you don't ever mix them is the stupidest idea I've heard today (which is saying a lot, considering I hang out in #gamedev).

You may notice that even C#/VB.Net are introducing functional paradigms into their languages, through LINQ and other such features. Mixing and matching paradigms is one of the best ways of solving problems you can. Simply put, each paradigm that you have available to you gives you the ability to cleanly solve yet another domain of problems. For each paradigm there is a domain of problems that they best solve. Using them outside of those domains, as I stated above, produces code that is NOT easy to maintain.

Share on other sites
MumbleFuzz    188
Quote:
 Original post by skittleoThat's just plain bad advice. You're implying that OOP should be used only when its useful, and functional procedural programming elsewhere? You should strive for code consistency, and mixing paradigms is possibly the worst thing you could do in that area. Just because C++ and other high-level languages ALLOW you to mix programming paradigms does NOT mean it's a good idea.

You reckon? I'd suggest that the most concise and expressive code is the best kind. Treating everything as an object doesn't make sense, because, conceptually, not everything is an object (at least, not in the Java sense). In single-paradigm languages, I find that the architecture of some programs, or of their components, is sometimes necessarily distorted to match the paradigm. They become bloated, or difficult to use, because of the constraints of the language.

Certainly code consistency is a good thing. But I think that writing effective, maintainable and bug-free code is better, and being able to mix paradigms can make this task a lot easier. By choosing a particular programming style, you signal intent; and choosing the right style will often aid one in writing significantly more concise code.

To achieve these ends, I sometimes end up mixing languages, which certainly doesn't aid code consistency.

Quote:
 let me quote Enterprise Application Development with Visual C++ 2005:...
That doesn't contradict anything I said. If anything, it supports it. It argues for "simplicity and clarity of code", which is exactly what I was arguing for myself.

Share on other sites
Washu    7829
Quote:
 Original post by mikemanMeh... People have so mixed ideas about what OO is, that personally I don't care any more. Most think that the difference between OO and procedural is the difference between foo.proc() and proc(foo). I won't even try to argue that,in many cases, proc(foo) enhances encapsulation(Scott Meyers). I just try(as much as I can) to keep some important design principles. Whether I do it with classes or non-member functions or templates or anything, I don't really care... Even SC++L mixes different paradigms, like OO(say,std::list),"procedural"(say,std::sort) or functional(say,std::for_each).

Actually, it was designed more around the idea of sets and the algorithms that can be performed on them. You can see this through the extensive use of the iterators and templates to ensure generic implementations of these algorithms. If anything, its more functional in design (see predicate algorithms) than object oriented, although the usage of templates does enable for distinctly OO principles to be expressed, such as OCP.

Share on other sites
Megaman_22    100
Maybe I don't fully understand the way Java is supposed to be*, but I've never really thought of it as objects so much as a way to keep your data and functions organized. From what I've read, what I'm talking about sounds more like the way Python uses modules.

I'll admit, when you're first learning Java, the OO-ness of it is ridiculous. It does become very useful once you start doing anything more advanced. I know it is far less work to get a JFrame up on the screen than it is to get a window using the Win32 API.

* which probably is true, since I think
public void foo(){	do_stuff();}

is far better than
public void foo(){	doStuff();}

Share on other sites
gunning    749
Quote:
 Original post by WashuWrong, wrong, wrong. The fact that you would even suggest this makes me shudder at the thought of the kind of code you must write.

Linking that youtube video is not making your point, and only furthering an elitist attitude which hinders debate - arguably the pinnical of intellectual thought. Not cool man.

Quote:
 Original post by WashuObject orientation deals with a domain of problems, mostly relating to inter and intra module relationships. Using it outside of the domain its for ends up producing code that is hard to maintain, buggy, and just plain dirty. You mix paradigms for the simple fact that not all paradigms are appropriate solutions to the problem domain at hand.

But surely you'll agree the vast majority of problems a programmer will encounter can cleanly be implemented in either paradigm, and consistency with that paradigm should take precidence over ease of implementation for the benefits of overall code expressiveness, maintenance, etc etc.

Quote:
 Original post by WashuYou may notice that even C#/VB.Net are introducing functional paradigms into their languages, through LINQ and other such features.

I don't know much about LINQ, but since C#.Net is primarily an OO language, any introduction of procedural paradigms is probably there just to make ends meet, which is an exceptional situation not in contrast to my general assertion that mixing paradigms is a bad idea.

Quote:
 Original post by WashuMixing and matching paradigms is one of the best ways of solving problems you can. Simply put, each paradigm that you have available to you gives you the ability to cleanly solve yet another domain of problems. For each paradigm there is a domain of problems that they best solve. Using them outside of those domains, as I stated above, produces code that is NOT easy to maintain.

Again, I'd argue that most problems can cleanly be implemented in either paradigm so consistency takes precidence over each's very minor benefits.

The .Net framework taken as a whole is a good example of OOP used across a very broad range of problems, arguably ones that might individually be better suited for a procedural approach, for the benefits of code consistency in this case even across languages.

Share on other sites
Washu    7829
Quote:
Original post by skittleo
Quote:
 Original post by WashuWrong, wrong, wrong. The fact that you would even suggest this makes me shudder at the thought of the kind of code you must write.

Linking that youtube video is not making your point, and only furthering an elitist attitude which hinders debate - arguably the pinnical of intellectual thought. Not cool man.

Very cool actually. I laugh each time I see that rerun.
Quote:

Quote:
 Original post by WashuObject orientation deals with a domain of problems, mostly relating to inter and intra module relationships. Using it outside of the domain its for ends up producing code that is hard to maintain, buggy, and just plain dirty. You mix paradigms for the simple fact that not all paradigms are appropriate solutions to the problem domain at hand.

But surely you'll agree the vast majority of problems a programmer will encounter can cleanly be implemented in either paradigm, and consistency with that paradigm should take precidence over ease of implementation for the benefits of overall code expressiveness, maintenance, etc etc.

No, I don't agree. There are many different types of problems, and not all of them are solve cleanly by a single paradigm. As an example, operating on collections of objects generally isn't a very clean area of OO. It introduces a lot of temporary or partial classes that just aren't needed in functional or relation styles of programming. Your database sure as heck isn't OO, although you may abstract the database out by exposing business objects that interface with the database. Note though, business objects incorporate business rules, and aren't just objects for the sake of being objects.
Quote:
Quote:
 Original post by WashuYou may notice that even C#/VB.Net are introducing functional paradigms into their languages, through LINQ and other such features.

I don't know much about LINQ, but since C# is an inheritently OO language, any introduction of procedural paradigms is probably there just to make ends meet, which is an exceptional situation not in contrast to my general assertion that mixing paradigms is a bad idea.

Uh, procedural != functional. Functional programming is an entirely different paradigm to that of procedural programming. Wikipedia them.
Quote:
Quote:
 Original post by WashuMixing and matching paradigms is one of the best ways of solving problems you can. Simply put, each paradigm that you have available to you gives you the ability to cleanly solve yet another domain of problems. For each paradigm there is a domain of problems that they best solve. Using them outside of those domains, as I stated above, produces code that is NOT easy to maintain.

Again, I'd argue that most problems can cleanly be implemented in either paradigm so consistency takes precidence over each's very minor benefits.

No. In fact, the "very minor benefits" that you just so decisively put down, are the very reasons they exist in the first place. OO's "very minor benefits" came about because procedural programming has issues in dealing with dependency management. Functional benefits came about because procedural and object oriented languages just don't deal with sets very cleanly. Aspect oriented programming came about because sometimes the dependencies introduced by OO are extrenuous to the point that even it requires extra dependency management.
Quote:
 The .Net framework taken as a whole is a good example of OOP used across a very broad range of problems, arguably ones that might individually be better suited for a procedural approach, for the benefits of code consistency in this case even across languages.

The .NET framework is writting in a mostly consistent OO style, but you can clearly see areas where they wished they had a functional notation at hand. Furthermore, the reliance upon static classes clearly demonstrates that even procedural programming is of great benefit to the framework. Just because you have a hammer (for any paradigm) doesn't mean that everything is a nail. Wiring up an RJ45 jack is extremely hard if all you can use is a hammer, the same is true of programming.

Share on other sites
Wavesonics    330
I disagree. A project should either lend it's self to OOP or not. No combination. certain projects should be OOP and certain shouldn't be.

But quite honestly. I'm drunk. really drunk. so don't take my word for crap right now.

[Edited by - Wavesonics on March 5, 2007 12:08:38 AM]

Share on other sites
Guest Anonymous Poster
Too much emphasis is given to these dubious software processes and software engineering principles. It is like comparing astrology as opposed to astronomy. Good software comes from understanding inputs and outputs not on relying on canned design patterns. I used to work for a company and they were real big on that crap but then so was their overbloated software.
The only principle one needs to know is to keep the software as local and independent as possible. Doesn't sell many books but it works.

Share on other sites
Nathan Baum    1027
Quote:
 Original post by WavesonicsI disagree. A project should either lend it's self to OOP or not. No combination. certain projects should be OOP and certain shouldn't be.

Does this mean rejecting projects which don't have a clear-cut solution?

Share on other sites
Washu    7829
Quote:
Original post by Nathan Baum
Quote:
 Original post by WavesonicsI disagree. A project should either lend it's self to OOP or not. No combination. certain projects should be OOP and certain shouldn't be.

Does this mean rejecting projects which don't have a clear-cut solution?

Not only would it appear to indicate that, but it would also suggest that any problem that might be better solved by stepping outside of such a restrictive problem domain would have to be hammered into an "OOP" solution. In his case this probably means using class and other such "OO" things.

Share on other sites
daviangel    604
Try C# if Java is giving you a headache since Java forces every program you write to be in a class whereas with C#/VB/c++ you can decide if you want your program to use oop or not.
It definitely takes more time/space to write a good OOP program just look at all the books Lamothe wrote and he never used OOP in any of them since it distracts from the game programming he was trying to teach and takes up alot more pages in a book.
Even Windows guru Charles Petzold admits he prefers using plain old C and it's procedural style for his short and dirty little programs.

Share on other sites
MaulingMonkey    1730
Quote:
Original post by skittleo
Quote:
 Original post by MaulingMonkeyJava is Object Obsessed Programming. This is counter-productive.Object Oriented Programming -- using objects where they make sense -- is a useful timesaver if you've got a good grasp of the concept, and it's pros and cons.

That's just plain bad advice. You're implying that OOP should be used only when its useful,

That's exactly what I'm saying. If it's not useful, why use it? If it is not useful, it is by definition without benifit, no? OOP for the sake of consistency is useful -- to a point. When half your classes contain verbs, you have a horrible problem. Like AIDS Java.

Note: Comprimises may need to be made if you've got AIDS a broken language (Java).

Quote:
 You should strive for code consistency, and mixing paradigms is possibly the worst thing you could do in that area. Just because C++ and other high-level languages ALLOW you to mix programming paradigms does NOT mean it's a good idea.

If you want consistency, try Whitespace. None of those pesky printable characters in between all that blankness to ruin consistent nothingness.

I think I've made my point. Trying to force things which by their very nature aren't consistent in the slightest to a superficial appearance of consistency only hides the relevant facts of the matter, and as a result is not a good ideaTM. In the case of whitespace, this would be words and the characters used for composing sentances (in deliniating where words begin and end, where sentances begin and end, and the overal tone and sentance type being posed).

EDIT:

Quote:
Original post by Washu
Quote:
Original post by skittleo
Quote:
 Original post by WashuWrong, wrong, wrong. The fact that you would even suggest this makes me shudder at the thought of the kind of code you must write.

Linking that youtube video is not making your point, and only furthering an elitist attitude which hinders debate - arguably the pinnical of intellectual thought. Not cool man.

Very cool actually. I laugh each time I see that rerun.

Agreed. I do hope you'll post it the next time you think I'm wrong, as I percieve it to lighten the mood of any debate, greasing the terse gears of debate, at the expense of a few who are too serious for their own good anyways.

Share on other sites
Nathan Baum    1027
Quote:
 Original post by daviangelEven Windows guru Charles Petzold admits he prefers using plain old C and it's procedural style for his short and dirty little programs.

Leo Tolstoy wrote in Russian, but I think if I tried, the result would not be War and Peace.

Share on other sites
Zahlman    1682
Quote:
 Original post by VorpyProponents of OOP agree that it is very useful. Detractors of OOP agree that no one can really agree on what OOP is.

Hey, I'm a proponent of OOP (for the things for which it's useful - in general I certainly support MM and Washu on this one, as I usually do) and I also agree that no one can really agree on what OOP is. :)

I can say that a *lot* of people out there are promoting *extremely bizarre* ideas about "OOP" which often go exactly against what OOP is supposed to be (as I see it), and often making large amounts of money in the process :(

(And yes, Java is broken, but not unusably so. It can also be abused - not only by the self-styled OOP "gurus" and "architects" building ridiculously complex object systems, but by people who want to do things the purely procedural way, as well. There is a loophole - the static keyword - that is required to get anything started in an otherwise-purely-OO environment. Unless maybe you want to specify *from the command line* which object to instantiate first and what "master" method to invoke to get things rolling. And this allows us to do deliciously evilly procedural things. :D Although I guess you might as well use C++ then. You'll lose lots of convenient memory management features and array safety, but you'll gain homogeneous containers, the ability to avoid automatically generated levels of indirection at every turn, and the ability to just create a damn 2-word struct without an extra 3 words of overhead.)

Edit: Yes, MM, I sux at teh intarwebs, k? <3

[Edited by - Zahlman on March 6, 2007 2:22:14 AM]

Create an account

Register a new account