When to use OOP?

[phpfreak101]

I'm currently a freshmen in college, majoring in Computer Science.  We've been going over Object Oriented Programming in Java the last 2 semesters and I'd like to take take what I've learned and apply it to web programming (specifically php) that I learned on my own.  I'm just a little confused as to when to use OOP.  What situations or methods would be good to create as an object for web programming?  What areas of dynamic websites (database driven) do you find most useful to build as objects, rather than building them as traditional functions/methods.

[btherl]

A lot of it is down to experience.  You'll learn over time where objects are appropriate and where they aren't.

 

Too much abstraction and you'll have code that spends more time dealing with the OOP framework than actually doing the task it's supposed to.  Too little and your code will be difficult to debug, maintain and re-use.

 

A situation where OOP works well is Smarty templates.  Another is the SimpleXML object in php 5.

[Daniel0]

I think objects work great anywhere...

 

It's just a matter of personal preference.

[Captain_Pugwash]

I would go with daniel0

 

If you can turn it into a class( perhaps be refering to obejcts you haven't really grasped the core of OOP)  to be exact then do so. You never know where or when these may be useful for other applicaions.

 

PersonallyI have classes for form generation date, handling, database access as standard and these are imported automastically to every website I develop and boy does it save bucket loads of work. I'm currently working on a simialr routine for dynamic style sheets, but it's  a way off yet.

 

You know the service you want to provide, so you build the tools you need to provide that service, hence the expression a poor workman always balmes his tools. Rememebr he made the tools.

[joquius]

The bottom line with functions/objects/loose code is: If you use it once, it should be loose, if you use it a lot and it's static, use a function, if it's the core of your software it should be an object. The main idea is to keep away from using objects for everything. MediaWiki is a great example of OOP php.

 

Software actually runs faster with no classes and only functions, but it can become impossible to maintain. So you're balancing speed and maintenance.

[roopurt18]

Too much abstraction and you'll have code that spends more time dealing with the OOP framework than actually doing the task it's supposed to.  Too little and your code will be difficult to debug, maintain and re-use.

 

Good advice there.

 

As dumb as this sounds, use OOP when you're creating objects or things that have object-like behavior.  For instance, employees, jobs, parts of a framework, etc. are all objects; they are things you can imagine holding in your hand.  A library of common functions, such as disk I/O, can be an object, but chances are you don't want to have to create a new object (or use an existing one) every time you want to check if a file exists.  These types of utility functions are best organized under a namespace to avoid naming collisions; it just so happens that the only way to do so in PHP is with the class keyword.

[phpfreak101]

alright, i think that'll get me off to a good start.  I'm trying to start a web design/development company so this information is very helpful.

[Fergusfer]

Software actually runs faster with no classes and only functions, but it can become impossible to maintain. So you're balancing speed and maintenance.

 

Software runs faster without functions too.

 

Remember that developer cycles can be more expensive than server cycles.  Focusing too much on the fastest code execution can cost you more money than buying a faster server.

 

There is a maxim in software development that 90% of development time is spent on maintenance and extension, and these are the areas where a well-designed object-oriented application will shine.  Few things are as awful as badly designed OOP, so stay away from a major OOP project until you are confident you understand design principles.