Well the good old GenericValue is an object as well. ;-)
Marc Morin Emforium Group Inc. ALL-IN Software 519-772-6824 ext 201 [email protected] ----- Original Message ----- > 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. ;-) > > > > > > > >
