using System;

using System.Linq;

using System.Collections.Generic;

using System.Threading.Tasks;

​

/* READ THIS FIRST */

/* Both of the examples have a statement that say "You later decide to change behavior more than once during app lifetime"

/* The point of this brainteaser is that when we first write this code, we think we only ever intend to have the behavior set once at app startup.

    If we are confident it will always be that way, then the functional/reusable paradigm says pick Gadget1.

    But if we already expect that we might later change behavior to be dynamic during runtime with multiple changes, then which design do you pick?

    You could still argue Gadget1.

    But what if you go even further and want more actors involve who change their own behavior based on the behavior of the Gadget?

    These actors could be observers of Gadget.  Otherwise you would need a separate class that tracks behavior state outside of Gadget.

    Things start taking a very specific direction that seems like it gets worse than if everything had just been put in Gadget2.  yes/no? Thoughts?

    */

​

public delegate void Behavior();

​

/* - Behavior defined externally and injected

    Consumer must know: How to define a behavior that will satisfy Gadget.

    Design effects: If you need a Visitor/Observer that can make decisions based on the behavior mode of Gadget at a late moment during runtime (not app startup),

            you will need a separate config/state object that knows the state of Gadget.  The visitor/observe can read that object.

            Building on above:  If you later decide you want to change behavior more than once during application lifetime, you will need to change both the config/state object

            and the Gadget itself.

            */

public class Gadget1

{

    private readonly Behavior behavior;

    public Gadget1(Behavior x)=>

            behavior=x;

    public void DoSomething()=>behavior();

}

​

/* - Behavior defined internally and data is injected to determine behavior

        Consumer must know: A description of how class should behave and what the "data" switch will do.

        Design effects: If you need a Visitor/Observer that can make decisions based on the behavior mode of Gadget at a late moment during runtime (not app startup),

            you can change behavior to public and read the state of Gadget directly.

            Building on above: If you later decide you want to change behavior more than once during application lifetime, you only change the data.

            */

public class Gadget2

{

    private readonly bool behavior;

    public Gadget2(bool data)=>

        behavior = data;

    public void DoSomething()

    {

        if(behavior)

            InternalDo1();

        else

            InternalDo2();

    }

    private void InternalDo1() => Console.WriteLine("Behavior 1");

    private void InternalDo2() => Console.WriteLine("Behavior 2");

}

​

public class Program

{

    public static void Main()

    {

        new Gadget1(Behavior1)

            .DoSomething();

        new Gadget1(Behavior2)

            .DoSomething();

        new Gadget2(true)

            .DoSomething();

        new Gadget2(false)

            .DoSomething();     

    }

    public static void Behavior1() =>

        Console.WriteLine("Behavior 1");

    public static void Behavior2() =>

        Console.WriteLine("Behavior 2");

}