views:

276

answers:

3

I have some event handler on a boundary class that manages a persistence mechanism for a given generic transaction:

void MyBoundaryClass::MyEventHandler(...)
{
  //retrieve stuff from the UI
  //...
  //declare and initialize trasaction to persist
  SimpleTransaction myTransaction(.../*pass down stuff*/);
  //do some other checks
  //...
  //declare transaction persistor
  TransactionPersistor myPersistor(myTransaction, .../*pass down connection to DB and other stuff*/);
  //persist transaction
  try
  {
    myPersistor.Persist();
  }
  catch(...)
  {
    //handle errors
  }
}

Would it be better to have some kind of TransactionManager to wrap SimpleTransaction and TransactionPErsistor objects?

Is there any useful rule of thumb to understand if I need a further level of encapsulation?

At the moment the rule of thumb I follow is "if the method gets too big - do something about it". It is hard sometimes to find the right balance between procedural and object oriented when dealing with boundary event handlers.

Any opinion?

Cheers

+3  A: 

Considering that:

  • the concept of encapsulation is about defining a container, and
  • object-oriented design is based on the concept of message passing (invocation of methods)

I would argue that the API is a good indication about the pertinence of a new high-level encapsulation (I.e. the definition of a new object)

If the services (i.e the API) offered by this new object are coherent, and are better exposed to the rest of the program when regrouped in one special object, then by all means, use a new object.

Otherwise, it is probable an overkill.

Since you expose a public API by creating a new object, the notion of test may be easier to do within that new object (and a few other mock objects), rather than create many legacy objects in order to test those same operations.

In your case, if you want to test the transaction, you must actually test MyEventHandler of MyBoundaryClass, in order to retrieve data from the UI.

But if you define a TransactionManager, that gives you the opportunity to lower coupling of different architecture levels (GUI vs. data) present in MyBoundaryClass, and to export data management into a dedicated class.
Then, you can test data persistence in independent test scenario, focusing especially on limit values, and database failure, and not-nominal conditions, and so on.

Testing scenario can help you refine the cohesion (great point mentioned by Daok) of your different objects. If your tests are simple and coherent, chances are that your objects have a well-define service boundary.

Since it can be argued that Coupling and Cohesion are two cornerstones of OO Programming, the cohesion of a new class like TransactionManager can be evaluated in term of the set of actions it will perform.

Cohesive means that a certain class performs a set of closely related actions. A lack of cohesion, on the other hand, means that a class is performing several unrelated tasks. [...] the application software will eventually become unmanageable as more and more behaviors become scattered and end up in wrong places.

If you regroup behaviors otherwise implemented in several different places into your TransactionManager, it should be fine, provided that its public API represent clear steps of what a transaction involves and not "stuff about transaction" like various utility functions. A name in itself is not enough to judge the cohesiveness of a class. The combination of the name and its public API is needed.

For instance, one interesting aspect of a TransactionManager would be to completely encapsulate the notion of Transaction, which would :

  • become virtually unkown by the rest f the system, and would lower coupling between the other classes and 'Transaction'
  • reinforce the cohesiveness of TransactionManager by centering its API around transaction steps (like initTransaction(), persistTransaction(), ...), avoiding any getter or setter for any Transaction instance.
VonC
+1 for advice that was clearly gained from experience!
Adam Liss
you make a great point - could integrate with a few considerations applying your general comment to my specific case/example?
JohnIdol
Thanks for your considerations. I already have a TransactionPersistor though - do you mean "But if you define a TransactionManager (...)"?
JohnIdol
TransactionManager indeed. Fixed
VonC
Cheers - one question: I am ok with decoupling but talking about highly cohesive classes, isn't "TransactionManager" a classic sample of a poorly cohesive class?
JohnIdol
I thought cohesive meant that the name of the class reflects exactly what the class responsibility is (from O'Reilly's "prefactoring") - in this case we are saying that a generic "TransactionManager" does/manages stuff "related" to Transaction ... not a hell of a name :-)
JohnIdol
The name is not enough to define cohesion: the name *and* the set of public API functions are needed, in order to see of those functions represents "stuff" about transactions (low cohesion), or clear steps of what a transaction involves (high cohesion)
VonC
So if my TransactionManager class was to expose methods such as SetTransaction, GetTransaction, PersistTransaction and so forth it would be highly cohesive 'cause name + public methods clearly define responsibility ... ?
JohnIdol
Yes, except for the 'getTransaction' part. It could be argue that the few operation/information you might need to do/request on a transaction could be better encapsulate and... managed by the TransactionManager, actually reinforcing its cohesiveness and lowering coupling btw system and transaction.
VonC
are you suggesting that the TransactionManager should completely wrap hence create a transaction so no need for Set Get methods?
JohnIdol
That is what I am suggesting at the end of this - lengthy - answer. But you will decide if that make sense regarding the rest of your system (which may actually need the transaction itself). If it does not need it directly, this is a great way to improve higher cohesiveness and lower coupling.
VonC
your answer was really helpful - thanks. The event handler method in object would shrink but my only concern with this is that I might end-up with more lines of code overall if I decide to go with a TransactionManager
JohnIdol
+2  A: 

Elaborating on VonC's suggestion, consider the following guidelines:

  • If you expect to invoke the same functions elsewhere, in the same way, it's reasonable to encapsulate them in a new object.

  • If one function (or one object) provides a set of facilities that are useful individually, it's reasonable to refactor it into smaller components.

VonC's point about the API is an excellent litmus test: create effective interfaces, and the objects often become apparent.

Adam Liss
And... +1 for the precisions. I will complete my answer
VonC
+1  A: 

The level of encapsulating should be directly linked to the cohesion of your object. Your object must do a single task or must be divided in multiple class and encapsulate all its behaviors and properties.

A rule of thumb is when it's time to test your object. If you are doing Unit Testing and you realize that you are testing multiple different thing (not in the same area action) than you might try to split it up.

For you case, I would encapsulate with your idea of "TransactionManager". This way the "TransactionManager" will handle how transaction works and not "MyBoundaryClass".

Daok
isn't TransactionManager too vague a name? Part of the problem is related to the fact that if you see a "manager" object you don't really know what it does - so cohesion of my object would be pretty poor
JohnIdol
+1 for buzzwords and theory backed up by practicality and a specific, helpful suggestion. Where were you guys before I learned the hard way? :-)
Adam Liss