I've just been reading through the SOLID principles, and this is one I have real difficulty with when designing software. I am relatively new (4 months professionally) at coding.

The idea is simply to encapsulate classes into ones that perform a single task.

For example, what if you have a class that creates and populates a Treeview and configures it to your specification. You then want data retrieved from a database when the user clicks on the nodes. Would you say this is two separate concerns?

Populate and configure the treeview

Obtain data from the database?

Also, in the same app. You have a datagridview that is also populated with dynamic data. Would you therefore put that data retrieval in the same class as the treeview data retrieval or would that be yet another completely seperate class?

5 Answers
5

Separation of concerns

Each object does its own job. Thus in your example the tree view knows only about being a tree view (presumably displaying data). It may may load its own data but it should not know where the data is coming from. If it knows were the data is coming from then it is tightly coupled with the data source (i.e. It may be a DB now, but what happens in version 2 when you need to get data from the space shuttle?).

Instead you should pass the tree view an interface (that it knows how to use) to retrieve its data from:

If you re-use the DataRetrieveInterface for the grid is something you need to decide as part of your design. Is generic enough? Alternatively you can derive from this interface and have something more grid-specific for the grid object. At this point there is not enough information in the question to say if you should or should not have a different interface for the grid.

I've found personally that it's preferable to separate serialization/deserialization from the actual classes. If you have an class which given data in some format (xml/dataset/json or what you prefer) builds/loads the class. The class should have no dependencies relating to serialization.

That way you can more easily change serialization methods , support different kinds of data and so forth

Rendering data, and retrieving data, are two separate concerns, and so belong in separate objects.

You might have a situation where it makes sense to have a single data retrieval class feeding data to a tree view and a data grid: two different views on the same data. Off-hand it seems unlikely: trees and tables aren't terribly similar.

Possibly you'll find it easier to think of it less as a theory thing and more as a practical thing.

Imagine that you're writing two apps which will provide identical functionality but through two completely different front ends - one web client, one native desktop client (assume both are being written in the same language).

Now, design and code that in such a way that you have as little duplication as is practically possible.

In terms of separating out data retrieval (actually getting the data) and business logic (applying processing and logic to that data), do the same but now assuming that you will have to implement the same solution for both SQL Server and data storage using XML flat files.

Again, design and code in such a way that you have as little duplication as is practically possible.