Software Engineering discussion
Code Complete
>
Working Classes
date
newest »
newest »
Yes, I was reading several of the sections thinking "I've made that mistake". I'm not sure this chapter would have prevented me from making those mistakes, but it helps me recognize the ones I have made.This chapter does point out advantages of composition over inheritance. The previous chapter seemed to be promoting inheritance more.
I really like the code examples. They are short and easy to understand the point. The code samples often show bad examples, but a few more good practice examples would be nice too. I would have liked to see the Cat and Scratch() example in code.
Good chapter, although some of the suggestions and discussions should be moved to Chapter 5 Design in Construction and explained in non object-oriented approach. Reading this chapter reminded me of Linus Torvarlds’s response to C++. Not that I share his opinions, it’s just made me thinking how much work we need to do and how many rules we need to follow to make a GOOD software design in object-oriented approach that would bring us all the benefits that it promises. That leads to a question: is there a minimum set of rules that if broken would make an object-oriented approach useless? I really like two suggestions provided in this book: Don’t make assumptions about the class’s users and Be very, very wary of semantic violations of encapsulation. I think these are the rules that may be added to the minimum set of rules every designer should follow.
Aleksandar, to your question "Is there a minimum set of rules that if broken would make an OO approach useless?"...
In my view, OO is just one tool in the toolbox, but a very important one. If I were writing a short program, by myself, I would probably reach for language that allows for an imperative style (Perl, Python, C, etc.) just because of the overhead and typing required to make it "OO". The bigger the project, and the more people involved, the more likely I am to go the OO route.
A hot topic right now is whether or not the OO paradigm is best suited for the coming demands of concurrent and multi-core programming. Some feel that functional programming fits better. FP is certainly elegant and has many advantages, but I am not yet convinced that it is the best approach for business applications.
CMU recently made the controversial move of dropping OO from its freshman CS class, and replacing it with an imperative-based class and a functional-based class. This opens up the age-old debate of how closely CS classes should address current industry practice (OO dominated) vs. teach students to think more fundamentally about approaches to solve computing problems with an eye toward the future.
http://developers.slashdot.org/story/...
http://existentialtype.wordpress.com/...
http://reports-archive.adm.cs.cmu.edu...
In my view, OO is just one tool in the toolbox, but a very important one. If I were writing a short program, by myself, I would probably reach for language that allows for an imperative style (Perl, Python, C, etc.) just because of the overhead and typing required to make it "OO". The bigger the project, and the more people involved, the more likely I am to go the OO route.
A hot topic right now is whether or not the OO paradigm is best suited for the coming demands of concurrent and multi-core programming. Some feel that functional programming fits better. FP is certainly elegant and has many advantages, but I am not yet convinced that it is the best approach for business applications.
CMU recently made the controversial move of dropping OO from its freshman CS class, and replacing it with an imperative-based class and a functional-based class. This opens up the age-old debate of how closely CS classes should address current industry practice (OO dominated) vs. teach students to think more fundamentally about approaches to solve computing problems with an eye toward the future.
http://developers.slashdot.org/story/...
http://existentialtype.wordpress.com/...
http://reports-archive.adm.cs.cmu.edu...
In particular, I think that the discussion of the evils of inheritance and the preferred alternative, in many cases, of using composition is well done, but code examples would be helpful to those new to this debate. I also thought that the case study of NASA's reuse approach, not focusing on building reusable classes during the project but mining them after the project, was interesting.
I thought that the summary of OO semantics that might vary from language to language is valuable, and I have not seen a list like this before. I really like the advice to program into a language, not in a language.
In the additional resources section, I highly recommend Arthur Riel's "Object-Oriented Design Heuristics". I accidentally stumbled upon it in a library once and agree that it's 200 pages contain clear and powerful advice. I wonder why this book is not more widely known? I also agree that Scott Meyers on "Effective C++" and Joshua Block on "Effective Java" are excellent choices too.
From the content of this chapter though, I don't think that this book will resonate well with newer programmers. There is quite a bit of assumed background knowledge and experience in OO design and language specifics.