It's quite hefty, and not easy to read from cover to cover. However, there's a lot in here worth reading. The material on "design by He has led the development of successful O-O products and libraries totaling thousands of classes. Object-oriented Software Construction. Bertrand Meyer. Criteria of object orientation. The road to object orientation.
Object-Oriented Software Construction, 2nd Edition
Software quality. Who warped it into this? The argument here is that top-down design focuses too much on the order of the steps in a process. With O-O we should instead focus on the objects and come up with as many operations as we can for each. But without a top-level process consisting of steps executed in a certain order, how do we have any idea what sort of operations our objects need? Yeah, well, you're going to have ordering problems in that case, and I don't care how O-O you are. Meyer's presentation is deficient in two ways here. First, his O-O solution to having a bad spec is based on a good spec!
Well, duh, anyone can fix the problem easily with a good spec in the first place. Second, he doesn't present the case where a spec is deficient in the object department. Oh, we forgot to tell you, we want a spell checker in our word processor. I'm sure Meyer wants us to believe that O-O is better from this example, however the lesson to be learned here is to make sure you understand all the possible permutations of process ordering.
And, a good spec makes life a lot easier. I need to look up the page number. Here we have the foundation of this book: the argument that since the functions of a system are more likely to change than object types, it is better to design a system around object types classes. But experience seems to support it overwhelmingly. In the "pure" O-O system that Meyer envisions, there is no clear top, therefore there is no code that clearly describes the high-level functionality of the system.
Consequently, a request for a new function might end up touching many objects. In a top-down approach, only the high-level controller function would need to change to support a new function. This is what Meyer calls "Modular Continuity" a spec change has limited impact on the code. How does one make the jump from "objects are stable" to "designing a system around objects is best" anyway? If anything, this promotes fragmenting the functions in such a way that the things that change the most are the hardest to figure out.
Instead of basing an architecture on the things that change the least, why not base it on making it easy to change the things that change the most? One doesn't necessarily lead to the other. After all the arguing that bottom-up O-O is the only way to go, Meyer gives in and says that O-O requires a top main function , hope, and good luck.
He admits that O-O " may hold the key to reusability and extendibility.
Critique of OOSC2 by Bertrand Meyer
Although, the Meyer we will meet in Chapter 19 would want to eat this Meyer for lunch! What does he mean by "representation-independent descriptions" of types and objects he claims this is the key to abstraction? The "Key Concepts" section calls it "abstract descriptions of objects. Is he implying that by describing something in an abstract way we can get the proper level of abstraction? That doesn't sound right to me. This part needs some further explanation.
- Tapas Revolution: 120 Simple Classic Spanish Recipes.
- Catalan: A Comprehensive Grammar (Routledge Grammars).
- Account Options!
As it stands, it is unintelligible. Also note here the second time that top-down design is given credit for being good at abstraction. Boy, if he continues at this rate, he'll be back to top-down design before you know it. See Chapter That's exactly what happens. I have them and should read them eventually.
At this point, I have to mention that I keep getting this feeling that by ignoring the top and focusing on the objects, one might be tempted to implement more functionality than is necessary the "Shopping List" approach, page The top provides a framework of limitations for the system. Without limitations, we could be developing wonderful reusable components forever, and never actually finish the software.
In theory, information hiding should prevent changes in data format from affecting software outside of the class that contains the data. The classic example is the stack whose representation is changed from an array to a linked list. In practice, however, there are two kinds of data changes.
- OOSC2 - Object Oriented Software Construction, 2nd Edition (Bertrand Meyer book) | AcronymFinder.
- Object-Oriented Software Construction, 2nd Edition - Semantic Scholar.
- Product details.
- Object-Oriented Software Construction (Book/CD-ROM) / Edition 2.
The first is a change that can be hidden, such as the stack representation mentioned. The second is a change that cannot be hidden, like the adding of a new field to a database, or the expanding of the size of a data element. There are many more examples. I'm not sure that the Lientz and Swanson book [ ISBN: ] differentiated amongst these types of data format changes.
I would have to read it. The fact that Meyer leaves this detail out is suspicious. Although he does follow up with a discussion of limiting middle initials to one character.
Object-Oriented Construction Handbook
But there's no solution presented. What's the point in presenting a problem, claiming O-O holds the key, then never showing how? Here's why McConnell suggested this book to me. Eiffel has a very nice "selective export" feature covered in section 7. Here's the "top" I've been waiting for. A "root object" containing a "creation procedure". The programmer supplies this procedure to create all needed objects, connect them together, and get them started. Meyer insists the "root execution procedure" is not a "main" function because it should only create other objects and get them going. Also on this page, Meyer promises not to trash "top" any more.
Libraries need no top, but systems do. Again, Meyer insists that order of execution is not important.
Instead, he says the software developer is a "firework expert or perhaps arsonist" that "prepares a giant conflagration, This is pretty telling since O-O excels at simulation. After all, it comes from a language called "Simula" that was intended for simulation. O-O is great at modeling autonomous objects that interact with one another. O-O is also strong on reuse with its emphasis on classes as modules. But that doesn't mean we should use a hammer to drive a screw.
I think that for interactive programs, a pure O-O approach is inappropriate.
The behavior of such a system is potentially so interesting that it usually deserves an object of its own. But an object that contains only behavior is not an object at all. Ordering relations between the operations are inessential to the design. These are UIs that are graphical and allow manipulation of objects such as icons through drag-and-drop and other means. Is O-O really good here? His mention of simulation is obvious.
Also on this page, Direct Mapping property: objects in the software should map to objects in the real-world. I was hoping that Meyer would give examples and advice about finding these hard-to-find classes. However, by the end of the book, I found only vague advice pertaining to finding the classes in a system. External Objects real-world vs.
enter Software Objects. This starts to feel like a "top" then. For some applications, the complex organization of objects might be created by the user as a document. The more I read, the more I mellow as the book is definitely getting better. Although the controversy is still there, the good stuff is outweighing it. It might be that Meyer is overcompensating in this book. Perhaps the intent is to get the reader to see the value of O-O by hitting them over the head. Maybe Meyer assumes his audience is reluctant to change? In general, all his points have some merit. However, his evangelical tone is a turn-off to me.
I already understand everything he is saying. He's preaching to the choir in my case. One could interpret this evangelical approach as irresponsible.
His points should stand on their own without having to pretend to be controversial to get people's attention. The controversy could be misleading to the uninitiated. The book's tone might be good for those stuck on Structured Design who need convincing. However, even they might be quickly turned off.