Packaging Data And Methods
While studying OO at university, it was drilled into me that I should "package data with the methods that operate on that data".
In recent years I have come to wonder why so much emphasis is placed on this concept.
For example, most 3D Vector classes I have encountered look something like:
public 3DVector Normalize();
This appears well organised.. Various methods that act on a 3D vector nicely packaged up together. I'm guessing most OO programmers would generally approach class design in this way.
But at the same time, its very hard for multiple vendors to add their own functionality to the class, they are forced to collaborate and merge their methods into the "current version".
In this instance, would it not be more sensible to have something like:
class 3DVector // Agreed, Never going to change
---- Vendor (1)
3DVector Vendor1_3DVector_Normalize (3DVector v)
---- Vendor (2)
3DVector Vendor2_3DVector_Cross (3DVector a, 3DVector b)
Then as a vendor, you are able to release new functions as and when you please.
As an application developer, you are free to pick and choose those functions that fit your requirements, or add your own.
The vendors would have to collaborate on the initial "Data Format" of a class, but once settled, an eco-system of functions would build up that operate on it.
I realise this is a simplistic example, and can see it would be hard to extend the idea to more complex objects with state. But I was curious whether there are any real-world OO systems that leverage this sort of thing, and how far they take it?
Active forum topics
New forum topics