in reply to Re: Accessor methods again.
in thread Accessor methods again.

Pretend you have an object that represents something like an "Order" in the sense of a shopping cart order. The order object has all these attributes and methods, and after you have populated the order with a customer, a list of items, and finalized the order using your fancy methods, you want to print out the order information to the customer so they can have a look over it and send an e-mail message if something is wrong. Not an uncommon problem.

It seems you are suggesting that instead of having accessor methods I can use to query specific data from the object and pass said data to something like a template system, you would have a method on the $order object called something like $order->print() or $order->fetch_printable() or something like that. In which case, we either have embedded HTML or template logic (where the templates are located, how to populate them) inside the class.

Now pretend this information is embedded into an outer page. Fine, you can use a script to pull the printable and place it inside the other page. What if you want to use some specific information from the order to place in the TITLE of the page? For instance, the order number? Oh wait, we can't have accessors so we will have to have the order object generate the entire page.

So then you get into this situation where each of your objects have to know how to render themselves completely (in the context of an entire web page, or pdf file, or gui window, etc.). But in order to render themselves, they need some information from other objects, which in turn requires accessors.

So exactly what are you suggesting?

Replies are listed 'Best First'.
Re^3: Accessor methods again.
by Moron (Curate) on Oct 05, 2005 at 08:51 UTC
    There are several oo mechanisms that can overcome this, including inheritance and friendship. However, if, with a full understanding of oo techniques, a 'clean' OO implementation still doesn't fit the requirement then I would recommend not using OO rather than being forced from the outset to abuse it.

    -M

    Free your mind

      I read the other OO articles linked in this thread about not using accessors. In my opinion there are many benefits of using an OO approach to some parts of a program and not for others. I'd rather abuse OO and have a bastardized OO/procedural program that works and is done in a reasonable amount of time than spend spend years coming up with some other paradigm just so I can get away from using accessors.

      I did give a clear example of where I thought using some accessors was okay, and I was hoping for a response from you suggesting an alternate way of solving the problem. Any chance of this?
        Sorry not have replied sooner - I am not very regularly on this site and have a busy time in general.

        My latest approach is to reduce this to just three methods, a define method that recursively sets anything anywhere in a multilevel hash or hash of arrays or any combination to which there is a blessed reference to the top; a recursive get method that is insensitive to reference types and similarly a prune method that deletes anywhere in the tree. But I am still checking whether the prune method needs to collect its own garbage or whether 'delete' is recursive before I would publish examples.

        -M

        Free your mind