On Aug 27, 2008, at 1:50 PM, R.L. Grigg wrote:
This is interesting. Correct me if I'm wrong but as a newb what I'm
getting from all this is if I design my code around implementation
specifics of frameworks or even the language I'm using, that equates
to a unrobust design, cuz if the underlying implementation changes,
I'm screwed, whereas simpler, more bread-and-butter "textbook"
designs are much more likely to weather any underlying
implementation changes, sort of like keeping your design at a high
level and not dirtying it with low-level implementation specifics.
Is that a reasonable conclusion to draw?
The framework provides a contract as part of its public interface.
The contract specifies what responsibilities you have and what
responsibilities the framework has. Turning that around, the
framework has the right to expect you to uphold your responsibilities
and you have the right to expect the framework to uphold its
responsibilities. Neither of you have the right to expect more than
what's in the contract.
In other words, you should pay no attention to the implementation
details, which are defined as those things which aren't specified in
the contract.
The framework designers try to keep their declared responsibilities as
unrestrictive on them as is reasonable, given that they want to
provide a useful framework. The freedom that this gives them allows
them to alter the implementation details, perhaps to improve
performance or enable new features, but also perhaps just to make life
easier for them, speeding development of the framework.
Cheers,
Ken
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
