|
|
Re: Designing Contracts and Interfaces
|
Posted: Jan 5, 2003 6:35 PM
|
|
> Here's an excerpt:
>
> Minimal and complete applies to the member functions.
> In that particular item, I'm talking about what you make
> member functions. I advocate that you determine what
> should be a member function by shooting for the minimal
> complete set.
>
> However, you will probably want to offer clients a greater
> degree of functionality. I will call this greater degree
> of functionality, which includes all the member functions
> plus whatever non-member functions you provide for
> convenience, "the interface to the class," because that is
> the set of functionality you are offering them. When
> you're shooting for the sweet spot, you really want a
> class that has a convenient interface.
>
> What do you think of Scott's comments? In particular, how
> do you go about deciding what functionality to offer in an
> interface, and what not to?
I agree with his comments, but I've always done that quite naturally. I only started OO programming after I had completely read Rumbaugh et al., and also Booch. Perhaps this is the reason it appears natural to me. These guys insisted on these principles too. I'm not sure what is so special about Scott Meyers' contribution on that topic.
The whole time he talked about a "class that has a convenient interface", I had the well known "utility class" concept in mind. And again, it's nothing new: Rumbaugh et al., and also Booch discussed and justified that concept a long time ago, if I remember well.
I don't mean to criticize Scott, he answered very well the questions that were asked.
|
|
Previous Topic
