Object communication Hades --- can you help me learn from this situation?

dalecosp

I've got a mature (heh, am I mature?) system that's continually getting new feature requests --- I'm suffering from "feeping creaturism", I guess. Here's an issue that's pretty hard to wrap my head around: whether I could have designed it from the Beginning (3 years ago now) with a better way to handle the situation below. I'd really like to see if I can learn something from this.

Please forgive the $cats abstraction; this is an object-oriented system that we rely on constantly at work.

I've a herd of $cats; each produces a litter of $kittens and puts them in the $nursery and then dies. The $nursery staff looks them over and decides what breed they are, what color their fur is, and so on. The $kittens are tagged with these qualities by the $nursery and then sends them to $PetsMart for sale. When all the $kittens are sent to $PetsMart, the $nursery goes out of business.

This has been working well enough as designed; all the data we needed to know about kittens 3 years ago has been programmed into the system.

However, the CEO at $PetsMart now wants to know which $kittens were conceived under a full moon, so he can tag them as such and get a higher price. 3 years ago we had no idea he was interested in such things.

Although the $cats know when their kittens are conceived, $PetsMart doesn't have a way to talk to dead cats.

The nursery could ask the $cats about this, but it wasn't written to do so.

In other words, the objects are discrete; a new flag ($born_under_fullmoon) can't be set at birth and retained until sale unless we alter the affected parts of the system. The first object can tell us that a certain flag should be set, but no mechanism exists to transmit the new data through the entire system.

Now, I've analyzed three possible "fixes":

I can add a boolean field to the $nursery DB queue and the $cats can set this their conception dates. The possible problem is that modifying the database means I'll have to review the entire system (since the "nursery" touches both the $cats and the $PetsMart) to make sure that other DB calls don't break.
The system has a config file, so I could create an array of $cats that are known to have conceived their litters during a full moon there. But then the config file must be altered for any new $cat that gets romantic at that time of the month. Plus, the $PetsMart object must read the config file and probably import it into its methods with "global $config". That feels dirty (is it?).
A 3rd alternative, possibly the best, is to create a new table that $cats can write to and $PetsMart can read.

I'll probably pick option #3. What I'd like to know, if you can even follow my story ... is there anything I might've done 3 years ago to foresee this and make my objects able to communicate with any part of the system, even though they don't exist any longer?

Is this, for example, a place where an object-oriented database might have helped? A particular pattern I didn't use?

Thanks for your help 🙂

Derokorian

Maybe I'm missing something, but $cats make $kittens, $cats know when the $kittens were conceived, so when $cats make $kitten, they can put a property on the kitten saying it was conceived under a full moon?

$kittens = $cat->getLitter();

// ....

class Cat {
   public function getLitter() {
       return array_map(function($kitten) { $kitten->fullMoonConception = $this->fullMoonConception; }, $this->kittens);
   }
}

Or something like that? Why put a property of the kitten anywhere but on the kitten itself? My cat has a white tail, I don't look at my dog to find that out, but at my cat!

Of course, this may make no sense in how your system actually works, but how I'm picturing it in my head from your description... something like that seems possible.

dalecosp

Thanks for the post, Derokorian 🙂

The real crux of the issue; there's no object persistence in the system. Each action saves data to a DB table/queue, and the next action triggers independently (by a human operator).

So the $cat can set the flag, but unless the DB is altered, as above, the $nursery won't be informed because it reads $kitten from the DB and there's no property/flag available there. I'm figuring I'll have to either do #1 (alter extant tables) or #3 (create a new table) to do this. Just wondered if there's a sufficiently generic concept that I'm missing someplace. For example, it has occurred to me that:

Dalecosp wrote:
Is this, for example, a place where an object-oriented database might have helped?

Instead of writing to a specifically laid-out DB, I might've serialized the objects between each stage. The downside is that we use PHPMyAdmin to monitor and analyze (and sometimes massage) the data between stages, and a serialized object isn't really DB friendly...

Bonesnap

I'd probably go with a variation of your third solution. I might make it a little generic, though, and make it sort of a "meta" table for the cats. It's always possible the PHB will want to know something else about the $cats in the future. Each entry in this table would consist of a $cat's ID and a meta key and meta value. Then when the table is read, you could construct a generic object from the table and do what you want with it.

However, I don't really see anything wrong with your first option and I don't think you really need to reevaluate your whole system because you added an additional column/flag. All the columns/values that are required are still in place and haven't been touched. I think you would need to do that if you were changing something that already existed.

Love the cat analogy, by the way. 🙂

NogDog

I don't know if this would fit your specific needs, but the app we're totally re-engineering right now will include an activity log table (or 2 or 3) to record things of potential interest, so that we have the data if needed, without it polluting the "regular" app data. But as you state, if you don't bother to record the data in the first place in that log table, it won't help -- the best you could do is to come up with an algorithm to make an educated guess at the conception date based on the actual birth date.

dalecosp

Bonesnap;11047443 wrote:
I'd probably go with a variation of your third solution. I might make it a little generic, though, and make it sort of a "meta" table for the cats. It's always possible the PHB will want to know something else about the $cats in the future. Each entry in this table would consist of a $cat's ID and a meta key and meta value. Then when the table is read, you could construct a generic object from the table and do what you want with it.

This is pretty much what I'd decided to do. Seems like it would be good for future-proofing, as 'twere.

However, I don't really see anything wrong with your first option and I don't think you really need to reevaluate your whole system because you added an additional column/flag. All the columns/values that are required are still in place and haven't been touched. I think you would need to do that if you were changing something that already existed.

Love the cat analogy, by the way. 🙂

I'm just terrified that I did something dumb ("select * from $table", or more likely, an insert without specifying the fields) that will break something while my supervisor has 20K kittens in the queue someplace at 4:30 PM. 😉

As for the $cats analogy, did I mention I work for a veterinarian? (Kidding!!!). I don't dislike cats, nor do I love them overmuch, but somehow it seemed appropriate....

dalecosp

NogDog;11047447 wrote:
I don't know if this would fit your specific needs, but the app we're totally re-engineering right now will include an activity log table (or 2 or 3) to record things of potential interest, so that we have the data if needed, without it polluting the "regular" app data. But as you state, if you don't bother to record the data in the first place in that log table, it won't help -- the best you could do is to come up with an algorithm to make an educated guess at the conception date based on the actual birth date.

That's kind of like my option #3, especially as Bonesnap has suggested it be done, right? A generic table which $cats can write to, with any information (a "tag type", and a "tag value" as it were), which modules farther down the line of processing could read if they wanted to.

It's not uncommon to write a new cat module, or modify an extant one, so "recording the data in the first place" can happen for any future incidences of $cat that come along.

I'm feeling better about a solution to the problem at hand. Just wish I could've figured out 3 years ago that I would need such a feature ... 😉