What do you think?
Rate this book
Program Development in Java: Abstraction, Specification, and Object-Oriented Design
Written by a world-renowned expert on programming methodology, and the winner of the 2008 Turing Award, this book shows how to build production-quality programs--programs that are reliable, easy to maintain, and quick to modify. Its emphasis is on modular program how to get the modules right and how to organize a program as a collection of modules. The book presents a methodology effective for either an individual programmer, who may be writing a small program or a single module in a larger one; or a software engineer, who may be part of a team developing a complex program comprised of many modules. Both audiences will acquire a solid foundation for object-oriented program design and component-based software development from this methodology. Because each module in a program corresponds to an abstraction, such as a collection of documents or a routine to search the collection for documents of interest, the book first explains the kinds of abstractions most useful to procedures; iteration abstractions; and, most critically, data abstractions. Indeed, the author treats data abstraction as the central paradigm in object-oriented program design and implementation. The author also shows, with numerous examples, how to develop informal specifications that define these abstractions--specifications that describe what the modules do--and then discusses how to implement the modules so that they do what they are supposed to do with acceptable performance. Other topics discussed The Java programming language is used for the book's examples. However, the techniques presented are language independent, and an introduction to key Java concepts is included for programmers who may not be familiar with the language.
- GenresProgramming
443 pages, Hardcover
First published June 6, 2000
17 people are currently reading
91 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 5 of 5 reviews
July 11, 2014
This is a thoughtful book written by two leading researchers and academicians, Turing-award winner Barbara Liskov, whose previous work included the development of, what was for its time, an innovative programming language (CLU) which integrated data and operations into parametrizable clusters, and John Guttag, who at the time was a leading researcher into algebraic specifications of abstract data types.
The authors write carefully about some key issues in the paradigm shift entailed from shifting from purely procedural programming to object-oriented programming, bolstered by use of semi-formal specification methods (that is, specifications are written in English with occasional but light forays into first-order logic) to help provide a disciplined approach to developing more robust programs. For Liskov and Guttag, the key to such development is the correct use of five key abstractions: procedural abstraction, data abstraction, iteration abstraction , type hierarchy and polymorphic abstraction, all of which have some measure of support in Java.
Procedural abstraction consists in first focusing on object methods as mathematical partial functions mapping inputs into outputs. Since they are partial functions, it is important to specify their exact domains and the relationship that holds between outputs and inputs. A requires clause specifies preconditions that must be satisfied by the inputs to a method in order to guarantee that an effects clause specifying a postcondition holds on the corresponding output. In order to develop more robust programs, the authors recommend that these partial functions be totalized by, in general, throwing exceptions when the input lies outside the original function´s domain. In short, the authors meticulously look into the use of exceptions as a defensive programming technique, taking time to present Java´s Throwable class hierarchy distinguishing between unchecked and checked exceptions.
Data abstractions consist of abstract data types, a class invariant is added to the preconditions and postconditions of the class methods and careful attention is paid to showing how the class as a data abstraction representation satisfies the abstract data type specification. A number of important issues on "benevolent" side effects, object mutability, operation (method) categories and locality and modifiability are also dealt with.
Nowadays, the chapter on iteration abstractions while well done, simply does not appear at the same level of importance as the rest of the abstractions. However I vividly recall how this idea struck me as strikingly original at the time of writing -perhaps the change is more a measure of how commonplace and mainstream the idea has become.
Perhaps the lasting key original contribution of the book is in section 7.8 which deals with the meaning of subtypes. While the mechanisms of object-oriented programming languages like Java, allow class methods to be overwritten or added in a subclass in a very liberal fashion, Guttag and Liskov develop the idea of a more restrictive subclass substitution principle based on two rules (the methods rule and the properties rule) that lie at the heart of a more disciplined and safer use of subclassing. This principle has been extensively endorsed by practitioners and academicians alike.
Finally the chapter on polymorphic abstraction does a fine job of showing how Java´s mechanism can implement an interesting subset of this kind of abstraction.
Since the book is based on the use of specifications, it is only fitting that a chapter (chapter nine) should be devoted to what constitute good specifications. The authors clearly explain the most important trade-offs involved between restrictiveness, generality and clarity.
The rest of the book proceeds to show how the previous ideas can be used to advantage in such typical software engineering activities as testing and debugging, requirements analysis and specifications, and design. There are some great insights in some of these chapters; for example I like how Liskov and Guttag link their ideas to cohesion and coupling design principles -though the reader should be warned that their (reasonable) terminology is non-standard- and particularly how they show how initial, requirements-level class models evolve and change during the design process. Two recurring case studies, one on a polynomial abstraction which eventually includes hidden dense and sparse representations, and the other on developing a search engine are worth studying in detail. The reader should be warned that Liskov and Guttag use notations for class and class-dependency diagrams, which have been superseded by clearer UML notations.
The book´s final chapter looks at design patterns. As an introduction to the topic, I found the chapter, unfortunately rather confusing, especially in comparison with the classic (and older) Gamma, Helm, Johnson and Vlissides Design Patterns book (1995) and with the much more recent and cheeky Head First Design Patterns(2004) by Eric Freeman, Elisabeth Robson, Bert Bates and Kathy Sierra. However, Liskov and Guttag point out interesting relationships between such design patterns as Adapter, Decorator and Proxy. The application of these patterns to the case studies mentioned above is invaluable.
Curiously, this book contains no references or bibliography. While a case might be made for providing a book on topics such as these with no distracting references, the lack of at least some "further readings" sections is, in my opinion, to be strongly deplored.
In spite of its age, I would strongly urge teachers searching for a book on which to base a course on topics on Software Development Methods as described in the ACM, IEEE Computer Society and AIS 2013 curriculum recommendations, that bridges fundamental algorithms and data structure, and software engineering to consider this book. As in many MIT textbooks, it occasionally gets ahead of itself and references material which most students will understand only later on (when they learn more about compiling fundamentals, for example), but it definely provides a disciplined framework for reflection that ought to distinguish the professional software engineer or computer scientist from the amateur programmer. I would also recommend this book to practitioners as a healthy reminder of the kind of approach that should not be thrown away in order to deal with the urgency of many real-life development situations.
The authors write carefully about some key issues in the paradigm shift entailed from shifting from purely procedural programming to object-oriented programming, bolstered by use of semi-formal specification methods (that is, specifications are written in English with occasional but light forays into first-order logic) to help provide a disciplined approach to developing more robust programs. For Liskov and Guttag, the key to such development is the correct use of five key abstractions: procedural abstraction, data abstraction, iteration abstraction , type hierarchy and polymorphic abstraction, all of which have some measure of support in Java.
Procedural abstraction consists in first focusing on object methods as mathematical partial functions mapping inputs into outputs. Since they are partial functions, it is important to specify their exact domains and the relationship that holds between outputs and inputs. A requires clause specifies preconditions that must be satisfied by the inputs to a method in order to guarantee that an effects clause specifying a postcondition holds on the corresponding output. In order to develop more robust programs, the authors recommend that these partial functions be totalized by, in general, throwing exceptions when the input lies outside the original function´s domain. In short, the authors meticulously look into the use of exceptions as a defensive programming technique, taking time to present Java´s Throwable class hierarchy distinguishing between unchecked and checked exceptions.
Data abstractions consist of abstract data types, a class invariant is added to the preconditions and postconditions of the class methods and careful attention is paid to showing how the class as a data abstraction representation satisfies the abstract data type specification. A number of important issues on "benevolent" side effects, object mutability, operation (method) categories and locality and modifiability are also dealt with.
Nowadays, the chapter on iteration abstractions while well done, simply does not appear at the same level of importance as the rest of the abstractions. However I vividly recall how this idea struck me as strikingly original at the time of writing -perhaps the change is more a measure of how commonplace and mainstream the idea has become.
Perhaps the lasting key original contribution of the book is in section 7.8 which deals with the meaning of subtypes. While the mechanisms of object-oriented programming languages like Java, allow class methods to be overwritten or added in a subclass in a very liberal fashion, Guttag and Liskov develop the idea of a more restrictive subclass substitution principle based on two rules (the methods rule and the properties rule) that lie at the heart of a more disciplined and safer use of subclassing. This principle has been extensively endorsed by practitioners and academicians alike.
Finally the chapter on polymorphic abstraction does a fine job of showing how Java´s mechanism can implement an interesting subset of this kind of abstraction.
Since the book is based on the use of specifications, it is only fitting that a chapter (chapter nine) should be devoted to what constitute good specifications. The authors clearly explain the most important trade-offs involved between restrictiveness, generality and clarity.
The rest of the book proceeds to show how the previous ideas can be used to advantage in such typical software engineering activities as testing and debugging, requirements analysis and specifications, and design. There are some great insights in some of these chapters; for example I like how Liskov and Guttag link their ideas to cohesion and coupling design principles -though the reader should be warned that their (reasonable) terminology is non-standard- and particularly how they show how initial, requirements-level class models evolve and change during the design process. Two recurring case studies, one on a polynomial abstraction which eventually includes hidden dense and sparse representations, and the other on developing a search engine are worth studying in detail. The reader should be warned that Liskov and Guttag use notations for class and class-dependency diagrams, which have been superseded by clearer UML notations.
The book´s final chapter looks at design patterns. As an introduction to the topic, I found the chapter, unfortunately rather confusing, especially in comparison with the classic (and older) Gamma, Helm, Johnson and Vlissides Design Patterns book (1995) and with the much more recent and cheeky Head First Design Patterns(2004) by Eric Freeman, Elisabeth Robson, Bert Bates and Kathy Sierra. However, Liskov and Guttag point out interesting relationships between such design patterns as Adapter, Decorator and Proxy. The application of these patterns to the case studies mentioned above is invaluable.
Curiously, this book contains no references or bibliography. While a case might be made for providing a book on topics such as these with no distracting references, the lack of at least some "further readings" sections is, in my opinion, to be strongly deplored.
In spite of its age, I would strongly urge teachers searching for a book on which to base a course on topics on Software Development Methods as described in the ACM, IEEE Computer Society and AIS 2013 curriculum recommendations, that bridges fundamental algorithms and data structure, and software engineering to consider this book. As in many MIT textbooks, it occasionally gets ahead of itself and references material which most students will understand only later on (when they learn more about compiling fundamentals, for example), but it definely provides a disciplined framework for reflection that ought to distinguish the professional software engineer or computer scientist from the amateur programmer. I would also recommend this book to practitioners as a healthy reminder of the kind of approach that should not be thrown away in order to deal with the urgency of many real-life development situations.
July 10, 2014
This is an interesting book overall. I think the authors made a mistake by putting JAVA in the title. As this book really have very little to do with JAVA. And the writing style is largely different from the language reference kinds of books that have the language names in the titles.
This book is about design methodology using Object Oriented languages. It uses JAVA as a vehicle to describe a formal program development methodology. Their approach is relatively more formal, requiring the practice of documenting the code so that the code can be reasoned manually later. Though it does not emphasis waterfall process, the heavy emphasis on documentation surely has the waterfall feelings in it.
For example, when mentioning inheritance the authors deliberately ignores the use of inheritance as ways of reusing code. Rather they focus on the subtype relation as a design constraint and discusses various rules that the subtype relation imposes on the design. This is completely different from many books that teach programming languages. This difference from conventional methods reflects the point that Liskov made in her talk, that many authors do not understand the concept and teaches it in a wrong way.
Perhaps the best book to compare with this one is the classical SICP (the wizard book); except the fact that SICP is based completely on Scheme and this book is on JAVA. They all share the same gene of avoiding formal mathematics, talking abstraction and elaborate on the design principles. SICP has more of the “fun” factors, and this book has more software engineering flavors in it. As for me, this book seems to be a little less ambitious. Perhaps that was the intent, because we are all humble programmers.
This book is about design methodology using Object Oriented languages. It uses JAVA as a vehicle to describe a formal program development methodology. Their approach is relatively more formal, requiring the practice of documenting the code so that the code can be reasoned manually later. Though it does not emphasis waterfall process, the heavy emphasis on documentation surely has the waterfall feelings in it.
For example, when mentioning inheritance the authors deliberately ignores the use of inheritance as ways of reusing code. Rather they focus on the subtype relation as a design constraint and discusses various rules that the subtype relation imposes on the design. This is completely different from many books that teach programming languages. This difference from conventional methods reflects the point that Liskov made in her talk, that many authors do not understand the concept and teaches it in a wrong way.
Perhaps the best book to compare with this one is the classical SICP (the wizard book); except the fact that SICP is based completely on Scheme and this book is on JAVA. They all share the same gene of avoiding formal mathematics, talking abstraction and elaborate on the design principles. SICP has more of the “fun” factors, and this book has more software engineering flavors in it. As for me, this book seems to be a little less ambitious. Perhaps that was the intent, because we are all humble programmers.
October 13, 2024
While researching the Liskov Substitution Principle, I found myself reading this book. How or why I started, I truly don’t know. To be honest, I didn’t even know Barbara Liskov had a book. Soon after, I ordered a second-hand copy from a Nadir bookstore's site (usedbook store). In fact, I can say I did this just to own a copy of the book. Normally, I prefer reading these types of technical books through O’Reilly, and that’s what I did. :)
The book dives deep into the concept of abstraction (procedural abstraction, data abstraction, iteration abstraction, polymorphic abstraction, etc.). Additionally, it covers topics like how to develop an object-oriented program, what the commonly used design patterns are, and also subjects like testing and debugging. Along with this, the author emphasizes the importance of writing specifications when developing a program. Even though it might seem like a verbal task, these specifications are closely tied to the substitution principle. For those who don’t have time to read the entire book, I would recommend at least reading one chapter—Chapter 7: Type Hierarchy. There is also a section in that chapter titled 7.9 The Meaning of Subtypes, which I personally refer to whenever I have the chance. I thought it was important, so I wanted to share it with you as well. From what I understand, this is the exact section where Barbara Liskov’s substitution principle is discussed.
That said, there were parts I couldn’t fully grasp. For example, writing abstraction functions and defining rep invariants are areas I need to revisit.
Although it’s an older book, I consider it one of the must-reads. In summary, these are my thoughts on the book. Even though I own a physical copy, I personally read it through O’Reilly. I hope this review has been helpful. Happy reading!
----
Liskov yer değiştirme ilkesi (liskov substitution principle) ile ilgili araştırma yaparken kendimi bu kitabı okurken buldum. Nasıl başladım, niye başladım gerçekten bilmiyorum. Açıkçası Barbara Liskov’un bir kitabı olduğunu da bilmiyordum. Akabinde, nadir kitap üzerinden kitabın ikinci elini hemen sipariş ettim. Aslında bunu, kitabın sadece bir kopyasına sahip olmak için yaptım diyebilirim. Normalde bu tarz teknik kitapları O’reilly üzerinden okumayı tercih ediyorum, ki öyle de yaptım :) Kitap, abstraction (soyutlama) olayını derinlemesine ele alıyor. (Procedural Abstraction, Data Abstraction, Iteration Abstraction, Polymorphic Abstraction vs). Bunun yanı sıra kitap, nesne yönelimli bir program nasıl geliştirilir? sık kullanılan tasarım kalıpları nelerdir? ve ayrıca test ve debugging konuları gibi bir çok başlığı da kapsıyor. Bununla beraber, yazar, bir program geliştirirken specification yazmanın önemine de ayrıca vurgu yapıyor. Her ne kadar sözel bir iş olsa da, bu specification’ların yer değiştirme ilkesiyle bir bağlantısı var. Kitabı komple okumaya vakti olmayanlara, en azından bir chapter’ı özellikle okumalarını tavsiye ediyorum. Bu, yedinci chapter olan 7. Type Hierarchy. Ve burada 7.9 The Meaning of Subtypes isimli bir başlık var. Ben şahsen bu başlığa fırsat buldukça bakıyorum. Önemli olduğunu düşündüğüm için sizinle de paylaşmak istedim. Anladığım üzere Barbara liskov’un yer değiştirme ilkesinin bahsedildiği yer tam olarak burası…
Aslında tam olarak içselleştiremediğim kısımlar da oldu. Örneğin abstraction function yazılması ve rep invariant tanımı gibi kısımlar. Velhasıl, bu bölümlere tekrar bakmam gerekiyor.
Her ne kadar eski bir kitap olsa da okunması gereken kitaplardan biri olarak görüyorum. Özetle kitapla ilgili görüşlerim bu kadar. Her ne kadar kitabın bir kopyasına sahip olsam da, şahsen kitabı O’reilly üzerinden okudum. Umarım bu kitap incelemesinin bir faydası olmuştur. İyi okumalar.
The book dives deep into the concept of abstraction (procedural abstraction, data abstraction, iteration abstraction, polymorphic abstraction, etc.). Additionally, it covers topics like how to develop an object-oriented program, what the commonly used design patterns are, and also subjects like testing and debugging. Along with this, the author emphasizes the importance of writing specifications when developing a program. Even though it might seem like a verbal task, these specifications are closely tied to the substitution principle. For those who don’t have time to read the entire book, I would recommend at least reading one chapter—Chapter 7: Type Hierarchy. There is also a section in that chapter titled 7.9 The Meaning of Subtypes, which I personally refer to whenever I have the chance. I thought it was important, so I wanted to share it with you as well. From what I understand, this is the exact section where Barbara Liskov’s substitution principle is discussed.
That said, there were parts I couldn’t fully grasp. For example, writing abstraction functions and defining rep invariants are areas I need to revisit.
Although it’s an older book, I consider it one of the must-reads. In summary, these are my thoughts on the book. Even though I own a physical copy, I personally read it through O’Reilly. I hope this review has been helpful. Happy reading!
----
Liskov yer değiştirme ilkesi (liskov substitution principle) ile ilgili araştırma yaparken kendimi bu kitabı okurken buldum. Nasıl başladım, niye başladım gerçekten bilmiyorum. Açıkçası Barbara Liskov’un bir kitabı olduğunu da bilmiyordum. Akabinde, nadir kitap üzerinden kitabın ikinci elini hemen sipariş ettim. Aslında bunu, kitabın sadece bir kopyasına sahip olmak için yaptım diyebilirim. Normalde bu tarz teknik kitapları O’reilly üzerinden okumayı tercih ediyorum, ki öyle de yaptım :) Kitap, abstraction (soyutlama) olayını derinlemesine ele alıyor. (Procedural Abstraction, Data Abstraction, Iteration Abstraction, Polymorphic Abstraction vs). Bunun yanı sıra kitap, nesne yönelimli bir program nasıl geliştirilir? sık kullanılan tasarım kalıpları nelerdir? ve ayrıca test ve debugging konuları gibi bir çok başlığı da kapsıyor. Bununla beraber, yazar, bir program geliştirirken specification yazmanın önemine de ayrıca vurgu yapıyor. Her ne kadar sözel bir iş olsa da, bu specification’ların yer değiştirme ilkesiyle bir bağlantısı var. Kitabı komple okumaya vakti olmayanlara, en azından bir chapter’ı özellikle okumalarını tavsiye ediyorum. Bu, yedinci chapter olan 7. Type Hierarchy. Ve burada 7.9 The Meaning of Subtypes isimli bir başlık var. Ben şahsen bu başlığa fırsat buldukça bakıyorum. Önemli olduğunu düşündüğüm için sizinle de paylaşmak istedim. Anladığım üzere Barbara liskov’un yer değiştirme ilkesinin bahsedildiği yer tam olarak burası…
Aslında tam olarak içselleştiremediğim kısımlar da oldu. Örneğin abstraction function yazılması ve rep invariant tanımı gibi kısımlar. Velhasıl, bu bölümlere tekrar bakmam gerekiyor.
Her ne kadar eski bir kitap olsa da okunması gereken kitaplardan biri olarak görüyorum. Özetle kitapla ilgili görüşlerim bu kadar. Her ne kadar kitabın bir kopyasına sahip olsam da, şahsen kitabı O’reilly üzerinden okudum. Umarım bu kitap incelemesinin bir faydası olmuştur. İyi okumalar.
January 14, 2019
A slightly dated book on program design and general software engineering principles
Originally, the book was named Abstraction and Specification in Program Development (published in 1986, with examples in CLU language). This is important because I feel the second edition has not been updated much for Java, and the proposed development methodology often felt more applicable for (or at least highly influenced by) the procedural languages.
So the result is that this book has almost nothing to do with Java. Its primary focus in on how to design programs - how to decompose large problems into smaller ones, how to specify the requirements in terms of informal specifications, how to use different types of abstraction, etc. This is the good part - the theory, high-level ideas and some parts of the reasoning.
However, the book no longer has an ideal audience. Novice programmers will likely find it too abstract and too far from their day-to-day experiences (the way development is done nowadays is much different from 2000 (and even more so from 1986)), while seasoned programmers will have to skim through a lot of text to find those timeless ideas.
For anyone reading this today, I'd suggest reading just the following chapters:
1 - Introduction
3 - Procedural abstraction
5 - Data abstraction
9 - Specifications
10 - Testing and debugging
13 - Desing
14 - Between design and implementation
Originally, the book was named Abstraction and Specification in Program Development (published in 1986, with examples in CLU language). This is important because I feel the second edition has not been updated much for Java, and the proposed development methodology often felt more applicable for (or at least highly influenced by) the procedural languages.
So the result is that this book has almost nothing to do with Java. Its primary focus in on how to design programs - how to decompose large problems into smaller ones, how to specify the requirements in terms of informal specifications, how to use different types of abstraction, etc. This is the good part - the theory, high-level ideas and some parts of the reasoning.
However, the book no longer has an ideal audience. Novice programmers will likely find it too abstract and too far from their day-to-day experiences (the way development is done nowadays is much different from 2000 (and even more so from 1986)), while seasoned programmers will have to skim through a lot of text to find those timeless ideas.
For anyone reading this today, I'd suggest reading just the following chapters:
1 - Introduction
3 - Procedural abstraction
5 - Data abstraction
9 - Specifications
10 - Testing and debugging
13 - Desing
14 - Between design and implementation
January 28, 2014
Chapters Read: 1 through 9
This book focuses on the concept of the relationship between the software client and the service provider, and it's not the full fledged interfaced software that I'm talking about, rather the clients who use programs and code as an API to their own applications. Liskov addresses what should be done by the service providers as a contract between them and their clients in terms using the concept of abstraction properly and describing the what a module does not how it does it so that it leaves space for multiple solution, or implementations, for the coders. This may seem direct and simple, but it is not as straight-forward and does not come naturally as one might think.
It also shines some light on the different data structures and explains them a bit in detail and explaining the level of abstraction they may provide, and how it hides the details from the clients, or at times a malicious entities, who may use the code improperly, whether intentionally or not.
This book should have been taught right after the first data structure course that is taken by CS undergrad students and I would recommend it to anyone who would be interested in software development in a professional manner.
This book focuses on the concept of the relationship between the software client and the service provider, and it's not the full fledged interfaced software that I'm talking about, rather the clients who use programs and code as an API to their own applications. Liskov addresses what should be done by the service providers as a contract between them and their clients in terms using the concept of abstraction properly and describing the what a module does not how it does it so that it leaves space for multiple solution, or implementations, for the coders. This may seem direct and simple, but it is not as straight-forward and does not come naturally as one might think.
It also shines some light on the different data structures and explains them a bit in detail and explaining the level of abstraction they may provide, and how it hides the details from the clients, or at times a malicious entities, who may use the code improperly, whether intentionally or not.
This book should have been taught right after the first data structure course that is taken by CS undergrad students and I would recommend it to anyone who would be interested in software development in a professional manner.
Displaying 1 - 5 of 5 reviews