Artima.com has published Part II of an interview with Scott Meyers in which he discusses interface contracts, private data, and designing minimal and complete interfaces.---xj40dkcfea73---Artima.com has published Part II of an interview with Scott Meyers in which he discusses interface contracts, private data, and designing minimal and complete interfaces.

http://www.artima.com/intv/mincomp.html

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?

>Bill Venners: One guideline in Effective C++ is, "Strive for
>interfaces that are minimal and complete." How do you know
>when an interface is complete? How do you determine what to
>leave in and what to leave out?

I haven't read Effective C++ before, can anyone give me more background about minimal and complete interfaces?

I think it was pretty well covered in the article, but the discussion stemmed from Item 18 in the book Effective C++, "Strive for class interfaces that are complete and minimal." You can find his books at http://www.aristeia.com/books_frames.html or at a bookstore.

I would have liked it if Bill had asked what specific suggestions Scott would have to make a class like JFrame (or any of its superclasses for that matter), or MFC's CWnd more minimal, yet still complete. I didn't count, but I'd guess both of these examples tally up more than a couple hundred methods.

> 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.