Results 1 to 15 of 15
  1. #1

    Object-Oriented Programming - pros and cons

    I'd like to open this discussion about the pros and cons of Object-oriented programming. What have you found works for you and what doesn't.
      0 Not allowed!

  2. #2
    Join Date
    Dec 2001
    Location
    NYC, NY
    Posts
    798
    the biggest pro is scalable code.. in a good language you can subclass easily to a parent class. It allows for rapid development also.
    Blog your life away
    http://photoblog.com
      0 Not allowed!

  3. #3
    You didn't give any cons.

    Cons:
    Not as efficent, uses more cpu
      0 Not allowed!

  4. #4
    Join Date
    Apr 2004
    Location
    Port St Lucie, FL
    Posts
    117
    I, for one, am a big fan of OO Programming and have been for years.

    Pro: Encapsulation. You can create modular classes that (hopefully) can be reused in other applications with little to no modification.

    On large teams of programmers, once the interfaces between classes have been worked out, each team can work (relatively) independently of the other - allowing parallel development.

    Con: Overuse of OO programming can cause bloated code and unnecessary overhead.
    Paul Embry
    Knight Software and Web Design
    Paul.Embry@gmail.com
    Quality PHP Web Programming for Reasonable Prices
      0 Not allowed!

  5. #5
    Join Date
    Oct 2001
    Location
    Ann Arbor, MI U.S.A.
    Posts
    217
    Debates will rage on forever about how "good" or "bad" OO programming is and whether is actually helps or hurts (or makes no difference at all).

    Any solid programmer can work wonders in procedural *and* OO based languages so much of the bickering over which is better is really moot IMHO.

    From a technical standpoint OO based software tends to have more overhead (but much of this can be mitagated by not using some of OOs features (RTTI comes to mind)), but this has rarely been a show stopper for me at least.

    I find that much of my slant toward for OO comes from the design side as opposed to the implementation side. I find OO projects easier to lay out on paper (and in my head). I have friends who are the exact opposite . It comes down to what you are used to and how you think about problems, any speed and other pros/cons can be designed around for the most part.

    Chris
    Chris Wells [clwells - at - nexcess.net]
    Nexcess - Beyond Hosting
    Dearborn, MI DC ● Southfield, MI DC
    Wordpress Hosting, Magento Hosting & More!
      0 Not allowed!

  6. #6
    Join Date
    Jul 2003
    Location
    Kuwait
    Posts
    5,099
    Originally posted by Wojjie
    You didn't give any cons.

    Cons:
    Not as efficent, uses more cpu
    How did you come to that conclusion?

    For me, cons of OOP:

    Requires a lot of planning if you intend to make your code portable. If you write sloppy OOP code, it won't benefit you as much as if you plan it and write it carefully. I suppose this applies to procedural code as well, but it applies especially to OOP.

    OOP requires accurate documentation, which increases your time to completion. After all, what's the point of creating a very nice class to do x when no one knows how to call its methods?

    Requires a bit more "academic" programming knowlege. For example, knowledge of OOP concepts such as polymorphism, inheritence etc. are all required. Not so much as in procedural languages.


    Pros (a few, but for me personally):

    Resuability is a big plus for me. You can write an object (and depending on what language you choose), you can use the same functionality in other programs -- even in programs written in other languages. This helps a lot when it comes time to implement the same logic somewhere else.

    I don't consider this really a OOP-specific pro, but maintainablity is improved with OOP. You can also write maintainable procedural code, but with OOP, since your codebase is centralized, you only have to concentrate on that part when it comes time to upgrade.

    Other things, such as RTTI, RPC, etc. are more language specific, not general OOP pros.
    Last edited by Burhan; 07-17-2004 at 03:02 AM.
    In order to understand recursion, one must first understand recursion.
    If you feel like it, you can read my blog
    Signal > Noise
      0 Not allowed!

  7. #7
    Join Date
    Oct 2001
    Location
    Ann Arbor, MI U.S.A.
    Posts
    217
    agreed fyrestrtr, I'm sure it was via benchmarking, extensive research and personal experience with OO vs. procedural systems, isn't that right Wojjie?

    Chris
    Chris Wells [clwells - at - nexcess.net]
    Nexcess - Beyond Hosting
    Dearborn, MI DC ● Southfield, MI DC
    Wordpress Hosting, Magento Hosting & More!
      0 Not allowed!

  8. #8
    Perhaps you should check my sig and look for the article where I benched the two. Perhaps in other situations they are equal in speed?

    You have a bit more control over the efficency (cpu load) with functional programming, than with OOP.

    PS. theserverpages one
      0 Not allowed!

  9. #9
    Join Date
    Oct 2001
    Location
    Ann Arbor, MI U.S.A.
    Posts
    217
    Wojjie,

    I'd hardly call your test suite of 2 15 line programs authoritative enough to make the blanket (and vague) statement: "Not as efficent, uses more cpu". Especially for an interpreted (and hardly OO) language such as PHP.

    That said, at least you tried, which is more than can be said for most. Why didn't you post your link to the "benchmark" in your initial post? It'd have at least backed up your claim and given the original poster something to ponder.

    Chris
    Chris Wells [clwells - at - nexcess.net]
    Nexcess - Beyond Hosting
    Dearborn, MI DC ● Southfield, MI DC
    Wordpress Hosting, Magento Hosting & More!
      0 Not allowed!

  10. #10
    Sorry, for some reason I assumed this thread was about PHP, force of habit.

    I would of posted the link if it was not on my own site.
      0 Not allowed!

  11. #11
    Join Date
    Jan 2004
    Posts
    406
    I almost exclusively, design and code using OO concepts. Most of my code now days is written in classic ASP and even though it is not an OO language I find huge benefits in applying the concepts.

    Pros
    Code reuse. It can take less time to actually code, depending on the project. For me the projects tend to be quite large at times and leveraging the same code for different areas of a site can make significantly cut down coding time.

    Maintainability is another huge reason. I'm still maintaining a project that is a few years old. It has been easy to add new functionality without the fear of breaking other parts. But more importantly for me is the ability to apply changes across the application. For example I create an object that abstracts all email functionality, if I need to change the emailing component from ASPMail to CDONTS I don't need to redo all the pages that email. I just go to my email object and change the code in just that single place.

    Security. I validate every input in the objects and do not access a database unless it is thru the objects. So regardless of the numbers of pages that need to access a database table, I have the code in one area and just need to make sure that it is properly validated in the one place. I find that enforcing a policy of not accessing resources without an object is particularly important for projects with multiple programmers as some are more security conscientious than others. I actually briefly deviated from policy myself, and even though I have many years of experience, I introduced an error that allowed for SQL injection. Fortunately, it was caught in code review.

    Cons
    It can take more time to actually code, depending on the project. This can be true particularly for small projects. You also need to code a lot more if your language is not inherently object oriented. However, I still favor taking the time to do it in OO because I feel the pros outweigh the cons.

    Performance. Using pure OO techniques can really affect application performance particularly in large projects. For example, suppose you have a Customer object and a CustomerList object. When you load the CustomerList object it should just tell each Customer object to load itself and just add it to the collection. That means that each Customer object is going to hit the database at least 1 time. This may be fine if you have a few hundred customers. But when you talk about thousands you will definitely have performance problems regardless of the hardware. Because of this you need to be prepared to get away from OO when needed. We create special list objects that hit the database once or twice and populate the properties in the Customer objects themselves. This way I get some of the benefits from both worlds.

    Learning curve. When people start programming - especially for the web - they tend to learn a particular language and concentrate on it's syntax. This leads to coding in long procedures with little thought on design. It is hard to get someone who is used to coding "top to bottom" to start thinking in objects. For me this has been the biggest challenge; getting people to think in objects so that I can use them on web projects.
    Affordable Business Web Site Hosting by Geo Redundant Hosting
      0 Not allowed!

  12. #12

    Something to the side of caution

    I this there are pros and cons to both procedural and OOP, but there's also on important thing to keep in the back of our minds while we are writing such awesome modular code.

    Reusable, it's a double edge sword and can cut both ways. On one hand it makes our lives easier in that it is reusable on the other hand...
    Due to the nature of capitalism, and corporate profit we could very easily write a highly paid profession into a minimum wage job.

    This happened to many other industries in the past.

    The flow is like this, first programmers simplify code into plug and play blocks, then quantify (make many blocks of various functions that are as universally compatible as possible. In doing so the corporation can now reduce programming jobs needing highly skilled professionals to low paying jobs requiring works of general knowledge and average skill. The more plug in play, the less skill required.

    The result if we are not careful, our enthusiasm to build the ultimate code, could lead the the loss of our comfortable incomes.
    It's a pattern all to familiar to CEOs and Industrialists.

    I'm not saying we shouldn't create beautiful code. In fact that's impossible because for most of us, It's A Passion!

    I am just saying be mindful of what the consequences could be if we are too zealous with the wrong employers.
    We should all guard that salary we have come to enjoy.

    Thanks for hearing out my two cents.
      0 Not allowed!

  13. #13
    Join Date
    Mar 2005
    Posts
    246
    Was this thread really bumped after almost 10 years?
    ColoCrossing - Connecting Business
    Alex Vial | avial@colocrossing.com | 1.800.518.9716

    Enterprise-Class Colo & Dedicated Servers in BUF, CHI, DFW, NYC, SJC, ATL & SEA
      0 Not allowed!

  14. #14
    Sorry I was doing some research and on Pros and Cons and didn't pay as much attention to the date as I should have.

    It was a bit off topic and I will leip this post got back to RIP

      0 Not allowed!

  15. #15
    Join Date
    Aug 2001
    Posts
    4,537
    Quote Originally Posted by nexcess.net View Post
    Debates will rage on forever about how "good" or "bad" OO programming is and whether is actually helps or hurts (or makes no difference at all).
    Exactly, even though I always wondered what there is to discuss in the first place.

    Quote Originally Posted by nexcess.net View Post
    Any solid programmer can work wonders in procedural *and* OO based languages so much of the bickering over which is better is really moot IMHO.
    Precisely.

    OOP is just another representation of code, and can help - in certain cases - for a somewhat better readable code for the developer. There is nothing you can do in OOP which you cannot do in the procedural world.

    Every single OOP code is eventually broken down in procedural code where the "object" is simply passed as "handle" (to use a good old procedural term) in the first argument of the function.
    Sitemeer.com ● Multi-Location Service Availability Check
    Not just HTTP! Proper HTTPS support, detailed timing statistics and full IDN compliance

      0 Not allowed!

  16. Newsletters

    Subscribe Now & Get The WHT Quick Start Guide!

Related Posts from theWHIR.com

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •