What's so good about OOP?

[M. Johansson]

Originally posted by voostind


You don't? Or are you kidding?

Method 1:
- Connect to the database
- Execute a standard selection query
- Retrieve a record, store it in an object
- Use the object in code

Method 2:
- Connect to the database
- Execute a selection to get the XML record
- Retrieve the record
- Parse the XML (yuk!)
- Store the record in an object
- Use the object in code

Which do you prefer?

Note that method 2 isn't even correct, because you should still execute the original query as well to make sure the duplicated XML record isn't invalid.

Vincent

Oh, there is an original table of data? In that case, storing objects would be very stupid as that would be double storage, a big no-no for databases. However, storing objects directly in the DB don't seem so bad besides the XML parsing involved. Unless you need to execute SELECT queries and the like with WHERE contions on anything else than the ID - then you are screwed, I guess.

I guess my original proposed solutiuon was better, then.

As a sidenot, I've heard that there are databases that can store objects directly - has anyone used or know of these things?

[firepages]

If you are going to serialize an object in PHP then just serialize it.

serialize($yaks);

then when you
include 'yaks.class'
$obj=unserialize($yaks) ;

your object is rebuilt and ready to use , it does not get any simpler than that, parsing to and from XML makes no sense whatsoever unless you intend to serve XML content in which case you can pull as XML if required.

storing a serialized object in a database makes about as much sense as storing images in a DB, i.e. none , the only manipulation you can perform is a fulltext search or get by ID which is what filenames are useful for ,perhaps storing some keywords in the DB ? may be useful with your serialized data saved to disk, but you may as well have the data in the DB as per normal and save the hassle.

I have heard about OOP databases as well but thats about all.

[KillaByte]

Yes, there are object oriented databases - when you use them you don't have to fiddle around with converting from the OO model to the relative model before inserting into the DB.

There's also object-relational databases - Postgres is one of them.

The biggest drawback on serializing objects versus converting to an relational model is that unless you de-serialize the object you can't access any of it's properties (and therefore you can't do such things as fetching only the objects you need from the DB by putting something in the WHERE clause of your SELECT).


@firepages:
With WDDX you need no parsing (at least you don't have to do it yourself) - you serialize the object and get the serialized object as XML-String. When you take that string and pass it to the de-serializing mehthod you get your objects back.

[voostind]

Oh, there is an original table of data?

Ah, I guess this was the reason we were arguing. I was under the impression some record from some tabled was copied to a record, and then copied back into the database, but then in XML.

storing a serialized object in a database makes about as much sense as storing images in a DB, i.e. none

I wouldn't say that. A system I have built for generating web sites does a lot of serializing: after creating an object used in a page once it is cached. When it is recreated it is immediately initialized, so all initialization steps can be skipped (config parsing, config checking, environment checking and so on). Instead of storing these cachefiles on disk it can make a lot of sense to store them in a database.

Using XML to do that, is of course, useless. Sure, XML has its uses, but not as many as people seem to think nowadays... I guess it'll blow over.

Oh, and for more information on ORDBMs (Object-Relational DBMSs), see PostgreSQL: http://www.postgresql.org. (You mean it's not only an excellent relational database system - unlike MySQL - but it's an object database system as well? Yes, indeed )

In an ORDBMS you can define your own datatypes. These types can than be used in table definitions as normal, built-in types. Compare this to OOP: once you've written a class, you can use it like normal, built-in datatypes (strings, integers, ...).

Vincent

[HarryF]

Just as an aside, ran into an interesting Java project recently: http://zsqlml.sourceforge.net - does quite a few things including generating Classes for accessing the tables with.

Strikes me that constructing solid classes for access MySQL from PHP is extremely important, given that it's PHP which has to ensure relationships between tables are maintained correctly.

As a side note, I've heard that there are databases that can store objects directly - has anyone used or know of these things?

Are you talking about database object relational mapping?

In general storing any object in a database is not a problem, using some kind of serializing of the object. I can imagine this being useful if you have an application where users can store their current state before logging off, for example

But that not what object-relational mapping is about, which is basically constructing a relationship between a database schema and a collection of classes to access it with. That's more or less what Captain Proton was talking about I think, when quoting Martin Fowler.

[Remy]

voostind: I wouldn't say that. A system I have built for generating web sites does a lot of serializing: after creating an object used in a page once it is cached. When it is recreated it is immediately initialized, so all initialization steps can be skipped (config parsing, config checking, environment checking and so on). Instead of storing these cachefiles on disk it can make a lot of sense to store them in a database.

Thats the only reason I see for serializing objects and storing it in a database, for caching.

M. Johansson: I guess my original proposed solutiuon was better, then.

M. Johansson: Essentially, have a property in your class called ID or DBID, or something like that. Then, have two methods called DBLoad() and DBSave(). The methods use the ID property to save/load data from the database based on the ID property of the object, which correspons to a index key column in the DBMS.

It is not clear to me what you mean, but I think you mean serializing and storing it in a RDMS with a ID but thats IMHO only for caching a option.

HarryF: Strikes me that constructing solid classes for access MySQL from PHP is extremely important, given that it's PHP which has to ensure relationships between tables are maintained correctly.

Its one of the points I dislike about MySQL. The database should take care of this. One big plus of this, you can easly switch to other storage like txt-files.

voostind: Oh, and for more information on ORDBMs (Object-Relational DBMSs), see PostgreSQL: http://www.postgresql.org.(You mean it's not only an excellent relational database system - unlike MySQL - but it's an object database system as well? Yes, indeed )

I will look into this, but at this time it is not realy a option for me. I use MySQL to develop and MSSQLserver to test an go operational. MSQLserver doesn't support this (if I am correct).

It have to be stored in MSSQLserver and shoud have the possibilty to connect to it without PHP (only SQL) to retrieve the data if needed. So the only way to do this is with Single Table Inheritance, Concrete Table Inheritance or Class Table Inheritance? I'am correct about this or are there other ways?

[M. Johansson]

Originally posted by Remy
It is not clear to me what you mean, but I think you mean serializing and storing it in a RDMS with a ID but thats IMHO only for caching a option.

No, my method doesn't serialize the object at all. All that the aforementioned DBLoad() and DBSave() does is to take the property values of the object and write them to the DB table. No serializing involved.

[voostind]

No, my method doesn't serialize the object at all. All that the aforementioned DBLoad() and DBSave() does is to take the property values of the object and write them to the DB table. No serializing involved.

... And you use XML to do so, right? Which do you think is faster: calling 'serialize' and 'unserialize', or constructing and breaking down an XML structure (with WDDX)?

But to be honest I shouldn't ask you this question, as you didn't come up with using XML for this in the first place...

Vincent

[M. Johansson]

Originally posted by voostind


... And you use XML to do so, right? Which do you think is faster: calling 'serialize' and 'unserialize', or constructing and breaking down an XML structure (with WDDX)?

XML? I've never really fancied XML that much except for Web Services. I imagined the DBSave() method to basically just store the object variables directly into the table with an INSERT/UPDATE statment.

[petesmc]

I know this thread is a little bit old, but it is extremely useful, and I'd just l ike to point out an observation with OOP. I used to be a PP as couldn't see a single benefit of OOP, then, one day, it just clicked, I saw all the benefits for an idea I had, then started working on it.

I think with OOP you need to read alot and try to grasp the main ideas and concepts, then one day it will just click. At the moment I wouldn't consider myself a good OOPP however, I understand the main ideas now.

-Peter

[Mincer]

Originally posted by petesmc
I know this thread is a little bit old, but it is extremely useful..*snip*

I actually have this thread bookmarked in my main bookmarks folder.

I generally use it to point people at for an explanation of OOP (cheers Vincent, saves my typing ).

Matt.

[malmi]

So when should I consider using OOP, and when must I avoid it?

I thought about it a lot and that's what I came up with:

There is no simple answer. It is possible to write an exceptionally good software using both techniques OOP as well as procedural.

It looks to me though, that OO approach provides better way to organize my software into building blocks - components. That helps me to accomplish my projects in shorter time and it helps me to communicate my ideas to other people.

But what classes do I need and what I don't? That's where it gets tricky!

My advise: think for your self and experiment, experiment, experiment!

[skeeterbug]

i'll add my thoughts in the hope they may benefit someone and that i'll get some feedback if i'm thinking looney.

major prinicple #1 - repeating code is not good. repeating code that may change in the future is bad. repeating code that will change in the future is reason to get your resume out - now! -lol-

i see a loose anology between OOP and database normalization. break the entity down to to its basic blocks. just like you can over normalize a database in some instances (or so i have read), you can probably over OOP in some cases, too.

in OOP you think in terms of the things some code does and then break it down to the unit level.

that doesn't seem too hard, actually. once you envision that, then it is just a matter of learning the PHP OOP mechanics of getting all the small parts to work together.

if the OOPed to death (within reason, if the idea isn't mutually exclusive) code is unacceptably slow, verify it is OOP that is causing this and decide if h/w can solve make the speed acceptable, if not very good for less than it will take you to un-OOP the code (and risk being wrong about the cause of the slowness). if the code is running nicely... you are living large.

also, think forward. assuming PHP's OOP process isn't optimized to an acceptable level right now, do you expect this to always be the case? do you want a ton of procedural (repeating code!) laying around in 2 years?

anyway, that's my thought process. database normalization *just makes sense*. using PHP includes for repeating code (or functions) *just makes sense*. i think that OOP *just makes sense* as well.

i will have to learn the mechanics, though, and this thread is a great start. it can't be nearly as hard as hacking css to work with all the top browsers! -lol-

having said that, i'm off to review my code to make updates!

[Dylan B]

Holy Old Thread, Batman!

[skeeterbug]

Holy Old Thread, Batman!

how did i get here? not used to asking that question *prior* to drinking some beers! -lol-

[karnetics]

I have seen some app use the define() to include and file or path just like and include() would to... How would I set this up... This is what I tried and I do not know if it is right or not

define('FILE', "/text.txt"); 

[karnetics]

I have seen some app use the define() to include and file or path just like and include() would to... How would I set this up... This is what I tried and I do not know if it is right or not

define('FILE', "/text.txt"); 

sorry wrong post!!