In OOP, should dependencies hold a reference to their parent?

Question

I have an Order object to represent a Prospective Order/Receipt. This is an entity. It has an identity.

I have a Writer object to read the Order object's properties and display it nicely.

It is a bit of a chore to have individual getters for all the pieces of the Client's Billing Details.

So, I am thinking of letting the Writer object get a Client's Billing Details Value Object from the Order object. (I guess the Client's Billing Details Value Object is called a 'dependency' - correct me if i am wrong)

Now, if I do this, I'd like this dependency to 'know' if the raw persistent data changes

i.e. if countryId changes from '214' to '35'

So that the depency can return the new countryAsPrettyString 'Mexico', say, instead of the old value for 'Ecuador'.

So I guess I would have a factory method in the Order Object and can inject the Order Object into the Client's Billing Details Value Object's constructor so the Billing Details Object always derives it properties from the Order's raw persistent data properties.

Is your reaction to this plan of action:

A: Blimey that's obvious this is pretty much the only way to do it

or

B: My Gosh! Put aside some time for some serious headaches in a few months time - you'll create a tangle of associations - i feel for you.

or C: [Other]

---

I am asking cos this seems like a bi-directional association to me.

The Order has a Billing Details Object

and

The Billing Details Object has the Order

and i have read that bi-directional associations are bad OOP practice.

Answer 1

Not sure if I know exactly what you are asking, but this may be of help:

Change bidirectional association to unidirectional

And this:

Change unidirectional association to bidirectional

Answer 2

All this started because "It is a bit of a chore to have individual getters for all the pieces of the Client's Billing Details.".

I don't know how exactly your classes are implemented, but would it be possible to use PHP's __call to automatically build those getters?

What if you were to set a convention that getBillingWhatever in Order will return $billing->getWhatever() and implement __call to provide this functionality?

Answer 3

I'm going to suggest you create an Address class. Your Order object can have two properties, BillingAddress and ShippingAddress, if you need both. You have a Writer class to create the view for the Order. Create an AddressWriter class to create a view for Address objects. Then you can do something like this:

public function printOrder($order)
{
    // print order stuff here...

    $addressWriter = new AddressWriter();

    echo "<h1>Billing Address</h1>";
    $addressWriter->printAddress($order->getBillingAddress);

    echo "<h1>Shipping Address</h1>";
    $addressWriter->printAddress($order->getShippingAddress);

    // print more order stuff ...
}

Answer 4

Having child class holds reference to a parent class tightens coupling. If it has to be done, I will suggest you make the parent an interface, and have the child referring to the interface. Or you can try to pass the relevant information to the child class through an associative array or a data container.