From: David M. <ma...@ha...> - 2012-07-18 08:44:23
|
At Mon, 2 Jul 2012 15:57:04 +0000, Demian Katz wrote: > > Let me describe the current design to demonstrate the reason for my discomfort with it. > > To search: > > Construct Search Options > Construct Search Params (injecting Options into constructor) > Construct Search Results (injecting Params into constructor) > > The final Results object is capable of returning an array of record > driver objects representing search results. It also proxies all of > the Params and Options methods for retrieving meta-information about > the search (i.e. to look up individual parameters like query, type, > etc.). Proxying all Params and Options methods via __call() is a really bad idea. Firstly it indicates that there is something wrong with the class hierarchy. You simulate inheritance (Results "inherits" the public methods of Params) while in the same moment claim that a Results is something different than a Params (class wise). Your are re-inventing the OOP system. This secondly makes it even harder to reason about the particular behaviour of a Results or Params. Any method call in a Results that refers to the Results class or any of its parent classes could as well be a call to the Params class or any of its parent classes. Any method you create in Results may or may not "conflict" with a method in the Params that was proxied before. This is black voodoo magic with extremly well hidden dependencies. And all this is done for no particular reason: If the creator of a Results object requires a Params in order to inject it via __construct() and requires a Options in order to create the Params then it already has access to the public methods of those objects. ~~~ What I like and makes sense to me is the separation of the search object (aka SearchObject aka RecordProvider) and the search object configuration. Thinking about the search process as SearchObject::search() := f(SearchConfiguration) => 0…n Records Re the question on a static getRecord() method I quite don't see why retrieving a single record is essentially different from retrieving multiple records. Retrieving a single record is a search that returns 0…1 Records instead of 0…n Records. It should be offered by an separate method to be able to skip some of the search configuration processing and translate the 0…1 result set into a single Record object or null if the record does not exist. Best, -- David -- David Maus Herzog August Bibliothek - D-38299 Wolfenbuettel Phone: +49-5331-808-317 Email: ma...@ha... PGP Key 0x0CC2E093512F7385 Fingerprint 1AD2 EE67 224F 18C5 EA55 98AD 0CC2 E093 512F 7385 |