Posts Tagged C#

My love… for Expressive Programming Languages

I started out my journey with programming as a teenager learning GW-BASIC. Soon I learnt C language followed by C++.  I was impressed with the OO syntactic constructs C++ had on offer but I felt a little uneasy with a few constructs such as the scope resolution. I started studying Java. It immediately caught my attention with the syntactic improvements and simplifications it brought over C++.

I was still in academics, so learning(precisely trying) programming languages on surface, was a fun activity. I went through PHP, Javascript. I came in interaction with C#. This was the time this language was evolving. The internet was full of text describing the fact that C# was Microsoft’s Java. This encouraged me to study C# and consequently .Net Framework in detail. This was the time LINQ was introduced and I simply loved it. I really liked the way it was elegantly added to the C#. The features added to C# for supporting LINQ namely lambda expressions, implicitly typed  variables, anonymous types, extension methods, query expressions and etc complemented the LINQ infrastructure beautifully. By the time I finished academics, I was a seasoned OO developer.

Recently, I was considering to learn a more cryptic language that aligns with jQuery’s ‘write less, do more’ tagline (although not a language, I like jQuery for the same reason). I considered Python/Ruby but did not find these exciting enough. I have just come across Scala, and decided to make it my next fun mission.

Normally when I learn a new programming, I would give very little time to learning conventional constructs(for, if, function/class definitions etc). After a very long time, I have come in connection with a language that demands paying attention to such constructs. So no liberty of skipping pages.

I am considering Programming in Scala by Martin Odersky – the man behind Scala, et al. At the time of writing this post, considerable amount of content that teaches Scala, is avaible on Google Books. If you already know Scala, you would probably know by now, what my feedback about the language is…A-W-E-S-O-M-E.

The motivation for using Expressive Languages

  • The code becomes declarative in nature. It has less noise for syntactic constructs and more concentration on the intended logic.
  • The above feature makes the developer productive in writing and making changes to the code
  • Debugging becomes super easy.
  • I personally feel, a developer has a better chance of aligning his/her code with coding best practices.

The only reason I find to keep my self from using an expressive language for a particular task is, as you might have guessed performance. Comparing LINQ to collections with loops, reveals loops are faster. You need to be able to judge if you need mission critical performance, otherwise the difference is ignorable.

, , , , ,

4 Comments

Multiple Inheritance with Strategy Pattern

When I was introduced to programming languages like Java and C# (coming from C++), one of the things that I really missed was Multiple Inheritance. That is, in these languages we could not say something like:

class AllRounder : Batsman, Bowler { }

These languages offer interfaces to establish polymorphism. That is we can say (in C#):

class Batsman
{
     void Bat()
     {  Console.WriteLine("Do batting.");  }
}
interface IBowler
{
     void Bowl();
}
class Bowler : IBowler
{
     public void Bowl()
     {  Console.WriteLine("Do bowling.");  }
}
class AllRounder : Batsman, IBowler
{
     public void Bowl()
     {  Console.WriteLine("Do bowling.");  }
}

Do you see a problem here…? I do.

The problem is that the Bowl() is implemented twice, although the code it contains is by definition the same. Its a shame calling this code ‘Multiple inheritance’ because actually interfaces do not inherit anything. They just ensure a contract. The only feature of inheritance that interface provide is Polymorphism. You can say:

IBowler bowler = new AllRounder();
bowler.Bowl();

But the problem with duplication is that if we need changing Bowl() in the Bowler class we will almost always require changing the Bowl() implementation in the AllRounder class. The are a few ways to get around this. The key to all solutions I can think of at the moment is to introduce a layer of abstraction i.e. wrap the code of Bowl() into code commonly accessible to both. I’ll choose using the Strategy Pattern

interface IBowlingBehavior
{
    void PerformBowling();
}
interface IBowler
{
    IBowlingBehavior BowlingBehavior { get; set; }
    void Bowl();
}
class Batsman
{
    void Bat()
    {  Console.WriteLine("Do batting.");  }
}
class Bowler : IBowler
{
    public IBowlingBehavior BowlingBehavior { get; set; }
    public void Bowl()
    {  BowlingBehavior.PerformBowling();  }
}
class AllRounder : Batsman, IBowler
{
    public IBowlingBehavior BowlingBehavior { get; set; }
    public void Bowl()
    {  BowlingBehavior.PerformBowling(); }
}
class DefaultBowlingBehavior : IBowlingBehavior
{
    public void PerformBowling()
    {  Console.WriteLine("Do bowling.");  }
}

This allows us to implement the bowling code in one place as well as select one of the many implementations of BowlingBehaviors at runtime!

class SpinBowlingBehavior : IBowlingBehavior
{
    public void PerformBowling()
    {  Console.WriteLine("Do spin bowling.");  }
}
class FastBowlingBehavior : IBowlingBehavior
{
    public void PerformBowling()
    {  Console.WriteLine("Do fast bowling.");  }
}

and later we can say…

Bowler fastBowler = new Bowler { BowlingBehavior = new FastBowlingBehavior() };
fastBowler.Bowl(); //Bowl Fast
fastBowler.Bowl(); //Bowl Fast
fastBowler.BowlingBehavior = new SpinBowlingBehavior();
fastBowler.Bowl(); //Bowl Slow, fool the batsman

, , , ,

2 Comments