A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I came across the following link, while I was looking for somethine else, which has a chapter from the book:
The section 'Choosing between class and interface' was good. It tells everything one should have come across if one tried to make the choice. The example was clear and there are comments from different people, which makes the ideas much easier to understand.
The book is about the .NET Framework but it sounds like a good book on design in general.
Is it really that good? I found it a few weeks ago and at first thought it looked really good (from the TOC). Then I started reading the author's blog and watched his ~2hr video, and it was plain annoying. Reading the bits on Amazon makes me think its really dry, and the do-don't style gets old fast. Maybe if it was in the Effective C++/Java style I'd like it...
(Note, I'm a Java dev. but I'll read anything if its good)
Sunday, April 15, 2007
It's an excellent book but it's not designed for reading front to back. They don't present entertaining puzzles like in Effective C++, that's not their goal. Browse the subjects and read the discussion on whatever you're interested in.
Sunday, April 15, 2007
Manes - I didn't like the video either. It was quite slow. You could get something faster out of the book. Like Chris says, may be it's not something you read cover to cover. The comments are good, which are even from people other than the authors. They are informal and it's like a friend who knows what he's worked on telling you about it.
A couple of comments from the sample chapter:
KRZYSZTOF CWALINA Over the course of the three versions of the .NET Framework, I have talked about this guideline with quite a few developers on our team. Many of them, including those who initially disagreed with the guideline, have said that they regret having shipped some API as an interface. I have not heard of even one case in which somebody regretted that they shipped a class.
JEFFREY RICHTER I agree with Krzysztof in general. However, you do need to think about some other things. There are some special base classes, such as MarshalByRefObject. If your library type provides an abstract base class that isn’t itself derived from MarshalByRefObject, then types that derive from your abstract base class cannot live in a different AppDomain. My recommendation to people is this: Define an interface first and then define an abstract base class that implements the interface. Use the interface to communicate to the object and let end-user developers decide for themselves whether they can just define their own type based on your abstract base class (for convenience) or define their own type based on whatever base class they desire and implement the interface (for flexibility). A good example of this is the IComponent interface and the Component base class that implements IComponent.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz