This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Are you talking up front costs or overall through the life of the application? I would think, personally, that while OO design might involve more work on the front end, the benefits over the long run of being maintainable, understandable and extensible would provide a cost-savings, rather than an increased cost. Just my $0.02. ------------------ Theodore Jonathan Casser SCPJ2 and SCWCD IBM Certified Specialist - WebSphere Application Server, Std. Ed, V3.5
Theodore Jonathan Casser
SCJP/SCSNI/SCBCD/SCWCD/SCDJWS/SCMAD/SCEA/MCTS/MCPD... and so many more letters than you can shake a stick at!
I believe OO design is more a perspective, a way of looking at things. Virtually all design methods have us decompose (break down) our problem into different things. Conventional design (structured programming) has us break our problem domain up into functions (modules that do specific tasks). That's why this is called functional decomposition. OO has us break things up into objects (object decomposition). But on what basis do we define our objects? The entities in our system (nouns for the objects, verbs for the methods) has significant problems. Abstracting out using commonality/variability analysis is much more effective. The question then becomes, which is the best way to break down our problem domain into smaller pieces. I think OO design is better. Particularly when you have an OO language like Java to implement the design. It can still be done in non-oo languages, but it is harder. Unfortunately, you can do non-oo programming in Java. I'd say more than half of the java code i see is of this type. In C++ it's even worse. There is a broader question - how heavy is the OO methodology you use? Rational's Rational Unified Process is way to heavy for me. We're developing our own methodology we call Lightweight Pattern Accelerated development that is based on XP but has a little bit more upfront design, uses UML for conceptual models and doesn't insist on paired programming (something we like but something not all departments will do). How heavy you go has nothing to do with whether you are OO or not, it speaks more to the processes you like to follow. ------------------ Alan Shalloway, Look for Jim Trott and my book: Design Patterns Explained Visit our site Net Objectives. Visit our on-line companion to the book
Alan Shalloway.<BR>Look for Jim Trott and my book: <A HREF="http://www.amazon.com/exec/obidos/ASIN/0201715945/ref=ase_electricporkchop/103-0514572-3811868" TARGET=_blank rel="nofollow">Design Patterns Explained</A><BR>Visit our site <A HREF="http://www.netobjectives.com" TARGET=_blank rel="nofollow">Net Objectives</A>.<BR>Visit our <A HREF="http://www.netobjectives.com/dpexplained/index.html" TARGET=_blank rel="nofollow">Design Patterns Explained Community of Practice</A><BR>Check out our <A HREF="http://www.netobjectives.com/xml/xml_cdrom_info.htm" TARGET=_blank rel="nofollow">CDROM based audio training in XML</A>