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 ob开发者_StackOverflowject
$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()
}
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
精彩评论