After reading the article, it seems pretty pointless... how about just not call any function if it can''t do what you are thinking of? What you are really doing is this... making all of your objects call functions with about the same name, just to make code easier to read -- which it doesn''t do. It is confusing to see a function called that does nothing... why even have it? Your code will be less cluttered.
And the rockets' red glare, the bombs bursting in air,gave proof through the fight that our flag was still there.Oh say, does that star-spangled banner yet waveover the land of the free and the home of the brave?
True, but in large programs you need closed objects that manipulate thru common interface. The more objects you can close in a large codebase the less time you have to figure out where to insert a similar object or how to make it fit. If the codebase is spread out then there will be many places where you have to insert the right function calls and data. That gets tedious after a while. The downfall of common interface is that it''s too common So some objects will do nothing when invoked. If I have a object that manipulates shapes thru a common interface then no matter what future objects I come up with the object is closed w.r.t. the shapes it manipulates.
I suggest anyone that is interested in the subject go out and pick up Design Patterns - Elements of reusable object-oriented software by Gamma, Helm, Johnson, and Vlissides. The book is a refrence for anyone who claims to have any intrest in OO design principals.
quote:Original post by PlayGGY After reading the article, it seems pretty pointless... how about just not call any function if it can''t do what you are thinking of?
You are entirely missing the point. If you have a pointer to a Foo object, you shouldn''t have to check exactly which subclass of Foo the pointer points to. You should be able to send a message through that pointer and expect that it is being received by the object, even if it''s not acted upon. The null object saves you from having to check whether the pointer is null.
quote: It is confusing to see a function called that does nothing... why even have it?
But you can''t tell by looking at the call site whether the function called does something or not - thats the whole point of a virtual function. You don''t know exactly which function will be called - a function that does something or one that doesn''t.
Hard to comment without a specific example, but if I have derived classes that implement no-ops for base functions, I might think about refactoring the interface.
So some objects will do nothing when invoked. If I have a object that manipulates shapes thru a common interface then no matter what future objects I come up with the object is closed w.r.t. the shapes it manipulates.
