ploeh blog danish software design en-us Mark Seemann Fri, 23 Mar 2018 08:49:46 UTC Fri, 23 Mar 2018 08:49:46 UTC Functors Thu, 22 Mar 2018 16:57:00 UTC <div id="post"> <p> <em>A functor is a common abstraction. While typically associated with functional programming, functors exist in C# as well.</em> </p> <p> This article series is part of <a href="">a larger series of articles about functors, applicatives, and other mappable containers</a>. </p> <p> Programming is about abstraction, since you can't manipulate individual sub-atomic particles on your circuit boards. Some abstractions are well-known because they're rooted in mathematics. Particularly, <a href="">category theory</a> has proven to be fertile ground for functional programming. Some of the concepts from category theory apply to object-oriented programming as well; all you need is generics, which is a feature of both C# and Java. </p> <p> In previous articles, you got an introduction to the specific <a href="">Test Data Builder</a> and <a href="">Test Data Generator</a> functors. Functors are more common than you may realise, although in programming, we usually work with a subset of functors called <em>endofunctors</em>. In daily speak, however, we just call them <em>functors</em>. </p> <p> In the next series of articles, you'll see plenty of examples of functors, with code examples in both C#, F#, and Haskell. These articles are mostly aimed at object-oriented programmers curious about the concept. <ul> <li>Maybe</li> <li>Tree</li> <li>Visitor</li> <li>Observable</li> </ul> This list is far from exhaustive; more functors exist. Perhaps the most well-known of all functors is List, a.k.a. Sequence. C# query syntax can handle any functor, but most people only think of it as a language feature related to <code>IEnumerable&lt;T&gt;</code>. Since the combination of <code>IEnumerable&lt;T&gt;</code> and query syntax is already well-described, I'm not going to cover it explicitly here. </p> <p> If you understand how LINQ, <code>IEnumerable&lt;T&gt;</code>, and C# query syntax works, however, all other functors should feel intuitive. That's the power of abstractions. </p> <p> <strong>Overview</strong> </p> <p> The purpose of this article isn't to give you a comprehensive introduction to the category theory of functors. Rather, the purpose is to give you an opportunity to learn how it translates to object-oriented code like C#. For a great introduction to functors, see <a href="">Bartosz Milewski</a>'s <a href="">explanation with illustrations</a>. </p> <p> In short, a functor is a mapping between two categories. A functor maps not only objects, but also functions (called <em>morphisms</em>) between objects. For instance, a functor <em>F</em> may be a mapping between the categories <em>C</em> and <em>D</em>: </p> <p> <img src="/content/binary/functor-diagram.png" alt="Functor diagram."> </p> <p> Not only does <em>F</em> map <em>a</em> from <em>C</em> to <em>F a</em> in <em>D</em> (and likewise for <em>b</em>), it also maps the function <em>f</em> to <em>F f</em>. Functors preserve the structure between objects. You'll often hear the phrase that a functor is a <em>structure-preserving map</em>. One example of this regards lists. You can translate a <code>List&lt;int&gt;</code> to a <code>List&lt;string&gt;</code>, but the translation preserves the structure. This means that the resulting object is also a list, and the order of values within the lists doesn't change. </p> <p> In category theory, categories are often named <em>C</em>, <em>D</em>, and so on, but an example of a category could be <code>IEnumerable&lt;T&gt;</code>. If you have a function that translates integers to strings, the the source <em>object</em> (that's what it's called, but it's not the same as an OOP object) could be <code>IEnumerable&lt;int&gt;</code>, and the destination object could be <code>IEnumerable&lt;string&gt;</code>. A functor, then, represents the ability to go from <code>IEnumerable&lt;int&gt;</code> to <code>IEnumerable&lt;string&gt;</code>, and since the <a href="">Select</a> method gives you that ability, <code>IEnumerable&lt;T&gt;.Select</code> is a functor. In this case, you sort of 'stay within' the category of <code>IEnumerable&lt;T&gt;</code>, only you change the generic type argument, so this functor is really an endofunctor (the <em>endo</em> prefix is from Greek, meaning <em>within</em>). </p> <p> As a rule of thumb, if you have a type with a generic type argument, it's a candidate to be a functor. Such a type is not always a functor, because it also depends on where the generic type argument appears, and some other rules. </p> <p> Fundamentally, you must be able to implement a method for your generic type that looks like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Functor</span>&lt;<span style="color:#2b91af;">TResult</span>&gt;&nbsp;Select&lt;<span style="color:#2b91af;">TResult</span>&gt;(<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">T</span>,&nbsp;<span style="color:#2b91af;">TResult</span>&gt;&nbsp;selector) </pre> </p> <p> Here, I've defined the <code>Select</code> method as an instance method on a class called <code>Functor&lt;T&gt;</code>, but often, as is the case with <code>IEnumerable&lt;T&gt;</code>, the method is instead implemented as an extension method. You don't have to name it <code>Select</code>, but doing so enables query syntax in C#: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;dest&nbsp;=&nbsp;<span style="color:blue;">from</span>&nbsp;x&nbsp;<span style="color:blue;">in</span>&nbsp;source &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">select</span>&nbsp;x.ToString();</pre> </p> <p> Here, <code>source</code> is a <code>Functor&lt;int&gt;</code> object. </p> <p> If you don't name the method <code>Select</code>, it could still be a functor, but then query syntax wouldn't work. Instead, normal method-call syntax would be your only option. This is, however, a specific C# language feature. F#, for example, has no particular built-in awareness of functors, although most libraries name the central function <code>map</code>. In Haskell, <code>Functor</code> is a typeclass that defines a function called <code>fmap</code>. </p> <p> The common trait is that there's an input value (<code>Functor&lt;T&gt;</code> in the above C# code snippet), which, when combined with a mapping function (<code>Func&lt;T, TResult&gt;</code>), returns an output value of the same generic type, but with a different generic type argument (<code>Functor&lt;TResult&gt;</code>). </p> <p> <strong>Laws</strong> </p> <p> Defining a <code>Select</code> method isn't enough. The method must also obey the so-called <em>functor laws</em>. These are quite intuitive laws that govern that a functor behaves correctly. </p> <p> The first law is that mapping the identity function returns the functor unchanged. The <em>identity function</em> is a function that returns all input unchanged. (It's called the <em>identity function</em> because it's the <em>identity</em> for the <a href="">endomorphism monoid</a>.) In F# and Haskell, this is simply a built-in function called <code>id</code>. </p> <p> In C#, you can write a demonstration of the law as a unit test: </p> <p> <pre>[<span style="color:#2b91af;">Theory</span>] [<span style="color:#2b91af;">InlineData</span>(-101)] [<span style="color:#2b91af;">InlineData</span>(-1)] [<span style="color:#2b91af;">InlineData</span>(0)] [<span style="color:#2b91af;">InlineData</span>(1)] [<span style="color:#2b91af;">InlineData</span>(42)] [<span style="color:#2b91af;">InlineData</span>(1337)] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;FunctorObeysFirstFunctorLaw(<span style="color:blue;">int</span>&nbsp;value) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">int</span>,&nbsp;<span style="color:blue;">int</span>&gt;&nbsp;id&nbsp;=&nbsp;x&nbsp;=&gt;&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;sut&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Functor</span>&lt;<span style="color:blue;">int</span>&gt;(value); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(sut,&nbsp;sut.Select(id)); }</pre> </p> <p> While this doesn't <em>prove</em> that the first law holds for all values and all generic type arguments, it illustrates what's going on. </p> <p> Since C# doesn't have a built-in identity function, the test creates a specialised identity function for integers, and calls it <code>id</code>. It simply returns all input values unchanged. Since <code>id</code> doesn't change the value, then <code>Select(id)</code> shouldn't change the functor, either. There's nothing more to the first law than this. </p> <p> The second law states that if you have to functions, <code>f</code> and <code>g</code>, then mapping over one after the other should be the same as mapping over the composition of <code>f</code> and <code>g</code>. In C#, you can illustrate it like this: </p> <p> <pre>[<span style="color:#2b91af;">Theory</span>] [<span style="color:#2b91af;">InlineData</span>(-101)] [<span style="color:#2b91af;">InlineData</span>(-1)] [<span style="color:#2b91af;">InlineData</span>(0)] [<span style="color:#2b91af;">InlineData</span>(1)] [<span style="color:#2b91af;">InlineData</span>(42)] [<span style="color:#2b91af;">InlineData</span>(1337)] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;FunctorObeysSecondFunctorLaw(<span style="color:blue;">int</span>&nbsp;value) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">int</span>,&nbsp;<span style="color:blue;">string</span>&gt;&nbsp;&nbsp;&nbsp;&nbsp;g&nbsp;=&nbsp;i&nbsp;=&gt;&nbsp;i.ToString(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">string</span>,&nbsp;<span style="color:blue;">string</span>&gt;&nbsp;f&nbsp;=&nbsp;s&nbsp;=&gt;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:blue;">string</span>(s.Reverse().ToArray()); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;sut&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Functor</span>&lt;<span style="color:blue;">int</span>&gt;(value); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(sut.Select(g).Select(f),&nbsp;sut.Select(i&nbsp;=&gt;&nbsp;f(g(i)))); }</pre> </p> <p> Here, <code>g</code> is a function that translates an <code>int</code> to a <code>string</code>, and <code>f</code> reverses a string. Since <code>g</code> returns <code>string</code>, you can compose it with <code>f</code>, which takes <code>string</code> as input. </p> <p> As the assertion points out, it shouldn't matter if you call <code>Select</code> piecemeal, first with <code>g</code> and then with <code>f</code>, or if you call <code>Select</code> with the composed function <code>f(g(i))</code>. </p> <p> <strong>Summary</strong> </p> <p> This is not a monad tutorial; it's a functor tutorial. Functors are commonplace, so it's worth keeping an eye out for them. If you already understand how LINQ (or similar concepts in Java) work, then functors should be intuitive, because they are all based on the same underlying maths. </p> <p> While this article is an overview article, it's also a part of <a href="">a larger series of articles</a> that explore what object-oriented programmers can learn from category theory. </p> <p> <strong>Next:</strong> Maybe. </p> </div><hr> This blog is totally free, but if you like it, please <a href="">buy me a cup of coffee</a>. Mark Seemann Functors, applicatives, and friends Mon, 19 Mar 2018 08:35:00 UTC <div id="post"> <p> <em>Functors and related data structures are containers of values. It's a family of abstractions. An overview for object-oriented programmers.</em> </p> <p> This article series is part of <a href="">an even larger series of articles about the relationship between design patterns and category theory.</a> </p> <p> If you've worked with C# or Java recently, you've most likely encountered types such as <code>Foo&lt;T&gt;</code> or <code>Bar&lt;T&gt;</code> (specifically, on .NET, e.g. <a href="">List&lt;T&gt;</a>). Perhaps you've also noticed that often, you can translate the type inside of <a href="">the container</a>. For example, if you have a <code>Foo&lt;string&gt;</code>, perhaps you can call some method on it that returns a <code>Foo&lt;int&gt;</code>. If so, it may be a <em>functor</em>. </p> <p> Not all generic types are functors. In order to be a functor, a generic type must obey a couple of intuitive laws. You'll learn about those in future articles. </p> <p> Some functors have extra capabilities, and you'll learn about some of those as well. Some are called <em>applicative functors</em>, and some are called <em>bifunctors</em>. There are others, as well. </p> <p> <img src="/content/binary/functors-applicatives-bifunctors.png" alt="Functors, applicative functors, and bifunctors as subsets of each other."> </p> <p> All applicative functors are functors, and this is true for bifunctors as well. </p> <p> In this article series, you'll learn about the following categories: <ul> <li><a href="">Functors</a> <ul> <li>Maybe</li> <li>Tree</li> <li>Visitor</li> <li>Observable</li> </ul> </li> <li>Applicative functors <ul> <li>Deck of cards</li> <li>Guess a password</li> <li>Applicative sequences as combinations</li> <li>Maybe</li> <li>Validation</li> <li>Test Data Generator</li> <li>Danish CPR numbers in F#</li> </ul> </li> <li>Bifunctors <ul> <li>Tuple bifunctor</li> <li>Either bifunctor</li> </ul> </li> </ul> You'll see plenty of examples along the way. Most examples will be in C#, but some articles will have code examples in <a href="">F#</a> or <a href="">Haskell</a>. You can read or skip those articles as you prefer. </p> <p> <strong>Next:</strong> <a href="">Functors</a>. </p> </div><hr> This blog is totally free, but if you like it, please <a href="">buy me a cup of coffee</a>. Mark Seemann Composite as a monoid Mon, 12 Mar 2018 09:39:00 UTC <div id="post"> <p> <em>When can you use the Composite design pattern? When the return types of your methods are monoids.</em> </p> <p> This article is part of <a href="">a series of articles about design patterns and their universal abstraction counterparts</a>. </p> <p> The <a href="">Composite</a> design pattern is a powerful way to structure code, but not all objects are composable. When is an object composable? This article explores that question. </p> <p> In short, Composites are <a href="">monoids</a>. </p> <p> <img src="/content/binary/composite-as-subset-of-monoid.png" alt="Composite shown as a subset of the set of monoids."> </p> <p> Not all monoids are Composites, but as far as I can tell, all Composites are monoids. </p> <p> <strong>Composite</strong> </p> <p> First, I'll use various <a href="">software design isomorphisms</a> to put Composite in a canonical form. From <a href="">unit isomorphisms</a>, <a href="">function isomorphisms</a>, and <a href="">argument list isomorphisms</a>, we know that we can represent any method as a method or function that takes a single argument, and returns a single output value. From <a href="">abstract class isomorphism</a> we know that we can represent an abstract class with interfaces. Thus, you can represent the interface for a Composite like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IInterface1</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Out1</span>&nbsp;Op1(<span style="color:#2b91af;">In1</span>&nbsp;arg); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Out2</span>&nbsp;Op2(<span style="color:#2b91af;">In2</span>&nbsp;arg); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Out3</span>&nbsp;Op3(<span style="color:#2b91af;">In3</span>&nbsp;arg); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;More&nbsp;operations...</span> }</pre> </p> <p> In order to create a Composite, we must be able to take an arbitrary number of implementations and make them look like a single object. </p> <p> <strong>Composite as monoid</strong> </p> <p> You have a set of implementations of <code>IInterface1</code>. In order to create a Composite, you loop over all of those implementations in order to produce an aggregated result. Imagine that you have to implement a <code>CompositeInterface1</code> class that composes <code>imps</code>, an <code>IReadOnlyCollection&lt;IInterface1&gt;</code>. In order to implement <code>Op1</code>, you'd have to write code like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Out1</span>&nbsp;Op1(<span style="color:#2b91af;">In1</span>&nbsp;arg) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">foreach</span>&nbsp;(<span style="color:blue;">var</span>&nbsp;imp&nbsp;<span style="color:blue;">in</span>&nbsp;<span style="color:blue;">this</span>.imps) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;out1&nbsp;=&nbsp;imp.Op1(arg); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Somehow&nbsp;combine&nbsp;this&nbsp;out1&nbsp;value&nbsp;with&nbsp;previous&nbsp;values</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Return&nbsp;combined&nbsp;Out1&nbsp;value</span> }</pre> </p> <p> This implies that we have an ordered, finite sequence of implementations: <em>imp1, imp2, imp3, ...</em>. In C#, we could represent such a sequence with the type <code>IReadOnlyCollection&lt;IInterface1&gt;</code>. Somehow, we need to turn that collection into a single <code>IInterface1</code> value. In other words, we need a translation of the type <code>IReadOnlyCollection&lt;IInterface1&gt; -&gt; IInterface1</code>. </p> <p> If we look to <a href="">Haskell</a> for inspiration for a moment, let's replace <code>IReadOnlyCollection&lt;T&gt;</code> with Haskell's built-in linked list. This means that we need a function of the type <code>[IInterface1] -&gt; IInterface1</code>, or, more generally, <code>[a] -&gt; a</code>. This function exists for all <code>a</code> as long as <code>a</code> forms a monoid; it's called <code>mconcat</code>: </p> <p> <pre>mconcat :: Monoid a =&gt; [a] -&gt; a</pre> </p> <p> We also know from a previous article that <a href="">a collection of monoids can be reduced to a single monoid</a>. Notice how the above outline of a composite implementation of <code>Op1</code> looks similar to the <code>Accumulate</code> method shown in the linked article. If <code>IInterface1</code> can form a monoid, then you can make a Composite. </p> <p> <strong>Objects as monoids</strong> </p> <p> When can an object (like <code>IInterface1</code>) form a monoid? </p> <p> From <a href="">object isomorphisms</a> we know that we can decompose an object with <em>n</em> members to <em>n</em> static methods. This means that instead of analysing all of <code>IInterface1</code>, we can consider the properties of each method in isolation. The properties of an object is the consolidation of the properties of all the methods. </p> <p> Recall, still from <em>object isomorphisms</em>, that we can represent an object as a tuple of functions. Moreover, <a href="">if you have a tuple of monoids, then the tuple also forms monoid</a>! </p> <p> In order to make an object a monoid, then, you have to make each method a monoid. When is a method a monoid? <a href="">A method is a monoid when its return type forms a monoid</a>. </p> <p> That's it. An interface like <code>IInterface1</code> is a monoid when <code>Out1</code>, <code>Out2</code>, <code>Out3</code>, and so on, form monoids. If that's the case, you can make a Composite. </p> <p> <strong>Examples</strong> </p> <p> From <em>unit isomorphism</em>, we know that we can represent C#'s and Java's <em>void</em> keywords with methods returning <em>unit</em>, and <em>unit</em> is a monoid. All methods that return <code>void</code> can be part of a Composite, but we already knew that <a href="">Commands are composable</a>. If you search for examples of the Composite design pattern, you'll find more than one variation involving drawing shapes on a digital canvas, with the central operation being a <code>Draw</code> method with a <code>void</code> return type. </p> <p> Another example could be calculation of the price of a shopping basket. If you have an interface method of the type <code>decimal Calculate(Basket basket)</code>, you could have several implementations: <ul> <li>Add all the item prices together</li> <li>Apply a discount (a negative number)</li> <li>Calculate sales tax</li> </ul> These could be three implementations of the same interface method, and since decimal numbers form a monoid over addition, then you can make a Composite basket calculator out of the three implementations. </p> <p> Boolean values also form at least two monoids (<em>any</em> and <em>all</em>), so any method you have that returns a Boolean value can be used in a Composite. You could, for example, have a list of criteria for granting a loan. Each such business rule returns <code>true</code> if it evaluates that the loan should be granted, and <code>false</code> otherwise. If you have more than one business rule, you can create a Composite that returns <code>true</code> only if all the individual rules return <code>true</code>. </p> <p> If you have a method that returns a string, then that is also a candidate for inclusion in a Composite, if string concatenation makes sense in the domain in question. </p> <p> You probably find it fairly mundane that you can create a Composite if all the methods involved return numbers, strings, Booleans, or nothing. The result generalises, however, to all monoids, including more complex types, including methods that return other interfaces that themselves form monoids, and so on recursively. </p> <p> <strong>Granularity</strong> </p> <p> The result, then, is that you can make a Composite when <em>all</em> methods in your interface have monoidal return types. If only a single method has a return type that isn't a monoid, you can't aggregate that value, and you can't make a Composite. </p> <p> Your interface can have as many methods you like, but they must all be monoids. Even one rogue method will prevent you from being able to create a Composite. This is another argument for <a href="">Role Interfaces</a>. The smaller an interface is, the more likely it is that you can make a Composite out of it. If you follow that line of reasoning to its ultimate conclusion, you'll <a href="">design your interfaces with a single member each</a>. </p> <p> <strong>Relaxation</strong> </p> <p> There can be some exceptions to the rule that all return values must be monoids. If you have at least one implementation of your interface, then a <a href="">semigroup</a> may be enough. Recall that monoids accumulate like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Foo</span>&nbsp;Accumulate(<span style="color:#2b91af;">IReadOnlyCollection</span>&lt;<span style="color:#2b91af;">Foo</span>&gt;&nbsp;foos) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;acc&nbsp;=&nbsp;Identity; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">foreach</span>&nbsp;(<span style="color:blue;">var</span>&nbsp;f&nbsp;<span style="color:blue;">in</span>&nbsp;foos) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;acc&nbsp;=&nbsp;acc.Op(f); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;acc; }</pre> </p> <p> You only need <code>Identity</code> in order to start the accumulation, and to have something to return in case you have no implementations. If you have at least one implementation, you don't need the identity, and then <a href="">a semigroup is enough to accumulate</a>. Consider the <a href="">bounding box example</a>. If you have a method that returns <code>BoundingBox</code> values, you can still make a Composite out of such an interface, as long as you have at least one implementation. There's no 'identity' bounding box, but it makes intuitive sense that you can still compose bounding boxes into bigger bounding boxes. </p> <p> Haskell formalises the rule for semigroups: </p> <p> <pre>sconcat :: Semigroup a =&gt; Data.List.NonEmpty.NonEmpty a -&gt; a</pre> </p> <p> The <code>sconcat</code> function reduces any non-empty list of any semigroup <code>a</code> to a single <code>a</code> value. </p> <p> If you have a non-empty list of implementations, then perhaps you don't even need a semigroup. Perhaps any <a href="">magma</a> will work. Be aware, however, that the lack of associativity will cause the order of implementations to matter. </p> <p> Technically, you may be able to program a Composite from a magma, but I'd suggest caution. The monoid and semigroup laws are intuitive. A magma without those properties may not form an intuitive Composite. While it may compile, it may have surprising, or counter-intuitive, behaviour. I'd favour sticking to monoids or semigroups. </p> <p> <strong>Summary</strong> </p> <p> When is an object-oriented design composable? Composition could mean more than one thing, but this article has focused exclusively on the Composite design pattern. When can you use the Composite pattern? When all method return types are monoids. </p> <p> <strong>Next: </strong> Coalescing Composite as a monoid. </p> </div><hr> This blog is totally free, but if you like it, please <a href="">buy me a cup of coffee</a>. Mark Seemann Some design patterns as universal abstractions Mon, 05 Mar 2018 08:10:00 UTC <div id="post"> <p> <em>Some design patterns can be formalised by fundamental abstractions.</em> </p> <p> Wouldn't it be wonderful if you could assemble software from predefined building blocks? This idea is <em>old</em>, and has been the driving force behind object-oriented programming (OOP). In <a href="">Douglas Coupland</a>'s 1995 novel <a href="">Microserfs</a>, the characters attempt to reach that goal through a project called <em>Oop!</em>. <a href="">Lego bricks</a> play a role as a metaphor as well. </p> <p> <img src="/content/binary/lego-bricks-as-connections.png" alt="Lego bricks."> </p> <p> Decades later, it doesn't look like we're much nearer that goal than before, but I believe that we'd made at least two (rectifiable) mistakes along the way: <ul> <li>Granularity</li> <li>Object-orientation</li> </ul> While I'm going to discuss both of these briefly, my principal message is one of hope. I still think we can assemble software from predefined 'things', but I believe that these 'things' are small and 'objects' in a different sense than normal. </p> <p> <strong>Granularity</strong> </p> <p> Over the years, I've seen several attempts at reducing software development to a matter of putting things together. These attempts have invariably failed. </p> <p> I believe that one of the reasons for failure is that such projects tend to aim at coarse-grained building blocks. As I explain in the <em>Interface Segregation Principle</em> module of my <a href="">Encapsulation and SOLID</a> Pluralsight course, granularity is a crucial determinant for your ability to create. The coarser-grained the building blocks, the harder it is to create something useful. </p> <p> Most attempts at software-as-building-blocks have used big, specialised building blocks aimed at non-technical users (<em>"Look! Create an entire web site without writing a single line of code!"</em>). That's just like <a href="">Duplo</a>. You can create exactly what the blocks were designed for, but as soon as you try to create something new and original, you can't. </p> <p> <strong>Object-orientation</strong> </p> <p> OOP is another attempt at software-as-building-blocks. In .NET (the OOP framework with which I'm most familiar) the Base Class Library (BCL) is enormous. Many of the reusable objects in the BCL are fine-grained, so at least it's often possible to put them together to create something useful. The problem with an object-oriented library like the .NET BCL, however, is that all the objects are <em>special</em>. </p> <p> The vision was always that software 'components' would be able to 'click' together, just like Lego bricks. The BCL isn't like that. Typically, objects have nothing in common apart from the useless <code>System.Object</code> base class. There's no system. In order to learn how the BCL works, you have to learn the ins and outs of every single class. </p> <p> Better know a framework. </p> <p> It doesn't help that OOP was never formally defined. Every time you see or hear a discussion about what 'real' object-orientation is, you can be sure that sooner or later, someone will say: "...but that's not what <a href="">Alan Kay</a> had in mind." </p> <p> What Alan Kay had in mind is still unclear to me, but it seems safe to say that it wasn't what we have now (C++, Java, C#). </p> <p> <strong>Building blocks from category theory</strong> </p> <p> While we (me included) have been on an a thirty-odd year long detour around object-orientation, I don't think all is lost. I still believe that a Lego-brick-like system exists for software development, but I think that it's a system that we have to <em>discover</em> instead of invent. </p> <p> As I already covered in the <a href="">introductory article</a>, <a href="">category theory</a> does, in fact, discuss 'objects'. It's not the same type of object that you know from C# or Java, but some of them do consist of data and behaviour - <a href="">monoids</a>, for example, or <a href="">functors</a>. Such object are more like types than objects in the OOP sense. </p> <p> Another, more crucial, difference to object-oriented programming is that these objects are lawful. An object is only a monoid if it obeys the monoid laws. An object is only a functor if it obeys the functor laws. </p> <p> Such objects are still fine-grained building blocks, but they fit into a system. You don't have to learn tens of thousands of specific objects in order to get to know a framework. You need to understand the system. You need to understand monoids, functors, applicatives, and a few other universal abstractions (yes: monads too). </p> <p> Many of these universal abstractions were almost discovered by the Gang of Four twenty years ago, but they weren't quite in place then. Much of that has to do with the fact that functional programming didn't seem like a realistic alternative back then, because of hardware limitations. This has all changed to the better. </p> <p> <strong>Specific patterns</strong> </p> <p> In the <a href="">introductory article about the relationship between design patterns and category theory</a>, you learned that some design patterns significantly overlap concepts from category theory. In this article series, we'll explore the relationships between some of the classic patterns and category theory. I'm not sure that all the patterns from <a href="">Design Patterns</a> can be reinterpreted as universal abstractions, but the following subset seems promising: <ul> <li><a href="">Composite as a monoid</a> <ul> <li>Coalescing Composite as a monoid</li> <li>Endomorphic Composite as a monoid</li> </ul> </li> <li>Null Object as identity</li> <li>Visitor</li> </ul> Granted, Null Object is actually not from <em>Design Patterns</em>, but as we shall see, it's a special case of Composite, so it fits well into that group. </p> <p> <strong>Summary</strong> </p> <p> Some design patterns closely resemble categorical objects. This article provides an overview, whereas the next articles in the series will dive into specifics. </p> <p> <strong>Next:</strong> <a href="">Composite as a monoid</a>. </p> </div><hr> This blog is totally free, but if you like it, please <a href="">buy me a cup of coffee</a>. Mark Seemann Inheritance-composition isomorphism Mon, 26 Feb 2018 07:24:00 UTC <div id="post"> <p> <em>Reuse via inheritance is isomorphic to composition.</em> </p> <p> This article is part of <a href="">a series of articles about software design isomorphisms</a>. </p> <p> Chapter 1 of <a href="">Design Patterns</a> admonishes: <blockquote> Favor object composition over class inheritance </blockquote> People sometimes struggle with this, because they use inheritance as a means to achieve reuse. That's not necessary, because you can use object composition instead. </p> <p> In the <a href="">previous article</a>, you learned that an abstract class can be refactored to a concrete class with injected dependencies. </p> <p> Did you you notice that there was an edge case that I didn't cover? </p> <p> I didn't cover it because I think it deserves its own article. The case is when you want to reuse a base class' functionality in a derived class. How do you do that with Dependency Injection? </p> <p> <strong>Calling base</strong> </p> <p> Imagine a virtual method: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">virtual</span>&nbsp;<span style="color:#2b91af;">OutVirt1</span>&nbsp;Virt1(<span style="color:#2b91af;">InVirt1</span>&nbsp;arg) </pre> </p> <p> In C#, a method is virtual when explicitly marked with the <code>virtual</code> keyword, whereas this is the default in Java. When you override a virtual method in a derived class, you can still invoke the parent class' implementation: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">override</span>&nbsp;<span style="color:#2b91af;">OutVirt1</span>&nbsp;Virt1(<span style="color:#2b91af;">InVirt1</span>&nbsp;arg) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this&nbsp;and&nbsp;arg</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;baseResult&nbsp;=&nbsp;<span style="color:blue;">base</span>.Virt1(arg); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;return&nbsp;an&nbsp;OutVirt1&nbsp;value</span> }</pre> </p> <p> When you override a virtual method, you can use the <code>base</code> keyword to invoke the parent implementation of the method that you're overriding. The enables you to reuse the base implementation, while at the same time adding new functionality. </p> <p> <strong>Virtual method as interface</strong> </p> <p> If you perform the refactoring to Dependency Injection shown in the previous article, you now have an interface: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IVirt1</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">OutVirt1</span>&nbsp;Virt1(<span style="color:#2b91af;">InVirt1</span>&nbsp;arg); }</pre> </p> <p> as well as a default implementation. In the previous article, I showed an example where a single class implements several 'virtual member interfaces'. In order to make this particular example clearer, however, here you instead see a variation where the default implementation of <code>IVirt1</code> is in a class that only implements that interface: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">DefaultVirt1</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IVirt1</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">OutVirt1</span>&nbsp;Virt1(<span style="color:#2b91af;">InVirt1</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;OutVirt1&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> <code>DefaultVirt1.Virt1</code> corresponds to the original virtual method on the abstract class. How can you 'override' this default implementation, while still make use of it? </p> <p> <strong>From base to composition</strong> </p> <p> You have a default implementation, and instead of replacing all of it, you want to somehow enhance it, but still use the 'base' implementation. Instead of inheritance, you can use composition: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">OverridingVirt1</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IVirt1</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IVirt1</span>&nbsp;@base&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">DefaultVirt1</span>(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">OutVirt1</span>&nbsp;Virt1(<span style="color:#2b91af;">InVirt1</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this&nbsp;and&nbsp;arg</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;baseResult&nbsp;=&nbsp;@base.Virt1(arg); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;return&nbsp;an&nbsp;OutVirt1&nbsp;value</span> &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> In order to drive home the similarity, I named the class field <code>@base</code>. I couldn't use <code>base</code> as a name, because that's a keyword in C#, but you can use the prefix <code>@</code> in order to use a keyword as a legal C# name. Notice that the body of <code>OverridingVirt1.Virt1</code> is almost identical to the above, inheritance-based overriding method. </p> <p> As a variation, you can inject <code>@base</code> via the constructor of <code>OverridingVirt1</code>, in which case you have a <a href="">Decorator</a>. </p> <p> <strong>Isomorphism</strong> </p> <p> If you already have an interface with a 'default implementation', and you want to reuse the default implementation, then you can use object composition as shown above. At its core, it's reminiscent of the Decorator design pattern, but instead of receiving the inner object via its constructor, it creates the object itself. You can, however, also use a Decorator in order to achieve the same effect. This will make your code more flexible, but possibly also more error-prone, because you no longer have any guarantee what the 'base' is. This is where the <a href="">Liskov Substitution Principle</a> becomes important, but that's a digression. </p> <p> If you're using the previous <a href="">abstract class isomorphism</a> to refactor to Dependency Injection, you can refactor any use of <code>base</code> to object composition as shown here. </p> <p> This is a special case of <em>Replace Inheritance with Delegation</em> from <a href="">Refactoring</a>, which also describes the inverse refactoring <em>Replace Delegation with Inheritance</em>, thereby making these two refactorings an isomorphism. </p> <p> <strong>Summary</strong> </p> <p> This article focuses on a particular issue that you may run into if you try to avoid the use of abstract classes. Many programmers use inheritance in order to achieve reuse, but this is in no way necessary. Favour composition over inheritance. </p> <p> <strong>Next:</strong> <a href="">Some design patterns as universal abstractions</a>. </p> </div> <hr> This blog is totally free, but if you like it, please <a href="">buy me a cup of coffee</a>. Mark Seemann Abstract class isomorphism Mon, 19 Feb 2018 13:10:00 UTC <div id="post"> <p> <em>Abstract classes are isomorphic to Dependency Injection.</em> </p> <p> This article is part of <a href="">a series of articles about software design isomorphisms</a>. </p> <p> The introduction to <a href="">Design Patterns</a> states: <blockquote> Program to an interface, not an implementation. </blockquote> When I originally read that, I took it quite literally, so I wrote all my C# code using interfaces instead of abstract classes. There are several reasons why, in general, that turns out to be a good idea, but that's not the point of this article. It turns out that it doesn't really matter. </p> <p> If you have an abstract class, you can refactor to an object model composed from interfaces without loss of information. You can also refactor back to an abstract class. These two refactorings are each others' inverses, so together, they form an isomorphism. </p> <p> <img src="/content/binary/abstract-class-to-interfaces-isomorphism.png" alt="Abstract class on the left, concrete class with injected interfaces on the right; arrow between boxes."> </p> <p> When refactoring an abstract class, you extract all its pure virtual members to an interface, each of its virtual members to other interfaces, and inject them into a concrete class. The inverse refactoring involves going back to an abstract class. </p> <p> This is an important result, because upon closer inspection, the Gang of Four didn't have C# or Java interfaces in mind. The book pre-dates both Java and C#, and its examples are mostly in C++. Many of the examples involve abstract classes, but more than ten years of experience has taught me that I can always write a variant that uses C# interfaces. That is, I believe, not a coincidence. </p> <p> <strong>Abstract class</strong> </p> <p> An abstract class in C# has this general shape: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">abstract</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Class1</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Data1</span>&nbsp;Data&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">set</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">abstract</span>&nbsp;<span style="color:#2b91af;">OutPureVirt1</span>&nbsp;PureVirt1(<span style="color:#2b91af;">InPureVirt1</span>&nbsp;arg); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">abstract</span>&nbsp;<span style="color:#2b91af;">OutPureVirt2</span>&nbsp;PureVirt2(<span style="color:#2b91af;">InPureVirt2</span>&nbsp;arg); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">abstract</span>&nbsp;<span style="color:#2b91af;">OutPureVirt3</span>&nbsp;PureVirt3(<span style="color:#2b91af;">InPureVirt3</span>&nbsp;arg); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;More&nbsp;pure&nbsp;virtual&nbsp;members...</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">virtual</span>&nbsp;<span style="color:#2b91af;">OutVirt1</span>&nbsp;Virt1(<span style="color:#2b91af;">InVirt1</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;OutVirt1&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">virtual</span>&nbsp;<span style="color:#2b91af;">OutVirt2</span>&nbsp;Virt2(<span style="color:#2b91af;">InVirt2</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;OutVirt2&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">virtual</span>&nbsp;<span style="color:#2b91af;">OutVirt3</span>&nbsp;Virt3(<span style="color:#2b91af;">InVirt3</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;OutVirt3&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;More&nbsp;virtual&nbsp;members...</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">OutConc1</span>&nbsp;Op1(<span style="color:#2b91af;">InConc1</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;OutConc1&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">OutConc2</span>&nbsp;Op2(<span style="color:#2b91af;">InConc2</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;OutConc2&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">OutConc3</span>&nbsp;Op3(<span style="color:#2b91af;">InConc3</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;OutConc3&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;More&nbsp;concrete&nbsp;members...</span> }</pre> </p> <p> Like in <a href="">the previous article</a>, I've deliberately kept the naming abstract (but added a more concrete example towards the end). The purpose of this article series is to look at the shape of code, instead of what it does, or why. From <a href="">argument list isomorphisms</a> we know that we can represent any method as taking a single input value, and returning a single output value. </p> <p> An abstract class can have non-virtual members. In C#, this is the default, whereas in Java, you'd explicitly have to use the <code>final</code> keyword. In the above generalised representation, I've named these non-virtual members <code>Op1</code>, <code>Op2</code>, and so on. </p> <p> An abstract class can also have virtual members. In C#, you must explicitly use the <code>virtual</code> keyword in order to mark a method as overridable, whereas this is the default for Java. In the above representation, I've called these methods <code>Virt1</code>, <code>Virt2</code>, etcetera. </p> <p> Some virtual members are <em>pure virtual</em> members. These are members without an implementation. Any concrete (that is: non-abstract) class inheriting from an abstract class must provide an implementation for such members. In both C# and Java, you must declare such members using the <code>abstract</code> keyword. In the above representation, I've called these methods <code>PureVirt1</code>, <code>PureVirt2</code>, and so on. </p> <p> Finally, an abstract class can contain data, which you can represent as a single data object, here of the type <code>Data1</code>. </p> <p> The concrete and virtual members could, conceivably, call other members in the class - both concrete, virtual, and pure virtual. In fact, this is how many of the design patterns in the book work, for example <a href="">Strategy</a>, <a href="">Template Method</a>, and <a href="">Builder</a>. </p> <p> <strong>From abstract class to Dependency Injection</strong> </p> <p> Apart from its <code>Data</code>, an abstract class contains three types of members: <ul> <li>Those that <em>must</em> be implemented by derived classes: pure virtual members</li> <li>Those that <em>optionally</em> can be overriden by derived classes: virtual members</li> <li>Those that cannot be overridden by derived classes: concrete, sealed, or final, members</li> </ul> When refactoring to interfaces, you do the following: <ol> <li>Extract an interface from the pure virtual members.</li> <li>Extract an interface from each of the virtual members.</li> <li>Implement each of the 'virtual member interfaces' with the implementation from the virtual member.</li> <li>Add a constructor to the abstract class that takes all these new interfaces as arguments. Save the arguments as class fields.</li> <li>Change all code in the abstract class to talk to the injected interfaces instead of direct class members.</li> <li>Remove the virtual and pure virtual members from the class, or make them non-virtual. If you keep them around, their implementation should be one line of code, delegating to the corresponding interface.</li> <li>Change the class to a concrete (non-abstract) class.</li> </ol> If you apply this refactoring to the above class, you should arrive at something like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">sealed</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Class1</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IInterface1</span>&nbsp;pureVirts; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IVirt1</span>&nbsp;virt1; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IVirt2</span>&nbsp;virt2; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IVirt3</span>&nbsp;virt3; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;More&nbsp;virt&nbsp;fields...</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Data1</span>&nbsp;Data&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">set</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;Class1( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IInterface1</span>&nbsp;pureVirts,&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IVirt1</span>&nbsp;virt1,&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IVirt2</span>&nbsp;virt2,&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IVirt3</span>&nbsp;virt3 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">/*&nbsp;More&nbsp;virt&nbsp;arguments...&nbsp;*/</span>) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.pureVirts&nbsp;=&nbsp;pureVirts; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.virt1&nbsp;=&nbsp;virt1; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.virt2&nbsp;=&nbsp;virt2; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.virt3&nbsp;=&nbsp;virt3; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;More&nbsp;field&nbsp;assignments</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">OutConc1</span>&nbsp;Op1(<span style="color:#2b91af;">InConc1</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;OutConc1&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">OutConc2</span>&nbsp;Op2(<span style="color:#2b91af;">InConc2</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;OutConc2&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">OutConc3</span>&nbsp;Op3(<span style="color:#2b91af;">InConc3</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;OutConc3&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;More&nbsp;concrete&nbsp;members...</span> }</pre> </p> <p> While not strictly necessary, I've marked the class <code>sealed</code> (<code>final</code> in Java) in order to drive home the point that this is no longer an abstract class. </p> <p> This is an example of the Constructor Injection design pattern. (This is not a Gang of Four pattern; you can find a description in <a href="">my book about Dependency Injection</a>.) </p> <p> Since it's optional to override virtual members, any class originally inheriting from an abstract class can choose to override only one, or two, of the virtual members, while leaving other virtual members with their default implementations. In order to support such piecemeal redefinition, you can extract each virtual member to a separate interface, like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IVirt1</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">OutVirt1</span>&nbsp;Virt1(<span style="color:#2b91af;">InVirt1</span>&nbsp;arg); }</pre> </p> <p> Notice that each of these 'virtual interfaces' are injected into <code>Class1</code> as a separate argument. This enables you to pass your own implementation of exactly those you wish to change, while you can pass in the default implementation for the rest. The default implementations are the original code from the virtual members, but moved to a class that implements the interfaces: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">DefaultVirt</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IVirt1</span>,&nbsp;<span style="color:#2b91af;">IVirt2</span>,&nbsp;<span style="color:#2b91af;">IVirt3</span> </pre> </p> <p> When inheriting from the original abstract class, however, you must implement all the pure virtual members, so you can extract a single interface from all the pure virtual members: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IInterface1</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">OutPureVirt1</span>&nbsp;PureVirt1(<span style="color:#2b91af;">InPureVirt1</span>&nbsp;arg); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">OutPureVirt2</span>&nbsp;PureVirt2(<span style="color:#2b91af;">InPureVirt2</span>&nbsp;arg); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">OutPureVirt3</span>&nbsp;PureVirt3(<span style="color:#2b91af;">InPureVirt3</span>&nbsp;arg); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;More&nbsp;pure&nbsp;virtual&nbsp;members...</span> }</pre> </p> <p> This forces anyone who wants to use the refactored (sealed) <code>Class1</code> to provide an implementation of all of those members. There's an edge case where you inherit from the original <code>Class1</code> in order to create a new <em>abstract</em> class, and implement only one or two of the pure virtual members. If you want to support that edge case, you can define an interface for each pure virtual member, instead of one big interface, similar to <code>IVirt1</code>, <code>IVirt2</code>, and so on. </p> <p> <strong>From Dependency Injection to abstract class</strong> </p> <p> I hope it's clear how to perform the inverse refactoring. Assume that the above sealed <code>Class1</code> is the starting point: <ol> <li>Mark <code>Class1</code> as <code>abstract</code>.</li> <li>For each of the members of <code>IInterface1</code>, add a pure virtual member.</li> <li>For each of the members of <code>IVirt1</code>, <code>IVirt2</code>, and so on, add a virtual member.</li> <li>Move the code from the default implementation of the 'virtual interfaces' to the new virtual members.</li> <li>Delete the dependency fields and remove the corresponding arguments from the constructor.</li> <li>Clean up orphaned interfaces and implementations.</li> </ol> This refactoring assumes a class using Dependency Injection like the one shown in this article, above. The example code is the same as the above example code, although the order is reversed: you start with the Dependency Injection class and end with the abstract class. </p> <p> <strong>Example: Gang of Four maze Builder as an abstract class</strong> </p> <p> As an example, consider the original Gang of Four example of the <a href="">Builder</a> pattern. The example in the book is based on an abstract class called <code>MazeBuilder</code>. Translated to C#, it looks like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">abstract</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">MazeBuilder</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">virtual</span>&nbsp;<span style="color:blue;">void</span>&nbsp;BuildMaze()&nbsp;{&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">virtual</span>&nbsp;<span style="color:blue;">void</span>&nbsp;BuildRoom(<span style="color:blue;">int</span>&nbsp;room)&nbsp;{&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">virtual</span>&nbsp;<span style="color:blue;">void</span>&nbsp;BuildDoor(<span style="color:blue;">int</span>&nbsp;roomFrom,&nbsp;<span style="color:blue;">int</span>&nbsp;roomTo)&nbsp;{&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">abstract</span>&nbsp;<span style="color:#2b91af;">Maze</span>&nbsp;GetMaze(); }</pre> </p> <p> In the book, all four methods are virtual, because: <blockquote> "They're not declared pure virtual to let derived classes override only those methods in which they're interested." </blockquote> When it comes to the <code>GetMaze</code> method, this means that the method in the book returns a null reference by default. Since this seems like poor API design, and also because the example becomes more illustrative if the class has both abstract and virtual members, I changed it to be abstract (i.e. pure virtual). </p> <p> In general, there are various other issues with this design, the most glaring of which is the implied <a href="">sequence coupling</a> between members: you're expected to call <code>BuildMaze</code> before any of the other methods. A better design would be to remove that explicit step entirely, or else turn it into a factory that you have to call in order to be able to call the other methods. That's not the topic of the present article, so I'll leave the API like this. </p> <p> The book also shows a simple usage example of the abstract <code>MazeBuilder</code> class: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">MazeGame</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Maze</span>&nbsp;CreateMaze(<span style="color:#2b91af;">MazeBuilder</span>&nbsp;builder) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;builder.BuildMaze(); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;builder.BuildRoom(1); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;builder.BuildRoom(2); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;builder.BuildDoor(1,&nbsp;2); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;builder.GetMaze(); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> You use it with e.g. a <code>StandardMazeBuilder</code> like this: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;game&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">MazeGame</span>(); <span style="color:blue;">var</span>&nbsp;builder&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">StandardMazeBuilder</span>(); <span style="color:blue;">var</span>&nbsp;maze&nbsp;=&nbsp;game.CreateMaze(builder);</pre> </p> <p> You could also, again following the book's example as closely as possible, use it with a <code>CountingMazeBuilder</code>, like this: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;game&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">MazeGame</span>(); <span style="color:blue;">var</span>&nbsp;builder&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">CountingMazeBuilder</span>(); game.CreateMaze(builder); <span style="color:blue;">var</span>&nbsp;msg&nbsp;=&nbsp;<span style="color:#a31515;">$&quot;The&nbsp;maze&nbsp;has&nbsp;</span>{builder.RoomCount}<span style="color:#a31515;">&nbsp;rooms&nbsp;and&nbsp;</span>{builder.DoorCount}<span style="color:#a31515;">&nbsp;doors.&quot;</span>;</pre> </p> <p> This would produce <code>"The maze has 2 rooms and 1 doors."</code>. </p> <p> Both <code>StandardMazeBuilder</code> and <code>CountingMazeBuilder</code> are concrete classes that derive from the abstract <code>MazeBuilder</code> class. </p> <p> <strong>Maze Builder refactored to interfaces</strong> </p> <p> If you follow the refactoring outline in this article, you can refactor the above <code>MazeBuilder</code> class to a set of interfaces. The first should be an interface extracted from all the pure virtual members of the class. In this example, there's only one such member, so the interface becomes this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IMazeBuilder</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Maze</span>&nbsp;GetMaze(); }</pre> </p> <p> The three virtual members each get their own interface, so that you can pick and choose which of them you want to override, and which of them you prefer to keep with their default implementation (which, in this particular case, is to do nothing). </p> <p> The first one was difficult to name: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IMazeInitializer</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">void</span>&nbsp;BuildMaze(); }</pre> </p> <p> An interface with a single method called <code>BuildMaze</code> would naturally have a name like <code>IMazeBuilder</code>, but unfortunately, I just used that name for the previous interface. The reason I named the above interface <code>IMazeBuilder</code> is because this is an interface extracted from the <code>MazeBuilder</code> abstract class, and I consider the pure virtual API to be the core API of the abstraction, so I think it makes most sense to keep the name for that interface. Thus, I had to come up with a <a href="">smelly</a> name like <code>IMazeInitializer</code>. </p> <p> Fortunately, the two remaining interfaces are a little better: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IRoomBuilder</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">void</span>&nbsp;BuildRoom(<span style="color:blue;">int</span>&nbsp;room); } <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IDoorBuilder</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">void</span>&nbsp;BuildDoor(<span style="color:blue;">int</span>&nbsp;roomFrom,&nbsp;<span style="color:blue;">int</span>&nbsp;roomTo); }</pre> </p> <p> The three virtual members all had default implementations, so you need to keep those around. You can do that by moving the methods' code to a new class that implements the new interfaces: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">DefaultMazeBuilder</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IMazeInitializer</span>,&nbsp;<span style="color:#2b91af;">IRoomBuilder</span>,&nbsp;<span style="color:#2b91af;">IDoorBuilder</span> </pre> </p> <p> In this example, there's no reason to show the implementation of the class, because, as you may recall, all three methods are no-ops. </p> <p> Instead of inheriting from <code>MazeBuilder</code>, implementers now implement the appropriate interfaces: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">StandardMazeBuilder</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IMazeBuilder</span>,&nbsp;<span style="color:#2b91af;">IMazeInitializer</span>,&nbsp;<span style="color:#2b91af;">IRoomBuilder</span>,&nbsp;<span style="color:#2b91af;">IDoorBuilder</span> </pre> </p> <p> This version of <code>StandardMazeBuilder</code> implements all four interfaces, since, before, it overrode all four methods. <code>CountingMazeBuilder</code>, on the other hand, never overrode <code>BuildMaze</code>, so it doesn't have to implement <code>IMazeInitializer</code>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">CountingMazeBuilder</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IRoomBuilder</span>,&nbsp;<span style="color:#2b91af;">IDoorBuilder</span>,&nbsp;<span style="color:#2b91af;">IMazeBuilder</span> </pre> </p> <p> All of these changes leaves the original <code>MazeBuilder</code> class defined like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">MazeBuilder</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IMazeBuilder</span>,&nbsp;<span style="color:#2b91af;">IMazeInitializer</span>,&nbsp;<span style="color:#2b91af;">IRoomBuilder</span>,&nbsp;<span style="color:#2b91af;">IDoorBuilder</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IMazeBuilder</span>&nbsp;mazeBuilder; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IMazeInitializer</span>&nbsp;mazeInitializer; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IRoomBuilder</span>&nbsp;roomBuilder; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IDoorBuilder</span>&nbsp;doorBuilder; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;MazeBuilder( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IMazeBuilder</span>&nbsp;mazeBuilder, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IMazeInitializer</span>&nbsp;mazeInitializer, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IRoomBuilder</span>&nbsp;roomBuilder, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IDoorBuilder</span>&nbsp;doorBuilder) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.mazeBuilder&nbsp;=&nbsp;mazeBuilder; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.mazeInitializer&nbsp;=&nbsp;mazeInitializer; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.roomBuilder&nbsp;=&nbsp;roomBuilder; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.doorBuilder&nbsp;=&nbsp;doorBuilder; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;BuildMaze() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.mazeInitializer.BuildMaze(); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;BuildRoom(<span style="color:blue;">int</span>&nbsp;room) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.roomBuilder.BuildRoom(room); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;BuildDoor(<span style="color:blue;">int</span>&nbsp;roomFrom,&nbsp;<span style="color:blue;">int</span>&nbsp;roomTo) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.doorBuilder.BuildDoor(roomFrom,&nbsp;roomTo); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Maze</span>&nbsp;GetMaze() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">this</span>.mazeBuilder.GetMaze(); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> At this point, you may decide to keep the old <code>MazeBuilder</code> class around, because you may have other code that relies on it. Notice, however, that it's now a concrete class that has dependencies injected into it via its constructor. All four members only delegate to the relevant dependencies in order to do actual work. </p> <p> <code>MazeGame</code> looks like before, but calling <code>CreateMaze</code> looks more complicated: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;game&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">MazeGame</span>(); <span style="color:blue;">var</span>&nbsp;builder&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">StandardMazeBuilder</span>(); <span style="color:blue;">var</span>&nbsp;maze&nbsp;=&nbsp;game.CreateMaze(<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">MazeBuilder</span>(builder,&nbsp;builder,&nbsp;builder,&nbsp;builder));</pre> </p> <p> Notice that while you're passing four dependencies to the <code>MazeBuilder</code> constructor, you can reuse the same <code>StandardMazeBuilder</code> object for all four roles. </p> <p> If you want to count the rooms and doors, however, <code>CountingMazeBuilder</code> doesn't implement <code>IMazeInitializer</code>, so for that role, you'll need to use the default implementation: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;game&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">MazeGame</span>(); <span style="color:blue;">var</span>&nbsp;builder&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">CountingMazeBuilder</span>(); game.CreateMaze(<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">MazeBuilder</span>(builder,&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">DefaultMazeBuilder</span>(),&nbsp;builder,&nbsp;builder)); <span style="color:blue;">var</span>&nbsp;msg&nbsp;=&nbsp;<span style="color:#a31515;">$&quot;The&nbsp;maze&nbsp;has&nbsp;</span>{builder.RoomCount}<span style="color:#a31515;">&nbsp;rooms&nbsp;and&nbsp;</span>{builder.DoorCount}<span style="color:#a31515;">&nbsp;doors.&quot;</span>;</pre> </p> <p> If, at this point, you're beginning to wonder what value <code>MazeBuilder</code> adds, then I think that's a legitimate concern. What often happens, then, is that you simply remove that extra layer. </p> <p> <strong>Mazes without MazeBuilder</strong> </p> <p> When you delete the <code>MazeBuilder</code> class, you'll have to adjust <code>MazeGame</code> accordingly: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">MazeGame</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Maze</span>&nbsp;CreateMaze( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IMazeInitializer</span>&nbsp;initializer,&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IRoomBuilder</span>&nbsp;roomBuilder,&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IDoorBuilder</span>&nbsp;doorBuilder, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IMazeBuilder</span>&nbsp;mazeBuilder) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;initializer.BuildMaze(); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;roomBuilder.BuildRoom(1); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;roomBuilder.BuildRoom(2); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;doorBuilder.BuildDoor(1,&nbsp;2); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;mazeBuilder.GetMaze(); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> The <code>CreateMaze</code> method now simply takes the four interfaces on which it relies as individual arguments. This simplifies the client code as well: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;game&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">MazeGame</span>(); <span style="color:blue;">var</span>&nbsp;builder&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">StandardMazeBuilder</span>(); <span style="color:blue;">var</span>&nbsp;maze&nbsp;=&nbsp;game.CreateMaze(builder,&nbsp;builder,&nbsp;builder,&nbsp;builder);</pre> </p> <p> You can still reuse a single <code>StandardMazeBuilder</code> in all roles, but again, if you only want to count the rooms and doors, you'll have to rely on <code>DefaultMazeBuilder</code> for the behaviour that <code>CountingMazeBuilder</code> doesn't define: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;game&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">MazeGame</span>(); <span style="color:blue;">var</span>&nbsp;builder&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">CountingMazeBuilder</span>(); game.CreateMaze(<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">DefaultMazeBuilder</span>(),&nbsp;builder,&nbsp;builder,&nbsp;builder); <span style="color:blue;">var</span>&nbsp;msg&nbsp;=&nbsp;<span style="color:#a31515;">$&quot;The&nbsp;maze&nbsp;has&nbsp;</span>{builder.RoomCount}<span style="color:#a31515;">&nbsp;rooms&nbsp;and&nbsp;</span>{builder.DoorCount}<span style="color:#a31515;">&nbsp;doors.&quot;</span>;</pre> </p> <p> The order in which dependencies are passed to <code>CreateMaze</code> is different than the order they were passed to the now-deleted <code>MazeBuilder</code> constructor, so you'll have to pass a <code>new DefaultMazeBuilder()</code> as the first argument in order to fill the role of <code>IMazeInitializer</code>. Another way to address this issue is to supply various overloads of the <code>CreateMaze</code> method that uses <code>DefaultMazeBuilder</code> for the behaviour that you don't want to override. </p> <p> <strong>Summary</strong> </p> <p> Many of the original design patterns in <em>Design Patterns</em> are described with examples in C++, and many of these examples use abstract classes as the programming interfaces that the Gang of Four really had in mind when they wrote that we should be programming to interfaces instead of implementations. </p> <p> The most important result of this article is that you can reinterpret the original design patterns with C# or Java interfaces and Dependency Injection, instead of using abstract classes. I've done this in C# for more than ten years, and in my experience, you never need abstract classes in a greenfield code base. There's always an equivalent representation that involves composition of interfaces. </p> <p> <strong>Next:</strong> <a href="">Inheritance-composition isomorphism</a>. </p> </div> <div id="comments"> <hr /> <h2 id="comments-header">Comments</h2> <div class="comment" id="b8cb5baf6ccd4cc98412c229d3dadb06"> <div class="comment-author"> <a href="">Max Kiselev</a> </div> <div class="comment-content"> <p> While the idea is vey interesting I think it is not exactly an isomorphism. </p> <p> The first reason I think it is not an isomorphism is language-specific since Java and C# allow implementing multiple interfaces but not multiple abstract classes. It can make a reverse transformation from interfaces back to an abstract class non-trivial. </p> <p> The second reason is that abstract class guarantees that whatever class implements the pure virtual members and overrides virtual members share the same state between all its methods and also with the abstract base class. With the maze Builder example there must be a state shared between GetMaze, BuildMaze, BuildRoom and BuildDoor methods but the dependency injection does not seem to reflect it. </p> <p> Perhaps there should be some kind of Data parameter passed to all injected interfaces. </p> </div> <div class="comment-date">2018-03-05 19:03 UTC</div> </div> <div class="comment" id="13cc2c9a28114b52add8942d3ac3c94d"> <div class="comment-author"><a href="">Mark Seemann</a></div> <div class="comment-content"> <p> Max, thank you for writing, and particularly for applying critique to this post. One of my main motivations for writing <a href="">the entire article series</a> is that I need to subject my thoughts to peer review. I've been thinking about these things for years, but in order to formalise them, I need to understand whether I'm completely wrong (I hope not), of, if I'm not, what are the limits of my findings. </p> <p> I think you've just pointed at one such limit, and for that I'm grateful. The rest of this answer, then, is not an attempt to refute your comment, but rather an effort to identify some <em>constraints</em> within which what I wrote may still hold. </p> <p> Your second objection doesn't worry me that much, because you also suggest a way around it. I admit that I faked the Maze Builder code somewhat, so that the state isn't explicit. I feel that fudging the code example is acceptable, as the Gang of Four code example is also clearly incomplete. In any case, you're right that an abstract class could easily contain some shared state. When refactoring to interfaces, the orchestrating class could instead pass around that state as an argument to all methods, as you suggest. Would it be reasonable to conclude that this, then, doesn't prevent the translations from being isomorphic? </p> <p> There's still your first objection, which I think is significant. That's the reason I decided to cover your second objection first, because I think it'll require more work to address the first objection. </p> <p> First, I think we need to delimit the problem, since your comment slightly misrepresents my article. The claim in the article is that you can refactor an abstract class to a concrete class with injected dependencies. Furthermore, the article claims that this translation is isomorphic; i.e. that you can refactor a concrete class with injected dependencies to an abstract class. </p> <p> If I read your comment right, you're saying that a class can implement more than one interface, like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">MyClass</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IFoo</span>,&nbsp;<span style="color:#2b91af;">IBar</span><br/></pre> </p> <p> I agree that you can't use the transformations described in this article to refactor <code>MyClass</code> to an abstract class, because that's not the transformation that the article describes. </p> <p> That doesn't change that your comment is uncomfortably close to an inconvenient limitation. You're right that there seems to be a limitation when it comes to C#'s and Java's lack of multiple inheritance. As your comment implies, if a translation is isomorphic, one has to be able to start at either end, and round-trip to the other end and back. Thus, one has to be able to start with a concrete class with injected dependencies, and refactor to an abstract class; for example: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">MyClass</span><br/>{<br/>&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;MyClass(<span style="color:#2b91af;">IFoo</span>&nbsp;foo,&nbsp;<span style="color:#2b91af;">IBar</span>&nbsp;bar)<br/>&nbsp;&nbsp;&nbsp;&nbsp;{<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;...</span><br/>&nbsp;&nbsp;&nbsp;&nbsp;}<br/>}</pre> </p> <p> As far as I can tell, that's exactly the shape of the <code>sealed</code> version of <code>Class1</code>, above, so I'm not convinced that that's a problem, but something like the following does look like a problem to me: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">MyClass</span><br/>{<br/>&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;MyClass(<span style="color:#2b91af;">IFoo</span>&nbsp;foo1,&nbsp;<span style="color:#2b91af;">IFoo</span>&nbsp;foo2)<br/>&nbsp;&nbsp;&nbsp;&nbsp;{<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;...</span><br/>&nbsp;&nbsp;&nbsp;&nbsp;}<br/>}</pre> </p> <p> It's not clear to me how one can refactor something like that to an abstract class, and still retain the distinction between <code>foo1</code> and <code>foo2</code>. My claim is not that this is impossible, but only that it's not immediately clear to me how to do that. Thus, we may have to put a constraint on the original claim, and instead say something like this: <blockquote> An abstract class is isomorphic to a concrete class with injected dependencies, given that all the injected dependencies are of different types. </blockquote> We can attempt to illustrate the claim like this: </p> <p> <img src="/content/binary/abstract-class-to-constrained-dependency-injection-isomorphism.png" alt="The set of abstract classes juxtaposed with the set of dependency injection, the latter with a subset for which arrows go both ways between the subset and the set of abstract classes."> </p> <p> This is still an isomorphism, I think, although I invite further criticism of that claim. <a href="">Conceptual Mathematics</a> defines an isomorphism in terms of categories <em>A</em> and <em>B</em>, and as far as I can tell, <em>A</em> and <em>B</em> can be as specific as we want them to be. Thus, we can say that <em>A</em> is the set of abstract classes, and <em>B</em> is the subset of concrete classes with injected dependencies, for which no dependency share the same type. </p> <p> If we have to constrain the isomorphism in this way, though, is it still interesting? Why should we care? </p> <p> To be perfectly honest, what motivated me to write this particular article is that I wanted to describe the translation from an abstract class to dependency injection. The inverse interests me less, but I thought that if the inverse translation exists, I could fit this article in with the other articles in this article series about software design isomorphisms. </p> <p> The reason I care about the translation from abstract class to dependency injection is that I often see code where the programmers misuse inheritance. My experience with C# is that one can completely avoid inheritance. The way to do that is to use dependency injection instead. This article shows how to do that. </p> <p> The result that one can write real, complex code bases in C# without inheritance is important to me, because one of my current goals is to teach people the advantages of functional programming, and one barrier I run into is that people who come from object-oriented programming run into problems when they no longer can use inheritance. Thus, this article shows an object-oriented alternative to inheritance, so that people can get used to the idea of designing without inheritance, even before they start looking at functional programming. </p> <p> Another motivation for this article is that it's part of <a href="">a much larger article series</a> about design patterns, and how they relate to fundamental abstractions. In <em>Design Patterns</em>, all the (C++) patterns are described in terms of inheritance, so I wrote this article series on isomorphisms in order to be able to represent various design patterns in other forms than they appear in the book. </p> </div> <div class="comment-date">2018-03-08 9:57 UTC</div> </div> <div class="comment" id="93410202470d4406a698fa4ffb6d3c27"> <div class="comment-author"> Ciprian Vilcan </div> <div class="comment-content"> <p> This idea is a very interesting and useful one, but as I found out in one of my toy projects and as Max stated above, it is unfortunately not language agnostic.<br /> As far as C# is concerned, you can have operator overloading in an abstract class, which is a bit of logic that I see no way of extracting to an interface and thus remove the need for inheritance. Example below.<br /> (You could define Add, Subtract, Multiply and Divide methods, but to me they seem like reinventing the square wheel. They seem much less convenient than +-*/) </p> <p> I tried creating some nice Temperature value objects, similar to <a href="">the money monoid you presented</a> and I came up with 5 classes:<br /> Temperature, Kelvin, Celsius, Fahrenheit and TemperatureExpression.<br /> Temperature is the abstract class and its +Temperature and -Temperature operators are overloaded so that they return a TemperatureExpression, which can then be evaluated to a Maybe&lt;TTemperature&gt; where TTemperature : Temperature. <br /> A TemperatureExpression is nothing more than a lazily evaluated mathematical expression (for example: 12K + 24C - 32F).<br /> Also, it's a Maybe because 0K - 1C won't be a valid temperature, so we have to also take this case into consideration. <br /> </p> <p> For further convenience, the Kelvin class has its own overloaded + operator, because no matter what you do, when adding together two Kelvin values you'll always end up with something that is greater than 0. </p> <p> These being said, if you want to leverage the C# operators there are some limitations regarding this transformation that keep you from having this abstract class -> DI isomorphism. <br /> That is, unless you're willing to add the methods I've spoken of in the first paragraph. <br /> But, in an ideal programming language, IMHO, arithmetic and boolean operators should be part of some public interfaces like, ISubtractable, IDivideable and thus allow for a smooth transition between abstract classes and interface DI. </p> </div> <div class="comment-date">2018-03-08 10:16 UTC</div> </div> <div class="comment" id="7aac063a684047ae9561c6666a42f908"> <div class="comment-author"><a href="">Mark Seemann</a></div> <div class="comment-content"> <p> Ciprian, thank you for writing. I agree that this isn't language agnostic. It's possible that we need to add further constraints to the conjecture, but I still anticipate that, with appropriate constraints, it holds for statically typed 'mainstream' object-oriented languages (i.e. C# and Java). It may also hold for other languages, but it requires detailed knowledge of a language to claim that it does. For instance, it's been too long since I wrote C++ code, and I can't remember how its object-oriented language features work. Likewise, it'd be interesting to investigate if the conjecture holds when applied to JavaScript, Ruby, Python, etc., but I've been careful not to claim that, as I know too little about those languages. </p> <p> Regarding your temperature example, I <em>think</em> that perhaps I understand what the issue is, but I'm not sure I've guessed right. In the interest of being able to have an unambiguous discussion about a code example, could you please post the pertinent code that illustrates your point? </p> </div> <div class="comment-date">2018-03-09 8:07 UTC</div> </div> <div class="comment" id="52d98574756f471482303e34dc02df33"> <div class="comment-author">Ciprian Vilcan</div> <div class="comment-content"> <p> I've added the code to <a href="">github</a>. I think it's better than copy-pasting here as you can gain some extra context. </p> <p> It's a playground project where I put to practice various ideas I find on the web (so if you see something you consider should be done otherwise, I don't mind you saying it). I've added a few comments to make it a bit easier to understand and also removed anything that doesn't pertain to the issue with abstract class -> DI.<br /> </p> <p> In short, the bit of logic that I can't see a way of extracting to some sort of injectable dependency are the +- operators on the Temperature class due to the fact that they are static methods, thus cannot be part of an interface (at least in C#, I don't know about programming languages). </p> </div> <div class="comment-date">2018-03-09 11:14 UTC</div> </div> <div class="comment" id="b9a9d7e657804832b4adcc6e71aa0d7f"> <div class="comment-author"><a href="">Mark Seemann</a></div> <div class="comment-content"> <p> Ciprian, thank you for elaborating. I'd forgotten about C#'s ability to overload arithmetic operators, which is, I believe, what you're referring to. To be clear, I do believe that it's a fair enough critique, so that we'll have to once again restrict this article's conjecture to something like: <blockquote> There exists a subset <em>A</em> of all abstract classes, and a subset of all concrete classes with injected dependencies <em>I</em>, such that an isomorphism <em>A &lt;-&gt; I</em> exists. </blockquote> In diagram form, it would look like this: </p> <p> <img src="/content/binary/subset-of-abstract-classes-to-subset-of-dependency-injection-isomorphism.png" alt=""> </p> <p> By its shape, the diagram suggests that the size of abstract classes <em>not</em> isomorphic with Dependency Injection is substantial, but that's not really my intent; I just had to leave room for the text. </p> <p> My experience suggests to me that most abstract classes can be refactored as I've described in this article, but clearly, as you've shown, there are exceptions. C#'s support for operator overloading is one such exception, but there may be others of which I'm currently ignorant. </p> <p> That said, I would like to make the case that arithmetic operators aren't object-oriented in the first place. Had the language been purely object-oriented from the outset, addition would more appropriately have had a syntax like <code>40.Add(2)</code>. This would imply that the language would have been based on the concept of objects as data with behaviour, and the behaviour would exclusively have been defined by class members. </p> <p> Even at the beginning, though, C# was a hybrid language. It had (and still has) a subset of language features focused on more low-level programming. It has value types in addition to reference types, it has arithmetic operators, it has special support for bitwise Boolean operators, and it even has pointers. </p> <p> There are practical reasons that all of those features exist, but I would claim that none of those features have anything to do with object-orientation. </p> <p> Specifically when it comes to arithmetic operators, the operators are all special cases baked into the language. The selection of operators is sensible, but when you get to the bottom of it, arbitrary. For instance, there's a modulo operator, but no power operator. Why? </p> <p> As an aside, languages do exist where arithmetic is an abstraction instead of a language feature. The one I'm most familiar with is <a href="">Haskell</a>, where arithmetic is defined in terms of type classes. It's worth noting that the operators <code>+</code>, <code>*</code>, and <code>-</code> are defined in an abstraction called <a href="">Num</a>, whereas the 'fourth' arithmetic operator <code>/</code> is defined in a more specialised abstraction called <a href="">Fractional</a>. </p> <p> Not that Haskell's model of arithmetic is perfect, but there's a rationale behind this distinction. Division is special, because it can translate two integers (e.g. <code>2</code> and <code>3</code>) into a rational number (e.g. <code>2/3</code>), while both addition and multiplication are <a href="">monoids</a>. This is where Haskell starts to fall apart itself, though, because subtraction can also translate two numbers out of the set in which they originally belonged. For example, given two <em>natural</em> numbers <code>2</code> and <code>3</code>, <code>2 - 3</code> is no longer a natural number, since it's negative. </p> <p> But all of that is an aside. Even in C#, one has to deal with low-level exceptional cases such as integer overflow, so even addition isn't truly monoidal, unless you use <a href="">BigInteger</a>. </p> </div> <div class="comment-date">2018-03-11 9:35 UTC</div> </div> <div class="comment" id="5b00a6edefbf4a82925083eeac5d7768"> <div class="comment-author"><a href="">Max Kiselev</a></div> <div class="comment-content"> <p> Mark, thank you for the detailed response. I didn't mean to refute the usefulness of the refactoring you described. I now see how I tried to apply the refactoring of DI to abstact class where it was not claimed to be possible. </p> <p> I've been thinking about the example with the injection of distinct instances of the same type. I think we can use simple wrapper types for this kind of problem: </p> <p> <pre style="font-family:Consolas;font-size:13;color:black;background:white;"><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">sealed</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Foo1</span>&nbsp;:&nbsp;IFoo { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;IFoo&nbsp;impl_; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;Foo1&nbsp;(IFoo&nbsp;impl) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;impl_&nbsp;=&nbsp;impl; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;Out1&nbsp;Op1&nbsp;(In1&nbsp;in1) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;impl_.Op1&nbsp;(in1); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> Foo1 implements IFoo to keep the ability to e.g. create a list of foo1 and foo2. </p> <p> Given such wrappers are created for all dependencies of type IFoo, MyClass can be rewritten like this: </p> <p> <pre style="font-family:Consolas;font-size:13;color:black;background:white;"><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">MyClass</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;MyClass&nbsp;(Foo1&nbsp;foo1,&nbsp;Foo2&nbsp;foo2) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;...</span> &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> Now MyClass can be refactored into an abstract class without losing the distinction between foo1 and foo2. </p> <p> I also belive that, given the wrappers are used only in the context of MyClass, the use of wrappers and diffent fields or parameters is an isomorphism. While its usefulness as a stand-alone refactoing is limited, it may come handy for reasoning similar to the one you did in <a href="/2018/03/12/composite-as-a-monoid/">Composite as a monoid</a>. </p> <p> Thin wrappers can be used to create an <em>almost</em> convenient way to define operators on interfaces. Unfortunately C# does not allow user-defined conversions to or from an interface so one have to explicitly wrap all instances of the interface in an expression that do not have wrapper on one side of an expression. While it can be acceptable in some cases (like <span>Wrap(a) + b + c + d ...</span>), it can make more complex expressions very cumbersome (like <span>(Wrap(a) + b) + (Wrap(c) + d) ...</span> hence it does not solve the problem that Ciprian described. </p> </div> <div class="comment-date">2018-03-22 21:33 UTC</div> </div> </div> <hr> This blog is totally free, but if you like it, please <a href="">buy me a cup of coffee</a>. Mark Seemann Object isomorphisms Mon, 12 Feb 2018 19:34:00 UTC <div id="post"> <p> <em>An object is equivalent to a product of functions. Alternative ways to look at objects.</em> </p> <p> This article is part of <a href="">a series of articles about software design isomorphisms</a>. So far, you've seen how to represent a single method or function in many different ways, but we haven't looked much at <em>objects</em> (in the object-oriented interpretation of the word). </p> <p> While this article starts by outlining the abstract concepts involved, an example is included towards the end. </p> <p> <strong>Objects as data with behaviour</strong> </p> <p> I often use the phrase that <em>objects are data with behaviour</em>. (I'm sure I didn't come up with this myself, but the source of the phrase escapes me.) In languages like C# and Java, objects are described by classes, and these often contain <em>class fields</em>. These fields constitute an instance's data, whereas its methods implement its behaviour. </p> <p> A class can contain an arbitrary number of fields, just like a method can take an arbitrary number of arguments. As demonstrated by the <a href="">argument list isomorphisms</a>, you can also represent an arbitrary number of arguments as a Parameter Object. The same argument can be applied to class fields. Instead of <em>n</em> fields, you can add a single 'data class' that holds all of these fields. In <a href="">F#</a> and <a href="">Haskell</a> these are called <em>records</em>. You could also dissolve such a record to individual fields. That would be the inverse refactoring, so these representations are isomorphic. </p> <p> In other words, a class looks like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Class1</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Data1</span>&nbsp;Data&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">set</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Out1</span>&nbsp;Op1(<span style="color:#2b91af;">In1</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;Out1&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Out2</span>&nbsp;Op2(<span style="color:#2b91af;">In2</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;Out1&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Out3</span>&nbsp;Op3(<span style="color:#2b91af;">In3</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;Out1&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;More&nbsp;members...</span> }</pre> </p> <p> Instead of an arbitrary number of fields, I've used the above isomorphism to represent data in a single <code>Data</code> property (Java developers: a C# property is a class field with public getter and setter methods). </p> <p> In this code example, I've deliberately kept the naming abstract. The purpose of this article series is to look at the shape of code, instead of what it does, or why. From argument list isomorphisms we know that we can represent any method as taking a single input value, and returning a single output value. The remaining work to be done in this article is to figure out what to do when there's more than a single method. </p> <p> <strong>Module</strong> </p> <p> From <a href="">function isomorphisms</a> we know that static methods are isomorphic to instance methods, as long as you include the original object as an extra argument. In this case, all data in <code>Class1</code> is contained in a single (mutable) <code>Data1</code> record, so we can eliminate <code>Class1</code> from the argument list in favour of <code>Data1</code>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Class1</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Out1</span>&nbsp;Op1(<span style="color:#2b91af;">Data1</span>&nbsp;data,&nbsp;<span style="color:#2b91af;">In1</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;data&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;Out1&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Out2</span>&nbsp;Op2(<span style="color:#2b91af;">Data1</span>&nbsp;data,&nbsp;<span style="color:#2b91af;">In2</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;data&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;Out1&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Out3</span>&nbsp;Op3(<span style="color:#2b91af;">Data1</span>&nbsp;data,&nbsp;<span style="color:#2b91af;">In3</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;data&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;Out1&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;More&nbsp;members...</span> }</pre> </p> <p> Notice that <code>Class1</code> is now a <code>static</code> class. This simply means that it has no instance members, and if you try to add one, the C# compiler will complain. </p> <p> This is, in essence, a <em>module</em>. In F#, for example, a <code>module</code> is a static class that contains a collection of values and functions. </p> <p> <strong>Closures as behaviour with data</strong> </p> <p> As <em>data with behaviour</em>, objects are often passed around as input to methods. It's a convenient way to pass both data and associated behaviour (perhaps even with polymorphic dispatch) as a single thing. You'd be forgiven if you've looked at the above module-style refactoring and found it lacking in that regard. </p> <p> Nevertheless, function isomorphisms already demonstrated that you can solve this problem with closures. Imagine that you want to package all the static methods of <code>Class1</code> with a particular <code>Data1</code> value, and pass that 'package' as a single argument to another method. You can do that by closing over the value: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;data&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Data1</span>&nbsp;{&nbsp;<span style="color:green;">/*&nbsp;initialize&nbsp;members&nbsp;here&nbsp;*/</span>&nbsp;}; <span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">In1</span>,&nbsp;<span style="color:#2b91af;">Out1</span>&gt;&nbsp;op1&nbsp;=&nbsp;arg&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">Class1</span>.Op1(data,&nbsp;arg); <span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">In2</span>,&nbsp;<span style="color:#2b91af;">Out2</span>&gt;&nbsp;op2&nbsp;=&nbsp;arg&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">Class1</span>.Op2(data,&nbsp;arg); <span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">In3</span>,&nbsp;<span style="color:#2b91af;">Out3</span>&gt;&nbsp;op3&nbsp;=&nbsp;arg&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">Class1</span>.Op3(data,&nbsp;arg); <span style="color:green;">//&nbsp;More&nbsp;closures...</span></pre> </p> <p> First, you create a <code>Data1</code> value, and initialise it with your desired values. You then create <code>op1</code>, <code>op2</code>, and so on. These are functions that close over <code>data</code>; A.K.A. <em>closures</em>. Notice that they all close over the same variable. Also keep in mind here that I'm in no way pretending that <code>data</code> is immutable. That's not a requirement. </p> <p> Now you have <em>n</em> closures that all close over the same <code>data</code>. All you need to do is to package them into a single 'object': </p> <p> <pre><span style="color:blue;">var</span>&nbsp;objEq&nbsp;=&nbsp;<span style="color:#2b91af;">Tuple</span>.Create(op1,&nbsp;op2,&nbsp;op3&nbsp;<span style="color:green;">/*&nbsp;more&nbsp;closures...&nbsp;*/</span>); </pre> </p> <p> Once again, tuples are workhorses of software design isomorphisms. <code>objEq</code> is an 'object equivalent' consisting of closures; it's <em>behaviour with data</em>. You can now pass <code>objEq</code> as an argument to another method, if that's what you need to do. </p> <p> <strong>Isomorphism</strong> </p> <p> One common variation that I sometimes see is that instead of a tuple of functions, you can create a <em>record</em> of functions. This enables you to give each function a statically enforced name. In the theory of <a href="">algebraic data types</a>, tuples and records are both <em>product types</em>, so when looking at the shape of code, these are closely related. Records also enable you to preserve the name of each method, so that this mapping from object to record of functions becomes lossless. </p> <p> The inverse mapping also exists. If you have a record of functions, you can refactor it to a class. You use the name of each record element as a method name, and the arguments and return types to further flesh out the methods. </p> <p> <strong>Example: simplified Turtle</strong> </p> <p> As an example, consider this (over-)simplified <a href="">Turtle</a> class: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Turtle</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">double</span>&nbsp;X&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">set</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">double</span>&nbsp;Y&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">set</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">double</span>&nbsp;AngleInDegrees&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">set</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;Turtle() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;Turtle(<span style="color:blue;">double</span>&nbsp;x,&nbsp;<span style="color:blue;">double</span>&nbsp;y,&nbsp;<span style="color:blue;">double</span>&nbsp;angleInDegrees) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.X&nbsp;=&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Y&nbsp;=&nbsp;y; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.AngleInDegrees&nbsp;=&nbsp;angleInDegrees; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;Turn(<span style="color:blue;">double</span>&nbsp;angleInDegrees) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.AngleInDegrees&nbsp;=&nbsp;(<span style="color:blue;">this</span>.AngleInDegrees&nbsp;+&nbsp;angleInDegrees)&nbsp;%&nbsp;360; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;Move(<span style="color:blue;">double</span>&nbsp;distance) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Convert&nbsp;degrees&nbsp;to&nbsp;radians&nbsp;with&nbsp;180.0&nbsp;degrees&nbsp;=&nbsp;1&nbsp;pi&nbsp;radian</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;angleInRadians&nbsp;=&nbsp;<span style="color:blue;">this</span>.AngleInDegrees&nbsp;*&nbsp;(<span style="color:#2b91af;">Math</span>.PI&nbsp;/&nbsp;180); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.X&nbsp;=&nbsp;<span style="color:blue;">this</span>.X&nbsp;+&nbsp;(distance&nbsp;*&nbsp;<span style="color:#2b91af;">Math</span>.Cos(angleInRadians)); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Y&nbsp;=&nbsp;<span style="color:blue;">this</span>.Y&nbsp;+&nbsp;(distance&nbsp;*&nbsp;<span style="color:#2b91af;">Math</span>.Sin(angleInRadians)); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> In order to keep the example simple, the only operations offered by the <code>Turtle</code> class is <code>Turn</code> and <code>Move</code>. With this simplified API, you can create a <code>turtle</code> object and interact with it: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;turtle&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Turtle</span>(); turtle.Move(2); turtle.Turn(90); turtle.Move(1);</pre> </p> <p> This sequence of operations will leave <code>turtle</code> as position <em>(2, 1)</em> and an angle of 90°. </p> <p> Instead of modelling a turtle as an object, you can instead model it as a data structure and a set of (impure) functions: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">TurtleData</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">double</span>&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">double</span>&nbsp;y; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">double</span>&nbsp;angleInDegrees; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;TurtleData() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;TurtleData(<span style="color:blue;">double</span>&nbsp;x,&nbsp;<span style="color:blue;">double</span>&nbsp;y,&nbsp;<span style="color:blue;">double</span>&nbsp;angleInDegrees) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.x&nbsp;=&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.y&nbsp;=&nbsp;y; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.angleInDegrees&nbsp;=&nbsp;angleInDegrees; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">void</span>&nbsp;Turn(<span style="color:#2b91af;">TurtleData</span>&nbsp;data,&nbsp;<span style="color:blue;">double</span>&nbsp;angleInDegrees) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;data.angleInDegrees&nbsp;=&nbsp;(data.angleInDegrees&nbsp;+&nbsp;angleInDegrees)&nbsp;%&nbsp;360; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">void</span>&nbsp;Move(<span style="color:#2b91af;">TurtleData</span>&nbsp;data,&nbsp;<span style="color:blue;">double</span>&nbsp;distance) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Convert&nbsp;degrees&nbsp;to&nbsp;radians&nbsp;with&nbsp;180.0&nbsp;degrees&nbsp;=&nbsp;1&nbsp;pi&nbsp;radian</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;angleInRadians&nbsp;=&nbsp;data.angleInDegrees&nbsp;*&nbsp;(<span style="color:#2b91af;">Math</span>.PI&nbsp;/&nbsp;180); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;data.x&nbsp;=&nbsp;data.x&nbsp;+&nbsp;(distance&nbsp;*&nbsp;<span style="color:#2b91af;">Math</span>.Cos(angleInRadians)); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;data.y&nbsp;=&nbsp;data.y&nbsp;+&nbsp;(distance&nbsp;*&nbsp;<span style="color:#2b91af;">Math</span>.Sin(angleInRadians)); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">double</span>&nbsp;GetX(<span style="color:#2b91af;">TurtleData</span>&nbsp;data) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;data.x; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">double</span>&nbsp;GetY(<span style="color:#2b91af;">TurtleData</span>&nbsp;data) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;data.y; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">double</span>&nbsp;GetAngleInDegrees(<span style="color:#2b91af;">TurtleData</span>&nbsp;data) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;data.angleInDegrees; &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> Notice that all five static methods take a <code>TurtleData</code> value as their first argument, just as the above abstract description suggests. The implementations are almost identical; you simply replace <code>this</code> with <code>data</code>. If you're a C# developer, you may be wondering about the accessor functions <code>GetX</code>, <code>GetY</code>, and <code>GetAngleInDegrees</code>. These are, however, the static equivalents to the <code>Turtle</code> class <code>X</code>, <code>Y</code>, and <code>AngleInDegrees</code> properties. Keep in mind that in C#, a property is nothing but syntactic sugar over one (or two) IL methods (e.g. <code>get_X()</code>). </p> <p> You can now create a pentuple (a five-tuple) of closures over those five static methods and a single <code>TurtleData</code> object. While you can always do that from scratch, it's illuminating to transform a <code>Turtle</code> into such a tuple, thereby illustrating how that morphism looks: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Tuple</span>&lt;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;&gt;&nbsp;ToTuple() { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;data&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">TurtleData</span>(<span style="color:blue;">this</span>.X,&nbsp;<span style="color:blue;">this</span>.Y,&nbsp;<span style="color:blue;">this</span>.AngleInDegrees); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;&nbsp;turn&nbsp;=&nbsp;angle&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">TurtleData</span>.Turn(data,&nbsp;angle); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;&nbsp;move&nbsp;=&nbsp;distance&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">TurtleData</span>.Move(data,&nbsp;distance); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;&nbsp;getX&nbsp;=&nbsp;()&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">TurtleData</span>.GetX(data); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;&nbsp;getY&nbsp;=&nbsp;()&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">TurtleData</span>.GetY(data); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;&nbsp;getAngle&nbsp;=&nbsp;()&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">TurtleData</span>.GetAngleInDegrees(data); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:#2b91af;">Tuple</span>.Create(turn,&nbsp;move,&nbsp;getX,&nbsp;getY,&nbsp;getAngle); }</pre> </p> <p> This <code>ToTuple</code> method is an instance method on <code>Turtle</code> (I just held it back from the above code listing, in order to list it here instead). It creates a new <code>TurtleData</code> object from its current state, and proceeds to close over it five times - each time delegating the closure implementation to the corresponding static method. Finally, it creates a pentuple of those five closures. </p> <p> You can interact with the pentuple just like it was an object: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;turtle&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Turtle</span>().ToTuple(); turtle.Item2(2); turtle.Item1(90); turtle.Item2(1);</pre> </p> <p> The syntax is essentially the same as before, but clearly, this isn't as readable. You have to remember that <code>Item2</code> contains the <code>move</code> closure, <code>Item1</code> the <code>turn</code> closure, and so on. Still, since they are all delegates, you can call them as though they are methods. </p> <p> I'm not trying to convince you that this sort of design is better, or even equivalent, in terms of readability. Clearly, it isn't - at least in C#. The point is, however, that from a perspective of structure, these two models are equivalent. Everything you can do with an object, you can also do with a tuple of closures. </p> <p> So far, you've seen that you can translate a <code>Turtle</code> into a tuple of closures, but in order to be an isomorphism, the reverse translation should also be possible. </p> <p> One way to translate from <code>TurtleData</code> to <code>Turtle</code> is with this static method (i.e. function): </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Turtle</span>&nbsp;ToTurtle(<span style="color:#2b91af;">TurtleData</span>&nbsp;data) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Turtle</span>(data.x,&nbsp;data.y,&nbsp;data.angleInDegrees); }</pre> </p> <p> Another option for making the pentuple of closures look like an object is to extract an interface from the original <code>Turtle</code> class: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">ITurtle</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">void</span>&nbsp;Turn(<span style="color:blue;">double</span>&nbsp;angleInDegrees); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">void</span>&nbsp;Move(<span style="color:blue;">double</span>&nbsp;distance); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">double</span>&nbsp;X&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">double</span>&nbsp;Y&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">double</span>&nbsp;AngleInDegrees&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} }</pre> </p> <p> Not only can you let <code>Turtle</code> implement this interface (<code>public class Turtle : ITurtle</code>), but you can also define an <a href="">Adapter</a>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">TupleTurtle</span>&nbsp;:&nbsp;<span style="color:#2b91af;">ITurtle</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">Tuple</span>&lt;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;imp; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;TupleTurtle( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Tuple</span>&lt;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;&gt;&nbsp;imp) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.imp&nbsp;=&nbsp;imp; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;Turn(<span style="color:blue;">double</span>&nbsp;angleInDegrees) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.imp.Item1(angleInDegrees); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;Move(<span style="color:blue;">double</span>&nbsp;distance) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.imp.Item2(distance); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">double</span>&nbsp;X &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">get</span>&nbsp;{&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">this</span>.imp.Item3();&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">double</span>&nbsp;Y &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">get</span>&nbsp;{&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">this</span>.imp.Item4();&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">double</span>&nbsp;AngleInDegrees &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">get</span>&nbsp;{&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">this</span>.imp.Item5();&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> This class simply delegates all its behaviour to the implementing pentuple. It can be used like this with no loss of readability: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;turtle&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">TupleTurtle</span>(<span style="color:#2b91af;">TurtleData</span>.CreateDefault()); turtle.Move(2); turtle.Turn(90); turtle.Move(1);</pre> </p> <p> This example utilises this creation function: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Tuple</span>&lt;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp;CreateDefault() { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;data&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">TurtleData</span>(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;&nbsp;turn&nbsp;=&nbsp;angle&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">TurtleData</span>.Turn(data,&nbsp;angle); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;&nbsp;move&nbsp;=&nbsp;distance&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">TurtleData</span>.Move(data,&nbsp;distance); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;&nbsp;getX&nbsp;=&nbsp;()&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">TurtleData</span>.GetX(data); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;&nbsp;getY&nbsp;=&nbsp;()&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">TurtleData</span>.GetY(data); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;&nbsp;getAngle&nbsp;=&nbsp;()&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">TurtleData</span>.GetAngleInDegrees(data); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:#2b91af;">Tuple</span>.Create(turn,&nbsp;move,&nbsp;getX,&nbsp;getY,&nbsp;getAngle); }</pre> </p> <p> This function is almost identical to the above <code>ToTuple</code> method, and those two could easily be refactored to a single method. </p> <p> This example demonstrates how an object can also be viewed as a tuple of closures, and that translations exist both ways between those two views. </p> <p> <strong>Conclusion</strong> </p> <p> To be clear, I'm not trying to convince you that it'd be great if you wrote all of your C# or Java using tuples of closures; it most likely wouldn't be. The point is that a class is isomorphic to a tuple of functions. </p> <p> From <a href="">category theory</a>, and particular its application to Haskell, we know quite a bit about the properties of certain functions. Once we start to look at objects as tuples of functions, we may be able to say something about the properties of objects, because category theory also has something to say about the properties of tuples (for example that a tuple of <a href="">monoids</a> is <a href="">itself a monoid</a>). </p> <p> <strong>Next:</strong> <a href="">Abstract class isomorphism</a>. </p> </div><hr> This blog is totally free, but if you like it, please <a href="">buy me a cup of coffee</a>. Mark Seemann Uncurry isomorphisms Mon, 05 Feb 2018 07:54:00 UTC <div id="post"> <p> <em>Curried functions are isomorphic to tupled functions.</em> </p> <p> This article is part of <a href="">a series of articles about software design isomorphisms</a>. <strong>Nota bene:</strong> it's <em>not</em> about <a href="">Curry–Howard isomorphism</a>. In order to prevent too much confusion, I chose the title <em>Uncurry isomorphism</em> over <em>Curry isomorphism</em>. </p> <p> The <a href="">Haskell</a> base library includes two functions called <code>curry</code> and <code>uncurry</code>, and for anyone aware of them, it should be no surprise that they are each others' inverses. This is another important software design isomorphism, because in the previous article, you saw that <a href="">all methods can be represented in tupled form</a>. The current isomorphism then extends that result because tupled and curried forms are isomorphic. </p> <p> <strong>An F# introduction to curry and uncurry</strong> </p> <p> While Haskell programmers are likely to be familiar with <code>curry</code> and <code>uncurry</code>, developers more familiar with other languages may not know them well. In this section follows an introduction in <a href="">F#</a>. Haskellers can skip it if they like. </p> <p> In F#, you often have to interoperate with code written in C#, and as the previous article explained, all such methods look to F# like functions taking a single tuple as input. Sometimes, however, you'd wish they were curried. </p> <p> This little function can help with that: </p> <p> <pre><span style="color:green;">//&nbsp;(&#39;a&nbsp;*&nbsp;&#39;b&nbsp;-&gt;&nbsp;&#39;c)&nbsp;-&gt;&nbsp;&#39;a&nbsp;-&gt;&nbsp;&#39;b&nbsp;-&gt;&nbsp;&#39;c</span> <span style="color:blue;">let</span>&nbsp;<span style="color:navy;">curry</span>&nbsp;<span style="color:navy;">f</span>&nbsp;x&nbsp;y&nbsp;=&nbsp;<span style="color:navy;">f</span>&nbsp;(x,&nbsp;y)</pre> </p> <p> You'll probably have to look at it for a while, and perhaps play with it, before it clicks, but it does this: it takes a function (<code>f</code>) that takes a tuple (<code>'a * 'b</code>) as input, and returns a new function that does the same, but instead takes the arguments in curried form: <code>'a -&gt; 'b -&gt; 'c</code>. </p> <p> It can be useful in interoperability scenarios. Imagine, as a toy example, that you have to list the powers of two from 0 to 10. You can use <a href="">Math.Pow</a>, but since it was designed with C# in mind, its argument is a single tuple. <code>curry</code> to the rescue: </p> <p> <pre>&gt; (curry Math.Pow 2.) [0.0..10.0];; val it : float list = [1.0; 2.0; 4.0; 8.0; 16.0; 32.0; 64.0; 128.0; 256.0; 512.0; 1024.0]</pre> </p> <p> While <code>Math.Pow</code> has the type <code>float * float -&gt; float</code>, <code>curry Math.Pow</code> turns it into a function with the type <code>float -&gt; float -&gt; float</code>. Since that function is curried, it can be partially applied with the value <code>2.</code>, which returns a function of the type <code>float -&gt; float</code>. That's a function you can use with <code></code>. </p> <p> You'd hardly be surprised that you can also <code>uncurry</code> a function: </p> <p> <pre><span style="color:green;">//&nbsp;(&#39;a&nbsp;-&gt;&nbsp;&#39;b&nbsp;-&gt;&nbsp;&#39;c)&nbsp;-&gt;&nbsp;&#39;a&nbsp;*&nbsp;&#39;b&nbsp;-&gt;&nbsp;&#39;c</span> <span style="color:blue;">let</span>&nbsp;<span style="color:navy;">uncurry</span>&nbsp;<span style="color:navy;">f</span>&nbsp;(x,&nbsp;y)&nbsp;=&nbsp;<span style="color:navy;">f</span>&nbsp;x&nbsp;y</pre> </p> <p> This function takes a curried function <code>f</code>, and returns a new function that does the same, but instead takes a tuple as input. </p> <p> <strong>Pair isomorphism</strong> </p> <p> Haskell comes with <code>curry</code> and <code>uncurry</code> as part of its standard library. It hardly comes as a surprise that they form an isomorphism. You can demonstrate this with some <a href="">QuickCheck</a> properties. </p> <p> If you have a curried function, you should be able to first <code>uncurry</code> it, then <code>curry</code> that function, and that function should be the same as the original function. In order to demonstrate that, I chose the <code>(&lt;&gt;)</code> operator from <code>Data.Semigroup</code>. Recall that Haskell operators are curried functions. This property function demonstrates the round-trip property of <code>uncurry</code> and <code>curry</code>: </p> <p> <pre><span style="color:#600277;">semigroup2RoundTrips</span>&nbsp;::&nbsp;(<span style="color:blue;">Semigroup</span>&nbsp;a,&nbsp;<span style="color:blue;">Eq</span>&nbsp;a)&nbsp;<span style="color:blue;">=&gt;</span>&nbsp;a&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;a&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;Bool semigroup2RoundTrips&nbsp;x&nbsp;y&nbsp;<span style="color:#666666;">=</span> &nbsp;&nbsp;x&nbsp;<span style="color:#666666;">&lt;&gt;</span>&nbsp;y&nbsp;<span style="color:#666666;">==</span>&nbsp;curry&nbsp;(uncurry&nbsp;<span style="color:#600277;">(&lt;&gt;)</span>)&nbsp;x&nbsp;y </pre> </p> <p> This property states that the result of combining two <a href="">semigroup</a> values is the same as first uncurrying <code>(&lt;&gt;)</code>, and then 'recurry' it. It passes for various <code>Semigroup</code> instances: </p> <p> <pre>testProperty&nbsp;<span style="color:#a31515;">&quot;All&nbsp;round-trips&quot;</span>&nbsp;(semigroup2RoundTrips&nbsp;<span style="color:#666666;">::</span>&nbsp;<span style="color:#dd0000;">All</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">All</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">Bool</span>), testProperty&nbsp;<span style="color:#a31515;">&quot;Any&nbsp;round-trips&quot;</span>&nbsp;(semigroup2RoundTrips&nbsp;<span style="color:#666666;">::</span>&nbsp;<span style="color:#dd0000;">Any</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">Any</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">Bool</span>), testProperty&nbsp;<span style="color:#a31515;">&quot;First&nbsp;round-trips&quot;</span>&nbsp;(semigroup2RoundTrips&nbsp;<span style="color:#666666;">::</span>&nbsp;<span style="color:#dd0000;">First</span>&nbsp;<span style="color:#dd0000;">Int</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">First</span>&nbsp;<span style="color:#dd0000;">Int</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">Bool</span>), testProperty&nbsp;<span style="color:#a31515;">&quot;Last&nbsp;round-trips&quot;</span>&nbsp;(semigroup2RoundTrips&nbsp;<span style="color:#666666;">::</span>&nbsp;<span style="color:#dd0000;">Last</span>&nbsp;<span style="color:#dd0000;">Int</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">Last</span>&nbsp;<span style="color:#dd0000;">Int</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">Bool</span>), testProperty&nbsp;<span style="color:#a31515;">&quot;Sum&nbsp;round-trips&quot;</span>&nbsp;(semigroup2RoundTrips&nbsp;<span style="color:#666666;">::</span>&nbsp;<span style="color:#dd0000;">Sum</span>&nbsp;<span style="color:#dd0000;">Int</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">Sum</span>&nbsp;<span style="color:#dd0000;">Int</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">Bool</span>), testProperty&nbsp;<span style="color:#a31515;">&quot;Product&nbsp;round-trips&quot;</span>&nbsp;(semigroup2RoundTrips&nbsp;<span style="color:#666666;">::</span>&nbsp;<span style="color:#dd0000;">Product</span>&nbsp;<span style="color:#dd0000;">Int</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">Product</span>&nbsp;<span style="color:#dd0000;">Int</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">Bool</span>) </pre> </p> <p> It's not a formal proof that all of these properties pass, but it does demonstrate the isomorphic nature of these two functions. In order to be truly isomorphic, however, you must also be able to start with a tupled function. In order to have a similar tupled function, I defined this: </p> <p> <pre><span style="color:#600277;">t2sg</span>&nbsp;::&nbsp;<span style="color:blue;">Semigroup</span>&nbsp;a&nbsp;<span style="color:blue;">=&gt;</span>&nbsp;(a,&nbsp;a)&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;a t2sg&nbsp;(x,&nbsp;y)&nbsp;<span style="color:#666666;">=</span>&nbsp;x&nbsp;<span style="color:#666666;">&lt;&gt;</span>&nbsp;y</pre> </p> <p> The <em>t2</em> in the name stands for <em>tuple-2</em>, and <em>sg</em> means <em>semigroup</em>. It really only exposes <code>(&lt;&gt;)</code> in tupled form. With it, though, you can write another property that demonstrates that the mapping starting with a tupled form is also an isomorphism: </p> <p> <pre><span style="color:#600277;">pairedRoundTrips</span>&nbsp;::&nbsp;(<span style="color:blue;">Semigroup</span>&nbsp;a,&nbsp;<span style="color:blue;">Eq</span>&nbsp;a)&nbsp;<span style="color:blue;">=&gt;</span>&nbsp;a&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;a&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;Bool pairedRoundTrips&nbsp;x&nbsp;y&nbsp;<span style="color:#666666;">=</span> &nbsp;&nbsp;t2sg&nbsp;(x,&nbsp;y)&nbsp;<span style="color:#666666;">==</span>&nbsp;uncurry&nbsp;(curry&nbsp;t2sg)&nbsp;(x,&nbsp;y) </pre> </p> <p> You can create properties for the same instances of <code>Semigroup</code> as the above list for <code>semigroup2RoundTrips</code>, and they all pass as well. </p> <p> <strong>Triplet isomorphism</strong> </p> <p> <code>curry</code> and <code>uncurry</code> only works for pairs (two-tuples) and functions that take exactly two curried arguments. What if you have a function that takes three curried arguments, or a function that takes a triplet (three-tuple) as an argument? </p> <p> First of all, while they aren't built-in, you can easily define corresponding mappings for those as well: </p> <p> <pre><span style="color:#600277;">curry3</span>&nbsp;::&nbsp;((a,&nbsp;b,&nbsp;c)&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;d)&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;a&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;b&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;c&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;d curry3&nbsp;f&nbsp;x&nbsp;y&nbsp;z&nbsp;<span style="color:#666666;">=</span>&nbsp;f&nbsp;(x,&nbsp;y,&nbsp;z) <span style="color:#600277;">uncurry3</span>&nbsp;::&nbsp;(a&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;b&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;c&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;d)&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;(a,&nbsp;b,&nbsp;c)&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;d uncurry3&nbsp;f&nbsp;(x,&nbsp;y,&nbsp;z)&nbsp;<span style="color:#666666;">=</span>&nbsp;f&nbsp;x&nbsp;y&nbsp;z </pre> </p> <p> These form an isomorphism as well. </p> <p> More generally, though, you can represent a triplet <code>(a, b, c)</code> as a nested pair: <code>(a, (b, c))</code>. These two representations are also isomorphic, as is <code>(a, b, c, d)</code> with <code>(a, (b, (c, d)))</code>. In other words, you can represent any n-tuple as a nested pair, and you already know that a function taking a pair as input is isomorphic to a curried function. </p> <p> <strong>Summary</strong> </p> <p> From <a href="">abstract algebra</a>, and particularly its application to a language like Haskell, we have mathematical abstractions over computation - semigroups, for example! In Haskell, these abstractions are often represented in curried form. If we wish to learn about such abstractions, and see if we can use them in object-oriented programming as well, we need to translate the curried representations into something more closely related to object-oriented programming, such as C# or Java. </p> <p> The present article describes how functions in curried form are equivalent to functions that take a single tuple as argument, and in a <a href="">previous article</a>, you saw how such functions are isomorphic to C# or Java methods. These equivalences provide a bridge that enables us to take what we've learned about abstract algebra and <a href="">category theory</a>, and bring them to object-oriented programming. </p> <p> <strong>Next:</strong> <a href="">Object isomorphisms</a>. </p> </div> <hr> This blog is totally free, but if you like it, please <a href="">buy me a cup of coffee</a>. Mark Seemann Argument list isomorphisms Mon, 29 Jan 2018 07:23:00 UTC <div id="post"> <p> <em>There are many ways to represent an argument list. An overview for object-oriented programmers.</em> </p> <p> This article is part of <a href="">a series of articles about software design isomorphisms</a>. </p> <p> Most programming languages enable you to pass arguments to operations. In C# and Java, you declare methods with a list of arguments: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Foo</span>&nbsp;Bar(<span style="color:#2b91af;">Baz</span>&nbsp;baz,&nbsp;<span style="color:#2b91af;">Qux</span>&nbsp;qux)</pre> </p> <p> Here, <code>baz</code> and <code>qux</code> are arguments to the <code>Bar</code> method. Together, the arguments for a method is called an <em>argument list</em>. To be clear, this isn't universally adopted terminology, but is what I'll be using in this article. Sometimes, people (including me) say <em>parameter</em> instead of <em>argument</em>, and I'm not aware of any formal specification to differentiate the two. </p> <p> While you can pass arguments as a flat list, you can also model them as parameter objects or tuples. These representations are equivalent, because lossless translations between them exist. We say that they are isomorphic. </p> <p> <strong>Isomorphisms</strong> </p> <p> In theory, you can declare a method that takes thousands of arguments. In practice, you should constrain your design to as few arguments as possible. As <a href="">Refactoring</a> demonstrates, one way to do that is to <em>Introduce Parameter Object</em>. That, already, teaches us that there's a mapping from a flat argument list to a Parameter Object. Is there an inverse mapping? Do other representations exist? </p> <p> <img src="/content/binary/argument-list-isomorphisms.png" alt="Isomorphisms between the general concept of a product type, and three types of representation: argument lists, parameter objects, and tuples."> </p> <p> There's at least three alternative representations of a group of arguments: <ul> <li>Argument list</li> <li>Parameter Object</li> <li>Tuple</li> </ul> The central concept that they all seem to orbit is what in <a href="">category theory</a> is known as a <em>product</em>. In the theory of <a href="">algebraic data types</a>, this is known as a <em>product type</em>. In short, a product type is a composite of elements, where each element can vary independently of the other elements. For more details, I can recommend <a href="">Tomáš Petříček</a>'s introduction to the subject: <a href="">Power of mathematics: Reasoning about functional types</a>. </p> <p> <strong>Argument list/Parameter Object isomorphism</strong> </p> <p> Perhaps the best-known mapping from an argument list is the <em>Introduce Parameter Object</em> refactoring described in <em>Refactoring</em>. </p> <p> Since the refactoring is described in detail in the book, I don't want to repeat it all here, but in short, assume that you have a method like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Bar</span>&nbsp;Baz(<span style="color:#2b91af;">Qux</span>&nbsp;qux,&nbsp;<span style="color:#2b91af;">Corge</span>&nbsp;corge)</pre> </p> <p> In this case, the method only has two arguments, so the refactoring may not be necessary, but that's not the point. The point is that it's possible to refactor the code to this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Bar</span>&nbsp;Baz(<span style="color:#2b91af;">BazParameter</span>&nbsp;arg) </pre> </p> <p> where <code>BazParameter</code> looks like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">BazParameter</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Qux</span>&nbsp;Qux&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">set</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Corge</span>&nbsp;Corge&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">set</span>;&nbsp;} }</pre> </p> <p> In <em>Refactoring</em>, the recipe states that you should make the class immutable, and while that's a good idea (I recommend it!), it's technically not necessary in order to perform the translation, so I omitted it here in order to make the code simpler. </p> <p> You're probably able to figure out how to translate back again. We could call this refactoring <em>Dissolve Parameter Object:</em> <ol> <li>For each field or property in the Parameter Object, add a new method argument to the target method.</li> <li>At all call sites, pass the Parameter Object's field or property value as each of those new arguments.</li> <li>Change the method body so that it uses each new argument, instead of the Parameter Object.</li> <li>Remove the Parameter Object argument, and update call sites accordingly.</li> </ol> You can go back and forth between a 'flat' argument list and a Parameter Object without loss of information, so these two refactorings together form an isomorphism. </p> <p> As an example, consider the <a href="">Roster example from a previous article</a>. The <code>Combine</code> method on the <code>Roster</code> class is implemented like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Roster</span>&nbsp;Combine(<span style="color:#2b91af;">Roster</span>&nbsp;other) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Roster</span>( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Girls&nbsp;+&nbsp;other.Girls, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Boys&nbsp;+&nbsp;other.Boys, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Exemptions.Concat(other.Exemptions).ToArray()); }</pre> </p> <p> This method takes an object as a single argument. You can think of this <code>Roster</code> object as a Parameter Object. </p> <p> If you like, you can add a method overload that dissolves the <code>Roster</code> object to its constituent values: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Roster</span>&nbsp;Combine( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">int</span>&nbsp;otherGirls, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">int</span>&nbsp;otherBoys, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">params</span>&nbsp;<span style="color:blue;">string</span>[]&nbsp;otherExemptions) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">this</span>.Combine( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Roster</span>(otherGirls,&nbsp;otherBoys,&nbsp;otherExemptions)); }</pre> </p> <p> In this incarnation, the dissolved method overload creates a new <code>Roster</code> from its argument list and delegates to the other overload. This is, however, an arbitrary implementation detail. You could just as well implement the two methods the other way around: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Roster</span>&nbsp;Combine(<span style="color:#2b91af;">Roster</span>&nbsp;other) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">this</span>.Combine( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;other.Girls, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;other.Boys, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;other.Exemptions.ToArray()); } <span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Roster</span>&nbsp;Combine( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">int</span>&nbsp;otherGirls, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">int</span>&nbsp;otherBoys, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">params</span>&nbsp;<span style="color:blue;">string</span>[]&nbsp;otherExemptions) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Roster</span>( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Girls&nbsp;+&nbsp;otherGirls, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Boys&nbsp;+&nbsp;otherBoys, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Exemptions.Concat(otherExemptions).ToArray()); }</pre> </p> <p> In this variation, the overload that takes three arguments contains the implementation, whereas the <code>Combine(Roster)</code> overload simply delegates to the <code>Combine(int, int, string[])</code> overload. </p> <p> In order to illustrate the idea that both APIs are equivalent, in this example I show two method overloads side by side. The overall point, however, is that you can translate between such two representations without changing the behaviour of the system. You don't have to keep both method overloads in place together. </p> <p> <strong>Argument list/tuple isomorphism</strong> </p> <p> In relationship to statically typed functional programming, the term <em>argument list</em> is confounding. In the functional programming languages I've so far dabbled with (<a href="">F#</a>, <a href="">Haskell</a>, <a href="">PureScript</a>, <a href="">Clojure</a>, <a href="">Erlang</a>), the word <em>list</em> is used synonymously with <a href="">linked list</a>. </p> <p> As a data type, a linked list can hold an arbitrary number of elements. (In Haskell, it can even be infinite, because Haskell is lazily evaluated.) Statically typed languages like F# and Haskell add the constraint that all elements must have the same type. </p> <p> An argument list like <code>(Qux qux, Corge corge)</code> isn't at all a statically typed linked list. Neither does it have an arbitrary size nor does it contain elements of the same type. On the contrary, it has a fixed length (two), and elements of different types. The first element must be a <code>Qux</code> value, and the second element must be a <code>Corge</code> value. </p> <p> That's not a list; that's a tuple. </p> <p> Surprisingly, Haskell may provide the most digestible illustration of that, even if you don't know how to read Haskell syntax. Suppose you have the values <code>qux</code> and <code>corge</code>, of similarly named types. Consider a C# method call <code>Baz(qux, corge)</code>. What's the type of the 'argument list'? </p> <p> <pre>λ&gt; :type (qux, corge) (qux, corge) :: (Qux, Corge)</pre> </p> <p> <code>:type</code> is a <a href="">GHCi</a> command that displays the type of an expression. By coincidence (or is it?), the C# argument list <code>(qux, corge)</code> is also valid Haskell syntax, but it is syntax for a tuple. In this example, the tuple is a <em>pair</em> where the first element has the type <code>Qux</code>, and the second element has the type <code>Corge</code>, but <code>(foo, qux, corge)</code> would be a triple, <code>(foo, qux, corge, grault)</code> would be a quadruple, and so on. </p> <p> We know that the argument list/tuple isomorphism exists, because that's how the F# compiler works. F# is a multi-paradigmatic language, and it can interact with C# code. It does that by treating all C# argument lists as tuples. Consider this example of calling <a href="">Math.Pow</a>: </p> <p> <pre><span style="color:blue;">let</span>&nbsp;i&nbsp;=&nbsp;<span style="color:teal;">Math</span>.<span style="color:navy;">Pow</span>(2.,&nbsp;4.)</pre> </p> <p> Programmers who still write more C# than F# often write it like that, because it looks like a method call, but I prefer to insert a space between the method and the arguments: </p> <p> <pre><span style="color:blue;">let</span>&nbsp;i&nbsp;=&nbsp;<span style="color:teal;">Math</span>.<span style="color:navy;">Pow</span>&nbsp;(2.,&nbsp;4.)</pre> </p> <p> The reason is that in F#, function calls are delimited with space. The brackets are there in order to override the normal operator precedence, just like you'd write <code>(1 + 2) * 3</code> in order to get <code>9</code> instead of <code>7</code>. This is better illustrated by introducing an intermediate value: </p> <p> <pre><span style="color:blue;">let</span>&nbsp;t&nbsp;=&nbsp;(2.,&nbsp;4.) <span style="color:blue;">let</span>&nbsp;i&nbsp;=&nbsp;<span style="color:teal;">Math</span>.<span style="color:navy;">Pow</span>&nbsp;t</pre> </p> <p> or even </p> <p> <pre><span style="color:blue;">let</span>&nbsp;t&nbsp;=&nbsp;2.,&nbsp;4. <span style="color:blue;">let</span>&nbsp;i&nbsp;=&nbsp;<span style="color:teal;">Math</span>.<span style="color:navy;">Pow</span>&nbsp;t</pre> </p> <p> because the brackets are now redundant. In the last two examples, <code>t</code> is a tuple of two floating-point numbers. All four code examples are equivalent and compile, thereby demonstrating that a translation exist from F# tuples to C# argument lists. </p> <p> The inverse translation exists as well. You can see a demonstration of this in the (dormant) <a href="">Numsense</a> code base, which includes an object-oriented <a href="">Façade</a>, which defines (among other things) an interface where the <code>TryParse</code> method takes a tuple argument. Here's the declaration of that method: </p> <p> <pre><span style="color:blue;">abstract</span>&nbsp;<span style="color:navy;">TryParse</span>&nbsp;:&nbsp;s&nbsp;:&nbsp;<span style="color:teal;">string</span>&nbsp;*&nbsp;[&lt;<span style="color:teal;">Out</span>&gt;]result&nbsp;:&nbsp;<span style="color:teal;">int</span>&nbsp;<span style="color:teal;">byref</span>&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:teal;">bool</span></pre> </p> <p> That looks cryptic, but if you remove the <code>[&lt;Out&gt;]</code> annotation and the argument names, the method is declared as taking <em>single</em> input value of the type <code>string * int byref</code>. It's a single value, but it's a tuple (a pair). </p> <p> Perhaps it's easier to understand if you see an implementation of this interface method, so here's the English implementation: </p> <p> <pre><span style="color:blue;">member</span>&nbsp;this.<span style="color:navy;">TryParse</span>&nbsp;(s,&nbsp;result)&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:teal;">Helper</span>.<span style="color:navy;">tryParse</span>&nbsp;<span style="color:teal;">Numeral</span>.<span style="color:navy;">tryParseEnglish</span>&nbsp;(s,&nbsp;&amp;result)</pre> </p> <p> You can see that, as I've described above, I've inserted a space between <code>this.TryParse</code> and <code>(s, result)</code>, in order to highlight that this is an F# function that takes a single tuple as input. </p> <p> In C#, however, you can use the method as though it had a standard C# argument list: </p> <p> <pre><span style="color:blue;">int</span>&nbsp;i; <span style="color:blue;">var</span>&nbsp;success&nbsp;=&nbsp;<span style="color:#2b91af;">Numeral</span>.English.TryParse( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#a31515;">&quot;one-thousand-three-hundred-thirty-seven&quot;</span>, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">out</span>&nbsp;i);</pre> </p> <p> You'll note that this is an advanced example that involves an <code>out</code> parameter, but even in this edge case, the translation is possible. </p> <p> C# argument lists and F# tuples are isomorphic. I'd be surprised if this result doesn't extend to other languages. </p> <p> <strong>Parameter Object/tuple isomorphism</strong> </p> <p> The third isomorphism that I claim exists is the one between Parameter Objects and tuples. If, however, we assume that the two above isomorphisms hold, then this third isomorphism exists as well. I know from my copy of <a href="">Conceptual Mathematics</a> that isomorphisms are transitive. If you can translate from Parameter Object to argument list, and from argument list to tuple, then you can translate from Parameter Object to tuple; and vice versa. </p> <p> Thus, I'm not going to use more words on this isomorphism. </p> <p> <strong>Summary</strong> </p> <p> Argument lists, Parameter Objects, and tuples are isomorphic. This has a few interesting implications, first of which is that because all these refactorings exist, you can employ them. If a method's argument list is inconvenient, consider introducing a Parameter Object. If your Parameter Object starts to look <a href="">so generic that you have a hard time coming up with good names for its elements</a>, perhaps a tuple is more appropriate. On the other hand, if you have a tuple, but it's unclear what role each unnamed element plays, consider refactoring to an argument list or Parameter Object. </p> <p> Another important result is that since these three ways to model arguments are isomorphic, we can treat them as interchangeable in analysis. For instance, from category theory we can learn about the properties of tuples. These properties, then, also apply to C# and Java argument lists. </p> <p> <strong>Next:</strong> <a href="">Uncurry isomorphisms</a>. </p> </div><hr> This blog is totally free, but if you like it, please <a href="">buy me a cup of coffee</a>. Mark Seemann Function isomorphisms Mon, 22 Jan 2018 14:37:00 UTC <div id="post"> <p> <em>Instance methods are isomorphic to functions.</em> </p> <p> This article is part of <a href="">a series of articles about software design isomorphisms</a>. </p> <p> While I have already, in <a href="">an earlier article</a>, quoted the following parable about Anton, Qc Na, objects, and closures, it's too good a fit to the current topic to pass up, so please pardon the duplication. </p> <blockquote> <p> The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." </p> <p> Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. </p> <p> On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened. </p> <p> - <a href="">Anton van Straaten</a> </p> </blockquote> <p> The point is that objects and closures are two ways of looking at a thing. In a nutshell, objects are data with behaviour, whereas closures are behaviour with data. I've <a href="">already shown an elaborate C# example of this</a>, so in this article, you'll get a slightly more formal treatment of the subject. </p> <p> <strong>Isomorphism</strong> </p> <p> In object-oriented design, you often bundle operations as methods that belong to objects. These are isomorphic to static methods, because a lossless translation exists. We can call such static methods <em>functions</em>, although they aren't guaranteed to be <a href="">pure</a>. </p> <p> <img src="/content/binary/function-isomorphism.png" alt="Diagram showing isomorphism between instance method and function."> </p> <p> In the spirit of <a href="">Refactoring</a>, we can describe each translation as a refactoring, because that's what it is. I don't think the book contains a specific refactoring that describes how to translate from an instance method to a static method, but we could call it <em>Replace Object with Argument</em>. </p> <p> Going the other way is, on the other hand, already described, so we can use Refactoring's <em>Move Method</em>. </p> <p> <strong>Replace Object with Argument</strong> </p> <p> While the concept of refactoring ought to be neutral across paradigms, the original book is about object-oriented programming. In object-oriented programming, objects are the design ideal, so it didn't make much sense to include, in the book, a refactoring that turns an instance method into a static method. </p> <p> Nevertheless, it's straightforward: <ol> <li>Add an argument to the instance method. Declare the argument as the type of the hosting class.</li> <li>In the method body, change all calls to <code>this</code> and <code>base</code> to the new argument.</li> <li>Make the method static.</li> </ol> As an example, imagine that you start with an instance method like this <code>Baz</code> method: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Foo</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Bar</span>&nbsp;Baz(<span style="color:#2b91af;">Qux</span>&nbsp;qux,&nbsp;<span style="color:#2b91af;">Corge</span>&nbsp;corge) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff,&nbsp;return&nbsp;bar</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Other&nbsp;members...</span> }</pre> </p> <p> You'll first introduce a new <code>Foo foo</code> argument to <code>Baz</code>, change the method body to use <code>foo</code> instead of <code>this</code>, and then make the method static. The result is this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Foo</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Bar</span>&nbsp;Baz(<span style="color:#2b91af;">Foo</span>&nbsp;foo,&nbsp;<span style="color:#2b91af;">Qux</span>&nbsp;qux,&nbsp;<span style="color:#2b91af;">Corge</span>&nbsp;corge) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff,&nbsp;return&nbsp;bar</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Other&nbsp;members...</span> }</pre> </p> <p> Once you have a static method, you can always move it to another class, if you'd like. This can, however, cause some problems with accessibility. In C#, for example, you'd no longer be able to access <code>private</code> or <code>protected</code> members from a method outside the class. You can choose to leave the static method reside on the original class, or you can make the member in question available to more clients (make it <code>internal</code> or <code>public</code>). </p> <p> <strong>Move Method</strong> </p> <p> The book Refactoring doesn't contain a recipe like the above, because the goal of that book is better object-oriented design. It would consider a static method, like the second variation of <code>Baz</code> above, a code smell named <em>Feature Envy</em>. You have this code smell when it looks as if a method is more interested in one of its arguments than in its host object. In that case, the book suggests using the <em>Move Method</em> refactoring. </p> <p> The book already describes this refactoring, so I'm not going to repeat it here. Also, there's no sense in showing you the code example, because it's literally the same two code examples as above, only in the opposite order. You start with the static method and end with the instance method. </p> <p> C# developers are most likely already aware of this relationship between static methods and objects, because you can use the <code>this</code> keyword in a static method to make it look like an instance method: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Bar</span>&nbsp;Baz(<span style="color:blue;">this</span>&nbsp;<span style="color:#2b91af;">Foo</span>&nbsp;foo,&nbsp;<span style="color:#2b91af;">Qux</span>&nbsp;qux,&nbsp;<span style="color:#2b91af;">Corge</span>&nbsp;corge) </pre> </p> <p> The addition of <code>this</code> in front of the <code>Foo foo</code> argument enables the C# compiler to treat the <code>Baz</code> method as though it's an instance method on a <code>Foo</code>object: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;bar&nbsp;=&nbsp;foo.Baz(qux,&nbsp;corge);</pre> </p> <p> This is only syntactic sugar. The method is still compiled as a static method, and if you, as a client developer, wish to use it as a static method, that's still possible. </p> <p> <strong>Functions</strong> </p> <p> A static method like <code>public static Bar Baz(Foo foo, Qux qux, Corge corge)</code> looks a lot like a function. If refactored from object-oriented design, that function is likely to be impure, but its shape is function-like. </p> <p> In C#, for example, you could model it as a variable of a delegate type: </p> <p> <pre><span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">Foo</span>,&nbsp;<span style="color:#2b91af;">Qux</span>,&nbsp;<span style="color:#2b91af;">Corge</span>,&nbsp;<span style="color:#2b91af;">Bar</span>&gt;&nbsp;baz&nbsp;=&nbsp;(foo,&nbsp;qux,&nbsp;corge)&nbsp;=&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff,&nbsp;return&nbsp;bar</span> };</pre> </p> <p> Here, <code>baz</code> is a function with the same signature as the above static <code>Baz</code> method. </p> <p> Have you ever noticed something odd about the various <code>Func</code> delegates in C#? </p> <p> They take the return type as the <em>last</em> type argument, which is contrary to C# syntax, where you have to declare the return type before the method name and argument list. Since C# is the dominant .NET language, that's surprising, and even counter-intuitive. </p> <p> It does, however, nicely align with an ML language like <a href="">F#</a>. As we'll see in a future article, the above <code>baz</code> function translates to an F# function with the type <code>Foo * Qux * Corge -&gt; Bar</code>, and to <a href="">Haskell</a> as a function with the type <code>(Foo, Qux, Corge) -&gt; Bar</code>. Notice that the return type comes last, just like in the C# <code>Func</code>. </p> <p> <strong>Closures</strong> </p> <p> <em>...but,</em> you may say, <em>what about data with behaviour?</em> One of the advantages, after all, of objects is that you can associate a particular collection of data with some behaviour. The above <code>Foo</code> class could have data members, and you may sometimes have a need for passing both data and behaviour around as a single... well... <em>object</em>. </p> <p> That seems to be much harder with a static <code>Baz</code> method. </p> <p> Don't worry, write a closure: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;foo&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Foo</span>&nbsp;{&nbsp;<span style="color:green;">/*&nbsp;initialize&nbsp;members&nbsp;here&nbsp;*/</span>&nbsp;}; <span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">Qux</span>,&nbsp;<span style="color:#2b91af;">Corge</span>,&nbsp;<span style="color:#2b91af;">Bar</span>&gt;&nbsp;baz&nbsp;=&nbsp;(qux,&nbsp;corge)&nbsp;=&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;foo,&nbsp;qux,&nbsp;and&nbsp;corge;&nbsp;return&nbsp;bar</span> };</pre> </p> <p> In this variation, <code>baz</code> closes over <code>foo</code>. Inside the function body, you can use <code>foo</code> like you can use <code>qux</code> and <code>corge</code>. As I've <a href="">already covered in an earlier article</a>, the C# compiler compiles this to an IL class, making it even more obvious that objects and closures are two sides of the same coin. </p> <p> <strong>Summary</strong> </p> <p> Object-oriented instance methods are isomorphic to both static methods and function values. The translations that transforms your code from one to the other are <em>refactorings</em>. Since you can move in both directions without loss of information, these refactorings constitute an isomorphism. </p> <p> This is another important result about the relationship between object-oriented design and functional programming, because this enables us to reduce any method to a canonical form, in the shape of a function. From a language like Haskell, we know a lot about the relationship between category theory and functional programming. With isomorphisms like the present, we can begin to extend that knowledge to object-oriented design. </p> <p> <strong>Next:</strong> <a href="">Argument list isomorphisms</a>. </p> </div><hr> This blog is totally free, but if you like it, please <a href="">buy me a cup of coffee</a>. Mark Seemann