Customer Reviews

Interface Oriented Design: With Patterns (Pragmatic Programmers)

5 star:		(4)
4 star:		(4)
3 star:		(2)
2 star:		(0)
1 star:		(1)

 

 

I've been very pleased with Interface Oriented Design by Ken Pugh. Not only does it cover it's stated topic well, but it is also refreshing in two ways: one, at 215 pages it is just the right size for someone who needs an overview of the interface-oriented approach; and two, it operates at a level of abstraction that is paradigm-agnostic and time-proof. This book will be useful and relevant ten or fifteen years from now with only a few minor tweaks in future editions to keep up with the times.

As example of the book's "paradigm-agnostic" approach, while the author does stay fairly rooted in the world of object- and component-oriented development (especially in certain chapters where objects, components, and/or services are explicitly assumed), he is careful to craft the discussion such that it is equally applicable to someone writing a set of web services in Java, a command line utility in C, or a stored procedure in PL/SQL. In doing so, he helps the reader see the commonalites across a variety of situations and approaches. It would have been difficult to achieve this if the author had elected to operate at a lower level of abstraction, diving into detailed code examples right away.

What one reviewer sees as "toy examples" I see as a very successful technique to explain a set of software design principles and techniques without getting caught up in language, platform, and other implementation details. And I do think that the author balances out his less realistic examples by following them up with real-world code and examples. Once the reader has absorbed the principle, he or she can see it at work in a more realistic example. This is a common teaching technique, and I think a very effective one. The author applies it successfully and consistently, both within each chapter and in the overall organization of the book.

It is unfair to say this book does not have realistic examples. The chapters throughout the book discuss both realistic fictional examples (such as an imagined XML pull-parser) and actual real-world examples (such as the refactoring of java.io.inputStream in Chapter 5). What's more, Part III, "Interfaces in the Real World," contains three chapters that each walk through a realistic interface-oriented design, from requirements, through a discussion of design trade-offs, to implementation and testing.

I also don't think it's fair to suggest, as one reviewer does, that this book could be condensed to just two pages. You could say that of just about any book, but more to the point, what I really hear this reviewer saying is, "If you are already an expert in the interface-related topics covered in this book, then it may be too basic for you."

Even if I agreed that the book could be effectively reduced to two pages, thereby removing the need to read it, at most I could see this being true for potential readers who are already experts. If you take a look at the table of contents of this book and consider yourself an expert already in all of the topics covered, then by all means you might prefer a different book. But I still say you'd be missing out.

As for the rest of us, there's a lot to be learned from this book. I started out as a pretty sophisticated reader in this topic area, but I have no doubt I learned from this book and that it will influence in subtle ways my own future software designs. For readers who are unfamiliar with an interface-oriented approach, this book is a great introduction. After you're done with it, you can jump back into that 500 page Java or C# book with a fresh perspective.

This wide-but-not-deep, somewhat abstract approach will no doubt turn off some readers, which is as it should be. It's not a one-size-fits-all world. Some readers might prefer a 400-600 page book with full code for multiple projects, detailed technical discussions, exhaustive consideration of various scenarios, and reference material. Ken Pugh could have written a book more like that, but I'm glad he didn't. I prefer the book we have.

Whether you like this book has probably more to do with your own personal needs, expectations, and stylistic preferences and less to do with whether or not this book is "full of rubbish," which it decidedly is not. The world of software development needs more books like this.

Too many beginning developers learning object oriented programming dive right into implementation and don't think about interfaces -- and interfaces are what OO is really all about.

This book is a good introduction to designing and thinking about interfaces. It touches on these topics and more, with examples...

The Three Laws of Interfaces:

1. An Interface's Implementation Shall Do What Its Methods Says It Does. (Principle of Least Surprises.)

2. An Interface Implementation Shall Do No Harm.
(implementation should use only those resources suggested
by its interface.)

3. If An Implementation Is Unable to Perform Its
Responsibilities, It Shall Notify Its Caller.
(an error return code or an exception.)

Data interfaces and Service interfaces. Stateless versus Stateful. Cohesion, Coupling, Inheritance, Polymorphism, etc.

This book is succinct, aimed at the novice, tends to be high-level. The reader would be advised to follow up the links and references in the text for more in-depth examples and discussions.

Are you a developer who has some experience with programming and who has been exposed to object-oriented design? If you are, then this book is for you. Author Ken Pugh, has done an outstanding job of writing a book that explores how developing software with an emphasis on interfaces helps you build robust systems easier and faster.

Pugh, begins by looking at some code and textual interfaces. Then, the author looks at how the Three Laws of Interfaces applies to implementations. Next, he explores how to transform an interface from one facet to another. He also looks at different sets of interfaces to explore the concept of cohesiveness. The author then investigates better ways to organize designs using interfaces and delegation. Then, he looks at the ramifications of using remote interfaces. The author continues by showing you how to develop a mini project. Then, he explores interface cohesiveness and generalization. Next, he develops a service registry to explore how directory services work. Finally, the author divides patterns into two camps: class-based and object-based.

In this most excellent book, you'll find techniques for breaking down solutions into interacting interfaces. Perhaps more importantly, this book is all about determining appropriate implementations to create well-structured programs.

This book discusses and encourages thinking about object oriented design in terms of interfaces, i.e. the high-level "tasks" that an object offers to carry out for you, rather than thinking about implementation details. Examples are given in a mixture of languages (not all OO), with the majority in the Java-like notation Pugh used in his previous book, Prefactoring. There are three parts to the book. The first part, which takes up the first half of the book, introduces interfaces and discusses them in the context of contracts, stateless versus stateful, and the interplay of inheritance and interfaces. The second part consists of one chapter on an agile development process, which discusses use cases and CRC cards (here redubbed Interface Responsibility Interaction cards). The third part covers three examples, and then a final chapter on design patterns.

The author suggests that the target audience for this book are those developers who have been "exposed to object-oriented design". However, I find it hard to believe that a beginner programmer will not have been introduced to the main thrust of the discussion in any introductory book on Java. An intermediate developer will have much of this material covered in a book on Design Patterns, or in any book that discusses the maxim 'favour composition over inheritance'.

My problem with this book is that while a fairly large number of topics are covered, it's all very superficial. Advantages and disadvantages of various approaches are summarised, but they're not very helpful, e.g. an advantage of a stateless interface is "order of the method calls does not matter", versus a stateful interface: "parameter lists shorter". Of course, these are not intended as a replacement for the main discussion in the text, but the likes of Joshua Bloch in 'Effective Java' or Scott Meyers in 'Effective C++' were able to distill object oriented wisdom more usefully.

Like Prefactoring, there are snippets of interest here and there. If you know nothing of Contract Programming, or web services, for example, you may find the descriptions useful, albeit very cursory. However, most readers are probably more interested in what Pugh can say about taking an interface-centric view of object orientation, and what it can add to their own designs. Unfortunately, like Prefactoring, I found little insight here. Despite there being three worked examples, the example code itself is intentionally simplistic, leaving only the design and analysis aspects. This is all too brief, jumping from use case to to CRC cards and finished interfaces in one bound. Surely the most valuable part of the analysis, the actual *process* of coming up with the design, with its attendant blind alleys, false starts and mistakes, is missing.

Like many Pragmatic Programmers books, this is a quick read (I read it in one sitting on a train journey). However, like some other Pragmatic Programmers books, I did not feel that it represented stellar value for money. If you didn't like Prefactoring, I'd steer clear of this one.

This is a lucid explanation of very complex concepts involved in systematic design using interfaces. Chapter 2 on interface contracts was a revelation! We design interfaces and implement them, but what are the expectations between interfaces and their implementation? What covert contracts have to exist between them? As a developer exploring the OOP features of ActionScript 3.0, I really appreciated this book -- don't just use interfaces, figure out why you should use them and how they should be implemented. I had no issues with following the snippets of code, even though there were examples in multiple languages, as the functionality was explained at length. I highly recommend this to any developer, exploring the *why* of OO development irrespective what language they use.

Very helpful introduction to Interface design. Examples are in C# but easily understandable by a VB programmer.

Including the appendix, the book is just over 200 pages. This makes it one of the shorter books I have on software design. It's also one of the most readable. The content of the book does a good job covering the subject matter. He compares and contrasts interface-based composition with inheritance, stateful vs stateless interfaces, translation between stateful and stateless interfaces, and a whole host of other relevant topics. Some of the more interesting points in the book were: interfaces as object roles, fluent interfaces, procedural vs document-based interfaces, and a small introduction to some of the commonly used GoF patterns. The topics on document-based interfaces were particularly relevant to my current project and his ability to sneak some SOA material in the appendix (and one of the examples) was also welcome.

[...]

When doing object-oriented programming, it's normal to dive right in to classes, methods, and properties. In Interface-Oriented Design by Ken Pugh, the reader is presented with the premise that the interface should drive the design. This book will make you pay a bit more attention to that area if you've overlooked it in the past...

Contents:
Part 1 - All About Interfaces: Introduction to Interfaces; Interface Contracts; Interface Ingredients; What Should Be in an Interface?; Inheritance and Interfaces; Remote Interfaces
Part 2 - Developing with Interfaces: A Little Process
Part 3 - Interfaces in the Real World: Link Checker; Web Conglomerator; Service Registry; Patterns
Appendix; Index

If you're building discrete chunks of code that can be combined with other objects to build applications, it makes a lot of sense to focus on the interface that you present to the world for your object. With Service Oriented Architecture becoming the next buzzword, interfaces take on even more importance. Pugh uses a "pizza ordering" example throughout the book to show how the interface to that service would be designed to take into account all the contracts that interfaces should abide by. In fact, I think the Interface Contracts chapter was the most useful for me, as the rules are logical and appropriate for designing solid objects. I also found the Inheritance and Interfaces chapter very useful, as it compared and contrasted the use of inheritance in your class vs. the use of interfaces. It's common to see inheritance examples in books, but the interface examples are not as widely covered, and that's too bad. After reading this chapter, I understood why interfaces offer so much flexibility to programming.

Some of the detailed code areas of the book are a little hard to follow, and as such it was one of those books I had to put down and come back to a few times before I worked my way through it all. Still, there's more than enough material here to twist your thought processes around to a new way of looking at your design skills.

One of my big issues with programing, being a SA, is that when I come to a large problem I see the beginning and the end but the middle is just not there. This book showed me a reasonable way to map out that middle. I am not saying it is the only way to do things but if you follow the process you have a good chance at getting to the result you want.

Other books from pragmatic programmers have a skill range indicated on them. If this book had one, it would be more towards the beginner than the expert. I was hoping for some new insite into OOP and interfaces, instead it was mostly a review.

Having said that, it does a good job of explaining the topics it covers. Anyone who hasn't spent years writing OO software would benefit from it.