🔒 Locked

OOP = Object Obsessive Programming

Started by mako_5 Aug 30, 2006 at 6:42 AM 81 replies 11.5k views

Original Post

Aug 30, 2006 at 6:42 AM

I was wondering what other's universities are doing about the whole OOP paradigm. It seems like they're teaching us to ALWAYS attack a problem from that perspective. While this doesn't completely sound harmful, they don't ever give cases when procedural work is best. Sometimes it seems like people make EVERYTHING an object, and it just ends up a big mess, like trying to find Shakespeare in alphabet soup. My main concern is that I go for a balanced OOP/procedural approach, and try to limit the number of classes, so every class has a very well defined purpose. Then they might punish me for the way I think... So, what's up with this object-obsession? Is this just used because they can more easily grade something like this when you have 40+ students a class?

dave

Aug 30, 2006 at 6:48 AM

Although you are correct, a balance needs to be found in commercial work, in education they are simply teaching you the object oriented approach. As much as it can suck, you have to do what they want for you to pass, regardless of whether it is the best of correct way.

Dave

ApochPiQ

Aug 30, 2006 at 6:53 AM

OOP sucks. Long live Object-Aware Programming.

polly

Aug 30, 2006 at 6:57 AM

Quote:
My main concern is that I go for a balanced OOP/procedural approach, and try to limit the number of classes, so every class has a very well defined purpose.

Erm... that is object oriented programming.

There is absolutely no need in OO to model absolutely everything as an instantiable object; and if that is what you're being taught, then I'd be quite worried.

An object is simply a block of data with a set of associated operations to modify or obtain that data; and not everything fits this pattern. Take the Service layer pattern for example - this is still OO, but I think that you would consider it "procedural" in appearance. Further examples are things such as static utility methods, which I generally group into a single non-instantiable classes of closely-related methods; again, this is still OO, but I think at this point you would become confused and consider such a practise "procedural".

OO does NOT mean treating absolutely everything in your problem domain as an instantiable object.

Jon

EDIT: When I say "instantiable object", I mean an object that other classes instantiate at will.

mako_5

Aug 30, 2006 at 6:58 AM

Quote:
Original post by ApochPiQ
OOP sucks. Long live Object-Aware Programming.

I read that especially with the Kingdom of Nouns illustrations. Every programmer who has ever used classes should read that. Now, if I could just dig up a copy of "The Pragmatic Programmer"... (will do this over Thanksgiving break)

ToohrVyk

Aug 30, 2006 at 7:04 AM

Many teachers just suck. A colleague (who had also been my Computer Science teacher) once said in a private discussion that Objective Caml was objective because they added operator.. For those who don't know this: operator. in OCaml is the namespace ownership operator, the actual polymorphic dispatch is done by operator#, as in:

let obj = new Rendering.Effects.sparks (position) in obj # render;;

A corollary to this is that most teachers don't have the slightest idea of what it takes to write professional code. My best teachers in this domain were former teachers who had become CEOs of a successful software company, and they taught me more on team development than anyone before. In short, 99% of teachers want to teach you not how to write good proofessional code, but rather how to pass whatever exams are required.

I must admit, I'm in this situation too, through no fault of my own, since (one of ) my job(s) is to teach functional programming to the equivalent of college freshmen, who have to pass several difficult exams at the end of their second year. Thus, I mustn't care about industry practices, team programming, objective analysis or planning ahead: I have a list of prerequisites and I must teach them.

So, when I teach recursion, even though someone in the class may come up with some clever, readable and efficient iterative method, I will insist that he instead uses recursion. This is because he obviously has no trouble writing an iterative solution, just like you have no trouble mixing OOP and procedural styles. Therefore, he must concentrate on what he might not master yet: recursive programming, even though he has to go through hOOPs for this.

polly

Aug 30, 2006 at 7:16 AM

Quote:
Original post by mako_5
Quote:
Original post by ApochPiQ
OOP sucks. Long live Object-Aware Programming.

I read that especially with the Kingdom of Nouns illustrations. Every programmer who has ever used classes should read that. Now, if I could just dig up a copy of "The Pragmatic Programmer"... (will do this over Thanksgiving break)

I don't think you should take the author (of the article) seriously. Here is the authors problem:

Quote:
I think, to a large degree, this kind of stuff is what "object-orientation" is all about: if you have code to write, find a way to cram it into an "object," a noun.

I think he's missed the point. I'd quite like to see an example of what he thinks is "Java OO style", a phrase he uses repeatedly, because I think it might illustrate why a lot of people hate Java - not because of Java itself, but because they have wierd ideas about what what object orientation is, and they take these wierd ideas with them and end up getting in mental-knots over whatever it is they are trying to achieve.

Jon

OrangyTang

Aug 30, 2006 at 7:21 AM

Quote:
Original post by mako_5
My main concern is that I go for a balanced OOP/procedural approach, and try to limit the number of classes, so every class has a very well defined purpose.

Fear Of Adding Classes. Your statement actually contradicts itself - you should have well defined purposes for classes, but this means that classes become smaller and more numerous, not fewer and larger. (Hint: "Everything to do with X" is not a well defined purpose, and leads to big bloaty classes).

If you're having problems with "too many" classes you've probably either got:
- Poorly defined class responsibilities
- Badly named classes

I'm also going to throw in a link to Most Programmers Don't Grok Objects / Most Game Programmers Don't Grok Objects on the basis that it's largely true. I don't even 'grok' objects yet - despite doing lots of programming using OO I've still not got a 'deep' understading and I'm constantly finding out how badly my previous stuff really was.

mako_5

Aug 30, 2006 at 7:24 AM

Quote:
Original post by polly
I think he's missed the point. I'd quite like to see an example of what he thinks is "Java OO style", a phrase he uses repeatedly, because I think it might illustrate why a lot of people hate Java - not because of Java itself, but because they have wierd ideas about what what object orientation is, and they take these wierd ideas with them and end up getting in mental-knots over whatever it is they are trying to achieve.

The problem with Java (from my personal experience with it) is that because everything lives in a class and classes are so hard to create, many people feel obligated to use classes a lot. All the time. For everything. As a language, the main weakness it has is the lack of real control of primitives (it can only pass their values by value, not by reference or pointer).

While I love the language for its simplicity, I am troubled that starting out new programmers in it will result in a continued object-obsession. This is because they will never be challenged to write code without using any objects at all, or attempting to limit the number of them in any way. So instead of thinking, "hey, that primitive data type or char[] would be better than making a whole new class" they blindly flock to making a class because that is the only thing they have ever been taught.

There's a magical balance point for each language between procedural and OO programming, we just should not venture to the far extremes unless dictated by our language choices (e.g. C doesn't have objects, but structs can do a lot classes can, and trying to write completely procedural stuff in Java is a nightmare).

polly

Aug 30, 2006 at 7:34 AM

I was a C programmer to start with (at College). I am now a Java programmer (at work), and I disagree with you completely.

1) Classes and Objects are not hard to create. I don't understand why you think this. Here is a simple utility class:

public class TextUtils{  private TextUtils(){}  public static String doSomething(String alterMe)  {     // .. Implement  }}

Whats hard about that? Where is the "noun" in the class name that OO programmers are accused of fetishising? Why is this so much more difficult than just writing a procedural method in C?

Can you give an example of this object obsession? I am genuinely curious, because I really don't understand where you're coming from on this.

2) If I can quote you're above..

Quote:
While I love the language for its simplicity, I am troubled that starting out new programmers in it will result in a continued object-obsession. This is because they will never be challenged to write code without using any objects at all, or attempting to limit the number of them in any way. So instead of thinking, "hey, that primitive data type or char[] would be better than making a whole new class" they blindly flock to making a class because that is the only thing they have ever been taught.

What would you think of a new programmer who produced massive monolithic functions that tried to do everything in one block of code? Or of a programmer who wrote new functions that could simply be inlined in one line of code in the few instances where it was used? Would you assume that there was something inherantly wrong with procedural programming and its over-use of functions, or that the programmer has simply had a poor teacher?

Jon

nullsquared

Aug 30, 2006 at 7:48 AM

Original post by polly
I was a C programmer to start with (at College). I am now a Java programmer (at work), and I disagree with you completely.

1) Classes and Objects are not hard to create. I don't understand why you think this. Here is a simple utility class:
public class TextUtils{  private TextUtils(){}  public static String doSomething(String alterMe)  {     // .. Implement  }}
Whats hard about that? Where is the "noun" in the class name that OO programmers are accused of fetishising? Why is this so much more difficult than just writing a procedural method in C?

Where is the object obsession you "I-hate-Java" guys talk about? Can you give an example? I am genuinely curious, because I really don't understand where you're coming from on this.

2) If I can quote you're above..

Quote:
While I love the language for its simplicity, I am troubled that starting out new programmers in it will result in a continued object-obsession. This is because they will never be challenged to write code without using any objects at all, or attempting to limit the number of them in any way. So instead of thinking, "hey, that primitive data type or char[] would be better than making a whole new class" they blindly flock to making a class because that is the only thing they have ever been taught.

What would you think of a new programmer who produced massive monolithic functions that tried to do everything in their code? Or of a programmer who wrote new functions that could simply be inlined in one line of code in the few instances where it was used? Would you assume that there was something inherantly wrong with procedural programming and its over-use of functions, or that the programmer has simply had a poor teacher?

Jon[/quote]

I think the point is that in your case you need a namespace, not a class. A class should be used when you want to initiate an object of that class and have member functions modify it.

Rather, this is how it should look:
namespace texUtils {    std::string toUpper(std::string const& in) { ... }}// and nowstd::string myString = texUtils::toUpper("hello");

ApochPiQ

Aug 30, 2006 at 7:54 AM

Quote:
Original post by polly
I think he's missed the point. I'd quite like to see an example of what he thinks is "Java OO style", a phrase he uses repeatedly, because I think it might illustrate why a lot of people hate Java - not because of Java itself, but because they have wierd ideas about what what object orientation is, and they take these wierd ideas with them and end up getting in mental-knots over whatever it is they are trying to achieve.

Jon

Read the Kingdom of Nouns thing - it explains in painful detail precisely what I'm talking about.

I know (and, apparently, so do you) that proper programs using objects do not over-nounify everything. However, noun-worship is terribly prevalent, and in many cases the connotation of noun-worship is inseparable from the term "object oriented" in many people's minds.

I proposed the replacement term "object-aware" not because it really means anything all that different from what OO should mean, but rather to escape all the stupid stigma and baggage that's been attached to the phrase "object oriented" over time.

Also, I'm not really in the mood to be tactful, so I'll be blunt instead: your example code is bullshit. That is far too trivial to really give any proper indication of the state of things. It's also 100% contrived, i.e. you could easily make up code that seems to support your point of view.

What's important is not whether you can contrive simple blocks of code that resemble procedural programs (however vaguely). What's important is the "attractor point" that programmers tend to gravitate towards when building real programs. For Java (and, sadly, even C#, which is otherwise a pretty good language) that attractor point lies in the domain of object-obsession, not the faux-procedural stuff you're demonstrating.

Nobody's saying that it's impossible to do procedural style apps in Java or whatever - what we're saying is that it is unnatural. OOP is possible in C (or assembler for that matter) but it's not natural. Functional programming is possible in C++ but definitely not natural. Procedural, non-object-obsessed software is possible in Java. But it's the exception, not the rule, and it's hideously awkward to create.

polly

Aug 30, 2006 at 7:55 AM

Quote:
Original post by agi_shi
A class should be used when you want to initiate an object of that class and have member functions modify it.

I disagree. A class can also be non-instantiable and can simply contain a collection of closely related methods. There is no inherant disadvantage in placing them as static methods in a class, at least that I can see.

Am I right in thinking that you think that there is something inherantly wrong with my example TextUtils class? Could you explain what it is?

Jon

polly

Aug 30, 2006 at 8:01 AM

Quote:
Original post by ApochPiQ
Read the Kingdom of Nouns thing - it explains in painful detail precisely what I'm talking about.

I know (and, apparently, so do you) that proper programs using objects do not over-nounify everything. However, noun-worship is terribly prevalent, and in many cases the connotation of noun-worship is inseparable from the term "object oriented" in many people's minds.

I proposed the replacement term "object-aware" not because it really means anything all that different from what OO should mean, but rather to escape all the stupid stigma and baggage that's been attached to the phrase "object oriented" over time.

I've started reading it, and he seems to start with the same flawed assumptions about Java programmers.

I have not encountered the noun worship that you mention. Is this something you've come across in the workplace, or at college? Although I do seem to remember some lecturers having some strange ideas about how to write object oriented code, but as has already been suggested, lecturers are often not the best people to teach programming.

Jon

PumpkinPieman

Aug 30, 2006 at 8:06 AM

Quote:
Original post by polly
I was a C programmer to start with (at College). I am now a Java programmer (at work), and I disagree with you completely.

1) Classes and Objects are not hard to create. I don't understand why you think this. Here is a simple utility class:

*** Source Snippet Removed ***

Whats hard about that? Where is the "noun" in the class name that OO programmers are accused of fetishising? Why is this so much more difficult than just writing a procedural method in C?

Can you give an example of this object obsession? I am genuinely curious, because I really don't understand where you're coming from on this.

Jon

I see this as "unclean", in this respect classes become a form of namespacing when all their members are declared static. I personally don't find Java any harder then C++, nor do I think the opposite. Java however IMO is very nasty when dealing with any GUI \ File IO stuff.

polly

Aug 30, 2006 at 8:15 AM

Quote:
Original post by ApochPiQ
Also, I'm not really in the mood to be tactful, so I'll be blunt instead: your example code is bullshit.

Oh, Really? I'm not going to spend hours writing vast amounts of code to explain things to some bloke on Gamedev. The point of trivial examples is they are easy to understand and illustrate simple points with minimal effort.

Jon

polly

Aug 30, 2006 at 8:20 AM

Quote:
Original post by PumpkinPieman
Java however IMO is very nasty when dealing with any GUI \ File IO stuff.

Both of these points I agree with. Although the recent NIO libraries have been an improvement.

Quote:

I see this as "unclean", in this respect classes become a form of namespacing when all their members are declared static.

It's worth pointing out here that such classes should never retain any state, or have any member variables at all.

PumpkinPieman

Aug 30, 2006 at 8:35 AM

Quote:
Original post by polly
Quote:
Original post by PumpkinPieman
Java however IMO is very nasty when dealing with any GUI \ File IO stuff.

Both of these points I agree with. Although the recent NIO libraries have been an improvement.

Quote:

I see this as "unclean", in this respect classes become a form of namespacing when all their members are declared static.

It's worth pointing out here that such classes should never retain any state, or have any member variables at all.

Personally I think a standard library should represent the most flexable model of file handling. I've never really liked object serialization as well, which is my beef with .NET. Athough I must note that .NET's implementation is still much better then Java's.

and of course, if you're developing a utility class like that it makes having member variables redundant unless the variables are private and static there by are needed by the static methods. (keeping track of stuff, I guess)

AndreTheGiant

Aug 30, 2006 at 9:03 AM

Doesnt it depend on the language too?

I think in Java, there is a lot more 'forcing' you to use objects wether you want to or not. So a lot of the time you end up using static methods/objects just to get back to procedural programming

On the other hand I find that C++ lets you use objects, but doesnt force you as much as java.

But yes, in school, they specifically chose problems (for homework, etc) that were best solved using an OO solution. This was because they were trying to teach us OO programming. They even worded the questions such that it was easy to pick out what the objects should be and what they should do.

Personally, I find that a lot of programming tasks seem like they could be solved using OO techniques, or procedural techniques just as easily. However, with experience, I find that when you have to go back and maintain that code, or expand it, or incorporate it into another project, you'll be happier if you used more OO than just procedural.

Nice topic :)

Simian Man

Aug 30, 2006 at 9:32 AM

I think the real issue here is that Computer Science courses are supposed to teach you more ways to solve a problem than just the Object-Oriented Way.

Using Java as the (only) teaching language will not do that. Sure you can show them how to hack up a procedural solution with static methods, but that is not really showing them the procedural paradigm.

Java also does not show them how to use pointers, which (though they should be avoided when they can in real code), is somthing CS students should learn. God help them if they ever have to learn assembly!

Also, Java does not naturally support functional programming. I think all CS students should be introduced to this. (Parenthetically, C++ better simulates the Functional style with its transform, and count_if type functions...This support will get better with the next standard.) An actual functional language would be much better than C++ obviously.

Also, unless I'm mistaken, Java's generics don't allow TMP, while C++ templates do. This is another paradigm that Java-based courses can't even begin to introduce.

Don't get me wrong, Java is a cool programming language, and is great at the things it was designed for. I just think that it should not be the *only* language that students are introduced to, because it leads to this "Object Obsession".

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.