pattern

I am upset every time I see a service calling another service when their business logic is not related to each other. Think about creating an entry in a security audit log or sending an email notification to the user once someone leaves a comment to their blog post. Calling these methods directly from a comment service would lead to a tightly coupled code which is hard to maintain and refactor.

A well-known solution to this problem is using aspect-oriented programming (AOP). However, you are usually limited to the original function arguments or its return value at most, having no access to the intermediate calculations. Before you try to refactor the code, introducing a new method just for a more suitable join point, let me show you another way first.

Unless you have a very simple UI, there are probably multiple views in your application, all having their own actions. The problem is, not all of these actions are disjunct – there are intersections, and we except to find some of them at particular places in the main menu or access over well-known keyboard shortcuts. The most obvious examples are copy & paste or delete actions, which are usually located under the Edit menu, assigned to standard key combinations (Ctrl+C, Ctrl+V, etc.) and sometimes put on the main toolbar. Creating individual actions for each view leads to multiple menu entries and shortcut conflicts, while creating a single action and managing its state and listening for its signals in individual views leads to complicated code and leaky abstractions. This problem can be solved using a proxy action, action multiplexer or context-aware action – an interesting pattern for Qt-based applications described in this blog post.