Book: Objects, Components, and Frameworks with UML, Fedmond F. D`Souza

-

This is a book about Catalysis, an OO method­ol­ogy. I read this book some time ago (like years). It is a quite com­plex book. If you don’t like method­ol­o­gists, it will eas­ily put you to sleep. But if you stay awake, it is worth it.

It is strange how this book crys­tal­lized one con­cept for me: the de­f­i­n­i­tion of an in­ter­face. An in­ter­face is not just the sum of the sig­na­tures of the meth­ods. It is a con­cep­tual frame­work. The only way to fully de­scribe it is to de­scribe in a for­mal way this con­cep­tual frame­work. For ex­am­ple with­out fur­ther spec­i­fi­ca­tion it is im­pos­si­ble to know how to use this in­ter­face:

in­ter­face IBook() {

  void AddPage(IPage p);

}

What hap­pens when you add a page? Will it add it at the end of the book? At the start? What hap­pens if you call the method twice? Will the pages be in or­der? Will they be in the same sec­tion? Is there a con­cept of a sec­tion?

There are ways to make ex­plicit the im­plicit model be­yond an in­ter­face: the one that I’ve com­monly seen be­ing used is doc­u­men­ta­tion. The book ar­gues for for­mal con­tracts (preconditions, post­con­di­tions, in­vari­ants). The lat­ter is cer­tainly more for­mal, but to use it you need to de­scribe for­mally what is the state be­yond the in­ter­face and how the dif­fer­ent meth­ods af­fect this state. It is a lot of work.

Is it worth the ef­fort? I guess it de­pends on a zil­lion things like: the type of pro­ject, the peo­ple in­volved, I don’t think any­body is ac­tu­ally do­ing it, but it is still a good con­cep­tual frame­work to keep in mind when you de­fine your in­ter­faces: it is not enough to write down the sig­na­ture meth­ods, you have some­how to ex­pose the con­cep­tual frame­work (where some­how means more or less for­mally).

Tags

1 Comment

Comments