﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Dmitry commented on Design patterns in the test of time: Factory Method</title><description>You can have a protected virtual "Create" method which can be called from the static factory method in the base class.

You can even use a Java-style nested builder class to create the objects. It will have access to the class internals and will not violate the single responsibility principal. 
</description><link>http://ayende.com/159363/design-patterns-in-the-test-of-time-factory-method#comment10</link><guid>http://ayende.com/159363/design-patterns-in-the-test-of-time-factory-method#comment10</guid><pubDate>Sun, 28 Oct 2012 20:06:12 GMT</pubDate></item><item><title>Ken commented on Design patterns in the test of time: Factory Method</title><description>@SteveR:  With a small tweak, the static Factory Method approach can still follow OCP.  For example, WebRequest.Create is a factory method. By registering a new factory with WebRequest.RegisterPrefix, WebRequest.Create can return my own objects. I use this technique to mock WebRequest objects. See answers to http://stackoverflow.com/q/87200 for more info.</description><link>http://ayende.com/159363/design-patterns-in-the-test-of-time-factory-method#comment8</link><guid>http://ayende.com/159363/design-patterns-in-the-test-of-time-factory-method#comment8</guid><pubDate>Sat, 27 Oct 2012 04:09:50 GMT</pubDate></item><item><title>Jimmy Zimms commented on Design patterns in the test of time: Factory Method</title><description>@SteveR.

Ahh my bad. I was reading that as two seperate thoughts, the latter directed at Oren. +D</description><link>http://ayende.com/159363/design-patterns-in-the-test-of-time-factory-method#comment7</link><guid>http://ayende.com/159363/design-patterns-in-the-test-of-time-factory-method#comment7</guid><pubDate>Fri, 26 Oct 2012 21:09:38 GMT</pubDate></item><item><title>SteveR commented on Design patterns in the test of time: Factory Method</title><description>@Jimmy: I was referring to the static Factory Method approach on the base class to avoid the concern about calling virtual methods from a constructor. You pretty much need to know the available subclasses ahead of time or change the method when a new one is introduced, hence the OCP violation.</description><link>http://ayende.com/159363/design-patterns-in-the-test-of-time-factory-method#comment6</link><guid>http://ayende.com/159363/design-patterns-in-the-test-of-time-factory-method#comment6</guid><pubDate>Fri, 26 Oct 2012 18:37:01 GMT</pubDate></item><item><title>Jimmy Zimms commented on Design patterns in the test of time: Factory Method</title><description>@Bartek/Markus

I think this is more a case of succinct for blogging purposes than actually how Oren suggests a factory should be written in practice. What you describe has multiple known "fixes" or techniques for avoiding that situation which can be as simple (or naive as you wish) as using a Lazy there to side step the problem to a method to "start the game"  to something totally full blown as appropriate for the problem area. More importantly to discuss here is the concept he points about about leveraging delegates (with sane default implementations automatically initialized) to callback into to do work.

@SteveR
No sure how you think that this isn't totally amenable to following the OCP. Here in this example is, again, what I assume to be simple code to illustrate the core concept succinctly. To support the OCP all one would need to do is have a core method that does whatever the work is that invokes the supplied delegate for whatever that part of the extensiblity is designed to do. This is what we referred to in the WF4 team as "basic swiss cheese" architecture (a toungue in cheek term). Nothing new here, just common sense =D</description><link>http://ayende.com/159363/design-patterns-in-the-test-of-time-factory-method#comment5</link><guid>http://ayende.com/159363/design-patterns-in-the-test-of-time-factory-method#comment5</guid><pubDate>Fri, 26 Oct 2012 16:52:18 GMT</pubDate></item><item><title>SteveR commented on Design patterns in the test of time: Factory Method</title><description>Of course, you lose the Open-Closed ability..</description><link>http://ayende.com/159363/design-patterns-in-the-test-of-time-factory-method#comment4</link><guid>http://ayende.com/159363/design-patterns-in-the-test-of-time-factory-method#comment4</guid><pubDate>Fri, 26 Oct 2012 15:37:13 GMT</pubDate></item><item><title>SteveR commented on Design patterns in the test of time: Factory Method</title><description>Following the example of WebClient.CreateRequest, you can easily avoid the concerns about calling virtual methods in the constructor by implementing a static Factory Method on the base class instead. In cases where the implementation of the overridden method can depend upon some state in a subclass this works out well, but the delegate approach is nice and light-weight whilst also being more in line with the maxim of preferring composition over inheritance.</description><link>http://ayende.com/159363/design-patterns-in-the-test-of-time-factory-method#comment3</link><guid>http://ayende.com/159363/design-patterns-in-the-test-of-time-factory-method#comment3</guid><pubDate>Fri, 26 Oct 2012 15:28:59 GMT</pubDate></item><item><title>Bartek commented on Design patterns in the test of time: Factory Method</title><description>I think calling virtual member from constructor is not a good idea. It might work in this example but in general it should be avoided: http://msdn.microsoft.com/en-us/library/ms182331(v=vs.80).aspx</description><link>http://ayende.com/159363/design-patterns-in-the-test-of-time-factory-method#comment2</link><guid>http://ayende.com/159363/design-patterns-in-the-test-of-time-factory-method#comment2</guid><pubDate>Fri, 26 Oct 2012 11:38:43 GMT</pubDate></item><item><title>Markus Zywitza commented on Design patterns in the test of time: Factory Method</title><description>I'd rather go for the delegate approach, as it is recommended to *not* access virtual methods from the constructor, as instance state might not be initialized by the time it is called.

The protected instance variable with the delegate is already populated before the base class constructor is called if it was initialized in the code.

But if MakeRoom is set in the child class constructor instead, the base class constructor will instead use the default method implementation. 

Nasty to debug and brittle, so I wouldn't recommend either approach.</description><link>http://ayende.com/159363/design-patterns-in-the-test-of-time-factory-method#comment1</link><guid>http://ayende.com/159363/design-patterns-in-the-test-of-time-factory-method#comment1</guid><pubDate>Fri, 26 Oct 2012 11:37:54 GMT</pubDate></item></channel></rss>