Commentaires client les plus utiles
|
|
3 internautes sur 4 ont trouvé ce commentaire utile :
2.0étoiles sur 5
Mostly Muck and Mire, Aoû 18 2003
Par Un client
The book begins with a bang and ends with distaste. After reading about the first hundred pages or so, I felt that I uncovered a truly remarkable book about programming. The advice it gave seemed concrete, and it had a promising appeal to make me a better programmer. Unfortunately, the next one thousand pages were not able to meet my expectations. In my opinion, there are three major problems with this book: its style, its consistency, and its goal. First, its style. The book is overflated. Meyers often spends several paragraphs describing a concept that deserves a mere sentence. A good editor could have compressed this book down to 600 pages or less. Moreover, his tone is somewhat conceited. He throws words around like 'n-dimensional space', 'topology', and 'monoid' without using them meaningfully. Is he trying to show off his knowledge? Second, the book is not consistent with itself. Meyers states many principles and chides other languages for violating them. However, he occasionally violates them himself. He justifies them via a sentence such as, "while this may appear to be a direct violation of Principle X, it actually isn't because of [some reason that usely isn't very convincing]..." Sometimes I found his reasons were based on misconceptions and personal opinion rather than fact. Third, Meyers' goal for the book is disreputable. The book advertises itself as a general reference for OOP; instead, it teaches the bare basics of OOP and spends the rest of its time bashing other languages and teaching Eiffel, a language developed by the author. I think that this is unacceptable. Is the book completely horrible? No. It does have a couple nice concepts, such as Design by Contract, Bottom-Up Approach, and implicit definitions of Abstract Data Types. However, these three concepts could have been summarized in 50 pages, not 1,250. For these reasons, I recommend getting another book, unless you want to learn to program in Eiffel.
|
|
|
4.0étoiles sur 5
A must have book for professionals in OO, Sep 16 2003
Unfortunately, the majority of books in computing science area suffers a lack of
precise definition and clarity of terms and concepts. In my personal opinion, the
commercial aspects that strongly affect this area, comparing to other technological
ones, contributes to open the computing book market for authors of highly questionable
experience and a quite shalow knowledge about the matter they're treating. For example, it
is not unusual to see the same author (or group of authors) writing books about Java, .NET,
JSP, ASP, Perl, OO, C/C++ and so on.
Bertrand Meyer's OO book is an exception in this tendency. The subjects treated are logically
distributed and the concepts are clearly and precisely defined. Then, the reader gets an
intuitive and deep understanding of OO theoretical aspects, independent of OO language
specifics. All the concepts are perfectly prioritized and sequenced: software quality before
OO, ADT before classes, features before functions, DBC before exception handling. Every
single concept bases the following ones. I must say, however, that the author should be more
concise: he writes too much to explain a single concept. He reveals his large academic
literate background inserting unnecessary large comments in the text. The book could have
a quite less number of pages without any loss in learning the main concepts.
I sincerely do not see any problem about the relation between the OO concepts presented and
their practical implementation: EIFFEL language. At least, the author shows concretely that
the concepts treated in the book are implementable. If there were not any language to
complete and support the theoretical aspects, we could say : "Ok, all the concepts
in the book are perfect and beautiful, but the closest programming language to
these concepts we can use is JAVA, for example."
|
|
|
2.0étoiles sur 5
Mostly Mire and Muck, Aoû 19 2003
Par Un client
The book begins with a bang and ends with distaste. After reading about the first hundred pages or so, I felt that I uncovered a truly remarkable book about programming. The advice it gave seemed concrete, and it had a promising appeal to make me a better programmer. Unfortunately, the next one thousand pages were not able to meet my expectations. In my opinion, there are three major problems with this book: its style, its consistency, and its goal. First, its style. The book is overflated. Meyers often spends several paragraphs describing a concept that deserves a mere sentence. A good editor could have compressed this book down to 600 pages or less. Moreover, his tone is somewhat conceited. He throws words like 'n-dimensional space', 'topology', and 'monoid' around without using them meaningfully. Is he trying to show off his knowledge? Second, the book is not consistent with itself. Meyers states many principles and chides other languages for violating them. However, he occasionally violates them himself. He justifies it via statement like, "while this may appear to be a direct violation of Principle X, it actually isn't because of [some reason that usually isn't very convincing]..." Sometimes I found his reasons were based on misconceptions and personal opinion rather than fact. Third, Meyers' goal for the book is disreputable. The book advertises itself as a general reference for OOP; instead, it teaches the bare basics of OOP and spends the rest of its time bashing other languages and furtively teaching Eiffel, a language he invented. I think that this is unacceptable. Is the book completely horrible? No. It does have a couple nice concepts, such as Design by Contract, Bottom-Up Approach, and his description of Abstract Data Types. However, all of the beneficial material could have been summarized in 50 pages, not 1,250. For these reasons, I recommend getting another book, unless you want to use this book for what it's really meant for: learning to program in Eiffel.
|
|
|
Commentaires client les plus récents
|
de Martin Fowler
de Martin Fowler
de Kent Beck
de Don Norman
