Programming Forums > Script Programming > Python

Darkhack · Oct 13th, 2007, 10:59 AM

Quote:

Originally Posted by Arevos

You seem to be labouring under the assumption that you need a language specifically created for OOP, which, as DaWei has pointed out several times in the past, is simply not the case.

OOP can be good when used properly. The thing about GObjects is that while it may be OOP, it is still confined to the rules of C, which makes it FAR more sane to use than C++ which requires a PhD to fully understand. Also, be careful not to confuse the idea of OOP with modularity. They are different. The idea of OOP isn't bad, but it can be easily misused. It is much easier to create a hard to read program with OOP than it is without. In particular, inheritance because instead of saying "W is made up of components X, Y, and Z". You are saying "W is X with Y and Z changes". The flow from simple functions building up to create more complex ones is now broken and you've added a crap load of complexity. Applications that use inheritance are simply harder to maintain. With procedural programming, functions are very predictable. With inheritance there is a LOT of ambiguity as to which is which and in what ways does this subclass override the parent class. Multiple inheritance is the biggest joke of all. With procedural programming, once you are familiar with the codebase, you can be quite productive. With multiple inheritance in use, you will be constantly checking the documentation to see which variables and methods are overridden. If you are working on an open source project, trying to follow the changes made by other programs to classes with inheritance requires you to practically relearn the entire class. It's just too difficult to use. I don't care what features [insert language here] adds to make inheritance more sane. It's still a nightmare and shouldn't be used. The "is a" relationship acts like spaghetti code on complex projects.

Please don't misunderstand. OOP can be a huge benefit to developers if you realize what features are sane and which aren't. Grouping together data with methods and being able to create multiple instances of a class is pure genius. Everything else... not such much, except maybe in a few isolated cases (hell, even goto is acceptable once in a rare while if you know what you are doing).

Arevos · Oct 13th, 2007, 5:27 PM

Quote:

Originally Posted by Darkhack

Applications that use inheritance are simply harder to maintain. With procedural programming, functions are very predictable. With inheritance there is a LOT of ambiguity as to which is which and in what ways does this subclass override the parent class. Multiple inheritance is the biggest joke of all. With procedural programming, once you are familiar with the codebase, you can be quite productive. With multiple inheritance in use, you will be constantly checking the documentation to see which variables and methods are overridden.

How much experience do you have maintaining large code bases? In my experience, inheritance done right makes maintenance a whole lot easier, especially when dealing with reasonably large applications.

With a sufficiently large codebase, it's often difficult to hold the complete layout in your mind at once. But if the system uses a sane amount of inheritance, you can get a good idea of what a class does by looking at what classes it inherits from. There have been times when I've come across an unknown class, but been able to infer it's general purpose from its ancestors.

Also, inheritance reduces repetition, which is always a good thing to have.

I think that you don't really have enough experience to judge the merits of OOP. If your sole experience of OOP is C++ and Java, then I suspect that you don't really have a complete understanding of OOP. In Alan Kay's words:

Quote:

I invented the term "Object-Oriented", and I can tell you I did not have C++ in mind.

Darkhack · Oct 13th, 2007, 7:16 PM

Quote:

Originally Posted by Arevos

I think that you don't really have enough experience to judge the merits of OOP. If your sole experience of OOP is C++ and Java, then I suspect that you don't really have a complete understanding of OOP.

My main experience with OOP is in C++. I also have experience with PHP but never even saw a reason to look at OOP with it. I still standby my statement that inheritance is pretty evil in that a constant over riding of variables and methods is a junk way to design programs. If one were to use inheritance in such a way that things were only be added in the subclass and very very few overrides were in place, then I would be much more likely to use it without throwing up on the keyboard. The problem with this though is that program requirements are constantly changing. With procedural programming it's not a big deal if a function changes. Your entire pyramid won't fall over because a function is designed to do one thing and do it well (UNIX Philosophy) where as an object tries to be an "all-in-one" solution. When a subclass extends a parent class, it inherits everything. As soon as you want exceptions to this, you have nasty overrides in the subclass and if for whatever reason the parent class needs additional methods that are to NOT belong in the subclass, you must again do some nasty overrides to ensure they do not inherit this new behavior.

My overall point is that OOP has a lot of features that promote bad practice. If one were to take OOP and strip it of all these flaws, then it would be quite nice to write code for. If you say that C++ sucks at OOP then I'll take your word for it. Maybe one of these days I'll pick Python up since I've heard so many good things about it. Until then, I'll stick with good, old fashioned C. Besides, OOP isn't the second coming. You really aren't going to be *that* much more productive than in a non-OOP language. Again, I realize OOP is more than just in the language, but in non-OOP languages, the syntax causes you to think about objects in a proper manner and not like a kid in a candy store with dozens of new keywords that are just begging the programmer to do something stupid like multiple inheritance. Also it is never acceptable to put everything under the sun in a class {...}. Anyone who thinks that it is necessary for all code to be inside a class needs a good hard slap across the face. Strong words, yes, and I realize I sound border-line douche-bagish, but you have to wonder who the hell taught this kids programming when they come out of college thinking OOP is a religion.

Arevos · Oct 13th, 2007, 8:42 PM

I still can't quite see why you object so strongly to inheritance, as in many situations it provides a much cleaner solution than the procedural approach. For instance, take the following code:

 python Syntax (Toggle Plain Text) 
class Player(object):
    def examine(self, name)
        item = self.find_item(name)
        item.on_examine(self)
 
    def take(self, name):
        item = self.find_item(name)
        item.on_take(self)
 
    def message(self, text):
        print text
 
    def kill(self, killer):
        self.message("You were killed by a " + killer)
 
class Item:
    def __str__(self):
        return self.name
 
    def on_examine(self, player):
        player.message(self.description)
 
    def on_take(self, player):
        self.container.remove(self)
        player.inventory.append(self)
 
class LiveGrenade(Item):
    name = "live grenade"
    description = "Look out! It's a live grenade!"
 
    def on_take(self, player):
        player.message("Kaboom! The grenade exploded when you picked it up!")
        player.kill(self)
class Player(object):
    def examine(self, name)
        item = self.find_item(name)
        item.on_examine(self)

    def take(self, name):
        item = self.find_item(name)
        item.on_take(self)

    def message(self, text):
        print text

    def kill(self, killer):
        self.message("You were killed by a " + killer)

class Item:
    def __str__(self):
        return self.name

    def on_examine(self, player):
        player.message(self.description)

    def on_take(self, player):
        self.container.remove(self)
        player.inventory.append(self)

class LiveGrenade(Item):
    name = "live grenade"
    description = "Look out! It's a live grenade!"

    def on_take(self, player):
        player.message("Kaboom! The grenade exploded when you picked it up!")
        player.kill(self)

The LiveGrenade class uses inheritance to override the on_take method. Indeed, the whole point of the OOP approach is that what a method actually does should be left up to the object. You're essentially just giving an object a message, and leaving the implementation up to it.

If I wanted to modify the above code to support multiple players, that wouldn't be too hard, either. I could have Player.message send the message to a TCP socket, rather than to STDOUT. I could even leave out the definition of the message method altogether, and have subclasses inheriting from it for single and multiplayer modes.

I'm curious as to how you'd write the above in a procedural style, and yet still retain the future flexibility that inheritance allows. For instance, let's say I wanted to have a squeaky toy:

 python Syntax (Toggle Plain Text) 
class SqueakyToy(Item):
    def on_take(self, player):
        player.message("It squeaks as you pick it up")
        Item.on_take(self, player)
class SqueakyToy(Item):
    def on_take(self, player):
        player.message("It squeaks as you pick it up")
        Item.on_take(self, player)

Or a gorgon head:

 python Syntax (Toggle Plain Text) 
class GorgonHead(Item):
    def on_examine(self, player):
        player.message("As you look at it, you turn to stone")
        player.kill(self)
class GorgonHead(Item):
    def on_examine(self, player):
        player.message("As you look at it, you turn to stone")
        player.kill(self)

I don't see how this makes the code any less maintainable. It seems to do quite the opposite, in fact!

Soulstorm · Oct 18th, 2007, 8:59 AM

Being much more inexperienced than possibly all of you, I didn't know that C++ is not to be taken as an example of OOP. However, allow me to disagree with Darkhack.

At first, programming concepts in general require much thinking before adopting any of them. Not all programming concepts are suitable for every situation. In some cases, utilizing procedural programming is all that one needs to solve a specific problem, if the project is small. But I find it hard to imagine that one could not use OOP for a larger project.

As for inheritance, I think it's god sent. I am programming in OBJC for 1,5 years and I find the way the language is organized brilliant. It is strongly based on inheritance. Apple is using ObjC as the main language for the Cocoa environment, and one thing it's being praised for is that the resulting code is clear, efficient, and projects from other languages can be stripped down to 5 times fewer the lines of the original size. And inheritance contributes a lot to that.

OOP and every OOP feature have been created for a reason. Thinks became more complicated at one point, and the programmers needed something new. The fact that OOP is the leading concept in any big (and most small) project nowadays is not a matter of luck.

Oct 13th, 2007, 8:42 PM	#44
Arevos Programming Guru Join Date: Aug 2005 Location: England Posts: 1,499 Rep Power: 5	I still can't quite see why you object so strongly to inheritance, as in many situations it provides a much cleaner solution than the procedural approach. For instance, take the following code: python Syntax (Toggle Plain Text) class Player(object): def examine(self, name) item = self.find_item(name) item.on_examine(self) def take(self, name): item = self.find_item(name) item.on_take(self) def message(self, text): print text def kill(self, killer): self.message("You were killed by a " + killer) class Item: def __str__(self): return self.name def on_examine(self, player): player.message(self.description) def on_take(self, player): self.container.remove(self) player.inventory.append(self) class LiveGrenade(Item): name = "live grenade" description = "Look out! It's a live grenade!" def on_take(self, player): player.message("Kaboom! The grenade exploded when you picked it up!") player.kill(self) class Player(object): def examine(self, name) item = self.find_item(name) item.on_examine(self) def take(self, name): item = self.find_item(name) item.on_take(self) def message(self, text): print text def kill(self, killer): self.message("You were killed by a " + killer) class Item: def __str__(self): return self.name def on_examine(self, player): player.message(self.description) def on_take(self, player): self.container.remove(self) player.inventory.append(self) class LiveGrenade(Item): name = "live grenade" description = "Look out! It's a live grenade!" def on_take(self, player): player.message("Kaboom! The grenade exploded when you picked it up!") player.kill(self) The LiveGrenade class uses inheritance to override the on_take method. Indeed, the whole point of the OOP approach is that what a method actually does should be left up to the object. You're essentially just giving an object a message, and leaving the implementation up to it. If I wanted to modify the above code to support multiple players, that wouldn't be too hard, either. I could have Player.message send the message to a TCP socket, rather than to STDOUT. I could even leave out the definition of the message method altogether, and have subclasses inheriting from it for single and multiplayer modes. I'm curious as to how you'd write the above in a procedural style, and yet still retain the future flexibility that inheritance allows. For instance, let's say I wanted to have a squeaky toy: python Syntax (Toggle Plain Text) class SqueakyToy(Item): def on_take(self, player): player.message("It squeaks as you pick it up") Item.on_take(self, player) class SqueakyToy(Item): def on_take(self, player): player.message("It squeaks as you pick it up") Item.on_take(self, player) Or a gorgon head: python Syntax (Toggle Plain Text) class GorgonHead(Item): def on_examine(self, player): player.message("As you look at it, you turn to stone") player.kill(self) class GorgonHead(Item): def on_examine(self, player): player.message("As you look at it, you turn to stone") player.kill(self) I don't see how this makes the code any less maintainable. It seems to do quite the opposite, in fact!

Oct 18th, 2007, 8:59 AM	#45
Soulstorm Hobbyist Programmer Join Date: Jan 2006 Location: Menidi, Athens, Greece Posts: 243 Rep Power: 3	Re: Why OOP? Being much more inexperienced than possibly all of you, I didn't know that C++ is not to be taken as an example of OOP. However, allow me to disagree with Darkhack. At first, programming concepts in general require much thinking before adopting any of them. Not all programming concepts are suitable for every situation. In some cases, utilizing procedural programming is all that one needs to solve a specific problem, if the project is small. But I find it hard to imagine that one could not use OOP for a larger project. As for inheritance, I think it's god sent. I am programming in OBJC for 1,5 years and I find the way the language is organized brilliant. It is strongly based on inheritance. Apple is using ObjC as the main language for the Cocoa environment, and one thing it's being praised for is that the resulting code is clear, efficient, and projects from other languages can be stripped down to 5 times fewer the lines of the original size. And inheritance contributes a lot to that. OOP and every OOP feature have been created for a reason. Thinks became more complicated at one point, and the programmers needed something new. The fact that OOP is the leading concept in any big (and most small) project nowadays is not a matter of luck. __________________ Project::Soulstorm (personal homepage)

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Learning old languages	Wizard1988	Coder's Corner Lounge	26	Sep 16th, 2007 10:10 PM
OOP design question	rwm	C++	7	May 28th, 2007 2:46 AM

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Programming Forums > Script Programming > Python

Why OOP?