Geek Answers Handbook

Single responsibility in C ++. Should I implement it using friend classes or other accessories?

I want to follow the principle of single responsibility in C ++. However, since I am breaking classes, it seems that in order for classes to "see" each other, I have the following options:

  • Add many more accessories for each class.
  • Make friendships with each other.
  • Improve the design (perhaps the fact that I will need to do 1 or 2 indicates a flaw in my design).

The question of friends and accessories was probably discussed earlier, but I did not know whether it was more profitable to use a single responsibility.

+4
source share
4 answers

Now that you have a group of classes that should all work together, you should consider how they should work together. If it is through access functions or friends, then you tightly bind classes. In the future, it would be difficult to abandon a new class that would do something else. It is also difficult to test classes because they are all interdependent.

Consider creating an interface class (s) that defines how your classes should interact. If some special privileges are not involved, this interface will also determine how it will communicate with someone. This way you break class interdependence. Any future changes are localized in the corresponding class. No one else should change (or even recompile).

+2
source

I always thought this was a BS rule. Most classes have several responsibilities and do no harm. Consider a bank account class - it may have responsibilities:

  • maintain customer information
  • allow transactions with debit and credit.
  • provide current balance
  • Report Questionable Security Transactions

Of course, these responsibilities are likely to be implemented using the other classes that make up the account.

+4
source

If you must expose personal data from one class to another, than make the second class a friend. Creating an accessor for your personal data is striking to make it private in the first place. The principle of single responsibility is not relevant to this.

Edit

In response to Dima’s comment below, I may have thought too much when I said “goal”. After all, there are several reasons why private data members are private. One of the reasons, according to Dima, is to protect the integrity of the object. Accessories really achieve this.

But the second (and, more importantly, in my opinion) reason is to hide the details of the class implementation. After you added public accessors, you lost control over how many other classes reference the implementation details of the class. Over time, this can make it difficult to change your implementation due to the cascading effect for other classes.

Classes of friends, although far from ideal, at least give you tight control over how many classes your changes will affect. Another advantage is that when you make changes, you know exactly which classes may be affected. So this is the best option when you should share your inner classes. But the best option for everyone (of course) is not to not disclose implementation details at all.

+3
source

You also have option 4: add more classes to represent different roles / interactions between classes.

This is at least more consistent with Demeter’s law.

+1
source

More articles:


All Articles