when you use a Class it is an object.
getter and setter are methods by another name.
if you instantiate a class all the methods are carried with it whether
they are used or not.
so regardless of your argument it is OO.
if you are familar with c then create a hello world function and compile
then create a class hello world. not the difference in size and look at
the stack for a call to both.
the last time I did this the function compiled to 1K the class compile
was 10K with no methods in the class.
then put getter and setter in the hellow world and watch the size and
the stack when using the class.
this will give you an idea of what is being talked about.
=========================
BJ Freeman
Strategic Power Office with Supplier Automation
<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist
Chat Y! messenger: bjfr33man
Marc Morin sent the following on 12/11/2010 12:40 PM:
Now it's pretty obvious that many are reading the incorrectly renamed O->R
mapping subject and saying it's counter to OFBiz entity model, core philosophy,
discussed before... go away you Object lovin' Java developer... ;-)
I don't want to repeat the topic, but it is a getter/setter decorator around
the Entity/Delegator API that you all love. Not hibernate, not OO
persistence...
I don't know how anyone can say that the following code is "nicer", "safer",
easier to maintain
GenericValue order = delegator.findOne("OrderHeader",
UtilMisc.toList("orderId", orderId), true);
Timestamp entryDate = order.getTimestamp("entryDate");
List<GenericValue> orderItems = order.getRelated("OrderItem");
vs (evil Object facade, what a Java developer would expect to see, IDE
auto-completion, type safety)
OrderHeader order = OrderHeader.findOne(delegator,orderId);
Timestamp entryDate = order.getEntryDate();
List<OrderItem> orderItems = order.getOrderItemList();
My point is, there is a simple facade we can present on all the goodness of the
GenericValue, delegator, dispatcher, transactions, that makes the Java purest
feel better about OFBiz. (been easier to find Java developers than OFBiz
ones...)
We have been using this exact decorator pattern in our OFBiz application for over 2
years, it feels natural when writing Java code (ie. when in Rome act like a Roman),
haven't heard any developers say they don't want to use it in favor of the
"String" way, once exposed to it and writing new code. When modifying existing
code, they want to change all GenericValues to their appropriate object decorator. (we
aren't doing this in app/framework so we can merge easier, but would love to do see it
done/do it)
Well, looks like we'll continue on our own marry way on this one, keep our
forked technology to ourselves.... I can feel the rope pushing that I
mentioned previously. ;-)
