Subtype dependency on corresponding subtypes

Question

Hi All,
I have a design question.
I am writing an application that will search through the contents of various files against a given search criteria. I envisage that there will be different search strategies, each of which have different search criteria. A couple of examples would be as per below.
Plain Text Strategy. Criteria: a single string (search term), case sensitive flag.
Regular Expression Strategy: a single regular expression, number of lines before and after each result to include, case sensitive flag.
XML Strategy: a single string (search term), name of the xml element to be searched within.
I envisage having an abstract search type and concrete subclasses based on each strategy. For example:
interface Search {
   SearchResult search(SearchCriteria criteria);
public class PlainTextSearchStrategy implements Search { 
   public SearchResult search(SearchCriteria criteria) {
      // do the search..
public class RegularExpressionSearchStrategy implements Search {  ... }
public class XmlSearchStrategy implements Search {  ... }My difficulty is the SearchCriteria. Each search strategy type would have its own search criteria type and I do not think there is any common behaviour (or data) that can be defined in the criteria super type. As such, SearchCriteria is just a marker interface, and this bothers me. The search strategy sub-types would need to cast SearchCriteria to the specific type they need, so there is no type safety beyond ensuring the marker interface is implemented. For example:
public class PlainTextSearchStrategy implements Search { 
   public SearchResult search(SearchCriteria criteria) {
      PlainTextSearchCriteria ptCriteria = (PlainTextSearchCriteria) criteria;
      // do the search..
}Is there a design better suited to this problem of ensuring a sub-type can rely on corresponding subtypes being present? As I understand it, generics won't help me here either. Do I need to live with the casting?
Any advice would be much appreciated!
Rob
:)

Answer 1

Even so, the client shouldn't need to know the
runtime type of the object. For example, if all of
the criteria are strings, you can use varargs to pass
them: interface Search {
SearchResult search(String... criteria);
code] Hi Uncle, thank you for this response. You have raised some important questions that I have put some thought into previously. If I were to store the criteria as strings, it would make a flexible search criteria object, but I think there are some disadvantages:
- I would want constants etc to formalize the position of each criterion in an array, for example.
- I would have to unpack each criterion and potentially parse them into types such as booleans and regular expressions or dates.
On the other hand, if each criteria were a type of its own, I would not have to unpack or care about the position of a string in an array.
But I'm not recommending a specific approach,
just encouraging the OP to minimize the coupling
between these Search objects and the code that uses
them. You are certainly right about the tighter coupling. Plain text search strategy is tightly coupled to plain text criteria, regular expression search strategy is tightly coupled to regular expression search strategy. Is this such a bad thing here? I would think that a search strategy should break if it does not receive criteria specific to its logic. My thinking is that the type safety is a deliberate measure to ensure the right arguments are sent to a subclass in a situation where the superclass defines something broader.
That's what programming to interfaces is all
about. If the client has to know the runtime types
of the Search objects, you largely defeat the purpose
of using interfaces.This point made me think a lot. The reason I began with the idea of a SearchStrategy supertype in the first place was so that multiple strategies could be swapped in and out as needed. Spring could control the initialisation of them and at the UI level I could potentially have a combo box for the user to select which one they want to use.
Then I thought: what about polymorphism for the search criteria as well? But, for a given strategy, I don't think I would ever want to swap between different search criteria types.
I hope I haven't misunderstood what you have stated; thank you for the thought behind your response.
Rob