The book "Patterns of object-oriented design"

Foreword

• The terminology has been updated (for example, the term "refactoring" has already taken root for the "reorganization" of the code, for the share it is "sharing" instead of "separation", and for mixin it is "admixture");
• updated style;
• unnecessarily bulky words have been eliminated (for example, “specification” or “instantiation.” The first can be quite adequately replaced with a “definition”, the second with “creating an instance”);
• the book is finally called “Object Oriented Design Patterns”.

PATTERN TEMPLATE METHOD (TEMPLATE METHOD)

void Application::OpenDocument (const char* name) {
      if (!CanOpenDocument(name)) {
          //   
          return;
      }

      Document* doc = DoCreateDocument();

      if (doc) {
          _docs->AddDocument(doc);
          AboutToOpenDocument(doc);
          doc->Open();
          doc->DoRead();
      }
}

• a single use of the invariant parts of the algorithm, while the implementation of the changing behavior remains at the discretion of the subclasses;
• the need to isolate and localize in one class the behavior common to all subclasses in order to avoid code duplication. This is a good example of the “bracketing to generalize” technique described by William Opdyke and Ralph Johnson [OJ93]. First, differences in the existing code are revealed, which are then transferred to separate operations. Ultimately, the different code fragments are replaced by the template method from which new operations are called;
• subclass extension management. The template method can be defined so that it will trigger hooks — see the Results section — at specific points, thereby allowing expansion only at these points.

• defines abstract primitive operations that are replaced in specific subclasses to implement the steps of the algorithm;
• implements a template method that defines the skeleton of an algorithm. The template method calls primitive operations, as well as operations defined in the AbstractClass class or in other objects;

• implements primitive operations that perform the steps of the algorithm in a way that depends on the subclass.

• specific operations (either from the ConcreteClass class, or from the client classes);
• specific operations from the AbstractClass class (that is, operations useful to all subclasses);
• primitive operations (i.e. abstract operations);
• factory methods (see factory method pattern (135));
• hook operations that implement default behavior that can be extended in subclasses. Often, such a default operation does nothing.

void DerivedClass::Operation () {
      //   DerivedClass
      ParentClass::Operation();
}

void ParentClass::Operation () {
      //  ParentClass
      HookOperation();
}

void ParentClass::HookOperation () { }

void DerivedClass::HookOperation () {
   //    
}

• C++. , , . , . , , . , -;
• . , . , ;
• naming convention. You can highlight operations that need to be replaced by adding a prefix to their names. For example, in the MacApp framework for Macintosh applications [App89], template method names begin with the Do prefix: DoCreateDocument, DoRead, and so on.

void View::Display () {
      SetFocus();
      DoDisplay();
      ResetFocus();
}

void View::DoDisplay () { }

void MyView::DoDisplay () {
      //   
}