2

Let me introduce my situation:

I have Java EE application and in one package, I want to have classes which will act primarily as cache for some data from database, for example:

  • class that will hold all articles for our website
  • class that will hold all categories
  • etc.

Every class should have some update() method, which will update data for that class from database and also some other methods for data manipulation specific for that data type.

Now, I would like to call update() method for all class instances (there will be exactly one class instance for every class) from one place.

What is the best design?

Improve this question
3
  • This sounds like it might work with the visitor pattern: en.wikipedia.org/wiki/Visitor_pattern or maybe the Strategy pattern, used here: stackoverflow.com/questions/985960/… as an alternative to the visitor pattern
    – FrustratedWithFormsDesigner
    Oct 21, 2013 at 14:09
  • Inheriting from a class or from an abstract class (with the common methods in it) might be a good solution.
    – codeKaichu
    Oct 21, 2013 at 14:10
  • 2
    @FrustratedWithFormsDesigner - or both. Visitor visits each object in a composite structure and calls a method (update?). Strategy implements the logic of what update does.
    – Matthew Flynn
    Oct 21, 2013 at 16:04

2 Answers 2

Reset to default
2

You should seriously consider using the observer pattern and, rather than calling an Update method which iterates through a list of objects that need an Update, you simply call an event to which all of your objects are subscribed for as long as they are valid to be updated?

Improve this answer
5
  • observer pattern seems to me like the most elegant solution from the class design point of view, but our cache is not updated very often (mabye few times a week), how big is performance hit?
    – betatester07
    Oct 21, 2013 at 21:01
  • @betatester07: There shouldn't be a performance hit. If anything, it'll probably be slightly optimised by the framework. But feel free to profile it and be sure.
    – pdr
    Oct 21, 2013 at 23:25
  • thanks. maybe, one more question - what is best approach to access other methods on one of my cache objects?
    – betatester07
    Oct 30, 2013 at 11:59
  • @betatester07: Not understanding your question, sorry. But it sounds unrelated to the original question, so I'd suggest raising it separately, rather than making this conversational.
    – pdr
    Oct 30, 2013 at 18:02
  • yes, you are right, I will open new question.
    – betatester07
    Oct 31, 2013 at 20:09
1

While you might be tempted to create an abstract class or interface. I would strongly advise against that approach.

Reasons Against Interfaces

  1. You'll end up with two classes that do a lot of the same work.
  2. It defines a contract but doesn't improve cohesion of code.

Reasons Against Abstraction

  1. You'll end up with 3 classes. The base class and 2 implementing classes.
  2. Most of the abstract methods will be public. Abstraction works best when the scope of the re-used methods are protected. This makes it clear that the abstract class is truly there to assist inherited classes.

Recommended Approach

  1. Define a sealed caching class that doesn't care when it caches. Create a class called DatabaseCacher that knows how to keep ICachable objects in memory.
  2. Articles and Categories then implement the ICachable interface.

DatabaseCacher should be used to modify the properties of ICachable. Don't implement any setter methods on your ICachable objects. Instead, create a generic setter method on DatabaseCacher that takes the name of the property as a parameter with it's value. This allows you to localize all caching and write operations of those objects.

I would avoid using a property change event listening approach. As it creates a large number of binding between only two entities (DatabaseCacher and ICachable objects). Property change listeners work best when the connection is ambiguous.

Improve this answer
4
  • 2
    Your reasons against interfaces don't make any sense, especially considering your recommended approach, which is to define an interface (ICachable).
    – Matthew Flynn
    Oct 21, 2013 at 15:59
  • @MatthewFlynn I was referring to creating multiple caching objects that implement an interface. Sorry if that wasn't clear.
    – Reactgular
    Oct 21, 2013 at 16:30
  • what do you mean by "sealed caching class that doesn't care when it caches"?
    – betatester07
    Oct 21, 2013 at 19:24
  • @betatester07 sealed as in not abstract, and caching as in it stores the objects in a collection to be reused later.
    – Reactgular
    Oct 21, 2013 at 19:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.