They don't have to be parameter-less (e.g. new()), but your search method does need to have a consistent way to create multiple objects and to generate the parameters needed for each object. For example, you might have a search method that takes a URI that identifies the physical storage to search. Your factory method could use the URI to deduce a physical implementation (i.e. class) for the found objects. Then your class level search method would convert the data retrieved for each found object into an instance of that class, perhaps by passing the data as parameters to the class.
As to your second question - Trying to design an interface without a clear idea of your use cases or your target user group and their needs I fear is going to be an exercise in futility. There are just too many alternatives.
Take, for example, your idea of passing in a closure or other subroutine for searching. This can be a very good idea, but it tends to be most effective (for your users) if the selection rules used by a search involve complex logic that is difficult to express using just data. If a list of fill-in-the-blank search criteria is what your users need, then making them write closures is going to be a big turn-off.
Or consider search criteria. In my opinion, it is a bit dubious to try to model search criteria without a clear idea of your user community. You might have some luck if your search finds things that you have a lot of experience with (e.g. past exposure to users/yourself as a user) or if X's are well defined and have industry standards and search conventions (e.g. books are usually categorized by title, subject, and author). If you don't have either of these, you are likely to either over or underscope the proposed search criteria.
You also indicate that your search strategy may have to be applied to a wide range of physical storage mechanisms. Implementing even one can be time consuming, so here it is especially important to prioritize which ones are likely to be more or less important. It is also highly likely that the data and functions needed for each storage mechanism will vary widely. You might be able to define a common set of access functions, but then again you might not. Just for starters, consider the difference between searching an in-memory and database storage pool. One uses variables and chains of hash keys for access. The other might require a URI, password, and search criteria morphed into an SQL statement.
So my first recommendation is to choose some use cases before you decide whether you need fancy things like code references passed in as data or class methods X,Y,Z.
If you are planning a project proposal and don't have any actual users, then try some market research and take a stab at what will most likely be needed and focus on those use cases.
If you are afraid of missing some general themes by focusing on specific use cases, then choose two or three very different use cases. You can use the tension between the different use cases to sort out which is specific to the use case and which represents aspects of the general problem. The main thing though is to focus on use cases that are likely to have a real market/user community.
Best, beth
In reply to Re: search methods as class methods?
by ELISHEVA
in thread search methods as class methods?
by Boldra
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |