The Cache: Technology Expert's Forum
 
*
Welcome, Guest. Please login or register. September 17, 2019, 06:06:46 PM

Login with username, password and session length


Pages: [1] 2
  Print  
Author Topic: a discussion on OOP  (Read 9877 times)
itchy
Rookie
**
Offline Offline

Posts: 12



View Profile
« on: May 12, 2007, 08:31:21 PM »

ok i've found myself at the point of learning to program that i've come across OOP especially in php but i wanted to keep this discussion more general than any specific language. you see the thing is i don't get the advantages of using OOP. functions yes, that little step in the curve really got my programming organised and tidier. obect oriented, no. it just feels like i'm learning to program from scratch again. new syntax for both making classes and instantiating variables,etc,etc..
so whats the point of learning to program this way. i mean i can read, use and edit other people's classes/objects if i need to but i don't see more of an advantage to say using include files and functions.
why do you program object oriented?
Logged

No links in signatures please
Bompa
Administrator
Lifer
*****
Offline Offline

Posts: 564


Where does this show?


View Profile
« Reply #1 on: May 13, 2007, 02:48:47 AM »

LOL, I hear yah.  I really don't like OOP in perl.  It's flaky and the modules are not well explained anywhere on earth.

I use perl OOP cuz I have to, heh.  The only perl oop I use, (almost), is LWP which is the web client "simulator".
My alternative would be to get into low level socket programming.

I have a real hard time understanding the terms "classes", "objects", and "methods".  I have read the
explanations many times.

In perl, there are modules that make big promises, but do little or nothing but waste my time, mechanize come to mind.

OOP evolved from more basic techniques and now it's the "in" thing.  Cheesy

Of course, if you are familar with a perl module or php class, using it can save a huge amount of time.

Many perl experts have told me "use the modules, don't reinvent the wheel".  bullshit!

There are those that are content to just drive a car and there are those that need to take the engine
apart and reassemble it.

dig?

in other words, i dunno,
Bompa

Cheesy

Logged

"The most beautiful and profound emotion we can experience is the sensation of the mystical..." - Albert Einstein
m0nkeymafia
Expert
****
Offline Offline

Posts: 240


Check it!


View Profile
« Reply #2 on: May 13, 2007, 02:56:00 AM »

OHHHHHHH BLASPHEMY Smiley

Im an OOP nut, oop simply rocks when used properly.  The reason it works so well is because it models not only the way your brain stores information [loosely of course] but also real life.

I must point out that i never use OOP in php.  Namely because im a slack php coder Tongue but in C++ and other langauge oop is the only way.

Say for example you are creating a project to display a number of objects on the screen [i will use c++ as reference]
So you know you want X number of objects.  All of them will need X and Y coordinates, and maybe a vector to describe any movement they may have.  If we dont look at the display side of thigns we can see straight away that each of our display component has at least 3 things in common.

So we put them into a class, say VisibleObject which encapsulates those methods and variables.  Meaning we KNOW that if an object is a visibleobject it will have coordinates etc.

So not onyl have you saved yourself a few hours work worrying about typos you also can check if an object is a visible object.

For example you may have a list of objects, some visible, some other objects, helper objects or something.
How can you tell which ones should be displayed and which ones should not be?
Easy you can cast each object in your list to a visibleobject type, if they are a visible object you will get the visible object portions of the object, else you get nothing.

I know this may be hard to understand, and what ive mentioned is very limited in its use of OOP, but my aim was to try inspire you to look further into OOP and how it can be used to reinforce your coding integrity AND save you time
Logged

I am Tyler Durden
thedarkness
Lifer
*****
Offline Offline

Posts: 585



View Profile
« Reply #3 on: May 13, 2007, 03:32:30 AM »

I'm with monkey on this and I'll offer another perspective (this is why you use LWP Bomps);

Say I have a browser object (class), I can put this code in ANY program that needs to grab a URL;

$myBrowser =& new Browser();

$response = $myBrowser->get( $target_url );

And I know $response is going to contain the target page every time. It has already been debugged, tested, used many times. IOW I am leveraging not just someone elses code in a simple package but all the dev, debugging, testing. Yes, the same advantages could be acheived with procedural code, function library perhaps, but it would not be as easy to use or distribute. You'll see that a lot of the stuff posted is in classes, I don't think I would be as likely to use one of perk's peices of code if they were an aggregation of functions rather than a class.

Of course there are other advantages, some of which monkey has touched upon, some which have not been touched upon such as code obfuscation and "data hiding" the concept of private parts of an object which are for internal use only.... etc.


 

Cheers,
td

Logged

"I want to be the guy my dog thinks I am."
 - Unknown
nutballs
Administrator
Lifer
*****
Offline Offline

Posts: 5627


Back in my day we had 9 planets


View Profile
« Reply #4 on: May 13, 2007, 08:07:05 AM »

i actually am going to side with the OOP is a Meh side, most of the time.

I do alot of code repair and system retooling, and i gotta tell you, people use OOP way too much, for no reason, and make things way more complicated than it needs to be.

for example, in asp, the common way to create a connection to a database in ADO is this chunk:
Code:
set db=server.createobject("adodb.connection")
db.open yourbiglongconnectionstringfromaconstantsomewhere

thats it. 2 lines. yet... I see people wrap that in a stupid class, so often its become a joke to me. it makes the code less readable, to save 1 line of code. it also causes 1 extra parse level (create and object, which again creates and object).

now....

where this does make sense is when you have a "thing" that you need to work with repeatedly, over time, and might have different statuses, modes, values, etc, every step of the way. to use a car as an example. the cruisecontrol function.
cruise = new cruisecontrol
cruise.set = 50
cruise.currentspeed = speedometer.speed
cruise.adjustspeed

these are all related controls of the single concept of cruisecontrol. so it makes sense.

but i find more often than not, that OOP gets in my way when doing the coding I do, both my own web development and my code repair work. however, this could just be a side effect of the type of work I do. web stuff tends to be 1-off functions most of the time. and repair stuff is web as well.

but if I was writing a game for example, OOP would be my jesus probably.
Logged

I could eat a bowl of Alphabet Soup and shit a better argument than that.
m0nkeymafia
Expert
****
Offline Offline

Posts: 240


Check it!


View Profile
« Reply #5 on: May 13, 2007, 10:14:07 AM »

Good point, using OOP for the sake of OOP just defeats the point.

I think possibly the best use of OOP in php that is easily accessible to those learning is php mailer of freakphpmail
i forget but its on phpfreaks or something

They extend the main phpmail class beautifully and simply to save you constantly re-entering info
Definately worth a read, sorry youll have to google it i cant remember its exact name Tongue
Logged

I am Tyler Durden
perkiset
Olde World Hacker
Administrator
Lifer
*****
Offline Offline

Posts: 10096



View Profile
« Reply #6 on: May 13, 2007, 11:42:18 AM »

This is going to be a great discussion. The question, is why OO programming is superior to virtually every other methodology in practice today.

First off, let's get entirely away from programming for a moment and talk about an office environment. In a normal office, you have a variety of workers that perform tasks. We use EMails, IM, meetings and most specifically English to interact and discuss what we need from each other to accomplish the overall goal. I think it's fair to say, that most often, the sales department is equally important to the engineering department, but neither really understands the ways that the other work. Let me be more precise: if the salesmen have been using "Act" for their customer contact information and choose to change to "Goldmine," should this even remotely affect the engineers? If the engineers stop using a straight-line perspective mechanism for their designs and go to a 30 degree flat perspective, should this affect the salesmen? Moreover: if a salesperson is underperforming, and the management decides either to grow the staff or replace the unproductive element, should that affect engineering? Even more specifically: should the engineering department have *any say whatsoever* in how the sales team should be doing their job?

In OO methodology, we use the term "encapsulation" to ... ah ... encapsulate this thinking. The notion is that a "thing" knows how to do it's job, it has the tools do do it's job, the mechanics of how it does its job is hidden from anyone else and noone else can get in and mess with how the job is done. This is a VITAL component of OO thinking because of the size and complexity of systems. My second retail framework (still online today and doing fine) is over 200K lines - spanning from marketing to operations, inventory management, email blasting, robust, capable and quick web sites, back office management consoles and telemetry... if that was one huge monolithic program I'd just be RATFUCKED if I changed a variable name - who knows what else I might be screwing up? For the same reason that physicians cannot entirely predict the affect of a new compound in the human body (take pill for headache, toe hurts...?) the Windows team has a monumentally difficult task understanding how the input of a new variable affects the entire system. So, using encapsulation we can know that an object's job is wrapped up tight and unfuckwithable by any other object.

Encapsulation also offers a magnificent programming advantage for folks like me that have to handle lots and lots of code. When I can "wear the hat" of a particular object's perspective knowing 100% that my only responsibility is to <that> object's functionality and it's relationship to the world, I can quickly and easily get my arms around "the entire scope" because the entire scope is so much smaller than the entire application. In that way, I can create systems that are vastly more complicated than I've ever even dared to dream.

Back to our office for a moment, let's talk about the legal team. When we started our business we only needed some general legal counsel, so we got basic lawyers. But as engineering started to created more creative things, it became apparent that we needed more specific strengths, so several lawyers went to school and added patent law to their educations. Later, because of the nature of our business they also needed to get additional strengths in certain elements of technology and technical patent law. We were able to grow the capabilities of our lawyers without losing any of the previous skills they had - the took what they new about law, and were able to add to it.

In OO this is called inheritance. The stucture of a class hierarichy is such that you can build upon code that you've already written without having to redo it, and yet take full advantage of what you've already built. Here is an example of a class hierarichy I have for a request/response mechanism I use. This class structure allowed me to write code that interacts with credit card processing, other folks web APIs and a variety of travel vendors with extremely little modification. And when I discovered that I fundamentally missed a critical piece, I was able to add it to the root class and all decendent classes instantly were able to take advantage of the upgrade. Here is the breakdown:

requestorBase
   structuredRequest
      socketRequest
         secureSocketRequest
            merchantProcessingRequest
               linkpointRequest
      httpRequest
         httpsRequest
         travelBaseRequest
            [vendor]Request
            [vendor]Request

In this structure, Ive placed the most essential elements of a request/response interaction into the requestorBase. This includes function declarations for dispatch and receive, variables to hang on to the last sent and last received valus and other maintenance items. The structured request adds to that the notion of request and response parameters, as well as events for handling/validating each. Note here that this class does not *implement* them, it describes their existence and interaction side of all decendent classes. The socket class and http class (on the same level) add the functionality of understanding talking in either a straight socket way or in an HTTP way. of course the child classes in each of those separate lines add a secure layer to them. Finally in this tree we can see some real specificity occuring: a merchant processing base adds the notion of secure keys, amounts and some validation points I need to talk to merchant processing gateways - I've called out one of them, "linkpoint" which is my gateway when I transact over Card Service International - while the travel base adds some specifics for talking to travel content providers (SABRE, WorldSpan, various wholesale tour outlet databases) and finally the base request for each vendor, because each travel vendor has a specific type of details and idiosyncracies that I need to deal with.

So: I need to add logging to my requests because I want to see the entire log of interactions: I added it at the requestorBase level. Kerpow, it's available to every class in the tree instantly. I wanted to add a particular type of date parameter to my requests - it goes in the structure level. You see what I am getting at here - additions and upgrades appropriately placed along the tree makes it so that all classes decendent get the benefit.

The last real tenent of OO thinking is polymorphism - which frankly is considerably more important in structured and early-bound languages like C++ and ObjectPascal than it is in modern scripted languages like PHP, becase PHP doesn't give a shit about what you ass (or eve IF you pass) params in the first place. The notion of polymorphism is that you can pass any type of value into a function and the function will accurately identify the type and do the appropriate thing with it. The most common example is the "StringValue" function - where you pass any form of primitave or object into a function and it will return the string value for that... be it another string, numeric, boolean, array... doesn't matter. Well today at least in PHP the polymorphic capability of a function is again, right in the fact that PHP doesn't care what you pass it - so you need to trap the type in code rather than at the object interface level.

OK my dissertation was way long winded, but important: the majority of people I speak with think that OO is a different syntax. Couldn't be farther from the truth: in fact, OO is a way of thinking that they needed to work *really hard* to get it back to a syntax that was understood by programmers. OO is a way of mapping the natural interaction of people and things in the world to programming languages. It is easier for me to envision a monumentally complex system if I can perceive it through the lens of "It looks just like a company" and then deal with the individual capabilities necessary for each member of my company to have, so that I can profit and prosper.

OO gets a bad name because of shit programmers, not because of what it is. Does it add bloat? No. Shit programming can make straight up functional programming bloated as hell. Does it sometimes mean more typing? YEs. Does it mean more thought up front? Hell yes - that's one of the things that makes it great. And n00bs take heart - there is an old truism about OO programming while you are learning the ropes: the 3rd time you build it is when you get it right. A bummer to be sure, but changing how you think to take advantage of this is both a bit time consuming and HUGELY worth it on the other side.

Trust me on that one...  Wink

/p
Logged

It is now believed, that after having lived in one compound with 3 wives and never leaving the house for 5 years, Bin Laden called the U.S. Navy Seals himself.
m0nkeymafia
Expert
****
Offline Offline

Posts: 240


Check it!


View Profile
« Reply #7 on: May 13, 2007, 01:25:18 PM »

What an explanation lol
Very well explained lol
Much better than my lame attempts lol
Logged

I am Tyler Durden
cdc
Expert
****
Offline Offline

Posts: 105


View Profile
« Reply #8 on: May 13, 2007, 03:24:42 PM »

If your entire project is over 250-500 lines of code, OOP is the way to go. Otherwise, I would say stick to just using functions. I agree with perk that OOP gives you a TON of good things, but you're never going to have the opportunity to use those things if your project is tiny.

The first language I really "got" was Java so I think in OO terms, but I haven't done any OO PHP code (even though there are a few projects where I really should have).
Logged

Will code for food.
perkiset
Olde World Hacker
Administrator
Lifer
*****
Offline Offline

Posts: 10096



View Profile
« Reply #9 on: May 13, 2007, 04:47:22 PM »

Agree CDC unless that project can be 50-100 lines because you make clever use of your existing class libs. This is why I spend a lot of time on my so that my actual applications are really tiny.

/p
Logged

It is now believed, that after having lived in one compound with 3 wives and never leaving the house for 5 years, Bin Laden called the U.S. Navy Seals himself.
itchy
Rookie
**
Offline Offline

Posts: 12



View Profile
« Reply #10 on: May 13, 2007, 08:11:25 PM »

great discussion and confirms what i was thinking with my current small scale programming base i think i'll just stick with my function library until things get to a stage when oop will really be a big benefit rather than converting it all now.
as for your comments about keeping it small with oop (@perk) thats kinda why i made the function library in the first place.simple function calls such as:
$urls = grabGoogleSerps($query,1000);
$result = doSomething($urls);
is keeping it small for me!!!! (but i know what you saying  Wink)

Quote
I use perl OOP cuz I have to, heh.  The only perl oop I use, (almost), is LWP which is the web client "simulator".

lol thats what took me down this path in the first place but i'll get to pseudo threads in another thread!
Logged

No links in signatures please
nop_90
Global Moderator
Lifer
*****
Offline Offline

Posts: 2203


View Profile
« Reply #11 on: May 14, 2007, 01:06:56 AM »

OOP is a catchy term that means little Smiley
I am still sick so i can not comment properly.
but encapsulation, inheritance etc,you are lead to believe that these only exist if u use classes etc.

function area("square",x,y)
function area("circle",r)
function area("triangle",b,h)

the advantage of a functional based system over OO is there are no side effects, sideeffects cause nasty bugs which are hard to detect, if not impossible.
you can see how a squares area is computed.
you get polymorphism still (depending on the language)
the string ("circle" etc) depending on the language would be a constant or enum

OO has its place, but for the most part is way too over used.
Logged
thedarkness
Lifer
*****
Offline Offline

Posts: 585



View Profile
« Reply #12 on: May 14, 2007, 03:20:33 AM »

great discussion and confirms what i was thinking with my current small scale programming base i think i'll just stick with my function library until things get to a stage when oop will really be a big benefit rather than converting it all now.
as for your comments about keeping it small with oop (@perk) thats kinda why i made the function library in the first place.simple function calls such as:
$urls = grabGoogleSerps($query,1000);
$result = doSomething($urls);
is keeping it small for me!!!! (but i know what you saying  Wink)

here's an opportunity to begin a transition to OO in a gradual way and protect yourself from namespace collision by employing another OO concept, the concept of the namespace.

Say you wanted to create a namespace called "itchylib", you can do this with a "container class" essentially creating a namespace thusly.
If you were to take a file of all your functions and put the following at the top;

class itchylib
{

and;

}

at the bottom of the file to close the container class you would then call your functions using the following syntax;

$urls = itchylib::grabGoogleSerps($query,1000);
$result = itchylib::doSomething($urls);

Or depending on the implementation you could create an instance of (instantiate) the class;

$thelib =& new itchylib();
$urls = $thelib->grabGoogleSerps($query,1000);
$result = $thelib->doSomething($urls);

There you go dude you've already created a useful class without even knowing it  Wink

As mentioned above, you get the added benefit that if you include a file with a doSomething() function in it you are protected against a name clash.

So, there you go, three lines of code in your function library file and your into OO  Nerd

Cheers,
td
 
Logged

"I want to be the guy my dog thinks I am."
 - Unknown
thedarkness
Lifer
*****
Offline Offline

Posts: 585



View Profile
« Reply #13 on: May 14, 2007, 03:36:36 AM »

Oh, BTW, this is the other thing OO excels at, wrapping up and distributing class libraries, vast amounts of code with plug and play interfaces.

In C++ take a look at boost, libcommoncpp2, libwww (intentionally not mentioning the MS stuff coz that would just be too obvious).

In PHP take a look at PEAR, I love PEAR  Smooch

Cheers,
td
Logged

"I want to be the guy my dog thinks I am."
 - Unknown
nop_90
Global Moderator
Lifer
*****
Offline Offline

Posts: 2203


View Profile
« Reply #14 on: May 14, 2007, 03:56:41 AM »

Gobject system, which glib and gtk based on,
http://en.wikipedia.org/wiki/GObject

if u have time to waste check it out to see how OO is made with C,
Also has signals too Smiley.
Logged
Pages: [1] 2
  Print  
 
Jump to:  

Perkiset's Place Home   Best of The Cache   phpMyIDE: MySQL Stored Procedures, Functions & Triggers
Politics @ Perkiset's   Pinkhat's Perspective   
cache
mart
coder
programmers
ajax
php
javascript
Powered by MySQL Powered by PHP Powered by SMF 1.1.2 | SMF © 2006-2007, Simple Machines LLC
Seo4Smf v0.2 © Webmaster's Talks


Valid XHTML 1.0! Valid CSS!