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. > 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. > 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. > No, I don't really have this class, but I could. > Keep it. > Cheers, > Rob. > -- ================== Nick Stinemates ([EMAIL PROTECTED]) http://nick.stinemates.org AIM: Nick Stinemates MSN: [EMAIL PROTECTED] Yahoo: [EMAIL PROTECTED] ================== -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
