• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Object Oriented and Conventional design

 
pavan meda
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is OO Design is costlier than Conventional Design?
 
Theodore Casser
Ranch Hand
Posts: 1902
Hibernate Netbeans IDE PHP
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 http://members.aol.com/kgb1001001 for other WebSphere information.
 
Alan Shalloway
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic