You're defining things that are primarily data holders (like C structs). Your ideas look like they'd be good for making data holders, if that's what's important to you. This is occasionally useful, but for most people OO is about behavior: your program works because there are a bunch of objects collaborating to do the work. The responsibility for various actions is partitioned between the objects.
So what is the behavior of an object that just holds data? When we're describing its responsibility, we use terms like "holds", "remembers", "knows", etc. These terms are an indication that we've got something that is more an attribute -- a (possibly composite) data item -- than a real object with its own behavior.
One important question to answer is: what happens to my interface when I change my implementation?. If your public interface is all behavioral, it doesn't matter how (or if) you encode your object's state (data). But if you expose every field, you've tied your interface to your implementation. This causes brittleness.
Perhaps part of the problem with this kind of thinking is all the "OO" tutorials that use the same tired "Employee" and "Manager" or "BankAccount" and "Customer" examples. These are more a case of warmed-over database records than objects with real behavior, generally speaking. But then many of the people who wrote those spent too long thinking about databases.
Anyway, thanks for suggesting this; you should probably look at Class::Struct, which does much the same thing.
In reply to Re: Idea on a Base class API
by bikeNomad
in thread Idea on a Base class API
by dragonchild
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |