Design pattern for selecting data

Question

I have implemented algorithm BFS(Breadth First Search) using a neighbors list ADT for scanning a graph and gathering information about it and answer questions.

I have function called BFS which implements the algorithm and i can answer questions(like: How many connected components the graph has ? Diameter of the graph ? and few more) by using the variables in the function.

For example, to find out how many connected components there are, i can print a variable int components (in the end of the function). To find out the diameter of the graph i'm using a int [] distances array and scanning it(in the end of the function) and getting the max value(precisely but not accurate), and so on.

My question is how can select/get the data from the function(and then i can wrap it within different functions)but still avoiding duplicate code ? is there a design pattern or different strategy for this type of problem ? solutions came in my mind:

1. Print all the required data in the end - possible but ugly and none modular.
2. Re-implement the function and every time return a different type of data(int, int[] etc) - code duplication.
3. Return an object of all data, and then every different function will use it - overkill.

I can add some code if needed.

Answer 1

If your function has a lot of out-parameters and if most of the time you only need a subset, then your function does too many things and its “interface” should be simplified.

The usual way is functional decomposition / method extraction: break the large function down into smaller ones that do-one-thing-and-do-it-well. Each function would then only provide the parameters that are really relevant for its goals. If you need several different results you would call the relevant functions directly. So you’d consume only what you need.

However, for some problems, this technique is not feasible. It is when the same algorithm has to calculate the different results together in order not to redo complex calculations several time. The typical case is when one calculation is the by-product of another. In this case you should consider to implement your algorithm as a class, that could cache/store the different intermediary results or by-products.

A variant thereof would be to use the strategy pattern. It’s also about embedding algorithms into classes, but with interchangeability in mind. In this way you could have a class Searcher, and specify a more specialised search strategy to be used (e.g. BFSearch or DFSearch).

Finally, before choosing one of these approaches, you should think about the larger picture of your design: which of all your potential “queries” depend on a particular bfs execution ? and which results are independent of any search and are in fact graph properties (e.g. connected groups, diameters)? Because even if it is similar algorithms, it makes no sense to re-identify connected groups of the whole graph every time your're just interested in a quick search (unnecessary performance overhead).

So I'd recommend to isolate the queries about the general graph properties from the search results. For this you should structure the algorithm in a way to be able to reuse the common parts (either subfunction of classification). If performance is at stake, and if there’s an opportunity to avoid recalculating something, you can think of some form of caching (e.g. if and only if you have the graph diameter as by-product of a bfs, you could store this result for the graph, for later re-use, but otherwhise use a separate function that calculate it only when really needed).