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? | [reply] |
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.
| [reply] |
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?
| [reply] |
Howdy!
I think what you meant to say was "it runs counter to encapsulation...".
If you need to extract values from an object, you need a method. If
you always use a method to fetch data from an object, you have no
way of knowing (and no need to know) whether you are fetching an
attribute or a computed value. Encapsulation means, among other
things, that you have no need to know the distinction. The object
makes certain data available to you via a well defined API, to wit,
the methods frequently labeled "accessors".
| [reply] |
| [reply] |