Question

I’m sure this is something that comes up regularly, but I don’t know how to handle it, nor do I know the relevant terms to search for. I’m creating a utility for a search engine which appends “heuristics” to incoming search jobs using Java. (So, for instance, if a user searches for “couch”, the utility will append terms like “sofa” and “bedroom furniture” to provide more relevant results.)

I’m having a bit of trouble handling the global information. In this specific case, the heuristic terms are the global information that can be modified by somebody working on the backend, or can be accessed by a client using the search. So, I wanted to know what would be the best practices in this case: I can create a class with almost purely static methods called something like HeuristicSearchEngine, which can be launched in the beginning of the server startup, load the heuristics into memory, and have methods which can be used to access the heuristics for the search or modify the terms. This just seems sloppy, since it doesn’t use any of the advantages of OOP. So, another approach is to use a singleton to create an instance of the current heuristics. That way, whenever a search job is launched, the job can load the instance of the current state, append heuristics to the search and move on. However, the singleton didn’t seem appropriate here, and I’d like to know how others would handle this case.

Let me know if you’d like further clarification any other info.

Answer 1

The singleton/factory method you are describing is functional and easy to implement. But singletons are dangerous because should you want to implement variants to your herustics services down the road, you may have to refactor things to accommodate them. Furthermore, singletons are typically passed around with static factories which, themselves, can interfere with extendability.

Instead of a singleton/factor approach, consider dependency injection. It’s more cumbersome to implement but extends more gracefully.

With dependency injection, you anticipate components’ needs for data/services, passing them to dependent components before they need them. (Whereas the alternative is leaving the work of finding that data/service to that component – functionality you might achieve with something like a static factory.) In general, you de-couple components and isolate their functionality; doing this is generally accepted as an effective design approach.

As a more concrete example, instead of your servlets calling com.me.Herusitic#getInstance(), they would instead have an instance of Heuristic passed to their constructors. That Heuristic reference is saved within the object and is called upon as needed. Later on, when you’ve extended Heuristic into FancyHeuristic and FakeHeuristicForTesting and you want your servlets to use them instead, you don’t need to modify your servlet code: just pass in the new type of heuristic. With the factory approach, you’d have to rewrite your factory logic.

This answer only scratches the surface of this topic. Fortunately, there is no end to discussion on the DI design pattern (both on StackOverflow and elsewhere), so I’ll leave it to you to continue research.