Hey---

Recently I took a look at what goes into phpBB forums. Objects, classes, methods, everything!

At the time, I was trying to integrate the forums and knew nothing about OOP. After an emergency visit to my PHP book, I was able to understand the notation.

But, I still have one vital 3-part question, that applies to all programming, not just PHP.

a) How do I make effective objects, classes, and the like? Because I could declare a new class and fill it with mindless dribble very easily. But, rolling into part b, how do I know what to put into classes?

b ) And, when would I declare a new class and create a new object? I know when, as in the portion of the code, but not when OOP becomes useful.

and, most importantly,
c) WHY? Why would I use objects? From what I can tell, methods and properties are just functions and variables / constants that belong to a specific class.

E.g., how is declaring a bunch of functions, and marking them off with a certain prefix db_myFunction() any worse than $db->myFunction()

This is really something that's been bothering me. I mean, what's the big deal about OOP? I understand the how-to part, but not the why.

Thanks,
-Spear

~~~~

PS - As I understand it, all languages have different terminology for the same things (although I'm only familiar with PHP), so sorry if my terms are not what you're used to dealing with.

This post has been edited by skyhawk133: 21 Apr, 2008 - 02:20 PM

As a general rule, OOP should be used to model things - and how they behave. For example, a Person class might have methods like speak(), eat(), save_money_on_insurance_by_switching_to_geico() - but if you were then to need to model a dog or something, you would need a different class - dogs don't need insurance.

Whether OOP is useful or not has been an ongoing argument since its inception. Some people swear by it; others do not. Realistically, you figure out which approach works for you and/or your current project, and you use that one. The best approach for one task may not be the best approach for some other task.

Generally, you'll want to put code that you'll be re-using(whether in another project or another area of your program) into a module.

Hope that helped.

This might be better suited for the software development forum, but the answers you seek are rather simple.

I will start part B and roll back into part A.... Objects mimic real life or theoretical objects. You know you need a new class when you are trying to mimic something you might hold in your hand or any concept that seems solid. A file could be a piece of paper with properties like color, lined or not lined, 2mm thick etc. It could also be a computer file which has a date created or date modified property. If it makes sense for a bunch of functions to be bundled together into a logical chunk to form an object, then you know you have to make a class.

Now for part A... you make effective objects when they accurately describe the properties and actions of the object you are trying to describe. They are also effective if they are complete enough to mimic the object but not so extensive as to mimic unnecessary functionality. Going back to our file object, it is good to have properties for when it is created and modified... that may be very useful in the context of a content management system and it wouldn't be useful to know that it was 2mm thick because that doesn't apply to electronic files. But if your object is in the context of the real world and your file object is to mimic a piece of paper, then 2mm might be relevant...not so much when it was created.

Part C... you use objects only for the human mind. We think of everything in terms of objects... both we can see and touch as well as theoretical principles like the concept of an electronic file. We use these objects when we mentally categorize its relationship to other objects. We might group a stop sign in with things that are red, red meaning danger or warning, we also categorize it with shapes... an octagon with 8 sides. Knowing it is red, eight sided and maybe relates to our idea of transportation, we can quickly figure out it is a stop sign.

Computers could care less about objects. It only looks at the hard code instructions we pass it. Objects are merely for humans to grasp the concept of how different parts of a system relate to one another. That is why it is easy to see from Parts A and B that the more accurately we can describe an object and bundle its functionality into that object, the easier it will be for us to look at a class called "StopSign" and know it probably has properties of being red and belonging to a subsystem that might deal with traffic signals or transportation.

Objects are pretty much a package that bundle properties and functionality together. Not all data about the object will be known either. Some info may be hidden away in the object needed to carry out the functionality it contains but also not of your concern to know. This makes objects a more simplistic concept for us and reduces complexity. Why worry about the details of how an electronic file's date created property is implemented? All we care about is what it represents to the system.

Remember, the job of a function is to only know how to do one thing and do it well. It is a building block to bigger things. If you see a function called stop_sign() what would it do? You would have to look at the contents of the function to know. How would it implement the property of being a color like red? What if we are creating a traffic grid system and want multiple stop signs but one red, one yellow, and one green (we have a crazy system I tell you)?

I hope I have helped clear up the confusion.

This post has been edited by Martyr2: 21 Apr, 2008 - 12:35 PM

Thanks Martyr. Sorry about the placement, I really didn't know where to put this thread.

So, essentially, OOP clears the way for a 3-Tiered organization system?

For example, all tables in my database that have to deal with phpBB have the prefix "zz_". So when I see "zz_", I know that it's phpBB stuff.

Now, let me make sure I'm understanding this right. A 2-Tiered system could be done just as easily by:

as
.

But then that system runs into problems when you start dealing with a "bigger picture". As in,

is confusing compared to, but just as serviceable as,


Is this right? I find that explaining a topic myself is the best way to make sure I understand it.

Essentaily yes, but I dont think you have to use OOP to use a multi tier desing (correct me if Im wrong here Martyr). Being able break an app into logical pieces (ie Classes and Obeject) allows you break down your layers. Im still pretty new to multi-tier development, but at my work we always use a 3 tier design. And OOP allows us to create a separate DAL (Data Access Layer) for our projects. So when working in BLL (Busininess Logic Layer) in order to work with our data we simply use a method from the DAL. It makes everything very clean.

Heres a question for Martyr since I am still kind of new to multi-layer design (although I feel I have a pretty solid grasp on OOP).

In my organization we use only stored procedures for any data work for the security purposes. Now would that theoretically be another tier making it a 4 tier design like this:

Presesentation Layer - aspx
BLL - Code-behind
DAL - Separate class with all data connections and methods that use stored procedures
Stored Procedures themselves - Could this be considered a fourth tier?

This post has been edited by Sonic88: 22 Apr, 2008 - 07:38 AM

I don't know if its safe to say that OOP is meant for a
First and foremost, OOP is meant to be an abstraction as Martyer points out. It is meant to encapsulate logical
groupings of things.

It fosters a viewpoint of thinking with objects instead of functions and variables. I don't think that
an N-tiered design necessarily has anything to do with OOP. I can create a DAL, and a BLL all without
the use of OOP, just by good ol functions. Take a traditional DLL as an example.

Skaoth, sure, you can create a 10 tiered organizational system with functions or constants.

For example, you could follow the pattern: industry_chain_store_brand_productType_product_size.... where food_wegmans_092_quaker_cereal_cinnamonLife_jumboPack.... follows that patter (I don't know, you're listing prices?).

But that's a lot more complicated, to me at least, when you compare it to objects and classes.

~~~

Regardless, with the thoughts that Martyr planted in mind, I reread the chapter on objects in the book. And it makes a lot more sense! The real value appears to be when you're trying to group things together, for example the posts in a thread on a forum.

This post has been edited by spearfish: 22 Apr, 2008 - 03:02 PM

I use OOP thought when I'm planning out code. I've noticed several companies have this a requirement to apply

"must appreciate knowing when not to use OOP"

Which is a good lesson for all of us I think.

Using OOP for Hello World might be overdoing it a wee bit.

Hey, guys-who-know-OOP-for-PHP, did I do that right?

Just to say, I find object oriented programing a waste of time. Instead, I seperate my code into sections with blank space, and put coments in the gap to create a pseudo-oop idea for myself so i can understand it. I don't, however, see any use in bothering with additional syntax and other modifiers for functions and variables and the like just for the sake of understanding when you can simply comment it. I swear by the KISS principal. If i need variables to be accessed by more than one function, i global-ify it, instead of making classes around the differant functions.

Thats all.

Using too many global variables is bad practice though. If variables are accessed and passed only by functions who need them, it can help debugging later.

I can get around that by passing variables by reference.