- Local time
- Today, 00:30
- Joined
- Jul 9, 2003
- Messages
- 17,637
Goodbye, Object Oriented Programming
- Thread starter Uncle Gizmo
- Start date
stopher
AWF VIP
- Local time
- Today, 00:30
- Joined
- Feb 1, 2006
- Messages
- 2,395
Yes, an interesting article.
I'm an amateur programmer so probably a bit naive as to the wider implications of particular paradigms. However, here's my views:
Inheritance
The writer sites the virtue of inheritance as "reuse" i.e. I'll take this code and use it elsewhere. But that's not the purpose of inheritance at all (or OOP as a whole). Inheritance is intended to reduce repetition of code by moving repeated code up the hierarchy. So if I find myself writing several classes with the same properties and methods then there may be a case for a parent class and inheritance. If you think of the standalone class a neat way to reuse code then you are missing the point. If you've designed a hierarchy of classes and then decide it's a chore to have to understand what has to be copied, then either the original design was wrong, or your view of the value of the design is short sighted. Besides, the problem of ensuring all references are available isn't just an OOP problem, it's prevalent in many paradigms. How often have we just tried to use a function to find missing libraries or other functions.
The solution the writer gives to inheritance is just common sense. The moral is if you get carried away with inheritance then you'll get in a mess. A great example of where he gets carried away here is the sock/drawer example. He is trying to use Inheritance to solve a containment hierarchy problem. There are plenty of container variable types for doing just this.
In the Diamond Problem he sites a very specific modelling case (much like the problem of image cataloging). You don't solve this with a class hierarchy. If you think inheritance is the way to solve this then you've missed the moral from the previous section. Classes are a very good way of maintaining the same information in multiple ways. So lets say I have a class of a collection of image links. In the same class I might also have a list of tags and pointers to image links. When someone updates a picture image through the class's interface, the tags are also updated. The works very well because of Encapsulation!
As one commenter noted, it's easy to get complicated with OOP when good functional programming will do. In other words, use OOP appropriately - don't turn code into an OOP nightmare because you think you have to have a class for everything. Another commenter suggests that his examples are not OOP problems but just bad design - I agree.
Encapsulation
I actually like the fact that objects are passed by reference. This is a big virtue. But encapsulation is really about providing an interface to objects and protecting the private contents of the objects. This is a virtue and little to do with how objects are passed.
I accept cloning takes some effort and perhaps dedicated code - but hardly a deal breaker. We have to remember that an object may be holding a great many attributes of different types. What's the alternative to this in other paradigms?
Polymorphism
He doesn't explain what the problem is with polymorhphism. He says polymorphism is good. So what's the problem?
I'm sure OOP does have shortcomings. But I'm not convinced about the points in the article.
I'm an amateur programmer so probably a bit naive as to the wider implications of particular paradigms. However, here's my views:
Inheritance
The writer sites the virtue of inheritance as "reuse" i.e. I'll take this code and use it elsewhere. But that's not the purpose of inheritance at all (or OOP as a whole). Inheritance is intended to reduce repetition of code by moving repeated code up the hierarchy. So if I find myself writing several classes with the same properties and methods then there may be a case for a parent class and inheritance. If you think of the standalone class a neat way to reuse code then you are missing the point. If you've designed a hierarchy of classes and then decide it's a chore to have to understand what has to be copied, then either the original design was wrong, or your view of the value of the design is short sighted. Besides, the problem of ensuring all references are available isn't just an OOP problem, it's prevalent in many paradigms. How often have we just tried to use a function to find missing libraries or other functions.
The solution the writer gives to inheritance is just common sense. The moral is if you get carried away with inheritance then you'll get in a mess. A great example of where he gets carried away here is the sock/drawer example. He is trying to use Inheritance to solve a containment hierarchy problem. There are plenty of container variable types for doing just this.
In the Diamond Problem he sites a very specific modelling case (much like the problem of image cataloging). You don't solve this with a class hierarchy. If you think inheritance is the way to solve this then you've missed the moral from the previous section. Classes are a very good way of maintaining the same information in multiple ways. So lets say I have a class of a collection of image links. In the same class I might also have a list of tags and pointers to image links. When someone updates a picture image through the class's interface, the tags are also updated. The works very well because of Encapsulation!
As one commenter noted, it's easy to get complicated with OOP when good functional programming will do. In other words, use OOP appropriately - don't turn code into an OOP nightmare because you think you have to have a class for everything. Another commenter suggests that his examples are not OOP problems but just bad design - I agree.
Encapsulation
I actually like the fact that objects are passed by reference. This is a big virtue. But encapsulation is really about providing an interface to objects and protecting the private contents of the objects. This is a virtue and little to do with how objects are passed.
I accept cloning takes some effort and perhaps dedicated code - but hardly a deal breaker. We have to remember that an object may be holding a great many attributes of different types. What's the alternative to this in other paradigms?
Polymorphism
He doesn't explain what the problem is with polymorhphism. He says polymorphism is good. So what's the problem?
I'm sure OOP does have shortcomings. But I'm not convinced about the points in the article.
- Local time
- Yesterday, 19:30
- Joined
- Jan 23, 2006
- Messages
- 15,583
I also think it was an interesting article --very good read. I always like to read articles and commentary where there are differing thoughts/ideas/facts. I don't have enough experience with OOP to understand the finer points (design vs fundamental concepts). But it's interesting to read thoughts from people/developers/programmers who have many years experience and see different arguments/points on concepts and practices. Suffice to say it is an interesting (thought provoking article), but not sufficient to deter me from learning/doing more with OOP.
Thanks Tony for the link.
Thanks Tony for the link.
- Local time
- Yesterday, 18:30
- Joined
- Feb 28, 2001
- Messages
- 30,866
I took the trouble to reply to the author under another account name to chastise him for making a very false assumption regarding OOP. See if you can guess which reply was mine.
