Jump to content

Archived

This topic is now archived and is closed to further replies.

emehrkay

Whould it be expensive to set new instances of objects to return's data fields?

Recommended Posts

Example - I am returning data for an event that has the following fields:

 

title varchar

start_date datetime

registration_date datetime

details text

 

so for my datetime fields, I would set the result new Date() so that I could run something like calling a method in the Date class

 

$row['start_date']->shortDate();

 

This isnt a new, I didnt invent the idea, but I would like to know how expensive it would be if it were applied for most of the rows in a result set (dates would get the date object, text would get the parseText obj etc), but for multiple rows of data. Say I am returning an array of 100's of arrays all of which have instances of classes as the values, is that too much, or is it done all the time?

 

This would make it a lot easier for a developer, but I am worried about the overhead.

 

Thanks

Share this post


Link to post
Share on other sites

The easiest way to think about this is how JavaScript treats its data. Everything is an object and because of the prototypical nature of JS, every object has access to all of the methods in that object's family;

 

ie

 

String.prototype.myAlert = function(){

alert(this);

};

 

var x = 'hi';

x.myAlert(); //alerts hi

Share this post


Link to post
Share on other sites

Pretty interesting idea.  I'd assume that it would be relatively expensive if you don't clean up the objects after each row is processed, but I could be wrong.  You might want to try out some speed tests.

Share this post


Link to post
Share on other sites

Sounds to me like static methods would be the most efficient since you wouldn't have to instantiate and have loaded so many instances, but that would be ugly.

Share this post


Link to post
Share on other sites

Sounds to me like static methods would be the most efficient since you wouldn't have to instantiate and have loaded so many instances, but that would be ugly.

 

That's what I've been doing. And my class names are kinda long - Utilities_Date_Base::shortDate($val); I guess it wont hurt to try it out and see what happens

Share this post


Link to post
Share on other sites

You can use a combo of the Flyweight and Value Object patterns. Simply put, that means you reuse objects that are identical by Value Object standards. If your result sets contain a lot of duplicate data, this can save you a ton of resources.

 

Also, use a result set with Lazy Initialization. It's just a wrapper around the native result set, that creates the Value Objects on demand. This is pretty easy to implement and may save even more than Flyweights. Remember that it is better to pull back a little too much from the db than a little too little.

Share this post


Link to post
Share on other sites

You can use a combo of the Flyweight and Value Object patterns. Simply put, that means you reuse objects that are identical by Value Object standards. If your result sets contain a lot of duplicate data, this can save you a ton of resources.

 

Also, use a result set with Lazy Initialization. It's just a wrapper around the native result set, that creates the Value Objects on demand. This is pretty easy to implement and may save even more than Flyweights. Remember that it is better to pull back a little too much from the db than a little too little.

 

Do you have anything on Lazy Initialization? I like your stuff, I read it all the time.

 

Thanks

Share this post


Link to post
Share on other sites

Shit man. Lazy Initialization just opened my mind to a hell of a lot of ideas. I have a registry class, lets say that I store an array of instances of the Date object with a certain date being the key. If I pull data from the DB and that date object already has an instance (key value pair in the registry), i just use it, if not, create a new instance and store it.

 

I recently read about memoization in JavaScript and I didnt think to apply it in this way. Design patterns rock, there seems to be an answer for whatever you're trying to do.

Share this post


Link to post
Share on other sites

That's Flyweight, not Lazy Init. Combined you could do something like this:

 

1. Date (and the like) is a Value Object

 

You can't change the internal value. If you use a modifying method (ie add(Date $date)), you get a new object. The Value Objects use a Factory.

 

2. The Factories use a Registry (or just a basic hash table -- slightly more efficient)

 

This allows reuse of objects that are identical by Value Object standards.

 

3. Your database access package features a ResultSet wrapper class, employing Lazy Init.

 

It's just your basic wrapper class, that uses the same Value Object Factories when an item in the ResultSet is requested. This class is a good candidate for the SPL Iterator family and the magic methods.

Share this post


Link to post
Share on other sites

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.