When do you stop encapsulation?

Question

I have an event handler on a border class that controls the persistence mechanism for a given general 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 for wrapping SimpleTransaction and TransactionPErsistor objects?

Is there any useful rule of thumb to understand if I need an extra level of encapsulation?

Currently, the rule of thumb is: "if the method is too large, do something about it." It is sometimes difficult to find the right balance between procedural and object-oriented when working with borderline event handlers.

Any opinion?

Greetings

Answer 1

Given that:

• - ( )

, API (I. )

( API), , , , , .

, , .

API public, , test ( ), .

, , MyEventHandler MyBoundaryClass, .

TransactionManager, ( ), MyBoundaryClass, . < > , , - ..

( , Daok) . , , .

, OO, , TransactionManager , .

, . , , . [...] , .

, TransactionManager, , , API , " ", . , . API.

, TransactionManager , :

• f ""
• TransactionManager, API (, initTransaction(), persistTransaction(),...), getter setter .

Answer 2

VonC, :

• , , .

• ( ) , , .

VonC API : , .

Answer 3

. .

A rule of thumb is the time it takes to validate your object. If you are performing Unit Testing, and realize that you are testing several different things (not in the same action in the field), you can try to break it.

For you , I would encapsulate your TransactionManager idea. Thus, the "TransactionManager" will process the transaction, not the "MyBoundaryClass".