Re: Q: how do you generate get/set methods?
Re: Q: how do you generate get/set methods?
- Subject: Re: Q: how do you generate get/set methods?
- From: "Glen Low" <email@hidden>
- Date: Wed, 21 Jan 2004 00:32:27 -0500
>
Without wanting to act like a wet blanket, I would like to point out
>
that one of the foundation principles of object oriented programming is
>
'encapsulation'. This is the idea that one object should not know
>
about the internal state of another. This is a well established design
>
principle and is fundamentally important in writing large, well behaved
>
applications. For example, a driver of a vehicle is not, and probably
>
should not be appraised of every piece of information a modern engine
>
management system gathers.
I agree with most of what you say, however I think modern OO design is a little more subtle than "one object should not know about the internal state of another."
I often find I need to know some inner detail of a class, and provided the detail is not some artifact of the implementation (a design design) but a genuiene indicator of state, it should be valid for the class to provide it (as an accessor). Question the need for mutators more.
An object can have a certain number of legal states, depending on its data members. The job of the interface, the methods is to defend these legal states and ensure that no illegal state is entered into. It helps that the object doesn't expose its innards, but the primary thing is that you can't or shouldn't be able to change the object into something inconsistent.
Many C++ developers now adopt a "minimal interface" ethic, where you actually minimize the number of distinct methods in the interface, essentially to the ones that defend state. This means that methods that could be composed of one or more of the core methods should be thrown out of the interface, and made into globals (or perhaps in the ObjC case, categories). This means when it comes time to revise the object, less actually has to change. This actually encourages encapsulation, even though it may lead to an accessor/mutator interface.
Cheers,
Glen Low, Pixelglow Software
www.pixelglow.com
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.