What's so good about OOP?

I’m not sure that’s true. I think I’m right in saying that the extreme programming methodology begins with the idea of “do some code first to build a prototype, then think hard once you’ve got there”.

You thought wrong :wink: XP is for sure not what you think it is.

Read this Extreme Programming: A gentle Introduction

I get the thinking of OOP (and N-Tier) development (I think ;)), but I got one problem with OOP: How to store the data.

OOP is about thinking in objects. I have this on paper (please correct me if this is wrong or could be better):

Article

+Subject
+Body
+Date
+PostedBy
Get()\Set() methods
Send()

Memo extends Article

+SendTo
+SendCopyTo
Get()\Set() methods
Send()

News extends Article

+Source
Get()\Set() methods
Send()

How do I put this in a database?
Should I take one table and set the field not needed for the current record to NULL (Takes a lot of useless space a think)? Can you give some hints how to store this the correct way in a RDBMS?

(Remembering what I read from Martin Fowler’s Patterns of Enterprise Applications :)):

There are three methods to map class inheritance to database tables:

[list]
[]Single Table Inheritance
You’d have one table ‘articles’ which holds both memos and news items. In that table you have a field which holds a typecode for the class, something like a field called ‘type’ with possible values ‘news’ and ‘memo’
[
]Concrete Table Inheritance
You have one table for each concrete subclass, i.e. two tables ‘news’ and ‘memos’.
[*]Class Table Inheritance
You have one table for each class in the class hierarchy, ‘articles’, ‘news’, ‘memos’. Each table for the subclasses (‘news’ and ‘memos’) have a field which relates them to the parent table (‘articles’), something like articleID.[/list]

I think in your situation, using Single or Class Table Inheritance would be a bit of overkill. Using one table for each subclass, news and memos, would probably be the best solution.

Captain Proton, thank you for your answer :).

I’m going for Class Table Inheritance, because I think it fits more to the thinking of classes and is more flexibel for future changes. The only thing that was holding me back from OOP was the datastorage. I have the feeling that OOP and RDBMS (normalization) doesn’t mix well, but your anwser changed that. Not completely, but enough to start changing my projects to OOP.

Voostind, a read a lot of articles about OOP but your explanation is clear, complete and better than what a read before. Thank you for your time to write this. It helped me a lot :). (Don’t get why this is not already made into article on sitepoint;))

Originally posted by Remy
I’m going for Class Table Inheritance, because I think it fits more to the thinking of classes and is more flexibel for future changes. The only thing that was holding me back from OOP was the datastorage. I have the feeling that OOP and RDBMS (normalization) doesn’t mix well, but your anwser changed that. Not completely, but enough to start changing my projects to OOP.

I have a solution suggestion for the datastorage thingy.

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.

You could also serialize the objects by using WDDX (outputs a XML document) and store that in the DB (with a unique object ID as Primary Key)

Originally posted by KillaByte
You could also serialize the objects by using WDDX (outputs a XML document) and store that in the DB (with a unique object ID as Primary Key)

Smarty-pants! :wink:

So you have a record in some table, retrieve that to store it in a PHP object, and then use WDDX and overhyped XML to store that same record back in that same database? :confused:

Right!

Vincent

Originally posted by voostind
[B]So you have a record in some table, retrieve that to store it in a PHP object, and then use WDDX and overhyped XML to store that same record back in that same database? :confused:

Right!

Vincent [/B]

Yes? I don’t see the problem with this.

Yes? I don’t see the problem with this.

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

Originally posted by voostind
[B]

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 [/B]

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?

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.

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.

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 :D)

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

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.

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?

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.

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… :wink:

Vincent

Originally posted by voostind
[B]

… 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)? [/B]

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.

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