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

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:

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();

}
}


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.

• As a reviewer, I'm not a fan of reviewing contrived examples that do nothing more than implementing a pattern for the sake of implementing a pattern. I hope that you will be able to find some realistic use cases to write code for. – 200_success Mar 10 '16 at 4:28
• Did You read my intention at all? – icbytes Mar 10 '16 at 7:44
• Yes. I'm just noting that I'm not a fan of such questions. – 200_success Mar 10 '16 at 7:51
• This is about porting properly. – icbytes Mar 10 '16 at 7:52
• I might make the case that strictly speaking, a question about porting would be off-topic, but a question about the code (which irrelevantly happens to be ported) would generally speaking be on topic. That question doesn't need to confuse people with the original code that you ported from though. – nhgrif Mar 26 '16 at 17:38

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.

• So, that means, I can now change my question, provide all my source files, the link to the original book, and that's it ? – icbytes Mar 9 '16 at 19:23
• For sure I look them up, that's the book, and the observer pattern for example is best implemented in c# by events. – icbytes Mar 9 '16 at 19:24

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.

• Ok, let me check, if I get this right, with the first sample of the book, the strategy pattern. Original question will be updates soon. – icbytes Mar 9 '16 at 19:27