Abstraction in business logic classes

Question

When you call a method from a library you expect that it does exactly what its name implies it will do.

Connection c = driver.getConnection();

1. to give back a connection
   
2. to report an error if it fails
   
3. not to do more than expected
   

When writing "library code" it is very easy to stick with the decoupling, cohesion, abstraction principles. Not adhering to these, most times, means an error in design.

But when you are in business logic, some difficulties arise and perhaps the perspective has to be changed. At the business logic level i say:

session.connect(); //session is of Session type, my "business logic class"

and i expect that it reads the config file, takes defaults if it doesn't find it, connect, do some checking, decide which warning need to be notified to the user, for example the fact that the database version is older than the client software.

If you say that a method shouldn't do all this stuff because it must be cohesive, and apply this rigorously, you'll end up with a connect method with just one line:

 public class Session {
        ...
        Connection c;
        public void connect() {
             c = driver.getConnection();
        }      
 }

that is, the method connect of the business class Session will collapse to the underlying classes.

And the rest of the tasks? Read the file, check the db version etc?

You are postponing the businness code to a "big method" that will do all the logic.

And this is exactly my point.

If you apply cohesion and decoupling principles in a business logic context, you'll fail to subdivide tasks into smaller sub-tasks, and you will have some big "monolithic" methods doing all the work and being poorly readable.

I find the good principles (cohesion, abstraction) for low level libraries (Driver.getConnection()) quite inadequate for businness logic.

My ideas are:

1. cohesion has to be replaced with an entirely new concept
   
2. cohesion has to be "stretched" to a certain point
   

And since i prefer the 2nd, my question is what is that point.

Answer 1

I think you are missing some parts in OOP concepts and good design. If your code is not readable anymore - as Martin Fowler mentioned it, if your code smells - because of your tries to increase cohesion or reduce coupling (you can't remove coupling to %0 or you can't increase cohesion upto 100%. As you try this, you get a code like your connect() example above), you are on a wrong way. Because, these concepts are there to make your code more readable. There are also refactoring concepts like "extract method" to increase cohesion. Cohesion and Coupling are usually used with adjectives, "lower coupling" and "higher cohesion". How low or high they must be, the designer must decide/optimise it. By the way, if you session.connect() calls, i don't expect that the connection has to be configured. To do this, there are many other concepts like connection factory, session manager and Co. If the connection is once configured, then you can call connect() method to establish a physical connection to device (database).

Answer 2

And since i prefer the 2nd, my question is what is that point.

I don't think this is answerable in any meaningful way.

As @Erhan's answer points out, Cohesion and Coupling are measures that are "in tension" with other measures, and with the principles of design (OO and otherwise). If you ignore common sense and attempt to max/minimize these measures in isolation, you end up with unreadable code.

IMO, the best approach is to develop a good intuition of what makes your code readable and your design comprehensible. Pay some attention to the various measures, but if they contradict your intuition, be prepared to ignore them. If you are unsure if your intuition is correct, ask a more experienced developer to review your work.

Always remember that the various measures (cohesion, coupling, complexity, test coverage) are empirical, as are "good design" and "best practice". They ignore the realities of the problem that you are trying to solve. Don't use them as an excuse for not thinking and using your judgement.