Rating: 
Summary: "OO 101"--A gentle intro to object oriented concepts
Review: This book is a brief introduction to object oriented principles. It may be helpful for readers trying to get their heads around the idea of OO programming. There are a few warnings I'd pass along to other readers, though.The discussion of association, aggregation and composition is confusing and unconventional. Weisfeld says that association and aggregation are forms of composition. I had been led to believe that composition is a special form of aggregation, and that association is a more general circumstance that may or may not involve a "has-a" relationship. Weisfeld didn't mention what I think is a good sign you're working with composition rather than aggregation: when the 'part' object goes out of existence when the 'whole' object goes out of existence, you're probably talking about composition. If the parts persist after the larger object is disbanded, then it's aggregation. The author drops in tips about how OO principles apply to popular languages like C++ or Java. Most of these are reasonable, but a few seem suspicious. For example, the author states that, "In Java, the default type of access is protected. Protected access means that only classes in the package can access the attribute or method." Actually, the default access type in Java is 'default.' The definition given for 'protected' is in fact a definition of default, so maybe this was nothing more than a big typo. I just wish the book had been reviewed by experts in the languages discussed. The book is a quick read. The reading would go a little more smoothly if the book had been edited more carefully. There are some redundancies and bumpy passages, especially later in the book. The chapters on objects and the web, software components & enterprise computing are at a very high level, but that's OK if they help the novice put the technology in perspective. Overall, this is a useful intro to the subject. A decent value as well.
Rating:
Summary: "OO 101"--A gentle intro to object oriented concepts
Review: This book is a brief introduction to object oriented principles. It may be helpful for readers trying to get their heads around the idea of OO programming. There are a few warnings I'd pass along to other readers, though. The discussion of association, aggregation and composition is confusing and unconventional. Weisfeld says that association and aggregation are forms of composition. I had been led to believe that composition is a special form of aggregation, and that association is a more general circumstance that may or may not involve a "has-a" relationship. Weisfeld didn't mention what I think is a good sign you're working with composition rather than aggregation: when the 'part' object goes out of existence when the 'whole' object goes out of existence, you're probably talking about composition. If the parts persist after the larger object is disbanded, then it's aggregation. The author drops in tips about how OO principles apply to popular languages like C++ or Java. Most of these are reasonable, but a few seem suspicious. For example, the author states that, "In Java, the default type of access is protected. Protected access means that only classes in the package can access the attribute or method." Actually, the default access type in Java is 'default.' The definition given for 'protected' is in fact a definition of default, so maybe this was nothing more than a big typo. I just wish the book had been reviewed by experts in the languages discussed. The book is a quick read. The reading would go a little more smoothly if the book had been edited more carefully. There are some redundancies and bumpy passages, especially later in the book. The chapters on objects and the web, software components & enterprise computing are at a very high level, but that's OK if they help the novice put the technology in perspective. Overall, this is a useful intro to the subject. A decent value as well.
Rating: 
Summary: Good introductory text
Review: This book is one of the best introductory texts to object-oriented programming available. It has the advantage of not depending on a particular programming language, so it is free to deal with the object-oriented philosophy and explain the core concepts of inheritance, polymorphism, etc. The examples used are simple but elegant, and the flow of the book takes the reader from the basics of building objects to the complexities of object interaction. It assumes very little about the readers background, so it is thorough and easy to follow. This book's best use is for the person who wants to make the jump from procedural to object-oriented programming by understanding it first, and getting into the details of coding later, which is the way it should be done. When someone asks "What is object-oriented programming, anyway?", I point them to this book as the answer.
Rating: 
Summary: Must buy!
Review: This book is only 200 pages but it is an EXCELLENT book for people that are trying to get a better understanding of Object-Oriented concepts! Most of the Java books that I have read don't cover the type of information found in this book. And the best part about it, is that it is very easy to read. After reading through most of the chapters, I have found that I was able to pick the book up again after a year....read a few select chapters again and get more out of it! It really helps you to achieve a solid understanding.
Rating:
Summary: What I should have learned in my beginning Java courses.
Review: This book is truly what I should have learned in my beginning Java courses. It is a good thing I found this book before I graduated. I finally understand how to truly program in an object oriented way.
Rating:
Summary: Great for Beginners
Review: This is a great book if you need a refresher or are new to the OO world. Most of the examples were good. A few were just more confusing.
It's a good short introduction to OO.
Rating:
Summary: For a Beginner to Object Oriented Design this book is great
Review: When I bought this book I didn't really have a handle on just what being object oriented was all about. The examples provided in this book were very clear and can relate to everyone. I'm now applying the information I learned from this book into real world techniques with my company's multimillion dollar e-commerce website.
Rating: 
Summary: Could turn on some lights but could also be dangerous.
Review: When I first bought this book, hoping for a synopsis of Object Oriented Programming's concepts to supplement some of the C++ Primers I had, I was pleased enough with the purchase. I read a few chapters, and they summarized more or less what I'd gathered Object Orientation was about in the various C++ primers I owned. At the time, I only dabbled in C++ and wasn't programming as part of my job. Had I rated the book then, I probably would have given it a 4. Since that time, I've played with C++ more, and read more perspectives on OOP, mostly from books like Thinking in C++. Recently I landed a new job, working with IDL (a programming language with some MATLAB similarities but almost wholly different syntax, used primarily in science). This language has recently added some OO constructs to it, news which I was very glad to hear and was a major reason for me applying for the position. However, I felt a bit rusty with some of the OO concepts, so I went back to this book... and was disappointed. Part of the problem was hinted at before. Much of the helpful information in the first few chapters is the same as what you get in primers of languages that focus on the OO methodology. Sometimes this information is more spread out in these primers, so at least it's nice to have all of the basics together in one place. Another problem I had was with the order of presentation. The first few chapters throw the basic spectrum of OO concepts at you. And in fact, each of the first few chapters discusses the same concepts over and over again. It's like starting to dig a hole here.. then jumping over there to start a hole, etc. Eventually you jump back to the first hole, dig a bit more, jump to the next, etc.. To me this is a disconcerting method of presenting information. I would have preferred the first chapter be the overview of everything (planting the flag at each spot you want to dig a hole), but then each additional chapter focus on one of those subjects, and dig until the bottom (in terms of how deep the book presents the information, not meaning it should go into a whole lot more detail) is reached. The first chapter should be enough to link the concepts together instead of constantly attempting to do so. Well, others might disagree with what I like in 'style' for books, but there are other problems. Many of the examples end just a bit too early with the 'take home messages' implied and not explicitly stated. The writing style feels disorganized. For example, quite late in the book it's mentioned that Inheritance is one of the Three Cornerstones of OOP along with Encapsulation. I couldn't remember what he said the third cornerstone was, so I went back to the front and searched... Nowhere are the three cornerstones (the third he mentions a bit after the point I mentioned above, Polymorphism) pointed out. Finally, there's the problem that he doesn't seem to understand himself some of the concepts he talks about. I'll give him the benefit of the doubt and say that this might be because he's trying to simplify things for the reader, but to me it just made it more confusing. The classic example is one already mentioned here, but in one sidebar he says "Sometimes a distinction is made between the words 'aggregation' and 'composition'. However, in this book we will consider composition and aggregation as the same thing." Well, first of all, the distinction is a valid one, but if he wanted to simplify things he should have phrased it more like, "There are different kinds of 'composition', however we will be focusing mainly on one, called 'aggregation'." The problem is exacerbated two chapters later when suddenly he changes his mind and talks about 'association' and 'aggregation' as two different kinds of composition. One other area that it seemed like he was a bit confused, or trying to overly simplify a discussion, was when talking about 'interfaces' versus 'abstract classes' in Java. He uses the example of an interface called 'nameable' and proceeds to say that it doesn't follow the "is a" rule for inheritance. Instead he drops the "a" and says: "A dog is nameable"
"A lizard is nameable" My instant reaction was, "Well, a dog is a nameable thing, and a lizard is a nameable thing." He then implies in a warning that another reason why an interface is different than an abstract class is because an interface doesn't provide implementation, but an abstract class does. In reality, an abstract class can be created that has no implementation either, which means both an abstract class and an interface can rely completely on a subclass to provide it. I'm not quite sure why he tries to make a distinction between implementation and behavior which to me confuses the issue more. And finally, after making the point that an interface doesn't follow the 'is a' property, he then says (one paragraph later), "How do we know for sure that interfaces have a true is-a relationship? In the case of Java, we can let the compiler tell is..." and proceeds to show the code that proves it. A final problem for me is some examples don't match the diagrams. The worst for me is the BlackJack example where he suddenly throws a D_Player object into the Use Case diagrams. Now, I assume that this is just a Player Object created to represent the dealer (ie, not a SubClass), but every other object is specifically the name of a class. He never mentions D_player in any of the descriptions. My overall conclusion of the First Edition of this book is that it could have been organized better and really provides not much more than some of the better Primers in various OO languages. It still would have been useful had the material been clear, coherent, consistent and correct. In some ways the book is still useful, but I would recommend picking up a good Primer that talks about OO fundamentals also, instead of this one. I know there is a second edition out, and if I get the chance I will pick it up to see if these problems have been ironed out. If they are, I would give the book a 4 as a nice, quick overview of the OO Thought process. If they aren't, I'd say "Programmer Beware".
Rating:
Summary: Could turn on some lights but could also be dangerous.
Review: When I first bought this book, hoping for a synopsis of Object Oriented Programming's concepts to supplement some of the C++ Primers I had, I was pleased enough with the purchase. I read a few chapters, and they summarized more or less what I'd gathered Object Orientation was about in the various C++ primers I owned. At the time, I only dabbled in C++ and wasn't programming as part of my job. Had I rated the book then, I probably would have given it a 4. Since that time, I've played with C++ more, and read more perspectives on OOP, mostly from books like Thinking in C++. Recently I landed a new job, working with IDL (a programming language with some MATLAB similarities but almost wholly different syntax, used primarily in science). This language has recently added some OO constructs to it, news which I was very glad to hear and was a major reason for me applying for the position. However, I felt a bit rusty with some of the OO concepts, so I went back to this book... and was disappointed. Part of the problem was hinted at before. Much of the helpful information in the first few chapters is the same as what you get in primers of languages that focus on the OO methodology. Sometimes this information is more spread out in these primers, so at least it's nice to have all of the basics together in one place. Another problem I had was with the order of presentation. The first few chapters throw the basic spectrum of OO concepts at you. And in fact, each of the first few chapters discusses the same concepts over and over again. It's like starting to dig a hole here.. then jumping over there to start a hole, etc. Eventually you jump back to the first hole, dig a bit more, jump to the next, etc.. To me this is a disconcerting method of presenting information. I would have preferred the first chapter be the overview of everything (planting the flag at each spot you want to dig a hole), but then each additional chapter focus on one of those subjects, and dig until the bottom (in terms of how deep the book presents the information, not meaning it should go into a whole lot more detail) is reached. The first chapter should be enough to link the concepts together instead of constantly attempting to do so. Well, others might disagree with what I like in 'style' for books, but there are other problems. Many of the examples end just a bit too early with the 'take home messages' implied and not explicitly stated. The writing style feels disorganized. For example, quite late in the book it's mentioned that Inheritance is one of the Three Cornerstones of OOP along with Encapsulation. I couldn't remember what he said the third cornerstone was, so I went back to the front and searched... Nowhere are the three cornerstones (the third he mentions a bit after the point I mentioned above, Polymorphism) pointed out. Finally, there's the problem that he doesn't seem to understand himself some of the concepts he talks about. I'll give him the benefit of the doubt and say that this might be because he's trying to simplify things for the reader, but to me it just made it more confusing. The classic example is one already mentioned here, but in one sidebar he says "Sometimes a distinction is made between the words 'aggregation' and 'composition'. However, in this book we will consider composition and aggregation as the same thing." Well, first of all, the distinction is a valid one, but if he wanted to simplify things he should have phrased it more like, "There are different kinds of 'composition', however we will be focusing mainly on one, called 'aggregation'." The problem is exacerbated two chapters later when suddenly he changes his mind and talks about 'association' and 'aggregation' as two different kinds of composition. One other area that it seemed like he was a bit confused, or trying to overly simplify a discussion, was when talking about 'interfaces' versus 'abstract classes' in Java. He uses the example of an interface called 'nameable' and proceeds to say that it doesn't follow the "is a" rule for inheritance. Instead he drops the "a" and says: "A dog is nameable"
"A lizard is nameable" My instant reaction was, "Well, a dog is a nameable thing, and a lizard is a nameable thing." He then implies in a warning that another reason why an interface is different than an abstract class is because an interface doesn't provide implementation, but an abstract class does. In reality, an abstract class can be created that has no implementation either, which means both an abstract class and an interface can rely completely on a subclass to provide it. I'm not quite sure why he tries to make a distinction between implementation and behavior which to me confuses the issue more. And finally, after making the point that an interface doesn't follow the 'is a' property, he then says (one paragraph later), "How do we know for sure that interfaces have a true is-a relationship? In the case of Java, we can let the compiler tell is..." and proceeds to show the code that proves it. A final problem for me is some examples don't match the diagrams. The worst for me is the BlackJack example where he suddenly throws a D_Player object into the Use Case diagrams. Now, I assume that this is just a Player Object created to represent the dealer (ie, not a SubClass), but every other object is specifically the name of a class. He never mentions D_player in any of the descriptions. My overall conclusion of the First Edition of this book is that it could have been organized better and really provides not much more than some of the better Primers in various OO languages. It still would have been useful had the material been clear, coherent, consistent and correct. In some ways the book is still useful, but I would recommend picking up a good Primer that talks about OO fundamentals also, instead of this one. I know there is a second edition out, and if I get the chance I will pick it up to see if these problems have been ironed out. If they are, I would give the book a 4 as a nice, quick overview of the OO Thought process. If they aren't, I'd say "Programmer Beware".
| 
