On Tue, 2008-02-19 at 22:26 -0800, Nick Stinemates wrote: > Robert Cummings wrote: > > On Tue, 2008-02-19 at 21:51 -0800, Nick Stinemates wrote: > > > >> Robert Cummings wrote: > >> > >>> On Tue, 2008-02-19 at 21:24 -0800, Nick Stinemates wrote: > >>> > >>> > >>>> I said, simply, returning an array of objects was usually an indication > >>>> of poor design. > >>>> > >>>> > >>> Please elaborate as to the "why" of it being an indication of poor > >>> design. > >>> > >>> Cheers, > >>> Rob. > >>> > >>> > >> I already did... > >> > >> I can condense it, since apparently I wasn't diligent enough in my > >> explanation the first time. I have a feeling that this will probably > >> evolve in to Procedural vs. OO design flame war, which was not the > >> intent nor desire. > >> > >> Please also consider that I am talking about modular/extensible design > >> philosophies (Gang of Four) strongly used in languages like C++/Java. > >> > >> Normally, if you're going to be returning a group of objects from a > >> method you're going to want to do something with them. In this case, why > >> should I expect the client of my library to have to do bulk operations? > >> The less trivial the example the more important it becomes, _especially_ > >> if your method is used more than once! That's twice the amount of code. > >> > >> If that doesn't make sense then my reasoning must be shit. > >> > > > > It makes sense in the sense that you anticipate certain bulk operations > > being performed. But as soon as you don't, they must resort to bulk > > operations again. Also, your assuming I want your group object to apply > > these bulk operations. Why can't I just request the result set, create > > an operations object, and pass the operations object your group object? > > > > I'm not against implementing an iterator... this is much different than > returning an array of multiple objects, with a lot less overhead. Actually, using foreach on an array has less overhead than an iterator on an object. > > Why must the action be on the group object. Going a step further, if > > I've moved the action to an action object, why do I need a grouping > > object? It can work as well on arrays or objects. As such I'll skip the > > overhead of a group object since an array is perfectly sufficient and > > Ill pass it to my operations class. > > > So you're going to rewrite implementation specific details every time > you use this bulk method? What about if one of the objects changes? Are > you going to limit yourself on maintenance because of poor design, or > are you going to refactor your code and search for every use and make > sure it's being used 'properly?' Sounds like a huge waste of time to me. Why would I rewrite implementation specific details? The implementation details are on the objects. The action object's operation routines work on the objects in the same way your group object's methods would. The difference is that I give the action object the group, array, vector or whatnot of items whereas you return it that way. My approach is more versatile, I can create operational differences upon the same set of results (whether it be an array, or a group object) by choosing to instantiate the appropriate action object whereas you would need to provide different return methods to get different types of group objects... or alternatively clutter the group object method space with a multitude of operational methods. > > More than one way to skin a cat. My operations class knows how to deal > > with lists, binary trees, vectors, arrays, CSVs, Xcel files. These are > > just extended classes on top of the operations object. And unlike your > > group object, my operations object can deal with any datatype, not just > > objects. > Hopefully you would be programming to an interface and not to an > implementation so that these types and functionality are interchangeable. Of course I would use whatever useful features of the language are available provided they don't impede my sense of design and efficiency... and that includes being able to return arrays as I see fit. Nothing wrong with returning arrays, your choice of design appears to have more drawbacks than mine. ;) Cheers, Rob. -- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
