HeadFirst - Design-Patterns: Porting from Java to C# and C++ for reviewing

Question

I am learning design patterns once more. The book mentioned above offers the examples in java, and I read them, write them and follow the book, I really like their kind of writing. But I gave myself two other exercises besides those in the book. I would like to port those Java exercises to C# and also C++11/14, in order to get some reviews of you (regarding all nice best practice stuff, like "there You can use lambda's, closures etc ...). So prior to flood this nice so-page with dozens of classes and interfaces, I would like to ask whether it is ok, to do so, and if not, why or where could this be ok.

As already stated, I would like to get in deep touch with the design patterns, in 3 languages at least (Java, because the examples are Java, and C# because I work with C# and I love the 5.0 features, and C++11/14 because I was too long away from this monsterous language).

The link to the PDF is here:

HeadFirst: Design Patterns

The first pattern is called strategy pattern and I start on page 18, chapter one (those real page numbers at the bottom, not those in PDF readers).

As you see, all is in java, now I ported this to C# first. My classes are in a folder called classes and my interfaces also in a folder called "Interfaces," therefore you might see the prefices.

I created this exercise as a console application on .NET 4.5 in VS2013 community edition, this is the structure:

Let us start with the interfaces first. Everywhere I will omit the usings, to keep it as small as possible, though informative as necessary, and some parts, being in separate files will be pasted in one code section.

namespace StrategyPattern.Interfaces
{
    public interface IFlyBehaviour
    {
        void fly();
    }
}

namespace StrategyPattern.Interfaces
{
    public interface IQuackBehaviour
    {
         void quack();
    }
}

Classes implementing IQuackBehaviour:

    public class Quack : Interfaces.IQuackBehaviour
    {
        public Quack()
        {

        }

        public void quack()
        {
            Console.WriteLine("QUAAACK");
        }
    }
}

class Sqeek : Interfaces.IQuackBehaviour
    {
        public Sqeek()
        { 

        }


        public void quack()
        {
            Console.WriteLine("SQEEEK");
        }
    }

 class MuteQuack : Interfaces.IQuackBehaviour
    {
        public MuteQuack()
        {

        }

        public void quack()
        {
            Console.WriteLine("<<<<<< NOTHING >>>>>");
        }
    }

Classes implementing IFlyBehaviour:

class FlyRocketPowered : Interfaces.IFlyBehaviour
    {
        public void fly()
        {
            Console.WriteLine("I fly with a jetpack :-)");
        }
    }


 class FlyNoWay : Interfaces.IFlyBehaviour
    {

        public void fly()
        {
            Console.WriteLine("I cannot fly.");
        }
    }

class FlyWithWings : Interfaces.IFlyBehaviour
    {

        public void fly()
        {
            Console.WriteLine("I fly with my wings");
        }
    }

Base class of those "clients":

abstract class Duck
{
    private Interfaces.IQuackBehaviour quackBehaviour;
    public Interfaces.IQuackBehaviour QuackBehaviour
    {
        get { return quackBehaviour; }
        set { quackBehaviour = value; }
    }
    private Interfaces.IFlyBehaviour flyBehaviour;

    public Interfaces.IFlyBehaviour FlyBehaviour
    {
        get { return flyBehaviour; }
        set { flyBehaviour = value; }
    }

    public Duck()
    { 

    }

    public void performQuack()
    {
        quackBehaviour.quack();
    }

    public void performFly()
    {
        flyBehaviour.fly();
    }

    public abstract void display();

Children inheriting from the base class:

class MallardDurck : Classes.Duck
    {
        public MallardDurck()
        {
            FlyBehaviour = new FlyWithWings();
            QuackBehaviour = new Quack();
        }


        public override void display()
        {
            Console.WriteLine("I am a mallard duck");
        }
    }


class ModelDuck :  Classes.Duck
    {   
        public ModelDuck()
        {
            FlyBehaviour = new Classes.FlyNoWay();
            QuackBehaviour = new Classes.Quack();
        }

        public override void display()
        {
            Console.WriteLine("I am a model duck...");
        }
    }

Program:

class Program
{
    static void Main(string[] args)
    {

        Classes.Duck mallardDuck = new Classes.MallardDurck();

        mallardDuck.display();
        mallardDuck.performQuack();
        mallardDuck.performFly();


        Classes.Duck modelDuck = new Classes.ModelDuck();

        Console.WriteLine("-----------------");

        modelDuck.display();
        modelDuck.performQuack();
        modelDuck.performFly();

        Console.WriteLine("-----CHANGING MODEL DUCK---");
        modelDuck.FlyBehaviour = new Classes.FlyRocketPowered();
        modelDuck.QuackBehaviour = new Classes.Sqeek();

        modelDuck.performQuack();
        modelDuck.performFly();

        Console.Read();

    }
}

I would like to have this C# coloured. I still hope you will get it. If not, just tell me and I will adjust any formatting.

Answer 1

I see no reason why not.

But you should note that a direct translation (the most obvious way) is usually not the correct way. You will need to dig a bit deeper into the specific language to get the idiomatic way of doing most things.

As a result I would hope that you at least try and look up those techniques before posting.

Provide a link to the original version may also be useful though not necessary.

Answer 2

Adding to Loki's answer, I'll say that "flooding" the front page with a dozen posts isn't likely to be a good idea, for several reasons:

• Reviewers may point out things that are applicable to every single post
• Only one question per day qualifies for the [badge:socratic] family of badges

Spacing each question a day or two apart allows them to be answered (hopefully), and then you can apply what you learn from the previous reviews to the new code you're writing.

The last thing reviewers want when answering, is to sound like a broken record.