What would it be the best OOP approach for comparing lists of objects?

Question

I am currently working on an algorithm for comparing two list of objects. Something like this:

I have a lists of sales:

class Sale
{
    protected $client;

    protected $products (ArrayCollection of Product objects with id and amount);

    protected $status;
}

And I am receiving an unordered list of SaleProducts like this:

[
    {
        'client_id' => 1,
        'product_id' => 21,
        'amount' => 1
    },
]

I parsed this JSON into an array of Product objects like this:

[clientId] => [Products]

But I'm having problems checking this list against the list of Sales previously given. What would it be the right OOP approach for a problem like this?

My first thought was using a Stack of Products and iterating through the Sales and build candidates for each one but I thought that maybe there was a better solution for this

`What would it be the right OOP approach for a problem like this?` -- The way that most effectively fulfills your specific requirements. Right now, there's not enough information in your question to make that determination. What does "checking this list against the list of Sales previously given" mean, for example? — Robert Harvey, Mar 14 '17 at 17:23
The checking means basically that if one Sale has all its products in the SaleProducts list then the Sale should have status = true — nimrod188, Mar 14 '17 at 17:26
Possible duplicate of [Choosing the right Design Pattern](http://softwareengineering.stackexchange.com/questions/227868/choosing-the-right-design-pattern) — gnat, Mar 14 '17 at 17:30

score 0 · Answer 1 · answered Mar 14 '17 at 17:51

What you are describing is a combination of joining entities from separate but related structures, and also something called referential integrity, and all database management systems (DBMS) products will have features for defining how your tables relate and making sure that referential integrity is kept intact. Given that there is a strong likelihood the next thing you have to design is how to persist that data, and your decision will be to leverage a DBMS for that, then I would recommend to define your tables in the DBMS such that referential integrity is guaranteed.

If you put your data into tables in a DBMS with a relationship, then it becomes a simple query to JOIN the tables and get the joined results back. From there you can easily craft a check to make sure the Sales that have all its products categorized as "sales" has its "sale" flag as true.

Also, you could create an UPDATE TRIGGER that performs that check, and adjusts the flag accordingly, each time a record is updated.

I always suggest to leverage a DBMS as much as you can because it makes less work for you. If your hesitating to leverage a DBMS because of costs or licensing, there are plenty of open sources and/or community DBMS products that can more than handle these jobs for you.

I am currently using a DBMS for storing Sales and SalesProducts but the input coming from the JSON file is not necessary fully corelated with the SalesProducts stored in DB. Example: I have stored a Sale with `SaleProduct [clientId => 2, productId => 21 => amount => 2]` and I got the following input from JSON` [ {client_id => 2, product => 21, amount => 1}, {client_id => 2, product => 21, amount => 1}]`. I guess I could add a valid_sale_product table and check it against sale_product table but I wanted to know if there's a more elegant solution to this (maybe common) problem — nimrod188, Mar 16 '17 at 08:31
If these JSON files are fed from another system, or systems, out fo your control and you are consuming, I typically have the job that retrieves the JSON files also re-structure to suit what the app is doing and perform any data cleansing there. I try not to replicate the data models of the feeding application unless the data models directly work for what the app is doing. The feed becomes a sort of interface into the feeding app, and when that feeding app decides to re-structure its data model and the JSON files, you don't have to go all throughout your app to fix. — Thomas Carlisle, Mar 17 '17 at 18:36

score 0 · Answer 2 · edited Apr 13 '17 at 12:45

The checking means basically that if one Sale has all its products in the SaleProducts list then the Sale should have status = true - nimrod188

I can tell you how to do exactly this but I don't think doing it this way is actually the best design. Lets say your Sale's status becomes true, what happens now?

My guess is something cares that they're true and has to poll them to find out their status because it has no idea when your SaleProduct's list comes in.

What I'd like better is a design that triggered an event when the Sale's status became true. That way you could do whatever needs to be done, when it needs to be done.

Now, about the pattern that solves your problem. What your doing reminds me of waiting for parts of a fragmented packet to come in to populate a buffer with the complete packet. Fragments can arrive in any order but until the buffer is full, you're still waiting for the rest of the packet.

A big hurtle to overcome is finding your way from a SaleProduct to a clientID to a Sale. SaleProducts have no knowledge of Sale's and it would be nice if it could stay that way.

How about if a Sale could register as an observer of Product objects? Each Product can be found by it's ID and can let Sales register to be notified when they show up in the SaleProducts feed.

Now a Sale can sit back and wait for the notifications to come in. Each time one comes in it marks it down and checks if that's all of them. Once all of it's products come in it is ready for it's status change. It can either just return true when asked it's status or it can fire off it's own event to deal with it's new status so you don't have to sit around polling it.

What would it be the best OOP approach for comparing lists of objects?

2 Answers2