Skip to content

Why Mobile App Developers Do Not Write Windows Phone Apps

The premise of Windows Phone’s future is dull due to lack of applications. Some attribute it to lack of interest from developers. But why? Because developers hate Microsoft that much? Or because Windows Phone is negligible since it is late in the game? Before I give the answer, let me give the conclusion first: Windows Phone’s future will not be brighter than today.

Don’t get me wrong. I am a lifelong Windows developer. Of course, I don’t hate Microsoft. I have developed on Windows NT, 2000, XP and 7 for Desktop, Web and database applications. Recent years, I started to develop mobile apps with IOS first, then, Android using Windows 7.

I love what I am doing now and my Web site and mobile app for IOS and Android is up running happily. So, I thought it is time to move my mobile app to Windows Phone platform. But I can’t. And I can’t even learn Windows Phone development. The reason is that you can only write new Windows Phone applications on Windows 8.

So, basically, Microsoft doesn’t want millions of mobile developers to write Windows Phone apps simply because they use Windows 7! Giving the slim share of Windows 8, no wonder there are not many Windows Phone apps.

To me, the decision is very simple: I have to hold off Windows Phone development for a while until I have time and money to upgrade to Windows 8. I don’t want to make my life more difficult.

So, it is not that developers don’t want to write Windows Phone apps, but that Microsoft restrains developers to write Windows Phone apps. This mistake may cost Windows Phone and Nokia!

Related articles

Mobile/Web Client, Web API and Cloud

Introduction

For the last a few months, I have been busy to put up my dream app with coolest technologies I could think of at the time when I started. Now, it is up and running. Feel free to try it at Shopping With Barcodes. In this blog, I would like to give it an overview and discuss how technologies have helped me to put it up quickly.

Basic Idea

A few months ago, I came up this idea: With a smartphone, you scan a barcode. Then, BOOM! The best deals, similar products and coupons – online or in local stores – are presented in front of you. Sounds pretty cool, eh? So, I rolled up my sleeves to get started.

Technologies

First, it needs to have mobile front end. So, I picked iOS5.1 for Apple devices. Second, it has to support Web front end and provide services. So, MVC3/jSON/HTML5/jQuery/Ajax were selected. Last, I wanted to start it small and cheap. So, the Amazon Web Service Cloud was a good fit.

Architecture

This application uses Front End/Service/Hosting architecture. The front end consists of mobile clients and Web browsers. The server hosts a Web site that also provides a Web API service for front end. It consumes other commercial Web APIs from Amazon, BestBuy, eBay, Google, etc.

fesvh

Overview

Corresponding to Front End/Service/Hosting architecture, this solution is implemented as Mobile/Web Client, Web API and Amazon Cloud with Mobile/Web Client as Front End, Web API as Service and Amazon Cloud as Hosting.

Mobile App

SmartBars is a simple mobile app for Apple and Google smartphones and tablets. It scans barcodes and sends requests to http://www.barcodesmart2u.com for price comparison and coupons. It also saves scan history and can edit scan results and email them. This is how it looks like after scanning a barcode.

scan

Web Front End

The Web front end consists of a set of MVC3 Views. It is based on HTML5/jQuery/Ajax. This is how it looks like after the mobile app sends a request with the scan result.

deal

From this screen, you can open offer details, check similar products, update local stores and search coupons.

Web API Platform

The server is a Web API platform. It consumes various Web APIs like EAN/UPC Web API, Amazon Shopping API, eBay Shopping API, Google Shopping API, Geo Location Web API, etc. Based on these Web APIs, it provides a value-added Price Comparison and Coupons Web API. It is both a consumer and a provider of Web API. The front end consumes the Price Comparision and Coupons Web API without knowing all other Web APIs. As a Web API platform, more Web API services can be consumed as needed and new Web API services can be provided as properly.

The Price Comparison and Coupons Web API provided by http://www.barcodesmart2u.com is jSON-based, which means that front end clients can consume it directly. For Web client (browsers), the jQuery/Ajax is used to consume the jSON service. For Apple mobile app, the Objective C is used to consume the jSON service. For Google mobile app, the Java is used to consume the jSON service. Basically, all types of front end applications consume the same Web API service provided by http://www.barcodesmart2u.com.

Points of Interest

The Mobile/Web Client, Web API and Cloud architecture has the following advantages.

  • Mobile/Web Client means reachable anywhere anytime.
  • Web API means the same service for various types of front end (mobile, Web client and desktop) and other consumers.
  • Cloud means scalable as needed.

In addition, the server as a Web API platform is essentially a hub of Web APIs. A Web API can be plugged in or pulled off easily. More Web APIs from service providers can be consumed as needed. They, then, can be packed as new services for consumers.

The SmartBars mobile app is free. For Apple smart devices, click here or search “SmartBars” in iTunes. For Google smart devices, click here or search “SmartBars” in Google Play.

Please contact me if you are interested in consuming the Price Comparison and Coupons Web API for your own mobile apps or site.

OOP, FP and OD

Introduction

After decades of object-oriented programming (OOP), it is still a mainstream programming paradigm in software development. However, there are other programming paradigms, namely, functional programming (FP) and object decoration (OD). In this article, I discuss how the OOP can be benefited from them.

OOP Challenges

Over the course of advancements of OOP, we have gotten to know it better for both its strength and weakness, and have more choices to address problems that OOP has been facing. There are a few challenges with OOP, i.e., dependency, extensibility and mutability.

Dependency

Dependency or coupling is the degree to which a software module relies on other modules. Whenever a class A uses another class or interface B, then A depends on B. A cannot carry out its work without B. Generally, interface dependency (loose coupling) is preferable over class dependency (tight coupling). Interface dependency is often desirable since it provides an abstract contract for client to follow without knowing the implementation details. On the other hand, class dependency is the root of all evil. It makes a system implementation-dependent and therefore difficult to change. Although it is possible to design a software system loosely-coupled initially, the challenge is how to keep it loosely-coupled while adding more functionality.

Extensibility

To add more functionality, you need to extend an existing software system. You can modify existing classes, or use inheritance, composition and design patterns to address changes. In general, you should choose composition over inheritance. Design patterns are often employed to solve common design problems for a complicate system while the use of them makes the system even more complicate. And they all need class design. The need of class design is a significant limit of OOP. It may break existing class dependencies or create new class dependencies, and needs significant compilation, testing and deployment efforts. The challenge for extensibility is how to avoid class design while adding more functionality.

Mutability

The result of an object operation depends on not only the arguments that are input to the operation but also the state of the executing program. It makes difficult to predict the behaviors of a software system. Although a certain degree of mutability may be inevitable, it is desired to avoid object mutability in object operations. The challenge is how to extend a software system without altering object state in object operations.

Solutions

The above challenges cannot be resolved effectively by OOP itself. In the following sections, I discuss how to address these challenges by combining technologies in OOP with other paradigms like functional programming and object decoration.

Programming to interface

By following Dependency Inversion Principle and using an IoC container, you can start programming to interfaces exposed by objects instantiated from the IoC container. Assuming that class Employee implements interface IEmployee, the following code registers the Employee class to UnityContainer with the IEmployee.

IUnityContainer unityContainer = new UnityContainer();
unityContainer.RegisterType<IEmployee, Employee>(new InjectionConstructor());

Now, you can ask the unityContainer for an Employee object by specifying the interface IEmployee as follows.

IEmployee e = unityContainer.Resolve<IEmployee>();

The rest of your program can start using the interface e without knowing it is an object of Employee class. Later on, let’s say you have a new class Employee2, which also implements the interface IEmployee. To replace Employee with Employee2, just modify the line of registering code as follows.

unityContainer.RegisterType<IEmployee, Employee2>(new InjectionConstructor());

Now, your program starts to use the new class Employee2. It makes component replacement extremely easy.

impromptu-interface: IoC containers are convenient if you know a class has implemented an interface. What about a class that doesn’t implement an interface? Of course, you can not program to interface since it simply doesn’t have interface to program. But wait! You can use impromptu-interface. With the impromptu-interface, any object can be wrapped with an interface. Say, you have a class Order defined as follows.

public class Order 
{
    public int OrderID { get; set; }
    public int CustomerID { get; set; }
    public DateTime DueDate { get; set; }
    public string AccountNumber { get; set; }
    public int ContactID { get; set; }
    public int BillToAddressID { get; set; }
    public int ShipToAddressID { get; set; }
    public int ShipMethodID { get; set; }
    public double SubTotal { get; set; }
    public double TaxAmt { get; set; }
    public SqlCommand Command { get; set; }

    public int InsertOrder()
    {
        //Code omitted.
        return 0;
    }
}

To use impromptu-interface, you need to define an interface first. Let’s say you want all methods of the class be interface methods. You define the interface as follows.

public interface IOrder
{
    int OrderID { get; set; }
    int CustomerID { get; set; }
    DateTime DueDate { get; set; }
    string AccountNumber { get; set; }
    int ContactID { get; set; }
    int BillToAddressID { get; set; }
    int ShipToAddressID { get; set; }
    int ShipMethodID { get; set; }
    double SubTotal { get; set; }
    double TaxAmt { get; set; }
    SqlCommand Command { get; set; }

    int InsertOrder();
}

Then, you use the following code to instantiate an Order object and wrap it in the interface IOrder.

IOrder iOrder = new Order().ActLike<IOrder>();

Now, you can use the interface iOrder in your program.

With impromptu-interface, interface can be designed after class design. You design your classes with or without interfaces. Remember an interface is a service contract to clients of a component. Sometimes, it is not clear what service contract a component should provide during design of business classes. At some other times, it seems making perfect sense to design a class without interface. Impromptu-interface gives clients of business classes the flexibility to wrap an object in an interface. After all, it is the client that knows what services it needs, not the other way around. Impromptu-interface makes possible program to interface as needed.

Object Decoration

Programming to interface is great for creation of a loosely-coupled software system in terms of use of existing functionality of business classes. Now, what about adding extra functionality? Of course, you can modify the existing classes or create new classes. But wait! You are modifying the existing class dependencies or creating new class dependencies. You should avoid doing this whenever possible.

So, what is the other option then? The answer is object decoration (OD). OD attaches extra behaviors to an existing object. The following code adds entering log and exiting log to the method InsertOrder of the object iOrder.

iOrder = ObjectProxyFactory.CreateProxy2<IOrder>(
    iOrder,
    new string[] { "InsertOrder" },
    new Decoration2((x, y) => { System.Console.WriteLine("Enter"); }, null),
    new Decoration2((x, y) => { System.Console.WriteLine("Exit"); }, null)
);

Now, the following code writes entering log, then, inserts an order, and last, writes exiting log.

iOrder.InsertOrder();

Here are a few interesting points regarding OD:

  • It is client-side programming (no class modifications or creations).
  • It works with object and object’s interface methods (programming to interface).
  • It is functional programming (behaviors are functions).

OD extends software by avoiding class design and therefore not changing/adding dependencies of a software system. Functions as behaviors means not increasing mutability of a software system. It is a simple yet very powerful approach for software extensibility. To see how logging, security checking and sorting are added to objects using OD, click here. To see how transaction is added to objects using OD, click here.

Conclusions

Both programming to interface and object decoration emphasize on client-side programming and are independent of server-side implementation.

Impromptu-interface makes possible programming to interface as needed.

Object decoration makes possible adding behaviors as needed.

Programming to interface with object decoration solves dependency, extensibility and mutability of OOP effectively. It makes possible a loosely-coupled system all the way through its life cycle.

Programming to interface and object decoration reduce class design but do not get rid of class design. You still need to design a business class if existing ones do not meet business requiremements. The key point here is that once a business class is designed appropriately, you should keep it from changes. The programming to interface and object decoration help to achieve this.

Object Decoration is Functional Programming

Functional Programming (FP) makes easy to add new operations on existing things (types and objects). This can be accomplished by adding new functions which compute with existing types. You can do functional programming in C# using lambda expression.

Object Decoration (OD) attaches behaviors to object. Using OD, you define behaviors as functions and attach them to existing objects. Here is an example to show how it is done using ObjectProxyFactory.CreateProxy of CBO Extender.

doAThing = ObjectProxyFactory.CreateProxy2<IDoAnything>(
    doAThing,
    new string[] { "DoThing" },
    new Decoration2(SayHello, null),
    new Decoration2(SayBye, null)
);

Here, you specify an object doAThing as the first argument, then, its method DoThing, the preprocessing behavior SayHello and the postprocessing behavior SayBye. All it says is that I want to add behavior SayHello before, and behavior SayBye after, the method DoThing of the object doAThing. That call returns a proxy of the original object. Then, you can use the proxy as if it was the original object. Now, the code

doAThing.DoThing();

executes SayHello first, then the actual method DoThing, and last SayBye.

For this example, the SayHello and SayBye are defined as static methods as follows.

public static void SayHello(AspectContext2 ctx, dynamic parameters)
{
    System.Console.WriteLine("Hello!");
}

public static void SayBye(AspectContext2 ctx, dynamic parameters)
{
    System.Console.WriteLine("Bye!");
}

You can also use lambda expressions in place of SayHello and SayBye in the call ObjectProxyFactory.CreateProxy. Here, the call is rewritten using lambda expressions as follows.

doAThing = ObjectProxyFactory.CreateProxy2<IDoAnything>(
    doAThing,
    new string[] { "DoThing" },
    new Decoration2((x, y) => { System.Console.WriteLine("Hello!"); }, null),
    new Decoration2((x, y) => { System.Console.WriteLine("Bye!"); }, null)
);

The complete code is listed as follows.

using CBOExtender;

namespace HelloWorld
{
    public interface IDoAnything {
        void DoThing();
    }

    public class DoAnything : IDoAnything {
        public void DoThing() { }
    }

    class Program
    {
        static void Main(string[] args)
        {
            IDoAnything doAThing = new DoAnything();

            doAThing = ObjectProxyFactory.CreateProxy2<IDoAnything>(
                doAThing,
                new string[] { "DoThing" },
                new Decoration2((x, y) => { System.Console.WriteLine("Hello!"); }, null),
                new Decoration2((x, y) => { System.Console.WriteLine("Bye!"); }, null)
            );

            doAThing.DoThing();
        }
    }
}

As you can see, it is extremely easy to add behaviors to an existing object. All you need to do is provide a function (lambda expresseion).

Using this approach, cross-cutting concerns and special business functionality can be added to existing objects conveniently. Please follow the links for examples of adding various behaviors to objects.

To see how logging, security checking and sorting are added to objects, click here.

To see how transaction is added to objects, click here.

Tame Application Flexibility By Loose Coupling With Object Decoration

When talking about application flexibility, the first thing you would think of probably is dynamic typing. However, dynamic typing is evil in a way that it is too flexible to maintain correctness, safety and predictability. Defensive coding and testing may alleviate the issues to some degree. But, how much defensive code is enough? How many tests are enough? The answers are probably “never enough” or “don’t know”. Plus, defensive code is ugly!

Static typing is evil in the opposite way that it is too inflexible to adapt to changes. Static typing is infamous in its rigidity and inflexibility to changes. That should not be the case, though! With loose coupling and object decoration, static typing is readily adaptive to changes.

Loose coupling is not new and is a great idea coming out of static typing. But for some reason, it has been underused. A system initially loosely-coupled is often quickly turned into tightly-coupled due to lack of follow-throughs to support it (mentally or technologically). With the advent of object decoration, behaviors can be added at runtime to a loosely-coupled system. Loose coupling forms a basis for adding dynamic behaviors – behaviors at runtime, which effectively make a software system adapt to changes. Vice versa, putting changes in dynamic behaviors makes a software system remain loosely-coupled. Object decoration technologically makes loose coupling possible over the course of evolving of a software system.

Loose coupling is based on interface, with which a client does not need to know about the inner workings of a component in order to make use of it. By programming to interface, the client is completely decoupled from the implementation of a component. Consequently, a component can replace another (at design time or runtime) as long as the successor component implements the same interface as the initial component without breaking the system in which the component operates.

Here is how loose coupling with object decoration adapts to changes. As new requirements come in, dynamic behaviors are created for them. The dynamic behaviors are, then, attached to methods of interface at runtime as needed. There is no need to modify the existing components. It is pure client-side coding.

In case of a new release of components, they can be just dropped into the client application as long as they keep their interfaces. The client application gets the new features of the components automatically.

This way, the client evolving and component enhancement are completely separated. And best of all, the system stays loosely-coupled. With the support of dynamic behaviors, it is possible to design a truly loosely-coupled software system. In the end, the loose coupling is not just an ideal, it is a reality.

Now it is time to mentally get ready for design of loosely-coupled system. Actually, loosely-coupled design is very simple. You design client contract (interfaces), implement them in your components, and program to these interfaces in client application, then, add extra behaviors at runtime with object decoration as needed based on requirements or changes of requirements. That’s it.

The important point here is add behaviors at runtime with object decoration instead of adding behaviors at design time with classes. That is the reason why a loosely-coupled system can stay loosely-coupled. Furthermore, why do you need class if method (dynamic behavior is method) can solve the problem? And, remember that some dynamic typing languages live without class!

As final notes, I would like to say a few words on flexibility. By now, you would agree that flexibility is possible with both static typing and dynamic typing in terms of adding behaviors at runtime. However, the mechanism used by static typing is different from dynamic typing. In static typing, the flexibility is achieved by loose coupling with object decoration, therefore, safe and predictable. On the other hand, the flexibility in dynamic typing is achieved by altering object types, therefore, unsafe and unpredictable.

Object Decoration – Solution to Runtime Behaviors for Compiled Languages

Compiled languages have been criticized for their inability to addding behaviors at runtime as their counterpart – interpreted languages – does. That should not be the case. With object decoration, behaviors can be added to objects at runtime in compiled languages. It is a simple yet powerful way for software extensibility. It complements class-based programming of compiled languages and has advantages over dynamic typing of interpreted languages.

Thinking in Object Decoration

Object decoration means attaching extra behaviors to an object. Here is the idea: You have an object whose methods perform defined behaviors. Now, you want some extra behaviors before or after the execution of methods. So, you attach the extra behaviors to the methods by decoration so that when invoking the methods at runtime the attached behaviors are executed before or after.

Once you get the idea, decoration itself is straightforward. At the very basic, you need to specify an object, method(s) of the object, extra behavior(s) and placements of the extra behavior(s) (before or after). All these are done in one call as follows.

doAThing = ObjectProxyFactory.CreateProxy2<IDoAnything>(
    doAThing,
    new string[] { "DoThing" },
    new Decoration2(SayHello, null),
    new Decoration2(SayBye, null)
);

Here, you specify an object doAThing as the first argument, then, its method DoThing, the preprocessing (before) behavior SayHello and the postprocessing (after) behavior SayBye. All it says is that I want to add behavior SayHello before and behavior SayBye after the method DoThing of the object doAThing. That call returns a proxy of the original object. Then, you can use the proxy as if it was the original object. Now, the code

doAThing.DoThing();

executes SayHello first, then the actual method DoThing, and last SayBye.

The complete code is listed as follows.

using CBOExtender;

namespace HelloWorld
{
    public interface IDoAnything {
        void DoThing();
    }

    public class DoAnything : IDoAnything {
        public void DoThing() { }
    }

    class Program
    {
        static void Main(string[] args)
        {
            IDoAnything doAThing = new DoAnything();

            doAThing = ObjectProxyFactory.CreateProxy2<IDoAnything>(
                doAThing,
                new string[] { "DoThing" },
                new Decoration2(SayHello, null),
                new Decoration2(SayBye, null)
            );

            doAThing.DoThing();
        }

        public static void SayHello(AspectContext2 ctx, dynamic parameters)
        {
            System.Console.WriteLine("Hello!");
        }

        public static void SayBye(AspectContext2 ctx, dynamic parameters)
        {
            System.Console.WriteLine("Bye!");
        }
    }
}

More Information

To download CBOExtender, use NuGet from inside Visual Studio 10 by searching CBOExtender, or click here.

To see how logging, security checking and sorting are added to objects as extra behaviors at runtime by decoration, click here.

To see how transaction is added to objects as extra behaviors at runtime by decoration, click here.

To see how object decoration is different from dynamic typing, click here.

To see all my articles and blogs, click here.

Dynamic Behaviors Or Dynamic Typing

Everybody knows that dynamic typing offers dynamic behaviors (runtime behaviors). It is little known that static typing can offer dynamic behaviors, too. With the advent of Component-Based Object Extender (CBO Extender), an object extensibility framework for .NET, behaviors can be added to objects at runtime.

It is good news for .NET developers or maybe for all developers using static programming languages. However, with this option, it becomes more complicate to decide on using a static programming language or a dynamic programming language for your development. Here, I try to discuss the differences between static typing and dynamic typing in terms of dynamic behaviors, and hope it will make the decision process a little easier.

Dynamic Behaviors With Dynamic Typing

There are two kinds of dynamic typing: prototype-based programming and class-based programming. In prototype-based programming classes are not present, and behavior reuse is performed via a process of cloning existing objects that serve as prototypes. Javascript is an example using prototype-based programming. In class-based programming a class is defined prior to an object is created out of it and used. Ruby is an example using class-based programming.

Regardless of using objects only or both classes and objects, dynamic behaviors are achieved by changing object types, i.e., adding, deleting or altering methods of object or class without a validation step (compilation). A dynamic behavior is resolved to a method of object at runtime.

Dynamic Behaviors With Static Typing

Static typing is class-based programming with a validation step (compilation). Prior to .NET 4, C# is a static typing language. Now, it is mixed with both dynamic typing and static typing. It still needs compilation step with intentionally omitting validation of certain types.

Unlike dynamic typing, in static typing dynamic behaviors are achieved by decorating methods of object without changing object types. A dynamic behavior is resolved to a decorator, which itself is a method independent of the decorated object.

Comparison of Dynamic Behavior between Dynamic Typing and Static Typing

First, let’s use an example to see how dynamic behaviors are achieved in dynamic typing and static typing. In the following sections, a Hello World! application is written using dynamic behaviors with three programming languages: Javacript, Ruby and C#.

Dynamic Behaviors in Javascript.

The following code is written using Javascript.

function doAnything() {
}

doIt = new doAnything();
doIt.hello = function () {
    alert("Hello!");
}

doIt.bye = function () {
    alert("Bye!");
}

//doIt.bye = function () {
//    alert("Not bye yet!");
//}

doIt.hello();

//delete doIt['bye'];

doIt.bye();

The doAnything function is empty, which is used to create doIt object. The, two properties, hello and bye are added to doIt. Last, the doIt.hello(); and doIt.bye(); are called to output “Hello!” and “Bye!”.

Note that the behaviors of doIt object can be changed anytime by adding, removing or altering its properties.

By uncommenting the code

//doIt.bye = function () {
//    alert("Not bye yet!");
//}

the output will be “Hello!” and “Not bye yet!”.

By uncommenting the code //delete doIt['bye']; you get a runtime error.

Imagine that in a big project these lines of code are buried deeply inside dozens of files with multiple million lines of code. You’re screwed! It is too flexible to be safe and predictable.

Dynamic Behaviors in Ruby

The same example is rewritten in Ruby as follows.

class DoAnything
end

class DoAnything
    def Hello
    	puts "Hello!"
    end

    def Bye
    	puts "Bye!"
    end
end

#class DoAnything
#    def Bye
#    	puts "Not Bye Yet!"
#    end
#end

doIt = DoAnything.new

doIt.Hello

#def doIt.Bye
#    puts "Bye from instance"
#end

#class << doIt
#    remove_method(:Bye)
#end 

doIt.Bye

The above code outputs “Hello!” and “Bye!”.

By uncommenting the code

#class DoAnything
#    def Bye
#    	puts "Not Bye Yet!"
#    end
#end

the output will be “Hello!” and “Not bye yet!”.

By uncommenting the code

#def doIt.Bye
#    puts "Bye from instance"
#end

the output will be “Hello!” and “Bye from instance”.

By uncommenting the code

#class << doIt
#    remove_method(:Bye)
#end

the output will be “Hello!” and “Not bye yet!”.

It suffers from the same problems as Javascript: too flexible to be safe and predictable!

Dynamic Behaviors in C#

The example is rewritten using C# as follows.

using CBOExtender;

namespace HelloWorld
{
    public interface IDoAnything {
        void DoThing();
    }

    public class DoAnything : IDoAnything {
        public void DoThing() { }
    }

    class Program
    {
        static void Main(string[] args)
        {
            IDoAnything doAThing = new DoAnything();

            doAThing = ObjectProxyFactory.CreateProxy2<IDoAnything>(
                doAThing,
                new string[] { "DoThing" },
                new Decoration2(SayHello, null),
                new Decoration2(SayBye, null)
            );

            doAThing.DoThing();
        }

        public static void SayHello(AspectContext2 ctx, dynamic parameters)
        {
            System.Console.WriteLine("Hello!");
        }

        public static void SayBye(AspectContext2 ctx, dynamic parameters)
        {
            System.Console.WriteLine("Bye!");
        }
    }
}

The code

doAThing = ObjectProxyFactory.CreateProxy2<IDoAnything>(
    doAThing,
    new string[] { "DoThing" },
    new Decoration2(SayHello, null),
    new Decoration2(SayBye, null)
);

decorates the original object and returns a proxy of it. The above code outputs “Hello!” and “Bye!”.

Dynamic decorating retains object types in terms of interface instead of implementation and does not change original object behaviors. It just attaches extra behaviors to object. Therefore, it is type-safe and predictable. It is flexible in a way of loosely-coupling not in a way of dynamic typing.

In summary,

  • Both dynamic programing languages and static programming languages can have dynamic behaviors;
  • Dynamic programing languages achieves dynamic behaviors by dynamic typing while static programming languages achieves dynamic behaviors by dynamic decorating;
  • Dynamic decorating retains types of object and its functionality, and is safe and predictable while dynamic typing alters types of object and its functionality, and is unsafe and unpredictable.

Conclusions

It is safe to say that applications except most trivial ones benefit from dynamic behaviors, but not every application needs dynamic typing.

If you need dynamic behaviors, and type-safety and predictability is important, you should choose .NET with dynamic decorating. If you need dynamic behaviors, and type-safety and predictability is not important, you can choose dynamic typing.

At this time, dynamic decorating supports only .NET.