Question

I have an object that represent’s a User’s account on my site, and a separate object that acts as an attachment to the main account object and extends the user’s ability to operate some major functionality on the site – a full functioning storefront.

I have been representing the relationship as so:

Class Account {
    $id
    $store // this is the store object
    $email
    $password
    $status

    get_store() // loads the store
}

Class Store {
    $id // unique store id
    $store_name
    $store_info

    post_item()
}

So far, this has been working great, but when I search or aggregate stores this way, it requires me to go through the Account object to get to the store.

I would like to cut the process in half by being able to also get to the account object through the store.

Does it create a problem to ALSO allow an $account object to be stored in the $store object, just in case I want to load it the other way around?

An example of allowing for this bi-directional loading would be as follows:

Class Account {
    $id
    $store // this is the store object
    $email
    $password
    $status

    get_store() // loads the store
}

Class Store {
    $id
    $account // this is the account object
    $store_name
    $store_info

    get_account() // loads the account
    post_item()
}

Answer 1

That’s a common refactoring. The only thing you have to be aware of is that you will need to manage the “back pointer” when you associate one object with the other, e.g. when fetching the store for an account, you have to make sure the store will also get the back pointer to that account and vice versa.

Further reading:

• Change Unidirectional Association to Bidirectional
• Same with examples in PHP