Which class design is more appropriate - dependency, association, or composition

Question

I have three possible designs and I'm trying to determine which one is better and in which cases they would be better. The general idea of all the designs is that there is a data object that stores some data and there is an analyzer object that analyzes the data.

I need to choose between these designs and I like Design 2 the best. However, a developer I'm working with is pushing for Design 3, which I think is the worst. Are there any advantages or disadvantages I'm missing for any of the designs? Let me know if clarification is needed.

Design 1

In design 1, DataAnalyzer has a Data object that is supplied during construction. When the client calls dataAnalyzer.analyze(), the data is analyzed. In this design, each objects responsibility is clear; The Data object simply holds data and the DataAnalyzer object analyzes data. Changing the data stored will only change the Data class and adding types of analysis methods will only change the DataAnalyzer class. One problem with this design is that the DataAnalyzer object can only be used for the Data object passed in during construction, so if there are lots of data objects, lots of DataAnalyzers need to be created. Another disadvantage (which will be clearer from Design 3) is that the client needs to know about two classes instead of just one. If there are more classes that have an association with Data, the client will have to work will all of these classes.

Design 2

Design 2 is very similar to design 1, except now DataAnalyzer is reusable (for different data objects). The client still has to work with two classes as opposed to one as in design 3. The responsibilities are still very clear and maintenance is easy.

Design3

Design 3 allows the client to work with one object. The client can say data.analyze() and not know anything about the DataAnalyzer. I'm not sure if this violates the single responsibility rule; the Data object has an interface that allows analysis, but the responsibility is really delegated to DataAnalyzer. Another issue is that a DataAnalyzer is created for every Data object created, regardless of whether the Data needs to be analyzed or not. Now if more functionality was added, a lot of things would change. If a DataPrinter class was created (let's assume this is better than having the data print the data itself), the client wouldn't have to worry about creating a dataPrinter object and calling dataPrinter.printData(), it could just call data.print(). However, by adding this class I had to change the interface of Data. Adding more methods to any of the DataXX classes causes methods to be added to the Data class.

Answer 1

Design 1 is useful if the analysis takes a long time or a lot of resources and you can use some sort of caching to make sequential analyses on the same data run faster (or with less resources).
- Use this if you need to store intermediate results or cache final results per instance of data you are analyzing.

Design 2 is useful if you want a static, thread safe analyzer which can be called over and over for different data and does not require resources to do it or can obtain different resources per request from a pool of resources.

If you have various data types (with the same base class or interface), you could use the visitor pattern, dependency injection, reflection or a command pattern to reach the correct concrete data analyzer class from the main one and thus not violate the single responsibility principle.

Design 3 is a bad idea, because it means you are coupling your data type with a processing done on it - each time you want to add or change a processing you will curse your decision if you decide to use this design :-)

In some languages, such as in C# 3.0+, there is a sugar syntax which can make the operation of Design 2 work using the syntax of design 3.

Answer 2

Quick Answer

Its easy to think from an Object Oriented point of view, that Design 3 could be better, because "Data" is an object, and "Analyze" seems more than an operation.

But, in practice, as @Danny Varod, says: "Its bad coupling" of data.

In real life, the analyzer changes to little, & the data changes, a lot, & from an Object Oriented point of view, the Analyzer will change the Data, so Design 1 seems more suited for your case.

Comment

I work, in my spare time, with Compilers & Parsers, and the programming languages they analyze. And that scenario looks similar to your question. The Parser, looks as an your "Data Analyzer", and the Source Code to be parsed, looks like your "Data".

Relation Example:

................................
....+----------------------+....
....|      CPPParser       |....
....+----------------------+....
....| [+] CPPStream Source |....
....+----------+-----------+....
...............|................
...............|................
...............v................
....+----------+-----------+....
....|     <<abstract>>     |....
....|       CPPStream      |....
....+----------------------+....
................................

But, since my "data provider", in this case, a stream, can be replaced by decendant classes, such a FileStream, StringStream.

Inheritance Diagram Example:

............................................................
....+----------------------+................................
....|      CPPStream       |................................
....+----------------------+................................
....| [+] CPPStream Source |................................
....+----------+-----------+................................
...............^............................................
...............|............................................
...............|............................................
...............+---------------------------+................
...............|...........................|................
...............|...........................|................
...............|...........................|................
....+----------+-----------+....+----------+-------------+....
....|     <<concrete>>     |....|      <<concrete>>      |....
....|    CPPFileStream     |....|     CPPFileStream      |....
....+----------------------+....+------------------------+....
....| [+] String Filename  |....| [+] String StringValue |....
....+----------------------+....+------------------------+....
............................................................

What about, your scenario,can the data, represented by a class, be replaced by a descendant class ?

If that's the case, Design 1 seems more suited.

Cheers.

Answer 3

Design 3 is not very ideal because the data analyzer must always be there. I am sure there are lots of cases where you don't always need that class attached to the DO. Also, I agree that it violates the Single Responsiblity principal.

Design 2 might have some problems if there are internal mechanisms/methods that are not the same for different data object types. You would have to re-initialize it each time. I think this ALSO violates the Single Responsibility principal. Data Analyzer should only have to worry about one type of data object. It should not have to reset and redo its internal workings every time a new data object comes in.

Design 1 is my favorite out of the three but not my ideal design. Ideally, I would pass the Data Object to an Analyzer factory. The Factory spits out an Analyzer for that specific data object and then the analyzer can do its work. This is probably the most maintainable solution.

Answer 4

Looking at your concerns, it looks like analyze is a static method. So you can have a Utility class which has analyze as a static method accepting data as input. dataPrinting can be another static method in this same utility class. This design would fail if there are multiple ways (algorithms) to analyze data. If this is required then Strategy pattern can help you there.