I don't know the name for this pattern, so I'll refer to it as a "Temporary Object" (although it has different meanings in compiled languages). Basically, it's an object that expires after a certain amount of time passes. This may be set period from the creation of the object or the last access of the object. Good examples of temporary objects are "Remember Me" tokens, user sessions and captchas.
Edit - Feyd says they're called Temporal Objects. Well what do you know: http://www.martinfowler.com/eaaDev/TemporalObject.html talks about change control... hmm... we still haven't figure out the name.
These objects require good garbage collection, essentially queries that delete all objects from the database that have "expired". Generally, it's like "DELETE FROM `tokens` WHERE creation < ?" and ? is the cutoff integer timestamp.
I'm having a bit of trouble naming this variable though. Should there be both a "Creation" and "Lastaccess" variable, even when most cases only one is used? It seems to me that you could condense the two fields, although that could lead to ambiguity (like, do you update the field?)
I'm also juggling around with the idea of "expiry": instead of saving the creation/lastaccess time, you set the expiry time, and you've got a real easy cutoff (it's the current time). However, you sorta lose information, and you can't easily change around the expiration times of earlier tokens (I suppose it's possible). And then there's still the problem of figuring out whether or not the object needs to have the expiry field updated in the Layer Supertype (variable flag in the mapper, perhaps)?
And of course, better, less ambiguous names for these fields would be welcome.
Another problem: both the domain object and the data mapper have to be aware of the amount of time the object is considered "Fresh". Does this mean I need a Lifetime Registry for the object, do I stick in the mapper or the domain object or in both?
Sorry, I was just doing some coding and I noticed duplication but I'm not sure what I should factor it into. I need to get some stable, well written enterprise systems to take a look at...
Temporal Objects
Moderator: General Moderators
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Temporal Objects
Last edited by Ambush Commander on Wed Oct 19, 2005 6:30 pm, edited 2 times in total.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Temporary Objects
A temporary object has a different meaning in compiled languages???Ambush Commander wrote:I don't know the name for this pattern, so I'll refer to it as a "Temporary Object" (although it has different meanings in compiled languages). Basically, it's an object that expires after a certain amount of time passes. This may be set period from the creation of the object or the last access of the object. Good examples of temporary objects are "Remember Me" tokens, user sessions and captchas.
These objects require good garbage collection, essentially queries that delete all objects from the database that have "expired". Generally, it's like "DELETE FROM `tokens` WHERE creation < ?" and ? is the cutoff integer timestamp.
I'm having a bit of trouble naming this variable though. Should there be both a "Creation" and "Lastaccess" variable, even when most cases only one is used? It seems to me that you could condense the two fields, although that could lead to ambiguity (like, do you update the field?)
I'm also juggling around with the idea of "expiry": instead of saving the creation/lastaccess time, you set the expiry time, and you've got a real easy cutoff (it's the current time). However, you sorta lose information, and you can't easily change around the expiration times of earlier tokens (I suppose it's possible). And then there's still the problem of figuring out whether or not the object needs to have the expiry field updated in the Layer Supertype (variable flag in the mapper, perhaps)?
And of course, better, less ambiguous names for these fields would be welcome.
Another problem: both the domain object and the data mapper have to be aware of the amount of time the object is considered "Fresh". Does this mean I need a Lifetime Registry for the object, do I stick in the mapper or the domain object or in both?
Sorry, I was just doing some coding and I noticed duplication but I'm not sure what I should factor it into. I need to get some stable, well written enterprise systems to take a look at...
Maybe it's my background in C++...but an object is an object is an object
An object being an instance of a C++ class (or any class in any OOP language) - in which case I suppose object assumes a different meaning under different technologies...
For instance an object in COM doesn't have to be programmed in C++ you can program an COM object in C.
Just buggin'
I'm just gonna sit back now and read what other people write....
Cheers
The first thing an extreme programmer would say is: what are the requirements? It's very easy to get stuck in analysis paralysis if you don't have clearly stated requirements.
These would be translated into unit test assertions, then you'd write the simplest possible thing that passes. The big difference is that you've (probably) created a much simpler problem to solve. You can always refactor towards a better system later as new requirements emerge, or as you learn from the code.
So, my suggestion would be to try writing down exactly what you need for the current job, and do (just) that.
These would be translated into unit test assertions, then you'd write the simplest possible thing that passes. The big difference is that you've (probably) created a much simpler problem to solve. You can always refactor towards a better system later as new requirements emerge, or as you learn from the code.
So, my suggestion would be to try writing down exactly what you need for the current job, and do (just) that.
How about, rather than updating objects, just make a new one? Then, you only need to take the most recent record as the valid one, and all objects, old or new, will be deleted when their time comes. That way, you can have a "creation" timestamp, which refers to the time the record was created, with no dupicity or ambiguity. Ok, so there is duplicity in that your creating objects that already exist, with only a small difference in the new version, but that shouldn't matter, because they're all gonna be deleted anyway. Hopefully you get what I'm trying to say.
But you should make sure you know exactly what it is you need to do, as McGruff was saying.
But you should make sure you know exactly what it is you need to do, as McGruff was saying.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Try a Google. It seems "in the evaluation of complex expressions, the compiler has to store intermediary results in a temporary location."A temporary object has a different meaning in compiled languages???
Temporal is a very good way to describe it. Very good...Seems "temporal" would describe it better. In which it would seem to me that it's more a timer class coupled with an event that fires into the object when the timer runs out.
Edit - Martin Fowler seems to disagree... no dice. http://www.martinfowler.com/eaaDev/TemporalObject.html
Okay, let's do a requirement check. I'm taking into account Feyd's abstraction.The first thing an extreme programmer would say is: what are the requirements? It's very easy to get stuck in analysis paralysis if you don't have clearly stated requirements.
1. When a certain event happens, the object tells the unit of work to commit suicide.
2. At various points, the state of the object should be checked to see if the event happened (since PHP is not an event-based language like JavaScript)
3. One type of event is when a timer runs out.
4. The timer needs to be selectively reset for certain objects but not others
A simpler way of putting it, without Feyd's idea, is
1. When an object becomes stale, it tells the unit of work to commit suicide
2. An object is stale when the timer has run out
3. Some objects can be "freshened" when they are touched upon.
Then, we create the testcase, and then we make the class, and this looks very good.
A few unanswered questions though:
1. Which object is responsible for maintaining the timer? The Data Mapper or the object itself? Both need to know about the timer (mapper needs to clean up the database), but there's a one to many association from data mappers to timers...
2. Do I need to make a value object for Timer? That way, I can encapsulate the logic about when timers expire and whatnot in that object. It might even be able to handle the database queries to clean up stale objects in database. What do you think?