Design pattern for class interaction

Question

I'm having some trouble deciding how two classes should interact and the problem I'm having seems like it would come up a lot so I was wondering if anyone knows of a design pattern (or any kind of solution) that addresses my issue.

Basically I have two classes. Class A deals with displaying information to the user and Class B deals with storing data. Class A needs to get data from class B, format the data based on Class A's internal state, and output the data. For example Class B contains English strings and Class A will always translate those strings into a language that is specified by an instance variable of Class A before preforming any further processing on them.

I can come up with two potential solutions for this but neither of them seem very clean.

1. Make Class B an instance variable of Class A. Write function in Class A that get the data out of Class B and format it for use in other functions in Class A. This solution doesn't seem great because it does not stop Class A from directly accessing the data in Class B without formatting it.

2. Make a Class C that extends Class B. Make Class C an instance variable of Class A. Class C will override the Getters of Class B so that the formatting is always applied to the data. However in order to format the data Class C needs to know about Class A's internal state. This could be accomplished by passing a pointer to Class A into the constructor of Class C. Class C could then call a function in Class A that calculated Class A's internal state.

Let me know if this is confusing and I could provide a more concrete example.

thanks

Answer 1

Sounds like either:

• Observer
• Model-View

Answer 2

I'm not sure its as pure as a "design pattern" choice and possibly more of a design principle. For example,

Single Responsibility - a class should do one thing, and ONLY 1 thing.

Have a look at SOLID.

http://en.wikipedia.org/wiki/Solid_(object-oriented_design)

It sounds like you might want Class B (your dataprovider) to be implementing an Interface, and you'll have several flavours of data provider classes (variants that all implement this interface). If you referenced any dataprovider from Class A, you'd use the interface, not the specific implementation (class-type). That way you can swap different data providers in and out without ever having to modify Class A as well...

Answer 3

In alternative #1, I don't think "stopping Class A from directly accessing the data in Class B without formatting it" is a concern. Any class can fail to do what it says it does, it doesn't take a bad design to do that. So I don't think that's a valid concern. A is the only thing that knows its internal state, so it should be providing the logic to transform the output.

One alternative to that, which may be overengineered for your needs, is to use something like the Strategy pattern. Basically, B accepts a strategy to format data, and in that function (that A would provide) you could rely on A's state.

Something like this:

interface FormattingStrategy {
    public String format(String input);
}

class B {
    public String getFormattedStringA(FormattingStrategy formatter)...
}

class A {

    public void someMethod() {
         String a = getFormattedStringA(new FormattingStrategy() {
             public String format(String input) {
                 if (someAState) {
                    //...
                 }
             }
         };
    }
}

The strategy could be an instance variable of A. This keeps B completely decoupled from A, only coupled to the FormattingStrategy interface.

Answer 4

Hi,
one mistake you make is the naming of classes A, B, C you should not do this. Better is to name your classes like more real objects e.g like a occupation or real things, because you will get the solution right out of the names. If you mention patterns...
they have names like: Model-View, Fabrique, Decorator, Observer. dig it?
to your problem: the class with data is your "model" the class that shows your data is your "view"
If you deal with languages maybe have a look at the interpreter pattern. But I must confess I do not really understand the problem, it sounds a kind of confused to me