File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Object Oriented and Conventional design Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Object Oriented and Conventional design" Watch "Object Oriented and Conventional design" New topic

Object Oriented and Conventional design

pavan meda

Joined: Oct 04, 2001
Posts: 2
Is OO Design is costlier than Conventional Design?
Theodore Casser
Ranch Hand

Joined: Mar 14, 2001
Posts: 1902

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
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!
Kyle Brown
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
Originally posted by pavan meda:
Is OO Design is costlier than Conventional Design?

Perhaps a better question (for this forum) is, can you do any other sort of design when Java is your target language? The answer to that (since Java is an OO language) is definitely no.

Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at for other WebSphere information.

Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at for other WebSphere information.
Alan Shalloway
Ranch Hand

Joined: Sep 26, 2001
Posts: 60
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="" TARGET=_blank rel="nofollow">Design Patterns Explained</A><BR>Visit our site <A HREF="" TARGET=_blank rel="nofollow">Net Objectives</A>.<BR>Visit our <A HREF="" TARGET=_blank rel="nofollow">Design Patterns Explained Community of Practice</A><BR>Check out our <A HREF="" TARGET=_blank rel="nofollow">CDROM based audio training in XML</A>
I agree. Here's the link:
subject: Object Oriented and Conventional design
It's not a secret anymore!