This article is going to look at how to implement a parameterizable algorithm so it can both conform generally to the open\/closed principal and also most effectively be tested.<\/p>\n
A common pattern for code reuse, implementation selection, or extension, is to use class inheritance and the template method pattern. This is an example of an implementation of the template method pattern with two different variations We can always convert this template method pattern to a compositional pattern by performing a refactoring in the following steps (if you have member variable access there are a couple more steps, but I’ll cover them in a follow up article):<\/p>\n Step 1<\/strong>; encapsulate the construction of the B and C strategies:<\/p>\n Step 2<\/strong>; extract an interface for the strategy methods:<\/p>\n Step 3<\/strong>; pass the strategies into the superclass instead of using Changes to In the compositional style, In the compositional style If This article is going to look at how to implement a parameterizable algorithm so it can both conform generally to the open\/closed principal and also most effectively be tested. A common pattern for code reuse, implementation selection, or extension, is … Continue reading B<\/code> and C<\/code>:<\/p>\n\r\nabstract class A {\r\n public void doSomething() {\r\n doP();\r\n doQ();\r\n doR();\r\n }\r\n\r\n protected abstract void doP();\r\n protected abstract void doQ();\r\n protected abstract void doR();\r\n}\r\n\r\nclass B extends A {\r\n @Override protected void doP() { \/* do P the B way *\/}\r\n @Override protected void doQ() { \/* do Q the B way *\/}\r\n @Override protected void doR() { \/* do R the B way *\/}\r\n}\r\n\r\nclass C extends A {\r\n @Override protected void doP() { \/* do P the C way *\/}\r\n @Override protected void doQ() { \/* do Q the C way *\/}\r\n @Override protected void doR() { \/* do R the C way *\/}\r\n}\r\n<\/pre>\nRefactoring template method pattern to Strategy Pattern<\/h3>\n
\r\nabstract class A {\r\n public void doSomething() {\r\n doP();\r\n doQ();\r\n doR();\r\n }\r\n\r\n protected abstract void doP();\r\n protected abstract void doQ();\r\n protected abstract void doR();\r\n}\r\n\r\nclass B extends A {\r\n public static A createB() {\r\n return new B();\r\n }\r\n\r\n @Override protected void doP() { \/* do P the B way *\/}\r\n @Override protected void doQ() { \/* do Q the B way *\/}\r\n @Override protected void doR() { \/* do R the B way *\/}\r\n}\r\n\r\nclass C extends A {\r\n public static A createC() {\r\n return new C();\r\n }\r\n\r\n @Override protected void doP() { \/* do P the C way *\/}\r\n @Override protected void doQ() { \/* do Q the C way *\/}\r\n @Override protected void doR() { \/* do R the C way *\/}\r\n}<\/pre>\n\r\ninterface S {\r\n void doP();\r\n void doQ();\r\n void doR();\r\n}\r\n\r\nabstract class A implements S {\r\n private final S s = this;\r\n\r\n public void doSomething() {\r\n s.doP();\r\n s.doQ();\r\n s.doR();\r\n }\r\n}\r\n\r\nclass B extends A {\r\n public static A createB() {\r\n return new B();\r\n }\r\n\r\n @Override public void doP() { \/* do P the B way *\/}\r\n @Override public void doQ() { \/* do Q the B way *\/}\r\n @Override public void doR() { \/* do R the B way *\/}\r\n}\r\n\r\nclass C extends A {\r\n public static A createC() {\r\n return new C();\r\n }\r\n\r\n @Override public void doP() { \/* do P the C way *\/}\r\n @Override public void doQ() { \/* do Q the C way *\/}\r\n @Override public void doR() { \/* do R the C way *\/}\r\n}\r\n<\/pre>\nthis<\/code>:<\/p>\n\r\ninterface S {\r\n void doP();\r\n void doQ();\r\n void doR();\r\n}\r\n\r\nfinal class A {\r\n private final S s;\r\n\r\n public A(final S s) {\r\n this.s = s;\r\n }\r\n\r\n public void doSomething() {\r\n s.doP();\r\n s.doQ();\r\n s.doR();\r\n }\r\n}\r\n\r\nclass B implements S {\r\n public static A createB() {\r\n return new A(new B());\r\n }\r\n\r\n public void doP() { \/* do P the B way *\/}\r\n public void doQ() { \/* do Q the B way *\/}\r\n public void doR() { \/* do R the B way *\/}\r\n}\r\n\r\nclass C implements S {\r\n public static A createC() {\r\n return new A(new C());\r\n }\r\n\r\n public void doP() { \/* do P the C way *\/}\r\n public void doQ() { \/* do Q the C way *\/}\r\n public void doR() { \/* do R the C way *\/}\r\n}\r\n<\/pre>\nAdvantage of the compositional style<\/h3>\n
Less fragile<\/h4>\n
A<\/code> such as new methods are much less likely to break the strategies in the compositional style.<\/p>\nEasier to Test<\/h4>\n
class A<\/code> can be tested by itself using Mocks. As can class B<\/code> and class C<\/code>. In the inheritance style class B<\/code> and class C<\/code> cannot be tested without also testing class A<\/code>. This leads to duplication in the tests, as features of class A are re-tested for every subclass.<\/p>\nEasier to Reuse<\/h4>\n
class B<\/code> and class C<\/code> can be reused in other contexts where A is not relevant. In the inheritance style this type of reuse is not possible.<\/p>\nEmergent Model\/Domain concepts<\/h4>\n
class B<\/code> or class C<\/code> are reused in a different context, it may turn out that during subsequent refactoring they develop a new role within the system. I may even discover an important new domain concept.<\/p>\n","protected":false},"excerpt":{"rendered":"