Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch3 S30 SK

2010-10-13T15:14:19Z

Sumi2509: /* Delegation */

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

==Introduction==

Object oriented programming (OOP) paradigm is based upon what is known as "objects", which represent real world concepts. One of the principal advantages of object-oriented programming over procedural programming is that they enable programmers to create modules that do not need to be changed when a new type of object is added.
Some basic concepts/features which are part of OOP are classes, methods, instances, encapsulation, inheritance, message forwarding, decomposition, delegation etc. This article discusses four of these concepts, namely, inheritance, message forwarding, decomposition and delegation. Specifically, comparison between inheritance and message forwarding, decomposition & delegation is made to understand when each of these can be considered as a potential alternative for inheritance, which forms core of OOP.

==Elements of OOP==

Some of the elements of OOP, relevant to the topic are discussed below

===Inheritance===

In OOP, inheritance is a way to compartmentalize the code by creating objects which are based on previously created objects. In classical inheritance where objects are defined by classes, parent class is known as super class and the one which inherits behavior is known as sub class. Inheritance is used to relate two or more objects to each other. With the use of inheritance, methods and instance variables of the parent object are available for use in all of its child objects.
[[Image:Inheritance.jpg|frame|center|Inheritance Hierarchy]]

In the above example, student and teacher both inherit characters from Person object and Teaching Assistant inherits characteristics from both Teacher and Student and indirectly from Person.

===Decomposition===

Decomposition, also known as factoring is the process by which a big, complex problem is broken into smaller problems which are easier to attack, conceive and manage. Object Oriented Decomposition breaks large problem domain, based on classification entities, into smaller objects which represents some part of the problem. Object oriented decomposition works especially fine due to the concept of procedural abstraction which makes a problem easier to solve. Object-oriented decomposition results in a product that is more reusable.

For example, we could have an object referring to Drawer which supports addition of information and an object Letter which supports retrieval of content. In this case, a bigger problem domain (Drawer) refers to an object (Letter) which handles smaller problem domain. The fact that Drawer can have many letters makes decomposition relation of type "has a".

[[Image:Decomposition.jpg|frame|center|Decomposition]]

In the above example, Drawer object holds an instance variable which refers to Letter object. The bigger problem domain of "Drawer" has now been divided into smaller problem domains, one of which is Letter. Letter behavior is easier to maintain as compared to Drawer and any change in Drawer behavior will not affect Letter's behavior. Moreover, Letter object can be part of some other big problem domain also(except that of Drawer).

===Message Forwarding===

Message Forwarding, also known as interfacing, describes the communication between objects using their public interfaces. Using message forwarding, objects can send and receive messages from each other, which help them to synchronize. Message passing is done using methods, properties and events. Message forwarding using method involves invoking an operation on an object. In response to the message the corresponding method is executed in the object and object may return some values. Message forwarding using property allows object to advertise and allow change in their state information. Events are raised by the objects in response to an internal action. Other objects can subscribe to these so that they can react to an occurrence of the event. An example for vehicles could be an 'ImpactDetected' event subscribed to by one or more 'AirBag' objects.

In some object-oriented programming languages, a message is the means to pass control to an object and if the object responds to the message, which means it has some way to handle that message. In pure object-oriented programming, message passing is performed exclusively through a dynamic dispatch strategy (process of mapping a message to a specific sequence of code at runtime.). Message forwarding techniques for communication between objects makes the interface descriptions with external systems much simpler.

Java employs message forwarding in the form of message calling. Objective C and Smalltalk heavily rely of message passing and use message sending instead of message calling.

As an example for message forwarding, when the object called "joe" (an instance of the driver class), presses the gas pedal, he literally passes an accelerate message to object "my Porsche", which in turn, invokes the "my Porsche" accelerate method.

[[Image:MessagePassing.jpg|frame|center|Message Forwarding]]
Image taken from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

===Delegation===

Delegation allows the behavior of an object to be defined in terms of the other object and can be viewed as a relationship between objects where one object forwards certain method calls to another object, called its delegate. In OOP, two notions of delegation exist. The older usage refers to passing on the execution to some other object. While new usage refers to using method lookup rules to dispatch so-called self-calls as defined by Lieberman in his 1986 paper "Using Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems".

Example for old definition:

Suppose there are class A and B defined as follows:

class A
{
public:
foo()
{
print("Object A doing the job");
}
}
class B
{
public:
A a;
foo()
{
a.foo();
}
}

Here class B calls A's foo method delegating the execution of its function foo to an object of class A. This example clearly explains how delegation works in most of the programming languages.

Example of new definition:

class A
{
foo() {
self.bar() // self is also known under the names "current" and "this" in other languages
}
bar() {
print("a.bar")
}
}
class B
{
delegationlink A a
foo() {
a.foo() // call foo() on the a-instance
}
bar() {
print("b.bar")
}
}
a = new A()
b = new B(a) // establish delegation between two objects

calling b.foo() will result in b.bar to be printed. Older definition would have resulted in a.bar.

Example taken from http://www.wordiq.com/definition/Delegation_(programming)

It should be noted that delegation as new definition is not widely supported in programming languages, though exceptions exist in the form of the languages Self and Kniesels Lava.

Delegation is based on dynamic binding, as it require that a given method call can invoke different segments of code at runtime. Delegation forms the core of design patterns like wrapper design pattern.

==Comparing Inheritance with Others==

As discussed above, inheritance forms a basic way to compartmentalize and code reuse in object oriented programming. However in some cases, inheritance may not be the best way to approach the problem. Some of the limitations of inheritance are:

* When single inheritance is used, an object can only inherit from a single object. If in the above given inheritance example, single inheritance is used Teaching assistant can either be student or a teacher but not both. Using multiple inheritance solves the problem (as in above example), but it can still inherit from each super class only once and hence a Teaching assistant cannot be a student at two different institutions. Also, multiple inheritance creates problem when a same trait is inherited from two different parents.

* Inheritance hierarchy for an object is fixed at the time of instantiation and cannot be changed. In the above example, Student object cannot change to Teacher while retaining characteristics of an Employee. Hence inheritance locks the original design which becomes difficult to change.

* When any client has access of any of the subclass, it automatically has access to the data which is part of the super class, even if data is private to the parent class. E.g in above example, access to student class gives an access of person class and can lead to unwarranted change of Person class properties.

Hence, it can be said that inheritance is not always a good approach for all the problems and some of the elements of OOP discussed above can be good alternatives for inheritance.

===Decomposition and Inheritance===

Traditionally, inheritance is used when there is a "is a" relationship between objects and decomposition when there is "has a" relationship between objects. An example of inheritance where "Programmer" and "Manager" extend "Employee" (is a relationship) can also be looked as, "Programmer" as a set of duties that an "Employee" may have, and this same employee may later change duties for "Manager" duties (has a relationship). Hence the way we design our system makes decomposition or inheritance favorable. But as a rule of thumb, object oriented design based on decomposition is more stable when parent objects are likely to change. In our decomposition example considered above, even if drawer functionality and role change drastically basic participants (letter object in this case) are likely to remain same and can be used in some other domain also. Hence, decomposition is used when there is lot of code reuse and/or polymorphism. By separating behaviors from the primary class hierarchy and including specific behavior for the child class, child class is not restricted by behavior of its ancestral classes.
Inheritance should be preferred when there is significant interaction between parent and its child classes. If parent must call back to child methods, then inheritance is usually the good answer. As an example, consider a class apple which inherits from its super class Fruit. Any change in the behavior of fruit will directly effect Orange which "is a" type of fruit. When super class and its subclasses are meant to be tied together inheritance should be used as it allows us to take advantage of dynamic binding and polymorphism.

===Message Passing and Inheritance===

Object oriented programs generally have two kinds of structures; one style is to have an inheritance hierarchy. The other is to have a pattern of message passing. Inheritance structure represents how different objects are related by their types. For example, in the program that models water use, Faucets and WaterPipes can be modeled as same kind of objects, except that Faucets can be turned on and off and WaterPipes can have multiple connections to other WaterPipes. Thus Faucet and WaterPipe objects can inherit from a common antecedent with all common traits and will have their specific properties in their classes.
Message passing structure represents how program works. For example, in the above mentioned program for water use, Appliance objects might send messages requesting water to Valves, and Valves to WaterPipes. The Building object can communicate through messages with all the Valves, Faucets, and WaterPipes, but not directly with Appliances. The connection between different objects which know whom to contact and pass message defines program structure.
[Example taken from: http://objc.toodarkpark.net/oop.html ]

There are situations where inheritance structure for the program may not work well. For example, consider an object Room which defines characteristics for the room. Room can be cubiod in shape so Object Room can inherit characteristics from Cuboid Object. However problem arise when different Rooms can have different shapes say cylindrical. Inheriting from both Cubiod and Cylindrical Objects will make Room both cylindrical and cubiod, instead of being cylindrical or cubiod in shape. Hence inheritance would not work here. A better way would be to have separate objects Shape and Room and shape object points to Cubiod or Cylindrical object. A Room object can interact with object Shape by passing messages. In this design approach access to all of other object facilities is not granted, instead an object needs to pass messages to access attributes and operations of the other class. Thus message passing exposes only the required interface of the object.

===Delegation and Inheritance===

Delegation is closely related to message forwarding and as discussed in above section, just like message forwarding and inheritance, there can be two kinds of structures for programs involving inheritance and delegation. Delegation supports the prototype-based programming model and inheritance, class based programming model. Inheritance schemes involve two kinds of objects, classes and instances. A class defines what is known as structure of its instances. Each instance maintains its values of attributes defined in the structure and the state of an object is given by the values of its attributes at any point in time. In delegation, there is only one type of object which represents real-world items. These objects are often taken to be “instances without classes.” This independence of all objects in delegation scheme allows delegation to capture the behavior of inheritance to some extent.

When it comes to building large systems with many objects, using an inheritance based system seems to make more sense. This is due to the fact that inheritance based system forces programmer to think and place some common behavior in super classes. In delegation based system, common behavior can be put in a single class, but this results in dependencies between objects and changing one object might result in errors in another object which is delegating the job to the first object.

In the nutshell, following are the situations when using delegations over inheritance is beneficial:

* When an object can play more than one role in the system, then sub-classing is not advisable, as the numbers of combinations are very large. Delegation would result in fewer classes and work best in this case.
* Inheritance, as discussed before, is a static relationship. If a class inherits from another class, this relationship cannot be changed at run time. On the other hand, Delegation is a dynamic relationship that can be changed at runtime.
* If an object needs to hide a function or an attribute from its super-class, then it is not a right candidate for inheritance. Delegation is an appropriate solution for this situation.
* If there’s no control over the class which is being inherited, it is good to use delegation over inheritance as inheritance has the risk that classes may have to be changed due to changes in parent class over which there’s no control.
* Delegation, unlike Inheritance, doesn’t force an object to accept all the methods of the super class, an object can only provide those methods that really make sense.

However, delegation has certain disadvantages over inheritance

* Delegation results in large number of objects in memory, which could result in performance issue when the objects in memory grow fast due to inefficient handling or disposal of objects.
* Delegation results in code more difficult to read understand and debug. This is due to the fact that delegation involves certain level of object indirection.

==Conclusion==

OOP has many features which makes it a favorable option in many problem domains. However, based on the requirements of the application, what is needed are subtle design decisions about which feature of OOP should be given more importance. Inheritance based models seem a very attractive choice for almost all object oriented applications, which is not true. As discussed in this article, techniques like decomposition, delegation and message forwarding do compass better alternatives for inheritance for some object oriented applications. What is needed is a perspective to see which OOP concept would make object oriented design more efficient and robust.

==References==

[1] Thomas K¨uhne, A Functional Pattern System for Object-Oriented Design. Retrieved 4th October 2010, from http://homepages.mcs.vuw.ac.nz/~tk/fps/fps-sans-escher.pdf

[2] Composition vs Inheritance in Java. Retrieved 4 October 2010, from http://www.mapleshirefarm.com/eric/CompositionVsInheritance.html

[3] Inheritance versus composition: Which one should you choose, retrieved 4th October 2010, from http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=2

[4] Inheritance. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)

[5] Decomposition. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Decomposition_(computer_science)

[6] Object Oriented Programming Concepts, Retrieved 4th October 2010, from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

[7] Message Passing. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Message_passing

[8] Object Oriented Programming, Retrieved 4th October 2010, from http://objc.toodarkpark.net/oop.html

[9] Meilir Page-Jones, Larry L. Constantine, Fundamentals of object-oriented design in UML, Addison-Wesley Professional,1999

[10] Lynn Andrea Stein,Delegation is inheritance, in the proceedings of conference on Object Oriented Programming Systems Languages and Applications, (Orlando, Florida), ACM, 138 - 146 Year of Publication: 1987

[11] Delegation Definition. Retrieved 5th October from , http://www.wordiq.com/definition/Delegation_(programming)

[12] Manish Sharma, When Not to use Inheritance but Delegation. Retrieved 5th october 2010, from http://developergeeks.com/article/16/when-not-to-use-inheritance-but-delegation

[13] Peter Bosch, Inheritance vs. delegation: Is one better than the other? Unpublished. Retrieved 5th october 2010, from www.python.org/ftp/python/doc/delegation.ps

CSC/ECE 517 Fall 2010/ch1 S10 ms

2010-10-06T17:41:40Z

Sumi2509:

*[[CSC/ECE 517 Fall 2010/ch1 1a vc]]

*[[CSC/ECE 517 Fall 2010/ch1 1a br]]

*[[CSC/ECE 517 Fall 2010/ch1 1b mg]]

*[[CSC/ECE 517 Fall 2010/ch1 1c JF]]

*[[CSC/ECE 517 Fall 2010/ch1 1e az]]

*[[CSC/ECE 517 Fall 2010/ch1 1e bb]]

*[[CSC/ECE 517 Fall 2010/ch1 1f vn]]

*[[CSC/ECE 517 Fall 2010/ch2 2b dg]]

*[[CSC/ECE 517 Fall 2010/ch1 2e RI]]

*[[CSC/ECE 517 Fall 2010/ch1 S6 aa]]

*[[CSC/ECE 517 Fall 2010/ch1 S6 km]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 GP]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 MS]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 MM]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 PH]]

*[[CSC/ECE 517 Fall 2010/ch2 2a CB]]

*[[CSC/ECE 517 Fall 2010/ch2 2a mw]]

*[[CSC/ECE 517 Fall 2010/ch2 2c ck]]

*[[CSC/ECE 517 Fall 2010/ch2 S23 GP]]

*[[CSC/ECE 517 Fall 2010/ch2 S24 NS]]

*[[CSC/ECE 517 Fall 2010/ch2 S23 SS]]

*[[CSC/ECE 517 Fall 2010/ch2 S23 NR]]

*[[CSC/ECE 517 Fall 2010/ch2 S20 TT]]

*[[CSC/ECE 517 Fall 2010/ch2 2d AS]]

*[[CSC/ECE 517 Fall 2010/ch3 3j KS]]

*[[CSC/ECE 517 Fall 2010/ch2 S24 rm]]

*[[CSC/ECE 517 Fall 2010/ch3 3h PW]]

*[[CSC/ECE 517 Fall 2010/ch3 3e br]]

*[[CSC/ECE 517 Fall 2010/ch3 3h az]]

*[[CSC/ECE 517 Fall 2010/ch3 3i MM]]

*[[CSC/ECE 517 Fall 2010/ch3 S30 SK]]

CSC/ECE 517 Fall 2010/ch3 S30 SK

2010-10-06T17:40:21Z

Sumi2509: /* References */

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

==Introduction==

Object oriented programming (OOP) paradigm is based upon what is known as "objects", which represent real world concepts. One of the principal advantages of object-oriented programming over procedural programming is that they enable programmers to create modules that do not need to be changed when a new type of object is added.
Some basic concepts/features which are part of OOP are classes, methods, instances, encapsulation, inheritance, message forwarding, decomposition, delegation etc. This article discusses four of these concepts, namely, inheritance, message forwarding, decomposition and delegation. Specifically, comparison between inheritance and message forwarding, decomposition & delegation is made to understand when each of these can be considered as a potential alternative for inheritance, which forms core of OOP.

==Elements of OOP==

Some of the elements of OOP, relevant to the topic are discussed below

===Inheritance===

In OOP, inheritance is a way to compartmentalize the code by creating objects which are based on previously created objects. In classical inheritance where objects are defined by classes, parent class is known as super class and the one which inherits behavior is known as sub class. Inheritance is used to relate two or more objects to each other. With the use of inheritance, methods and instance variables of the parent object are available for use in all of its child objects.
[[Image:Inheritance.jpg|frame|center|Inheritance Hierarchy]]

In the above example, student and teacher both inherit characters from Person object and Teaching Assistant inherits characteristics from both Teacher and Student and indirectly from Person.

===Decomposition===

Decomposition, also known as factoring is the process by which a big, complex problem is broken into smaller problems which are easier to attack, conceive and manage. Object Oriented Decomposition breaks large problem domain, based on classification entities, into smaller objects which represents some part of the problem. Object oriented decomposition works especially fine due to the concept of procedural abstraction which makes a problem easier to solve. Object-oriented decomposition results in a product that is more reusable.

For example, we could have an object referring to Drawer which supports addition of information and an object Letter which supports retrieval of content. In this case, a bigger problem domain (Drawer) refers to an object (Letter) which handles smaller problem domain. The fact that Drawer can have many letters makes decomposition relation of type "has a".

[[Image:Decomposition.jpg|frame|center|Decomposition]]

In the above example, Drawer object holds an instance variable which refers to Letter object. The bigger problem domain of "Drawer" has now been divided into smaller problem domains, one of which is Letter. Letter behavior is easier to maintain as compared to Drawer and any change in Drawer behavior will not affect Letter's behavior. Moreover, Letter object can be part of some other big problem domain also(except that of Drawer).

===Message Forwarding===

Message Forwarding, also known as interfacing, describes the communication between objects using their public interfaces. Using message forwarding, objects can send and receive messages from each other, which help them to synchronize. Message passing is done using methods, properties and events. Message forwarding using method involves invoking an operation on an object. In response to the message the corresponding method is executed in the object and object may return some values. Message forwarding using property allows object to advertise and allow change in their state information. Events are raised by the objects in response to an internal action. Other objects can subscribe to these so that they can react to an occurrence of the event. An example for vehicles could be an 'ImpactDetected' event subscribed to by one or more 'AirBag' objects.

In some object-oriented programming languages, a message is the means to pass control to an object and if the object responds to the message, which means it has some way to handle that message. In pure object-oriented programming, message passing is performed exclusively through a dynamic dispatch strategy (process of mapping a message to a specific sequence of code at runtime.). Message forwarding techniques for communication between objects makes the interface descriptions with external systems much simpler.

Java employs message forwarding in the form of message calling. Objective C and Smalltalk heavily rely of message passing and use message sending instead of message calling.

As an example for message forwarding, when the object called "joe" (an instance of the driver class), presses the gas pedal, he literally passes an accelerate message to object "my Porsche", which in turn, invokes the "my Porsche" accelerate method.

[[Image:MessagePassing.jpg|frame|center|Message Forwarding]]
Image taken from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

===Delegation===

Delegation allows the behavior of an object to be defined in terms of the other object and can be viewed as a relationship between objects where one object forwards certain method calls to another object, called its delegate. In OOP, two notions of delegation exist. The older usage refers to passing on the execution to some other object. While new usage refers to using method lookup rules to dispatch so-called self-calls as defined by Lieberman in his 1986 paper "Using Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems".

Example for old definition:

Suppose there are class A and B defined as follows:

class A
{
public:
foo()
{
print("Object A doing the job");
}
}
class B
{
public:
A a;
foo()
{
a.foo();
}
}

Here class B delegates the execution of its function foo to an object of class A.

Example of new definition:

class A
{
foo() {
self.bar() // self is also known under the names "current" and "this" in other languages
}
bar() {
print("a.bar")
}
}
class B
{
delegationlink A a
foo() {
a.foo() // call foo() on the a-instance
}
bar() {
print("b.bar")
}
}
a = new A()
b = new B(a) // establish delegation between two objects

calling b.foo() will result in b.bar to be printed. Older definition would have resulted in a.bar.

Example taken from http://www.wordiq.com/definition/Delegation_(programming)

It should be noted that support for delegation as new definition is not widely supported in programming languages, though exceptions exists in the form of the languages Self and Kniesels Lava.

Delegation is based on dynamic binding, as it requires that a given method call can invoke different segments of code at runtime. Delegation forms the core of design patterns like wrapper design pattern.

==Comparing Inheritance with Others==

As discussed above, inheritance forms a basic way to compartmentalize and code reuse in object oriented programming. However in some cases, inheritance may not be the best way to approach the problem. Some of the limitations of inheritance are:

* When single inheritance is used, an object can only inherit from a single object. If in the above given inheritance example, single inheritance is used Teaching assistant can either be student or a teacher but not both. Using multiple inheritance solves the problem (as in above example), but it can still inherit from each super class only once and hence a Teaching assistant cannot be a student at two different institutions. Also, multiple inheritance creates problem when a same trait is inherited from two different parents.

* Inheritance hierarchy for an object is fixed at the time of instantiation and cannot be changed. In the above example, Student object cannot change to Teacher while retaining characteristics of an Employee. Hence inheritance locks the original design which becomes difficult to change.

* When any client has access of any of the subclass, it automatically has access to the data which is part of the super class, even if data is private to the parent class. E.g in above example, access to student class gives an access of person class and can lead to unwarranted change of Person class properties.

Hence, it can be said that inheritance is not always a good approach for all the problems and some of the elements of OOP discussed above can be good alternatives for inheritance.

===Decomposition and Inheritance===

Traditionally, inheritance is used when there is a "is a" relationship between objects and decomposition when there is "has a" relationship between objects. An example of inheritance where "Programmer" and "Manager" extend "Employee" (is a relationship) can also be looked as, "Programmer" as a set of duties that an "Employee" may have, and this same employee may later change duties for "Manager" duties (has a relationship). Hence the way we design our system makes decomposition or inheritance favorable. But as a rule of thumb, object oriented design based on decomposition is more stable when parent objects are likely to change. In our decomposition example considered above, even if drawer functionality and role change drastically basic participants (letter object in this case) are likely to remain same and can be used in some other domain also. Hence, decomposition is used when there is lot of code reuse and/or polymorphism. By separating behaviors from the primary class hierarchy and including specific behavior for the child class, child class is not restricted by behavior of its ancestral classes.
Inheritance should be preferred when there is significant interaction between parent and its child classes. If parent must call back to child methods, then inheritance is usually the good answer. As an example, consider a class apple which inherits from its super class Fruit. Any change in the behavior of fruit will directly effect Orange which "is a" type of fruit. When super class and its subclasses are meant to be tied together inheritance should be used as it allows us to take advantage of dynamic binding and polymorphism.

===Message Passing and Inheritance===

Object oriented programs generally have two kinds of structures; one style is to have an inheritance hierarchy. The other is to have a pattern of message passing. Inheritance structure represents how different objects are related by their types. For example, in the program that models water use, Faucets and WaterPipes can be modeled as same kind of objects, except that Faucets can be turned on and off and WaterPipes can have multiple connections to other WaterPipes. Thus Faucet and WaterPipe objects can inherit from a common antecedent with all common traits and will have their specific properties in their classes.
Message passing structure represents how program works. For example, in the above mentioned program for water use, Appliance objects might send messages requesting water to Valves, and Valves to WaterPipes. The Building object can communicate through messages with all the Valves, Faucets, and WaterPipes, but not directly with Appliances. The connection between different objects which know whom to contact and pass message defines program structure.
[Example taken from: http://objc.toodarkpark.net/oop.html ]

There are situations where inheritance structure for the program may not work well. For example, consider an object Room which defines characteristics for the room. Room can be cubiod in shape so Object Room can inherit characteristics from Cuboid Object. However problem arise when different Rooms can have different shapes say cylindrical. Inheriting from both Cubiod and Cylindrical Objects will make Room both cylindrical and cubiod, instead of being cylindrical or cubiod in shape. Hence inheritance would not work here. A better way would be to have separate objects Shape and Room and shape object points to Cubiod or Cylindrical object. A Room object can interact with object Shape by passing messages. In this design approach access to all of other object facilities is not granted, instead an object needs to pass messages to access attributes and operations of the other class. Thus message passing exposes only the required interface of the object.

===Delegation and Inheritance===

Delegation is closely related to message forwarding and as discussed in above section, just like message forwarding and inheritance, there can be two kinds of structures for programs involving inheritance and delegation. Delegation supports the prototype-based programming model and inheritance, class based programming model. Inheritance schemes involve two kinds of objects, classes and instances. A class defines what is known as structure of its instances. Each instance maintains its values of attributes defined in the structure and the state of an object is given by the values of its attributes at any point in time. In delegation, there is only one type of object which represents real-world items. These objects are often taken to be “instances without classes.” This independence of all objects in delegation scheme allows delegation to capture the behavior of inheritance to some extent.

When it comes to building large systems with many objects, using an inheritance based system seems to make more sense. This is due to the fact that inheritance based system forces programmer to think and place some common behavior in super classes. In delegation based system, common behavior can be put in a single class, but this results in dependencies between objects and changing one object might result in errors in another object which is delegating the job to the first object.

In the nutshell, following are the situations when using delegations over inheritance is beneficial:

* When an object can play more than one role in the system, then sub-classing is not advisable, as the numbers of combinations are very large. Delegation would result in fewer classes and work best in this case.
* Inheritance, as discussed before, is a static relationship. If a class inherits from another class, this relationship cannot be changed at run time. On the other hand, Delegation is a dynamic relationship that can be changed at runtime.
* If an object needs to hide a function or an attribute from its super-class, then it is not a right candidate for inheritance. Delegation is an appropriate solution for this situation.
* If there’s no control over the class which is being inherited, it is good to use delegation over inheritance as inheritance has the risk that classes may have to be changed due to changes in parent class over which there’s no control.
* Delegation, unlike Inheritance, doesn’t force an object to accept all the methods of the super class, an object can only provide those methods that really make sense.

However, delegation has certain disadvantages over inheritance

* Delegation results in large number of objects in memory, which could result in performance issue when the objects in memory grow fast due to inefficient handling or disposal of objects.
* Delegation results in code more difficult to read understand and debug. This is due to the fact that delegation involves certain level of object indirection.

==Conclusion==

OOP has many features which makes it a favorable option in many problem domains. However, based on the requirements of the application, what is needed are subtle design decisions about which feature of OOP should be given more importance. Inheritance based models seem a very attractive choice for almost all object oriented applications, which is not true. As discussed in this article, techniques like decomposition, delegation and message forwarding do compass better alternatives for inheritance for some object oriented applications. What is needed is a perspective to see which OOP concept would make object oriented design more efficient and robust.

==References==

[1] Thomas K¨uhne, A Functional Pattern System for Object-Oriented Design. Retrieved 4th October 2010, from http://homepages.mcs.vuw.ac.nz/~tk/fps/fps-sans-escher.pdf

[2] Composition vs Inheritance in Java. Retrieved 4 October 2010, from http://www.mapleshirefarm.com/eric/CompositionVsInheritance.html

[3] Inheritance versus composition: Which one should you choose, retrieved 4th October 2010, from http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=2

[4] Inheritance. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)

[5] Decomposition. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Decomposition_(computer_science)

[6] Object Oriented Programming Concepts, Retrieved 4th October 2010, from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

[7] Message Passing. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Message_passing

[8] Object Oriented Programming, Retrieved 4th October 2010, from http://objc.toodarkpark.net/oop.html

[9] Meilir Page-Jones, Larry L. Constantine, Fundamentals of object-oriented design in UML, Addison-Wesley Professional,1999

[10] Lynn Andrea Stein,Delegation is inheritance, in the proceedings of conference on Object Oriented Programming Systems Languages and Applications, (Orlando, Florida), ACM, 138 - 146 Year of Publication: 1987

[11] Delegation Definition. Retrieved 5th October from , http://www.wordiq.com/definition/Delegation_(programming)

[12] Manish Sharma, When Not to use Inheritance but Delegation. Retrieved 5th october 2010, from http://developergeeks.com/article/16/when-not-to-use-inheritance-but-delegation

[13] Peter Bosch, Inheritance vs. delegation: Is one better than the other? Unpublished. Retrieved 5th october 2010, from www.python.org/ftp/python/doc/delegation.ps

CSC/ECE 517 Fall 2010/ch3 S30 SK

2010-10-06T17:39:17Z

Sumi2509: /* References */

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

==Introduction==

Object oriented programming (OOP) paradigm is based upon what is known as "objects", which represent real world concepts. One of the principal advantages of object-oriented programming over procedural programming is that they enable programmers to create modules that do not need to be changed when a new type of object is added.
Some basic concepts/features which are part of OOP are classes, methods, instances, encapsulation, inheritance, message forwarding, decomposition, delegation etc. This article discusses four of these concepts, namely, inheritance, message forwarding, decomposition and delegation. Specifically, comparison between inheritance and message forwarding, decomposition & delegation is made to understand when each of these can be considered as a potential alternative for inheritance, which forms core of OOP.

==Elements of OOP==

Some of the elements of OOP, relevant to the topic are discussed below

===Inheritance===

In OOP, inheritance is a way to compartmentalize the code by creating objects which are based on previously created objects. In classical inheritance where objects are defined by classes, parent class is known as super class and the one which inherits behavior is known as sub class. Inheritance is used to relate two or more objects to each other. With the use of inheritance, methods and instance variables of the parent object are available for use in all of its child objects.
[[Image:Inheritance.jpg|frame|center|Inheritance Hierarchy]]

In the above example, student and teacher both inherit characters from Person object and Teaching Assistant inherits characteristics from both Teacher and Student and indirectly from Person.

===Decomposition===

Decomposition, also known as factoring is the process by which a big, complex problem is broken into smaller problems which are easier to attack, conceive and manage. Object Oriented Decomposition breaks large problem domain, based on classification entities, into smaller objects which represents some part of the problem. Object oriented decomposition works especially fine due to the concept of procedural abstraction which makes a problem easier to solve. Object-oriented decomposition results in a product that is more reusable.

For example, we could have an object referring to Drawer which supports addition of information and an object Letter which supports retrieval of content. In this case, a bigger problem domain (Drawer) refers to an object (Letter) which handles smaller problem domain. The fact that Drawer can have many letters makes decomposition relation of type "has a".

[[Image:Decomposition.jpg|frame|center|Decomposition]]

In the above example, Drawer object holds an instance variable which refers to Letter object. The bigger problem domain of "Drawer" has now been divided into smaller problem domains, one of which is Letter. Letter behavior is easier to maintain as compared to Drawer and any change in Drawer behavior will not affect Letter's behavior. Moreover, Letter object can be part of some other big problem domain also(except that of Drawer).

===Message Forwarding===

Message Forwarding, also known as interfacing, describes the communication between objects using their public interfaces. Using message forwarding, objects can send and receive messages from each other, which help them to synchronize. Message passing is done using methods, properties and events. Message forwarding using method involves invoking an operation on an object. In response to the message the corresponding method is executed in the object and object may return some values. Message forwarding using property allows object to advertise and allow change in their state information. Events are raised by the objects in response to an internal action. Other objects can subscribe to these so that they can react to an occurrence of the event. An example for vehicles could be an 'ImpactDetected' event subscribed to by one or more 'AirBag' objects.

In some object-oriented programming languages, a message is the means to pass control to an object and if the object responds to the message, which means it has some way to handle that message. In pure object-oriented programming, message passing is performed exclusively through a dynamic dispatch strategy (process of mapping a message to a specific sequence of code at runtime.). Message forwarding techniques for communication between objects makes the interface descriptions with external systems much simpler.

Java employs message forwarding in the form of message calling. Objective C and Smalltalk heavily rely of message passing and use message sending instead of message calling.

As an example for message forwarding, when the object called "joe" (an instance of the driver class), presses the gas pedal, he literally passes an accelerate message to object "my Porsche", which in turn, invokes the "my Porsche" accelerate method.

[[Image:MessagePassing.jpg|frame|center|Message Forwarding]]
Image taken from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

===Delegation===

Delegation allows the behavior of an object to be defined in terms of the other object and can be viewed as a relationship between objects where one object forwards certain method calls to another object, called its delegate. In OOP, two notions of delegation exist. The older usage refers to passing on the execution to some other object. While new usage refers to using method lookup rules to dispatch so-called self-calls as defined by Lieberman in his 1986 paper "Using Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems".

Example for old definition:

Suppose there are class A and B defined as follows:

class A
{
public:
foo()
{
print("Object A doing the job");
}
}
class B
{
public:
A a;
foo()
{
a.foo();
}
}

Here class B delegates the execution of its function foo to an object of class A.

Example of new definition:

class A
{
foo() {
self.bar() // self is also known under the names "current" and "this" in other languages
}
bar() {
print("a.bar")
}
}
class B
{
delegationlink A a
foo() {
a.foo() // call foo() on the a-instance
}
bar() {
print("b.bar")
}
}
a = new A()
b = new B(a) // establish delegation between two objects

calling b.foo() will result in b.bar to be printed. Older definition would have resulted in a.bar.

Example taken from http://www.wordiq.com/definition/Delegation_(programming)

It should be noted that support for delegation as new definition is not widely supported in programming languages, though exceptions exists in the form of the languages Self and Kniesels Lava.

Delegation is based on dynamic binding, as it requires that a given method call can invoke different segments of code at runtime. Delegation forms the core of design patterns like wrapper design pattern.

==Comparing Inheritance with Others==

As discussed above, inheritance forms a basic way to compartmentalize and code reuse in object oriented programming. However in some cases, inheritance may not be the best way to approach the problem. Some of the limitations of inheritance are:

* When single inheritance is used, an object can only inherit from a single object. If in the above given inheritance example, single inheritance is used Teaching assistant can either be student or a teacher but not both. Using multiple inheritance solves the problem (as in above example), but it can still inherit from each super class only once and hence a Teaching assistant cannot be a student at two different institutions. Also, multiple inheritance creates problem when a same trait is inherited from two different parents.

* Inheritance hierarchy for an object is fixed at the time of instantiation and cannot be changed. In the above example, Student object cannot change to Teacher while retaining characteristics of an Employee. Hence inheritance locks the original design which becomes difficult to change.

* When any client has access of any of the subclass, it automatically has access to the data which is part of the super class, even if data is private to the parent class. E.g in above example, access to student class gives an access of person class and can lead to unwarranted change of Person class properties.

Hence, it can be said that inheritance is not always a good approach for all the problems and some of the elements of OOP discussed above can be good alternatives for inheritance.

===Decomposition and Inheritance===

Traditionally, inheritance is used when there is a "is a" relationship between objects and decomposition when there is "has a" relationship between objects. An example of inheritance where "Programmer" and "Manager" extend "Employee" (is a relationship) can also be looked as, "Programmer" as a set of duties that an "Employee" may have, and this same employee may later change duties for "Manager" duties (has a relationship). Hence the way we design our system makes decomposition or inheritance favorable. But as a rule of thumb, object oriented design based on decomposition is more stable when parent objects are likely to change. In our decomposition example considered above, even if drawer functionality and role change drastically basic participants (letter object in this case) are likely to remain same and can be used in some other domain also. Hence, decomposition is used when there is lot of code reuse and/or polymorphism. By separating behaviors from the primary class hierarchy and including specific behavior for the child class, child class is not restricted by behavior of its ancestral classes.
Inheritance should be preferred when there is significant interaction between parent and its child classes. If parent must call back to child methods, then inheritance is usually the good answer. As an example, consider a class apple which inherits from its super class Fruit. Any change in the behavior of fruit will directly effect Orange which "is a" type of fruit. When super class and its subclasses are meant to be tied together inheritance should be used as it allows us to take advantage of dynamic binding and polymorphism.

===Message Passing and Inheritance===

Object oriented programs generally have two kinds of structures; one style is to have an inheritance hierarchy. The other is to have a pattern of message passing. Inheritance structure represents how different objects are related by their types. For example, in the program that models water use, Faucets and WaterPipes can be modeled as same kind of objects, except that Faucets can be turned on and off and WaterPipes can have multiple connections to other WaterPipes. Thus Faucet and WaterPipe objects can inherit from a common antecedent with all common traits and will have their specific properties in their classes.
Message passing structure represents how program works. For example, in the above mentioned program for water use, Appliance objects might send messages requesting water to Valves, and Valves to WaterPipes. The Building object can communicate through messages with all the Valves, Faucets, and WaterPipes, but not directly with Appliances. The connection between different objects which know whom to contact and pass message defines program structure.
[Example taken from: http://objc.toodarkpark.net/oop.html ]

There are situations where inheritance structure for the program may not work well. For example, consider an object Room which defines characteristics for the room. Room can be cubiod in shape so Object Room can inherit characteristics from Cuboid Object. However problem arise when different Rooms can have different shapes say cylindrical. Inheriting from both Cubiod and Cylindrical Objects will make Room both cylindrical and cubiod, instead of being cylindrical or cubiod in shape. Hence inheritance would not work here. A better way would be to have separate objects Shape and Room and shape object points to Cubiod or Cylindrical object. A Room object can interact with object Shape by passing messages. In this design approach access to all of other object facilities is not granted, instead an object needs to pass messages to access attributes and operations of the other class. Thus message passing exposes only the required interface of the object.

===Delegation and Inheritance===

Delegation is closely related to message forwarding and as discussed in above section, just like message forwarding and inheritance, there can be two kinds of structures for programs involving inheritance and delegation. Delegation supports the prototype-based programming model and inheritance, class based programming model. Inheritance schemes involve two kinds of objects, classes and instances. A class defines what is known as structure of its instances. Each instance maintains its values of attributes defined in the structure and the state of an object is given by the values of its attributes at any point in time. In delegation, there is only one type of object which represents real-world items. These objects are often taken to be “instances without classes.” This independence of all objects in delegation scheme allows delegation to capture the behavior of inheritance to some extent.

When it comes to building large systems with many objects, using an inheritance based system seems to make more sense. This is due to the fact that inheritance based system forces programmer to think and place some common behavior in super classes. In delegation based system, common behavior can be put in a single class, but this results in dependencies between objects and changing one object might result in errors in another object which is delegating the job to the first object.

In the nutshell, following are the situations when using delegations over inheritance is beneficial:

* When an object can play more than one role in the system, then sub-classing is not advisable, as the numbers of combinations are very large. Delegation would result in fewer classes and work best in this case.
* Inheritance, as discussed before, is a static relationship. If a class inherits from another class, this relationship cannot be changed at run time. On the other hand, Delegation is a dynamic relationship that can be changed at runtime.
* If an object needs to hide a function or an attribute from its super-class, then it is not a right candidate for inheritance. Delegation is an appropriate solution for this situation.
* If there’s no control over the class which is being inherited, it is good to use delegation over inheritance as inheritance has the risk that classes may have to be changed due to changes in parent class over which there’s no control.
* Delegation, unlike Inheritance, doesn’t force an object to accept all the methods of the super class, an object can only provide those methods that really make sense.

However, delegation has certain disadvantages over inheritance

* Delegation results in large number of objects in memory, which could result in performance issue when the objects in memory grow fast due to inefficient handling or disposal of objects.
* Delegation results in code more difficult to read understand and debug. This is due to the fact that delegation involves certain level of object indirection.

==Conclusion==

OOP has many features which makes it a favorable option in many problem domains. However, based on the requirements of the application, what is needed are subtle design decisions about which feature of OOP should be given more importance. Inheritance based models seem a very attractive choice for almost all object oriented applications, which is not true. As discussed in this article, techniques like decomposition, delegation and message forwarding do compass better alternatives for inheritance for some object oriented applications. What is needed is a perspective to see which OOP concept would make object oriented design more efficient and robust.

==References==

[1] Thomas K¨uhne, A Functional Pattern System for Object-Oriented Design. Retrieved 4th October 2010, from http://homepages.mcs.vuw.ac.nz/~tk/fps/fps-sans-escher.pdf

[2] Composition vs Inheritance in Java. Retrieved 4 October 2010, from http://www.mapleshirefarm.com/eric/CompositionVsInheritance.html

[3] Inheritance versus composition: Which one should you choose, retrieved 4th October 2010, from http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=2

[4] Inheritance. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)

[5] Decomposition. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Decomposition_(computer_science)

[6] Object Oriented Programming Concepts, Retrieved 4th October 2010, from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

[7] Message Passing. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Message_passing

[8] Object Oriented Programming, Retrieved 4th October 2010, from http://objc.toodarkpark.net/oop.html

[9] Meilir Page-Jones, Larry L. Constantine, Fundamentals of object-oriented design in UML, Addison-Wesley Professional,1999

[10] Lynn Andrea Stein,Delegation is inheritance in the proceedings of conference on Object Oriented Programming Systems Languages and Applications, (Orlando, Florida, 1987), ACM, 138 - 146 Year of Publication: 1987

[11] Delegation Definition. Retrieved 5th October from , http://www.wordiq.com/definition/Delegation_(programming)

[12] Manish Sharma, When Not to use Inheritance but Delegation. Retrieved 5th october 2010, from http://developergeeks.com/article/16/when-not-to-use-inheritance-but-delegation

[13] Peter Bosch, Inheritance vs. delegation: Is one better than the other? Unpublished. Retrieved 5th october 2010, from www.python.org/ftp/python/doc/delegation.ps

CSC/ECE 517 Fall 2010/ch3 S30 SK

2010-10-06T17:38:28Z

Sumi2509: /* Conclusion */

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

==Introduction==

Object oriented programming (OOP) paradigm is based upon what is known as "objects", which represent real world concepts. One of the principal advantages of object-oriented programming over procedural programming is that they enable programmers to create modules that do not need to be changed when a new type of object is added.
Some basic concepts/features which are part of OOP are classes, methods, instances, encapsulation, inheritance, message forwarding, decomposition, delegation etc. This article discusses four of these concepts, namely, inheritance, message forwarding, decomposition and delegation. Specifically, comparison between inheritance and message forwarding, decomposition & delegation is made to understand when each of these can be considered as a potential alternative for inheritance, which forms core of OOP.

==Elements of OOP==

Some of the elements of OOP, relevant to the topic are discussed below

===Inheritance===

In OOP, inheritance is a way to compartmentalize the code by creating objects which are based on previously created objects. In classical inheritance where objects are defined by classes, parent class is known as super class and the one which inherits behavior is known as sub class. Inheritance is used to relate two or more objects to each other. With the use of inheritance, methods and instance variables of the parent object are available for use in all of its child objects.
[[Image:Inheritance.jpg|frame|center|Inheritance Hierarchy]]

In the above example, student and teacher both inherit characters from Person object and Teaching Assistant inherits characteristics from both Teacher and Student and indirectly from Person.

===Decomposition===

Decomposition, also known as factoring is the process by which a big, complex problem is broken into smaller problems which are easier to attack, conceive and manage. Object Oriented Decomposition breaks large problem domain, based on classification entities, into smaller objects which represents some part of the problem. Object oriented decomposition works especially fine due to the concept of procedural abstraction which makes a problem easier to solve. Object-oriented decomposition results in a product that is more reusable.

For example, we could have an object referring to Drawer which supports addition of information and an object Letter which supports retrieval of content. In this case, a bigger problem domain (Drawer) refers to an object (Letter) which handles smaller problem domain. The fact that Drawer can have many letters makes decomposition relation of type "has a".

[[Image:Decomposition.jpg|frame|center|Decomposition]]

In the above example, Drawer object holds an instance variable which refers to Letter object. The bigger problem domain of "Drawer" has now been divided into smaller problem domains, one of which is Letter. Letter behavior is easier to maintain as compared to Drawer and any change in Drawer behavior will not affect Letter's behavior. Moreover, Letter object can be part of some other big problem domain also(except that of Drawer).

===Message Forwarding===

Message Forwarding, also known as interfacing, describes the communication between objects using their public interfaces. Using message forwarding, objects can send and receive messages from each other, which help them to synchronize. Message passing is done using methods, properties and events. Message forwarding using method involves invoking an operation on an object. In response to the message the corresponding method is executed in the object and object may return some values. Message forwarding using property allows object to advertise and allow change in their state information. Events are raised by the objects in response to an internal action. Other objects can subscribe to these so that they can react to an occurrence of the event. An example for vehicles could be an 'ImpactDetected' event subscribed to by one or more 'AirBag' objects.

In some object-oriented programming languages, a message is the means to pass control to an object and if the object responds to the message, which means it has some way to handle that message. In pure object-oriented programming, message passing is performed exclusively through a dynamic dispatch strategy (process of mapping a message to a specific sequence of code at runtime.). Message forwarding techniques for communication between objects makes the interface descriptions with external systems much simpler.

Java employs message forwarding in the form of message calling. Objective C and Smalltalk heavily rely of message passing and use message sending instead of message calling.

As an example for message forwarding, when the object called "joe" (an instance of the driver class), presses the gas pedal, he literally passes an accelerate message to object "my Porsche", which in turn, invokes the "my Porsche" accelerate method.

[[Image:MessagePassing.jpg|frame|center|Message Forwarding]]
Image taken from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

===Delegation===

Delegation allows the behavior of an object to be defined in terms of the other object and can be viewed as a relationship between objects where one object forwards certain method calls to another object, called its delegate. In OOP, two notions of delegation exist. The older usage refers to passing on the execution to some other object. While new usage refers to using method lookup rules to dispatch so-called self-calls as defined by Lieberman in his 1986 paper "Using Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems".

Example for old definition:

Suppose there are class A and B defined as follows:

class A
{
public:
foo()
{
print("Object A doing the job");
}
}
class B
{
public:
A a;
foo()
{
a.foo();
}
}

Here class B delegates the execution of its function foo to an object of class A.

Example of new definition:

class A
{
foo() {
self.bar() // self is also known under the names "current" and "this" in other languages
}
bar() {
print("a.bar")
}
}
class B
{
delegationlink A a
foo() {
a.foo() // call foo() on the a-instance
}
bar() {
print("b.bar")
}
}
a = new A()
b = new B(a) // establish delegation between two objects

calling b.foo() will result in b.bar to be printed. Older definition would have resulted in a.bar.

Example taken from http://www.wordiq.com/definition/Delegation_(programming)

It should be noted that support for delegation as new definition is not widely supported in programming languages, though exceptions exists in the form of the languages Self and Kniesels Lava.

Delegation is based on dynamic binding, as it requires that a given method call can invoke different segments of code at runtime. Delegation forms the core of design patterns like wrapper design pattern.

==Comparing Inheritance with Others==

As discussed above, inheritance forms a basic way to compartmentalize and code reuse in object oriented programming. However in some cases, inheritance may not be the best way to approach the problem. Some of the limitations of inheritance are:

* When single inheritance is used, an object can only inherit from a single object. If in the above given inheritance example, single inheritance is used Teaching assistant can either be student or a teacher but not both. Using multiple inheritance solves the problem (as in above example), but it can still inherit from each super class only once and hence a Teaching assistant cannot be a student at two different institutions. Also, multiple inheritance creates problem when a same trait is inherited from two different parents.

* Inheritance hierarchy for an object is fixed at the time of instantiation and cannot be changed. In the above example, Student object cannot change to Teacher while retaining characteristics of an Employee. Hence inheritance locks the original design which becomes difficult to change.

* When any client has access of any of the subclass, it automatically has access to the data which is part of the super class, even if data is private to the parent class. E.g in above example, access to student class gives an access of person class and can lead to unwarranted change of Person class properties.

Hence, it can be said that inheritance is not always a good approach for all the problems and some of the elements of OOP discussed above can be good alternatives for inheritance.

===Decomposition and Inheritance===

Traditionally, inheritance is used when there is a "is a" relationship between objects and decomposition when there is "has a" relationship between objects. An example of inheritance where "Programmer" and "Manager" extend "Employee" (is a relationship) can also be looked as, "Programmer" as a set of duties that an "Employee" may have, and this same employee may later change duties for "Manager" duties (has a relationship). Hence the way we design our system makes decomposition or inheritance favorable. But as a rule of thumb, object oriented design based on decomposition is more stable when parent objects are likely to change. In our decomposition example considered above, even if drawer functionality and role change drastically basic participants (letter object in this case) are likely to remain same and can be used in some other domain also. Hence, decomposition is used when there is lot of code reuse and/or polymorphism. By separating behaviors from the primary class hierarchy and including specific behavior for the child class, child class is not restricted by behavior of its ancestral classes.
Inheritance should be preferred when there is significant interaction between parent and its child classes. If parent must call back to child methods, then inheritance is usually the good answer. As an example, consider a class apple which inherits from its super class Fruit. Any change in the behavior of fruit will directly effect Orange which "is a" type of fruit. When super class and its subclasses are meant to be tied together inheritance should be used as it allows us to take advantage of dynamic binding and polymorphism.

===Message Passing and Inheritance===

Object oriented programs generally have two kinds of structures; one style is to have an inheritance hierarchy. The other is to have a pattern of message passing. Inheritance structure represents how different objects are related by their types. For example, in the program that models water use, Faucets and WaterPipes can be modeled as same kind of objects, except that Faucets can be turned on and off and WaterPipes can have multiple connections to other WaterPipes. Thus Faucet and WaterPipe objects can inherit from a common antecedent with all common traits and will have their specific properties in their classes.
Message passing structure represents how program works. For example, in the above mentioned program for water use, Appliance objects might send messages requesting water to Valves, and Valves to WaterPipes. The Building object can communicate through messages with all the Valves, Faucets, and WaterPipes, but not directly with Appliances. The connection between different objects which know whom to contact and pass message defines program structure.
[Example taken from: http://objc.toodarkpark.net/oop.html ]

There are situations where inheritance structure for the program may not work well. For example, consider an object Room which defines characteristics for the room. Room can be cubiod in shape so Object Room can inherit characteristics from Cuboid Object. However problem arise when different Rooms can have different shapes say cylindrical. Inheriting from both Cubiod and Cylindrical Objects will make Room both cylindrical and cubiod, instead of being cylindrical or cubiod in shape. Hence inheritance would not work here. A better way would be to have separate objects Shape and Room and shape object points to Cubiod or Cylindrical object. A Room object can interact with object Shape by passing messages. In this design approach access to all of other object facilities is not granted, instead an object needs to pass messages to access attributes and operations of the other class. Thus message passing exposes only the required interface of the object.

===Delegation and Inheritance===

Delegation is closely related to message forwarding and as discussed in above section, just like message forwarding and inheritance, there can be two kinds of structures for programs involving inheritance and delegation. Delegation supports the prototype-based programming model and inheritance, class based programming model. Inheritance schemes involve two kinds of objects, classes and instances. A class defines what is known as structure of its instances. Each instance maintains its values of attributes defined in the structure and the state of an object is given by the values of its attributes at any point in time. In delegation, there is only one type of object which represents real-world items. These objects are often taken to be “instances without classes.” This independence of all objects in delegation scheme allows delegation to capture the behavior of inheritance to some extent.

When it comes to building large systems with many objects, using an inheritance based system seems to make more sense. This is due to the fact that inheritance based system forces programmer to think and place some common behavior in super classes. In delegation based system, common behavior can be put in a single class, but this results in dependencies between objects and changing one object might result in errors in another object which is delegating the job to the first object.

In the nutshell, following are the situations when using delegations over inheritance is beneficial:

* When an object can play more than one role in the system, then sub-classing is not advisable, as the numbers of combinations are very large. Delegation would result in fewer classes and work best in this case.
* Inheritance, as discussed before, is a static relationship. If a class inherits from another class, this relationship cannot be changed at run time. On the other hand, Delegation is a dynamic relationship that can be changed at runtime.
* If an object needs to hide a function or an attribute from its super-class, then it is not a right candidate for inheritance. Delegation is an appropriate solution for this situation.
* If there’s no control over the class which is being inherited, it is good to use delegation over inheritance as inheritance has the risk that classes may have to be changed due to changes in parent class over which there’s no control.
* Delegation, unlike Inheritance, doesn’t force an object to accept all the methods of the super class, an object can only provide those methods that really make sense.

However, delegation has certain disadvantages over inheritance

* Delegation results in large number of objects in memory, which could result in performance issue when the objects in memory grow fast due to inefficient handling or disposal of objects.
* Delegation results in code more difficult to read understand and debug. This is due to the fact that delegation involves certain level of object indirection.

==Conclusion==

OOP has many features which makes it a favorable option in many problem domains. However, based on the requirements of the application, what is needed are subtle design decisions about which feature of OOP should be given more importance. Inheritance based models seem a very attractive choice for almost all object oriented applications, which is not true. As discussed in this article, techniques like decomposition, delegation and message forwarding do compass better alternatives for inheritance for some object oriented applications. What is needed is a perspective to see which OOP concept would make object oriented design more efficient and robust.

==References==

[1] Thomas K¨uhne, A Functional Pattern System for Object-Oriented Design. Retrieved 4th October 2010, from http://homepages.mcs.vuw.ac.nz/~tk/fps/fps-sans-escher.pdf

[2] Composition vs Inheritance in Java. Retrieved 4 October 2010, from http://www.mapleshirefarm.com/eric/CompositionVsInheritance.html

[3] Inheritance versus composition: Which one should you choose, retrieved 4th October 2010, from http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=2

[4] Inheritance. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)

[5] Decomposition. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Decomposition_(computer_science)

[6] Object Oriented Programming Concepts, Retrieved 4th October 2010, from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

[7] Message Passing. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Message_passing

[8] Object Oriented Programming, Retrieved 4th October 2010, from http://objc.toodarkpark.net/oop.html

[9] Meilir Page-Jones, Larry L. Constantine, Fundamentals of object-oriented design in UML, Addison-Wesley Professional,1999

[10] Lynn Andrea Stein,Delegation is inheritance in Conference on Object Oriented Programming Systems Languages and Applications, (Orlando, Florida, 1987), ACM, 138 - 146 Year of Publication: 1987

[11] Delegation Definition. Retrieved 5th October from , http://www.wordiq.com/definition/Delegation_(programming)

[12] Manish Sharma, When Not to use Inheritance but Delegation. Retrieved 5th october 2010, from http://developergeeks.com/article/16/when-not-to-use-inheritance-but-delegation

[13] Peter Bosch, Inheritance vs. delegation: Is one better than the other? Unpublished. Retrieved 5th october 2010, from www.python.org/ftp/python/doc/delegation.ps

CSC/ECE 517 Fall 2010/ch3 S30 SK

2010-10-06T17:34:58Z

Sumi2509: /* Delegation */

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

==Introduction==

Object oriented programming (OOP) paradigm is based upon what is known as "objects", which represent real world concepts. One of the principal advantages of object-oriented programming over procedural programming is that they enable programmers to create modules that do not need to be changed when a new type of object is added.
Some basic concepts/features which are part of OOP are classes, methods, instances, encapsulation, inheritance, message forwarding, decomposition, delegation etc. This article discusses four of these concepts, namely, inheritance, message forwarding, decomposition and delegation. Specifically, comparison between inheritance and message forwarding, decomposition & delegation is made to understand when each of these can be considered as a potential alternative for inheritance, which forms core of OOP.

==Elements of OOP==

Some of the elements of OOP, relevant to the topic are discussed below

===Inheritance===

In OOP, inheritance is a way to compartmentalize the code by creating objects which are based on previously created objects. In classical inheritance where objects are defined by classes, parent class is known as super class and the one which inherits behavior is known as sub class. Inheritance is used to relate two or more objects to each other. With the use of inheritance, methods and instance variables of the parent object are available for use in all of its child objects.
[[Image:Inheritance.jpg|frame|center|Inheritance Hierarchy]]

In the above example, student and teacher both inherit characters from Person object and Teaching Assistant inherits characteristics from both Teacher and Student and indirectly from Person.

===Decomposition===

Decomposition, also known as factoring is the process by which a big, complex problem is broken into smaller problems which are easier to attack, conceive and manage. Object Oriented Decomposition breaks large problem domain, based on classification entities, into smaller objects which represents some part of the problem. Object oriented decomposition works especially fine due to the concept of procedural abstraction which makes a problem easier to solve. Object-oriented decomposition results in a product that is more reusable.

For example, we could have an object referring to Drawer which supports addition of information and an object Letter which supports retrieval of content. In this case, a bigger problem domain (Drawer) refers to an object (Letter) which handles smaller problem domain. The fact that Drawer can have many letters makes decomposition relation of type "has a".

[[Image:Decomposition.jpg|frame|center|Decomposition]]

In the above example, Drawer object holds an instance variable which refers to Letter object. The bigger problem domain of "Drawer" has now been divided into smaller problem domains, one of which is Letter. Letter behavior is easier to maintain as compared to Drawer and any change in Drawer behavior will not affect Letter's behavior. Moreover, Letter object can be part of some other big problem domain also(except that of Drawer).

===Message Forwarding===

Message Forwarding, also known as interfacing, describes the communication between objects using their public interfaces. Using message forwarding, objects can send and receive messages from each other, which help them to synchronize. Message passing is done using methods, properties and events. Message forwarding using method involves invoking an operation on an object. In response to the message the corresponding method is executed in the object and object may return some values. Message forwarding using property allows object to advertise and allow change in their state information. Events are raised by the objects in response to an internal action. Other objects can subscribe to these so that they can react to an occurrence of the event. An example for vehicles could be an 'ImpactDetected' event subscribed to by one or more 'AirBag' objects.

In some object-oriented programming languages, a message is the means to pass control to an object and if the object responds to the message, which means it has some way to handle that message. In pure object-oriented programming, message passing is performed exclusively through a dynamic dispatch strategy (process of mapping a message to a specific sequence of code at runtime.). Message forwarding techniques for communication between objects makes the interface descriptions with external systems much simpler.

Java employs message forwarding in the form of message calling. Objective C and Smalltalk heavily rely of message passing and use message sending instead of message calling.

As an example for message forwarding, when the object called "joe" (an instance of the driver class), presses the gas pedal, he literally passes an accelerate message to object "my Porsche", which in turn, invokes the "my Porsche" accelerate method.

[[Image:MessagePassing.jpg|frame|center|Message Forwarding]]
Image taken from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

===Delegation===

Delegation allows the behavior of an object to be defined in terms of the other object and can be viewed as a relationship between objects where one object forwards certain method calls to another object, called its delegate. In OOP, two notions of delegation exist. The older usage refers to passing on the execution to some other object. While new usage refers to using method lookup rules to dispatch so-called self-calls as defined by Lieberman in his 1986 paper "Using Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems".

Example for old definition:

Suppose there are class A and B defined as follows:

class A
{
public:
foo()
{
print("Object A doing the job");
}
}
class B
{
public:
A a;
foo()
{
a.foo();
}
}

Here class B delegates the execution of its function foo to an object of class A.

Example of new definition:

class A
{
foo() {
self.bar() // self is also known under the names "current" and "this" in other languages
}
bar() {
print("a.bar")
}
}
class B
{
delegationlink A a
foo() {
a.foo() // call foo() on the a-instance
}
bar() {
print("b.bar")
}
}
a = new A()
b = new B(a) // establish delegation between two objects

calling b.foo() will result in b.bar to be printed. Older definition would have resulted in a.bar.

Example taken from http://www.wordiq.com/definition/Delegation_(programming)

It should be noted that support for delegation as new definition is not widely supported in programming languages, though exceptions exists in the form of the languages Self and Kniesels Lava.

Delegation is based on dynamic binding, as it requires that a given method call can invoke different segments of code at runtime. Delegation forms the core of design patterns like wrapper design pattern.

==Comparing Inheritance with Others==

As discussed above, inheritance forms a basic way to compartmentalize and code reuse in object oriented programming. However in some cases, inheritance may not be the best way to approach the problem. Some of the limitations of inheritance are:

* When single inheritance is used, an object can only inherit from a single object. If in the above given inheritance example, single inheritance is used Teaching assistant can either be student or a teacher but not both. Using multiple inheritance solves the problem (as in above example), but it can still inherit from each super class only once and hence a Teaching assistant cannot be a student at two different institutions. Also, multiple inheritance creates problem when a same trait is inherited from two different parents.

* Inheritance hierarchy for an object is fixed at the time of instantiation and cannot be changed. In the above example, Student object cannot change to Teacher while retaining characteristics of an Employee. Hence inheritance locks the original design which becomes difficult to change.

* When any client has access of any of the subclass, it automatically has access to the data which is part of the super class, even if data is private to the parent class. E.g in above example, access to student class gives an access of person class and can lead to unwarranted change of Person class properties.

Hence, it can be said that inheritance is not always a good approach for all the problems and some of the elements of OOP discussed above can be good alternatives for inheritance.

===Decomposition and Inheritance===

Traditionally, inheritance is used when there is a "is a" relationship between objects and decomposition when there is "has a" relationship between objects. An example of inheritance where "Programmer" and "Manager" extend "Employee" (is a relationship) can also be looked as, "Programmer" as a set of duties that an "Employee" may have, and this same employee may later change duties for "Manager" duties (has a relationship). Hence the way we design our system makes decomposition or inheritance favorable. But as a rule of thumb, object oriented design based on decomposition is more stable when parent objects are likely to change. In our decomposition example considered above, even if drawer functionality and role change drastically basic participants (letter object in this case) are likely to remain same and can be used in some other domain also. Hence, decomposition is used when there is lot of code reuse and/or polymorphism. By separating behaviors from the primary class hierarchy and including specific behavior for the child class, child class is not restricted by behavior of its ancestral classes.
Inheritance should be preferred when there is significant interaction between parent and its child classes. If parent must call back to child methods, then inheritance is usually the good answer. As an example, consider a class apple which inherits from its super class Fruit. Any change in the behavior of fruit will directly effect Orange which "is a" type of fruit. When super class and its subclasses are meant to be tied together inheritance should be used as it allows us to take advantage of dynamic binding and polymorphism.

===Message Passing and Inheritance===

Object oriented programs generally have two kinds of structures; one style is to have an inheritance hierarchy. The other is to have a pattern of message passing. Inheritance structure represents how different objects are related by their types. For example, in the program that models water use, Faucets and WaterPipes can be modeled as same kind of objects, except that Faucets can be turned on and off and WaterPipes can have multiple connections to other WaterPipes. Thus Faucet and WaterPipe objects can inherit from a common antecedent with all common traits and will have their specific properties in their classes.
Message passing structure represents how program works. For example, in the above mentioned program for water use, Appliance objects might send messages requesting water to Valves, and Valves to WaterPipes. The Building object can communicate through messages with all the Valves, Faucets, and WaterPipes, but not directly with Appliances. The connection between different objects which know whom to contact and pass message defines program structure.
[Example taken from: http://objc.toodarkpark.net/oop.html ]

There are situations where inheritance structure for the program may not work well. For example, consider an object Room which defines characteristics for the room. Room can be cubiod in shape so Object Room can inherit characteristics from Cuboid Object. However problem arise when different Rooms can have different shapes say cylindrical. Inheriting from both Cubiod and Cylindrical Objects will make Room both cylindrical and cubiod, instead of being cylindrical or cubiod in shape. Hence inheritance would not work here. A better way would be to have separate objects Shape and Room and shape object points to Cubiod or Cylindrical object. A Room object can interact with object Shape by passing messages. In this design approach access to all of other object facilities is not granted, instead an object needs to pass messages to access attributes and operations of the other class. Thus message passing exposes only the required interface of the object.

===Delegation and Inheritance===

Delegation is closely related to message forwarding and as discussed in above section, just like message forwarding and inheritance, there can be two kinds of structures for programs involving inheritance and delegation. Delegation supports the prototype-based programming model and inheritance, class based programming model. Inheritance schemes involve two kinds of objects, classes and instances. A class defines what is known as structure of its instances. Each instance maintains its values of attributes defined in the structure and the state of an object is given by the values of its attributes at any point in time. In delegation, there is only one type of object which represents real-world items. These objects are often taken to be “instances without classes.” This independence of all objects in delegation scheme allows delegation to capture the behavior of inheritance to some extent.

When it comes to building large systems with many objects, using an inheritance based system seems to make more sense. This is due to the fact that inheritance based system forces programmer to think and place some common behavior in super classes. In delegation based system, common behavior can be put in a single class, but this results in dependencies between objects and changing one object might result in errors in another object which is delegating the job to the first object.

In the nutshell, following are the situations when using delegations over inheritance is beneficial:

* When an object can play more than one role in the system, then sub-classing is not advisable, as the numbers of combinations are very large. Delegation would result in fewer classes and work best in this case.
* Inheritance, as discussed before, is a static relationship. If a class inherits from another class, this relationship cannot be changed at run time. On the other hand, Delegation is a dynamic relationship that can be changed at runtime.
* If an object needs to hide a function or an attribute from its super-class, then it is not a right candidate for inheritance. Delegation is an appropriate solution for this situation.
* If there’s no control over the class which is being inherited, it is good to use delegation over inheritance as inheritance has the risk that classes may have to be changed due to changes in parent class over which there’s no control.
* Delegation, unlike Inheritance, doesn’t force an object to accept all the methods of the super class, an object can only provide those methods that really make sense.

However, delegation has certain disadvantages over inheritance

* Delegation results in large number of objects in memory, which could result in performance issue when the objects in memory grow fast due to inefficient handling or disposal of objects.
* Delegation results in code more difficult to read understand and debug. This is due to the fact that delegation involves certain level of object indirection.

==Conclusion==

OOP has many features which makes it a favorable option in many problem domains. However, based on the requirements of the application, what is needed are subtle design decisions about which feature of OOP is a best option. Inheritance based models seem a very attractive choice for all object oriented applications, which is not true. As discussed in this article, techniques like decomposition, delegation and message forwarding do compass better alternatives for inheritance for some object oriented applications. What is needed is a perspective to see which OOP concept fits best in the overall picture.

==References==

[1] Thomas K¨uhne, A Functional Pattern System for Object-Oriented Design. Retrieved 4th October 2010, from http://homepages.mcs.vuw.ac.nz/~tk/fps/fps-sans-escher.pdf

[2] Composition vs Inheritance in Java. Retrieved 4 October 2010, from http://www.mapleshirefarm.com/eric/CompositionVsInheritance.html

[3] Inheritance versus composition: Which one should you choose, retrieved 4th October 2010, from http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=2

[4] Inheritance. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)

[5] Decomposition. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Decomposition_(computer_science)

[6] Object Oriented Programming Concepts, Retrieved 4th October 2010, from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

[7] Message Passing. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Message_passing

[8] Object Oriented Programming, Retrieved 4th October 2010, from http://objc.toodarkpark.net/oop.html

[9] Meilir Page-Jones, Larry L. Constantine, Fundamentals of object-oriented design in UML, Addison-Wesley Professional,1999

[10] Lynn Andrea Stein,Delegation is inheritance in Conference on Object Oriented Programming Systems Languages and Applications, (Orlando, Florida, 1987), ACM, 138 - 146 Year of Publication: 1987

[11] Delegation Definition. Retrieved 5th October from , http://www.wordiq.com/definition/Delegation_(programming)

[12] Manish Sharma, When Not to use Inheritance but Delegation. Retrieved 5th october 2010, from http://developergeeks.com/article/16/when-not-to-use-inheritance-but-delegation

[13] Peter Bosch, Inheritance vs. delegation: Is one better than the other? Unpublished. Retrieved 5th october 2010, from www.python.org/ftp/python/doc/delegation.ps

CSC/ECE 517 Fall 2010/ch3 S30 SK

2010-10-06T17:30:52Z

Sumi2509: /* Decomposition */

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

==Introduction==

Object oriented programming (OOP) paradigm is based upon what is known as "objects", which represent real world concepts. One of the principal advantages of object-oriented programming over procedural programming is that they enable programmers to create modules that do not need to be changed when a new type of object is added.
Some basic concepts/features which are part of OOP are classes, methods, instances, encapsulation, inheritance, message forwarding, decomposition, delegation etc. This article discusses four of these concepts, namely, inheritance, message forwarding, decomposition and delegation. Specifically, comparison between inheritance and message forwarding, decomposition & delegation is made to understand when each of these can be considered as a potential alternative for inheritance, which forms core of OOP.

==Elements of OOP==

Some of the elements of OOP, relevant to the topic are discussed below

===Inheritance===

In OOP, inheritance is a way to compartmentalize the code by creating objects which are based on previously created objects. In classical inheritance where objects are defined by classes, parent class is known as super class and the one which inherits behavior is known as sub class. Inheritance is used to relate two or more objects to each other. With the use of inheritance, methods and instance variables of the parent object are available for use in all of its child objects.
[[Image:Inheritance.jpg|frame|center|Inheritance Hierarchy]]

In the above example, student and teacher both inherit characters from Person object and Teaching Assistant inherits characteristics from both Teacher and Student and indirectly from Person.

===Decomposition===

Decomposition, also known as factoring is the process by which a big, complex problem is broken into smaller problems which are easier to attack, conceive and manage. Object Oriented Decomposition breaks large problem domain, based on classification entities, into smaller objects which represents some part of the problem. Object oriented decomposition works especially fine due to the concept of procedural abstraction which makes a problem easier to solve. Object-oriented decomposition results in a product that is more reusable.

For example, we could have an object referring to Drawer which supports addition of information and an object Letter which supports retrieval of content. In this case, a bigger problem domain (Drawer) refers to an object (Letter) which handles smaller problem domain. The fact that Drawer can have many letters makes decomposition relation of type "has a".

[[Image:Decomposition.jpg|frame|center|Decomposition]]

In the above example, Drawer object holds an instance variable which refers to Letter object. The bigger problem domain of "Drawer" has now been divided into smaller problem domains, one of which is Letter. Letter behavior is easier to maintain as compared to Drawer and any change in Drawer behavior will not affect Letter's behavior. Moreover, Letter object can be part of some other big problem domain also(except that of Drawer).

===Message Forwarding===

Message Forwarding, also known as interfacing, describes the communication between objects using their public interfaces. Using message forwarding, objects can send and receive messages from each other, which help them to synchronize. Message passing is done using methods, properties and events. Message forwarding using method involves invoking an operation on an object. In response to the message the corresponding method is executed in the object and object may return some values. Message forwarding using property allows object to advertise and allow change in their state information. Events are raised by the objects in response to an internal action. Other objects can subscribe to these so that they can react to an occurrence of the event. An example for vehicles could be an 'ImpactDetected' event subscribed to by one or more 'AirBag' objects.

In some object-oriented programming languages, a message is the means to pass control to an object and if the object responds to the message, which means it has some way to handle that message. In pure object-oriented programming, message passing is performed exclusively through a dynamic dispatch strategy (process of mapping a message to a specific sequence of code at runtime.). Message forwarding techniques for communication between objects makes the interface descriptions with external systems much simpler.

Java employs message forwarding in the form of message calling. Objective C and Smalltalk heavily rely of message passing and use message sending instead of message calling.

As an example for message forwarding, when the object called "joe" (an instance of the driver class), presses the gas pedal, he literally passes an accelerate message to object "my Porsche", which in turn, invokes the "my Porsche" accelerate method.

[[Image:MessagePassing.jpg|frame|center|Message Forwarding]]
Image taken from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

===Delegation===

In OOP, two notions of delegation exist. The older usage refers to passing on the execution to some other object. While new usage refers to using method lookup rules to dispatch so-called self-calls as defined by Lieberman in his 1986 paper "Using Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems".

Example for old definition:

Suppose there are class A and B defined as follows:

class A
{
public:
foo()
{
print("Object A doing the job");
}
}
class B
{
public:
A a;
foo()
{
a.foo();
}
}

Here class B delegates the execution of its function foo to an object of class A.

Example of new definition:

class A
{
foo() {
self.bar() // self is also known under the names "current" and "this" in other languages
}
bar() {
print("a.bar")
}
}
class B
{
delegationlink A a
foo() {
a.foo() // call foo() on the a-instance
}
bar() {
print("b.bar")
}
}
a = new A()
b = new B(a) // establish delegation between two objects

calling b.foo() will result in b.bar to be printed. Older definition would have resulted in a.bar.

Example taken from http://www.wordiq.com/definition/Delegation_(programming)

It should be noted that support for delegation as new definition is not widely supported in programming languages, though exceptions exists in the form of the languages Self and Kniesels Lava.

Delegation can be viewed as a relationship between objects where one object forwards certain method calls to another object, called its delegate. Delegation is based on dynamic binding, as it requires that a given method call can invoke different segments of code at runtime. Delegation forms the core of design patterns like wrapper design pattern.

==Comparing Inheritance with Others==

As discussed above, inheritance forms a basic way to compartmentalize and code reuse in object oriented programming. However in some cases, inheritance may not be the best way to approach the problem. Some of the limitations of inheritance are:

* When single inheritance is used, an object can only inherit from a single object. If in the above given inheritance example, single inheritance is used Teaching assistant can either be student or a teacher but not both. Using multiple inheritance solves the problem (as in above example), but it can still inherit from each super class only once and hence a Teaching assistant cannot be a student at two different institutions. Also, multiple inheritance creates problem when a same trait is inherited from two different parents.

* Inheritance hierarchy for an object is fixed at the time of instantiation and cannot be changed. In the above example, Student object cannot change to Teacher while retaining characteristics of an Employee. Hence inheritance locks the original design which becomes difficult to change.

* When any client has access of any of the subclass, it automatically has access to the data which is part of the super class, even if data is private to the parent class. E.g in above example, access to student class gives an access of person class and can lead to unwarranted change of Person class properties.

Hence, it can be said that inheritance is not always a good approach for all the problems and some of the elements of OOP discussed above can be good alternatives for inheritance.

===Decomposition and Inheritance===

Traditionally, inheritance is used when there is a "is a" relationship between objects and decomposition when there is "has a" relationship between objects. An example of inheritance where "Programmer" and "Manager" extend "Employee" (is a relationship) can also be looked as, "Programmer" as a set of duties that an "Employee" may have, and this same employee may later change duties for "Manager" duties (has a relationship). Hence the way we design our system makes decomposition or inheritance favorable. But as a rule of thumb, object oriented design based on decomposition is more stable when parent objects are likely to change. In our decomposition example considered above, even if drawer functionality and role change drastically basic participants (letter object in this case) are likely to remain same and can be used in some other domain also. Hence, decomposition is used when there is lot of code reuse and/or polymorphism. By separating behaviors from the primary class hierarchy and including specific behavior for the child class, child class is not restricted by behavior of its ancestral classes.
Inheritance should be preferred when there is significant interaction between parent and its child classes. If parent must call back to child methods, then inheritance is usually the good answer. As an example, consider a class apple which inherits from its super class Fruit. Any change in the behavior of fruit will directly effect Orange which "is a" type of fruit. When super class and its subclasses are meant to be tied together inheritance should be used as it allows us to take advantage of dynamic binding and polymorphism.

===Message Passing and Inheritance===

Object oriented programs generally have two kinds of structures; one style is to have an inheritance hierarchy. The other is to have a pattern of message passing. Inheritance structure represents how different objects are related by their types. For example, in the program that models water use, Faucets and WaterPipes can be modeled as same kind of objects, except that Faucets can be turned on and off and WaterPipes can have multiple connections to other WaterPipes. Thus Faucet and WaterPipe objects can inherit from a common antecedent with all common traits and will have their specific properties in their classes.
Message passing structure represents how program works. For example, in the above mentioned program for water use, Appliance objects might send messages requesting water to Valves, and Valves to WaterPipes. The Building object can communicate through messages with all the Valves, Faucets, and WaterPipes, but not directly with Appliances. The connection between different objects which know whom to contact and pass message defines program structure.
[Example taken from: http://objc.toodarkpark.net/oop.html ]

There are situations where inheritance structure for the program may not work well. For example, consider an object Room which defines characteristics for the room. Room can be cubiod in shape so Object Room can inherit characteristics from Cuboid Object. However problem arise when different Rooms can have different shapes say cylindrical. Inheriting from both Cubiod and Cylindrical Objects will make Room both cylindrical and cubiod, instead of being cylindrical or cubiod in shape. Hence inheritance would not work here. A better way would be to have separate objects Shape and Room and shape object points to Cubiod or Cylindrical object. A Room object can interact with object Shape by passing messages. In this design approach access to all of other object facilities is not granted, instead an object needs to pass messages to access attributes and operations of the other class. Thus message passing exposes only the required interface of the object.

===Delegation and Inheritance===

Delegation is closely related to message forwarding and as discussed in above section, just like message forwarding and inheritance, there can be two kinds of structures for programs involving inheritance and delegation. Delegation supports the prototype-based programming model and inheritance, class based programming model. Inheritance schemes involve two kinds of objects, classes and instances. A class defines what is known as structure of its instances. Each instance maintains its values of attributes defined in the structure and the state of an object is given by the values of its attributes at any point in time. In delegation, there is only one type of object which represents real-world items. These objects are often taken to be “instances without classes.” This independence of all objects in delegation scheme allows delegation to capture the behavior of inheritance to some extent.

When it comes to building large systems with many objects, using an inheritance based system seems to make more sense. This is due to the fact that inheritance based system forces programmer to think and place some common behavior in super classes. In delegation based system, common behavior can be put in a single class, but this results in dependencies between objects and changing one object might result in errors in another object which is delegating the job to the first object.

In the nutshell, following are the situations when using delegations over inheritance is beneficial:

* When an object can play more than one role in the system, then sub-classing is not advisable, as the numbers of combinations are very large. Delegation would result in fewer classes and work best in this case.
* Inheritance, as discussed before, is a static relationship. If a class inherits from another class, this relationship cannot be changed at run time. On the other hand, Delegation is a dynamic relationship that can be changed at runtime.
* If an object needs to hide a function or an attribute from its super-class, then it is not a right candidate for inheritance. Delegation is an appropriate solution for this situation.
* If there’s no control over the class which is being inherited, it is good to use delegation over inheritance as inheritance has the risk that classes may have to be changed due to changes in parent class over which there’s no control.
* Delegation, unlike Inheritance, doesn’t force an object to accept all the methods of the super class, an object can only provide those methods that really make sense.

However, delegation has certain disadvantages over inheritance

* Delegation results in large number of objects in memory, which could result in performance issue when the objects in memory grow fast due to inefficient handling or disposal of objects.
* Delegation results in code more difficult to read understand and debug. This is due to the fact that delegation involves certain level of object indirection.

==Conclusion==

OOP has many features which makes it a favorable option in many problem domains. However, based on the requirements of the application, what is needed are subtle design decisions about which feature of OOP is a best option. Inheritance based models seem a very attractive choice for all object oriented applications, which is not true. As discussed in this article, techniques like decomposition, delegation and message forwarding do compass better alternatives for inheritance for some object oriented applications. What is needed is a perspective to see which OOP concept fits best in the overall picture.

==References==

[1] Thomas K¨uhne, A Functional Pattern System for Object-Oriented Design. Retrieved 4th October 2010, from http://homepages.mcs.vuw.ac.nz/~tk/fps/fps-sans-escher.pdf

[2] Composition vs Inheritance in Java. Retrieved 4 October 2010, from http://www.mapleshirefarm.com/eric/CompositionVsInheritance.html

[3] Inheritance versus composition: Which one should you choose, retrieved 4th October 2010, from http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=2

[4] Inheritance. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)

[5] Decomposition. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Decomposition_(computer_science)

[6] Object Oriented Programming Concepts, Retrieved 4th October 2010, from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

[7] Message Passing. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Message_passing

[8] Object Oriented Programming, Retrieved 4th October 2010, from http://objc.toodarkpark.net/oop.html

[9] Meilir Page-Jones, Larry L. Constantine, Fundamentals of object-oriented design in UML, Addison-Wesley Professional,1999

[10] Lynn Andrea Stein,Delegation is inheritance in Conference on Object Oriented Programming Systems Languages and Applications, (Orlando, Florida, 1987), ACM, 138 - 146 Year of Publication: 1987

[11] Delegation Definition. Retrieved 5th October from , http://www.wordiq.com/definition/Delegation_(programming)

[12] Manish Sharma, When Not to use Inheritance but Delegation. Retrieved 5th october 2010, from http://developergeeks.com/article/16/when-not-to-use-inheritance-but-delegation

[13] Peter Bosch, Inheritance vs. delegation: Is one better than the other? Unpublished. Retrieved 5th october 2010, from www.python.org/ftp/python/doc/delegation.ps

CSC/ECE 517 Fall 2010/ch3 S30 SK

2010-10-06T17:30:38Z

Sumi2509: /* Decomposition */

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

==Introduction==

Object oriented programming (OOP) paradigm is based upon what is known as "objects", which represent real world concepts. One of the principal advantages of object-oriented programming over procedural programming is that they enable programmers to create modules that do not need to be changed when a new type of object is added.
Some basic concepts/features which are part of OOP are classes, methods, instances, encapsulation, inheritance, message forwarding, decomposition, delegation etc. This article discusses four of these concepts, namely, inheritance, message forwarding, decomposition and delegation. Specifically, comparison between inheritance and message forwarding, decomposition & delegation is made to understand when each of these can be considered as a potential alternative for inheritance, which forms core of OOP.

==Elements of OOP==

Some of the elements of OOP, relevant to the topic are discussed below

===Inheritance===

In OOP, inheritance is a way to compartmentalize the code by creating objects which are based on previously created objects. In classical inheritance where objects are defined by classes, parent class is known as super class and the one which inherits behavior is known as sub class. Inheritance is used to relate two or more objects to each other. With the use of inheritance, methods and instance variables of the parent object are available for use in all of its child objects.
[[Image:Inheritance.jpg|frame|center|Inheritance Hierarchy]]

In the above example, student and teacher both inherit characters from Person object and Teaching Assistant inherits characteristics from both Teacher and Student and indirectly from Person.

===Decomposition===

Decomposition, also known as factoring is the process by which a big, complex problem is broken into smaller problems which are easier to attack, conceive and manage. Object Oriented Decomposition breaks large problem domain, based on classification entities, into smaller objects which represents some part of the problem. Object oriented decomposition works especially fine due to the concept of procedural abstraction which makes a problem easier to solve. Object-oriented decomposition results in a product that is more reusable.

For example, we could have an object referring to Drawer which supports addition of information and an object Letter which supports retrieval of content. In this case, a bigger problem domain (Drawer) refers to an object (Letter) which handles smaller problem domain. The fact that Drawer can have many letters makes decomposition relation of type "has a".

[[Image:Decomposition.jpg|frame|center|Decomposition]]

In the above example, Drawer object holds an instance variable which refers to Letter object. The bigger problem domain of "Drawer" has now been divided into smaller problem domains, one of which is Letter. Letter behavior is easier to maintain as compared to Drawer and any change in Drawer behavior will not affect Letter's behavior. Moreover, letter object can be part of some other big problem domain also(except that of Drawer).

===Message Forwarding===

Message Forwarding, also known as interfacing, describes the communication between objects using their public interfaces. Using message forwarding, objects can send and receive messages from each other, which help them to synchronize. Message passing is done using methods, properties and events. Message forwarding using method involves invoking an operation on an object. In response to the message the corresponding method is executed in the object and object may return some values. Message forwarding using property allows object to advertise and allow change in their state information. Events are raised by the objects in response to an internal action. Other objects can subscribe to these so that they can react to an occurrence of the event. An example for vehicles could be an 'ImpactDetected' event subscribed to by one or more 'AirBag' objects.

In some object-oriented programming languages, a message is the means to pass control to an object and if the object responds to the message, which means it has some way to handle that message. In pure object-oriented programming, message passing is performed exclusively through a dynamic dispatch strategy (process of mapping a message to a specific sequence of code at runtime.). Message forwarding techniques for communication between objects makes the interface descriptions with external systems much simpler.

Java employs message forwarding in the form of message calling. Objective C and Smalltalk heavily rely of message passing and use message sending instead of message calling.

As an example for message forwarding, when the object called "joe" (an instance of the driver class), presses the gas pedal, he literally passes an accelerate message to object "my Porsche", which in turn, invokes the "my Porsche" accelerate method.

[[Image:MessagePassing.jpg|frame|center|Message Forwarding]]
Image taken from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

===Delegation===

In OOP, two notions of delegation exist. The older usage refers to passing on the execution to some other object. While new usage refers to using method lookup rules to dispatch so-called self-calls as defined by Lieberman in his 1986 paper "Using Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems".

Example for old definition:

Suppose there are class A and B defined as follows:

class A
{
public:
foo()
{
print("Object A doing the job");
}
}
class B
{
public:
A a;
foo()
{
a.foo();
}
}

Here class B delegates the execution of its function foo to an object of class A.

Example of new definition:

class A
{
foo() {
self.bar() // self is also known under the names "current" and "this" in other languages
}
bar() {
print("a.bar")
}
}
class B
{
delegationlink A a
foo() {
a.foo() // call foo() on the a-instance
}
bar() {
print("b.bar")
}
}
a = new A()
b = new B(a) // establish delegation between two objects

calling b.foo() will result in b.bar to be printed. Older definition would have resulted in a.bar.

Example taken from http://www.wordiq.com/definition/Delegation_(programming)

It should be noted that support for delegation as new definition is not widely supported in programming languages, though exceptions exists in the form of the languages Self and Kniesels Lava.

Delegation can be viewed as a relationship between objects where one object forwards certain method calls to another object, called its delegate. Delegation is based on dynamic binding, as it requires that a given method call can invoke different segments of code at runtime. Delegation forms the core of design patterns like wrapper design pattern.

==Comparing Inheritance with Others==

As discussed above, inheritance forms a basic way to compartmentalize and code reuse in object oriented programming. However in some cases, inheritance may not be the best way to approach the problem. Some of the limitations of inheritance are:

* When single inheritance is used, an object can only inherit from a single object. If in the above given inheritance example, single inheritance is used Teaching assistant can either be student or a teacher but not both. Using multiple inheritance solves the problem (as in above example), but it can still inherit from each super class only once and hence a Teaching assistant cannot be a student at two different institutions. Also, multiple inheritance creates problem when a same trait is inherited from two different parents.

* Inheritance hierarchy for an object is fixed at the time of instantiation and cannot be changed. In the above example, Student object cannot change to Teacher while retaining characteristics of an Employee. Hence inheritance locks the original design which becomes difficult to change.

* When any client has access of any of the subclass, it automatically has access to the data which is part of the super class, even if data is private to the parent class. E.g in above example, access to student class gives an access of person class and can lead to unwarranted change of Person class properties.

Hence, it can be said that inheritance is not always a good approach for all the problems and some of the elements of OOP discussed above can be good alternatives for inheritance.

===Decomposition and Inheritance===

Traditionally, inheritance is used when there is a "is a" relationship between objects and decomposition when there is "has a" relationship between objects. An example of inheritance where "Programmer" and "Manager" extend "Employee" (is a relationship) can also be looked as, "Programmer" as a set of duties that an "Employee" may have, and this same employee may later change duties for "Manager" duties (has a relationship). Hence the way we design our system makes decomposition or inheritance favorable. But as a rule of thumb, object oriented design based on decomposition is more stable when parent objects are likely to change. In our decomposition example considered above, even if drawer functionality and role change drastically basic participants (letter object in this case) are likely to remain same and can be used in some other domain also. Hence, decomposition is used when there is lot of code reuse and/or polymorphism. By separating behaviors from the primary class hierarchy and including specific behavior for the child class, child class is not restricted by behavior of its ancestral classes.
Inheritance should be preferred when there is significant interaction between parent and its child classes. If parent must call back to child methods, then inheritance is usually the good answer. As an example, consider a class apple which inherits from its super class Fruit. Any change in the behavior of fruit will directly effect Orange which "is a" type of fruit. When super class and its subclasses are meant to be tied together inheritance should be used as it allows us to take advantage of dynamic binding and polymorphism.

===Message Passing and Inheritance===

Object oriented programs generally have two kinds of structures; one style is to have an inheritance hierarchy. The other is to have a pattern of message passing. Inheritance structure represents how different objects are related by their types. For example, in the program that models water use, Faucets and WaterPipes can be modeled as same kind of objects, except that Faucets can be turned on and off and WaterPipes can have multiple connections to other WaterPipes. Thus Faucet and WaterPipe objects can inherit from a common antecedent with all common traits and will have their specific properties in their classes.
Message passing structure represents how program works. For example, in the above mentioned program for water use, Appliance objects might send messages requesting water to Valves, and Valves to WaterPipes. The Building object can communicate through messages with all the Valves, Faucets, and WaterPipes, but not directly with Appliances. The connection between different objects which know whom to contact and pass message defines program structure.
[Example taken from: http://objc.toodarkpark.net/oop.html ]

There are situations where inheritance structure for the program may not work well. For example, consider an object Room which defines characteristics for the room. Room can be cubiod in shape so Object Room can inherit characteristics from Cuboid Object. However problem arise when different Rooms can have different shapes say cylindrical. Inheriting from both Cubiod and Cylindrical Objects will make Room both cylindrical and cubiod, instead of being cylindrical or cubiod in shape. Hence inheritance would not work here. A better way would be to have separate objects Shape and Room and shape object points to Cubiod or Cylindrical object. A Room object can interact with object Shape by passing messages. In this design approach access to all of other object facilities is not granted, instead an object needs to pass messages to access attributes and operations of the other class. Thus message passing exposes only the required interface of the object.

===Delegation and Inheritance===

Delegation is closely related to message forwarding and as discussed in above section, just like message forwarding and inheritance, there can be two kinds of structures for programs involving inheritance and delegation. Delegation supports the prototype-based programming model and inheritance, class based programming model. Inheritance schemes involve two kinds of objects, classes and instances. A class defines what is known as structure of its instances. Each instance maintains its values of attributes defined in the structure and the state of an object is given by the values of its attributes at any point in time. In delegation, there is only one type of object which represents real-world items. These objects are often taken to be “instances without classes.” This independence of all objects in delegation scheme allows delegation to capture the behavior of inheritance to some extent.

When it comes to building large systems with many objects, using an inheritance based system seems to make more sense. This is due to the fact that inheritance based system forces programmer to think and place some common behavior in super classes. In delegation based system, common behavior can be put in a single class, but this results in dependencies between objects and changing one object might result in errors in another object which is delegating the job to the first object.

In the nutshell, following are the situations when using delegations over inheritance is beneficial:

* When an object can play more than one role in the system, then sub-classing is not advisable, as the numbers of combinations are very large. Delegation would result in fewer classes and work best in this case.
* Inheritance, as discussed before, is a static relationship. If a class inherits from another class, this relationship cannot be changed at run time. On the other hand, Delegation is a dynamic relationship that can be changed at runtime.
* If an object needs to hide a function or an attribute from its super-class, then it is not a right candidate for inheritance. Delegation is an appropriate solution for this situation.
* If there’s no control over the class which is being inherited, it is good to use delegation over inheritance as inheritance has the risk that classes may have to be changed due to changes in parent class over which there’s no control.
* Delegation, unlike Inheritance, doesn’t force an object to accept all the methods of the super class, an object can only provide those methods that really make sense.

However, delegation has certain disadvantages over inheritance

* Delegation results in large number of objects in memory, which could result in performance issue when the objects in memory grow fast due to inefficient handling or disposal of objects.
* Delegation results in code more difficult to read understand and debug. This is due to the fact that delegation involves certain level of object indirection.

==Conclusion==

OOP has many features which makes it a favorable option in many problem domains. However, based on the requirements of the application, what is needed are subtle design decisions about which feature of OOP is a best option. Inheritance based models seem a very attractive choice for all object oriented applications, which is not true. As discussed in this article, techniques like decomposition, delegation and message forwarding do compass better alternatives for inheritance for some object oriented applications. What is needed is a perspective to see which OOP concept fits best in the overall picture.

==References==

[1] Thomas K¨uhne, A Functional Pattern System for Object-Oriented Design. Retrieved 4th October 2010, from http://homepages.mcs.vuw.ac.nz/~tk/fps/fps-sans-escher.pdf

[2] Composition vs Inheritance in Java. Retrieved 4 October 2010, from http://www.mapleshirefarm.com/eric/CompositionVsInheritance.html

[3] Inheritance versus composition: Which one should you choose, retrieved 4th October 2010, from http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=2

[4] Inheritance. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)

[5] Decomposition. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Decomposition_(computer_science)

[6] Object Oriented Programming Concepts, Retrieved 4th October 2010, from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

[7] Message Passing. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Message_passing

[8] Object Oriented Programming, Retrieved 4th October 2010, from http://objc.toodarkpark.net/oop.html

[9] Meilir Page-Jones, Larry L. Constantine, Fundamentals of object-oriented design in UML, Addison-Wesley Professional,1999

[10] Lynn Andrea Stein,Delegation is inheritance in Conference on Object Oriented Programming Systems Languages and Applications, (Orlando, Florida, 1987), ACM, 138 - 146 Year of Publication: 1987

[11] Delegation Definition. Retrieved 5th October from , http://www.wordiq.com/definition/Delegation_(programming)

[12] Manish Sharma, When Not to use Inheritance but Delegation. Retrieved 5th october 2010, from http://developergeeks.com/article/16/when-not-to-use-inheritance-but-delegation

[13] Peter Bosch, Inheritance vs. delegation: Is one better than the other? Unpublished. Retrieved 5th october 2010, from www.python.org/ftp/python/doc/delegation.ps

CSC/ECE 517 Fall 2010/ch3 S30 SK

2010-10-06T17:29:20Z

Sumi2509: /* Inheritance */

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

==Introduction==

Object oriented programming (OOP) paradigm is based upon what is known as "objects", which represent real world concepts. One of the principal advantages of object-oriented programming over procedural programming is that they enable programmers to create modules that do not need to be changed when a new type of object is added.
Some basic concepts/features which are part of OOP are classes, methods, instances, encapsulation, inheritance, message forwarding, decomposition, delegation etc. This article discusses four of these concepts, namely, inheritance, message forwarding, decomposition and delegation. Specifically, comparison between inheritance and message forwarding, decomposition & delegation is made to understand when each of these can be considered as a potential alternative for inheritance, which forms core of OOP.

==Elements of OOP==

Some of the elements of OOP, relevant to the topic are discussed below

===Inheritance===

In OOP, inheritance is a way to compartmentalize the code by creating objects which are based on previously created objects. In classical inheritance where objects are defined by classes, parent class is known as super class and the one which inherits behavior is known as sub class. Inheritance is used to relate two or more objects to each other. With the use of inheritance, methods and instance variables of the parent object are available for use in all of its child objects.
[[Image:Inheritance.jpg|frame|center|Inheritance Hierarchy]]

In the above example, student and teacher both inherit characters from Person object and Teaching Assistant inherits characteristics from both Teacher and Student and indirectly from Person.

===Decomposition===

Decomposition, also known as factoring is the process by which a big, complex problem is broken into smaller problems which are easier to attack, conceive and manage. Object Oriented Decomposition breaks large problem domain, based on classification entities, into smaller objects which represents some part of the problem. Object oriented decomposition works especially fine due to the concept of procedural abstraction which makes a problem easier to solve. Object-oriented decomposition results in a product that is more reusable.

For example, we could have an object referring to Drawer which supports addition of information and an object Letter which supports retrieval of content. In this case, a bigger problem domain (Drawer) refers to an object (Letter) which handles smaller problem domain. The fact that Drawer can have many letters makes decomposition relation of type "has a".

[[Image:Decomposition.jpg|frame|center|Decomposition]]

In the above example, Drawer object holds an instance variable which refers to Letter object. The bigger problem domain of "Drawer" has now been divided into smaller problem domains, one of which is Letter. Letter behavior is easier to maintain as compared to Drawer and any change in Drawer behavior will not affect Letter's behavior. Moreover, letter object can be part of some other big problem domain also(except of drawer).

===Message Forwarding===

Message Forwarding, also known as interfacing, describes the communication between objects using their public interfaces. Using message forwarding, objects can send and receive messages from each other, which help them to synchronize. Message passing is done using methods, properties and events. Message forwarding using method involves invoking an operation on an object. In response to the message the corresponding method is executed in the object and object may return some values. Message forwarding using property allows object to advertise and allow change in their state information. Events are raised by the objects in response to an internal action. Other objects can subscribe to these so that they can react to an occurrence of the event. An example for vehicles could be an 'ImpactDetected' event subscribed to by one or more 'AirBag' objects.

In some object-oriented programming languages, a message is the means to pass control to an object and if the object responds to the message, which means it has some way to handle that message. In pure object-oriented programming, message passing is performed exclusively through a dynamic dispatch strategy (process of mapping a message to a specific sequence of code at runtime.). Message forwarding techniques for communication between objects makes the interface descriptions with external systems much simpler.

Java employs message forwarding in the form of message calling. Objective C and Smalltalk heavily rely of message passing and use message sending instead of message calling.

As an example for message forwarding, when the object called "joe" (an instance of the driver class), presses the gas pedal, he literally passes an accelerate message to object "my Porsche", which in turn, invokes the "my Porsche" accelerate method.

[[Image:MessagePassing.jpg|frame|center|Message Forwarding]]
Image taken from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

===Delegation===

In OOP, two notions of delegation exist. The older usage refers to passing on the execution to some other object. While new usage refers to using method lookup rules to dispatch so-called self-calls as defined by Lieberman in his 1986 paper "Using Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems".

Example for old definition:

Suppose there are class A and B defined as follows:

class A
{
public:
foo()
{
print("Object A doing the job");
}
}
class B
{
public:
A a;
foo()
{
a.foo();
}
}

Here class B delegates the execution of its function foo to an object of class A.

Example of new definition:

class A
{
foo() {
self.bar() // self is also known under the names "current" and "this" in other languages
}
bar() {
print("a.bar")
}
}
class B
{
delegationlink A a
foo() {
a.foo() // call foo() on the a-instance
}
bar() {
print("b.bar")
}
}
a = new A()
b = new B(a) // establish delegation between two objects

calling b.foo() will result in b.bar to be printed. Older definition would have resulted in a.bar.

Example taken from http://www.wordiq.com/definition/Delegation_(programming)

It should be noted that support for delegation as new definition is not widely supported in programming languages, though exceptions exists in the form of the languages Self and Kniesels Lava.

Delegation can be viewed as a relationship between objects where one object forwards certain method calls to another object, called its delegate. Delegation is based on dynamic binding, as it requires that a given method call can invoke different segments of code at runtime. Delegation forms the core of design patterns like wrapper design pattern.

==Comparing Inheritance with Others==

As discussed above, inheritance forms a basic way to compartmentalize and code reuse in object oriented programming. However in some cases, inheritance may not be the best way to approach the problem. Some of the limitations of inheritance are:

* When single inheritance is used, an object can only inherit from a single object. If in the above given inheritance example, single inheritance is used Teaching assistant can either be student or a teacher but not both. Using multiple inheritance solves the problem (as in above example), but it can still inherit from each super class only once and hence a Teaching assistant cannot be a student at two different institutions. Also, multiple inheritance creates problem when a same trait is inherited from two different parents.

* Inheritance hierarchy for an object is fixed at the time of instantiation and cannot be changed. In the above example, Student object cannot change to Teacher while retaining characteristics of an Employee. Hence inheritance locks the original design which becomes difficult to change.

* When any client has access of any of the subclass, it automatically has access to the data which is part of the super class, even if data is private to the parent class. E.g in above example, access to student class gives an access of person class and can lead to unwarranted change of Person class properties.

Hence, it can be said that inheritance is not always a good approach for all the problems and some of the elements of OOP discussed above can be good alternatives for inheritance.

===Decomposition and Inheritance===

Traditionally, inheritance is used when there is a "is a" relationship between objects and decomposition when there is "has a" relationship between objects. An example of inheritance where "Programmer" and "Manager" extend "Employee" (is a relationship) can also be looked as, "Programmer" as a set of duties that an "Employee" may have, and this same employee may later change duties for "Manager" duties (has a relationship). Hence the way we design our system makes decomposition or inheritance favorable. But as a rule of thumb, object oriented design based on decomposition is more stable when parent objects are likely to change. In our decomposition example considered above, even if drawer functionality and role change drastically basic participants (letter object in this case) are likely to remain same and can be used in some other domain also. Hence, decomposition is used when there is lot of code reuse and/or polymorphism. By separating behaviors from the primary class hierarchy and including specific behavior for the child class, child class is not restricted by behavior of its ancestral classes.
Inheritance should be preferred when there is significant interaction between parent and its child classes. If parent must call back to child methods, then inheritance is usually the good answer. As an example, consider a class apple which inherits from its super class Fruit. Any change in the behavior of fruit will directly effect Orange which "is a" type of fruit. When super class and its subclasses are meant to be tied together inheritance should be used as it allows us to take advantage of dynamic binding and polymorphism.

===Message Passing and Inheritance===

Object oriented programs generally have two kinds of structures; one style is to have an inheritance hierarchy. The other is to have a pattern of message passing. Inheritance structure represents how different objects are related by their types. For example, in the program that models water use, Faucets and WaterPipes can be modeled as same kind of objects, except that Faucets can be turned on and off and WaterPipes can have multiple connections to other WaterPipes. Thus Faucet and WaterPipe objects can inherit from a common antecedent with all common traits and will have their specific properties in their classes.
Message passing structure represents how program works. For example, in the above mentioned program for water use, Appliance objects might send messages requesting water to Valves, and Valves to WaterPipes. The Building object can communicate through messages with all the Valves, Faucets, and WaterPipes, but not directly with Appliances. The connection between different objects which know whom to contact and pass message defines program structure.
[Example taken from: http://objc.toodarkpark.net/oop.html ]

There are situations where inheritance structure for the program may not work well. For example, consider an object Room which defines characteristics for the room. Room can be cubiod in shape so Object Room can inherit characteristics from Cuboid Object. However problem arise when different Rooms can have different shapes say cylindrical. Inheriting from both Cubiod and Cylindrical Objects will make Room both cylindrical and cubiod, instead of being cylindrical or cubiod in shape. Hence inheritance would not work here. A better way would be to have separate objects Shape and Room and shape object points to Cubiod or Cylindrical object. A Room object can interact with object Shape by passing messages. In this design approach access to all of other object facilities is not granted, instead an object needs to pass messages to access attributes and operations of the other class. Thus message passing exposes only the required interface of the object.

===Delegation and Inheritance===

Delegation is closely related to message forwarding and as discussed in above section, just like message forwarding and inheritance, there can be two kinds of structures for programs involving inheritance and delegation. Delegation supports the prototype-based programming model and inheritance, class based programming model. Inheritance schemes involve two kinds of objects, classes and instances. A class defines what is known as structure of its instances. Each instance maintains its values of attributes defined in the structure and the state of an object is given by the values of its attributes at any point in time. In delegation, there is only one type of object which represents real-world items. These objects are often taken to be “instances without classes.” This independence of all objects in delegation scheme allows delegation to capture the behavior of inheritance to some extent.

When it comes to building large systems with many objects, using an inheritance based system seems to make more sense. This is due to the fact that inheritance based system forces programmer to think and place some common behavior in super classes. In delegation based system, common behavior can be put in a single class, but this results in dependencies between objects and changing one object might result in errors in another object which is delegating the job to the first object.

In the nutshell, following are the situations when using delegations over inheritance is beneficial:

* When an object can play more than one role in the system, then sub-classing is not advisable, as the numbers of combinations are very large. Delegation would result in fewer classes and work best in this case.
* Inheritance, as discussed before, is a static relationship. If a class inherits from another class, this relationship cannot be changed at run time. On the other hand, Delegation is a dynamic relationship that can be changed at runtime.
* If an object needs to hide a function or an attribute from its super-class, then it is not a right candidate for inheritance. Delegation is an appropriate solution for this situation.
* If there’s no control over the class which is being inherited, it is good to use delegation over inheritance as inheritance has the risk that classes may have to be changed due to changes in parent class over which there’s no control.
* Delegation, unlike Inheritance, doesn’t force an object to accept all the methods of the super class, an object can only provide those methods that really make sense.

However, delegation has certain disadvantages over inheritance

* Delegation results in large number of objects in memory, which could result in performance issue when the objects in memory grow fast due to inefficient handling or disposal of objects.
* Delegation results in code more difficult to read understand and debug. This is due to the fact that delegation involves certain level of object indirection.

==Conclusion==

OOP has many features which makes it a favorable option in many problem domains. However, based on the requirements of the application, what is needed are subtle design decisions about which feature of OOP is a best option. Inheritance based models seem a very attractive choice for all object oriented applications, which is not true. As discussed in this article, techniques like decomposition, delegation and message forwarding do compass better alternatives for inheritance for some object oriented applications. What is needed is a perspective to see which OOP concept fits best in the overall picture.

==References==

[1] Thomas K¨uhne, A Functional Pattern System for Object-Oriented Design. Retrieved 4th October 2010, from http://homepages.mcs.vuw.ac.nz/~tk/fps/fps-sans-escher.pdf

[2] Composition vs Inheritance in Java. Retrieved 4 October 2010, from http://www.mapleshirefarm.com/eric/CompositionVsInheritance.html

[3] Inheritance versus composition: Which one should you choose, retrieved 4th October 2010, from http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=2

[4] Inheritance. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)

[5] Decomposition. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Decomposition_(computer_science)

[6] Object Oriented Programming Concepts, Retrieved 4th October 2010, from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

[7] Message Passing. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Message_passing

[8] Object Oriented Programming, Retrieved 4th October 2010, from http://objc.toodarkpark.net/oop.html

[9] Meilir Page-Jones, Larry L. Constantine, Fundamentals of object-oriented design in UML, Addison-Wesley Professional,1999

[10] Lynn Andrea Stein,Delegation is inheritance in Conference on Object Oriented Programming Systems Languages and Applications, (Orlando, Florida, 1987), ACM, 138 - 146 Year of Publication: 1987

[11] Delegation Definition. Retrieved 5th October from , http://www.wordiq.com/definition/Delegation_(programming)

[12] Manish Sharma, When Not to use Inheritance but Delegation. Retrieved 5th october 2010, from http://developergeeks.com/article/16/when-not-to-use-inheritance-but-delegation

[13] Peter Bosch, Inheritance vs. delegation: Is one better than the other? Unpublished. Retrieved 5th october 2010, from www.python.org/ftp/python/doc/delegation.ps

CSC/ECE 517 Fall 2010/ch3 S30 SK

2010-10-06T17:28:15Z

Sumi2509: /* Introduction */

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

==Introduction==

Object oriented programming (OOP) paradigm is based upon what is known as "objects", which represent real world concepts. One of the principal advantages of object-oriented programming over procedural programming is that they enable programmers to create modules that do not need to be changed when a new type of object is added.
Some basic concepts/features which are part of OOP are classes, methods, instances, encapsulation, inheritance, message forwarding, decomposition, delegation etc. This article discusses four of these concepts, namely, inheritance, message forwarding, decomposition and delegation. Specifically, comparison between inheritance and message forwarding, decomposition & delegation is made to understand when each of these can be considered as a potential alternative for inheritance, which forms core of OOP.

==Elements of OOP==

Some of the elements of OOP, relevant to the topic are discussed below

===Inheritance===

In OOP, inheritance is a way to compartmentalize the code by creating objects which are based on previously created objects. In classical inheritance where objects are defined by classes, parent class is known as super class and the one which inherits behavior is known as sub class. Inheritance is used to relate two or more objects to each other. With the use of inheritance, methods and instance variables of the parent object are available for use in all of its child objects.
[[Image:Inheritance.jpg|frame|center|Inheritance Hierarchy]]

In the above example, student and teacher both inherit characters from Person object and Teaching Assistant inherits characteristics from Teacher and Student and in turn form Person.

===Decomposition===

Decomposition, also known as factoring is the process by which a big, complex problem is broken into smaller problems which are easier to attack, conceive and manage. Object Oriented Decomposition breaks large problem domain, based on classification entities, into smaller objects which represents some part of the problem. Object oriented decomposition works especially fine due to the concept of procedural abstraction which makes a problem easier to solve. Object-oriented decomposition results in a product that is more reusable.

For example, we could have an object referring to Drawer which supports addition of information and an object Letter which supports retrieval of content. In this case, a bigger problem domain (Drawer) refers to an object (Letter) which handles smaller problem domain. The fact that Drawer can have many letters makes decomposition relation of type "has a".

[[Image:Decomposition.jpg|frame|center|Decomposition]]

In the above example, Drawer object holds an instance variable which refers to Letter object. The bigger problem domain of "Drawer" has now been divided into smaller problem domains, one of which is Letter. Letter behavior is easier to maintain as compared to Drawer and any change in Drawer behavior will not affect Letter's behavior. Moreover, letter object can be part of some other big problem domain also(except of drawer).

===Message Forwarding===

Message Forwarding, also known as interfacing, describes the communication between objects using their public interfaces. Using message forwarding, objects can send and receive messages from each other, which help them to synchronize. Message passing is done using methods, properties and events. Message forwarding using method involves invoking an operation on an object. In response to the message the corresponding method is executed in the object and object may return some values. Message forwarding using property allows object to advertise and allow change in their state information. Events are raised by the objects in response to an internal action. Other objects can subscribe to these so that they can react to an occurrence of the event. An example for vehicles could be an 'ImpactDetected' event subscribed to by one or more 'AirBag' objects.

In some object-oriented programming languages, a message is the means to pass control to an object and if the object responds to the message, which means it has some way to handle that message. In pure object-oriented programming, message passing is performed exclusively through a dynamic dispatch strategy (process of mapping a message to a specific sequence of code at runtime.). Message forwarding techniques for communication between objects makes the interface descriptions with external systems much simpler.

Java employs message forwarding in the form of message calling. Objective C and Smalltalk heavily rely of message passing and use message sending instead of message calling.

As an example for message forwarding, when the object called "joe" (an instance of the driver class), presses the gas pedal, he literally passes an accelerate message to object "my Porsche", which in turn, invokes the "my Porsche" accelerate method.

[[Image:MessagePassing.jpg|frame|center|Message Forwarding]]
Image taken from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

===Delegation===

In OOP, two notions of delegation exist. The older usage refers to passing on the execution to some other object. While new usage refers to using method lookup rules to dispatch so-called self-calls as defined by Lieberman in his 1986 paper "Using Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems".

Example for old definition:

Suppose there are class A and B defined as follows:

class A
{
public:
foo()
{
print("Object A doing the job");
}
}
class B
{
public:
A a;
foo()
{
a.foo();
}
}

Here class B delegates the execution of its function foo to an object of class A.

Example of new definition:

class A
{
foo() {
self.bar() // self is also known under the names "current" and "this" in other languages
}
bar() {
print("a.bar")
}
}
class B
{
delegationlink A a
foo() {
a.foo() // call foo() on the a-instance
}
bar() {
print("b.bar")
}
}
a = new A()
b = new B(a) // establish delegation between two objects

calling b.foo() will result in b.bar to be printed. Older definition would have resulted in a.bar.

Example taken from http://www.wordiq.com/definition/Delegation_(programming)

It should be noted that support for delegation as new definition is not widely supported in programming languages, though exceptions exists in the form of the languages Self and Kniesels Lava.

Delegation can be viewed as a relationship between objects where one object forwards certain method calls to another object, called its delegate. Delegation is based on dynamic binding, as it requires that a given method call can invoke different segments of code at runtime. Delegation forms the core of design patterns like wrapper design pattern.

==Comparing Inheritance with Others==

As discussed above, inheritance forms a basic way to compartmentalize and code reuse in object oriented programming. However in some cases, inheritance may not be the best way to approach the problem. Some of the limitations of inheritance are:

* When single inheritance is used, an object can only inherit from a single object. If in the above given inheritance example, single inheritance is used Teaching assistant can either be student or a teacher but not both. Using multiple inheritance solves the problem (as in above example), but it can still inherit from each super class only once and hence a Teaching assistant cannot be a student at two different institutions. Also, multiple inheritance creates problem when a same trait is inherited from two different parents.

* Inheritance hierarchy for an object is fixed at the time of instantiation and cannot be changed. In the above example, Student object cannot change to Teacher while retaining characteristics of an Employee. Hence inheritance locks the original design which becomes difficult to change.

* When any client has access of any of the subclass, it automatically has access to the data which is part of the super class, even if data is private to the parent class. E.g in above example, access to student class gives an access of person class and can lead to unwarranted change of Person class properties.

Hence, it can be said that inheritance is not always a good approach for all the problems and some of the elements of OOP discussed above can be good alternatives for inheritance.

===Decomposition and Inheritance===

Traditionally, inheritance is used when there is a "is a" relationship between objects and decomposition when there is "has a" relationship between objects. An example of inheritance where "Programmer" and "Manager" extend "Employee" (is a relationship) can also be looked as, "Programmer" as a set of duties that an "Employee" may have, and this same employee may later change duties for "Manager" duties (has a relationship). Hence the way we design our system makes decomposition or inheritance favorable. But as a rule of thumb, object oriented design based on decomposition is more stable when parent objects are likely to change. In our decomposition example considered above, even if drawer functionality and role change drastically basic participants (letter object in this case) are likely to remain same and can be used in some other domain also. Hence, decomposition is used when there is lot of code reuse and/or polymorphism. By separating behaviors from the primary class hierarchy and including specific behavior for the child class, child class is not restricted by behavior of its ancestral classes.
Inheritance should be preferred when there is significant interaction between parent and its child classes. If parent must call back to child methods, then inheritance is usually the good answer. As an example, consider a class apple which inherits from its super class Fruit. Any change in the behavior of fruit will directly effect Orange which "is a" type of fruit. When super class and its subclasses are meant to be tied together inheritance should be used as it allows us to take advantage of dynamic binding and polymorphism.

===Message Passing and Inheritance===

Object oriented programs generally have two kinds of structures; one style is to have an inheritance hierarchy. The other is to have a pattern of message passing. Inheritance structure represents how different objects are related by their types. For example, in the program that models water use, Faucets and WaterPipes can be modeled as same kind of objects, except that Faucets can be turned on and off and WaterPipes can have multiple connections to other WaterPipes. Thus Faucet and WaterPipe objects can inherit from a common antecedent with all common traits and will have their specific properties in their classes.
Message passing structure represents how program works. For example, in the above mentioned program for water use, Appliance objects might send messages requesting water to Valves, and Valves to WaterPipes. The Building object can communicate through messages with all the Valves, Faucets, and WaterPipes, but not directly with Appliances. The connection between different objects which know whom to contact and pass message defines program structure.
[Example taken from: http://objc.toodarkpark.net/oop.html ]

There are situations where inheritance structure for the program may not work well. For example, consider an object Room which defines characteristics for the room. Room can be cubiod in shape so Object Room can inherit characteristics from Cuboid Object. However problem arise when different Rooms can have different shapes say cylindrical. Inheriting from both Cubiod and Cylindrical Objects will make Room both cylindrical and cubiod, instead of being cylindrical or cubiod in shape. Hence inheritance would not work here. A better way would be to have separate objects Shape and Room and shape object points to Cubiod or Cylindrical object. A Room object can interact with object Shape by passing messages. In this design approach access to all of other object facilities is not granted, instead an object needs to pass messages to access attributes and operations of the other class. Thus message passing exposes only the required interface of the object.

===Delegation and Inheritance===

Delegation is closely related to message forwarding and as discussed in above section, just like message forwarding and inheritance, there can be two kinds of structures for programs involving inheritance and delegation. Delegation supports the prototype-based programming model and inheritance, class based programming model. Inheritance schemes involve two kinds of objects, classes and instances. A class defines what is known as structure of its instances. Each instance maintains its values of attributes defined in the structure and the state of an object is given by the values of its attributes at any point in time. In delegation, there is only one type of object which represents real-world items. These objects are often taken to be “instances without classes.” This independence of all objects in delegation scheme allows delegation to capture the behavior of inheritance to some extent.

When it comes to building large systems with many objects, using an inheritance based system seems to make more sense. This is due to the fact that inheritance based system forces programmer to think and place some common behavior in super classes. In delegation based system, common behavior can be put in a single class, but this results in dependencies between objects and changing one object might result in errors in another object which is delegating the job to the first object.

In the nutshell, following are the situations when using delegations over inheritance is beneficial:

* When an object can play more than one role in the system, then sub-classing is not advisable, as the numbers of combinations are very large. Delegation would result in fewer classes and work best in this case.
* Inheritance, as discussed before, is a static relationship. If a class inherits from another class, this relationship cannot be changed at run time. On the other hand, Delegation is a dynamic relationship that can be changed at runtime.
* If an object needs to hide a function or an attribute from its super-class, then it is not a right candidate for inheritance. Delegation is an appropriate solution for this situation.
* If there’s no control over the class which is being inherited, it is good to use delegation over inheritance as inheritance has the risk that classes may have to be changed due to changes in parent class over which there’s no control.
* Delegation, unlike Inheritance, doesn’t force an object to accept all the methods of the super class, an object can only provide those methods that really make sense.

However, delegation has certain disadvantages over inheritance

* Delegation results in large number of objects in memory, which could result in performance issue when the objects in memory grow fast due to inefficient handling or disposal of objects.
* Delegation results in code more difficult to read understand and debug. This is due to the fact that delegation involves certain level of object indirection.

==Conclusion==

OOP has many features which makes it a favorable option in many problem domains. However, based on the requirements of the application, what is needed are subtle design decisions about which feature of OOP is a best option. Inheritance based models seem a very attractive choice for all object oriented applications, which is not true. As discussed in this article, techniques like decomposition, delegation and message forwarding do compass better alternatives for inheritance for some object oriented applications. What is needed is a perspective to see which OOP concept fits best in the overall picture.

==References==

[1] Thomas K¨uhne, A Functional Pattern System for Object-Oriented Design. Retrieved 4th October 2010, from http://homepages.mcs.vuw.ac.nz/~tk/fps/fps-sans-escher.pdf

[2] Composition vs Inheritance in Java. Retrieved 4 October 2010, from http://www.mapleshirefarm.com/eric/CompositionVsInheritance.html

[3] Inheritance versus composition: Which one should you choose, retrieved 4th October 2010, from http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=2

[4] Inheritance. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)

[5] Decomposition. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Decomposition_(computer_science)

[6] Object Oriented Programming Concepts, Retrieved 4th October 2010, from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

[7] Message Passing. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Message_passing

[8] Object Oriented Programming, Retrieved 4th October 2010, from http://objc.toodarkpark.net/oop.html

[9] Meilir Page-Jones, Larry L. Constantine, Fundamentals of object-oriented design in UML, Addison-Wesley Professional,1999

[10] Lynn Andrea Stein,Delegation is inheritance in Conference on Object Oriented Programming Systems Languages and Applications, (Orlando, Florida, 1987), ACM, 138 - 146 Year of Publication: 1987

[11] Delegation Definition. Retrieved 5th October from , http://www.wordiq.com/definition/Delegation_(programming)

[12] Manish Sharma, When Not to use Inheritance but Delegation. Retrieved 5th october 2010, from http://developergeeks.com/article/16/when-not-to-use-inheritance-but-delegation

[13] Peter Bosch, Inheritance vs. delegation: Is one better than the other? Unpublished. Retrieved 5th october 2010, from www.python.org/ftp/python/doc/delegation.ps

CSC/ECE 517 Fall 2010/ch3 S30 SK

2010-10-06T17:24:30Z

Sumi2509: /* References */

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

==Introduction==

Object oriented programming (OOP) paradigm is based upon what is known as "objects" which represent real world concepts. One of the principal advantages of object-oriented programming over procedural programming is that they enable programmers to create modules that do not need to be changed when a new type of object is added.
Some basic concepts/features which are part of OOP are classes, methods, instances, encapsulation, inheritance, message forwarding, decomposition, delegation etc. This article discusses four of these concepts, namely, inheritance, message forwarding, decomposition and delegation. Specifically, comparison between inheritance and message forwarding, decomposition & delegation is made to understand when each of these can be considered as a potential alternative for inheritance, which forms core of OOP.

==Elements of OOP==

Some of the elements of OOP, relevant to the topic are discussed below

===Inheritance===

In OOP, inheritance is a way to compartmentalize the code by creating objects which are based on previously created objects. In classical inheritance where objects are defined by classes, parent class is known as super class and the one which inherits behavior is known as sub class. Inheritance is used to relate two or more objects to each other. With the use of inheritance, methods and instance variables of the parent object are available for use in all of its child objects.
[[Image:Inheritance.jpg|frame|center|Inheritance Hierarchy]]

In the above example, student and teacher both inherit characters from Person object and Teaching Assistant inherits characteristics from Teacher and Student and in turn form Person.

===Decomposition===

Decomposition, also known as factoring is the process by which a big, complex problem is broken into smaller problems which are easier to attack, conceive and manage. Object Oriented Decomposition breaks large problem domain, based on classification entities, into smaller objects which represents some part of the problem. Object oriented decomposition works especially fine due to the concept of procedural abstraction which makes a problem easier to solve. Object-oriented decomposition results in a product that is more reusable.

For example, we could have an object referring to Drawer which supports addition of information and an object Letter which supports retrieval of content. In this case, a bigger problem domain (Drawer) refers to an object (Letter) which handles smaller problem domain. The fact that Drawer can have many letters makes decomposition relation of type "has a".

[[Image:Decomposition.jpg|frame|center|Decomposition]]

In the above example, Drawer object holds an instance variable which refers to Letter object. The bigger problem domain of "Drawer" has now been divided into smaller problem domains, one of which is Letter. Letter behavior is easier to maintain as compared to Drawer and any change in Drawer behavior will not affect Letter's behavior. Moreover, letter object can be part of some other big problem domain also(except of drawer).

===Message Forwarding===

Message Forwarding, also known as interfacing, describes the communication between objects using their public interfaces. Using message forwarding, objects can send and receive messages from each other, which help them to synchronize. Message passing is done using methods, properties and events. Message forwarding using method involves invoking an operation on an object. In response to the message the corresponding method is executed in the object and object may return some values. Message forwarding using property allows object to advertise and allow change in their state information. Events are raised by the objects in response to an internal action. Other objects can subscribe to these so that they can react to an occurrence of the event. An example for vehicles could be an 'ImpactDetected' event subscribed to by one or more 'AirBag' objects.

In some object-oriented programming languages, a message is the means to pass control to an object and if the object responds to the message, which means it has some way to handle that message. In pure object-oriented programming, message passing is performed exclusively through a dynamic dispatch strategy (process of mapping a message to a specific sequence of code at runtime.). Message forwarding techniques for communication between objects makes the interface descriptions with external systems much simpler.

Java employs message forwarding in the form of message calling. Objective C and Smalltalk heavily rely of message passing and use message sending instead of message calling.

As an example for message forwarding, when the object called "joe" (an instance of the driver class), presses the gas pedal, he literally passes an accelerate message to object "my Porsche", which in turn, invokes the "my Porsche" accelerate method.

[[Image:MessagePassing.jpg|frame|center|Message Forwarding]]
Image taken from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

===Delegation===

In OOP, two notions of delegation exist. The older usage refers to passing on the execution to some other object. While new usage refers to using method lookup rules to dispatch so-called self-calls as defined by Lieberman in his 1986 paper "Using Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems".

Example for old definition:

Suppose there are class A and B defined as follows:

class A
{
public:
foo()
{
print("Object A doing the job");
}
}
class B
{
public:
A a;
foo()
{
a.foo();
}
}

Here class B delegates the execution of its function foo to an object of class A.

Example of new definition:

class A
{
foo() {
self.bar() // self is also known under the names "current" and "this" in other languages
}
bar() {
print("a.bar")
}
}
class B
{
delegationlink A a
foo() {
a.foo() // call foo() on the a-instance
}
bar() {
print("b.bar")
}
}
a = new A()
b = new B(a) // establish delegation between two objects

calling b.foo() will result in b.bar to be printed. Older definition would have resulted in a.bar.

Example taken from http://www.wordiq.com/definition/Delegation_(programming)

It should be noted that support for delegation as new definition is not widely supported in programming languages, though exceptions exists in the form of the languages Self and Kniesels Lava.

Delegation can be viewed as a relationship between objects where one object forwards certain method calls to another object, called its delegate. Delegation is based on dynamic binding, as it requires that a given method call can invoke different segments of code at runtime. Delegation forms the core of design patterns like wrapper design pattern.

==Comparing Inheritance with Others==

As discussed above, inheritance forms a basic way to compartmentalize and code reuse in object oriented programming. However in some cases, inheritance may not be the best way to approach the problem. Some of the limitations of inheritance are:

* When single inheritance is used, an object can only inherit from a single object. If in the above given inheritance example, single inheritance is used Teaching assistant can either be student or a teacher but not both. Using multiple inheritance solves the problem (as in above example), but it can still inherit from each super class only once and hence a Teaching assistant cannot be a student at two different institutions. Also, multiple inheritance creates problem when a same trait is inherited from two different parents.

* Inheritance hierarchy for an object is fixed at the time of instantiation and cannot be changed. In the above example, Student object cannot change to Teacher while retaining characteristics of an Employee. Hence inheritance locks the original design which becomes difficult to change.

* When any client has access of any of the subclass, it automatically has access to the data which is part of the super class, even if data is private to the parent class. E.g in above example, access to student class gives an access of person class and can lead to unwarranted change of Person class properties.

Hence, it can be said that inheritance is not always a good approach for all the problems and some of the elements of OOP discussed above can be good alternatives for inheritance.

===Decomposition and Inheritance===

Traditionally, inheritance is used when there is a "is a" relationship between objects and decomposition when there is "has a" relationship between objects. An example of inheritance where "Programmer" and "Manager" extend "Employee" (is a relationship) can also be looked as, "Programmer" as a set of duties that an "Employee" may have, and this same employee may later change duties for "Manager" duties (has a relationship). Hence the way we design our system makes decomposition or inheritance favorable. But as a rule of thumb, object oriented design based on decomposition is more stable when parent objects are likely to change. In our decomposition example considered above, even if drawer functionality and role change drastically basic participants (letter object in this case) are likely to remain same and can be used in some other domain also. Hence, decomposition is used when there is lot of code reuse and/or polymorphism. By separating behaviors from the primary class hierarchy and including specific behavior for the child class, child class is not restricted by behavior of its ancestral classes.
Inheritance should be preferred when there is significant interaction between parent and its child classes. If parent must call back to child methods, then inheritance is usually the good answer. As an example, consider a class apple which inherits from its super class Fruit. Any change in the behavior of fruit will directly effect Orange which "is a" type of fruit. When super class and its subclasses are meant to be tied together inheritance should be used as it allows us to take advantage of dynamic binding and polymorphism.

===Message Passing and Inheritance===

Object oriented programs generally have two kinds of structures; one style is to have an inheritance hierarchy. The other is to have a pattern of message passing. Inheritance structure represents how different objects are related by their types. For example, in the program that models water use, Faucets and WaterPipes can be modeled as same kind of objects, except that Faucets can be turned on and off and WaterPipes can have multiple connections to other WaterPipes. Thus Faucet and WaterPipe objects can inherit from a common antecedent with all common traits and will have their specific properties in their classes.
Message passing structure represents how program works. For example, in the above mentioned program for water use, Appliance objects might send messages requesting water to Valves, and Valves to WaterPipes. The Building object can communicate through messages with all the Valves, Faucets, and WaterPipes, but not directly with Appliances. The connection between different objects which know whom to contact and pass message defines program structure.
[Example taken from: http://objc.toodarkpark.net/oop.html ]

There are situations where inheritance structure for the program may not work well. For example, consider an object Room which defines characteristics for the room. Room can be cubiod in shape so Object Room can inherit characteristics from Cuboid Object. However problem arise when different Rooms can have different shapes say cylindrical. Inheriting from both Cubiod and Cylindrical Objects will make Room both cylindrical and cubiod, instead of being cylindrical or cubiod in shape. Hence inheritance would not work here. A better way would be to have separate objects Shape and Room and shape object points to Cubiod or Cylindrical object. A Room object can interact with object Shape by passing messages. In this design approach access to all of other object facilities is not granted, instead an object needs to pass messages to access attributes and operations of the other class. Thus message passing exposes only the required interface of the object.

===Delegation and Inheritance===

Delegation is closely related to message forwarding and as discussed in above section, just like message forwarding and inheritance, there can be two kinds of structures for programs involving inheritance and delegation. Delegation supports the prototype-based programming model and inheritance, class based programming model. Inheritance schemes involve two kinds of objects, classes and instances. A class defines what is known as structure of its instances. Each instance maintains its values of attributes defined in the structure and the state of an object is given by the values of its attributes at any point in time. In delegation, there is only one type of object which represents real-world items. These objects are often taken to be “instances without classes.” This independence of all objects in delegation scheme allows delegation to capture the behavior of inheritance to some extent.

When it comes to building large systems with many objects, using an inheritance based system seems to make more sense. This is due to the fact that inheritance based system forces programmer to think and place some common behavior in super classes. In delegation based system, common behavior can be put in a single class, but this results in dependencies between objects and changing one object might result in errors in another object which is delegating the job to the first object.

In the nutshell, following are the situations when using delegations over inheritance is beneficial:

* When an object can play more than one role in the system, then sub-classing is not advisable, as the numbers of combinations are very large. Delegation would result in fewer classes and work best in this case.
* Inheritance, as discussed before, is a static relationship. If a class inherits from another class, this relationship cannot be changed at run time. On the other hand, Delegation is a dynamic relationship that can be changed at runtime.
* If an object needs to hide a function or an attribute from its super-class, then it is not a right candidate for inheritance. Delegation is an appropriate solution for this situation.
* If there’s no control over the class which is being inherited, it is good to use delegation over inheritance as inheritance has the risk that classes may have to be changed due to changes in parent class over which there’s no control.
* Delegation, unlike Inheritance, doesn’t force an object to accept all the methods of the super class, an object can only provide those methods that really make sense.

However, delegation has certain disadvantages over inheritance

* Delegation results in large number of objects in memory, which could result in performance issue when the objects in memory grow fast due to inefficient handling or disposal of objects.
* Delegation results in code more difficult to read understand and debug. This is due to the fact that delegation involves certain level of object indirection.

==Conclusion==

OOP has many features which makes it a favorable option in many problem domains. However, based on the requirements of the application, what is needed are subtle design decisions about which feature of OOP is a best option. Inheritance based models seem a very attractive choice for all object oriented applications, which is not true. As discussed in this article, techniques like decomposition, delegation and message forwarding do compass better alternatives for inheritance for some object oriented applications. What is needed is a perspective to see which OOP concept fits best in the overall picture.

==References==

[1] Thomas K¨uhne, A Functional Pattern System for Object-Oriented Design. Retrieved 4th October 2010, from http://homepages.mcs.vuw.ac.nz/~tk/fps/fps-sans-escher.pdf

[2] Composition vs Inheritance in Java. Retrieved 4 October 2010, from http://www.mapleshirefarm.com/eric/CompositionVsInheritance.html

[3] Inheritance versus composition: Which one should you choose, retrieved 4th October 2010, from http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=2

[4] Inheritance. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)

[5] Decomposition. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Decomposition_(computer_science)

[6] Object Oriented Programming Concepts, Retrieved 4th October 2010, from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

[7] Message Passing. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Message_passing

[8] Object Oriented Programming, Retrieved 4th October 2010, from http://objc.toodarkpark.net/oop.html

[9] Meilir Page-Jones, Larry L. Constantine, Fundamentals of object-oriented design in UML, Addison-Wesley Professional,1999

[10] Lynn Andrea Stein,Delegation is inheritance in Conference on Object Oriented Programming Systems Languages and Applications, (Orlando, Florida, 1987), ACM, 138 - 146 Year of Publication: 1987

[11] Delegation Definition. Retrieved 5th October from , http://www.wordiq.com/definition/Delegation_(programming)

[12] Manish Sharma, When Not to use Inheritance but Delegation. Retrieved 5th october 2010, from http://developergeeks.com/article/16/when-not-to-use-inheritance-but-delegation

[13] Peter Bosch, Inheritance vs. delegation: Is one better than the other? Unpublished. Retrieved 5th october 2010, from www.python.org/ftp/python/doc/delegation.ps

CSC/ECE 517 Fall 2010/ch3 S30 SK

2010-10-06T03:03:56Z

Sumi2509:

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

==Introduction==

Object oriented programming (OOP) paradigm is based upon what is known as "objects" which represent real world concepts. One of the principal advantages of object-oriented programming over procedural programming is that they enable programmers to create modules that do not need to be changed when a new type of object is added.
Some basic concepts/features which are part of OOP are classes, methods, instances, encapsulation, inheritance, message forwarding, decomposition, delegation etc. This article discusses four of these concepts, namely, inheritance, message forwarding, decomposition and delegation. Specifically, comparison between inheritance and message forwarding, decomposition & delegation is made to understand when each of these can be considered as a potential alternative for inheritance, which forms core of OOP.

==Elements of OOP==

Some of the elements of OOP, relevant to the topic are discussed below

===Inheritance===

In OOP, inheritance is a way to compartmentalize the code by creating objects which are based on previously created objects. In classical inheritance where objects are defined by classes, parent class is known as super class and the one which inherits behavior is known as sub class. Inheritance is used to relate two or more objects to each other. With the use of inheritance, methods and instance variables of the parent object are available for use in all of its child objects.
[[Image:Inheritance.jpg|frame|center|Inheritance Hierarchy]]

In the above example, student and teacher both inherit characters from Person object and Teaching Assistant inherits characteristics from Teacher and Student and in turn form Person.

===Decomposition===

Decomposition, also known as factoring is the process by which a big, complex problem is broken into smaller problems which are easier to attack, conceive and manage. Object Oriented Decomposition breaks large problem domain, based on classification entities, into smaller objects which represents some part of the problem. Object oriented decomposition works especially fine due to the concept of procedural abstraction which makes a problem easier to solve. Object-oriented decomposition results in a product that is more reusable.

For example, we could have an object referring to Drawer which supports addition of information and an object Letter which supports retrieval of content. In this case, a bigger problem domain (Drawer) refers to an object (Letter) which handles smaller problem domain. The fact that Drawer can have many letters makes decomposition relation of type "has a".

[[Image:Decomposition.jpg|frame|center|Decomposition]]

In the above example, Drawer object holds an instance variable which refers to Letter object. The bigger problem domain of "Drawer" has now been divided into smaller problem domains, one of which is Letter. Letter behavior is easier to maintain as compared to Drawer and any change in Drawer behavior will not affect Letter's behavior. Moreover, letter object can be part of some other big problem domain also(except of drawer).

===Message Forwarding===

Message Forwarding, also known as interfacing, describes the communication between objects using their public interfaces. Using message forwarding, objects can send and receive messages from each other, which help them to synchronize. Message passing is done using methods, properties and events. Message forwarding using method involves invoking an operation on an object. In response to the message the corresponding method is executed in the object and object may return some values. Message forwarding using property allows object to advertise and allow change in their state information. Events are raised by the objects in response to an internal action. Other objects can subscribe to these so that they can react to an occurrence of the event. An example for vehicles could be an 'ImpactDetected' event subscribed to by one or more 'AirBag' objects.

In some object-oriented programming languages, a message is the means to pass control to an object and if the object responds to the message, which means it has some way to handle that message. In pure object-oriented programming, message passing is performed exclusively through a dynamic dispatch strategy (process of mapping a message to a specific sequence of code at runtime.). Message forwarding techniques for communication between objects makes the interface descriptions with external systems much simpler.

Java employs message forwarding in the form of message calling. Objective C and Smalltalk heavily rely of message passing and use message sending instead of message calling.

As an example for message forwarding, when the object called "joe" (an instance of the driver class), presses the gas pedal, he literally passes an accelerate message to object "my Porsche", which in turn, invokes the "my Porsche" accelerate method.

[[Image:MessagePassing.jpg|frame|center|Message Forwarding]]
Image taken from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

===Delegation===

In OOP, two notions of delegation exist. The older usage refers to passing on the execution to some other object. While new usage refers to using method lookup rules to dispatch so-called self-calls as defined by Lieberman in his 1986 paper "Using Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems".

Example for old definition:

Suppose there are class A and B defined as follows:

class A
{
public:
foo()
{
print("Object A doing the job");
}
}
class B
{
public:
A a;
foo()
{
a.foo();
}
}

Here class B delegates the execution of its function foo to an object of class A.

Example of new definition:

class A
{
foo() {
self.bar() // self is also known under the names "current" and "this" in other languages
}
bar() {
print("a.bar")
}
}
class B
{
delegationlink A a
foo() {
a.foo() // call foo() on the a-instance
}
bar() {
print("b.bar")
}
}
a = new A()
b = new B(a) // establish delegation between two objects

calling b.foo() will result in b.bar to be printed. Older definition would have resulted in a.bar.

Example taken from http://www.wordiq.com/definition/Delegation_(programming)

It should be noted that support for delegation as new definition is not widely supported in programming languages, though exceptions exists in the form of the languages Self and Kniesels Lava.

Delegation can be viewed as a relationship between objects where one object forwards certain method calls to another object, called its delegate. Delegation is based on dynamic binding, as it requires that a given method call can invoke different segments of code at runtime. Delegation forms the core of design patterns like wrapper design pattern.

==Comparing Inheritance with Others==

As discussed above, inheritance forms a basic way to compartmentalize and code reuse in object oriented programming. However in some cases, inheritance may not be the best way to approach the problem. Some of the limitations of inheritance are:

* When single inheritance is used, an object can only inherit from a single object. If in the above given inheritance example, single inheritance is used Teaching assistant can either be student or a teacher but not both. Using multiple inheritance solves the problem (as in above example), but it can still inherit from each super class only once and hence a Teaching assistant cannot be a student at two different institutions. Also, multiple inheritance creates problem when a same trait is inherited from two different parents.

* Inheritance hierarchy for an object is fixed at the time of instantiation and cannot be changed. In the above example, Student object cannot change to Teacher while retaining characteristics of an Employee. Hence inheritance locks the original design which becomes difficult to change.

* When any client has access of any of the subclass, it automatically has access to the data which is part of the super class, even if data is private to the parent class. E.g in above example, access to student class gives an access of person class and can lead to unwarranted change of Person class properties.

Hence, it can be said that inheritance is not always a good approach for all the problems and some of the elements of OOP discussed above can be good alternatives for inheritance.

===Decomposition and Inheritance===

Traditionally, inheritance is used when there is a "is a" relationship between objects and decomposition when there is "has a" relationship between objects. An example of inheritance where "Programmer" and "Manager" extend "Employee" (is a relationship) can also be looked as, "Programmer" as a set of duties that an "Employee" may have, and this same employee may later change duties for "Manager" duties (has a relationship). Hence the way we design our system makes decomposition or inheritance favorable. But as a rule of thumb, object oriented design based on decomposition is more stable when parent objects are likely to change. In our decomposition example considered above, even if drawer functionality and role change drastically basic participants (letter object in this case) are likely to remain same and can be used in some other domain also. Hence, decomposition is used when there is lot of code reuse and/or polymorphism. By separating behaviors from the primary class hierarchy and including specific behavior for the child class, child class is not restricted by behavior of its ancestral classes.
Inheritance should be preferred when there is significant interaction between parent and its child classes. If parent must call back to child methods, then inheritance is usually the good answer. As an example, consider a class apple which inherits from its super class Fruit. Any change in the behavior of fruit will directly effect Orange which "is a" type of fruit. When super class and its subclasses are meant to be tied together inheritance should be used as it allows us to take advantage of dynamic binding and polymorphism.

===Message Passing and Inheritance===

Object oriented programs generally have two kinds of structures; one style is to have an inheritance hierarchy. The other is to have a pattern of message passing. Inheritance structure represents how different objects are related by their types. For example, in the program that models water use, Faucets and WaterPipes can be modeled as same kind of objects, except that Faucets can be turned on and off and WaterPipes can have multiple connections to other WaterPipes. Thus Faucet and WaterPipe objects can inherit from a common antecedent with all common traits and will have their specific properties in their classes.
Message passing structure represents how program works. For example, in the above mentioned program for water use, Appliance objects might send messages requesting water to Valves, and Valves to WaterPipes. The Building object can communicate through messages with all the Valves, Faucets, and WaterPipes, but not directly with Appliances. The connection between different objects which know whom to contact and pass message defines program structure.
[Example taken from: http://objc.toodarkpark.net/oop.html ]

There are situations where inheritance structure for the program may not work well. For example, consider an object Room which defines characteristics for the room. Room can be cubiod in shape so Object Room can inherit characteristics from Cuboid Object. However problem arise when different Rooms can have different shapes say cylindrical. Inheriting from both Cubiod and Cylindrical Objects will make Room both cylindrical and cubiod, instead of being cylindrical or cubiod in shape. Hence inheritance would not work here. A better way would be to have separate objects Shape and Room and shape object points to Cubiod or Cylindrical object. A Room object can interact with object Shape by passing messages. In this design approach access to all of other object facilities is not granted, instead an object needs to pass messages to access attributes and operations of the other class. Thus message passing exposes only the required interface of the object.

===Delegation and Inheritance===

Delegation is closely related to message forwarding and as discussed in above section, just like message forwarding and inheritance, there can be two kinds of structures for programs involving inheritance and delegation. Delegation supports the prototype-based programming model and inheritance, class based programming model. Inheritance schemes involve two kinds of objects, classes and instances. A class defines what is known as structure of its instances. Each instance maintains its values of attributes defined in the structure and the state of an object is given by the values of its attributes at any point in time. In delegation, there is only one type of object which represents real-world items. These objects are often taken to be “instances without classes.” This independence of all objects in delegation scheme allows delegation to capture the behavior of inheritance to some extent.

When it comes to building large systems with many objects, using an inheritance based system seems to make more sense. This is due to the fact that inheritance based system forces programmer to think and place some common behavior in super classes. In delegation based system, common behavior can be put in a single class, but this results in dependencies between objects and changing one object might result in errors in another object which is delegating the job to the first object.

In the nutshell, following are the situations when using delegations over inheritance is beneficial:

* When an object can play more than one role in the system, then sub-classing is not advisable, as the numbers of combinations are very large. Delegation would result in fewer classes and work best in this case.
* Inheritance, as discussed before, is a static relationship. If a class inherits from another class, this relationship cannot be changed at run time. On the other hand, Delegation is a dynamic relationship that can be changed at runtime.
* If an object needs to hide a function or an attribute from its super-class, then it is not a right candidate for inheritance. Delegation is an appropriate solution for this situation.
* If there’s no control over the class which is being inherited, it is good to use delegation over inheritance as inheritance has the risk that classes may have to be changed due to changes in parent class over which there’s no control.
* Delegation, unlike Inheritance, doesn’t force an object to accept all the methods of the super class, an object can only provide those methods that really make sense.

However, delegation has certain disadvantages over inheritance

* Delegation results in large number of objects in memory, which could result in performance issue when the objects in memory grow fast due to inefficient handling or disposal of objects.
* Delegation results in code more difficult to read understand and debug. This is due to the fact that delegation involves certain level of object indirection.

==Conclusion==

OOP has many features which makes it a favorable option in many problem domains. However, based on the requirements of the application, what is needed are subtle design decisions about which feature of OOP is a best option. Inheritance based models seem a very attractive choice for all object oriented applications, which is not true. As discussed in this article, techniques like decomposition, delegation and message forwarding do compass better alternatives for inheritance for some object oriented applications. What is needed is a perspective to see which OOP concept fits best in the overall picture.

==References==

[1] Thomas K¨uhne, A Functional Pattern System for Object-Oriented Design. Retrieved 4th October 2010, from http://homepages.mcs.vuw.ac.nz/~tk/fps/fps-sans-escher.pdf

[2] Composition vs Inheritance in Java. Retrieved 4 October 2010, from http://www.mapleshirefarm.com/eric/CompositionVsInheritance.html

[3] Inheritance versus composition: Which one should you choose, retrieved 4th October 2010, from http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=2

[4] Inheritance. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)

[5] Decomposition. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Decomposition_(computer_science)

[6] Object Oriented Programming Concepts, Retrieved 4th October 2010, from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

[7] Message Passing. Wikipedia, the Free Encyclopedia. Retrieved 3rd October 2010, from http://en.wikipedia.org/wiki/Message_passing

[8] Object Oriented Programming, Retrieved 4th October 2010, from http://objc.toodarkpark.net/oop.html

[9] Meilir Page-Jones, Larry L. Constantine, Fundamentals of object-oriented design in UML, Addison-Wesley Professional,1999

[10] Lynn Andrea Stein,Delegation is inheritance in Conference on Object Oriented Programming Systems Languages and Applications, (Orlando, Florida, 1987), ACM, 138 - 146 Year of Publication: 1987

[11] Delegation Definition. Retrieved 5th October from , http://www.wordiq.com/definition/Delegation_(programming)

[12] Manish Sharma, When Not to use Inheritance but Delegation. Retrieved 5th october 2010, from http://developergeeks.com/article/16/when-not-to-use-inheritance-but-delegation

[13] Peter Bosch, Inheritance vs. delegation: Is one better than the other? Unpublished. www.python.org/ftp/python/doc/delegation.ps

CSC/ECE 517 Fall 2010/ch3 S30 SK

2010-10-06T02:26:36Z

Sumi2509: /* Elements of OOP */

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

==Introduction==

Object oriented programming (OOP) paradigm is based upon what is known as "objects" which represent real world concepts. One of the principal advantages of object-oriented programming over procedural programming is that they enable programmers to create modules that do not need to be changed when a new type of object is added.
Some basic concepts/features which are part of OOP are classes, methods, instances, encapsulation, inheritance, message forwarding, decomposition, delegation etc. This article discusses four of these concepts, namely, inheritance, message forwarding, decomposition and delegation. Specifically, comparison between inheritance and message forwarding, decomposition & delegation is made to understand when each of these can be considered as a potential alternative for inheritance, which forms core of OOP.

==Elements of OOP==

Some of the elements of OOP, relevant to the topic are discussed below

===Inheritance===

In OOP, inheritance is a way to compartmentalize the code by creating objects which are based on previously created objects. In classical inheritance where objects are defined by classes, parent class is known as super class and the one which inherits behavior is known as sub class. Inheritance is used to relate two or more objects to each other. With the use of inheritance, methods and instance variables of the parent object are available for use in all of its child objects.
[[Image:Inheritance.jpg|frame|center|Inheritance Hierarchy]]

In the above example, student and teacher both inherit characters from Person object and Teaching Assistant inherits characteristics from Teacher and Student and in turn form Person.

===Decomposition===

Decomposition, also known as factoring is the process by which a big, complex problem is broken into smaller problems which are easier to attack, conceive and manage. Object Oriented Decomposition breaks large problem domain, based on classification entities, into smaller objects which represents some part of the problem. Object oriented decomposition works especially fine due to the concept of procedural abstraction which makes a problem easier to solve. Object-oriented decomposition results in a product that is more reusable.

For example, we could have an object referring to Drawer which supports addition of information and an object Letter which supports retrieval of content. In this case, a bigger problem domain (Drawer) refers to an object (Letter) which handles smaller problem domain. The fact that Drawer can have many letters makes decomposition relation of type "has a".

[[Image:Decomposition.jpg|frame|center|Decomposition]]

In the above example, Drawer object holds an instance variable which refers to Letter object. The bigger problem domain of "Drawer" has now been divided into smaller problem domains, one of which is Letter. Letter behavior is easier to maintain as compared to Drawer and any change in Drawer behavior will not affect Letter's behavior. Moreover, letter object can be part of some other big problem domain also(except of drawer).

===Message Forwarding===

Message Forwarding, also known as interfacing, describes the communication between objects using their public interfaces. Using message forwarding, objects can send and receive messages from each other, which help them to synchronize. Message passing is done using methods, properties and events. Message forwarding using method involves invoking an operation on an object. In response to the message the corresponding method is executed in the object and object may return some values. Message forwarding using property allows object to advertise and allow change in their state information. Events are raised by the objects in response to an internal action. Other objects can subscribe to these so that they can react to an occurrence of the event. An example for vehicles could be an 'ImpactDetected' event subscribed to by one or more 'AirBag' objects.

In some object-oriented programming languages, a message is the means to pass control to an object and if the object responds to the message, which means it has some way to handle that message. In pure object-oriented programming, message passing is performed exclusively through a dynamic dispatch strategy (process of mapping a message to a specific sequence of code at runtime.). Message forwarding techniques for communication between objects makes the interface descriptions with external systems much simpler.

Java employs message forwarding in the form of message calling. Objective C and Smalltalk heavily rely of message passing and use message sending instead of message calling.

As an example for message forwarding, when the object called "joe" (an instance of the driver class), presses the gas pedal, he literally passes an accelerate message to object "my Porsche", which in turn, invokes the "my Porsche" accelerate method.

[[Image:MessagePassing.jpg|frame|center|Message Forwarding]]
Image taken from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

===Delegation===

In OOP, two notions of delegation exist. The older usage refers to passing on the execution to some other object. While new usage refers to using method lookup rules to dispatch so-called self-calls as defined by Lieberman in his 1986 paper "Using Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems".

Example for old definition:

Suppose there are class A and B defined as follows:

class A
{
public:
foo()
{
print("Object A doing the job");
}
}
class B
{
public:
A a;
foo()
{
a.foo();
}
}

Here class B delegates the execution of its function foo to an object of class A.

Example of new definition:

class A
{
foo() {
self.bar() // self is also known under the names "current" and "this" in other languages
}
bar() {
print("a.bar")
}
}
class B
{
delegationlink A a
foo() {
a.foo() // call foo() on the a-instance
}
bar() {
print("b.bar")
}
}
a = new A()
b = new B(a) // establish delegation between two objects

calling b.foo() will result in b.bar to be printed. Older definition would have resulted in a.bar.

Example taken from http://www.wordiq.com/definition/Delegation_(programming)

It should be noted that support for delegation as new definition is not widely supported in programming languages, though exceptions exists in the form of the languages Self and Kniesels Lava.

Delegation can be viewed as a relationship between objects where one object forwards certain method calls to another object, called its delegate. Delegation is based on dynamic binding, as it requires that a given method call can invoke different segments of code at runtime. Delegation forms the core of design patterns like wrapper design pattern.

==Comparing Inheritance with Others==

As discussed above, inheritance forms a basic way to compartmentalize and code reuse in object oriented programming. However in some cases, inheritance may not be the best way to approach the problem. Some of the limitations of inheritance are:

* When single inheritance is used, an object can only inherit from a single object. If in the above given inheritance example, single inheritance is used Teaching assistant can either be student or a teacher but not both. Using multiple inheritance solves the problem (as in above example), but it can still inherit from each super class only once and hence a Teaching assistant cannot be a student at two different institutions. Also, multiple inheritance creates problem when a same trait is inherited from two different parents.

* Inheritance hierarchy for an object is fixed at the time of instantiation and cannot be changed. In the above example, Student object cannot change to Teacher while retaining characteristics of an Employee. Hence inheritance locks the original design which becomes difficult to change.

* When any client has access of any of the subclass, it automatically has access to the data which is part of the super class, even if data is private to the parent class. E.g in above example, access to student class gives an access of person class and can lead to unwarranted change of Person class properties.

Hence, it can be said that inheritance is not always a good approach for all the problems and some of the elements of OOP discussed above can be good alternatives for inheritance.

===Decomposition and Inheritance===

Traditionally, inheritance is used when there is a "is a" relationship between objects and decomposition when there is "has a" relationship between objects. An example of inheritance where "Programmer" and "Manager" extend "Employee" (is a relationship) can also be looked as, "Programmer" as a set of duties that an "Employee" may have, and this same employee may later change duties for "Manager" duties (has a relationship). Hence the way we design our system makes decomposition or inheritance favorable. But as a rule of thumb, object oriented design based on decomposition is more stable when parent objects are likely to change. In our decomposition example considered above, even if drawer functionality and role change drastically basic participants (letter object in this case) are likely to remain same and can be used in some other domain also. Hence, decomposition is used when there is lot of code reuse and/or polymorphism. By separating behaviors from the primary class hierarchy and including specific behavior for the child class, child class is not restricted by behavior of its ancestral classes.
Inheritance should be preferred when there is significant interaction between parent and its child classes. If parent must call back to child methods, then inheritance is usually the good answer. As an example, consider a class apple which inherits from its super class Fruit. Any change in the behavior of fruit will directly effect Orange which "is a" type of fruit. When super class and its subclasses are meant to be tied together inheritance should be used as it allows us to take advantage of dynamic binding and polymorphism.

===Message Passing and Inheritance===

Object oriented programs generally have two kinds of structures; one style is to have an inheritance hierarchy. The other is to have a pattern of message passing. Inheritance structure represents how different objects are related by their types. For example, in the program that models water use, Faucets and WaterPipes can be modeled as same kind of objects, except that Faucets can be turned on and off and WaterPipes can have multiple connections to other WaterPipes. Thus Faucet and WaterPipe objects can inherit from a common antecedent with all common traits and will have their specific properties in their classes.
Message passing structure represents how program works. For example, in the above mentioned program for water use, Appliance objects might send messages requesting water to Valves, and Valves to WaterPipes. The Building object can communicate through messages with all the Valves, Faucets, and WaterPipes, but not directly with Appliances. The connection between different objects which know whom to contact and pass message defines program structure.
[Example taken from: http://objc.toodarkpark.net/oop.html ]

There are situations where inheritance structure for the program may not work well. For example, consider an object Room which defines characteristics for the room. Room can be cubiod in shape so Object Room can inherit characteristics from Cuboid Object. However problem arise when different Rooms can have different shapes say cylindrical. Inheriting from both Cubiod and Cylindrical Objects will make Room both cylindrical and cubiod, instead of being cylindrical or cubiod in shape. Hence inheritance would not work here. A better way would be to have separate objects Shape and Room and shape object points to Cubiod or Cylindrical object. A Room object can interact with object Shape by passing messages. In this design approach access to all of other object facilities is not granted, instead an object needs to pass messages to access attributes and operations of the other class. Thus message passing exposes only the required interface of the object.

===Delegation and Inheritance===

Delegation is closely related to message forwarding and as discussed in above section, just like message forwarding and inheritance, there can be two kinds of structures for programs involving inheritance and delegation. Delegation supports the prototype-based programming model and inheritance, class based programming model. Inheritance schemes involve two kinds of objects, classes and instances. A class defines what is known as structure of its instances. Each instance maintains its values of attributes defined in the structure and the state of an object is given by the values of its attributes at any point in time. In delegation, there is only one type of object which represents real-world items. These objects are often taken to be “instances without classes.” This independence of all objects in delegation scheme allows delegation to capture the behavior of inheritance to some extent.

When it comes to building large systems with many objects, using an inheritance based system seems to make more sense. This is due to the fact that inheritance based system forces programmer to think and place some common behavior in super classes. In delegation based system, common behavior can be put in a single class, but this results in dependencies between objects and changing one object might result in errors in another object which is delegating the job to the first object.

In the nutshell, following are the situations when using delegations over inheritance is beneficial:

* When an object can play more than one role in the system, then sub-classing is not advisable, as the numbers of combinations are very large. Delegation would result in fewer classes and work best in this case.
* Inheritance, as discussed before, is a static relationship. If a class inherits from another class, this relationship cannot be changed at run time. On the other hand, Delegation is a dynamic relationship that can be changed at runtime.
* If an object needs to hide a function or an attribute from its super-class, then it is not a right candidate for inheritance. Delegation is an appropriate solution for this situation.
* If there’s no control over the class which is being inherited, it is good to use delegation over inheritance as inheritance has the risk that classes may have to be changed due to changes in parent class over which there’s no control.
* Delegation, unlike Inheritance, doesn’t force an object to accept all the methods of the super class, an object can only provide those methods that really make sense.

However, delegation has certain disadvantages over inheritance

* Delegation results in large number of objects in memory, which could result in performance issue when the objects in memory grow fast due to inefficient handling or disposal of objects.
* Delegation results in code more difficult to read understand and debug. This is due to the fact that delegation involves certain level of object indirection.

==Conclusion==

OOP has many features which makes it a favorable option in many problem domains. However, based on the requirements of the application, what is needed are subtle design decisions about which feature of OOP is a best option. Inheritance based models seem a very attractive choice for all object oriented applications, which is not true. As discussed in this article, techniques like decomposition, delegation and message forwarding do compass better alternatives for inheritance for some object oriented applications. What is needed is a perspective to see which OOP concept fits best in the overall picture.

CSC/ECE 517 Fall 2010/ch3 S30 SK

2010-10-06T00:29:06Z

Sumi2509:

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

==Introduction==

Object oriented programming (OOP) paradigm is based upon what is known as "objects" which represent real world concepts. One of the principal advantages of object-oriented programming over procedural programming is that they enable programmers to create modules that do not need to be changed when a new type of object is added.
Some basic concepts/features which are part of OOP are classes, methods, instances, encapsulation, inheritance, message forwarding, decomposition, delegation etc. This article discusses four of these concepts, namely, inheritance, message forwarding, decomposition and delegation. Specifically, comparison between inheritance and message forwarding, decomposition & delegation is made to understand when each of these can be considered as a potential alternative for inheritance, which forms core of OOP.

==Elements of OOP==

Some of the elements of OOP, relevant to the discussion of the topic are discussed below

===Inheritance===

In OOP, inheritance is a way to compartmentalize the code by creating objects which are based on previously created objects. In classical inheritance where objects are defined by classes, parent class is known as super class and the one which inherits behavior is known as sub class. Inheritance is used to relate two or more objects to each other. With the use of inheritance, methods and instance variables of the parent object are available for use in all of its child objects.
[[Image:Inheritance.jpg|frame|center|Inheritance Hierarchy]]

In the above example, student and teacher both inherit characters from Person object and Teaching Assistant inherits characteristics from Teacher and Student and in turn form Person.

===Decomposition===

Decomposition, also known as factoring is the process by which a big, complex problem is broken into smaller problems which are easier to attack, conceive and manage. Object Oriented Decomposition breaks large problem domain, based on classification entities, into smaller objects which represents some part of the problem. Object oriented decomposition works especially fine due to the concept of procedural abstraction which makes a problem easier to solve. Object-oriented decomposition results in a product that is more reusable.

For example, we could have an object referring to Drawer which supports addition of information and an object Letter which supports retrieval of content. In this case, a bigger problem domain (Drawer) refers to an object (Letter) which handles smaller problem domain. The fact that Drawer can have many letters makes decomposition relation of type "has a".

[[Image:Decomposition.jpg|frame|center|Decomposition]]

In the above example, Drawer object holds an instance variable which refers to Letter object. The bigger problem domain of "Drawer" has now been divided into smaller problem domains, one of which is Letter. Letter behavior is easier to maintain as compared to Drawer and any change in Drawer behavior will not affect Letter's behavior. Moreover, letter object can be part of some other big problem domain also(except of drawer).

===Message Forwarding===

Message Forwarding, also known as interfacing, describes the communication between objects using their public interfaces. Using message forwarding, objects can send and receive messages from each other, which help them to synchronize. Message passing is done using methods, properties and events. Message forwarding using method involves invoking an operation on an object. In response to the message the corresponding method is executed in the object and object may return some values. Message forwarding using property allows object to advertise and allow change in their state information. Events are raised by the objects in response to an internal action. Other objects can subscribe to these so that they can react to an occurrence of the event. An example for vehicles could be an 'ImpactDetected' event subscribed to by one or more 'AirBag' objects.

In some object-oriented programming languages, a message is the means to pass control to an object and if the object responds to the message, which means it has some way to handle that message. In pure object-oriented programming, message passing is performed exclusively through a dynamic dispatch strategy (process of mapping a message to a specific sequence of code at runtime.). Message forwarding techniques for communication between objects makes the interface descriptions with external systems much simpler.

Java employs message forwarding in the form of message calling. Objective C and Smalltalk heavily rely of message passing and use message sending instead of message calling.

As an example for message forwarding, when the object called "joe" (an instance of the driver class), presses the gas pedal, he literally passes an accelerate message to object "my Porsche", which in turn, invokes the "my Porsche" accelerate method.

[[Image:MessagePassing.jpg|frame|center|Message Forwarding]]
Image taken from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

===Delegation===

In OOP, two notions of delegation exist. The older usage refers to passing on the execution to some other object. While new usage refers to using method lookup rules to dispatch so-called self-calls as defined by Lieberman in his 1986 paper "Using Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems".

Example for old definition:

Suppose there are class A and B defined as follows:

class A
{
public:
foo()
{
print("Object A doing the job");
}
}
class B
{
public:
A a;
foo()
{
a.foo();
}
}

Here class B delegates the execution of its function foo to an object of class A.

Example of new definition:

class A
{
foo() {
self.bar() // self is also known under the names "current" and "this" in other languages
}
bar() {
print("a.bar")
}
}
class B
{
delegationlink A a
foo() {
a.foo() // call foo() on the a-instance
}
bar() {
print("b.bar")
}
}
a = new A()
b = new B(a) // establish delegation between two objects

calling b.foo() will result in b.bar to be printed. Older definition would have resulted in a.bar.

Example taken from http://www.wordiq.com/definition/Delegation_(programming)

It should be noted that support for delegation as new definition is not widely supported in programming languages, though exceptions exists in the form of the languages Self and Kniesels Lava.

Delegation can be viewed as a relationship between objects where one object forwards certain method calls to another object, called its delegate. Delegation is based on dynamic binding, as it requires that a given method call can invoke different segments of code at runtime. Delegation forms the core of design patterns like wrapper design pattern.

==Comparing Inheritance with Others==

As discussed above, inheritance forms a basic way to compartmentalize and code reuse in object oriented programming. However in some cases, inheritance may not be the best way to approach the problem. Some of the limitations of inheritance are:

* When single inheritance is used, an object can only inherit from a single object. If in the above given inheritance example, single inheritance is used Teaching assistant can either be student or a teacher but not both. Using multiple inheritance solves the problem (as in above example), but it can still inherit from each super class only once and hence a Teaching assistant cannot be a student at two different institutions. Also, multiple inheritance creates problem when a same trait is inherited from two different parents.

* Inheritance hierarchy for an object is fixed at the time of instantiation and cannot be changed. In the above example, Student object cannot change to Teacher while retaining characteristics of an Employee. Hence inheritance locks the original design which becomes difficult to change.

* When any client has access of any of the subclass, it automatically has access to the data which is part of the super class, even if data is private to the parent class. E.g in above example, access to student class gives an access of person class and can lead to unwarranted change of Person class properties.

Hence, it can be said that inheritance is not always a good approach for all the problems and some of the elements of OOP discussed above can be good alternatives for inheritance.

===Decomposition and Inheritance===

Traditionally, inheritance is used when there is a "is a" relationship between objects and decomposition when there is "has a" relationship between objects. An example of inheritance where "Programmer" and "Manager" extend "Employee" (is a relationship) can also be looked as, "Programmer" as a set of duties that an "Employee" may have, and this same employee may later change duties for "Manager" duties (has a relationship). Hence the way we design our system makes decomposition or inheritance favorable. But as a rule of thumb, object oriented design based on decomposition is more stable when parent objects are likely to change. In our decomposition example considered above, even if drawer functionality and role change drastically basic participants (letter object in this case) are likely to remain same and can be used in some other domain also. Hence, decomposition is used when there is lot of code reuse and/or polymorphism. By separating behaviors from the primary class hierarchy and including specific behavior for the child class, child class is not restricted by behavior of its ancestral classes.
Inheritance should be preferred when there is significant interaction between parent and its child classes. If parent must call back to child methods, then inheritance is usually the good answer. As an example, consider a class apple which inherits from its super class Fruit. Any change in the behavior of fruit will directly effect Orange which "is a" type of fruit. When super class and its subclasses are meant to be tied together inheritance should be used as it allows us to take advantage of dynamic binding and polymorphism.

===Message Passing and Inheritance===

Object oriented programs generally have two kinds of structures; one style is to have an inheritance hierarchy. The other is to have a pattern of message passing. Inheritance structure represents how different objects are related by their types. For example, in the program that models water use, Faucets and WaterPipes can be modeled as same kind of objects, except that Faucets can be turned on and off and WaterPipes can have multiple connections to other WaterPipes. Thus Faucet and WaterPipe objects can inherit from a common antecedent with all common traits and will have their specific properties in their classes.
Message passing structure represents how program works. For example, in the above mentioned program for water use, Appliance objects might send messages requesting water to Valves, and Valves to WaterPipes. The Building object can communicate through messages with all the Valves, Faucets, and WaterPipes, but not directly with Appliances. The connection between different objects which know whom to contact and pass message defines program structure.
[Example taken from: http://objc.toodarkpark.net/oop.html ]

There are situations where inheritance structure for the program may not work well. For example, consider an object Room which defines characteristics for the room. Room can be cubiod in shape so Object Room can inherit characteristics from Cuboid Object. However problem arise when different Rooms can have different shapes say cylindrical. Inheriting from both Cubiod and Cylindrical Objects will make Room both cylindrical and cubiod, instead of being cylindrical or cubiod in shape. Hence inheritance would not work here. A better way would be to have separate objects Shape and Room and shape object points to Cubiod or Cylindrical object. A Room object can interact with object Shape by passing messages. In this design approach access to all of other object facilities is not granted, instead an object needs to pass messages to access attributes and operations of the other class. Thus message passing exposes only the required interface of the object.

===Delegation and Inheritance===

Delegation is closely related to message forwarding and as discussed in above section, just like message forwarding and inheritance, there can be two kinds of structures for programs involving inheritance and delegation. Delegation supports the prototype-based programming model and inheritance, class based programming model. Inheritance schemes involve two kinds of objects, classes and instances. A class defines what is known as structure of its instances. Each instance maintains its values of attributes defined in the structure and the state of an object is given by the values of its attributes at any point in time. In delegation, there is only one type of object which represents real-world items. These objects are often taken to be “instances without classes.” This independence of all objects in delegation scheme allows delegation to capture the behavior of inheritance to some extent.

When it comes to building large systems with many objects, using an inheritance based system seems to make more sense. This is due to the fact that inheritance based system forces programmer to think and place some common behavior in super classes. In delegation based system, common behavior can be put in a single class, but this results in dependencies between objects and changing one object might result in errors in another object which is delegating the job to the first object.

In the nutshell, following are the situations when using delegations over inheritance is beneficial:

* When an object can play more than one role in the system, then sub-classing is not advisable, as the numbers of combinations are very large. Delegation would result in fewer classes and work best in this case.
* Inheritance, as discussed before, is a static relationship. If a class inherits from another class, this relationship cannot be changed at run time. On the other hand, Delegation is a dynamic relationship that can be changed at runtime.
* If an object needs to hide a function or an attribute from its super-class, then it is not a right candidate for inheritance. Delegation is an appropriate solution for this situation.
* If there’s no control over the class which is being inherited, it is good to use delegation over inheritance as inheritance has the risk that classes may have to be changed due to changes in parent class over which there’s no control.
* Delegation, unlike Inheritance, doesn’t force an object to accept all the methods of the super class, an object can only provide those methods that really make sense.

However, delegation has certain disadvantages over inheritance

* Delegation results in large number of objects in memory, which could result in performance issue when the objects in memory grow fast due to inefficient handling or disposal of objects.
* Delegation results in code more difficult to read understand and debug. This is due to the fact that delegation involves certain level of object indirection.

==Conclusion==

OOP has many features which makes it a favorable option in many problem domains. However, based on the requirements of the application, what is needed are subtle design decisions about which feature of OOP is a best option. Inheritance based models seem a very attractive choice for all object oriented applications, which is not true. As discussed in this article, techniques like decomposition, delegation and message forwarding do compass better alternatives for inheritance for some object oriented applications. What is needed is a perspective to see which OOP concept fits best in the overall picture.

CSC/ECE 517 Fall 2010/ch3 S30 SK

2010-10-06T00:27:50Z

Sumi2509:

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

==Introduction==

Object oriented programming (OOP) paradigm is based upon what is known as "objects" which represent real world concepts. One of the principal advantages of object-oriented programming over procedural programming is that they enable programmers to create modules that do not need to be changed when a new type of object is added.
Some basic concepts/features which are part of OOP are classes, methods, instances, encapsulation, inheritance, message forwarding, decomposition, delegation etc. This article discusses four of these concepts, namely, inheritance, message forwarding, decomposition and delegation. Specifically, comparison between inheritance and message forwarding, decomposition & delegation is made to understand when each of these can be considered as a potential alternative for inheritance, which forms core of OOP.

==Elements of OOP==

Some of the elements of OOP, relevant to the discussion of the topic are discussed below

===Inheritance===

In OOP, inheritance is a way to compartmentalize the code by creating objects which are based on previously created objects. In classical inheritance where objects are defined by classes, parent class is known as super class and the one which inherits behavior is known as sub class. Inheritance is used to relate two or more objects to each other. With the use of inheritance, methods and instance variables of the parent object are available for use in all of its child objects.
[[Image:Inheritance.jpg|frame|center|Inheritance Hierarchy]]

In the above example, student and teacher both inherit characters from Person object and Teaching Assistant inherits characteristics from Teacher and Student and in turn form Person.

===Decomposition===

Decomposition, also known as factoring is the process by which a big, complex problem is broken into smaller problems which are easier to attack, conceive and manage. Object Oriented Decomposition breaks large problem domain, based on classification entities, into smaller objects which represents some part of the problem. Object oriented decomposition works especially fine due to the concept of procedural abstraction which makes a problem easier to solve. Object-oriented decomposition results in a product that is more reusable.

For example, we could have an object referring to Drawer which supports addition of information and an object Letter which supports retrieval of content. In this case, a bigger problem domain (Drawer) refers to an object (Letter) which handles smaller problem domain. The fact that Drawer can have many letters makes decomposition relation of type "has a".

[[Image:Decomposition.jpg|frame|center|Decomposition]]

In the above example, Drawer object holds an instance variable which refers to Letter object. The bigger problem domain of "Drawer" has now been divided into smaller problem domains, one of which is Letter. Letter behavior is easier to maintain as compared to Drawer and any change in Drawer behavior will not affect Letter's behavior. Moreover, letter object can be part of some other big problem domain also(except of drawer).

===Message Forwarding===

Message Forwarding, also known as interfacing, describes the communication between objects using their public interfaces. Using message forwarding, objects can send and receive messages from each other, which help them to synchronize. Message passing is done using methods, properties and events. Message forwarding using method involves invoking an operation on an object. In response to the message the corresponding method is executed in the object and object may return some values. Message forwarding using property allows object to advertise and allow change in their state information. Events are raised by the objects in response to an internal action. Other objects can subscribe to these so that they can react to an occurrence of the event. An example for vehicles could be an 'ImpactDetected' event subscribed to by one or more 'AirBag' objects.

In some object-oriented programming languages, a message is the means to pass control to an object and if the object responds to the message, which means it has some way to handle that message. In pure object-oriented programming, message passing is performed exclusively through a dynamic dispatch strategy (process of mapping a message to a specific sequence of code at runtime.). Message forwarding techniques for communication between objects makes the interface descriptions with external systems much simpler.

Java employs message forwarding in the form of message calling. Objective C and Smalltalk heavily rely of message passing and use message sending instead of message calling.

As an example for message forwarding, when the object called "joe" (an instance of the driver class), presses the gas pedal, he literally passes an accelerate message to object "my Porsche", which in turn, invokes the "my Porsche" accelerate method.

[[Image:MessagePassing.jpg|frame|center|Message Forwarding]]
Image taken from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

===Delegation===

In OOP, two notions of delegation exist. The older usage refers to passing on the execution to some other object. While new usage refers to using method lookup rules to dispatch so-called self-calls as defined by Lieberman in his 1986 paper "Using Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems".

Example for old definition:

Suppose there are class A and B defined as follows:

class A
{
public:
foo()
{
print("Object A doing the job");
}
}
class B
{
public:
A a;
foo()
{
a.foo();
}
}

Here class B delegates the execution of its function foo to an object of class A.

Example of new definition:

class A
{
foo() {
self.bar() // self is also known under the names "current" and "this" in other languages
}
bar() {
print("a.bar")
}
}
class B
{
delegationlink A a
foo() {
a.foo() // call foo() on the a-instance
}
bar() {
print("b.bar")
}
}
a = new A()
b = new B(a) // establish delegation between two objects

calling b.foo() will result in b.bar to be printed. Older definition would have resulted in a.bar.

Example taken from http://www.wordiq.com/definition/Delegation_(programming)

It should be noted that support for delegation as new definition is not widely supported in programming languages, though exceptions exists in the form of the languages Self and Kniesels Lava.

Delegation can be viewed as a relationship between objects where one object forwards certain method calls to another object, called its delegate. Delegation is based on dynamic binding, as it requires that a given method call can invoke different segments of code at runtime. Delegation forms the core of design patterns like wrapper design pattern.

==Comparing Inheritance with Others==

As discussed above, inheritance forms a basic way to compartmentalize and code reuse in object oriented programming. However in some cases, inheritance may not be the best way to approach the problem. Some of the limitations of inheritance are:

* When single inheritance is used, an object can only inherit from a single object. If in the above given inheritance example, single inheritance is used Teaching assistant can either be student or a teacher but not both. Using multiple inheritance solves the problem (as in above example), but it can still inherit from each super class only once and hence a Teaching assistant cannot be a student at two different institutions. Also, multiple inheritance creates problem when a same trait is inherited from two different parents.

* Inheritance hierarchy for an object is fixed at the time of instantiation and cannot be changed. In the above example, Student object cannot change to Teacher while retaining characteristics of an Employee. Hence inheritance locks the original design which becomes difficult to change.

* When any client has access of any of the subclass, it automatically has access to the data which is part of the super class, even if data is private to the parent class. E.g in above example, access to student class gives an access of person class and can lead to unwarranted change of Person class properties.

Hence, it can be said that inheritance is not always a good approach for all the problems and some of the elements of OOP discussed above can be good alternatives for inheritance.

===Decomposition and Inheritance===

Traditionally, inheritance is used when there is a "is a" relationship between objects and decomposition when there is "has a" relationship between objects. An example of inheritance where "Programmer" and "Manager" extend "Employee" (is a relationship) can also be looked as, "Programmer" as a set of duties that an "Employee" may have, and this same employee may later change duties for "Manager" duties (has a relationship). Hence the way we design our system makes decomposition or inheritance favorable. But as a rule of thumb, object oriented design based on decomposition is more stable when parent objects are likely to change. In our decomposition example considered above, even if drawer functionality and role change drastically basic participants (letter object in this case) are likely to remain same and can be used in some other domain also. Hence, decomposition is used when there is lot of code reuse and/or polymorphism. By separating behaviors from the primary class hierarchy and including specific behavior for the child class, child class is not restricted by behavior of its ancestral classes.
Inheritance should be preferred when there is significant interaction between parent and its child classes. If parent must call back to child methods, then inheritance is usually the good answer. As an example, consider a class apple which inherits from its super class Fruit. Any change in the behavior of fruit will directly effect Orange which "is a" type of fruit. When super class and its subclasses are meant to be tied together inheritance should be used as it allows us to take advantage of dynamic binding and polymorphism.

===Message Passing and Inheritance===

Object oriented programs generally have two kinds of structures; one style is to have an inheritance hierarchy. The other is to have a pattern of message passing. Inheritance structure represents how different objects are related by their types. For example, in the program that models water use, Faucets and WaterPipes can be modeled as same kind of objects, except that Faucets can be turned on and off and WaterPipes can have multiple connections to other WaterPipes. Thus Faucet and WaterPipe objects can inherit from a common antecedent with all common traits and will have their specific properties in their classes.
Message passing structure represents how program works. For example, in the above mentioned program for water use, Appliance objects might send messages requesting water to Valves, and Valves to WaterPipes. The Building object can communicate through messages with all the Valves, Faucets, and WaterPipes, but not directly with Appliances. The connection between different objects which know whom to contact and pass message defines program structure.
[Example taken from: http://objc.toodarkpark.net/oop.html ]

There are situations where inheritance structure for the program may not work well. For example, consider an object Room which defines characteristics for the room. Room can be cubiod in shape so Object Room can inherit characteristics from Cuboid Object. However problem arise when different Rooms can have different shapes say cylindrical. Inheriting from both Cubiod and Cylindrical Objects will make Room both cylindrical and cubiod, instead of being cylindrical or cubiod in shape. Hence inheritance would not work here. A better way would be to have separate objects Shape and Room and shape object points to Cubiod or Cylindrical object. A Room object can interact with object Shape by passing messages. In this design approach access to all of other object facilities is not granted, instead an object needs to pass messages to access attributes and operations of the other class. Thus message passing exposes only the required interface of the object.

===Delegation and Inheritance===

Delegation is closely related to message forwarding and as discussed in above section, just like message forwarding and inheritance, there can be two kinds of structures for programs involving inheritance and delegation. Delegation supports the prototype-based programming model and inheritance, class based programming model. Inheritance schemes involve two kinds of objects, classes and instances. A class defines what is known as structure of its instances. Each instance maintains its values of attributes defined in the structure and the state of an object is given by the values of its attributes at any point in time. In delegation, there is only one type of object which represents real-world items. These objects are often taken to be “instances without classes.” This independence of all objects in delegation scheme allows delegation to capture the behavior of inheritance to some extent.

When it comes to building large systems with many objects, using an inheritance based system seems to make more sense. This is due to the fact that inheritance based system forces programmer to think and place some common behavior in super classes. In delegation based system, common behavior can be put in a single class, but this results in dependencies between objects and changing one object might result in errors in another object which is delegating the job to the first object.

In the nutshell, following are the situations when using delegations over inheritance is beneficial:

* When an object can play more than one role in the system, then sub-classing is not advisable, as the numbers of combinations are very large. Delegation would result in fewer classes and work best in this case.
* Inheritance, as discussed before, is a static relationship. If a class inherits from another class, this relationship cannot be changed at run time. On the other hand, Delegation is a dynamic relationship that can be changed at runtime.
* If an object needs to hide a function or an attribute from its super-class, then it is not a right candidate for inheritance. Delegation is an appropriate solution for this situation.
* If there’s no control over the class which is being inherited, it is good to use delegation over inheritance as inheritance has the risk that classes may have to be changed due to changes in parent class over which there’s no control.
* Delegation, unlike Inheritance, doesn’t force an object to accept all the methods of the super class, an object can only provide those methods that really make sense.

However, delegation has certain disadvantages over inheritance

* Delegation results in large number of objects in memory, which could result in performance issue when the objects in memory grow fast due to inefficient handling or disposal of objects.
* Delegation results in code more difficult to read understand and debug. This is due to the fact that delegation involves certain level of object indirection.

==Conclusion==

OOP has many features which makes it a favorable option in many problem domains. However, based on the requirements of the application, what is needed are subtle design decisions about which feature of OOP is a best option. Inheritance based models seem a very attractive choice for all object oriented applications, which is not true. As discussed in this article, techniques like decomposition, delegation and message forwarding do compass better alternatives for inheritance for some object oriented applications. What is needed is a perspective to see which OOP concept fits best in the overall picture.

CSC/ECE 517 Fall 2010/ch3 S30 SK

2010-10-06T00:25:34Z

Sumi2509:

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

==Introduction==

Object oriented programming (OOP) paradigm is based upon what is known as "objects" which represent real world concepts. One of the principal advantages of object-oriented programming over procedural programming is that they enable programmers to create modules that do not need to be changed when a new type of object is added.
Some basic concepts/features which are part of OOP are classes, methods, instances, encapsulation, inheritance, message forwarding, decomposition, delegation etc. This article discusses four of these concepts, namely, inheritance, message forwarding, decomposition and delegation. Specifically, comparison between inheritance and message forwarding, decomposition & delegation is made to understand when each of these can be considered as a potential alternative for inheritance, which forms core of OOP.

==Elements of OOP==

Some of the elements of OOP, relevant to the discussion of the topic are discussed below

===Inheritance===
In OOP, inheritance is a way to compartmentalize the code by creating objects which are based on previously created objects. In classical inheritance where objects are defined by classes, parent class is known as super class and the one which inherits behavior is known as sub class. Inheritance is used to relate two or more objects to each other. With the use of inheritance, methods and instance variables of the parent object are available for use in all of its child objects.
[[Image:Inheritance.jpg|frame|center|Inheritance Hierarchy]]

In the above example, student and teacher both inherit characters from Person object and Teaching Assistant inherits characteristics from Teacher and Student and in turn form Person.

===Decomposition===
Decomposition, also known as factoring is the process by which a big, complex problem is broken into smaller problems which are easier to attack, conceive and manage. Object Oriented Decomposition breaks large problem domain, based on classification entities, into smaller objects which represents some part of the problem. Object oriented decomposition works especially fine due to the concept of procedural abstraction which makes a problem easier to solve. Object-oriented decomposition results in a product that is more reusable.

For example, we could have an object referring to Drawer which supports addition of information and an object Letter which supports retrieval of content. In this case, a bigger problem domain (Drawer) refers to an object (Letter) which handles smaller problem domain. The fact that Drawer can have many letters makes decomposition relation of type "has a".

[[Image:Decomposition.jpg|frame|center|Decomposition]]

In the above example, Drawer object holds an instance variable which refers to Letter object. The bigger problem domain of "Drawer" has now been divided into smaller problem domains, one of which is Letter. Letter behavior is easier to maintain as compared to Drawer and any change in Drawer behavior will not affect Letter's behavior. Moreover, letter object can be part of some other big problem domain also(except of drawer).

===Message Forwarding===
Message Forwarding, also known as interfacing, describes the communication between objects using their public interfaces. Using message forwarding, objects can send and receive messages from each other, which help them to synchronize. Message passing is done using methods, properties and events. Message forwarding using method involves invoking an operation on an object. In response to the message the corresponding method is executed in the object and object may return some values. Message forwarding using property allows object to advertise and allow change in their state information. Events are raised by the objects in response to an internal action. Other objects can subscribe to these so that they can react to an occurrence of the event. An example for vehicles could be an 'ImpactDetected' event subscribed to by one or more 'AirBag' objects.

In some object-oriented programming languages, a message is the means to pass control to an object and if the object responds to the message, which means it has some way to handle that message. In pure object-oriented programming, message passing is performed exclusively through a dynamic dispatch strategy (process of mapping a message to a specific sequence of code at runtime.). Message forwarding techniques for communication between objects makes the interface descriptions with external systems much simpler.

Java employs message forwarding in the form of message calling. Objective C and Smalltalk heavily rely of message passing and use message sending instead of message calling.

As an example for message forwarding, when the object called "joe" (an instance of the driver class), presses the gas pedal, he literally passes an accelerate message to object "my Porsche", which in turn, invokes the "my Porsche" accelerate method.

[[Image:MessagePassing.jpg|frame|center|Message Forwarding]]
Image taken from http://www.freecomputertutor.net/object-oriented-programming-concepts.php#messagepassing

===Delegation===
In OOP, two notions of delegation exist. The older usage refers to passing on the execution to some other object. While new usage refers to using method lookup rules to dispatch so-called self-calls as defined by Lieberman in his 1986 paper "Using Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems".

Example for old definition:

Suppose there are class A and B defined as follows:

class A
{
public:
foo()
{
print("Object A doing the job");
}
}
class B
{
public:
A a;
foo()
{
a.foo();
}
}

Here class B delegates the execution of its function foo to an object of class A.

Example of new definition:

class A
{
foo() {
self.bar() // self is also known under the names "current" and "this" in other languages
}
bar() {
print("a.bar")
}
}
class B
{
delegationlink A a
foo() {
a.foo() // call foo() on the a-instance
}
bar() {
print("b.bar")
}
}
a = new A()
b = new B(a) // establish delegation between two objects

calling b.foo() will result in b.bar to be printed. Older definition would have resulted in a.bar.

Example taken from http://www.wordiq.com/definition/Delegation_(programming)

It should be noted that support for delegation as new definition is not widely supported in programming languages, though exceptions exists in the form of the languages Self and Kniesels Lava.

Delegation can be viewed as a relationship between objects where one object forwards certain method calls to another object, called its delegate. Delegation is based on dynamic binding, as it requires that a given method call can invoke different segments of code at runtime. Delegation forms the core of design patterns like wrapper design pattern.

==Comparing Inheritance with Others==

As discussed above, inheritance forms a basic way to compartmentalize and code reuse in object oriented programming. However in some cases, inheritance may not be the best way to approach the problem. Some of the limitations of inheritance are:

* When single inheritance is used, an object can only inherit from a single object. If in the above given inheritance example, single inheritance is used Teaching assistant can either be student or a teacher but not both. Using multiple inheritance solves the problem (as in above example), but it can still inherit from each super class only once and hence a Teaching assistant cannot be a student at two different institutions. Also, multiple inheritance creates problem when a same trait is inherited from two different parents.

* Inheritance hierarchy for an object is fixed at the time of instantiation and cannot be changed. In the above example, Student object cannot change to Teacher while retaining characteristics of an Employee. Hence inheritance locks the original design which becomes difficult to change.

* When any client has access of any of the subclass, it automatically has access to the data which is part of the super class, even if data is private to the parent class. E.g in above example, access to student class gives an access of person class and can lead to unwarranted change of Person class properties.

Hence, it can be said that inheritance is not always a good approach for all the problems and some of the elements of OOP discussed above can be good alternatives for inheritance.

===Decomposition and Inheritance===

Traditionally, inheritance is used when there is a "is a" relationship between objects and decomposition when there is "has a" relationship between objects. An example of inheritance where "Programmer" and "Manager" extend "Employee" (is a relationship) can also be looked as, "Programmer" as a set of duties that an "Employee" may have, and this same employee may later change duties for "Manager" duties (has a relationship). Hence the way we design our system makes decomposition or inheritance favorable. But as a rule of thumb, object oriented design based on decomposition is more stable when parent objects are likely to change. In our decomposition example considered above, even if drawer functionality and role change drastically basic participants (letter object in this case) are likely to remain same and can be used in some other domain also. Hence, decomposition is used when there is lot of code reuse and/or polymorphism. By separating behaviors from the primary class hierarchy and including specific behavior for the child class, child class is not restricted by behavior of its ancestral classes.
Inheritance should be preferred when there is significant interaction between parent and its child classes. If parent must call back to child methods, then inheritance is usually the good answer. As an example, consider a class apple which inherits from its super class Fruit. Any change in the behavior of fruit will directly effect Orange which "is a" type of fruit. When super class and its subclasses are meant to be tied together inheritance should be used as it allows us to take advantage of dynamic binding and polymorphism.

===Message Passing and Inheritance===
Object oriented programs generally have two kinds of structures; one style is to have an inheritance hierarchy. The other is to have a pattern of message passing. Inheritance structure represents how different objects are related by their types. For example, in the program that models water use, Faucets and WaterPipes can be modeled as same kind of objects, except that Faucets can be turned on and off and WaterPipes can have multiple connections to other WaterPipes. Thus Faucet and WaterPipe objects can inherit from a common antecedent with all common traits and will have their specific properties in their classes.
Message passing structure represents how program works. For example, in the above mentioned program for water use, Appliance objects might send messages requesting water to Valves, and Valves to WaterPipes. The Building object can communicate through messages with all the Valves, Faucets, and WaterPipes, but not directly with Appliances. The connection between different objects which know whom to contact and pass message defines program structure.
[Example taken from: http://objc.toodarkpark.net/oop.html ]

There are situations where inheritance structure for the program may not work well. For example, consider an object Room which defines characteristics for the room. Room can be cubiod in shape so Object Room can inherit characteristics from Cuboid Object. However problem arise when different Rooms can have different shapes say cylindrical. Inheriting from both Cubiod and Cylindrical Objects will make Room both cylindrical and cubiod, instead of being cylindrical or cubiod in shape. Hence inheritance would not work here. A better way would be to have separate objects Shape and Room and shape object points to Cubiod or Cylindrical object. A Room object can interact with object Shape by passing messages. In this design approach access to all of other object facilities is not granted, instead an object needs to pass messages to access attributes and operations of the other class. Thus message passing exposes only the required interface of the object.

===Delegation and Inheritance===

Delegation is closely related to message forwarding and as discussed in above section, just like message forwarding and inheritance, there can be two kinds of structures for programs involving inheritance and delegation. Delegation supports the prototype-based programming model and inheritance, class based programming model. Inheritance schemes involve two kinds of objects, classes and instances. A class defines what is known as structure of its instances. Each instance maintains its values of attributes defined in the structure and the state of an object is given by the values of its attributes at any point in time. In delegation, there is only one type of object which represents real-world items. These objects are often taken to be “instances without classes.” This independence of all objects in delegation scheme allows delegation to capture the behavior of inheritance to some extent.

When it comes to building large systems with many objects, using an inheritance based system seems to make more sense. This is due to the fact that inheritance based system forces programmer to think and place some common behavior in super classes. In delegation based system, common behavior can be put in a single class, but this results in dependencies between objects and changing one object might result in errors in another object which is delegating the job to the first object.

In the nutshell, following are the situations when using delegations over inheritance is beneficial:

* When an object can play more than one role in the system, then sub-classing is not advisable, as the numbers of combinations are very large. Delegation would result in fewer classes and work best in this case.
* Inheritance, as discussed before, is a static relationship. If a class inherits from another class, this relationship cannot be changed at run time. On the other hand, Delegation is a dynamic relationship that can be changed at runtime.
* If an object needs to hide a function or an attribute from its super-class, then it is not a right candidate for inheritance. Delegation is an appropriate solution for this situation.
* If there’s no control over the class which is being inherited, it is good to use delegation over inheritance as inheritance has the risk that classes may have to be changed due to changes in parent class over which there’s no control.
* Delegation, unlike Inheritance, doesn’t force an object to accept all the methods of the super class, an object can only provide those methods that really make sense.

However, delegation has certain disadvantages over inheritance

* Delegation results in large number of objects in memory, which could result in performance issue when the objects in memory grow fast due to inefficient handling or disposal of objects.
* Delegation results in code more difficult to read understand and debug. This is due to the fact that delegation involves certain level of object indirection.

==Conclusion==

OOP has many features which makes it a favorable option in many problem domains. However, based on the requirements of the application, what is needed are subtle design decisions about which feature of OOP is a best option. Inheritance based models seem a very attractive choice for all object oriented applications, which is not true. As discussed in this article, techniques like decomposition, delegation and message forwarding do compass better alternatives for inheritance for some object oriented applications. What is needed is a perspective to see which OOP concept fits best in the overall picture.

CSC/ECE 517 Fall 2010/ch3 S30 SK

2010-10-06T00:21:50Z

Sumi2509:

CSC/ECE 517 Fall 2010/ch3 S30 SK

2010-10-06T00:20:59Z

Sumi2509:

CSC/ECE 517 Fall 2010/ch3 S30 SK

2010-10-06T00:19:10Z

Sumi2509:

CSC/ECE 517 Fall 2010/ch3 S30 SK

2010-10-06T00:17:31Z

Sumi2509:

File:MessagePassing.jpg

2010-10-06T00:00:49Z

Sumi2509:

File:Inheritance.jpg

2010-10-05T23:59:50Z

Sumi2509:

File:Decomposition.jpg

2010-10-05T23:59:33Z

Sumi2509:

CSC/ECE 517 Fall 2010/ch2 S23 SS

2010-09-23T01:05:36Z

Sumi2509: /* Properties of any OODSL: */

'''Domain Specific Object Oriented Languages'''

==Introduction==

Domain Specific Language (DSL) is any programming language which is designed to solve some specific problems and tasks in a specific domain. These languages are very focused and restricted to particular problem domain. This is in contrast to general programming languages (GPL) like java or C++ which can be used for software development in many application domains. Examples for DSL include:
* SQL for relational database
* Verilog for statistics
* Latex for typesetting

Object Oriented DSL's (OODSL) are DSL's based on object oriented programming paradigm. They employ the idea of classes and objects with concepts like encapsulation, polymorphism, abstraction etc. OODSL's like any other DSL's are much more expressive in their domain and much less comprehensive than general purpose object oriented programming languages like Java, C# etc. They are high-level languages, in the sense that they abstract from low-level implementation details. Some OODSL examples are Rails based on ruby programming language and JSP tags, Hibernate and Spring based on Java.

===Pros and Cons of OODSL===

Like any other DSL, employing OODSL in any application domain comes with its own set of advantages and disadvantages. Some of them are discussed below.

Pros of using OODSL for application development are:
* OODSL's are developed for a particular domain and hence can handle the problems related to that domain. They help express solution in the idiom and abstraction of problem domain and can be easily understood by experts in that domain.
* OODSL's are much simpler to use than general purpose language in their domain.
* They are concise, self documented and easy to understand and hence aid in easy development, maintainability and productivity

On the other side, cons of using OODSL are:
* Developing an OODSL require effort and cost.
* OODSL has limited scope within their domain.
* Using a newly developed OODSL requires users to understand its syntax.
* Using OODSL together with GPL constructs can be a difficult task.

===Types of OODSL===

OODSL can be of two types, internal and external :

'''Internal OODSL''' are the ones which use a host language and give them the feel of a particular language. Developing internal OODSL's is comparatively simple as they use grammar, parsers and tools of underlying language. But they are constrained by the underlying language. The challenge is to design these languages so as to have syntax within the confines of host language, yet these languages are simple, concise and fluent. An example of internal OODSL would be Rake (make equivalent) based on host, Ruby.Internal OODSL's are also referred as embedded languages or fluent interfaces.

'''External OODSL''', on the other hand is designed to be independent of any other language. Syntax, grammar, parsing of these languages is pretty much based on its author choice and gives both pain and pleasure of developing all from scratch. Example of external DSL would be Ant based on java.

==History of OODSLs==

History of DSL dates back than modeling approaches used now to develop them. Initial DSL's were developed many decades before. Worth mentioning is FORTRAN developed in late 1950s, an abbreviation of 'formula translation'. FORTRAN borrowed notation from mathematics so that programmers could write mathematical formulas directly. OODSL's started coming up after object oriented paradigm became prominent in 1970's and 1980's. OODSL's appeared mostly in late 1980's and 1990's. Now, OODSL's are used in web applications (e.g. Rails), computer games and environments (e.g. MOO programming) and as programming languages for music (e.g. Formes).

==OODSL Examples==

Some examples of OODSL prevalent today are:

* '''Kiddo''' - Kiddo is an internal OODSL based on ruby and used for building silverlight and WPF applications. Kiddo is based on ideals of "kid friendly" coding and has 5 core methods to get started with drawing.
* '''ColdFusion Markup Language''' - Commonly known as CFML, it is a scripting language used by Adobe's ColdFusion and other scripting engines. The CFML includes a set of tags that can be used in ColdFusion pages to interact with data sources and display output.
* '''MOO Programming Language''' - Moo programming language is used to support Mud Object Oriented or MOO server which is online virtual reality system to which multiple players can connect at the same time. Its domain is computer gaming environment.
* '''LPC''' - It is an object-oriented programming language derived from C and developed originally to facilitate MUD building. It was designed for game development.
* '''Formes''' - It is an object-oriented DSL used for music composition and synthesis. It is written in VLISP.
* '''R - R''' is a programming language for statistical computing and graphics. R has stronger object-oriented programming facilities than most statistical computing languages available.
* '''Kermeta''' - Kermeta is a meta-modeling language used to describe structure and the behavior of models. Kermeta can be used as the core language for a model oriented platform.

==Creating an OODSL==

OODSL can be created using many techniques and tools available in the market.

===Properties of any OODSL===

Any OODSL should be fluent and in context.

* '''Fluency''': A fluent OODSL should have interfaces which are properly designed for human use and has high readability and natural flows within the language. An example explaining fluency is given below:

Looping through any collection in java was done traditionally as:

for(int i = 0; i < products.size(); i++)
{
String name = (String) products.get(i);
//...
//.....

}

However it can be done more fluently starting Java 5 as:

for(String product : products)
{
// ...
// ...
}

This flow comes naturally to any user and is easier to interpret.

* '''Context:''' OODSL should have a proper context on which they are built upon, after all, they are domain specific. Shared context makes OODSL easier to understand and work with and highly expressive. For example:

In java declaring and adding into the cart is done as:

java.util.ArrayList<String> cart = new java.util.ArrayList<String>();
cart.add("Milk");
cart.add("Juice");
cart.add("Apple");
System.out.print("My cart has %d items.", cart.size())

Same thing can be done in groovy as:
cart = []
cart.with {
add "Milk"
add "Juice"
add "Apple"
println "My cart has $size items."
}

Languages like Groovy and javascript are easier than java to build context such that convention is followed.

Examples taken from: http://www.javaworld.com/javaworld/jw-07-2008/jw-07-dsls-in-java-2.html?page=3

===Techniques/Tools used===

There are many OO languages like Smalltalk, ruby, groovy which easily lend themselves for creating internal OODSL. Ruby provides expressive, flexible syntax and has a dynamic nature which makes implementing a new OODSL easy without using any additional parser or compiler. Also, groovy easily supports creating fluent and in context OODSL's. On the other hand, C++ or Java syntax is not easy to attain the level of fluency required for a DSL, and so creating internal OODSLs using these languages is challenging. However, these languages offer good parsing libraries or capabilities and their support for creating external DSL’s is pretty strong.

Tools like visual studio and ANTLR aid in creating OODSL. Visual studio contains Domain-Specific Language Designer Wizard which provides many solution templates which can be used to create an OODSL. ANTLR, ANother Tool for Language Recognition, is another language tool that provides a framework for constructing recognizers, interpreters, compilers, and translators from grammatical descriptions. It supports many runtime libraries of ruby, C#, java etc which helps to create internal OODSL.

There are four basic approaches used for creating OODSL. These are:

* '''Instantiation:''' This approach is used mostly in Ruby projects, and not even recognized as a DSL. Using this approach, DSL is defined by defining methods of an object. Interaction is like any other OODSL, done by instantiating the object and calling the methods. The HTML creation DSL of Ruby’s CGI class uses this approach.
* '''Class macros:''' DSL is defined as methods on some ancestor class, and those methods are tweaked to modify the behavior of super-class and for subclasses of the particular class in question. These kinds of macros often create new methods. “has_many” in ActiveRecord is a good example of this type of approach.
* '''Top-level methods:''' There exists a configuration file, which is just like a Ruby script augmented with some DSL syntax. Any application using this type of DSL will load this configuration and uses DSL top level methods defined. When those methods are called in the configuration file, they modify some central (typically global) data, which then application uses to determine how it should execute. Rake is an example of this kind of DSL.
* '''Sandboxing:''' This approach is a special case of the more general instantiation technique. Using this technique, DSL is defined as methods of some object which is really just a “sandbox”. Interaction with the object’s methods modifies state of the sandbox which is queried by the application. This technique is similar to the top-level methods technique, with an exception that the DSL is restricted to the sandbox and there are no global methods involved. Needle uses this approach.

===Steps to create an OODSL===

Some of the steps which can be used to create an OODSL are:
* Identifying the goals to be accomplished.
* Reasoning why creating a new OODSL would be better than existing well crafted OODSL or an API.
* Defining ideal syntax before even coding.
* Referring to other examples of OODSL's, learning from their code and looking at the similarities.
* Refining syntax to get the best Return on Investment. If creating an internal OODSL, it is best to take advantage of host language’s compiler and adapting syntax slightly without creating a new full fledged parser or compiler.

==Example==

Below is an example of how an OODSL for creating SQL statements and querying database systems can be created. It is compared with how the same task is done in general purpose language.

Dynamic construction of an SQL statement in Java :

String sql = "select id, name " +
"from customers c, order o " +
"where " +
"c.since >= sysdate - 30 and " +
"sum(o.total) > " + significantTotal + " and " +
"c.id = o.customer_id and " +
"nvl(c.status, 'DROPPED') != 'DROPPED'";

The same can be written using OODSL as follows :

Table c = CUSTOMER.alias();
Table o = ORDER.alias();
Clause recent = c.SINCE.laterThan(daysEarlier(30));
Clause hasSignificantOrders = o.TOTAL.sum().isAbove(significantTotal);
Clause ordersMatch = c.ID.matches(o.CUSTOMER_ID);
Clause activeCustomer = c.STATUS.isNotNullOr("DROPPED");
String sql = CUSTOMERS.where(recent.and(hasSignificantOrders)
.and(ordersMatch)
.and(activeCustomer)
.select(c.ID, c.NAME)
.sql();

The SQL statement written in Java requires developer to be familiar with Oracle-SQL. This may not be the case for every application development in every domain. An OODSL like above can help in these cases. Creating basic classes representing different constructs of SQL query makes creating query easy. E.g. Class “Table” represents a basic API available through DSL and is used for representing tables which are to be queried. Creating different clauses using class “Clause” help filter data from the database.

The DSL code is less procedural, more declarative and object-oriented. It also has several advantages, major one being creating SQL statements without having familiarity of how to write SQL statements in database packages like Oracle, MySQL etc. The commonly used phrase, “nvl(c.status, 'DROPPED') != 'DROPPED'" in Oracle SQL cannot be easily understood by a non-SQL programmer. By replacing this phrase with the more easily understandable and language-like "isNotNullOr(“DROPPED”)," readability has been enhanced, and the system is protected from a later need to change the implementation to take advantage of facilities offered by another database vendor.

Note: The above example was explained in an easier manner. Further reading can be done from original source, http://www.infoq.com/articles/internal-dsls-java

==Summary==

This article gives some basic overview of OODSL features. OODSLs are mainly used in the domain of software engineering. The challenge using software engineering is to create flexible, reliable, scalable and maintainable systems. To achieve this, the software engineer must apply a wide variety of tools and techniques. One of these is to take advantage of the knowledge from underlying application domain, by means of a domain-specific language (DSL), which provides a notation that can be used to compose applications from a set of concepts tailored towards a specific application domain. Creating OODSL is a good option because OODSL provides benefits from both the worlds, DSL and OO concepts. An OODSL can be easily extended later, if required, which may not be the case with any other DSL. Hence it can be said that, OODSLs provide a certain level of abstraction of a domain, which can result in a greater control over or understanding of that domain. At the same time, they provide some good features of object oriented programming.

==References==
[1] Eelco Visser. WebDSL: A Case Study in Domain-Specific Language Engineering. Lecture Notes in Computer Science, 2008, Volume 5235/2008, 291-373.

[2] Martin Fowler. MF Bliki: DomainSpecificLanguage. Retrieved September 15, 2010, from, http://www.martinfowler.com/bliki/DomainSpecificLanguage.html

[3] Domain-specific Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/Domain-specific_language.

[4] Jeff Barczewski. Creating DSL’s in Ruby. Retrieved September 16, 2010 from http://inspiredhorizons.com/presentations/CreatingDSLsInRuby-060926.pdf

[5] Venkat Subramaniam, Creating DSL’s in java. Retrieved September 16, 2010 from http://www.java2s.com/Article/Java/Development/DSL.htm

[6] Jamis Buck. Writing Domain Specific Languages. Retrieved September 16, 2010 from http://weblog.jamisbuck.org/2006/4/20/writing-domain-specific-languages

[7] Alex Ruiz, Jeff Bay. An Approach to Internal Domain-Specific Languages in Java Retreved September 16, 2010 from http://www.infoq.com/articles/internal-dsls-java

[8] ColdFusion Markup Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/ColdFusion_Markup_Language

[9] MOO. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/MOO

[10] Freedom Dumlao. Introducing Kiddo: A Ruby DSL for building simple WPF and Silverlight applications. Retrieved September 15, 2010 from http://weblogs.asp.net/freedomdumlao/archive/2010/05/27/introducing-kiddo-a-ruby-dsl-for-building-simple-wpf-and-silverlight-applications.aspx

[11] LPC (programming language). Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/LPC_(programming_language)

[12] Kermeta Language Overview. Retrieved September 15, 2010 from https://www.kermeta.org/docs/KerMeta-MetaModel.pdf

CSC/ECE 517 Fall 2010/ch2 S20 st

2010-09-22T21:43:18Z

Sumi2509:

CSC/ECE 517 Fall 2010/ch2 S20 st

2010-09-22T21:42:49Z

Sumi2509:

CSC/ECE 517 Fall 2010/ch2 S23 SS

2010-09-22T21:42:04Z

Sumi2509:

'''Domain Specific Object Oriented Languages'''

==Introduction==

Domain Specific Language (DSL) is any programming language which is designed to solve some specific problems and tasks in a specific domain. These languages are very focused and restricted to particular problem domain. This is in contrast to general programming languages (GPL) like java or C++ which can be used for software development in many application domains. Examples for DSL include:
* SQL for relational database
* Verilog for statistics
* Latex for typesetting

Object Oriented DSL's (OODSL) are DSL's based on object oriented programming paradigm. They employ the idea of classes and objects with concepts like encapsulation, polymorphism, abstraction etc. OODSL's like any other DSL's are much more expressive in their domain and much less comprehensive than general purpose object oriented programming languages like Java, C# etc. They are high-level languages, in the sense that they abstract from low-level implementation details. Some OODSL examples are Rails based on ruby programming language and JSP tags, Hibernate and Spring based on Java.

===Pros and Cons of OODSL===

Like any other DSL, employing OODSL in any application domain comes with its own set of advantages and disadvantages. Some of them are discussed below.

Pros of using OODSL for application development are:
* OODSL's are developed for a particular domain and hence can handle the problems related to that domain. They help express solution in the idiom and abstraction of problem domain and can be easily understood by experts in that domain.
* OODSL's are much simpler to use than general purpose language in their domain.
* They are concise, self documented and easy to understand and hence aid in easy development, maintainability and productivity

On the other side, cons of using OODSL are:
* Developing an OODSL require effort and cost.
* OODSL has limited scope within their domain.
* Using a newly developed OODSL requires users to understand its syntax.
* Using OODSL together with GPL constructs can be a difficult task.

===Types of OODSL===

OODSL can be of two types, internal and external :

'''Internal OODSL''' are the ones which use a host language and give them the feel of a particular language. Developing internal OODSL's is comparatively simple as they use grammar, parsers and tools of underlying language. But they are constrained by the underlying language. The challenge is to design these languages so as to have syntax within the confines of host language, yet these languages are simple, concise and fluent. An example of internal OODSL would be Rake (make equivalent) based on host, Ruby.Internal OODSL's are also referred as embedded languages or fluent interfaces.

'''External OODSL''', on the other hand is designed to be independent of any other language. Syntax, grammar, parsing of these languages is pretty much based on its author choice and gives both pain and pleasure of developing all from scratch. Example of external DSL would be Ant based on java.

==History of OODSLs==

History of DSL dates back than modeling approaches used now to develop them. Initial DSL's were developed many decades before. Worth mentioning is FORTRAN developed in late 1950s, an abbreviation of 'formula translation'. FORTRAN borrowed notation from mathematics so that programmers could write mathematical formulas directly. OODSL's started coming up after object oriented paradigm became prominent in 1970's and 1980's. OODSL's appeared mostly in late 1980's and 1990's. Now, OODSL's are used in web applications (e.g. Rails), computer games and environments (e.g. MOO programming) and as programming languages for music (e.g. Formes).

==OODSL Examples==

Some examples of OODSL prevalent today are:

* '''Kiddo''' - Kiddo is an internal OODSL based on ruby and used for building silverlight and WPF applications. Kiddo is based on ideals of "kid friendly" coding and has 5 core methods to get started with drawing.
* '''ColdFusion Markup Language''' - Commonly known as CFML, it is a scripting language used by Adobe's ColdFusion and other scripting engines. The CFML includes a set of tags that can be used in ColdFusion pages to interact with data sources and display output.
* '''MOO Programming Language''' - Moo programming language is used to support Mud Object Oriented or MOO server which is online virtual reality system to which multiple players can connect at the same time. Its domain is computer gaming environment.
* '''LPC''' - It is an object-oriented programming language derived from C and developed originally to facilitate MUD building. It was designed for game development.
* '''Formes''' - It is an object-oriented DSL used for music composition and synthesis. It is written in VLISP.
* '''R - R''' is a programming language for statistical computing and graphics. R has stronger object-oriented programming facilities than most statistical computing languages available.
* '''Kermeta''' - Kermeta is a meta-modeling language used to describe structure and the behavior of models. Kermeta can be used as the core language for a model oriented platform.

==Creating an OODSL==

OODSL can be created using many techniques and tools available in the market.

===Properties of any OODSL:===

Any OODSL should be fluent and in context.

* '''Fluency''': A fluent OODSL should have interfaces which are properly designed for human use and has high readability and natural flows within the language. An example explaining fluency is given below:

Looping through any collection in java was done traditionally as:

for(int i = 0; i < products.size(); i++)
{
String name = (String) products.get(i);
//...
//.....

}

However it can be done more fluently starting Java 5 as:

for(String product : products)
{
// ...
// ...
}

This flow comes naturally to any user and is easier to interpret.

* '''Context:''' OODSL should have a proper context on which they are built upon, after all, they are domain specific. Shared context makes OODSL easier to understand and work with and highly expressive. For example:

In java declaring and adding into the cart is done as:

java.util.ArrayList<String> cart = new java.util.ArrayList<String>();
cart.add("Milk");
cart.add("Juice");
cart.add("Apple");
System.out.print("My cart has %d items.", cart.size())

Same thing can be done in groovy as:
cart = []
cart.with {
add "Milk"
add "Juice"
add "Apple"
println "My cart has $size items."
}

Languages like Groovy and javascript are easier than java to build context such that convention is followed.

Examples taken from: http://www.javaworld.com/javaworld/jw-07-2008/jw-07-dsls-in-java-2.html?page=3

===Techniques/Tools used===

There are many OO languages like Smalltalk, ruby, groovy which easily lend themselves for creating internal OODSL. Ruby provides expressive, flexible syntax and has a dynamic nature which makes implementing a new OODSL easy without using any additional parser or compiler. Also, groovy easily supports creating fluent and in context OODSL's. On the other hand, C++ or Java syntax is not easy to attain the level of fluency required for a DSL, and so creating internal OODSLs using these languages is challenging. However, these languages offer good parsing libraries or capabilities and their support for creating external DSL’s is pretty strong.

Tools like visual studio and ANTLR aid in creating OODSL. Visual studio contains Domain-Specific Language Designer Wizard which provides many solution templates which can be used to create an OODSL. ANTLR, ANother Tool for Language Recognition, is another language tool that provides a framework for constructing recognizers, interpreters, compilers, and translators from grammatical descriptions. It supports many runtime libraries of ruby, C#, java etc which helps to create internal OODSL.

There are four basic approaches used for creating OODSL. These are:

* '''Instantiation:''' This approach is used mostly in Ruby projects, and not even recognized as a DSL. Using this approach, DSL is defined by defining methods of an object. Interaction is like any other OODSL, done by instantiating the object and calling the methods. The HTML creation DSL of Ruby’s CGI class uses this approach.
* '''Class macros:''' DSL is defined as methods on some ancestor class, and those methods are tweaked to modify the behavior of super-class and for subclasses of the particular class in question. These kinds of macros often create new methods. “has_many” in ActiveRecord is a good example of this type of approach.
* '''Top-level methods:''' There exists a configuration file, which is just like a Ruby script augmented with some DSL syntax. Any application using this type of DSL will load this configuration and uses DSL top level methods defined. When those methods are called in the configuration file, they modify some central (typically global) data, which then application uses to determine how it should execute. Rake is an example of this kind of DSL.
* '''Sandboxing:''' This approach is a special case of the more general instantiation technique. Using this technique, DSL is defined as methods of some object which is really just a “sandbox”. Interaction with the object’s methods modifies state of the sandbox which is queried by the application. This technique is similar to the top-level methods technique, with an exception that the DSL is restricted to the sandbox and there are no global methods involved. Needle uses this approach.

===Steps to create an OODSL===

Some of the steps which can be used to create an OODSL are:
* Identifying the goals to be accomplished.
* Reasoning why creating a new OODSL would be better than existing well crafted OODSL or an API.
* Defining ideal syntax before even coding.
* Referring to other examples of OODSL's, learning from their code and looking at the similarities.
* Refining syntax to get the best Return on Investment. If creating an internal OODSL, it is best to take advantage of host language’s compiler and adapting syntax slightly without creating a new full fledged parser or compiler.

==Example==

Below is an example of how an OODSL for creating SQL statements and querying database systems can be created. It is compared with how the same task is done in general purpose language.

Dynamic construction of an SQL statement in Java :

String sql = "select id, name " +
"from customers c, order o " +
"where " +
"c.since >= sysdate - 30 and " +
"sum(o.total) > " + significantTotal + " and " +
"c.id = o.customer_id and " +
"nvl(c.status, 'DROPPED') != 'DROPPED'";

The same can be written using OODSL as follows :

Table c = CUSTOMER.alias();
Table o = ORDER.alias();
Clause recent = c.SINCE.laterThan(daysEarlier(30));
Clause hasSignificantOrders = o.TOTAL.sum().isAbove(significantTotal);
Clause ordersMatch = c.ID.matches(o.CUSTOMER_ID);
Clause activeCustomer = c.STATUS.isNotNullOr("DROPPED");
String sql = CUSTOMERS.where(recent.and(hasSignificantOrders)
.and(ordersMatch)
.and(activeCustomer)
.select(c.ID, c.NAME)
.sql();

The SQL statement written in Java requires developer to be familiar with Oracle-SQL. This may not be the case for every application development in every domain. An OODSL like above can help in these cases. Creating basic classes representing different constructs of SQL query makes creating query easy. E.g. Class “Table” represents a basic API available through DSL and is used for representing tables which are to be queried. Creating different clauses using class “Clause” help filter data from the database.

The DSL code is less procedural, more declarative and object-oriented. It also has several advantages, major one being creating SQL statements without having familiarity of how to write SQL statements in database packages like Oracle, MySQL etc. The commonly used phrase, “nvl(c.status, 'DROPPED') != 'DROPPED'" in Oracle SQL cannot be easily understood by a non-SQL programmer. By replacing this phrase with the more easily understandable and language-like "isNotNullOr(“DROPPED”)," readability has been enhanced, and the system is protected from a later need to change the implementation to take advantage of facilities offered by another database vendor.

Note: The above example was explained in an easier manner. Further reading can be done from original source, http://www.infoq.com/articles/internal-dsls-java

==Summary==

This article gives some basic overview of OODSL features. OODSLs are mainly used in the domain of software engineering. The challenge using software engineering is to create flexible, reliable, scalable and maintainable systems. To achieve this, the software engineer must apply a wide variety of tools and techniques. One of these is to take advantage of the knowledge from underlying application domain, by means of a domain-specific language (DSL), which provides a notation that can be used to compose applications from a set of concepts tailored towards a specific application domain. Creating OODSL is a good option because OODSL provides benefits from both the worlds, DSL and OO concepts. An OODSL can be easily extended later, if required, which may not be the case with any other DSL. Hence it can be said that, OODSLs provide a certain level of abstraction of a domain, which can result in a greater control over or understanding of that domain. At the same time, they provide some good features of object oriented programming.

==References==
[1] Eelco Visser. WebDSL: A Case Study in Domain-Specific Language Engineering. Lecture Notes in Computer Science, 2008, Volume 5235/2008, 291-373.

[2] Martin Fowler. MF Bliki: DomainSpecificLanguage. Retrieved September 15, 2010, from, http://www.martinfowler.com/bliki/DomainSpecificLanguage.html

[3] Domain-specific Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/Domain-specific_language.

[4] Jeff Barczewski. Creating DSL’s in Ruby. Retrieved September 16, 2010 from http://inspiredhorizons.com/presentations/CreatingDSLsInRuby-060926.pdf

[5] Venkat Subramaniam, Creating DSL’s in java. Retrieved September 16, 2010 from http://www.java2s.com/Article/Java/Development/DSL.htm

[6] Jamis Buck. Writing Domain Specific Languages. Retrieved September 16, 2010 from http://weblog.jamisbuck.org/2006/4/20/writing-domain-specific-languages

[7] Alex Ruiz, Jeff Bay. An Approach to Internal Domain-Specific Languages in Java Retreved September 16, 2010 from http://www.infoq.com/articles/internal-dsls-java

[8] ColdFusion Markup Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/ColdFusion_Markup_Language

[9] MOO. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/MOO

[10] Freedom Dumlao. Introducing Kiddo: A Ruby DSL for building simple WPF and Silverlight applications. Retrieved September 15, 2010 from http://weblogs.asp.net/freedomdumlao/archive/2010/05/27/introducing-kiddo-a-ruby-dsl-for-building-simple-wpf-and-silverlight-applications.aspx

[11] LPC (programming language). Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/LPC_(programming_language)

[12] Kermeta Language Overview. Retrieved September 15, 2010 from https://www.kermeta.org/docs/KerMeta-MetaModel.pdf

CSC/ECE 517 Fall 2010/ch2 S23 SS

2010-09-22T21:41:52Z

Sumi2509:

''Domain Specific Object Oriented Languages''

==Introduction==

Domain Specific Language (DSL) is any programming language which is designed to solve some specific problems and tasks in a specific domain. These languages are very focused and restricted to particular problem domain. This is in contrast to general programming languages (GPL) like java or C++ which can be used for software development in many application domains. Examples for DSL include:
* SQL for relational database
* Verilog for statistics
* Latex for typesetting

Object Oriented DSL's (OODSL) are DSL's based on object oriented programming paradigm. They employ the idea of classes and objects with concepts like encapsulation, polymorphism, abstraction etc. OODSL's like any other DSL's are much more expressive in their domain and much less comprehensive than general purpose object oriented programming languages like Java, C# etc. They are high-level languages, in the sense that they abstract from low-level implementation details. Some OODSL examples are Rails based on ruby programming language and JSP tags, Hibernate and Spring based on Java.

===Pros and Cons of OODSL===

Like any other DSL, employing OODSL in any application domain comes with its own set of advantages and disadvantages. Some of them are discussed below.

Pros of using OODSL for application development are:
* OODSL's are developed for a particular domain and hence can handle the problems related to that domain. They help express solution in the idiom and abstraction of problem domain and can be easily understood by experts in that domain.
* OODSL's are much simpler to use than general purpose language in their domain.
* They are concise, self documented and easy to understand and hence aid in easy development, maintainability and productivity

On the other side, cons of using OODSL are:
* Developing an OODSL require effort and cost.
* OODSL has limited scope within their domain.
* Using a newly developed OODSL requires users to understand its syntax.
* Using OODSL together with GPL constructs can be a difficult task.

===Types of OODSL===

OODSL can be of two types, internal and external :

'''Internal OODSL''' are the ones which use a host language and give them the feel of a particular language. Developing internal OODSL's is comparatively simple as they use grammar, parsers and tools of underlying language. But they are constrained by the underlying language. The challenge is to design these languages so as to have syntax within the confines of host language, yet these languages are simple, concise and fluent. An example of internal OODSL would be Rake (make equivalent) based on host, Ruby.Internal OODSL's are also referred as embedded languages or fluent interfaces.

'''External OODSL''', on the other hand is designed to be independent of any other language. Syntax, grammar, parsing of these languages is pretty much based on its author choice and gives both pain and pleasure of developing all from scratch. Example of external DSL would be Ant based on java.

==History of OODSLs==

History of DSL dates back than modeling approaches used now to develop them. Initial DSL's were developed many decades before. Worth mentioning is FORTRAN developed in late 1950s, an abbreviation of 'formula translation'. FORTRAN borrowed notation from mathematics so that programmers could write mathematical formulas directly. OODSL's started coming up after object oriented paradigm became prominent in 1970's and 1980's. OODSL's appeared mostly in late 1980's and 1990's. Now, OODSL's are used in web applications (e.g. Rails), computer games and environments (e.g. MOO programming) and as programming languages for music (e.g. Formes).

==OODSL Examples==

Some examples of OODSL prevalent today are:

* '''Kiddo''' - Kiddo is an internal OODSL based on ruby and used for building silverlight and WPF applications. Kiddo is based on ideals of "kid friendly" coding and has 5 core methods to get started with drawing.
* '''ColdFusion Markup Language''' - Commonly known as CFML, it is a scripting language used by Adobe's ColdFusion and other scripting engines. The CFML includes a set of tags that can be used in ColdFusion pages to interact with data sources and display output.
* '''MOO Programming Language''' - Moo programming language is used to support Mud Object Oriented or MOO server which is online virtual reality system to which multiple players can connect at the same time. Its domain is computer gaming environment.
* '''LPC''' - It is an object-oriented programming language derived from C and developed originally to facilitate MUD building. It was designed for game development.
* '''Formes''' - It is an object-oriented DSL used for music composition and synthesis. It is written in VLISP.
* '''R - R''' is a programming language for statistical computing and graphics. R has stronger object-oriented programming facilities than most statistical computing languages available.
* '''Kermeta''' - Kermeta is a meta-modeling language used to describe structure and the behavior of models. Kermeta can be used as the core language for a model oriented platform.

==Creating an OODSL==

OODSL can be created using many techniques and tools available in the market.

===Properties of any OODSL:===

Any OODSL should be fluent and in context.

* '''Fluency''': A fluent OODSL should have interfaces which are properly designed for human use and has high readability and natural flows within the language. An example explaining fluency is given below:

Looping through any collection in java was done traditionally as:

for(int i = 0; i < products.size(); i++)
{
String name = (String) products.get(i);
//...
//.....

}

However it can be done more fluently starting Java 5 as:

for(String product : products)
{
// ...
// ...
}

This flow comes naturally to any user and is easier to interpret.

* '''Context:''' OODSL should have a proper context on which they are built upon, after all, they are domain specific. Shared context makes OODSL easier to understand and work with and highly expressive. For example:

In java declaring and adding into the cart is done as:

java.util.ArrayList<String> cart = new java.util.ArrayList<String>();
cart.add("Milk");
cart.add("Juice");
cart.add("Apple");
System.out.print("My cart has %d items.", cart.size())

Same thing can be done in groovy as:
cart = []
cart.with {
add "Milk"
add "Juice"
add "Apple"
println "My cart has $size items."
}

Languages like Groovy and javascript are easier than java to build context such that convention is followed.

Examples taken from: http://www.javaworld.com/javaworld/jw-07-2008/jw-07-dsls-in-java-2.html?page=3

===Techniques/Tools used===

There are many OO languages like Smalltalk, ruby, groovy which easily lend themselves for creating internal OODSL. Ruby provides expressive, flexible syntax and has a dynamic nature which makes implementing a new OODSL easy without using any additional parser or compiler. Also, groovy easily supports creating fluent and in context OODSL's. On the other hand, C++ or Java syntax is not easy to attain the level of fluency required for a DSL, and so creating internal OODSLs using these languages is challenging. However, these languages offer good parsing libraries or capabilities and their support for creating external DSL’s is pretty strong.

Tools like visual studio and ANTLR aid in creating OODSL. Visual studio contains Domain-Specific Language Designer Wizard which provides many solution templates which can be used to create an OODSL. ANTLR, ANother Tool for Language Recognition, is another language tool that provides a framework for constructing recognizers, interpreters, compilers, and translators from grammatical descriptions. It supports many runtime libraries of ruby, C#, java etc which helps to create internal OODSL.

There are four basic approaches used for creating OODSL. These are:

* '''Instantiation:''' This approach is used mostly in Ruby projects, and not even recognized as a DSL. Using this approach, DSL is defined by defining methods of an object. Interaction is like any other OODSL, done by instantiating the object and calling the methods. The HTML creation DSL of Ruby’s CGI class uses this approach.
* '''Class macros:''' DSL is defined as methods on some ancestor class, and those methods are tweaked to modify the behavior of super-class and for subclasses of the particular class in question. These kinds of macros often create new methods. “has_many” in ActiveRecord is a good example of this type of approach.
* '''Top-level methods:''' There exists a configuration file, which is just like a Ruby script augmented with some DSL syntax. Any application using this type of DSL will load this configuration and uses DSL top level methods defined. When those methods are called in the configuration file, they modify some central (typically global) data, which then application uses to determine how it should execute. Rake is an example of this kind of DSL.
* '''Sandboxing:''' This approach is a special case of the more general instantiation technique. Using this technique, DSL is defined as methods of some object which is really just a “sandbox”. Interaction with the object’s methods modifies state of the sandbox which is queried by the application. This technique is similar to the top-level methods technique, with an exception that the DSL is restricted to the sandbox and there are no global methods involved. Needle uses this approach.

===Steps to create an OODSL===

Some of the steps which can be used to create an OODSL are:
* Identifying the goals to be accomplished.
* Reasoning why creating a new OODSL would be better than existing well crafted OODSL or an API.
* Defining ideal syntax before even coding.
* Referring to other examples of OODSL's, learning from their code and looking at the similarities.
* Refining syntax to get the best Return on Investment. If creating an internal OODSL, it is best to take advantage of host language’s compiler and adapting syntax slightly without creating a new full fledged parser or compiler.

==Example==

Below is an example of how an OODSL for creating SQL statements and querying database systems can be created. It is compared with how the same task is done in general purpose language.

Dynamic construction of an SQL statement in Java :

String sql = "select id, name " +
"from customers c, order o " +
"where " +
"c.since >= sysdate - 30 and " +
"sum(o.total) > " + significantTotal + " and " +
"c.id = o.customer_id and " +
"nvl(c.status, 'DROPPED') != 'DROPPED'";

The same can be written using OODSL as follows :

Table c = CUSTOMER.alias();
Table o = ORDER.alias();
Clause recent = c.SINCE.laterThan(daysEarlier(30));
Clause hasSignificantOrders = o.TOTAL.sum().isAbove(significantTotal);
Clause ordersMatch = c.ID.matches(o.CUSTOMER_ID);
Clause activeCustomer = c.STATUS.isNotNullOr("DROPPED");
String sql = CUSTOMERS.where(recent.and(hasSignificantOrders)
.and(ordersMatch)
.and(activeCustomer)
.select(c.ID, c.NAME)
.sql();

The SQL statement written in Java requires developer to be familiar with Oracle-SQL. This may not be the case for every application development in every domain. An OODSL like above can help in these cases. Creating basic classes representing different constructs of SQL query makes creating query easy. E.g. Class “Table” represents a basic API available through DSL and is used for representing tables which are to be queried. Creating different clauses using class “Clause” help filter data from the database.

The DSL code is less procedural, more declarative and object-oriented. It also has several advantages, major one being creating SQL statements without having familiarity of how to write SQL statements in database packages like Oracle, MySQL etc. The commonly used phrase, “nvl(c.status, 'DROPPED') != 'DROPPED'" in Oracle SQL cannot be easily understood by a non-SQL programmer. By replacing this phrase with the more easily understandable and language-like "isNotNullOr(“DROPPED”)," readability has been enhanced, and the system is protected from a later need to change the implementation to take advantage of facilities offered by another database vendor.

Note: The above example was explained in an easier manner. Further reading can be done from original source, http://www.infoq.com/articles/internal-dsls-java

==Summary==

This article gives some basic overview of OODSL features. OODSLs are mainly used in the domain of software engineering. The challenge using software engineering is to create flexible, reliable, scalable and maintainable systems. To achieve this, the software engineer must apply a wide variety of tools and techniques. One of these is to take advantage of the knowledge from underlying application domain, by means of a domain-specific language (DSL), which provides a notation that can be used to compose applications from a set of concepts tailored towards a specific application domain. Creating OODSL is a good option because OODSL provides benefits from both the worlds, DSL and OO concepts. An OODSL can be easily extended later, if required, which may not be the case with any other DSL. Hence it can be said that, OODSLs provide a certain level of abstraction of a domain, which can result in a greater control over or understanding of that domain. At the same time, they provide some good features of object oriented programming.

==References==
[1] Eelco Visser. WebDSL: A Case Study in Domain-Specific Language Engineering. Lecture Notes in Computer Science, 2008, Volume 5235/2008, 291-373.

[2] Martin Fowler. MF Bliki: DomainSpecificLanguage. Retrieved September 15, 2010, from, http://www.martinfowler.com/bliki/DomainSpecificLanguage.html

[3] Domain-specific Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/Domain-specific_language.

[4] Jeff Barczewski. Creating DSL’s in Ruby. Retrieved September 16, 2010 from http://inspiredhorizons.com/presentations/CreatingDSLsInRuby-060926.pdf

[5] Venkat Subramaniam, Creating DSL’s in java. Retrieved September 16, 2010 from http://www.java2s.com/Article/Java/Development/DSL.htm

[6] Jamis Buck. Writing Domain Specific Languages. Retrieved September 16, 2010 from http://weblog.jamisbuck.org/2006/4/20/writing-domain-specific-languages

[7] Alex Ruiz, Jeff Bay. An Approach to Internal Domain-Specific Languages in Java Retreved September 16, 2010 from http://www.infoq.com/articles/internal-dsls-java

[8] ColdFusion Markup Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/ColdFusion_Markup_Language

[9] MOO. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/MOO

[10] Freedom Dumlao. Introducing Kiddo: A Ruby DSL for building simple WPF and Silverlight applications. Retrieved September 15, 2010 from http://weblogs.asp.net/freedomdumlao/archive/2010/05/27/introducing-kiddo-a-ruby-dsl-for-building-simple-wpf-and-silverlight-applications.aspx

[11] LPC (programming language). Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/LPC_(programming_language)

[12] Kermeta Language Overview. Retrieved September 15, 2010 from https://www.kermeta.org/docs/KerMeta-MetaModel.pdf

CSC/ECE 517 Fall 2010/ch2 S23 SS

2010-09-22T21:41:35Z

Sumi2509:

''''Domain Specific Object Oriented Languages''''

==Introduction==

Domain Specific Language (DSL) is any programming language which is designed to solve some specific problems and tasks in a specific domain. These languages are very focused and restricted to particular problem domain. This is in contrast to general programming languages (GPL) like java or C++ which can be used for software development in many application domains. Examples for DSL include:
* SQL for relational database
* Verilog for statistics
* Latex for typesetting

Object Oriented DSL's (OODSL) are DSL's based on object oriented programming paradigm. They employ the idea of classes and objects with concepts like encapsulation, polymorphism, abstraction etc. OODSL's like any other DSL's are much more expressive in their domain and much less comprehensive than general purpose object oriented programming languages like Java, C# etc. They are high-level languages, in the sense that they abstract from low-level implementation details. Some OODSL examples are Rails based on ruby programming language and JSP tags, Hibernate and Spring based on Java.

===Pros and Cons of OODSL===

Like any other DSL, employing OODSL in any application domain comes with its own set of advantages and disadvantages. Some of them are discussed below.

Pros of using OODSL for application development are:
* OODSL's are developed for a particular domain and hence can handle the problems related to that domain. They help express solution in the idiom and abstraction of problem domain and can be easily understood by experts in that domain.
* OODSL's are much simpler to use than general purpose language in their domain.
* They are concise, self documented and easy to understand and hence aid in easy development, maintainability and productivity

On the other side, cons of using OODSL are:
* Developing an OODSL require effort and cost.
* OODSL has limited scope within their domain.
* Using a newly developed OODSL requires users to understand its syntax.
* Using OODSL together with GPL constructs can be a difficult task.

===Types of OODSL===

OODSL can be of two types, internal and external :

'''Internal OODSL''' are the ones which use a host language and give them the feel of a particular language. Developing internal OODSL's is comparatively simple as they use grammar, parsers and tools of underlying language. But they are constrained by the underlying language. The challenge is to design these languages so as to have syntax within the confines of host language, yet these languages are simple, concise and fluent. An example of internal OODSL would be Rake (make equivalent) based on host, Ruby.Internal OODSL's are also referred as embedded languages or fluent interfaces.

'''External OODSL''', on the other hand is designed to be independent of any other language. Syntax, grammar, parsing of these languages is pretty much based on its author choice and gives both pain and pleasure of developing all from scratch. Example of external DSL would be Ant based on java.

==History of OODSLs==

History of DSL dates back than modeling approaches used now to develop them. Initial DSL's were developed many decades before. Worth mentioning is FORTRAN developed in late 1950s, an abbreviation of 'formula translation'. FORTRAN borrowed notation from mathematics so that programmers could write mathematical formulas directly. OODSL's started coming up after object oriented paradigm became prominent in 1970's and 1980's. OODSL's appeared mostly in late 1980's and 1990's. Now, OODSL's are used in web applications (e.g. Rails), computer games and environments (e.g. MOO programming) and as programming languages for music (e.g. Formes).

==OODSL Examples==

Some examples of OODSL prevalent today are:

* '''Kiddo''' - Kiddo is an internal OODSL based on ruby and used for building silverlight and WPF applications. Kiddo is based on ideals of "kid friendly" coding and has 5 core methods to get started with drawing.
* '''ColdFusion Markup Language''' - Commonly known as CFML, it is a scripting language used by Adobe's ColdFusion and other scripting engines. The CFML includes a set of tags that can be used in ColdFusion pages to interact with data sources and display output.
* '''MOO Programming Language''' - Moo programming language is used to support Mud Object Oriented or MOO server which is online virtual reality system to which multiple players can connect at the same time. Its domain is computer gaming environment.
* '''LPC''' - It is an object-oriented programming language derived from C and developed originally to facilitate MUD building. It was designed for game development.
* '''Formes''' - It is an object-oriented DSL used for music composition and synthesis. It is written in VLISP.
* '''R - R''' is a programming language for statistical computing and graphics. R has stronger object-oriented programming facilities than most statistical computing languages available.
* '''Kermeta''' - Kermeta is a meta-modeling language used to describe structure and the behavior of models. Kermeta can be used as the core language for a model oriented platform.

==Creating an OODSL==

OODSL can be created using many techniques and tools available in the market.

===Properties of any OODSL:===

Any OODSL should be fluent and in context.

* '''Fluency''': A fluent OODSL should have interfaces which are properly designed for human use and has high readability and natural flows within the language. An example explaining fluency is given below:

Looping through any collection in java was done traditionally as:

for(int i = 0; i < products.size(); i++)
{
String name = (String) products.get(i);
//...
//.....

}

However it can be done more fluently starting Java 5 as:

for(String product : products)
{
// ...
// ...
}

This flow comes naturally to any user and is easier to interpret.

* '''Context:''' OODSL should have a proper context on which they are built upon, after all, they are domain specific. Shared context makes OODSL easier to understand and work with and highly expressive. For example:

In java declaring and adding into the cart is done as:

java.util.ArrayList<String> cart = new java.util.ArrayList<String>();
cart.add("Milk");
cart.add("Juice");
cart.add("Apple");
System.out.print("My cart has %d items.", cart.size())

Same thing can be done in groovy as:
cart = []
cart.with {
add "Milk"
add "Juice"
add "Apple"
println "My cart has $size items."
}

Languages like Groovy and javascript are easier than java to build context such that convention is followed.

Examples taken from: http://www.javaworld.com/javaworld/jw-07-2008/jw-07-dsls-in-java-2.html?page=3

===Techniques/Tools used===

There are many OO languages like Smalltalk, ruby, groovy which easily lend themselves for creating internal OODSL. Ruby provides expressive, flexible syntax and has a dynamic nature which makes implementing a new OODSL easy without using any additional parser or compiler. Also, groovy easily supports creating fluent and in context OODSL's. On the other hand, C++ or Java syntax is not easy to attain the level of fluency required for a DSL, and so creating internal OODSLs using these languages is challenging. However, these languages offer good parsing libraries or capabilities and their support for creating external DSL’s is pretty strong.

Tools like visual studio and ANTLR aid in creating OODSL. Visual studio contains Domain-Specific Language Designer Wizard which provides many solution templates which can be used to create an OODSL. ANTLR, ANother Tool for Language Recognition, is another language tool that provides a framework for constructing recognizers, interpreters, compilers, and translators from grammatical descriptions. It supports many runtime libraries of ruby, C#, java etc which helps to create internal OODSL.

There are four basic approaches used for creating OODSL. These are:

* '''Instantiation:''' This approach is used mostly in Ruby projects, and not even recognized as a DSL. Using this approach, DSL is defined by defining methods of an object. Interaction is like any other OODSL, done by instantiating the object and calling the methods. The HTML creation DSL of Ruby’s CGI class uses this approach.
* '''Class macros:''' DSL is defined as methods on some ancestor class, and those methods are tweaked to modify the behavior of super-class and for subclasses of the particular class in question. These kinds of macros often create new methods. “has_many” in ActiveRecord is a good example of this type of approach.
* '''Top-level methods:''' There exists a configuration file, which is just like a Ruby script augmented with some DSL syntax. Any application using this type of DSL will load this configuration and uses DSL top level methods defined. When those methods are called in the configuration file, they modify some central (typically global) data, which then application uses to determine how it should execute. Rake is an example of this kind of DSL.
* '''Sandboxing:''' This approach is a special case of the more general instantiation technique. Using this technique, DSL is defined as methods of some object which is really just a “sandbox”. Interaction with the object’s methods modifies state of the sandbox which is queried by the application. This technique is similar to the top-level methods technique, with an exception that the DSL is restricted to the sandbox and there are no global methods involved. Needle uses this approach.

===Steps to create an OODSL===

Some of the steps which can be used to create an OODSL are:
* Identifying the goals to be accomplished.
* Reasoning why creating a new OODSL would be better than existing well crafted OODSL or an API.
* Defining ideal syntax before even coding.
* Referring to other examples of OODSL's, learning from their code and looking at the similarities.
* Refining syntax to get the best Return on Investment. If creating an internal OODSL, it is best to take advantage of host language’s compiler and adapting syntax slightly without creating a new full fledged parser or compiler.

==Example==

Below is an example of how an OODSL for creating SQL statements and querying database systems can be created. It is compared with how the same task is done in general purpose language.

Dynamic construction of an SQL statement in Java :

String sql = "select id, name " +
"from customers c, order o " +
"where " +
"c.since >= sysdate - 30 and " +
"sum(o.total) > " + significantTotal + " and " +
"c.id = o.customer_id and " +
"nvl(c.status, 'DROPPED') != 'DROPPED'";

The same can be written using OODSL as follows :

Table c = CUSTOMER.alias();
Table o = ORDER.alias();
Clause recent = c.SINCE.laterThan(daysEarlier(30));
Clause hasSignificantOrders = o.TOTAL.sum().isAbove(significantTotal);
Clause ordersMatch = c.ID.matches(o.CUSTOMER_ID);
Clause activeCustomer = c.STATUS.isNotNullOr("DROPPED");
String sql = CUSTOMERS.where(recent.and(hasSignificantOrders)
.and(ordersMatch)
.and(activeCustomer)
.select(c.ID, c.NAME)
.sql();

The SQL statement written in Java requires developer to be familiar with Oracle-SQL. This may not be the case for every application development in every domain. An OODSL like above can help in these cases. Creating basic classes representing different constructs of SQL query makes creating query easy. E.g. Class “Table” represents a basic API available through DSL and is used for representing tables which are to be queried. Creating different clauses using class “Clause” help filter data from the database.

The DSL code is less procedural, more declarative and object-oriented. It also has several advantages, major one being creating SQL statements without having familiarity of how to write SQL statements in database packages like Oracle, MySQL etc. The commonly used phrase, “nvl(c.status, 'DROPPED') != 'DROPPED'" in Oracle SQL cannot be easily understood by a non-SQL programmer. By replacing this phrase with the more easily understandable and language-like "isNotNullOr(“DROPPED”)," readability has been enhanced, and the system is protected from a later need to change the implementation to take advantage of facilities offered by another database vendor.

Note: The above example was explained in an easier manner. Further reading can be done from original source, http://www.infoq.com/articles/internal-dsls-java

==Summary==

This article gives some basic overview of OODSL features. OODSLs are mainly used in the domain of software engineering. The challenge using software engineering is to create flexible, reliable, scalable and maintainable systems. To achieve this, the software engineer must apply a wide variety of tools and techniques. One of these is to take advantage of the knowledge from underlying application domain, by means of a domain-specific language (DSL), which provides a notation that can be used to compose applications from a set of concepts tailored towards a specific application domain. Creating OODSL is a good option because OODSL provides benefits from both the worlds, DSL and OO concepts. An OODSL can be easily extended later, if required, which may not be the case with any other DSL. Hence it can be said that, OODSLs provide a certain level of abstraction of a domain, which can result in a greater control over or understanding of that domain. At the same time, they provide some good features of object oriented programming.

==References==
[1] Eelco Visser. WebDSL: A Case Study in Domain-Specific Language Engineering. Lecture Notes in Computer Science, 2008, Volume 5235/2008, 291-373.

[2] Martin Fowler. MF Bliki: DomainSpecificLanguage. Retrieved September 15, 2010, from, http://www.martinfowler.com/bliki/DomainSpecificLanguage.html

[3] Domain-specific Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/Domain-specific_language.

[4] Jeff Barczewski. Creating DSL’s in Ruby. Retrieved September 16, 2010 from http://inspiredhorizons.com/presentations/CreatingDSLsInRuby-060926.pdf

[5] Venkat Subramaniam, Creating DSL’s in java. Retrieved September 16, 2010 from http://www.java2s.com/Article/Java/Development/DSL.htm

[6] Jamis Buck. Writing Domain Specific Languages. Retrieved September 16, 2010 from http://weblog.jamisbuck.org/2006/4/20/writing-domain-specific-languages

[7] Alex Ruiz, Jeff Bay. An Approach to Internal Domain-Specific Languages in Java Retreved September 16, 2010 from http://www.infoq.com/articles/internal-dsls-java

[8] ColdFusion Markup Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/ColdFusion_Markup_Language

[9] MOO. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/MOO

[10] Freedom Dumlao. Introducing Kiddo: A Ruby DSL for building simple WPF and Silverlight applications. Retrieved September 15, 2010 from http://weblogs.asp.net/freedomdumlao/archive/2010/05/27/introducing-kiddo-a-ruby-dsl-for-building-simple-wpf-and-silverlight-applications.aspx

[11] LPC (programming language). Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/LPC_(programming_language)

[12] Kermeta Language Overview. Retrieved September 15, 2010 from https://www.kermeta.org/docs/KerMeta-MetaModel.pdf

CSC/ECE 517 Fall 2010/ch2 S23 SS

2010-09-22T21:39:56Z

Sumi2509: /* Introduction */

=Domain Specific Object Oriented Languages=

==Introduction==

Domain Specific Language (DSL) is any programming language which is designed to solve some specific problems and tasks in a specific domain. These languages are very focused and restricted to particular problem domain. This is in contrast to general programming languages (GPL) like java or C++ which can be used for software development in many application domains. Examples for DSL include:
* SQL for relational database
* Verilog for statistics
* Latex for typesetting

Object Oriented DSL's (OODSL) are DSL's based on object oriented programming paradigm. They employ the idea of classes and objects with concepts like encapsulation, polymorphism, abstraction etc. OODSL's like any other DSL's are much more expressive in their domain and much less comprehensive than general purpose object oriented programming languages like Java, C# etc. They are high-level languages, in the sense that they abstract from low-level implementation details. Some OODSL examples are Rails based on ruby programming language and JSP tags, Hibernate and Spring based on Java.

===Pros and Cons of OODSL===

Like any other DSL, employing OODSL in any application domain comes with its own set of advantages and disadvantages. Some of them are discussed below.

Pros of using OODSL for application development are:
* OODSL's are developed for a particular domain and hence can handle the problems related to that domain. They help express solution in the idiom and abstraction of problem domain and can be easily understood by experts in that domain.
* OODSL's are much simpler to use than general purpose language in their domain.
* They are concise, self documented and easy to understand and hence aid in easy development, maintainability and productivity

On the other side, cons of using OODSL are:
* Developing an OODSL require effort and cost.
* OODSL has limited scope within their domain.
* Using a newly developed OODSL requires users to understand its syntax.
* Using OODSL together with GPL constructs can be a difficult task.

===Types of OODSL===

OODSL can be of two types, internal and external :

'''Internal OODSL''' are the ones which use a host language and give them the feel of a particular language. Developing internal OODSL's is comparatively simple as they use grammar, parsers and tools of underlying language. But they are constrained by the underlying language. The challenge is to design these languages so as to have syntax within the confines of host language, yet these languages are simple, concise and fluent. An example of internal OODSL would be Rake (make equivalent) based on host, Ruby.Internal OODSL's are also referred as embedded languages or fluent interfaces.

'''External OODSL''', on the other hand is designed to be independent of any other language. Syntax, grammar, parsing of these languages is pretty much based on its author choice and gives both pain and pleasure of developing all from scratch. Example of external DSL would be Ant based on java.

==History of OODSLs==

History of DSL dates back than modeling approaches used now to develop them. Initial DSL's were developed many decades before. Worth mentioning is FORTRAN developed in late 1950s, an abbreviation of 'formula translation'. FORTRAN borrowed notation from mathematics so that programmers could write mathematical formulas directly. OODSL's started coming up after object oriented paradigm became prominent in 1970's and 1980's. OODSL's appeared mostly in late 1980's and 1990's. Now, OODSL's are used in web applications (e.g. Rails), computer games and environments (e.g. MOO programming) and as programming languages for music (e.g. Formes).

==OODSL Examples==

Some examples of OODSL prevalent today are:

* '''Kiddo''' - Kiddo is an internal OODSL based on ruby and used for building silverlight and WPF applications. Kiddo is based on ideals of "kid friendly" coding and has 5 core methods to get started with drawing.
* '''ColdFusion Markup Language''' - Commonly known as CFML, it is a scripting language used by Adobe's ColdFusion and other scripting engines. The CFML includes a set of tags that can be used in ColdFusion pages to interact with data sources and display output.
* '''MOO Programming Language''' - Moo programming language is used to support Mud Object Oriented or MOO server which is online virtual reality system to which multiple players can connect at the same time. Its domain is computer gaming environment.
* '''LPC''' - It is an object-oriented programming language derived from C and developed originally to facilitate MUD building. It was designed for game development.
* '''Formes''' - It is an object-oriented DSL used for music composition and synthesis. It is written in VLISP.
* '''R - R''' is a programming language for statistical computing and graphics. R has stronger object-oriented programming facilities than most statistical computing languages available.
* '''Kermeta''' - Kermeta is a meta-modeling language used to describe structure and the behavior of models. Kermeta can be used as the core language for a model oriented platform.

==Creating an OODSL==

OODSL can be created using many techniques and tools available in the market.

===Properties of any OODSL:===

Any OODSL should be fluent and in context.

* '''Fluency''': A fluent OODSL should have interfaces which are properly designed for human use and has high readability and natural flows within the language. An example explaining fluency is given below:

Looping through any collection in java was done traditionally as:

for(int i = 0; i < products.size(); i++)
{
String name = (String) products.get(i);
//...
//.....

}

However it can be done more fluently starting Java 5 as:

for(String product : products)
{
// ...
// ...
}

This flow comes naturally to any user and is easier to interpret.

* '''Context:''' OODSL should have a proper context on which they are built upon, after all, they are domain specific. Shared context makes OODSL easier to understand and work with and highly expressive. For example:

In java declaring and adding into the cart is done as:

java.util.ArrayList<String> cart = new java.util.ArrayList<String>();
cart.add("Milk");
cart.add("Juice");
cart.add("Apple");
System.out.print("My cart has %d items.", cart.size())

Same thing can be done in groovy as:
cart = []
cart.with {
add "Milk"
add "Juice"
add "Apple"
println "My cart has $size items."
}

Languages like Groovy and javascript are easier than java to build context such that convention is followed.

Examples taken from: http://www.javaworld.com/javaworld/jw-07-2008/jw-07-dsls-in-java-2.html?page=3

===Techniques/Tools used===

There are many OO languages like Smalltalk, ruby, groovy which easily lend themselves for creating internal OODSL. Ruby provides expressive, flexible syntax and has a dynamic nature which makes implementing a new OODSL easy without using any additional parser or compiler. Also, groovy easily supports creating fluent and in context OODSL's. On the other hand, C++ or Java syntax is not easy to attain the level of fluency required for a DSL, and so creating internal OODSLs using these languages is challenging. However, these languages offer good parsing libraries or capabilities and their support for creating external DSL’s is pretty strong.

Tools like visual studio and ANTLR aid in creating OODSL. Visual studio contains Domain-Specific Language Designer Wizard which provides many solution templates which can be used to create an OODSL. ANTLR, ANother Tool for Language Recognition, is another language tool that provides a framework for constructing recognizers, interpreters, compilers, and translators from grammatical descriptions. It supports many runtime libraries of ruby, C#, java etc which helps to create internal OODSL.

There are four basic approaches used for creating OODSL. These are:

* '''Instantiation:''' This approach is used mostly in Ruby projects, and not even recognized as a DSL. Using this approach, DSL is defined by defining methods of an object. Interaction is like any other OODSL, done by instantiating the object and calling the methods. The HTML creation DSL of Ruby’s CGI class uses this approach.
* '''Class macros:''' DSL is defined as methods on some ancestor class, and those methods are tweaked to modify the behavior of super-class and for subclasses of the particular class in question. These kinds of macros often create new methods. “has_many” in ActiveRecord is a good example of this type of approach.
* '''Top-level methods:''' There exists a configuration file, which is just like a Ruby script augmented with some DSL syntax. Any application using this type of DSL will load this configuration and uses DSL top level methods defined. When those methods are called in the configuration file, they modify some central (typically global) data, which then application uses to determine how it should execute. Rake is an example of this kind of DSL.
* '''Sandboxing:''' This approach is a special case of the more general instantiation technique. Using this technique, DSL is defined as methods of some object which is really just a “sandbox”. Interaction with the object’s methods modifies state of the sandbox which is queried by the application. This technique is similar to the top-level methods technique, with an exception that the DSL is restricted to the sandbox and there are no global methods involved. Needle uses this approach.

===Steps to create an OODSL===

Some of the steps which can be used to create an OODSL are:
* Identifying the goals to be accomplished.
* Reasoning why creating a new OODSL would be better than existing well crafted OODSL or an API.
* Defining ideal syntax before even coding.
* Referring to other examples of OODSL's, learning from their code and looking at the similarities.
* Refining syntax to get the best Return on Investment. If creating an internal OODSL, it is best to take advantage of host language’s compiler and adapting syntax slightly without creating a new full fledged parser or compiler.

==Example==

Below is an example of how an OODSL for creating SQL statements and querying database systems can be created. It is compared with how the same task is done in general purpose language.

Dynamic construction of an SQL statement in Java :

String sql = "select id, name " +
"from customers c, order o " +
"where " +
"c.since >= sysdate - 30 and " +
"sum(o.total) > " + significantTotal + " and " +
"c.id = o.customer_id and " +
"nvl(c.status, 'DROPPED') != 'DROPPED'";

The same can be written using OODSL as follows :

Table c = CUSTOMER.alias();
Table o = ORDER.alias();
Clause recent = c.SINCE.laterThan(daysEarlier(30));
Clause hasSignificantOrders = o.TOTAL.sum().isAbove(significantTotal);
Clause ordersMatch = c.ID.matches(o.CUSTOMER_ID);
Clause activeCustomer = c.STATUS.isNotNullOr("DROPPED");
String sql = CUSTOMERS.where(recent.and(hasSignificantOrders)
.and(ordersMatch)
.and(activeCustomer)
.select(c.ID, c.NAME)
.sql();

The SQL statement written in Java requires developer to be familiar with Oracle-SQL. This may not be the case for every application development in every domain. An OODSL like above can help in these cases. Creating basic classes representing different constructs of SQL query makes creating query easy. E.g. Class “Table” represents a basic API available through DSL and is used for representing tables which are to be queried. Creating different clauses using class “Clause” help filter data from the database.

The DSL code is less procedural, more declarative and object-oriented. It also has several advantages, major one being creating SQL statements without having familiarity of how to write SQL statements in database packages like Oracle, MySQL etc. The commonly used phrase, “nvl(c.status, 'DROPPED') != 'DROPPED'" in Oracle SQL cannot be easily understood by a non-SQL programmer. By replacing this phrase with the more easily understandable and language-like "isNotNullOr(“DROPPED”)," readability has been enhanced, and the system is protected from a later need to change the implementation to take advantage of facilities offered by another database vendor.

Note: The above example was explained in an easier manner. Further reading can be done from original source, http://www.infoq.com/articles/internal-dsls-java

==Summary==

This article gives some basic overview of OODSL features. OODSLs are mainly used in the domain of software engineering. The challenge using software engineering is to create flexible, reliable, scalable and maintainable systems. To achieve this, the software engineer must apply a wide variety of tools and techniques. One of these is to take advantage of the knowledge from underlying application domain, by means of a domain-specific language (DSL), which provides a notation that can be used to compose applications from a set of concepts tailored towards a specific application domain. Creating OODSL is a good option because OODSL provides benefits from both the worlds, DSL and OO concepts. An OODSL can be easily extended later, if required, which may not be the case with any other DSL. Hence it can be said that, OODSLs provide a certain level of abstraction of a domain, which can result in a greater control over or understanding of that domain. At the same time, they provide some good features of object oriented programming.

==References==
[1] Eelco Visser. WebDSL: A Case Study in Domain-Specific Language Engineering. Lecture Notes in Computer Science, 2008, Volume 5235/2008, 291-373.

[2] Martin Fowler. MF Bliki: DomainSpecificLanguage. Retrieved September 15, 2010, from, http://www.martinfowler.com/bliki/DomainSpecificLanguage.html

[3] Domain-specific Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/Domain-specific_language.

[4] Jeff Barczewski. Creating DSL’s in Ruby. Retrieved September 16, 2010 from http://inspiredhorizons.com/presentations/CreatingDSLsInRuby-060926.pdf

[5] Venkat Subramaniam, Creating DSL’s in java. Retrieved September 16, 2010 from http://www.java2s.com/Article/Java/Development/DSL.htm

[6] Jamis Buck. Writing Domain Specific Languages. Retrieved September 16, 2010 from http://weblog.jamisbuck.org/2006/4/20/writing-domain-specific-languages

[7] Alex Ruiz, Jeff Bay. An Approach to Internal Domain-Specific Languages in Java Retreved September 16, 2010 from http://www.infoq.com/articles/internal-dsls-java

[8] ColdFusion Markup Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/ColdFusion_Markup_Language

[9] MOO. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/MOO

[10] Freedom Dumlao. Introducing Kiddo: A Ruby DSL for building simple WPF and Silverlight applications. Retrieved September 15, 2010 from http://weblogs.asp.net/freedomdumlao/archive/2010/05/27/introducing-kiddo-a-ruby-dsl-for-building-simple-wpf-and-silverlight-applications.aspx

[11] LPC (programming language). Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/LPC_(programming_language)

[12] Kermeta Language Overview. Retrieved September 15, 2010 from https://www.kermeta.org/docs/KerMeta-MetaModel.pdf

CSC/ECE 517 Fall 2010/ch2 S23 SS

2010-09-22T16:09:14Z

Sumi2509: /* History of OODSLs */

==Introduction==

Domain Specific Language (DSL) is any programming language which is designed to solve some specific problems and tasks in a specific domain. These languages are very focused and restricted to particular problem domain. This is in contrast to general programming languages (GPL) like java or C++ which can be used for software development in many application domains. Examples for DSL include:
* SQL for relational database
* Verilog for statistics
* Latex for typesetting

Object Oriented DSL's (OODSL) are DSL's based on object oriented programming paradigm. They employ the idea of classes and objects with concepts like encapsulation, polymorphism, abstraction etc. OODSL's like any other DSL's are much more expressive in their domain and much less comprehensive than general purpose object oriented programming languages like Java, C# etc. They are high-level languages, in the sense that they abstract from low-level implementation details. Some OODSL examples are Rails based on ruby programming language and JSP tags, Hibernate and Spring based on Java.

===Pros and Cons of OODSL===

Like any other DSL, employing OODSL in any application domain comes with its own set of advantages and disadvantages. Some of them are discussed below.

Pros of using OODSL for application development are:
* OODSL's are developed for a particular domain and hence can handle the problems related to that domain. They help express solution in the idiom and abstraction of problem domain and can be easily understood by experts in that domain.
* OODSL's are much simpler to use than general purpose language in their domain.
* They are concise, self documented and easy to understand and hence aid in easy development, maintainability and productivity

On the other side, cons of using OODSL are:
* Developing an OODSL require effort and cost.
* OODSL has limited scope within their domain.
* Using a newly developed OODSL requires users to understand its syntax.
* Using OODSL together with GPL constructs can be a difficult task.

===Types of OODSL===

OODSL can be of two types, internal and external :

'''Internal OODSL''' are the ones which use a host language and give them the feel of a particular language. Developing internal OODSL's is comparatively simple as they use grammar, parsers and tools of underlying language. But they are constrained by the underlying language. The challenge is to design these languages so as to have syntax within the confines of host language, yet these languages are simple, concise and fluent. An example of internal OODSL would be Rake (make equivalent) based on host, Ruby.Internal OODSL's are also referred as embedded languages or fluent interfaces.

'''External OODSL''', on the other hand is designed to be independent of any other language. Syntax, grammar, parsing of these languages is pretty much based on its author choice and gives both pain and pleasure of developing all from scratch. Example of external DSL would be Ant based on java.

==History of OODSLs==

History of DSL dates back than modeling approaches used now to develop them. Initial DSL's were developed many decades before. Worth mentioning is FORTRAN developed in late 1950s, an abbreviation of 'formula translation'. FORTRAN borrowed notation from mathematics so that programmers could write mathematical formulas directly. OODSL's started coming up after object oriented paradigm became prominent in 1970's and 1980's. OODSL's appeared mostly in late 1980's and 1990's. Now, OODSL's are used in web applications (e.g. Rails), computer games and environments (e.g. MOO programming) and as programming languages for music (e.g. Formes).

==OODSL Examples==

Some examples of OODSL prevalent today are:

* '''Kiddo''' - Kiddo is an internal OODSL based on ruby and used for building silverlight and WPF applications. Kiddo is based on ideals of "kid friendly" coding and has 5 core methods to get started with drawing.
* '''ColdFusion Markup Language''' - Commonly known as CFML, it is a scripting language used by Adobe's ColdFusion and other scripting engines. The CFML includes a set of tags that can be used in ColdFusion pages to interact with data sources and display output.
* '''MOO Programming Language''' - Moo programming language is used to support Mud Object Oriented or MOO server which is online virtual reality system to which multiple players can connect at the same time. Its domain is computer gaming environment.
* '''LPC''' - It is an object-oriented programming language derived from C and developed originally to facilitate MUD building. It was designed for game development.
* '''Formes''' - It is an object-oriented DSL used for music composition and synthesis. It is written in VLISP.
* '''R - R''' is a programming language for statistical computing and graphics. R has stronger object-oriented programming facilities than most statistical computing languages available.
* '''Kermeta''' - Kermeta is a meta-modeling language used to describe structure and the behavior of models. Kermeta can be used as the core language for a model oriented platform.

==Creating an OODSL==

OODSL can be created using many techniques and tools available in the market.

===Properties of any OODSL:===

Any OODSL should be fluent and in context.

* '''Fluency''': A fluent OODSL should have interfaces which are properly designed for human use and has high readability and natural flows within the language. An example explaining fluency is given below:

Looping through any collection in java was done traditionally as:

for(int i = 0; i < products.size(); i++)
{
String name = (String) products.get(i);
//...
//.....

}

However it can be done more fluently starting Java 5 as:

for(String product : products)
{
// ...
// ...
}

This flow comes naturally to any user and is easier to interpret.

* '''Context:''' OODSL should have a proper context on which they are built upon, after all, they are domain specific. Shared context makes OODSL easier to understand and work with and highly expressive. For example:

In java declaring and adding into the cart is done as:

java.util.ArrayList<String> cart = new java.util.ArrayList<String>();
cart.add("Milk");
cart.add("Juice");
cart.add("Apple");
System.out.print("My cart has %d items.", cart.size())

Same thing can be done in groovy as:
cart = []
cart.with {
add "Milk"
add "Juice"
add "Apple"
println "My cart has $size items."
}

Languages like Groovy and javascript are easier than java to build context such that convention is followed.

Examples taken from: http://www.javaworld.com/javaworld/jw-07-2008/jw-07-dsls-in-java-2.html?page=3

===Techniques/Tools used===

There are many OO languages like Smalltalk, ruby, groovy which easily lend themselves for creating internal OODSL. Ruby provides expressive, flexible syntax and has a dynamic nature which makes implementing a new OODSL easy without using any additional parser or compiler. Also, groovy easily supports creating fluent and in context OODSL's. On the other hand, C++ or Java syntax is not easy to attain the level of fluency required for a DSL, and so creating internal OODSLs using these languages is challenging. However, these languages offer good parsing libraries or capabilities and their support for creating external DSL’s is pretty strong.

Tools like visual studio and ANTLR aid in creating OODSL. Visual studio contains Domain-Specific Language Designer Wizard which provides many solution templates which can be used to create an OODSL. ANTLR, ANother Tool for Language Recognition, is another language tool that provides a framework for constructing recognizers, interpreters, compilers, and translators from grammatical descriptions. It supports many runtime libraries of ruby, C#, java etc which helps to create internal OODSL.

There are four basic approaches used for creating OODSL. These are:

* '''Instantiation:''' This approach is used mostly in Ruby projects, and not even recognized as a DSL. Using this approach, DSL is defined by defining methods of an object. Interaction is like any other OODSL, done by instantiating the object and calling the methods. The HTML creation DSL of Ruby’s CGI class uses this approach.
* '''Class macros:''' DSL is defined as methods on some ancestor class, and those methods are tweaked to modify the behavior of super-class and for subclasses of the particular class in question. These kinds of macros often create new methods. “has_many” in ActiveRecord is a good example of this type of approach.
* '''Top-level methods:''' There exists a configuration file, which is just like a Ruby script augmented with some DSL syntax. Any application using this type of DSL will load this configuration and uses DSL top level methods defined. When those methods are called in the configuration file, they modify some central (typically global) data, which then application uses to determine how it should execute. Rake is an example of this kind of DSL.
* '''Sandboxing:''' This approach is a special case of the more general instantiation technique. Using this technique, DSL is defined as methods of some object which is really just a “sandbox”. Interaction with the object’s methods modifies state of the sandbox which is queried by the application. This technique is similar to the top-level methods technique, with an exception that the DSL is restricted to the sandbox and there are no global methods involved. Needle uses this approach.

===Steps to create an OODSL===

Some of the steps which can be used to create an OODSL are:
* Identifying the goals to be accomplished.
* Reasoning why creating a new OODSL would be better than existing well crafted OODSL or an API.
* Defining ideal syntax before even coding.
* Referring to other examples of OODSL's, learning from their code and looking at the similarities.
* Refining syntax to get the best Return on Investment. If creating an internal OODSL, it is best to take advantage of host language’s compiler and adapting syntax slightly without creating a new full fledged parser or compiler.

==Example==

Below is an example of how an OODSL for creating SQL statements and querying database systems can be created. It is compared with how the same task is done in general purpose language.

Dynamic construction of an SQL statement in Java :

String sql = "select id, name " +
"from customers c, order o " +
"where " +
"c.since >= sysdate - 30 and " +
"sum(o.total) > " + significantTotal + " and " +
"c.id = o.customer_id and " +
"nvl(c.status, 'DROPPED') != 'DROPPED'";

The same can be written using OODSL as follows :

Table c = CUSTOMER.alias();
Table o = ORDER.alias();
Clause recent = c.SINCE.laterThan(daysEarlier(30));
Clause hasSignificantOrders = o.TOTAL.sum().isAbove(significantTotal);
Clause ordersMatch = c.ID.matches(o.CUSTOMER_ID);
Clause activeCustomer = c.STATUS.isNotNullOr("DROPPED");
String sql = CUSTOMERS.where(recent.and(hasSignificantOrders)
.and(ordersMatch)
.and(activeCustomer)
.select(c.ID, c.NAME)
.sql();

The SQL statement written in Java requires developer to be familiar with Oracle-SQL. This may not be the case for every application development in every domain. An OODSL like above can help in these cases. Creating basic classes representing different constructs of SQL query makes creating query easy. E.g. Class “Table” represents a basic API available through DSL and is used for representing tables which are to be queried. Creating different clauses using class “Clause” help filter data from the database.

The DSL code is less procedural, more declarative and object-oriented. It also has several advantages, major one being creating SQL statements without having familiarity of how to write SQL statements in database packages like Oracle, MySQL etc. The commonly used phrase, “nvl(c.status, 'DROPPED') != 'DROPPED'" in Oracle SQL cannot be easily understood by a non-SQL programmer. By replacing this phrase with the more easily understandable and language-like "isNotNullOr(“DROPPED”)," readability has been enhanced, and the system is protected from a later need to change the implementation to take advantage of facilities offered by another database vendor.

Note: The above example was explained in an easier manner. Further reading can be done from original source, http://www.infoq.com/articles/internal-dsls-java

==Summary==

This article gives some basic overview of OODSL features. OODSLs are mainly used in the domain of software engineering. The challenge using software engineering is to create flexible, reliable, scalable and maintainable systems. To achieve this, the software engineer must apply a wide variety of tools and techniques. One of these is to take advantage of the knowledge from underlying application domain, by means of a domain-specific language (DSL), which provides a notation that can be used to compose applications from a set of concepts tailored towards a specific application domain. Creating OODSL is a good option because OODSL provides benefits from both the worlds, DSL and OO concepts. An OODSL can be easily extended later, if required, which may not be the case with any other DSL. Hence it can be said that, OODSLs provide a certain level of abstraction of a domain, which can result in a greater control over or understanding of that domain. At the same time, they provide some good features of object oriented programming.

==References==
[1] Eelco Visser. WebDSL: A Case Study in Domain-Specific Language Engineering. Lecture Notes in Computer Science, 2008, Volume 5235/2008, 291-373.

[2] Martin Fowler. MF Bliki: DomainSpecificLanguage. Retrieved September 15, 2010, from, http://www.martinfowler.com/bliki/DomainSpecificLanguage.html

[3] Domain-specific Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/Domain-specific_language.

[4] Jeff Barczewski. Creating DSL’s in Ruby. Retrieved September 16, 2010 from http://inspiredhorizons.com/presentations/CreatingDSLsInRuby-060926.pdf

[5] Venkat Subramaniam, Creating DSL’s in java. Retrieved September 16, 2010 from http://www.java2s.com/Article/Java/Development/DSL.htm

[6] Jamis Buck. Writing Domain Specific Languages. Retrieved September 16, 2010 from http://weblog.jamisbuck.org/2006/4/20/writing-domain-specific-languages

[7] Alex Ruiz, Jeff Bay. An Approach to Internal Domain-Specific Languages in Java Retreved September 16, 2010 from http://www.infoq.com/articles/internal-dsls-java

[8] ColdFusion Markup Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/ColdFusion_Markup_Language

[9] MOO. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/MOO

[10] Freedom Dumlao. Introducing Kiddo: A Ruby DSL for building simple WPF and Silverlight applications. Retrieved September 15, 2010 from http://weblogs.asp.net/freedomdumlao/archive/2010/05/27/introducing-kiddo-a-ruby-dsl-for-building-simple-wpf-and-silverlight-applications.aspx

[11] LPC (programming language). Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/LPC_(programming_language)

[12] Kermeta Language Overview. Retrieved September 15, 2010 from https://www.kermeta.org/docs/KerMeta-MetaModel.pdf

CSC/ECE 517 Fall 2010/ch2 S23 SS

2010-09-21T18:01:40Z

Sumi2509: /* References */

==Introduction==

Domain Specific Language (DSL) is any programming language which is designed to solve some specific problems and tasks in a specific domain. These languages are very focused and restricted to particular problem domain. This is in contrast to general programming languages (GPL) like java or C++ which can be used for software development in many application domains. Examples for DSL include:
* SQL for relational database
* Verilog for statistics
* Latex for typesetting

Object Oriented DSL's (OODSL) are DSL's based on object oriented programming paradigm. They employ the idea of classes and objects with concepts like encapsulation, polymorphism, abstraction etc. OODSL's like any other DSL's are much more expressive in their domain and much less comprehensive than general purpose object oriented programming languages like Java, C# etc. They are high-level languages, in the sense that they abstract from low-level implementation details. Some OODSL examples are Rails based on ruby programming language and JSP tags, Hibernate and Spring based on Java.

===Pros and Cons of OODSL===

Like any other DSL, employing OODSL in any application domain comes with its own set of advantages and disadvantages. Some of them are discussed below.

Pros of using OODSL for application development are:
* OODSL's are developed for a particular domain and hence can handle the problems related to that domain. They help express solution in the idiom and abstraction of problem domain and can be easily understood by experts in that domain.
* OODSL's are much simpler to use than general purpose language in their domain.
* They are concise, self documented and easy to understand and hence aid in easy development, maintainability and productivity

On the other side, cons of using OODSL are:
* Developing an OODSL require effort and cost.
* OODSL has limited scope within their domain.
* Using a newly developed OODSL requires users to understand its syntax.
* Using OODSL together with GPL constructs can be a difficult task.

===Types of OODSL===

OODSL can be of two types, internal and external :

'''Internal OODSL''' are the ones which use a host language and give them the feel of a particular language. Developing internal OODSL's is comparatively simple as they use grammar, parsers and tools of underlying language. But they are constrained by the underlying language. The challenge is to design these languages so as to have syntax within the confines of host language, yet these languages are simple, concise and fluent. An example of internal OODSL would be Rake (make equivalent) based on host, Ruby.Internal OODSL's are also referred as embedded languages or fluent interfaces.

'''External OODSL''', on the other hand is designed to be independent of any other language. Syntax, grammar, parsing of these languages is pretty much based on its author choice and gives both pain and pleasure of developing all from scratch. Example of external DSL would be Ant based on java.

==History of OODSLs==

History of DSL dates back than modeling approaches used now to develop them. First DSL's were developed many decades before. Worth mentioning is FORTRAN developed in late 1950s, an abbreviation of 'formula translation'. FORTRAN borrowed notation from mathematics so that programmers could write mathematical formulas directly. OODSL's started coming up after object oriented paradigm became prominent in 1970's and 1980's. OODSL's appeared mostly in late 1980's and 1990's. Now, OODSL's are used in web applications (e.g. Rails), computer games and environments (e.g. MOO programming) and as programming languages for music (e.g. Formes).

==OODSL Examples==

Some examples of OODSL prevalent today are:

* '''Kiddo''' - Kiddo is an internal OODSL based on ruby and used for building silverlight and WPF applications. Kiddo is based on ideals of "kid friendly" coding and has 5 core methods to get started with drawing.
* '''ColdFusion Markup Language''' - Commonly known as CFML, it is a scripting language used by Adobe's ColdFusion and other scripting engines. The CFML includes a set of tags that can be used in ColdFusion pages to interact with data sources and display output.
* '''MOO Programming Language''' - Moo programming language is used to support Mud Object Oriented or MOO server which is online virtual reality system to which multiple players can connect at the same time. Its domain is computer gaming environment.
* '''LPC''' - It is an object-oriented programming language derived from C and developed originally to facilitate MUD building. It was designed for game development.
* '''Formes''' - It is an object-oriented DSL used for music composition and synthesis. It is written in VLISP.
* '''R - R''' is a programming language for statistical computing and graphics. R has stronger object-oriented programming facilities than most statistical computing languages available.
* '''Kermeta''' - Kermeta is a meta-modeling language used to describe structure and the behavior of models. Kermeta can be used as the core language for a model oriented platform.

==Creating an OODSL==

OODSL can be created using many techniques and tools available in the market.

===Properties of any OODSL:===

Any OODSL should be fluent and in context.

* '''Fluency''': A fluent OODSL should have interfaces which are properly designed for human use and has high readability and natural flows within the language. An example explaining fluency is given below:

Looping through any collection in java was done traditionally as:

for(int i = 0; i < products.size(); i++)
{
String name = (String) products.get(i);
//...
//.....

}

However it can be done more fluently starting Java 5 as:

for(String product : products)
{
// ...
// ...
}

This flow comes naturally to any user and is easier to interpret.

* '''Context:''' OODSL should have a proper context on which they are built upon, after all, they are domain specific. Shared context makes OODSL easier to understand and work with and highly expressive. For example:

In java declaring and adding into the cart is done as:

java.util.ArrayList<String> cart = new java.util.ArrayList<String>();
cart.add("Milk");
cart.add("Juice");
cart.add("Apple");
System.out.print("My cart has %d items.", cart.size())

Same thing can be done in groovy as:
cart = []
cart.with {
add "Milk"
add "Juice"
add "Apple"
println "My cart has $size items."
}

Languages like Groovy and javascript are easier than java to build context such that convention is followed.

Examples taken from: http://www.javaworld.com/javaworld/jw-07-2008/jw-07-dsls-in-java-2.html?page=3

===Techniques/Tools used===

There are many OO languages like Smalltalk, ruby, groovy which easily lend themselves for creating internal OODSL. Ruby provides expressive, flexible syntax and has a dynamic nature which makes implementing a new OODSL easy without using any additional parser or compiler. Also, groovy easily supports creating fluent and in context OODSL's. On the other hand, C++ or Java syntax is not easy to attain the level of fluency required for a DSL, and so creating internal OODSLs using these languages is challenging. However, these languages offer good parsing libraries or capabilities and their support for creating external DSL’s is pretty strong.

Tools like visual studio and ANTLR aid in creating OODSL. Visual studio contains Domain-Specific Language Designer Wizard which provides many solution templates which can be used to create an OODSL. ANTLR, ANother Tool for Language Recognition, is another language tool that provides a framework for constructing recognizers, interpreters, compilers, and translators from grammatical descriptions. It supports many runtime libraries of ruby, C#, java etc which helps to create internal OODSL.

There are four basic approaches used for creating OODSL. These are:

* '''Instantiation:''' This approach is used mostly in Ruby projects, and not even recognized as a DSL. Using this approach, DSL is defined by defining methods of an object. Interaction is like any other OODSL, done by instantiating the object and calling the methods. The HTML creation DSL of Ruby’s CGI class uses this approach.
* '''Class macros:''' DSL is defined as methods on some ancestor class, and those methods are tweaked to modify the behavior of super-class and for subclasses of the particular class in question. These kinds of macros often create new methods. “has_many” in ActiveRecord is a good example of this type of approach.
* '''Top-level methods:''' There exists a configuration file, which is just like a Ruby script augmented with some DSL syntax. Any application using this type of DSL will load this configuration and uses DSL top level methods defined. When those methods are called in the configuration file, they modify some central (typically global) data, which then application uses to determine how it should execute. Rake is an example of this kind of DSL.
* '''Sandboxing:''' This approach is a special case of the more general instantiation technique. Using this technique, DSL is defined as methods of some object which is really just a “sandbox”. Interaction with the object’s methods modifies state of the sandbox which is queried by the application. This technique is similar to the top-level methods technique, with an exception that the DSL is restricted to the sandbox and there are no global methods involved. Needle uses this approach.

===Steps to create an OODSL===

Some of the steps which can be used to create an OODSL are:
* Identifying the goals to be accomplished.
* Reasoning why creating a new OODSL would be better than existing well crafted OODSL or an API.
* Defining ideal syntax before even coding.
* Referring to other examples of OODSL's, learning from their code and looking at the similarities.
* Refining syntax to get the best Return on Investment. If creating an internal OODSL, it is best to take advantage of host language’s compiler and adapting syntax slightly without creating a new full fledged parser or compiler.

==Example==

Below is an example of how an OODSL for creating SQL statements and querying database systems can be created. It is compared with how the same task is done in general purpose language.

Dynamic construction of an SQL statement in Java :

String sql = "select id, name " +
"from customers c, order o " +
"where " +
"c.since >= sysdate - 30 and " +
"sum(o.total) > " + significantTotal + " and " +
"c.id = o.customer_id and " +
"nvl(c.status, 'DROPPED') != 'DROPPED'";

The same can be written using OODSL as follows :

Table c = CUSTOMER.alias();
Table o = ORDER.alias();
Clause recent = c.SINCE.laterThan(daysEarlier(30));
Clause hasSignificantOrders = o.TOTAL.sum().isAbove(significantTotal);
Clause ordersMatch = c.ID.matches(o.CUSTOMER_ID);
Clause activeCustomer = c.STATUS.isNotNullOr("DROPPED");
String sql = CUSTOMERS.where(recent.and(hasSignificantOrders)
.and(ordersMatch)
.and(activeCustomer)
.select(c.ID, c.NAME)
.sql();

The SQL statement written in Java requires developer to be familiar with Oracle-SQL. This may not be the case for every application development in every domain. An OODSL like above can help in these cases. Creating basic classes representing different constructs of SQL query makes creating query easy. E.g. Class “Table” represents a basic API available through DSL and is used for representing tables which are to be queried. Creating different clauses using class “Clause” help filter data from the database.

The DSL code is less procedural, more declarative and object-oriented. It also has several advantages, major one being creating SQL statements without having familiarity of how to write SQL statements in database packages like Oracle, MySQL etc. The commonly used phrase, “nvl(c.status, 'DROPPED') != 'DROPPED'" in Oracle SQL cannot be easily understood by a non-SQL programmer. By replacing this phrase with the more easily understandable and language-like "isNotNullOr(“DROPPED”)," readability has been enhanced, and the system is protected from a later need to change the implementation to take advantage of facilities offered by another database vendor.

Note: The above example was explained in an easier manner. Further reading can be done from original source, http://www.infoq.com/articles/internal-dsls-java

==Summary==

This article gives some basic overview of OODSL features. OODSLs are mainly used in the domain of software engineering. The challenge using software engineering is to create flexible, reliable, scalable and maintainable systems. To achieve this, the software engineer must apply a wide variety of tools and techniques. One of these is to take advantage of the knowledge from underlying application domain, by means of a domain-specific language (DSL), which provides a notation that can be used to compose applications from a set of concepts tailored towards a specific application domain. Creating OODSL is a good option because OODSL provides benefits from both the worlds, DSL and OO concepts. An OODSL can be easily extended later, if required, which may not be the case with any other DSL. Hence it can be said that, OODSLs provide a certain level of abstraction of a domain, which can result in a greater control over or understanding of that domain. At the same time, they provide some good features of object oriented programming.

==References==
[1] Eelco Visser. WebDSL: A Case Study in Domain-Specific Language Engineering. Lecture Notes in Computer Science, 2008, Volume 5235/2008, 291-373.

[2] Martin Fowler. MF Bliki: DomainSpecificLanguage. Retrieved September 15, 2010, from, http://www.martinfowler.com/bliki/DomainSpecificLanguage.html

[3] Domain-specific Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/Domain-specific_language.

[4] Jeff Barczewski. Creating DSL’s in Ruby. Retrieved September 16, 2010 from http://inspiredhorizons.com/presentations/CreatingDSLsInRuby-060926.pdf

[5] Venkat Subramaniam, Creating DSL’s in java. Retrieved September 16, 2010 from http://www.java2s.com/Article/Java/Development/DSL.htm

[6] Jamis Buck. Writing Domain Specific Languages. Retrieved September 16, 2010 from http://weblog.jamisbuck.org/2006/4/20/writing-domain-specific-languages

[7] Alex Ruiz, Jeff Bay. An Approach to Internal Domain-Specific Languages in Java Retreved September 16, 2010 from http://www.infoq.com/articles/internal-dsls-java

[8] ColdFusion Markup Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/ColdFusion_Markup_Language

[9] MOO. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/MOO

[10] Freedom Dumlao. Introducing Kiddo: A Ruby DSL for building simple WPF and Silverlight applications. Retrieved September 15, 2010 from http://weblogs.asp.net/freedomdumlao/archive/2010/05/27/introducing-kiddo-a-ruby-dsl-for-building-simple-wpf-and-silverlight-applications.aspx

[11] LPC (programming language). Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/LPC_(programming_language)

[12] Kermeta Language Overview. Retrieved September 15, 2010 from https://www.kermeta.org/docs/KerMeta-MetaModel.pdf

CSC/ECE 517 Fall 2010/ch2 S23 SS

2010-09-21T18:00:44Z

Sumi2509: /* Steps to create an OODSL */

==Introduction==

Domain Specific Language (DSL) is any programming language which is designed to solve some specific problems and tasks in a specific domain. These languages are very focused and restricted to particular problem domain. This is in contrast to general programming languages (GPL) like java or C++ which can be used for software development in many application domains. Examples for DSL include:
* SQL for relational database
* Verilog for statistics
* Latex for typesetting

Object Oriented DSL's (OODSL) are DSL's based on object oriented programming paradigm. They employ the idea of classes and objects with concepts like encapsulation, polymorphism, abstraction etc. OODSL's like any other DSL's are much more expressive in their domain and much less comprehensive than general purpose object oriented programming languages like Java, C# etc. They are high-level languages, in the sense that they abstract from low-level implementation details. Some OODSL examples are Rails based on ruby programming language and JSP tags, Hibernate and Spring based on Java.

===Pros and Cons of OODSL===

Like any other DSL, employing OODSL in any application domain comes with its own set of advantages and disadvantages. Some of them are discussed below.

Pros of using OODSL for application development are:
* OODSL's are developed for a particular domain and hence can handle the problems related to that domain. They help express solution in the idiom and abstraction of problem domain and can be easily understood by experts in that domain.
* OODSL's are much simpler to use than general purpose language in their domain.
* They are concise, self documented and easy to understand and hence aid in easy development, maintainability and productivity

On the other side, cons of using OODSL are:
* Developing an OODSL require effort and cost.
* OODSL has limited scope within their domain.
* Using a newly developed OODSL requires users to understand its syntax.
* Using OODSL together with GPL constructs can be a difficult task.

===Types of OODSL===

OODSL can be of two types, internal and external :

'''Internal OODSL''' are the ones which use a host language and give them the feel of a particular language. Developing internal OODSL's is comparatively simple as they use grammar, parsers and tools of underlying language. But they are constrained by the underlying language. The challenge is to design these languages so as to have syntax within the confines of host language, yet these languages are simple, concise and fluent. An example of internal OODSL would be Rake (make equivalent) based on host, Ruby.Internal OODSL's are also referred as embedded languages or fluent interfaces.

'''External OODSL''', on the other hand is designed to be independent of any other language. Syntax, grammar, parsing of these languages is pretty much based on its author choice and gives both pain and pleasure of developing all from scratch. Example of external DSL would be Ant based on java.

==History of OODSLs==

History of DSL dates back than modeling approaches used now to develop them. First DSL's were developed many decades before. Worth mentioning is FORTRAN developed in late 1950s, an abbreviation of 'formula translation'. FORTRAN borrowed notation from mathematics so that programmers could write mathematical formulas directly. OODSL's started coming up after object oriented paradigm became prominent in 1970's and 1980's. OODSL's appeared mostly in late 1980's and 1990's. Now, OODSL's are used in web applications (e.g. Rails), computer games and environments (e.g. MOO programming) and as programming languages for music (e.g. Formes).

==OODSL Examples==

Some examples of OODSL prevalent today are:

* '''Kiddo''' - Kiddo is an internal OODSL based on ruby and used for building silverlight and WPF applications. Kiddo is based on ideals of "kid friendly" coding and has 5 core methods to get started with drawing.
* '''ColdFusion Markup Language''' - Commonly known as CFML, it is a scripting language used by Adobe's ColdFusion and other scripting engines. The CFML includes a set of tags that can be used in ColdFusion pages to interact with data sources and display output.
* '''MOO Programming Language''' - Moo programming language is used to support Mud Object Oriented or MOO server which is online virtual reality system to which multiple players can connect at the same time. Its domain is computer gaming environment.
* '''LPC''' - It is an object-oriented programming language derived from C and developed originally to facilitate MUD building. It was designed for game development.
* '''Formes''' - It is an object-oriented DSL used for music composition and synthesis. It is written in VLISP.
* '''R - R''' is a programming language for statistical computing and graphics. R has stronger object-oriented programming facilities than most statistical computing languages available.
* '''Kermeta''' - Kermeta is a meta-modeling language used to describe structure and the behavior of models. Kermeta can be used as the core language for a model oriented platform.

==Creating an OODSL==

OODSL can be created using many techniques and tools available in the market.

===Properties of any OODSL:===

Any OODSL should be fluent and in context.

* '''Fluency''': A fluent OODSL should have interfaces which are properly designed for human use and has high readability and natural flows within the language. An example explaining fluency is given below:

Looping through any collection in java was done traditionally as:

for(int i = 0; i < products.size(); i++)
{
String name = (String) products.get(i);
//...
//.....

}

However it can be done more fluently starting Java 5 as:

for(String product : products)
{
// ...
// ...
}

This flow comes naturally to any user and is easier to interpret.

* '''Context:''' OODSL should have a proper context on which they are built upon, after all, they are domain specific. Shared context makes OODSL easier to understand and work with and highly expressive. For example:

In java declaring and adding into the cart is done as:

java.util.ArrayList<String> cart = new java.util.ArrayList<String>();
cart.add("Milk");
cart.add("Juice");
cart.add("Apple");
System.out.print("My cart has %d items.", cart.size())

Same thing can be done in groovy as:
cart = []
cart.with {
add "Milk"
add "Juice"
add "Apple"
println "My cart has $size items."
}

Languages like Groovy and javascript are easier than java to build context such that convention is followed.

Examples taken from: http://www.javaworld.com/javaworld/jw-07-2008/jw-07-dsls-in-java-2.html?page=3

===Techniques/Tools used===

There are many OO languages like Smalltalk, ruby, groovy which easily lend themselves for creating internal OODSL. Ruby provides expressive, flexible syntax and has a dynamic nature which makes implementing a new OODSL easy without using any additional parser or compiler. Also, groovy easily supports creating fluent and in context OODSL's. On the other hand, C++ or Java syntax is not easy to attain the level of fluency required for a DSL, and so creating internal OODSLs using these languages is challenging. However, these languages offer good parsing libraries or capabilities and their support for creating external DSL’s is pretty strong.

Tools like visual studio and ANTLR aid in creating OODSL. Visual studio contains Domain-Specific Language Designer Wizard which provides many solution templates which can be used to create an OODSL. ANTLR, ANother Tool for Language Recognition, is another language tool that provides a framework for constructing recognizers, interpreters, compilers, and translators from grammatical descriptions. It supports many runtime libraries of ruby, C#, java etc which helps to create internal OODSL.

There are four basic approaches used for creating OODSL. These are:

* '''Instantiation:''' This approach is used mostly in Ruby projects, and not even recognized as a DSL. Using this approach, DSL is defined by defining methods of an object. Interaction is like any other OODSL, done by instantiating the object and calling the methods. The HTML creation DSL of Ruby’s CGI class uses this approach.
* '''Class macros:''' DSL is defined as methods on some ancestor class, and those methods are tweaked to modify the behavior of super-class and for subclasses of the particular class in question. These kinds of macros often create new methods. “has_many” in ActiveRecord is a good example of this type of approach.
* '''Top-level methods:''' There exists a configuration file, which is just like a Ruby script augmented with some DSL syntax. Any application using this type of DSL will load this configuration and uses DSL top level methods defined. When those methods are called in the configuration file, they modify some central (typically global) data, which then application uses to determine how it should execute. Rake is an example of this kind of DSL.
* '''Sandboxing:''' This approach is a special case of the more general instantiation technique. Using this technique, DSL is defined as methods of some object which is really just a “sandbox”. Interaction with the object’s methods modifies state of the sandbox which is queried by the application. This technique is similar to the top-level methods technique, with an exception that the DSL is restricted to the sandbox and there are no global methods involved. Needle uses this approach.

===Steps to create an OODSL===

Some of the steps which can be used to create an OODSL are:
* Identifying the goals to be accomplished.
* Reasoning why creating a new OODSL would be better than existing well crafted OODSL or an API.
* Defining ideal syntax before even coding.
* Referring to other examples of OODSL's, learning from their code and looking at the similarities.
* Refining syntax to get the best Return on Investment. If creating an internal OODSL, it is best to take advantage of host language’s compiler and adapting syntax slightly without creating a new full fledged parser or compiler.

==Example==

Below is an example of how an OODSL for creating SQL statements and querying database systems can be created. It is compared with how the same task is done in general purpose language.

Dynamic construction of an SQL statement in Java :

String sql = "select id, name " +
"from customers c, order o " +
"where " +
"c.since >= sysdate - 30 and " +
"sum(o.total) > " + significantTotal + " and " +
"c.id = o.customer_id and " +
"nvl(c.status, 'DROPPED') != 'DROPPED'";

The same can be written using OODSL as follows :

Table c = CUSTOMER.alias();
Table o = ORDER.alias();
Clause recent = c.SINCE.laterThan(daysEarlier(30));
Clause hasSignificantOrders = o.TOTAL.sum().isAbove(significantTotal);
Clause ordersMatch = c.ID.matches(o.CUSTOMER_ID);
Clause activeCustomer = c.STATUS.isNotNullOr("DROPPED");
String sql = CUSTOMERS.where(recent.and(hasSignificantOrders)
.and(ordersMatch)
.and(activeCustomer)
.select(c.ID, c.NAME)
.sql();

The SQL statement written in Java requires developer to be familiar with Oracle-SQL. This may not be the case for every application development in every domain. An OODSL like above can help in these cases. Creating basic classes representing different constructs of SQL query makes creating query easy. E.g. Class “Table” represents a basic API available through DSL and is used for representing tables which are to be queried. Creating different clauses using class “Clause” help filter data from the database.

The DSL code is less procedural, more declarative and object-oriented. It also has several advantages, major one being creating SQL statements without having familiarity of how to write SQL statements in database packages like Oracle, MySQL etc. The commonly used phrase, “nvl(c.status, 'DROPPED') != 'DROPPED'" in Oracle SQL cannot be easily understood by a non-SQL programmer. By replacing this phrase with the more easily understandable and language-like "isNotNullOr(“DROPPED”)," readability has been enhanced, and the system is protected from a later need to change the implementation to take advantage of facilities offered by another database vendor.

Note: The above example was explained in an easier manner. Further reading can be done from original source, http://www.infoq.com/articles/internal-dsls-java

==Summary==

This article gives some basic overview of OODSL features. OODSLs are mainly used in the domain of software engineering. The challenge using software engineering is to create flexible, reliable, scalable and maintainable systems. To achieve this, the software engineer must apply a wide variety of tools and techniques. One of these is to take advantage of the knowledge from underlying application domain, by means of a domain-specific language (DSL), which provides a notation that can be used to compose applications from a set of concepts tailored towards a specific application domain. Creating OODSL is a good option because OODSL provides benefits from both the worlds, DSL and OO concepts. An OODSL can be easily extended later, if required, which may not be the case with any other DSL. Hence it can be said that, OODSLs provide a certain level of abstraction of a domain, which can result in a greater control over or understanding of that domain. At the same time, they provide some good features of object oriented programming.

==References==
[1]Eelco Visser. WebDSL: A Case Study in Domain-Specific Language Engineering. Lecture Notes in Computer Science, 2008, Volume 5235/2008, 291-373.

[2]Martin Fowler. MF Bliki: DomainSpecificLanguage. Retrieved September 15, 2010, from, http://www.martinfowler.com/bliki/DomainSpecificLanguage.html

[3]Domain-specific Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/Domain-specific_language.

[4]Jeff Barczewski. Creating DSL’s in Ruby. Retrieved September 16, 2010 from http://inspiredhorizons.com/presentations/CreatingDSLsInRuby-060926.pdf

[5]Venkat Subramaniam, Creating DSL’s in java. Retrieved September 16, 2010 from http://www.java2s.com/Article/Java/Development/DSL.htm

[6]Jamis Buck. Writing Domain Specific Languages. Retrieved September 16, 2010 from http://weblog.jamisbuck.org/2006/4/20/writing-domain-specific-languages

[7]Alex Ruiz, Jeff Bay. An Approach to Internal Domain-Specific Languages in Java Retreved September 16, 2010 from http://www.infoq.com/articles/internal-dsls-java

[8]ColdFusion Markup Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/ColdFusion_Markup_Language

[9]MOO. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/MOO

[10]Freedom Dumlao. Introducing Kiddo: A Ruby DSL for building simple WPF and Silverlight applications. Retrieved September 15, 2010 from http://weblogs.asp.net/freedomdumlao/archive/2010/05/27/introducing-kiddo-a-ruby-dsl-for-building-simple-wpf-and-silverlight-applications.aspx

[11]LPC (programming language). Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/LPC_(programming_language)

[12]Kermeta Language Overview. Retrieved September 15, 2010 from https://www.kermeta.org/docs/KerMeta-MetaModel.pdf

CSC/ECE 517 Fall 2010/ch2 S23 SS

2010-09-21T18:00:27Z

Sumi2509: /* Techniques/Tools used */

==Introduction==

Domain Specific Language (DSL) is any programming language which is designed to solve some specific problems and tasks in a specific domain. These languages are very focused and restricted to particular problem domain. This is in contrast to general programming languages (GPL) like java or C++ which can be used for software development in many application domains. Examples for DSL include:
* SQL for relational database
* Verilog for statistics
* Latex for typesetting

Object Oriented DSL's (OODSL) are DSL's based on object oriented programming paradigm. They employ the idea of classes and objects with concepts like encapsulation, polymorphism, abstraction etc. OODSL's like any other DSL's are much more expressive in their domain and much less comprehensive than general purpose object oriented programming languages like Java, C# etc. They are high-level languages, in the sense that they abstract from low-level implementation details. Some OODSL examples are Rails based on ruby programming language and JSP tags, Hibernate and Spring based on Java.

===Pros and Cons of OODSL===

Like any other DSL, employing OODSL in any application domain comes with its own set of advantages and disadvantages. Some of them are discussed below.

Pros of using OODSL for application development are:
* OODSL's are developed for a particular domain and hence can handle the problems related to that domain. They help express solution in the idiom and abstraction of problem domain and can be easily understood by experts in that domain.
* OODSL's are much simpler to use than general purpose language in their domain.
* They are concise, self documented and easy to understand and hence aid in easy development, maintainability and productivity

On the other side, cons of using OODSL are:
* Developing an OODSL require effort and cost.
* OODSL has limited scope within their domain.
* Using a newly developed OODSL requires users to understand its syntax.
* Using OODSL together with GPL constructs can be a difficult task.

===Types of OODSL===

OODSL can be of two types, internal and external :

'''Internal OODSL''' are the ones which use a host language and give them the feel of a particular language. Developing internal OODSL's is comparatively simple as they use grammar, parsers and tools of underlying language. But they are constrained by the underlying language. The challenge is to design these languages so as to have syntax within the confines of host language, yet these languages are simple, concise and fluent. An example of internal OODSL would be Rake (make equivalent) based on host, Ruby.Internal OODSL's are also referred as embedded languages or fluent interfaces.

'''External OODSL''', on the other hand is designed to be independent of any other language. Syntax, grammar, parsing of these languages is pretty much based on its author choice and gives both pain and pleasure of developing all from scratch. Example of external DSL would be Ant based on java.

==History of OODSLs==

History of DSL dates back than modeling approaches used now to develop them. First DSL's were developed many decades before. Worth mentioning is FORTRAN developed in late 1950s, an abbreviation of 'formula translation'. FORTRAN borrowed notation from mathematics so that programmers could write mathematical formulas directly. OODSL's started coming up after object oriented paradigm became prominent in 1970's and 1980's. OODSL's appeared mostly in late 1980's and 1990's. Now, OODSL's are used in web applications (e.g. Rails), computer games and environments (e.g. MOO programming) and as programming languages for music (e.g. Formes).

==OODSL Examples==

Some examples of OODSL prevalent today are:

* '''Kiddo''' - Kiddo is an internal OODSL based on ruby and used for building silverlight and WPF applications. Kiddo is based on ideals of "kid friendly" coding and has 5 core methods to get started with drawing.
* '''ColdFusion Markup Language''' - Commonly known as CFML, it is a scripting language used by Adobe's ColdFusion and other scripting engines. The CFML includes a set of tags that can be used in ColdFusion pages to interact with data sources and display output.
* '''MOO Programming Language''' - Moo programming language is used to support Mud Object Oriented or MOO server which is online virtual reality system to which multiple players can connect at the same time. Its domain is computer gaming environment.
* '''LPC''' - It is an object-oriented programming language derived from C and developed originally to facilitate MUD building. It was designed for game development.
* '''Formes''' - It is an object-oriented DSL used for music composition and synthesis. It is written in VLISP.
* '''R - R''' is a programming language for statistical computing and graphics. R has stronger object-oriented programming facilities than most statistical computing languages available.
* '''Kermeta''' - Kermeta is a meta-modeling language used to describe structure and the behavior of models. Kermeta can be used as the core language for a model oriented platform.

==Creating an OODSL==

OODSL can be created using many techniques and tools available in the market.

===Properties of any OODSL:===

Any OODSL should be fluent and in context.

* '''Fluency''': A fluent OODSL should have interfaces which are properly designed for human use and has high readability and natural flows within the language. An example explaining fluency is given below:

Looping through any collection in java was done traditionally as:

for(int i = 0; i < products.size(); i++)
{
String name = (String) products.get(i);
//...
//.....

}

However it can be done more fluently starting Java 5 as:

for(String product : products)
{
// ...
// ...
}

This flow comes naturally to any user and is easier to interpret.

* '''Context:''' OODSL should have a proper context on which they are built upon, after all, they are domain specific. Shared context makes OODSL easier to understand and work with and highly expressive. For example:

In java declaring and adding into the cart is done as:

java.util.ArrayList<String> cart = new java.util.ArrayList<String>();
cart.add("Milk");
cart.add("Juice");
cart.add("Apple");
System.out.print("My cart has %d items.", cart.size())

Same thing can be done in groovy as:
cart = []
cart.with {
add "Milk"
add "Juice"
add "Apple"
println "My cart has $size items."
}

Languages like Groovy and javascript are easier than java to build context such that convention is followed.

Examples taken from: http://www.javaworld.com/javaworld/jw-07-2008/jw-07-dsls-in-java-2.html?page=3

===Techniques/Tools used===

There are many OO languages like Smalltalk, ruby, groovy which easily lend themselves for creating internal OODSL. Ruby provides expressive, flexible syntax and has a dynamic nature which makes implementing a new OODSL easy without using any additional parser or compiler. Also, groovy easily supports creating fluent and in context OODSL's. On the other hand, C++ or Java syntax is not easy to attain the level of fluency required for a DSL, and so creating internal OODSLs using these languages is challenging. However, these languages offer good parsing libraries or capabilities and their support for creating external DSL’s is pretty strong.

Tools like visual studio and ANTLR aid in creating OODSL. Visual studio contains Domain-Specific Language Designer Wizard which provides many solution templates which can be used to create an OODSL. ANTLR, ANother Tool for Language Recognition, is another language tool that provides a framework for constructing recognizers, interpreters, compilers, and translators from grammatical descriptions. It supports many runtime libraries of ruby, C#, java etc which helps to create internal OODSL.

There are four basic approaches used for creating OODSL. These are:

* '''Instantiation:''' This approach is used mostly in Ruby projects, and not even recognized as a DSL. Using this approach, DSL is defined by defining methods of an object. Interaction is like any other OODSL, done by instantiating the object and calling the methods. The HTML creation DSL of Ruby’s CGI class uses this approach.
* '''Class macros:''' DSL is defined as methods on some ancestor class, and those methods are tweaked to modify the behavior of super-class and for subclasses of the particular class in question. These kinds of macros often create new methods. “has_many” in ActiveRecord is a good example of this type of approach.
* '''Top-level methods:''' There exists a configuration file, which is just like a Ruby script augmented with some DSL syntax. Any application using this type of DSL will load this configuration and uses DSL top level methods defined. When those methods are called in the configuration file, they modify some central (typically global) data, which then application uses to determine how it should execute. Rake is an example of this kind of DSL.
* '''Sandboxing:''' This approach is a special case of the more general instantiation technique. Using this technique, DSL is defined as methods of some object which is really just a “sandbox”. Interaction with the object’s methods modifies state of the sandbox which is queried by the application. This technique is similar to the top-level methods technique, with an exception that the DSL is restricted to the sandbox and there are no global methods involved. Needle uses this approach.

==Steps to create an OODSL==

Some of the steps which can be used to create an OODSL are:
* Identifying the goals to be accomplished.
* Reasoning why creating a new OODSL would be better than existing well crafted OODSL or an API.
* Defining ideal syntax before even coding.
* Referring to other examples of OODSL's, learning from their code and looking at the similarities.
* Refining syntax to get the best Return on Investment. If creating an internal OODSL, it is best to take advantage of host language’s compiler and adapting syntax slightly without creating a new full fledged parser or compiler.

==Example==

Below is an example of how an OODSL for creating SQL statements and querying database systems can be created. It is compared with how the same task is done in general purpose language.

Dynamic construction of an SQL statement in Java :

String sql = "select id, name " +
"from customers c, order o " +
"where " +
"c.since >= sysdate - 30 and " +
"sum(o.total) > " + significantTotal + " and " +
"c.id = o.customer_id and " +
"nvl(c.status, 'DROPPED') != 'DROPPED'";

The same can be written using OODSL as follows :

Table c = CUSTOMER.alias();
Table o = ORDER.alias();
Clause recent = c.SINCE.laterThan(daysEarlier(30));
Clause hasSignificantOrders = o.TOTAL.sum().isAbove(significantTotal);
Clause ordersMatch = c.ID.matches(o.CUSTOMER_ID);
Clause activeCustomer = c.STATUS.isNotNullOr("DROPPED");
String sql = CUSTOMERS.where(recent.and(hasSignificantOrders)
.and(ordersMatch)
.and(activeCustomer)
.select(c.ID, c.NAME)
.sql();

The SQL statement written in Java requires developer to be familiar with Oracle-SQL. This may not be the case for every application development in every domain. An OODSL like above can help in these cases. Creating basic classes representing different constructs of SQL query makes creating query easy. E.g. Class “Table” represents a basic API available through DSL and is used for representing tables which are to be queried. Creating different clauses using class “Clause” help filter data from the database.

The DSL code is less procedural, more declarative and object-oriented. It also has several advantages, major one being creating SQL statements without having familiarity of how to write SQL statements in database packages like Oracle, MySQL etc. The commonly used phrase, “nvl(c.status, 'DROPPED') != 'DROPPED'" in Oracle SQL cannot be easily understood by a non-SQL programmer. By replacing this phrase with the more easily understandable and language-like "isNotNullOr(“DROPPED”)," readability has been enhanced, and the system is protected from a later need to change the implementation to take advantage of facilities offered by another database vendor.

Note: The above example was explained in an easier manner. Further reading can be done from original source, http://www.infoq.com/articles/internal-dsls-java

==Summary==

This article gives some basic overview of OODSL features. OODSLs are mainly used in the domain of software engineering. The challenge using software engineering is to create flexible, reliable, scalable and maintainable systems. To achieve this, the software engineer must apply a wide variety of tools and techniques. One of these is to take advantage of the knowledge from underlying application domain, by means of a domain-specific language (DSL), which provides a notation that can be used to compose applications from a set of concepts tailored towards a specific application domain. Creating OODSL is a good option because OODSL provides benefits from both the worlds, DSL and OO concepts. An OODSL can be easily extended later, if required, which may not be the case with any other DSL. Hence it can be said that, OODSLs provide a certain level of abstraction of a domain, which can result in a greater control over or understanding of that domain. At the same time, they provide some good features of object oriented programming.

==References==
[1]Eelco Visser. WebDSL: A Case Study in Domain-Specific Language Engineering. Lecture Notes in Computer Science, 2008, Volume 5235/2008, 291-373.

[2]Martin Fowler. MF Bliki: DomainSpecificLanguage. Retrieved September 15, 2010, from, http://www.martinfowler.com/bliki/DomainSpecificLanguage.html

[3]Domain-specific Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/Domain-specific_language.

[4]Jeff Barczewski. Creating DSL’s in Ruby. Retrieved September 16, 2010 from http://inspiredhorizons.com/presentations/CreatingDSLsInRuby-060926.pdf

[5]Venkat Subramaniam, Creating DSL’s in java. Retrieved September 16, 2010 from http://www.java2s.com/Article/Java/Development/DSL.htm

[6]Jamis Buck. Writing Domain Specific Languages. Retrieved September 16, 2010 from http://weblog.jamisbuck.org/2006/4/20/writing-domain-specific-languages

[7]Alex Ruiz, Jeff Bay. An Approach to Internal Domain-Specific Languages in Java Retreved September 16, 2010 from http://www.infoq.com/articles/internal-dsls-java

[8]ColdFusion Markup Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/ColdFusion_Markup_Language

[9]MOO. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/MOO

[10]Freedom Dumlao. Introducing Kiddo: A Ruby DSL for building simple WPF and Silverlight applications. Retrieved September 15, 2010 from http://weblogs.asp.net/freedomdumlao/archive/2010/05/27/introducing-kiddo-a-ruby-dsl-for-building-simple-wpf-and-silverlight-applications.aspx

[11]LPC (programming language). Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/LPC_(programming_language)

[12]Kermeta Language Overview. Retrieved September 15, 2010 from https://www.kermeta.org/docs/KerMeta-MetaModel.pdf

CSC/ECE 517 Fall 2010/ch2 S23 SS

2010-09-21T17:59:33Z

Sumi2509: /* Creating an OODSL */

==Introduction==

Domain Specific Language (DSL) is any programming language which is designed to solve some specific problems and tasks in a specific domain. These languages are very focused and restricted to particular problem domain. This is in contrast to general programming languages (GPL) like java or C++ which can be used for software development in many application domains. Examples for DSL include:
* SQL for relational database
* Verilog for statistics
* Latex for typesetting

Object Oriented DSL's (OODSL) are DSL's based on object oriented programming paradigm. They employ the idea of classes and objects with concepts like encapsulation, polymorphism, abstraction etc. OODSL's like any other DSL's are much more expressive in their domain and much less comprehensive than general purpose object oriented programming languages like Java, C# etc. They are high-level languages, in the sense that they abstract from low-level implementation details. Some OODSL examples are Rails based on ruby programming language and JSP tags, Hibernate and Spring based on Java.

===Pros and Cons of OODSL===

Like any other DSL, employing OODSL in any application domain comes with its own set of advantages and disadvantages. Some of them are discussed below.

Pros of using OODSL for application development are:
* OODSL's are developed for a particular domain and hence can handle the problems related to that domain. They help express solution in the idiom and abstraction of problem domain and can be easily understood by experts in that domain.
* OODSL's are much simpler to use than general purpose language in their domain.
* They are concise, self documented and easy to understand and hence aid in easy development, maintainability and productivity

On the other side, cons of using OODSL are:
* Developing an OODSL require effort and cost.
* OODSL has limited scope within their domain.
* Using a newly developed OODSL requires users to understand its syntax.
* Using OODSL together with GPL constructs can be a difficult task.

===Types of OODSL===

OODSL can be of two types, internal and external :

'''Internal OODSL''' are the ones which use a host language and give them the feel of a particular language. Developing internal OODSL's is comparatively simple as they use grammar, parsers and tools of underlying language. But they are constrained by the underlying language. The challenge is to design these languages so as to have syntax within the confines of host language, yet these languages are simple, concise and fluent. An example of internal OODSL would be Rake (make equivalent) based on host, Ruby.Internal OODSL's are also referred as embedded languages or fluent interfaces.

'''External OODSL''', on the other hand is designed to be independent of any other language. Syntax, grammar, parsing of these languages is pretty much based on its author choice and gives both pain and pleasure of developing all from scratch. Example of external DSL would be Ant based on java.

==History of OODSLs==

History of DSL dates back than modeling approaches used now to develop them. First DSL's were developed many decades before. Worth mentioning is FORTRAN developed in late 1950s, an abbreviation of 'formula translation'. FORTRAN borrowed notation from mathematics so that programmers could write mathematical formulas directly. OODSL's started coming up after object oriented paradigm became prominent in 1970's and 1980's. OODSL's appeared mostly in late 1980's and 1990's. Now, OODSL's are used in web applications (e.g. Rails), computer games and environments (e.g. MOO programming) and as programming languages for music (e.g. Formes).

==OODSL Examples==

Some examples of OODSL prevalent today are:

* '''Kiddo''' - Kiddo is an internal OODSL based on ruby and used for building silverlight and WPF applications. Kiddo is based on ideals of "kid friendly" coding and has 5 core methods to get started with drawing.
* '''ColdFusion Markup Language''' - Commonly known as CFML, it is a scripting language used by Adobe's ColdFusion and other scripting engines. The CFML includes a set of tags that can be used in ColdFusion pages to interact with data sources and display output.
* '''MOO Programming Language''' - Moo programming language is used to support Mud Object Oriented or MOO server which is online virtual reality system to which multiple players can connect at the same time. Its domain is computer gaming environment.
* '''LPC''' - It is an object-oriented programming language derived from C and developed originally to facilitate MUD building. It was designed for game development.
* '''Formes''' - It is an object-oriented DSL used for music composition and synthesis. It is written in VLISP.
* '''R - R''' is a programming language for statistical computing and graphics. R has stronger object-oriented programming facilities than most statistical computing languages available.
* '''Kermeta''' - Kermeta is a meta-modeling language used to describe structure and the behavior of models. Kermeta can be used as the core language for a model oriented platform.

==Creating an OODSL==

OODSL can be created using many techniques and tools available in the market.

===Properties of any OODSL:===

Any OODSL should be fluent and in context.

* '''Fluency''': A fluent OODSL should have interfaces which are properly designed for human use and has high readability and natural flows within the language. An example explaining fluency is given below:

Looping through any collection in java was done traditionally as:

for(int i = 0; i < products.size(); i++)
{
String name = (String) products.get(i);
//...
//.....

}

However it can be done more fluently starting Java 5 as:

for(String product : products)
{
// ...
// ...
}

This flow comes naturally to any user and is easier to interpret.

* '''Context:''' OODSL should have a proper context on which they are built upon, after all, they are domain specific. Shared context makes OODSL easier to understand and work with and highly expressive. For example:

In java declaring and adding into the cart is done as:

java.util.ArrayList<String> cart = new java.util.ArrayList<String>();
cart.add("Milk");
cart.add("Juice");
cart.add("Apple");
System.out.print("My cart has %d items.", cart.size())

Same thing can be done in groovy as:
cart = []
cart.with {
add "Milk"
add "Juice"
add "Apple"
println "My cart has $size items."
}

Languages like Groovy and javascript are easier than java to build context such that convention is followed.

Examples taken from: http://www.javaworld.com/javaworld/jw-07-2008/jw-07-dsls-in-java-2.html?page=3

==Techniques/Tools used==

There are many OO languages like Smalltalk, ruby, groovy which easily lend themselves for creating internal OODSL. Ruby provides expressive, flexible syntax and has a dynamic nature which makes implementing a new OODSL easy without using any additional parser or compiler. Also, groovy easily supports creating fluent and in context OODSL's. On the other hand, C++ or Java syntax is not easy to attain the level of fluency required for a DSL, and so creating internal OODSLs using these languages is challenging. However, these languages offer good parsing libraries or capabilities and their support for creating external DSL’s is pretty strong.

Tools like visual studio and ANTLR aid in creating OODSL. Visual studio contains Domain-Specific Language Designer Wizard which provides many solution templates which can be used to create an OODSL. ANTLR, ANother Tool for Language Recognition, is another language tool that provides a framework for constructing recognizers, interpreters, compilers, and translators from grammatical descriptions. It supports many runtime libraries of ruby, C#, java etc which helps to create internal OODSL.

There are four basic approaches used for creating OODSL. These are:

* '''Instantiation:''' This approach is used mostly in Ruby projects, and not even recognized as a DSL. Using this approach, DSL is defined by defining methods of an object. Interaction is like any other OODSL, done by instantiating the object and calling the methods. The HTML creation DSL of Ruby’s CGI class uses this approach.
* '''Class macros:''' DSL is defined as methods on some ancestor class, and those methods are tweaked to modify the behavior of super-class and for subclasses of the particular class in question. These kinds of macros often create new methods. “has_many” in ActiveRecord is a good example of this type of approach.
* '''Top-level methods:''' There exists a configuration file, which is just like a Ruby script augmented with some DSL syntax. Any application using this type of DSL will load this configuration and uses DSL top level methods defined. When those methods are called in the configuration file, they modify some central (typically global) data, which then application uses to determine how it should execute. Rake is an example of this kind of DSL.
* '''Sandboxing:''' This approach is a special case of the more general instantiation technique. Using this technique, DSL is defined as methods of some object which is really just a “sandbox”. Interaction with the object’s methods modifies state of the sandbox which is queried by the application. This technique is similar to the top-level methods technique, with an exception that the DSL is restricted to the sandbox and there are no global methods involved. Needle uses this approach.

==Steps to create an OODSL==

Some of the steps which can be used to create an OODSL are:
* Identifying the goals to be accomplished.
* Reasoning why creating a new OODSL would be better than existing well crafted OODSL or an API.
* Defining ideal syntax before even coding.
* Referring to other examples of OODSL's, learning from their code and looking at the similarities.
* Refining syntax to get the best Return on Investment. If creating an internal OODSL, it is best to take advantage of host language’s compiler and adapting syntax slightly without creating a new full fledged parser or compiler.

==Example==

Below is an example of how an OODSL for creating SQL statements and querying database systems can be created. It is compared with how the same task is done in general purpose language.

Dynamic construction of an SQL statement in Java :

String sql = "select id, name " +
"from customers c, order o " +
"where " +
"c.since >= sysdate - 30 and " +
"sum(o.total) > " + significantTotal + " and " +
"c.id = o.customer_id and " +
"nvl(c.status, 'DROPPED') != 'DROPPED'";

The same can be written using OODSL as follows :

Table c = CUSTOMER.alias();
Table o = ORDER.alias();
Clause recent = c.SINCE.laterThan(daysEarlier(30));
Clause hasSignificantOrders = o.TOTAL.sum().isAbove(significantTotal);
Clause ordersMatch = c.ID.matches(o.CUSTOMER_ID);
Clause activeCustomer = c.STATUS.isNotNullOr("DROPPED");
String sql = CUSTOMERS.where(recent.and(hasSignificantOrders)
.and(ordersMatch)
.and(activeCustomer)
.select(c.ID, c.NAME)
.sql();

The SQL statement written in Java requires developer to be familiar with Oracle-SQL. This may not be the case for every application development in every domain. An OODSL like above can help in these cases. Creating basic classes representing different constructs of SQL query makes creating query easy. E.g. Class “Table” represents a basic API available through DSL and is used for representing tables which are to be queried. Creating different clauses using class “Clause” help filter data from the database.

The DSL code is less procedural, more declarative and object-oriented. It also has several advantages, major one being creating SQL statements without having familiarity of how to write SQL statements in database packages like Oracle, MySQL etc. The commonly used phrase, “nvl(c.status, 'DROPPED') != 'DROPPED'" in Oracle SQL cannot be easily understood by a non-SQL programmer. By replacing this phrase with the more easily understandable and language-like "isNotNullOr(“DROPPED”)," readability has been enhanced, and the system is protected from a later need to change the implementation to take advantage of facilities offered by another database vendor.

Note: The above example was explained in an easier manner. Further reading can be done from original source, http://www.infoq.com/articles/internal-dsls-java

==Summary==

This article gives some basic overview of OODSL features. OODSLs are mainly used in the domain of software engineering. The challenge using software engineering is to create flexible, reliable, scalable and maintainable systems. To achieve this, the software engineer must apply a wide variety of tools and techniques. One of these is to take advantage of the knowledge from underlying application domain, by means of a domain-specific language (DSL), which provides a notation that can be used to compose applications from a set of concepts tailored towards a specific application domain. Creating OODSL is a good option because OODSL provides benefits from both the worlds, DSL and OO concepts. An OODSL can be easily extended later, if required, which may not be the case with any other DSL. Hence it can be said that, OODSLs provide a certain level of abstraction of a domain, which can result in a greater control over or understanding of that domain. At the same time, they provide some good features of object oriented programming.

==References==
[1]Eelco Visser. WebDSL: A Case Study in Domain-Specific Language Engineering. Lecture Notes in Computer Science, 2008, Volume 5235/2008, 291-373.

[2]Martin Fowler. MF Bliki: DomainSpecificLanguage. Retrieved September 15, 2010, from, http://www.martinfowler.com/bliki/DomainSpecificLanguage.html

[3]Domain-specific Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/Domain-specific_language.

[4]Jeff Barczewski. Creating DSL’s in Ruby. Retrieved September 16, 2010 from http://inspiredhorizons.com/presentations/CreatingDSLsInRuby-060926.pdf

[5]Venkat Subramaniam, Creating DSL’s in java. Retrieved September 16, 2010 from http://www.java2s.com/Article/Java/Development/DSL.htm

[6]Jamis Buck. Writing Domain Specific Languages. Retrieved September 16, 2010 from http://weblog.jamisbuck.org/2006/4/20/writing-domain-specific-languages

[7]Alex Ruiz, Jeff Bay. An Approach to Internal Domain-Specific Languages in Java Retreved September 16, 2010 from http://www.infoq.com/articles/internal-dsls-java

[8]ColdFusion Markup Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/ColdFusion_Markup_Language

[9]MOO. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/MOO

[10]Freedom Dumlao. Introducing Kiddo: A Ruby DSL for building simple WPF and Silverlight applications. Retrieved September 15, 2010 from http://weblogs.asp.net/freedomdumlao/archive/2010/05/27/introducing-kiddo-a-ruby-dsl-for-building-simple-wpf-and-silverlight-applications.aspx

[11]LPC (programming language). Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/LPC_(programming_language)

[12]Kermeta Language Overview. Retrieved September 15, 2010 from https://www.kermeta.org/docs/KerMeta-MetaModel.pdf