What is Domain Specific Language (DSL)?

Introduction: Any programming language is intended to take you so far to solve real world problems. Object oriented language like C# or JAVA is directed to create applications that, solves problems using the generic syntax, allowing one to build components / classes that solves the business problem. DSL on the other hand empowers to develop a layer through quasi syntax (and its corresponding semantics) that solves the business domain problems.

Definition: In essence, DSL is a meta-programming approach (business centered specific programming on top of conventional programming language) that develops a layer of domain specific syntax/components which can be, invoked typically over command line or structured textually through syntax or structured graphically, and hence interpreted through a custom parser. This facilitates a conventional programming language to extend and solve a specific business problem at hand.

Essential: There is an urgent need to build a repository of DSL for any business domain which inherently abstracts the repeating miniscule problems and allows one to flexibly weave the DSL components making it powerful, reusable, well tested over time and extensible.

Popular Examples:

                >UNIX’s command line (grep/awk/sed) entities that allow one to solve recurring everyday programming problems of data manipulation and can be invoked through scripts and command line.

                >HTML is by itself a configuration (textual/xml) based DSL that allows to solve the rendering hypertext over browsers.

                >CSS is another meta-programming language that allows specifying styles for its kin HTML.

Challenges: There is clearly an overhead in building a foundation of DSL components with economical syntax that greedily solves the business problem at hand.

Note: There are scores of books devoted for DSL running to 100s of pages. But I have made a sincere attempt to capture my understanding both from the theory I have read and practical coding experience.

IOC/DI – From a Manager’s perspective.

Another short departure from the inner urges of design guru is what resulted in this blog post about Inversion of Control (IOC)/Dependency Injection (DI). I have decided to switch between technical and design oriented topics in my blog post from this point.

The reason why I put the word “Manager” in the topic is to stave off from technical nitty-gritty details like reflection etc. (internet is awash with such articles of that nature), rather get into the higher purpose and object oriented motivation behind the IOC/DI.

What is IOC/DI?

Predominantly software systems’ implements, a flow of control from the top to bottom or higher level module to lower level module. A simple real world example can throw some light: Let’s take a Car class instance and, Car class determines the composed object instances (like Engine, Door etc.,) life time and scope. This principle is called composition  in object oriented world. And in parallel to composition, there is a similar principle, called as aggregation. 

Aggregation is where the passengers can come and go but passenger outlives the car. But the engine cannot outlive the car. Also within the context of car, passenger (which is typically a polymorphic interface) is injected through the constructor of a car class. This way, again, within the context of the class, there is a dynamism introduced and this dynamic state behavior which is practically controlled by an external entity, which here happens to be a low level module, can be broadly described as inverting the flow of control. Now we have justified the word “IOC”. “Dependency Injection” (DI) can be justified by claiming that the passenger code is being injected from an external entity.

Why IOC/DI?  - 

This principle allows the lower level module to control the behavior and state of the class dynamically without changing the existing piece of code. This way it honors the Open/Closed Principle.