Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T19:17:48Z

Aamarna2:

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle] object-oriented software development. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]SOLID object oriented principles.
<ol>
<li> SRP- The Single Responsibility Principle - A class should have one, and only one, reason to change.</li>
<li> OCP- The Open Closed Principle - You should be able to extend a classes behavior, without modifying it.</li>
<li> LSP- The Liskov Substitution Principle - Derived classes must be substitutable for their base classes.</li>
<li> DIP- The Dependency Inversion Principle- Depend on abstractions, not on concretions.</li>
<li> ISP- The Interface Segregation Principle- Make fine grained interfaces that are client specific.</li>
</ol>

In this chapter we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>
<li>CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DON'T USE.</li>
</ul>
==Implications of the emphasis==
<ol>
<li>This principle provides guidelines to write our interfaces. When we write our interfaces we should take care to add only methods that should be there. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well.
</li>
<li>The interfaces that are designed should not be fat, i.e the interface should not have too many methods which often do not get used together.
The idea here is to avoid loading all the methods into a single interface, instead segregate the methods in the interface such that all the methods that contribute towards offering a single type of service (or single type of clients) are grouped under one single interface. Thereby dealing with a bulky interface that might be difficult to manage is avoided.
</li>

<li>
The interface should be specific. The methods in the interface should be the ones that contribute towards offering only a specific type of service. For example, if there is an interface that offers methods that provide mathematical services to its clients, then the same interface should not contain methods that accomplish totally different types of tasks say, like a database functionality implementation.
The main reason behind such interfaces being discouraged is that if a class decides to (or has to) implement that interface, then, it has to provide an implementation even for those methods that it doesn’t intend to use. Even though such implementations may be empty methods, it is not convenient and also distorts the readability of the code.

</li>
</ol>
==Results of following ISP==
Designing software by adopting ISP will yield many simple interfaces that are more specific in nature which in turn will make the classes more cohesive.
==How ISP can be implemented in the design==
===Segregation through Delegation===
The object form of the ADAPTER Pattern can be used to delegate the responsibility of implementing the thin interface to the class that is the client of the interface.
===Segregation through multiple inheritance===
The methods that are to be included into the interfaces are grouped into interfaces such that all the methods in the interface are directed towards accomplishing a certain type of service. When a class has to use the methods in the interface, it has to implement the interface. When the class is required to implement methods from many interfaces, the class will have to inherit multiple light interfaces and also implement the methods in the interfaces.

==Example==
Consider an example of Course registration system which allows students to enroll in courses, similar to the one we have at NCSU.
Let us assume we have a student base class which other specialized student classes inherit from.

A full time student is allowed to register for a class. He can also choose to audit a particular class.

Lets say we have an interface called IEnroll.
The IEnroll interface exposes two methods viz. registerClass() which should allow a student to register himself for a class, and auditClass() which allows a student to audit a class he has registered for.
The FullStudent class is used to represent full time students. It extends the Student class and implements this IEnroll interface.
 
 
 
[[Image:Figure 1Class diagram for FullStudent (violates ISP).png]]
 
 
 
interface IEnroll {
public void registerClass();
public void auditClass();
}

class FullStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

Now lets suppose, NCSU decided not to allow part time students to audit a class once they have registered.
The PartStudent class represents the part time students. It extends the Student class.
Now PartStudent class can either implement IEnroll to provide the registration facility. But in that case, PartStudent is forced to implement the auditClass method.
 
 
 
[[Image:Figure 2Class diagram for PartStudent (violates ISP).png ]]
 
 
 
class PartStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//do nothing since we didn't want this method in the first place!
}
}

The other option is to define a new interface with just registClass method and use it in PartStudent class. But this defeats the purpose of having a common interface.

This is a good example of how our interface has become 'Fat' or 'Polluted'. It is exposing 2 different methods which its clients are forced to honor. This violates the ISP.

Lets see how we can correct this.

We separate out the 2 functions into different interfaces now,

interface IRegisterClass {
public void registerClass();
}
interface IAuditClass {
public auditClass();
}

This allows the FullStudent and PartStudent to be defined as following:
 
 
 
[[Image:Figure 3Class diagram for FullStudent (conforms to ISP).png]]
 
 
 

class FullStudent extends Student implements IRegisterClass, IAuditClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}
 
 
 
[[Image:Figure 4Class diagram for PartStudent (conforms to ISP).png]]
 
 
 
class PartStudent extends Student implements IRegisterClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
}
This gives a clean and correct way in which the PartStudent class is not forced to depend on an interface it does not want.

==Conclusion==
#Fat Interfaces are the interfaces that are not specific to a single client. Fat interfaces lead to unintended couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, through multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that resolve the unwanted coupling between clients. Thus maintaining loose coupling and high cohesion, which is an essential attribute of good software design.
#Interfaces containing methods that are not specific to a particular type of service are called polluted or fat interfaces. These must be avoided.

==See Also==
#[http://www.oodesign.com/design-principles.html Design principles]
#[http://java.sys-con.com/node/84633/print Three Sources of a Solid Object-Oriented Design]
#[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Principles of OOD]
#[http://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes episode on SOLID]

==External References==
<ol>
<li> [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]</li>
<li> [http://www.objectmentor.com Design Principles and Design Patterns, Robert C Martin]</li>
<li> [http://ontwik.com/ruby/sandi-metz-solid-object-oriented-design/ 2009 Gotham Ruby Conference, presentation on SOLID Object Oriented Design by Sandi Metz, Duke University.]</li>
<ol>

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T19:13:08Z

Aamarna2:

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle] object-oriented software development. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]SOLID object oriented principles.
<table>
<tr><td>SRP</td><td>The Single Responsibility Principle<td></td><td>A class should have one, and only one, reason to change.</td><tr>
<tr><td>OCP</td><td>The Open Closed Principle</td><td>You should be able to extend a classes behavior, without modifying it.</td><tr>
<tr><td>LSP</td><td>The Liskov Substitution Principle</td><td>Derived classes must be substitutable for their base classes.</td><tr>
<tr><td>DIP</td><td>The Dependency Inversion Principle</td><td>Depend on abstractions, not on concretions.</td><tr>
<tr><td>ISP</td><td>The Interface Segregation Principle</td><td>Make fine grained interfaces that are client specific.</td><tr>
</table>

In this chapter we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>
<li>CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DON'T USE.</li>
</ul>
==Implications of the emphasis==
<ol>
<li>This principle provides guidelines to write our interfaces. When we write our interfaces we should take care to add only methods that should be there. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well.
</li>
<li>The interfaces that are designed should not be fat, i.e the interface should not have too many methods which often do not get used together.
The idea here is to avoid loading all the methods into a single interface, instead segregate the methods in the interface such that all the methods that contribute towards offering a single type of service (or single type of clients) are grouped under one single interface. Thereby dealing with a bulky interface that might be difficult to manage is avoided.
</li>

<li>
The interface should be specific. The methods in the interface should be the ones that contribute towards offering only a specific type of service. For example, if there is an interface that offers methods that provide mathematical services to its clients, then the same interface should not contain methods that accomplish totally different types of tasks say, like a database functionality implementation.
The main reason behind such interfaces being discouraged is that if a class decides to (or has to) implement that interface, then, it has to provide an implementation even for those methods that it doesn’t intend to use. Even though such implementations may be empty methods, it is not convenient and also distorts the readability of the code.

</li>
</ol>
==Results of following ISP==
Designing software by adopting ISP will yield many simple interfaces that are more specific in nature which in turn will make the classes more cohesive.
==How ISP can be implemented in the design==
===Segregation through Delegation===
The object form of the ADAPTER Pattern can be used to delegate the responsibility of implementing the thin interface to the class that is the client of the interface.
===Segregation through multiple inheritance===
The methods that are to be included into the interfaces are grouped into interfaces such that all the methods in the interface are directed towards accomplishing a certain type of service. When a class has to use the methods in the interface, it has to implement the interface. When the class is required to implement methods from many interfaces, the class will have to inherit multiple light interfaces and also implement the methods in the interfaces.

==Example==
Consider an example of Course registration system which allows students to enroll in courses, similar to the one we have at NCSU.
Let us assume we have a student base class which other specialized student classes inherit from.

A full time student is allowed to register for a class. He can also choose to audit a particular class.

Lets say we have an interface called IEnroll.
The IEnroll interface exposes two methods viz. registerClass() which should allow a student to register himself for a class, and auditClass() which allows a student to audit a class he has registered for.
The FullStudent class is used to represent full time students. It extends the Student class and implements this IEnroll interface.
 
 
 
[[Image:Figure 1Class diagram for FullStudent (violates ISP).png]]
 
 
 
interface IEnroll {
public void registerClass();
public void auditClass();
}

class FullStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

Now lets suppose, NCSU decided not to allow part time students to audit a class once they have registered.
The PartStudent class represents the part time students. It extends the Student class.
Now PartStudent class can either implement IEnroll to provide the registration facility. But in that case, PartStudent is forced to implement the auditClass method.
 
 
 
[[Image:Figure 2Class diagram for PartStudent (violates ISP).png ]]
 
 
 
class PartStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//do nothing since we didn't want this method in the first place!
}
}

The other option is to define a new interface with just registClass method and use it in PartStudent class. But this defeats the purpose of having a common interface.

This is a good example of how our interface has become 'Fat' or 'Polluted'. It is exposing 2 different methods which its clients are forced to honor. This violates the ISP.

Lets see how we can correct this.

We separate out the 2 functions into different interfaces now,

interface IRegisterClass {
public void registerClass();
}
interface IAuditClass {
public auditClass();
}

This allows the FullStudent and PartStudent to be defined as following:
 
 
 
[[Image:Figure 3Class diagram for FullStudent (conforms to ISP).png]]
 
 
 

class FullStudent extends Student implements IRegisterClass, IAuditClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}
 
 
 
[[Image:Figure 4Class diagram for PartStudent (conforms to ISP).png]]
 
 
 
class PartStudent extends Student implements IRegisterClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
}
This gives a clean and correct way in which the PartStudent class is not forced to depend on an interface it does not want.

==Conclusion==
#Fat Interfaces are the interfaces that are not specific to a single client. Fat interfaces lead to unintended couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, through multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that resolve the unwanted coupling between clients. Thus maintaining loose coupling and high cohesion, which is an essential attribute of good software design.
#Interfaces containing methods that are not specific to a particular type of service are called polluted or fat interfaces. These must be avoided.

==See Also==
#[http://www.oodesign.com/design-principles.html Design principles]
#[http://java.sys-con.com/node/84633/print Three Sources of a Solid Object-Oriented Design]
#[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Principles of OOD]
#[http://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes episode on SOLID]

==External References==
<ol>
<li> [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]</li>
<li> [http://www.objectmentor.com Design Principles and Design Patterns, Robert C Martin]</li>
<li> [http://ontwik.com/ruby/sandi-metz-solid-object-oriented-design/ 2009 Gotham Ruby Conference, presentation on SOLID Object Oriented Design by Sandi Metz, Duke University.]</li>
<ol>

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T19:04:04Z

Aamarna2:

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle] object-oriented software development. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]SOLID object oriented principles. In this article we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>
<li>CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DON'T USE.</li>
</ul>
==Implications of the emphasis==
<ol>
<li>This principle provides guidelines to write our interfaces. When we write our interfaces we should take care to add only methods that should be there. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well.
</li>
<li>The interfaces that are designed should not be fat, i.e the interface should not have too many methods which often do not get used together.
The idea here is to avoid loading all the methods into a single interface, instead segregate the methods in the interface such that all the methods that contribute towards offering a single type of service (or single type of clients) are grouped under one single interface. Thereby dealing with a bulky interface that might be difficult to manage is avoided.
</li>

<li>
The interface should be specific. The methods in the interface should be the ones that contribute towards offering only a specific type of service. For example, if there is an interface that offers methods that provide mathematical services to its clients, then the same interface should not contain methods that accomplish totally different types of tasks say, like a database functionality implementation.
The main reason behind such interfaces being discouraged is that if a class decides to (or has to) implement that interface, then, it has to provide an implementation even for those methods that it doesn’t intend to use. Even though such implementations may be empty methods, it is not convenient and also distorts the readability of the code.

</li>
</ol>
==Results of following ISP==
Designing software by adopting ISP will yield many simple interfaces that are more specific in nature which in turn will make the classes more cohesive.
==How ISP can be implemented in the design==
===Segregation through Delegation===
The object form of the ADAPTER Pattern can be used to delegate the responsibility of implementing the thin interface to the class that is the client of the interface.
===Segregation through multiple inheritance===
The methods that are to be included into the interfaces are grouped into interfaces such that all the methods in the interface are directed towards accomplishing a certain type of service. When a class has to use the methods in the interface, it has to implement the interface. When the class is required to implement methods from many interfaces, the class will have to inherit multiple light interfaces and also implement the methods in the interfaces.

==Example==
Consider an example of Course registration system which allows students to enroll in courses, similar to the one we have at NCSU.
Let us assume we have a student base class which other specialized student classes inherit from.

A full time student is allowed to register for a class. He can also choose to audit a particular class.

Lets say we have an interface called IEnroll.
The IEnroll interface exposes two methods viz. registerClass() which should allow a student to register himself for a class, and auditClass() which allows a student to audit a class he has registered for.
The FullStudent class is used to represent full time students. It extends the Student class and implements this IEnroll interface.
 
 
 
[[Image:Figure 1Class diagram for FullStudent (violates ISP).png]]
 
 
 
interface IEnroll {
public void registerClass();
public void auditClass();
}

class FullStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

Now lets suppose, NCSU decided not to allow part time students to audit a class once they have registered.
The PartStudent class represents the part time students. It extends the Student class.
Now PartStudent class can either implement IEnroll to provide the registration facility. But in that case, PartStudent is forced to implement the auditClass method.
 
 
 
[[Image:Figure 2Class diagram for PartStudent (violates ISP).png ]]
 
 
 
class PartStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//do nothing since we didn't want this method in the first place!
}
}

The other option is to define a new interface with just registClass method and use it in PartStudent class. But this defeats the purpose of having a common interface.

This is a good example of how our interface has become 'Fat' or 'Polluted'. It is exposing 2 different methods which its clients are forced to honor. This violates the ISP.

Lets see how we can correct this.

We separate out the 2 functions into different interfaces now,

interface IRegisterClass {
public void registerClass();
}
interface IAuditClass {
public auditClass();
}

This allows the FullStudent and PartStudent to be defined as following:
 
 
 
[[Image:Figure 3Class diagram for FullStudent (conforms to ISP).png]]
 
 
 

class FullStudent extends Student implements IRegisterClass, IAuditClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}
 
 
 
[[Image:Figure 4Class diagram for PartStudent (conforms to ISP).png]]
 
 
 
class PartStudent extends Student implements IRegisterClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
}
This gives a clean and correct way in which the PartStudent class is not forced to depend on an interface it does not want.

==Conclusion==
#Fat Interfaces are the interfaces that are not specific to a single client. Fat interfaces lead to unintended couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, through multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that resolve the unwanted coupling between clients. Thus maintaining loose coupling and high cohesion, which is an essential attribute of good software design.
#Interfaces containing methods that are not specific to a particular type of service are called polluted or fat interfaces. These must be avoided.

==See Also==
#[http://www.oodesign.com/design-principles.html Design principles]
#[http://java.sys-con.com/node/84633/print Three Sources of a Solid Object-Oriented Design]
#[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Principles of OOD]
#[http://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes episode on SOLID]

==External References==
<ol>
<li> [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]</li>
<li> [http://www.objectmentor.com Design Principles and Design Patterns, Robert C Martin]</li>
<li> [http://ontwik.com/ruby/sandi-metz-solid-object-oriented-design/ 2009 Gotham Ruby Conference, presentation on SOLID Object Oriented Design by Sandi Metz, Duke University.]</li>
<ol>

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T19:03:48Z

Aamarna2:

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle] object-oriented software development. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]SOLID object oriented principles. In this article we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>
<li>b. CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DON'T USE.</li>
</ul>
==Implications of the emphasis==
<ol>
<li>This principle provides guidelines to write our interfaces. When we write our interfaces we should take care to add only methods that should be there. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well.
</li>
<li>The interfaces that are designed should not be fat, i.e the interface should not have too many methods which often do not get used together.
The idea here is to avoid loading all the methods into a single interface, instead segregate the methods in the interface such that all the methods that contribute towards offering a single type of service (or single type of clients) are grouped under one single interface. Thereby dealing with a bulky interface that might be difficult to manage is avoided.
</li>

<li>
The interface should be specific. The methods in the interface should be the ones that contribute towards offering only a specific type of service. For example, if there is an interface that offers methods that provide mathematical services to its clients, then the same interface should not contain methods that accomplish totally different types of tasks say, like a database functionality implementation.
The main reason behind such interfaces being discouraged is that if a class decides to (or has to) implement that interface, then, it has to provide an implementation even for those methods that it doesn’t intend to use. Even though such implementations may be empty methods, it is not convenient and also distorts the readability of the code.

</li>
</ol>
==Results of following ISP==
Designing software by adopting ISP will yield many simple interfaces that are more specific in nature which in turn will make the classes more cohesive.
==How ISP can be implemented in the design==
===Segregation through Delegation===
The object form of the ADAPTER Pattern can be used to delegate the responsibility of implementing the thin interface to the class that is the client of the interface.
===Segregation through multiple inheritance===
The methods that are to be included into the interfaces are grouped into interfaces such that all the methods in the interface are directed towards accomplishing a certain type of service. When a class has to use the methods in the interface, it has to implement the interface. When the class is required to implement methods from many interfaces, the class will have to inherit multiple light interfaces and also implement the methods in the interfaces.

==Example==
Consider an example of Course registration system which allows students to enroll in courses, similar to the one we have at NCSU.
Let us assume we have a student base class which other specialized student classes inherit from.

A full time student is allowed to register for a class. He can also choose to audit a particular class.

Lets say we have an interface called IEnroll.
The IEnroll interface exposes two methods viz. registerClass() which should allow a student to register himself for a class, and auditClass() which allows a student to audit a class he has registered for.
The FullStudent class is used to represent full time students. It extends the Student class and implements this IEnroll interface.
 
 
 
[[Image:Figure 1Class diagram for FullStudent (violates ISP).png]]
 
 
 
interface IEnroll {
public void registerClass();
public void auditClass();
}

class FullStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

Now lets suppose, NCSU decided not to allow part time students to audit a class once they have registered.
The PartStudent class represents the part time students. It extends the Student class.
Now PartStudent class can either implement IEnroll to provide the registration facility. But in that case, PartStudent is forced to implement the auditClass method.
 
 
 
[[Image:Figure 2Class diagram for PartStudent (violates ISP).png ]]
 
 
 
class PartStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//do nothing since we didn't want this method in the first place!
}
}

The other option is to define a new interface with just registClass method and use it in PartStudent class. But this defeats the purpose of having a common interface.

This is a good example of how our interface has become 'Fat' or 'Polluted'. It is exposing 2 different methods which its clients are forced to honor. This violates the ISP.

Lets see how we can correct this.

We separate out the 2 functions into different interfaces now,

interface IRegisterClass {
public void registerClass();
}
interface IAuditClass {
public auditClass();
}

This allows the FullStudent and PartStudent to be defined as following:
 
 
 
[[Image:Figure 3Class diagram for FullStudent (conforms to ISP).png]]
 
 
 

class FullStudent extends Student implements IRegisterClass, IAuditClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}
 
 
 
[[Image:Figure 4Class diagram for PartStudent (conforms to ISP).png]]
 
 
 
class PartStudent extends Student implements IRegisterClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
}
This gives a clean and correct way in which the PartStudent class is not forced to depend on an interface it does not want.

==Conclusion==
#Fat Interfaces are the interfaces that are not specific to a single client. Fat interfaces lead to unintended couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, through multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that resolve the unwanted coupling between clients. Thus maintaining loose coupling and high cohesion, which is an essential attribute of good software design.
#Interfaces containing methods that are not specific to a particular type of service are called polluted or fat interfaces. These must be avoided.

==See Also==
#[http://www.oodesign.com/design-principles.html Design principles]
#[http://java.sys-con.com/node/84633/print Three Sources of a Solid Object-Oriented Design]
#[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Principles of OOD]
#[http://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes episode on SOLID]

==External References==
<ol>
<li> [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]</li>
<li> [http://www.objectmentor.com Design Principles and Design Patterns, Robert C Martin]</li>
<li> [http://ontwik.com/ruby/sandi-metz-solid-object-oriented-design/ 2009 Gotham Ruby Conference, presentation on SOLID Object Oriented Design by Sandi Metz, Duke University.]</li>
<ol>

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T19:02:40Z

Aamarna2:

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle] object-oriented software development. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]SOLID object oriented principles. In this article we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>
<li>Clients should not be forced to depend upon interfaces that they don't use.</li>
</ul>
==Implications of the emphasis==
<ol>
<li>This principle provides guidelines to write our interfaces. When we write our interfaces we should take care to add only methods that should be there. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well.
</li>
<li>The interfaces that are designed should not be fat, i.e the interface should not have too many methods which often do not get used together.
The idea here is to avoid loading all the methods into a single interface, instead segregate the methods in the interface such that all the methods that contribute towards offering a single type of service (or single type of clients) are grouped under one single interface. Thereby dealing with a bulky interface that might be difficult to manage is avoided.
</li>

<li>
The interface should be specific. The methods in the interface should be the ones that contribute towards offering only a specific type of service. For example, if there is an interface that offers methods that provide mathematical services to its clients, then the same interface should not contain methods that accomplish totally different types of tasks say, like a database functionality implementation.
The main reason behind such interfaces being discouraged is that if a class decides to (or has to) implement that interface, then, it has to provide an implementation even for those methods that it doesn’t intend to use. Even though such implementations may be empty methods, it is not convenient and also distorts the readability of the code.

</li>
</ol>
==Results of following ISP==
Designing software by adopting ISP will yield many simple interfaces that are more specific in nature which in turn will make the classes more cohesive.
==How ISP can be implemented in the design==
===Segregation through Delegation===
The object form of the ADAPTER Pattern can be used to delegate the responsibility of implementing the thin interface to the class that is the client of the interface.
===Segregation through multiple inheritance===
The methods that are to be included into the interfaces are grouped into interfaces such that all the methods in the interface are directed towards accomplishing a certain type of service. When a class has to use the methods in the interface, it has to implement the interface. When the class is required to implement methods from many interfaces, the class will have to inherit multiple light interfaces and also implement the methods in the interfaces.

==Example==
Consider an example of Course registration system which allows students to enroll in courses, similar to the one we have at NCSU.
Let us assume we have a student base class which other specialized student classes inherit from.

A full time student is allowed to register for a class. He can also choose to audit a particular class.

Lets say we have an interface called IEnroll.
The IEnroll interface exposes two methods viz. registerClass() which should allow a student to register himself for a class, and auditClass() which allows a student to audit a class he has registered for.
The FullStudent class is used to represent full time students. It extends the Student class and implements this IEnroll interface.
 
 
 
[[Image:Figure 1Class diagram for FullStudent (violates ISP).png]]
 
 
 
interface IEnroll {
public void registerClass();
public void auditClass();
}

class FullStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

Now lets suppose, NCSU decided not to allow part time students to audit a class once they have registered.
The PartStudent class represents the part time students. It extends the Student class.
Now PartStudent class can either implement IEnroll to provide the registration facility. But in that case, PartStudent is forced to implement the auditClass method.
 
 
 
[[Image:Figure 2Class diagram for PartStudent (violates ISP).png ]]
 
 
 
class PartStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//do nothing since we didn't want this method in the first place!
}
}

The other option is to define a new interface with just registClass method and use it in PartStudent class. But this defeats the purpose of having a common interface.

This is a good example of how our interface has become 'Fat' or 'Polluted'. It is exposing 2 different methods which its clients are forced to honor. This violates the ISP.

Lets see how we can correct this.

We separate out the 2 functions into different interfaces now,

interface IRegisterClass {
public void registerClass();
}
interface IAuditClass {
public auditClass();
}

This allows the FullStudent and PartStudent to be defined as following:
 
 
 
[[Image:Figure 3Class diagram for FullStudent (conforms to ISP).png]]
 
 
 

class FullStudent extends Student implements IRegisterClass, IAuditClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}
 
 
 
[[Image:Figure 4Class diagram for PartStudent (conforms to ISP).png]]
 
 
 
class PartStudent extends Student implements IRegisterClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
}
This gives a clean and correct way in which the PartStudent class is not forced to depend on an interface it does not want.

==Conclusion==
#Fat Interfaces are the interfaces that are not specific to a single client. Fat interfaces lead to unintended couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, through multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that resolve the unwanted coupling between clients. Thus maintaining loose coupling and high cohesion, which is an essential attribute of good software design.
#Interfaces containing methods that are not specific to a particular type of service are called polluted or fat interfaces. These must be avoided.

==See Also==
#[http://www.oodesign.com/design-principles.html Design principles]
#[http://java.sys-con.com/node/84633/print Three Sources of a Solid Object-Oriented Design]
#[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Principles of OOD]
#[http://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes episode on SOLID]

==External References==
<ol>
<li> [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]</li>
<li> [http://www.objectmentor.com Design Principles and Design Patterns, Robert C Martin]</li>
<li> [http://ontwik.com/ruby/sandi-metz-solid-object-oriented-design/ 2009 Gotham Ruby Conference, presentation on SOLID Object Oriented Design by Sandi Metz, Duke University.]</li>
<ol>

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T19:00:50Z

Aamarna2:

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle] object-oriented software development. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]SOLID object oriented principles. In this article we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>
<li>Clients should not be forced to depend upon interfaces that they don't use.</li>
</ul>
==Implications of the emphasis==
<ol>
<li>This principle provides guidelines to write our interfaces. When we write our interfaces we should take care to add only methods that should be there. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well.
</li>
<li>The interfaces that are designed should not be fat, i.e the interface should not have too many methods which often do not get used together.
The idea here is to avoid loading all the methods into a single interface, instead segregate the methods in the interface such that all the methods that contribute towards offering a single type of service (or single type of clients) are grouped under one single interface. Thereby dealing with a bulky interface that might be difficult to manage is avoided.
</li>

<li>
The interface should be specific. The methods in the interface should be the ones that contribute towards offering only a specific type of service. For example, if there is an interface that offers methods that provide mathematical services to its clients, then the same interface should not contain methods that accomplish totally different types of tasks say, like a database functionality implementation.
The main reason behind such interfaces being discouraged is that if a class decides to (or has to) implement that interface, then, it has to provide an implementation even for those methods that it doesn’t intend to use. Even though such implementations may be empty methods, it is not convenient and also distorts the readability of the code.
</li>
</ol>
==Results of following ISP==
Designing software by adopting ISP will yield many simple interfaces that are more specific in nature which in turn will make the classes more cohesive.
==How ISP can be implemented in the design==
===Segregation through Delegation===
The object form of the ADAPTER Pattern can be used to delegate the responsibility of implementing the thin interface to the class that is the client of the interface.
===Segregation through multiple inheritance===
The methods that are to be included into the interfaces are grouped into interfaces such that all the methods in the interface are directed towards accomplishing a certain type of service. When a class has to use the methods in the interface, it has to implement the interface. When the class is required to implement methods from many interfaces, the class will have to inherit multiple light interfaces and also implement the methods in the interfaces.

==Example==
Consider an example of Course registration system which allows students to enroll in courses, similar to the one we have at NCSU.
Let us assume we have a student base class which other specialized student classes inherit from.

A full time student is allowed to register for a class. He can also choose to audit a particular class.

Lets say we have an interface called IEnroll.
The IEnroll interface exposes two methods viz. registerClass() which should allow a student to register himself for a class, and auditClass() which allows a student to audit a class he has registered for.
The FullStudent class is used to represent full time students. It extends the Student class and implements this IEnroll interface.
 
 
 
[[Image:Figure 1Class diagram for FullStudent (violates ISP).png]]
 
 
 
interface IEnroll {
public void registerClass();
public void auditClass();
}

class FullStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

Now lets suppose, NCSU decided not to allow part time students to audit a class once they have registered.
The PartStudent class represents the part time students. It extends the Student class.
Now PartStudent class can either implement IEnroll to provide the registration facility. But in that case, PartStudent is forced to implement the auditClass method.
 
 
 
[[Image:Figure 2Class diagram for PartStudent (violates ISP).png ]]
 
 
 
class PartStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//do nothing since we didn't want this method in the first place!
}
}

The other option is to define a new interface with just registClass method and use it in PartStudent class. But this defeats the purpose of having a common interface.

This is a good example of how our interface has become 'Fat' or 'Polluted'. It is exposing 2 different methods which its clients are forced to honor. This violates the ISP.

Lets see how we can correct this.

We separate out the 2 functions into different interfaces now,

interface IRegisterClass {
public void registerClass();
}
interface IAuditClass {
public auditClass();
}

This allows the FullStudent and PartStudent to be defined as following:
 
 
 
[[Image:Figure 3Class diagram for FullStudent (conforms to ISP).png]]
 
 
 

class FullStudent extends Student implements IRegisterClass, IAuditClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}
 
 
 
[[Image:Figure 4Class diagram for PartStudent (conforms to ISP).png]]
 
 
 
class PartStudent extends Student implements IRegisterClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
}
This gives a clean and correct way in which the PartStudent class is not forced to depend on an interface it does not want.

==Conclusion==
#Fat Interfaces are the interfaces that are not specific to a single client. Fat interfaces lead to unintended couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, through multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that resolve the unwanted coupling between clients. Thus maintaining loose coupling and high cohesion, which is an essential attribute of good software design.
#Interfaces containing methods that are not specific to a particular type of service are called polluted or fat interfaces. These must be avoided.

==See Also==
#[http://www.oodesign.com/design-principles.html Design principles]
#[http://java.sys-con.com/node/84633/print Three Sources of a Solid Object-Oriented Design]
#[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Principles of OOD]
#[http://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes episode on SOLID]

==External References==
<ol>
<li> [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]</li>
<li> [http://www.objectmentor.com Design Principles and Design Patterns, Robert C Martin]</li>
<li> [http://ontwik.com/ruby/sandi-metz-solid-object-oriented-design/ 2009 Gotham Ruby Conference, presentation on SOLID Object Oriented Design by Sandi Metz, Duke University.]</li>
<ol>

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T18:59:20Z

Aamarna2:

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle] object-oriented software development. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]SOLID object oriented principles. In this article we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>
<li>Clients should not be forced to depend upon interfaces that they don't use.</li>
</ul>
==Implications of the emphasis==
<ol>
<li>This principle provides guidelines to write our interfaces. When we write our interfaces we should take care to add only methods that should be there. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well.
</li>
<li>The interfaces that are designed should not be fat, i.e the interface should not have too many methods which often do not get used together.
The idea here is to avoid loading all the methods into a single interface, instead segregate the methods in the interface such that all the methods that contribute towards offering a single type of service (or single type of clients) are grouped under one single interface. Thereby dealing with a bulky interface that might be difficult to manage is avoided.
</li>

<li>
The interface should be specific. The methods in the interface should be the ones that contribute towards offering only a specific type of service. For example, if there is an interface that offers methods that provide mathematical services to its clients, then the same interface should not contain methods that accomplish totally different types of tasks say, like a database functionality implementation.
The main reason behind such interfaces being discouraged is that if a class decides to (or has to) implement that interface, then, it has to provide an implementation even for those methods that it doesn’t intend to use. Even though such implementations may be empty methods, it is not convenient and also distorts the readability of the code.
</li>
</ol>
==Results of following ISP==
Designing software by adopting ISP will yield many simple interfaces that are more specific in nature which in turn will make the classes more cohesive.
==How ISP can be implemented in the design==
===Segregation through Delegation===
The object form of the ADAPTER Pattern can be used to delegate the responsibility of implementing the thin interface to the class that is the client of the interface.
===Segregation through multiple inheritance===
The methods that are to be included into the interfaces are grouped into interfaces such that all the methods in the interface are directed towards accomplishing a certain type of service. When a class has to use the methods in the interface, it has to implement the interface. When the class is required to implement methods from many interfaces, the class will have to inherit multiple light interfaces and also implement the methods in the interfaces.

==Example==
Consider an example of Course registration system which allows students to enroll in courses, similar to the one we have at NCSU.
Let us assume we have a student base class which other specialized student classes inherit from.

A full time student is allowed to register for a class. He can also choose to audit a particular class.

Lets say we have an interface called IEnroll.
The IEnroll interface exposes two methods viz. registerClass() which should allow a student to register himself for a class, and auditClass() which allows a student to audit a class he has registered for.
The FullStudent class is used to represent full time students. It extends the Student class and implements this IEnroll interface.
 
 
 
[[Image:Figure 1Class diagram for FullStudent (violates ISP).png]]
 
 
 
interface IEnroll {
public void registerClass();
public void auditClass();
}

class FullStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

Now lets suppose, NCSU decided not to allow part time students to audit a class once they have registered.
The PartStudent class represents the part time students. It extends the Student class.
Now PartStudent class can either implement IEnroll to provide the registration facility. But in that case, PartStudent is forced to implement the auditClass method.
 
 
 
[[Image:Figure 2Class diagram for PartStudent (violates ISP).png ]]
 
 
 
class PartStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//do nothing since we didn't want this method in the first place!
}
}

The other option is to define a new interface with just registClass method and use it in PartStudent class. But this defeats the purpose of having a common interface.

This is a good example of how our interface has become 'Fat' or 'Polluted'. It is exposing 2 different methods which its clients are forced to honor. This violates the ISP.

Lets see how we can correct this.

We separate out the 2 functions into different interfaces now,

interface IRegisterClass {
public void registerClass();
}
interface IAuditClass {
public auditClass();
}

This allows the FullStudent and PartStudent to be defined as following:
 
 
 
[[Image:Figure 3Class diagram for FullStudent (conforms to ISP).png]]
 
 
 

class FullStudent extends Student implements IRegisterClass, IAuditClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}
 
 
 
[[Image:Figure 4Class diagram for PartStudent (conforms to ISP).png]]
 
 
 
class PartStudent extends Student implements IRegisterClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
}
This gives a clean and correct way in which the PartStudent class is not forced to depend on an interface it does not want.

==Conclusion==
#Fat Interfaces are the interfaces that are not specific to a single client. Fat interfaces lead to unintended couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, through multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that resolve the unwanted coupling between clients. Thus maintaining loose coupling and high cohesion, which is an essential attribute of good software design.
#Interfaces containing methods that are not specific to a particular type of service are called polluted or fat interfaces. These must be avoided.

==See Also==
#[http://www.oodesign.com/design-principles.html Design principles]
#[http://java.sys-con.com/node/84633/print Three Sources of a Solid Object-Oriented Design]
#[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Principles of OOD]
#[http://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes episode on SOLID]

==External References==
<ol>
<li> [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]</li>
<li> [http://www.objectmentor.com Design Principles and Design Patterns, Robert C Martin]</li>
<li> [http://ontwik.com/ruby/sandi-metz-solid-object-oriented-design/ 2009 Gotham Ruby Conference, presentation on SOLID Object Oriented Design by Sandi Metz, Duke University.]</li>
<ol>

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T18:58:58Z

Aamarna2:

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle] object-oriented software development. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]SOLID object oriented principles. In this article we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>
<li>Clients should not be forced to depend upon interfaces that they don't use.</li>
</ul>
==Implications of the emphasis==
<ol>
<li>a. This principle provides guidelines to write our interfaces. When we write our interfaces we should take care to add only methods that should be there. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well.
</li>
<li>The interfaces that are designed should not be fat, i.e the interface should not have too many methods which often do not get used together.
The idea here is to avoid loading all the methods into a single interface, instead segregate the methods in the interface such that all the methods that contribute towards offering a single type of service (or single type of clients) are grouped under one single interface. Thereby dealing with a bulky interface that might be difficult to manage is avoided.
</li>

<li>
The interface should be specific. The methods in the interface should be the ones that contribute towards offering only a specific type of service. For example, if there is an interface that offers methods that provide mathematical services to its clients, then the same interface should not contain methods that accomplish totally different types of tasks say, like a database functionality implementation.
The main reason behind such interfaces being discouraged is that if a class decides to (or has to) implement that interface, then, it has to provide an implementation even for those methods that it doesn’t intend to use. Even though such implementations may be empty methods, it is not convenient and also distorts the readability of the code.
</li>
</ol>
==Results of following ISP==
Designing software by adopting ISP will yield many simple interfaces that are more specific in nature which in turn will make the classes more cohesive.
==How ISP can be implemented in the design==
===Segregation through Delegation===
The object form of the ADAPTER Pattern can be used to delegate the responsibility of implementing the thin interface to the class that is the client of the interface.
===Segregation through multiple inheritance===
The methods that are to be included into the interfaces are grouped into interfaces such that all the methods in the interface are directed towards accomplishing a certain type of service. When a class has to use the methods in the interface, it has to implement the interface. When the class is required to implement methods from many interfaces, the class will have to inherit multiple light interfaces and also implement the methods in the interfaces.

==Example==
Consider an example of Course registration system which allows students to enroll in courses, similar to the one we have at NCSU.
Let us assume we have a student base class which other specialized student classes inherit from.

A full time student is allowed to register for a class. He can also choose to audit a particular class.

Lets say we have an interface called IEnroll.
The IEnroll interface exposes two methods viz. registerClass() which should allow a student to register himself for a class, and auditClass() which allows a student to audit a class he has registered for.
The FullStudent class is used to represent full time students. It extends the Student class and implements this IEnroll interface.
 
 
 
[[Image:Figure 1Class diagram for FullStudent (violates ISP).png]]
 
 
 
interface IEnroll {
public void registerClass();
public void auditClass();
}

class FullStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

Now lets suppose, NCSU decided not to allow part time students to audit a class once they have registered.
The PartStudent class represents the part time students. It extends the Student class.
Now PartStudent class can either implement IEnroll to provide the registration facility. But in that case, PartStudent is forced to implement the auditClass method.
 
 
 
[[Image:Figure 2Class diagram for PartStudent (violates ISP).png ]]
 
 
 
class PartStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//do nothing since we didn't want this method in the first place!
}
}

The other option is to define a new interface with just registClass method and use it in PartStudent class. But this defeats the purpose of having a common interface.

This is a good example of how our interface has become 'Fat' or 'Polluted'. It is exposing 2 different methods which its clients are forced to honor. This violates the ISP.

Lets see how we can correct this.

We separate out the 2 functions into different interfaces now,

interface IRegisterClass {
public void registerClass();
}
interface IAuditClass {
public auditClass();
}

This allows the FullStudent and PartStudent to be defined as following:
 
 
 
[[Image:Figure 3Class diagram for FullStudent (conforms to ISP).png]]
 
 
 

class FullStudent extends Student implements IRegisterClass, IAuditClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}
 
 
 
[[Image:Figure 4Class diagram for PartStudent (conforms to ISP).png]]
 
 
 
class PartStudent extends Student implements IRegisterClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
}
This gives a clean and correct way in which the PartStudent class is not forced to depend on an interface it does not want.

==Conclusion==
#Fat Interfaces are the interfaces that are not specific to a single client. Fat interfaces lead to unintended couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, through multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that resolve the unwanted coupling between clients. Thus maintaining loose coupling and high cohesion, which is an essential attribute of good software design.
#Interfaces containing methods that are not specific to a particular type of service are called polluted or fat interfaces. These must be avoided.

==See Also==
#[http://www.oodesign.com/design-principles.html Design principles]
#[http://java.sys-con.com/node/84633/print Three Sources of a Solid Object-Oriented Design]
#[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Principles of OOD]
#[http://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes episode on SOLID]

==External References==
<ol>
<li> [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]</li>
<li> [http://www.objectmentor.com Design Principles and Design Patterns, Robert C Martin]</li>
<li> [http://ontwik.com/ruby/sandi-metz-solid-object-oriented-design/ 2009 Gotham Ruby Conference, presentation on SOLID Object Oriented Design by Sandi Metz, Duke University.]</li>
<ol>

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T18:55:40Z

Aamarna2:

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle] object-oriented software development. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]SOLID object oriented principles. In this article we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>
</ul>
==Implications of the emphasis==
<ol>
<li>The interfaces that are designed should not be fat, i.e the interface should not have too many methods which often do not get used together.
The idea here is to avoid loading all the methods into a single interface, instead segregate the methods in the interface such that all the methods that contribute towards offering a single type of service (or single type of clients) are grouped under one single interface. Thereby dealing with a bulky interface that might be difficult to manage is avoided.
</li>

<li>
The interface should be specific. The methods in the interface should be the ones that contribute towards offering only a specific type of service. For example, if there is an interface that offers methods that provide mathematical services to its clients, then the same interface should not contain methods that accomplish totally different types of tasks say, like a database functionality implementation.
The main reason behind such interfaces being discouraged is that if a class decides to (or has to) implement that interface, then, it has to provide an implementation even for those methods that it doesn’t intend to use. Even though such implementations may be empty methods, it is not convenient and also distorts the readability of the code.
</li>
</ol>
==Results of following ISP==
Designing software by adopting ISP will yield many simple interfaces that are more specific in nature which in turn will make the classes more cohesive.
==How ISP can be implemented in the design==
===Segregation through Delegation===
The object form of the ADAPTER Pattern can be used to delegate the responsibility of implementing the thin interface to the class that is the client of the interface.
===Segregation through multiple inheritance===
The methods that are to be included into the interfaces are grouped into interfaces such that all the methods in the interface are directed towards accomplishing a certain type of service. When a class has to use the methods in the interface, it has to implement the interface. When the class is required to implement methods from many interfaces, the class will have to inherit multiple light interfaces and also implement the methods in the interfaces.

==Example==
Consider an example of Course registration system which allows students to enroll in courses, similar to the one we have at NCSU.
Let us assume we have a student base class which other specialized student classes inherit from.

A full time student is allowed to register for a class. He can also choose to audit a particular class.

Lets say we have an interface called IEnroll.
The IEnroll interface exposes two methods viz. registerClass() which should allow a student to register himself for a class, and auditClass() which allows a student to audit a class he has registered for.
The FullStudent class is used to represent full time students. It extends the Student class and implements this IEnroll interface.
 
 
 
[[Image:Figure 1Class diagram for FullStudent (violates ISP).png]]
 
 
 
interface IEnroll {
public void registerClass();
public void auditClass();
}

class FullStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

Now lets suppose, NCSU decided not to allow part time students to audit a class once they have registered.
The PartStudent class represents the part time students. It extends the Student class.
Now PartStudent class can either implement IEnroll to provide the registration facility. But in that case, PartStudent is forced to implement the auditClass method.
 
 
 
[[Image:Figure 2Class diagram for PartStudent (violates ISP).png ]]
 
 
 
class PartStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//do nothing since we didn't want this method in the first place!
}
}

The other option is to define a new interface with just registClass method and use it in PartStudent class. But this defeats the purpose of having a common interface.

This is a good example of how our interface has become 'Fat' or 'Polluted'. It is exposing 2 different methods which its clients are forced to honor. This violates the ISP.

Lets see how we can correct this.

We separate out the 2 functions into different interfaces now,

interface IRegisterClass {
public void registerClass();
}
interface IAuditClass {
public auditClass();
}

This allows the FullStudent and PartStudent to be defined as following:
 
 
 
[[Image:Figure 3Class diagram for FullStudent (conforms to ISP).png]]
 
 
 

class FullStudent extends Student implements IRegisterClass, IAuditClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}
 
 
 
[[Image:Figure 4Class diagram for PartStudent (conforms to ISP).png]]
 
 
 
class PartStudent extends Student implements IRegisterClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
}
This gives a clean and correct way in which the PartStudent class is not forced to depend on an interface it does not want.

==Conclusion==
#Fat Interfaces are the interfaces that are not specific to a single client. Fat interfaces lead to unintended couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, through multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that resolve the unwanted coupling between clients. Thus maintaining loose coupling and high cohesion, which is an essential attribute of good software design.
#Interfaces containing methods that are not specific to a particular type of service are called polluted or fat interfaces. These must be avoided.

==See Also==
#[http://www.oodesign.com/design-principles.html Design principles]
#[http://java.sys-con.com/node/84633/print Three Sources of a Solid Object-Oriented Design]
#[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Principles of OOD]
#[http://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes episode on SOLID]

==External References==
<ol>
<li> [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]</li>
<li> [http://www.objectmentor.com Design Principles and Design Patterns, Robert C Martin]</li>
<li> [http://ontwik.com/ruby/sandi-metz-solid-object-oriented-design/ 2009 Gotham Ruby Conference, presentation on SOLID Object Oriented Design by Sandi Metz, Duke University.]</li>
<ol>

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T18:53:11Z

Aamarna2:

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle] object-oriented software development. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]SOLID object oriented principles. In this article we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>
</ul>
==Implications of the emphasis==
<ol>
<li>The interfaces that are designed should not be fat, i.e the interface should not have too many methods which often do not get used together.
The idea here is to avoid loading all the methods into a single interface, instead segregate the methods in the interface such that all the methods that contribute towards offering a single type of service (or single type of clients) are grouped under one single interface. Thereby dealing with a bulky interface that might be difficult to manage is avoided.
</li>

<li>
The interface should be specific. The methods in the interface should be the ones that contribute towards offering only a specific type of service. For example, if there is an interface that offers methods that provide mathematical services to its clients, then the same interface should not contain methods that accomplish totally different types of tasks say, like a database functionality implementation.
The main reason behind such interfaces being discouraged is that if a class decides to (or has to) implement that interface, then, it has to provide an implementation even for those methods that it doesn’t intend to use. Even though such implementations may be empty methods, it is not convenient and also distorts the readability of the code.
</li>
</ol>
==Results of following ISP==
Designing software by adopting ISP will yield many simple interfaces that are more specific in nature which in turn will make the classes more cohesive.
==How ISP can be implemented in the design==
===Segregation through Delegation===
The object form of the ADAPTER Pattern can be used to delegate the responsibility of implementing the thin interface to the class that is the client of the interface.
===Segregation through multiple inheritance===
The methods that are to be included into the interfaces are grouped into interfaces such that all the methods in the interface are directed towards accomplishing a certain type of service. When a class has to use the methods in the interface, it has to implement the interface. When the class is required to implement methods from many interfaces, the class will have to inherit multiple light interfaces and also implement the methods in the interfaces.

==Example==
Consider an example of Course registration system which allows students to enroll in courses, similar to the one we have at NCSU.
Let us assume we have a student base class which other specialized student classes inherit from.

A full time student is allowed to register for a class. He can also choose to audit a particular class.

Lets say we have an interface called IEnroll.
The IEnroll interface exposes two methods viz. registerClass() which should allow a student to register himself for a class, and auditClass() which allows a student to audit a class he has registered for.
The FullStudent class is used to represent full time students. It extends the Student class and implements this IEnroll interface.
 
 
 
[[Image:Figure 1Class diagram for FullStudent (violates ISP).png]]
 
 
 
interface IEnroll {
public void registerClass();
public void auditClass();
}

class FullStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

Now lets suppose, NCSU decided not to allow part time students to audit a class once they have registered.
The PartStudent class represents the part time students. It extends the Student class.
Now PartStudent class can either implement IEnroll to provide the registration facility. But in that case, PartStudent is forced to implement the auditClass method.
 
 
 
[[Image:Figure 2Class diagram for PartStudent (violates ISP).png ]]
 
 
 
class PartStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//do nothing since we didn't want this method in the first place!
}
}

The other option is to define a new interface with just registClass method and use it in PartStudent class. But this defeats the purpose of having a common interface.

This is a good example of how our interface has become 'Fat' or 'Polluted'. It is exposing 2 different methods which its clients are forced to honor. This violates the ISP.

Lets see how we can correct this.

We separate out the 2 functions into different interfaces now,

interface IRegisterClass {
public void registerClass();
}
interface IAuditClass {
public auditClass();
}

This allows the FullStudent and PartStudent to be defined as following:
 
 
 
[[Image:Figure 3Class diagram for FullStudent (conforms to ISP).png]]
 
 
 

class FullStudent extends Student implements IRegisterClass, IAuditClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}
 
 
 
[[Image:Figure 4Class diagram for PartStudent (conforms to ISP).png]]
 
 
 
class PartStudent extends Student implements IRegisterClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
}
This gives a clean and correct way in which the PartStudent class is not forced to depend on an interface it does not want.

==Conclusion==
Fat Interfaces are the interfaces that are not specific to a single client. Fat interfaces lead to unintended couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, through multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that resolve the unwanted coupling between clients. Thus maintaining loose coupling and high cohesion, which is an essential attribute of good software design.

==See Also==
#[http://www.oodesign.com/design-principles.html Design principles]
#[http://java.sys-con.com/node/84633/print Three Sources of a Solid Object-Oriented Design]
#[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Principles of OOD]
#[http://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes episode on SOLID]

==External References==
<ol>
<li> [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]</li>
<li> [http://www.objectmentor.com Design Principles and Design Patterns, Robert C Martin]</li>
<li> [http://ontwik.com/ruby/sandi-metz-solid-object-oriented-design/ 2009 Gotham Ruby Conference, presentation on SOLID Object Oriented Design by Sandi Metz, Duke University.]</li>
<ol>

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T18:51:52Z

Aamarna2:

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle] object-oriented software development. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]SOLID object oriented principles. In this article we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>
</ul>
==Implications of the emphasis==
<ol>
<li>The interfaces that are designed should not be fat, i.e the interface should not have too many methods which often do not get used together.
The idea here is to avoid loading all the methods into a single interface, instead segregate the methods in the interface such that all the methods that contribute towards offering a single type of service (or single type of clients) are grouped under one single interface. Thereby dealing with a bulky interface that might be difficult to manage is avoided.
</li>

<li>
The interface should be specific. The methods in the interface should be the ones that contribute towards offering only a specific type of service. For example, if there is an interface that offers methods that provide mathematical services to its clients, then the same interface should not contain methods that accomplish totally different types of tasks say, like a database functionality implementation.
The main reason behind such interfaces being discouraged is that if a class decides to (or has to) implement that interface, then, it has to provide an implementation even for those methods that it doesn’t intend to use. Even though such implementations may be empty methods, it is not convenient and also distorts the readability of the code.
</li>
</ol>
==Results of following ISP==
Designing software by adopting ISP will yield many simple interfaces that are more specific in nature which in turn will make the classes more cohesive.
==How ISP can be implemented in the design==
===Segregation through Delegation===
The object form of the ADAPTER Pattern can be used to delegate the responsibility of implementing the thin interface to the class that is the client of the interface.
===Segregation through multiple inheritance===
The methods that are to be included into the interfaces are grouped into interfaces such that all the methods in the interface are directed towards accomplishing a certain type of service. When a class has to use the methods in the interface, it has to implement the interface. When the class is required to implement methods from many interfaces, the class will have to inherit multiple light interfaces and also implement the methods in the interfaces.

==Example==
Consider an example of Course registration system which allows students to enroll in courses, similar to the one we have at NCSU.
Let us assume we have a student base class which other specialized student classes inherit from.

A full time student is allowed to register for a class. He can also choose to audit a particular class.

Lets say we have an interface called IEnroll.
The IEnroll interface exposes two methods viz. registerClass() which should allow a student to register himself for a class, and auditClass() which allows a student to audit a class he has registered for.
The FullStudent class is used to represent full time students. It extends the Student class and implements this IEnroll interface.
 

 
[[Image:Figure 1Class diagram for FullStudent (violates ISP).png]]
 
interface IEnroll {
public void registerClass();
public void auditClass();
}

class FullStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

Now lets suppose, NCSU decided not to allow part time students to audit a class once they have registered.
The PartStudent class represents the part time students. It extends the Student class.
Now PartStudent class can either implement IEnroll to provide the registration facility. But in that case, PartStudent is forced to implement the auditClass method.
 
[[Image:Figure 2Class diagram for PartStudent (violates ISP).png ]]
 
class PartStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//do nothing since we didn't want this method in the first place!
}
}

The other option is to define a new interface with just registClass method and use it in PartStudent class. But this defeats the purpose of having a common interface.

This is a good example of how our interface has become 'Fat' or 'Polluted'. It is exposing 2 different methods which its clients are forced to honor. This violates the ISP.

Lets see how we can correct this.

We separate out the 2 functions into different interfaces now,

interface IRegisterClass {
public void registerClass();
}
interface IAuditClass {
public auditClass();
}

This allows the FullStudent and PartStudent to be defined as following:
 
[[Image:Figure 3Class diagram for FullStudent (conforms to ISP).png]]
 

class FullStudent extends Student implements IRegisterClass, IAuditClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}
 
[[Image:Figure 4Class diagram for PartStudent (conforms to ISP).png]]
 

class PartStudent extends Student implements IRegisterClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
}
This gives a clean and correct way in which the PartStudent class is not forced to depend on an interface it does not want.

==Conclusion==
Fat Interfaces are the interfaces that are not specific to a single client. Fat interfaces lead to unintended couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, through multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that resolve the unwanted coupling between clients. Thus maintaining loose coupling and high cohesion, which is an essential attribute of good software design.

==See Also==
#[http://www.oodesign.com/design-principles.html Design principles]
#[http://java.sys-con.com/node/84633/print Three Sources of a Solid Object-Oriented Design]
#[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Principles of OOD]
#[http://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes episode on SOLID]

==External References==
<ol>
<li> [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]</li>
<li> [http://www.objectmentor.com Design Principles and Design Patterns, Robert C Martin]</li>
<li> [http://ontwik.com/ruby/sandi-metz-solid-object-oriented-design/ 2009 Gotham Ruby Conference, presentation on SOLID Object Oriented Design by Sandi Metz, Duke University.]</li>
<ol>

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T18:50:19Z

Aamarna2:

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle] object-oriented software development. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]SOLID object oriented principles. In this article we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>
</ul>
==Implications of the emphasis==
<ol>
<li>The interfaces that are designed should not be fat, i.e the interface should not have too many methods which often do not get used together.
The idea here is to avoid loading all the methods into a single interface, instead segregate the methods in the interface such that all the methods that contribute towards offering a single type of service (or single type of clients) are grouped under one single interface. Thereby dealing with a bulky interface that might be difficult to manage is avoided.
</li>

<li>
The interface should be specific. The methods in the interface should be the ones that contribute towards offering only a specific type of service. For example, if there is an interface that offers methods that provide mathematical services to its clients, then the same interface should not contain methods that accomplish totally different types of tasks say, like a database functionality implementation.
The main reason behind such interfaces being discouraged is that if a class decides to (or has to) implement that interface, then, it has to provide an implementation even for those methods that it doesn’t intend to use. Even though such implementations may be empty methods, it is not convenient and also distorts the readability of the code.
</li>
</ol>
==Results of following ISP==
Designing software by adopting ISP will yield many simple interfaces that are more specific in nature which in turn will make the classes more cohesive.
==How ISP can be implemented in the design==
===Segregation through Delegation===
The object form of the ADAPTER Pattern can be used to delegate the responsibility of implementing the thin interface to the class that is the client of the interface.
===Segregation through multiple inheritance===
The methods that are to be included into the interfaces are grouped into interfaces such that all the methods in the interface are directed towards accomplishing a certain type of service. When a class has to use the methods in the interface, it has to implement the interface. When the class is required to implement methods from many interfaces, the class will have to inherit multiple light interfaces and also implement the methods in the interfaces.

==Example==
Consider an example of Course registration system which allows students to enroll in courses, similar to the one we have at NCSU.
Let us assume we have a student base class which other specialized student classes inherit from.

A full time student is allowed to register for a class. He can also choose to audit a particular class.

Lets say we have an interface called IEnroll.
The IEnroll interface exposes two methods viz. registerClass() which should allow a student to register himself for a class, and auditClass() which allows a student to audit a class he has registered for.
The FullStudent class is used to represent full time students. It extends the Student class and implements this IEnroll interface.
 
<table border=1>
<tr>[[Image:Figure 1Class diagram for FullStudent (violates ISP).png]]</tr>
</table>
interface IEnroll {
public void registerClass();
public void auditClass();
}

class FullStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

Now lets suppose, NCSU decided not to allow part time students to audit a class once they have registered.
The PartStudent class represents the part time students. It extends the Student class.
Now PartStudent class can either implement IEnroll to provide the registration facility. But in that case, PartStudent is forced to implement the auditClass method.
<table border=1>
<tr> [[Image:Figure 2Class diagram for PartStudent (violates ISP).png ]]</tr>
</table>
class PartStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//do nothing since we didn't want this method in the first place!
}
}

The other option is to define a new interface with just registClass method and use it in PartStudent class. But this defeats the purpose of having a common interface.

This is a good example of how our interface has become 'Fat' or 'Polluted'. It is exposing 2 different methods which its clients are forced to honor. This violates the ISP.

Lets see how we can correct this.

We separate out the 2 functions into different interfaces now,

interface IRegisterClass {
public void registerClass();
}
interface IAuditClass {
public auditClass();
}

This allows the FullStudent and PartStudent to be defined as following:
 
[[Image:Figure 3Class diagram for FullStudent (conforms to ISP).png]]

class FullStudent extends Student implements IRegisterClass, IAuditClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

[[Image:Figure 4Class diagram for PartStudent (conforms to ISP).png]]

class PartStudent extends Student implements IRegisterClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
}
This gives a clean and correct way in which the PartStudent class is not forced to depend on an interface it does not want.

==Conclusion==
Fat Interfaces are the interfaces that are not specific to a single client. Fat interfaces lead to unintended couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, through multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that resolve the unwanted coupling between clients. Thus maintaining loose coupling and high cohesion, which is an essential attribute of good software design.

==See Also==
#[http://www.oodesign.com/design-principles.html Design principles]
#[http://java.sys-con.com/node/84633/print Three Sources of a Solid Object-Oriented Design]
#[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Principles of OOD]
#[http://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes episode on SOLID]

==External References==
<ol>
<li> [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]</li>
<li> [http://www.objectmentor.com Design Principles and Design Patterns, Robert C Martin]</li>
<li> [http://ontwik.com/ruby/sandi-metz-solid-object-oriented-design/ 2009 Gotham Ruby Conference, presentation on SOLID Object Oriented Design by Sandi Metz, Duke University.]</li>
<ol>

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T18:49:35Z

Aamarna2:

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle] object-oriented software development. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]SOLID object oriented principles. In this article we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>
</ul>
==Implications of the emphasis==
<ol>
<li>The interfaces that are designed should not be fat, i.e the interface should not have too many methods which often do not get used together.
The idea here is to avoid loading all the methods into a single interface, instead segregate the methods in the interface such that all the methods that contribute towards offering a single type of service (or single type of clients) are grouped under one single interface. Thereby dealing with a bulky interface that might be difficult to manage is avoided.
</li>

<li>
The interface should be specific. The methods in the interface should be the ones that contribute towards offering only a specific type of service. For example, if there is an interface that offers methods that provide mathematical services to its clients, then the same interface should not contain methods that accomplish totally different types of tasks say, like a database functionality implementation.
The main reason behind such interfaces being discouraged is that if a class decides to (or has to) implement that interface, then, it has to provide an implementation even for those methods that it doesn’t intend to use. Even though such implementations may be empty methods, it is not convenient and also distorts the readability of the code.
</li>
</ol>
==Results of following ISP==
Designing software by adopting ISP will yield many simple interfaces that are more specific in nature which in turn will make the classes more cohesive.
==How ISP can be implemented in the design==
===Segregation through Delegation===
The object form of the ADAPTER Pattern can be used to delegate the responsibility of implementing the thin interface to the class that is the client of the interface.
===Segregation through multiple inheritance===
The methods that are to be included into the interfaces are grouped into interfaces such that all the methods in the interface are directed towards accomplishing a certain type of service. When a class has to use the methods in the interface, it has to implement the interface. When the class is required to implement methods from many interfaces, the class will have to inherit multiple light interfaces and also implement the methods in the interfaces.

==Example==
Consider an example of Course registration system which allows students to enroll in courses, similar to the one we have at NCSU.
Let us assume we have a student base class which other specialized student classes inherit from.

A full time student is allowed to register for a class. He can also choose to audit a particular class.

Lets say we have an interface called IEnroll.
The IEnroll interface exposes two methods viz. registerClass() which should allow a student to register himself for a class, and auditClass() which allows a student to audit a class he has registered for.
The FullStudent class is used to represent full time students. It extends the Student class and implements this IEnroll interface.
 
<table border=1>
<tr>[[Image:Figure 1Class diagram for FullStudent (violates ISP).png]]</tr>
</table>
interface IEnroll {
public void registerClass();
public void auditClass();
}

class FullStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

Now lets suppose, NCSU decided not to allow part time students to audit a class once they have registered.
The PartStudent class represents the part time students. It extends the Student class.
Now PartStudent class can either implement IEnroll to provide the registration facility. But in that case, PartStudent is forced to implement the auditClass method.
<table border=1>
<tr> [[Image:Figure 2Class diagram for PartStudent (violates ISP).png ]]</tr>
</table>
class PartStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//do nothing since we didn't want this method in the first place!
}
}

The other option is to define a new interface with just registClass method and use it in PartStudent class. But this defeats the purpose of having a common interface.

This is a good example of how our interface has become 'Fat' or 'Polluted'. It is exposing 2 different methods which its clients are forced to honor. This violates the ISP.

Lets see how we can correct this.

We separate out the 2 functions into different interfaces now,

interface IRegisterClass {
public void registerClass();
}
interface IAuditClass {
public auditClass();
}

This allows the FullStudent and PartStudent to be defined as following:
[[Image:Figure 3Class diagram for FullStudent (conforms to ISP).png]]

class FullStudent extends Student implements IRegisterClass, IAuditClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

[[Image:Figure 4Class diagram for PartStudent (conforms to ISP).png]]

class PartStudent extends Student implements IRegisterClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
}
This gives a clean and correct way in which the PartStudent class is not forced to depend on an interface it does not want.

==Conclusion==
Fat Interfaces are the interfaces that are not specific to a single client. Fat interfaces lead to unintended couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, through multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that resolve the unwanted coupling between clients. Thus maintaining loose coupling and high cohesion, which is an essential attribute of good software design.

==See Also==
#[http://www.oodesign.com/design-principles.html Design principles]
#[http://java.sys-con.com/node/84633/print Three Sources of a Solid Object-Oriented Design]
#[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Principles of OOD]
#[http://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes episode on SOLID]

==External References==
<ol>
<li> [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]</li>
<li> [http://www.objectmentor.com Design Principles and Design Patterns, Robert C Martin]</li>
<li> [http://ontwik.com/ruby/sandi-metz-solid-object-oriented-design/ 2009 Gotham Ruby Conference, presentation on SOLID Object Oriented Design by Sandi Metz, Duke University.]</li>
<ol>

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T18:39:48Z

Aamarna2:

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle] object-oriented software development. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]SOLID object oriented principles. In this article we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>
</ul>
==Implications of the emphasis==
<ol>
<li>The interfaces that are designed should not be fat, i.e the interface should not have too many methods which often do not get used together.
The idea here is to avoid loading all the methods into a single interface, instead segregate the methods in the interface such that all the methods that contribute towards offering a single type of service (or single type of clients) are grouped under one single interface. Thereby dealing with a bulky interface that might be difficult to manage is avoided.
</li>

<li>
The interface should be specific. The methods in the interface should be the ones that contribute towards offering only a specific type of service. For example, if there is an interface that offers methods that provide mathematical services to its clients, then the same interface should not contain methods that accomplish totally different types of tasks say, like a database functionality implementation.
The main reason behind such interfaces being discouraged is that if a class decides to (or has to) implement that interface, then, it has to provide an implementation even for those methods that it doesn’t intend to use. Even though such implementations may be empty methods, it is not convenient and also distorts the readability of the code.
</li>
</ol>
==Results of following ISP==
Designing software by adopting ISP will yield many simple interfaces that are more specific in nature which in turn will make the classes more cohesive.
==How ISP can be implemented in the design==
===#Segregation through Delegation===
The object form of the ADAPTER Pattern can be used to delegate the responsibility of implementing the thin interface to the class that is the client of the interface.
===#Segregation through multiple inheritance===
The methods that are to be included into the interfaces are grouped into interfaces such that all the methods in the interface are directed towards accomplishing a certain type of service. When a class has to use the methods in the interface, it has to implement the interface. When the class is required to implement methods from many interfaces, the class will have to inherit multiple light interfaces and also implement the methods in the interfaces.

==Example==
Consider an example of Course registration system which allows students to enroll in courses, similar to the one we have at NCSU.
Let us assume we have a student base class which other specialized student classes inherit from.

A full time student at NCSU is allowed to register for a class. He can also choose to audit a particular class.

Lets say we have an interface called IEnroll.
The IEnroll interface exposes two methods viz. registerClass() which should allow a student to register himself for a class, and auditClass() which allows a student to audit a class he has registered for.
The FullStudent class is used to represent full time students. It extends the Student class and implements this IEnroll interface.

interface IEnroll {
public void registerClass();
public void auditClass();
}

class FullStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

Now lets suppose, NCSU decided not to allow part time students to audit a class once they have registered.
The PartStudent class represents the part time students. It extends the Student class.
Now PartStudent class can either implement IEnroll to provide the registration facility. But in that case, PartStudent is forced to implement the auditClass method.

class PartStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//do nothing since we didn't want this method in the first place!
}
}

The other option is to define a new interface with just registClass method and use it in PartStudent class. But this defeats the purpose of having a common interface.

This is a good example of how our interface has become 'Fat' or 'Polluted'. It is exposing 2 different methods which its clients are forced to honor. This violates the ISP.

Lets see how we can correct this.

We separate out the 2 functions into different interfaces now,

interface IRegisterClass {
public void registerClass();
}
interface IAuditClass {
public auditClass();
}

This allows the FullStudent and PartStudent to be defined as following:

class FullStudent extends Student implements IRegisterClass, IAuditClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

class PartStudent extends Student implements IRegisterClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
}
This gives a clean and correct way in which the PartStudent class is not forced to depend on an interface it does not want.

==Conclusion==
Fat Interfaces are the interfaces that are not specific to a single client. Fat interfaces lead to unintended couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, through multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that resolve the unwanted coupling between clients. Thus maintaining loose coupling and high cohesion, which is an essential attribute of good software design.

==See Also==
#[http://www.oodesign.com/design-principles.html Design principles]
#[http://java.sys-con.com/node/84633/print Three Sources of a Solid Object-Oriented Design]
#[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Principles of OOD]
#[http://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes episode on SOLID]

==External References==
<ol>
<li> [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]</li>
<li> [http://www.objectmentor.com Design Principles and Design Patterns, Robert C Martin]</li>
<li> [http://ontwik.com/ruby/sandi-metz-solid-object-oriented-design/ 2009 Gotham Ruby Conference, presentation on SOLID Object Oriented Design by Sandi Metz, Duke University.]</li>
<ol>

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T18:38:57Z

Aamarna2:

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle] object-oriented software development. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]SOLID object oriented principles. In this article we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>
</ul>
==Implications of the emphasis==
<ol>
<li>The interfaces that are designed should not be fat, i.e the interface should not have too many methods which often do not get used together.
The idea here is to avoid loading all the methods into a single interface, instead segregate the methods in the interface such that all the methods that contribute towards offering a single type of service (or single type of clients) are grouped under one single interface. Thereby dealing with a bulky interface that might be difficult to manage is avoided.
</li>

<li>
The interface should be specific. The methods in the interface should be the ones that contribute towards offering only a specific type of service. For example, if there is an interface that offers methods that provide mathematical services to its clients, then the same interface should not contain methods that accomplish totally different types of tasks say, like a database functionality implementation.
The main reason behind such interfaces being discouraged is that if a class decides to (or has to) implement that interface, then, it has to provide an implementation even for those methods that it doesn’t intend to use. Even though such implementations may be empty methods, it is not convenient and also distorts the readability of the code.
</li>
</ol>
==Results of following ISP==
Designing software by adopting ISP will yield many simple interfaces that are more specific in nature which in turn will make the classes more cohesive.
==How ISP can be implemented in the design==
#Segregation through Delegation
The object form of the ADAPTER Pattern can be used to delegate the responsibility of implementing the thin interface to the class that is the client of the interface.
#Segregation through multiple inheritance
The methods that are to be included into the interfaces are grouped into interfaces such that all the methods in the interface are directed towards accomplishing a certain type of service. When a class has to use the methods in the interface, it has to implement the interface. When the class is required to implement methods from many interfaces, the class will have to inherit multiple light interfaces and also implement the methods in the interfaces.

==Example==
Consider an example of Course registration system which allows students to enroll in courses, similar to the one we have at NCSU.
Let us assume we have a student base class which other specialized student classes inherit from.

A full time student at NCSU is allowed to register for a class. He can also choose to audit a particular class.

Lets say we have an interface called IEnroll.
The IEnroll interface exposes two methods viz. registerClass() which should allow a student to register himself for a class, and auditClass() which allows a student to audit a class he has registered for.
The FullStudent class is used to represent full time students. It extends the Student class and implements this IEnroll interface.

interface IEnroll {
public void registerClass();
public void auditClass();
}

class FullStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

Now lets suppose, NCSU decided not to allow part time students to audit a class once they have registered.
The PartStudent class represents the part time students. It extends the Student class.
Now PartStudent class can either implement IEnroll to provide the registration facility. But in that case, PartStudent is forced to implement the auditClass method.

class PartStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//do nothing since we didn't want this method in the first place!
}
}

The other option is to define a new interface with just registClass method and use it in PartStudent class. But this defeats the purpose of having a common interface.

This is a good example of how our interface has become 'Fat' or 'Polluted'. It is exposing 2 different methods which its clients are forced to honor. This violates the ISP.

Lets see how we can correct this.

We separate out the 2 functions into different interfaces now,

interface IRegisterClass {
public void registerClass();
}
interface IAuditClass {
public auditClass();
}

This allows the FullStudent and PartStudent to be defined as following:

class FullStudent extends Student implements IRegisterClass, IAuditClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

class PartStudent extends Student implements IRegisterClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
}
This gives a clean and correct way in which the PartStudent class is not forced to depend on an interface it does not want.

==Conclusion==
Fat Interfaces are the interfaces that are not specific to a single client. Fat interfaces lead to unintended couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, through multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that resolve the unwanted coupling between clients. Thus maintaining loose coupling and high cohesion, which is an essential attribute of good software design.

==See Also==
#[http://www.oodesign.com/design-principles.html Design principles]
#[http://java.sys-con.com/node/84633/print Three Sources of a Solid Object-Oriented Design]
#[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Principles of OOD]
#[http://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes episode on SOLID]

==External References==
<ol>
<li> [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]</li>
<li> [http://www.objectmentor.com Design Principles and Design Patterns, Robert C Martin]</li>
<li> [http://ontwik.com/ruby/sandi-metz-solid-object-oriented-design/ 2009 Gotham Ruby Conference, presentation on SOLID Object Oriented Design by Sandi Metz, Duke University.]</li>
<ol>

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T18:36:30Z

Aamarna2:

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle] object-oriented software development. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]SOLID object oriented principles. In this article we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>
</ul>
==Implications of the emphasis==
<ol>
<li>The interfaces that are designed should not be fat, i.e the interface should not have too many methods which often do not get used together.
The idea here is to avoid loading all the methods into a single interface, instead segregate the methods in the interface such that all the methods that contribute towards offering a single type of service (or single type of clients) are grouped under one single interface. Thereby dealing with a bulky interface that might be difficult to manage is avoided.
</li>

<li>
The interface should be specific. The methods in the interface should be the ones that contribute towards offering only a specific type of service. For example, if there is an interface that offers methods that provide mathematical services to its clients, then the same interface should not contain methods that accomplish totally different types of tasks say, like a database functionality implementation.
The main reason behind such interfaces being discouraged is that if a class decides to (or has to) implement that interface, then, it has to provide an implementation even for those methods that it doesn’t intend to use. Even though such implementations may be empty methods, it is not convenient and also distorts the readability of the code.
</li>
</ol>
==Results of following ISP==
Designing software by adopting ISP will yield many simple interfaces that are more specific in nature which in turn will make the classes more cohesive.
==How ISP can be implemented in the design==
#Segregation through Delegation
The object form of the ADAPTER Pattern can be used to delegate the responsibility of implementing the thin interface to the class that is the client of the interface.
#Segregation through multiple inheritance
The methods that are to be included into the interfaces are grouped into interfaces such that all the methods in the interface are directed towards accomplishing a certain type of service. When a class has to use the methods in the interface, it has to implement the interface. When the class is required to implement methods from many interfaces, the class will have to inherit multiple light interfaces and also implement the methods in the interfaces.

==Example==
Consider an example of Course registration system which allows students to enroll in courses, similar to the one we have at NCSU.
Let us assume we have a student base class which other specialized student classes inherit from.

A full time student at NCSU is allowed to register for a class. He can also choose to audit a particular class.

Lets say we have an interface called IEnroll.
The IEnroll interface exposes two methods viz. registerClass() which should allow a student to register himself for a class, and auditClass() which allows a student to audit a class he has registered for.
The FullStudent class is used to represent full time students. It extends the Student class and implements this IEnroll interface.

interface IEnroll {
public void registerClass();
public void auditClass();
}

class FullStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

Now lets suppose, NCSU decided not to allow part time students to audit a class once they have registered.
The PartStudent class represents the part time students. It extends the Student class.
Now PartStudent class can either implement IEnroll to provide the registration facility. But in that case, PartStudent is forced to implement the auditClass method.

class PartStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//do nothing since we didn't want this method in the first place!
}
}

The other option is to define a new interface with just registClass method and use it in PartStudent class. But this defeats the purpose of having a common interface.

This is a good example of how our interface has become 'Fat' or 'Polluted'. It is exposing 2 different methods which its clients are forced to honor. This violates the ISP.

Lets see how we can correct this.

We separate out the 2 functions into different interfaces now,

interface IRegisterClass {
public void registerClass();
}
interface IAuditClass {
public auditClass();
}

This allows the FullStudent and PartStudent to be defined as following:

class FullStudent extends Student implements IRegisterClass, IAuditClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

class PartStudent extends Student implements IRegisterClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
}
This gives a clean and correct way in which the PartStudent class is not forced to depend on an interface it does not want.

==Conclusion==
Fat Interfaces are the interfaces that are not specific to a single client. Fat interfaces lead to unintended couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, through multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that resolve the unwanted coupling between clients. Thus maintaining loose coupling and high cohesion, which is an essential attribute of good software design.

==See Also==
#[http://www.oodesign.com/design-principles.html Design principles]
#[http://java.sys-con.com/node/84633/print Three Sources of a Solid Object-Oriented Design]
#[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Principles of OOD]
#[http://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes episode on SOLID]

==External References==
<ol>
<li> [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]</li>
<li> [http://www.objectmentor.com Design Principles and Design Patterns, Robert C Martin]</li>
<li> [http://ontwik.com/ruby/sandi-metz-solid-object-oriented-design/ 2009 Gotham Ruby Conference, presentation on SOLID Object Oriented Design by Sandi Metz, Duke University.]</li>
<ol>

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T18:34:42Z

Aamarna2:

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle] object-oriented software development. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]SOLID object oriented principles. In this article we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>
</ul>
==Implications of the emphasis==
<ol>
<li>The interfaces that are designed should not be fat, i.e the interface should not have too many methods which often do not get used together.
The idea here is to avoid loading all the methods into a single interface, instead segregate the methods in the interface such that all the methods that contribute towards offering a single type of service (or single type of clients) are grouped under one single interface. Thereby dealing with a bulky interface that might be difficult to manage is avoided.
</li>

<li>
The interface should be specific. The methods in the interface should be the ones that contribute towards offering only a specific type of service. For example, if there is an interface that offers methods that provide mathematical services to its clients, then the same interface should not contain methods that accomplish totally different types of tasks say, like a database functionality implementation.
The main reason behind such interfaces being discouraged is that if a class decides to (or has to) implement that interface, then, it has to provide an implementation even for those methods that it doesn’t intend to use. Even though such implementations may be empty methods, it is not convenient and also distorts the readability of the code.
</li>
</ol>
==Results of following ISP==
Designing software by adopting ISP will yield many simple interfaces that are more specific in nature which in turn will make the classes more cohesive.
==How ISP can be implemented in the design==
#Segregation through Delegation
The object form of the ADAPTER Pattern can be used to delegate the responsibility of implementing the thin interface to the class that is the client of the interface.
#Segregation through multiple inheritance
The methods that are to be included into the interfaces are grouped into interfaces such that all the methods in the interface are directed towards accomplishing a certain type of service. When a class has to use the methods in the interface, it has to implement the interface. When the class is required to implement methods from many interfaces, the class will have to inherit multiple light interfaces and also implement the methods in the interfaces.

==Example==
Consider an example of Course registration system which allows students to enroll in courses, similar to the one we have at NCSU.
Let us assume we have a student base class which other specialized student classes inherit from.

A full time student at NCSU is allowed to register for a class. He can also choose to audit a particular class.

Lets say we have an interface called IEnroll.
The IEnroll interface exposes two methods viz. registerClass() which should allow a student to register himself for a class, and auditClass() which allows a student to audit a class he has registered for.
The FullStudent class is used to represent full time students. It extends the Student class and implements this IEnroll interface.

interface IEnroll {
public void registerClass();
public void auditClass();
}

class FullStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

Now lets suppose, NCSU decided not to allow part time students to audit a class once they have registered.
The PartStudent class represents the part time students. It extends the Student class.
Now PartStudent class can either implement IEnroll to provide the registration facility. But in that case, PartStudent is forced to implement the auditClass method.

class PartStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//do nothing since we didn't want this method in the first place!
}
}

The other option is to define a new interface with just registClass method and use it in PartStudent class. But this defeats the purpose of having a common interface.

This is a good example of how our interface has become 'Fat' or 'Polluted'. It is exposing 2 different methods which its clients are forced to honor. This violates the ISP.

Lets see how we can correct this.

We separate out the 2 functions into different interfaces now,

interface IRegisterClass {
public void registerClass();
}
interface IAuditClass {
public auditClass();
}

This allows the FullStudent and PartStudent to be defined as following:

class FullStudent extends Student implements IRegisterClass, IAuditClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

class PartStudent extends Student implements IRegisterClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
}

This gives a clean and correct way in which the PartStudent class is not forced to depend on an interface it does not want.

==Conclusion==
Fat Interfaces are the interfaces that are not specific to a single client. Fat interfaces lead to unintended couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, through multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that resolve the unwanted coupling between clients. Thus maintaining loose coupling and high cohesion, which is an essential attribute of good software design.

==See Also==
#[http://www.oodesign.com/design-principles.html Design principles]
#[http://java.sys-con.com/node/84633/print Three Sources of a Solid Object-Oriented Design]
#[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Principles of OOD]
#[http://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes episode on SOLID]

==External References==
<ol>
<li> [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]</li>
<li> [http://www.objectmentor.com Design Principles and Design Patterns, Robert C Martin]</li>
<li> [http://ontwik.com/ruby/sandi-metz-solid-object-oriented-design/ 2009 Gotham Ruby Conference, presentation on SOLID Object Oriented Design by Sandi Metz, Duke University.]</li>
<ol>

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T18:28:25Z

Aamarna2:

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle] object-oriented software development. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]SOLID object oriented principles. In this article we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>
</ul>
==Implications of the emphasis==
<ol>
<li>The interfaces that are designed should not be fat, i.e the interface should not have too many methods which often do not get used together.
The idea here is to avoid loading all the methods into a single interface, instead segregate the methods in the interface such that all the methods that contribute towards offering a single type of service (or single type of clients) are grouped under one single interface. Thereby dealing with a bulky interface that might be difficult to manage is avoided.
</li>

<li>
The interface should be specific. The methods in the interface should be the ones that contribute towards offering only a specific type of service. For example, if there is an interface that offers methods that provide mathematical services to its clients, then the same interface should not contain methods that accomplish totally different types of tasks say, like a database functionality implementation.
The main reason behind such interfaces being discouraged is that if a class decides to (or has to) implement that interface, then, it has to provide an implementation even for those methods that it doesn’t intend to use. Even though such implementations may be empty methods, it is not convenient and also distorts the readability of the code.
</li>
</ol>
==Results of following ISP==
Designing software by adopting ISP will yield many simple interfaces that are more specific in nature which in turn will make the classes more cohesive.
==How ISP can be implemented in the design==
#Segregation through Delegation
The object form of the ADAPTER Pattern can be used to delegate the responsibility of implementing the thin interface to the class that is the client of the interface.
#Segregation through multiple inheritance
The methods that are to be included into the interfaces are grouped into interfaces such that all the methods in the interface are directed towards accomplishing a certain type of service. When a class has to use the methods in the interface, it has to implement the interface. When the class is required to implement methods from many interfaces, the class will have to inherit multiple light interfaces and also implement the methods in the interfaces.

==Example==
Consider an example of Course registration system which allows students to enroll in courses, similar to the one we have at NCSU.
Let us assume we have a student base class which other specialized student classes inherit from.

A full time student at NCSU is allowed to register for a class. He can also choose to audit a particular class.

Lets say we have an interface called IEnroll.
The IEnroll interface exposes two methods viz. registerClass() which should allow a student to register himself for a class, and auditClass() which allows a student to audit a class he has registered for.
The FullStudent class is used to represent full time students. It extends the Student class and implements this IEnroll interface.

interface IEnroll {
public void registerClass();
public void auditClass();
}

class FullStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

Now lets suppose, NCSU decided not to allow part time students to audit a class once they have registered.
The PartStudent class represents the part time students. It extends the Student class.
Now PartStudent class can either implement IEnroll to provide the registration facility. But in that case, PartStudent is forced to implement the auditClass method.

class PartStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//do nothing since we didn't want this method in the first place!
}
}

The other option is to define a new interface with just registClass method and use it in PartStudent class. But this defeats the purpose of having a common interface.

This is a good example of how our interface has become 'Fat' or 'Polluted'. It is exposing 2 different methods which its clients are forced to honor. This violates the ISP.

Lets see how we can correct this.

We separate out the 2 functions into different interfaces now,

interface IRegisterClass {
public void registerClass();
}
interface IAuditClass {
public auditClass();
}

This allows the FullStudent and PartStudent to be defined as following:

class FullStudent extends Student implements IRegisterClass, IAuditClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

class PartStudent extends Student implements IRegisterClass
{
public void registerClass()
{
//allow a student to register for a particular class
}

}

This gives a clean and correct way in which the PartStudent class is not forced to depend on an interface it does not want.

==Conclusion==
Fat Interfaces are the interfaces that are not specific to a single client. Fat interfaces lead to unintended couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, through multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that resolve the unwanted coupling between clients. Thus maintaining loose coupling and high cohesion, which is an essential attribute of good software design.

==See Also==
#[http://www.oodesign.com/design-principles.html Design principles]
#[http://java.sys-con.com/node/84633/print Three Sources of a Solid Object-Oriented Design]
#[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Principles of OOD]
#[http://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes episode on SOLID]

==External References==
<ol>
<li> [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]</li>
<li> [http://www.objectmentor.com Design Principles and Design Patterns, Robert C Martin]</li>
<li> [http://ontwik.com/ruby/sandi-metz-solid-object-oriented-design/ 2009 Gotham Ruby Conference, presentation on SOLID Object Oriented Design by Sandi Metz, Duke University.]</li>
<ol>

File:Figure 4Class diagram for PartStudent (conforms to ISP).png

2010-11-16T18:24:48Z

Aamarna2: Figure 4 Class diagram for PartStudent (conforms to ISP)

Figure 4 Class diagram for PartStudent (conforms to ISP)

File:Figure 3Class diagram for FullStudent (conforms to ISP).png

2010-11-16T18:24:24Z

Aamarna2: Figure 3 Class diagram for FullStudent (conforms to ISP)

Figure 3 Class diagram for FullStudent (conforms to ISP)

File:Figure 2Class diagram for PartStudent (violates ISP).png

2010-11-16T18:23:55Z

Aamarna2: Figure 2 Class diagram for PartStudent (violates ISP)

Figure 2 Class diagram for PartStudent (violates ISP)

File:Figure 1Class diagram for FullStudent (violates ISP).png

2010-11-16T18:23:24Z

Aamarna2: Figure 1Class diagram for FullStudent (violates ISP)

Figure 1Class diagram for FullStudent (violates ISP)

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T18:17:46Z

Aamarna2:

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T18:16:37Z

Aamarna2:

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T18:02:11Z

Aamarna2:

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T18:01:44Z

Aamarna2:

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T17:56:30Z

Aamarna2:

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T17:55:48Z

Aamarna2:

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T17:53:25Z

Aamarna2:

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T17:45:57Z

Aamarna2:

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T17:44:27Z

Aamarna2:

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-16T17:39:30Z

Aamarna2:

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of object-oriented software development [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle]. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the SOLID object oriented principles[http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]. In this article we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>

CSC/ECE 517 Fall 2010/ch2 2a aa

2010-10-06T23:11:56Z

Aamarna2:

[Language extensions for ORM]

== Introduction to Object Relational Mapping. ==
Object Relational Mapping is a technique of mapping the solution entities of an object oriented system, objects [http://en.wikipedia.org/wiki/Object_%28computer_science%29]to relational database [http://en.wikipedia.org/wiki/Relational_database_management_system] tables. This technique came into existence as an answer to the problem of lack of persistence of objects across session in Object Oriented Programming Systems [http://en.wikipedia.org/wiki/Object-oriented_programming]. For instance in a software solution to manage the order and inventory systems of a company, the objects that are part of the systems e.g orders, customers, must be accessible even if the system was temporarily shut down for a while. ORM [http://en.wikipedia.org/wiki/Object-relational_mapping] helps in achieving this very essential requirement by bringing the database into the picture, more specifically bringing the RDBMS into the picture.

== Why ORM, why not another solution? ==
The answer to this is quite an obvious one. ORM brings to the table something(s) that another solution hasn’t done so far. These “something(s)” that ORM contributes are listed below:
#Alleviates the problem that hinders a transition from one database provider to another database vendor or even another database product.
#Enables to perform most of the database operations (mainly CRUD[http://en.wikipedia.org/wiki/Create,_read,_update_and_delete]) without having to write any SQL [http://en.wikipedia.org/wiki/SQL] statements, thereby permitting a shift from one SQL dialect to another. This also allows the software solutions to focus more on the actual problem being solved rather that performing supplementary functions extensively.

[[Image:Example1.png]]

==Flavors of ORM solutions.==
The term ORM is a very generic name for the class of solutions. Typically, ORM support in object oriented languages comes in two flavors; one that comes in separate packages which can be imported into our application, the other is the variety that comes incorporated into a language.
When there is an option of choosing among the two flavors, the solution that come incorporated into the language is preferred. This choice may be quite an obvious one depending on the language that is being considered.
Though the difference between the two might not be that apparent in the outset, the reason for this predilection towards the language incorporate solution over the other has mainly to do with design paradigm of the modern day software development of “convention over configuration”[http://en.wikipedia.org/wiki/Convention_over_configuration]. This paradigm emphasizes on the development by convention rather than development by configuration. The fact that the solution involving external packages and libraries involve a lot of configuration files which play the instructing role. In the language incorporated solution, such a problem doesn’t arise as the involvement of configuration files in the entire system itself is scanty. In the following sections we will take a look at two of the preferred language incorporated solutions.

==ORM implementation in specific languages.==
In this section, we will look at the language specific ORM examples illustrating the relation between creation of classes and tables, objects and rows, attributes and columns; and also examples for performing basic CRUD operations for two specific Object Oriented languages.
===Groovy, Grails and GROM:===
====Creating classes and tables:====
Classes, when created using the create-domain-class, also create the table of the same name as the class (not the plural).
For example,
grails create-domain-class Assignment
running the above command would create an empty class named Assignment and also create a table named Assignment in the database. Attributes to this class may be added in a fashion similar to the one followed in java. The attributes that are created in-turn gets automatically mapped to the columns in the table “Assignment”.

We may want to define the Assignment class as follows
class Assignment {
String title
Date dueDate
String weightage_on_final_grade
}
Having objects defined within a class would facilitate in achieving association between classes.

====Basic CRUD:====
:Creating objects also creates rows. This is done as illustrated below:
def a = new Assignment (title:"WikiTextChapter", dueDate:date, weightage_on_final_grade:3)
a.save()

The above statements would create a new Assignment object and also create a row in the Assignment table. The save method above may be considered analogous to a commit statement that may be used in SQL.
:Reading objects from the database. This can be done as in the below example.
def a = Assignment.get(1)
In the above statement, the parameter 1 passed to the get method is an identifier for the object. When an object is created in the database, an id is created transparently by the language specifics.
Apart from the get method, other ways of fetching objects from database would involve use of methods such as list(), findBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. This is achieved by updating the necessary attribute of an object and saving or committing the changes back to the database. This is illustrated in the below example.
def a = Assignment.get(1)
a. weightage_on_final_grade =5
a.save()
:Deleting objects. To perform a delete, we must first get an object and then call the delete method on that object. This is illustrated in the below example.
def a = Assignment.get(1)
a.delete()

===PHP ActiveRecord:===
====Creating classes and tables:====
Tables corresponding to classes can be created by
classes extending the ActiveRecord\Model class.
class Assignment extends ActiveRecord\Model
{
}
====Basic CRUD:====
:Creating objects also creates rows. This can be done by as shown below.
$a = new Assignment();
$a-> title=’ WikiTextChapter’;
$a->save();
:Reading objects from database. Objects can be read from the database as illustrated in the below example.
$a = Assignment::find(1);
::Apart from the get method, other ways of fetching objects from database would involve use of methods such as findBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. For this to be done, we need to find a record first and then change one of its attributes and finally commit the changes. This is illustrated below:
$a = Assignment::find(1);
$a->title = 'NewWikiTextChapter’';
$a->save();
:Deleting objects. For this to be done, we need to find a record first and then call the delete method on the object.
$a = Assignment::find(1);
$a->delete();
:This is similar to ActiveRecord in Ruby, so we will not explicitly deal with ORM in Ruby.

==Language support for ORM.==
To incorporate ORM into a language, the usual approach, is to implement the ActiveRecord Design Pattern [http://en.wikipedia.org/wiki/Active_record_pattern]. This approach considers persistence as a responsibility of the object rather than as a service. Following this approach, would hence expect the objects themselves implement methods to support database operations and like in the object oriented world the objects are expected to be able to manage themselves. Following the object oriented paradigm and adopting a modular approach the responsibility of implementing the methods facilitating the database operations are implemented by a class which is inherited by all other classes whose objects have to persist across sessions. The methods to support database operations include methods to create tables, create rows in the table when objects of a class are created; methods to read objects from the table; methods that facilitate updating the objects and finally methods to delete the objects. Apart from this basic CRUD functionality any extra functionality would always be welcome.

==References and Further Reading==
#Very informative and a nice place to start. http://www.slideshare.net/hominhchuc/grails-docs-presentation
#Insight into impedance mismatch. http://www.agiledata.org/essays/impedanceMismatch.html
#three List of object-relational mapping software http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
#Active Record Design Pattern - Domain Driven Design and Domain Layer - Object Persistence. http://davidhayden.com/blog/dave/archive/2006/06/10/2984.aspx
#Grails home page. http://grails.org/
#ORM in php: php.active record http://www.phpactiverecord.org/
#Active Record Design Pattern http://en.wikipedia.org/wiki/Active_record_pattern

CSC/ECE 517 Fall 2010/ch2 2a aa

2010-10-06T23:11:14Z

Aamarna2:

[Language extensions for ORM]

== Introduction to Object Relational Mapping. ==
Object Relational Mapping is a technique of mapping the solution entities of an object oriented system, objects [http://en.wikipedia.org/wiki/Object_%28computer_science%29]to relational database [http://en.wikipedia.org/wiki/Relational_database_management_system] tables. This technique came into existence as an answer to the problem of lack of persistence of objects across session in Object Oriented Programming Systems [http://en.wikipedia.org/wiki/Object-oriented_programming]. For instance in a software solution to manage the order and inventory systems of a company, the objects that are part of the systems e.g orders, customers, must be accessible even if the system was temporarily shut down for a while. ORM [http://en.wikipedia.org/wiki/Object-relational_mapping] helps in achieving this very essential requirement by bringing the database into the picture, more specifically bringing the RDBMS into the picture.

== Why ORM, why not another solution? ==
The answer to this is quite an obvious one. ORM brings to the table something(s) that another solution hasn’t done so far. These “something(s)” that ORM contributes are listed below:
#Alleviates the problem that hinders a transition from one database provider to another database vendor or even another database product.
#Enables to perform most of the database operations (mainly CRUD[http://en.wikipedia.org/wiki/Create,_read,_update_and_delete]) without having to write any SQL [http://en.wikipedia.org/wiki/SQL] statements, thereby permitting a shift from one SQL dialect to another. This also allows the software solutions to focus more on the actual problem being solved rather that performing supplementary functions extensively.

[[Image:Example1.png]]

==Flavors of ORM solutions.==
The term ORM is a very generic name for the class of solutions. Typically, ORM support in object oriented languages comes in two flavors; one that comes in separate packages which can be imported into our application, the other is the variety that comes incorporated into a language.
When there is an option of choosing among the two flavors, the solution that come incorporated into the language is preferred. This choice may be quite an obvious one depending on the language that is being considered.
Though the difference between the two might not be that apparent in the outset, the reason for this predilection towards the language incorporate solution over the other has mainly to do with design paradigm of the modern day software development of “convention over configuration”[http://en.wikipedia.org/wiki/Convention_over_configuration]. This paradigm emphasizes on the development by convention rather than development by configuration. The fact that the solution involving external packages and libraries involve a lot of configuration files which play the instructing role. In the language incorporated solution, such a problem doesn’t arise as the involvement of configuration files in the entire system itself is scanty. In the following sections we will take a look at two of the preferred language incorporated solutions.

==ORM implementation in specific languages.==
In this section, we will look at the language specific ORM examples illustrating the relation between creation of classes and tables, objects and rows, attributes and columns; and also examples for performing basic CRUD operations for two specific Object Oriented languages.
===Groovy, Grails and GROM:===
====Creating classes and tables:====
Classes, when created using the create-domain-class, also create the table of the same name as the class (not the plural).
For example,
grails create-domain-class Assignment
running the above command would create an empty class named Assignment and also create a table named Assignment in the database. Attributes to this class may be added in a fashion similar to the one followed in java. The attributes that are created in-turn gets automatically mapped to the columns in the table “Assignment”.

We may want to define the Assignment class as follows
class Assignment {
String title
Date dueDate
String weightage_on_final_grade
}
Having objects defined within a class would facilitate in achieving association between classes.

====Basic CRUD:====
:Creating objects also creates rows. This is done as illustrated below:
def a = new Assignment (title:"WikiTextChapter", dueDate:date, weightage_on_final_grade:3)
a.save()

The above statements would create a new Assignment object and also create a row in the Assignment table. The save method above may be considered analogous to a commit statement that may be used in SQL.
:Reading objects from the database. This can be done as in the below example.
def a = Assignment.get(1)
In the above statement, the parameter 1 passed to the get method is an identifier for the object. When an object is created in the database, an id is created transparently by the language specifics.
Apart from the get method, other ways of fetching objects from database would involve use of methods such as list(), findBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. This is achieved by updating the necessary attribute of an object and saving or committing the changes back to the database. This is illustrated in the below example.
def a = Assignment.get(1)
a. weightage_on_final_grade =5
a.save()
:Deleting objects. To perform a delete, we must first get an object and then call the delete method on that object. This is illustrated in the below example.
def a = Assignment.get(1)
a.delete()

===PHP ActiveRecord:===
====Creating classes and tables:====
Tables corresponding to classes can be created by
classes extending the ActiveRecord\Model class.
class Assignment extends ActiveRecord\Model
{
}
====Basic CRUD:====
:Creating objects also creates rows. This can be done by as shown below.
$a = new Assignment();
$a-> title=’ WikiTextChapter’;
$a->save();
:Reading objects from database. Objects can be read from the database as illustrated in the below example.
$a = Assignment::find(1);
::Apart from the get method, other ways of fetching objects from database would involve use of methods such as findBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. For this to be done, we need to find a record first and then change one of its attributes and finally commit the changes. This is illustrated below:
$a = Assignment::find(1);
$a->title = 'NewWikiTextChapter’';
$a->save();
:Deleting objects. For this to be done, we need to find a record first and then call the delete method on the object.
$a = Assignment::find(1);
$a->delete();
:This is similar to ActiveRecord in Ruby, so we will not explicitly deal with ORM in Ruby.

==Language support for ORM.==
To incorporate ORM into a language, the usual approach, is to implement the ActiveRecord Design Pattern [http://en.wikipedia.org/wiki/Active_record_pattern]. This approach considers persistence as a responsibility of the object rather than as a service. Following this approach, would hence expect the objects themselves implement methods to support database operations and like in the object oriented world the objects are expected to be able to manage themselves. Following the object oriented paradigm and adopting a modular approach the responsibility of implementing the methods facilitating the database operations are implemented by a class which is inherited by all other classes whose objects have to persist across sessions. The methods to support database operations include methods to create tables, create rows in the table when objects of a class are created; methods to read objects from the table; methods that facilitate updating the objects and finally methods to delete the objects. Apart from this basic CRUD functionality any extra functionality would always be welcome.

==References and Further Reading==
#one Very informative and a nice place to start. http://www.slideshare.net/hominhchuc/grails-docs-presentation
#two Insight into impedance mismatch. http://www.agiledata.org/essays/impedanceMismatch.html
#three List of object-relational mapping software http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
*Active Record Design Pattern - Domain Driven Design and Domain Layer - Object Persistence. http://davidhayden.com/blog/dave/archive/2006/06/10/2984.aspx
*Grails home page. http://grails.org/
*ORM in php: php.active record http://www.phpactiverecord.org/
*Active Record Design Pattern http://en.wikipedia.org/wiki/Active_record_pattern

File:Example1.png

2010-10-06T23:07:46Z

Aamarna2:

CSC/ECE 517 Fall 2010/ch2 2a aa

2010-10-06T23:06:46Z

Aamarna2:

[Language extensions for ORM]

== Introduction to Object Relational Mapping. ==
Object Relational Mapping is a technique of mapping the solution entities of an object oriented system, objects [http://en.wikipedia.org/wiki/Object_%28computer_science%29]to relational database [http://en.wikipedia.org/wiki/Relational_database_management_system] tables. This technique came into existence as an answer to the problem of lack of persistence of objects across session in Object Oriented Programming Systems [http://en.wikipedia.org/wiki/Object-oriented_programming]. For instance in a software solution to manage the order and inventory systems of a company, the objects that are part of the systems e.g orders, customers, must be accessible even if the system was temporarily shut down for a while. ORM [http://en.wikipedia.org/wiki/Object-relational_mapping] helps in achieving this very essential requirement by bringing the database into the picture, more specifically bringing the RDBMS into the picture.

== Why ORM, why not another solution? ==
The answer to this is quite an obvious one. ORM brings to the table something(s) that another solution hasn’t done so far. These “something(s)” that ORM contributes are listed below:
#Alleviates the problem that hinders a transition from one database provider to another database vendor or even another database product.
#Enables to perform most of the database operations (mainly CRUD[http://en.wikipedia.org/wiki/Create,_read,_update_and_delete]) without having to write any SQL [http://en.wikipedia.org/wiki/SQL] statements, thereby permitting a shift from one SQL dialect to another. This also allows the software solutions to focus more on the actual problem being solved rather that performing supplementary functions extensively.

[[Image:Example1.png]]

==Flavors of ORM solutions.==
The term ORM is a very generic name for the class of solutions. Typically, ORM support in object oriented languages comes in two flavors; one that comes in separate packages which can be imported into our application, the other is the variety that comes incorporated into a language.
When there is an option of choosing among the two flavors, the solution that come incorporated into the language is preferred. This choice may be quite an obvious one depending on the language that is being considered.
Though the difference between the two might not be that apparent in the outset, the reason for this predilection towards the language incorporate solution over the other has mainly to do with design paradigm of the modern day software development of “convention over configuration”[http://en.wikipedia.org/wiki/Convention_over_configuration]. This paradigm emphasizes on the development by convention rather than development by configuration. The fact that the solution involving external packages and libraries involve a lot of configuration files which play the instructing role. In the language incorporated solution, such a problem doesn’t arise as the involvement of configuration files in the entire system itself is scanty. In the following sections we will take a look at two of the preferred language incorporated solutions.

==ORM implementation in specific languages.==
In this section, we will look at the language specific ORM examples illustrating the relation between creation of classes and tables, objects and rows, attributes and columns; and also examples for performing basic CRUD operations for two specific Object Oriented languages.
===Groovy, Grails and GROM:===
====Creating classes and tables:====
Classes, when created using the create-domain-class, also create the table of the same name as the class (not the plural).
For example,
grails create-domain-class Assignment
running the above command would create an empty class named Assignment and also create a table named Assignment in the database. Attributes to this class may be added in a fashion similar to the one followed in java. The attributes that are created in-turn gets automatically mapped to the columns in the table “Assignment”.

We may want to define the Assignment class as follows
class Assignment {
String title
Date dueDate
String weightage_on_final_grade
}
Having objects defined within a class would facilitate in achieving association between classes.

====Basic CRUD:====
:Creating objects also creates rows. This is done as illustrated below:
def a = new Assignment (title:"WikiTextChapter", dueDate:date, weightage_on_final_grade:3)
a.save()

The above statements would create a new Assignment object and also create a row in the Assignment table. The save method above may be considered analogous to a commit statement that may be used in SQL.
:Reading objects from the database. This can be done as in the below example.
def a = Assignment.get(1)
In the above statement, the parameter 1 passed to the get method is an identifier for the object. When an object is created in the database, an id is created transparently by the language specifics.
Apart from the get method, other ways of fetching objects from database would involve use of methods such as list(), findBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. This is achieved by updating the necessary attribute of an object and saving or committing the changes back to the database. This is illustrated in the below example.
def a = Assignment.get(1)
a. weightage_on_final_grade =5
a.save()
:Deleting objects. To perform a delete, we must first get an object and then call the delete method on that object. This is illustrated in the below example.
def a = Assignment.get(1)
a.delete()

===PHP ActiveRecord:===
====Creating classes and tables:====
Tables corresponding to classes can be created by
classes extending the ActiveRecord\Model class.
class Assignment extends ActiveRecord\Model
{
}
====Basic CRUD:====
:Creating objects also creates rows. This can be done by as shown below.
$a = new Assignment();
$a-> title=’ WikiTextChapter’;
$a->save();
:Reading objects from database. Objects can be read from the database as illustrated in the below example.
$a = Assignment::find(1);
::Apart from the get method, other ways of fetching objects from database would involve use of methods such as findBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. For this to be done, we need to find a record first and then change one of its attributes and finally commit the changes. This is illustrated below:
$a = Assignment::find(1);
$a->title = 'NewWikiTextChapter’';
$a->save();
:Deleting objects. For this to be done, we need to find a record first and then call the delete method on the object.
$a = Assignment::find(1);
$a->delete();
:This is similar to ActiveRecord in Ruby, so we will not explicitly deal with ORM in Ruby.

==Language support for ORM.==
To incorporate ORM into a language, the usual approach, is to implement the ActiveRecord Design Pattern [http://en.wikipedia.org/wiki/Active_record_pattern]. This approach considers persistence as a responsibility of the object rather than as a service. Following this approach, would hence expect the objects themselves implement methods to support database operations and like in the object oriented world the objects are expected to be able to manage themselves. Following the object oriented paradigm and adopting a modular approach the responsibility of implementing the methods facilitating the database operations are implemented by a class which is inherited by all other classes whose objects have to persist across sessions. The methods to support database operations include methods to create tables, create rows in the table when objects of a class are created; methods to read objects from the table; methods that facilitate updating the objects and finally methods to delete the objects. Apart from this basic CRUD functionality any extra functionality would always be welcome.

==References and Further Reading==
*Very informative and a nice place to start. http://www.slideshare.net/hominhchuc/grails-docs-presentation
*Insight into impedance mismatch. http://www.agiledata.org/essays/impedanceMismatch.html
*List of object-relational mapping software http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
*Active Record Design Pattern - Domain Driven Design and Domain Layer - Object Persistence. http://davidhayden.com/blog/dave/archive/2006/06/10/2984.aspx
*Grails home page. http://grails.org/
*ORM in php: php.active record http://www.phpactiverecord.org/
*Active Record Design Pattern http://en.wikipedia.org/wiki/Active_record_pattern

CSC/ECE 517 Fall 2010/ch2 2a aa

2010-10-06T23:06:04Z

Aamarna2:

[Language extensions for ORM]

== Introduction to Object Relational Mapping. ==
Object Relational Mapping is a technique of mapping the solution entities of an object oriented system, objects [http://en.wikipedia.org/wiki/Object_%28computer_science%29]to relational database [http://en.wikipedia.org/wiki/Relational_database_management_system] tables. This technique came into existence as an answer to the problem of lack of persistence of objects across session in Object Oriented Programming Systems [http://en.wikipedia.org/wiki/Object-oriented_programming]. For instance in a software solution to manage the order and inventory systems of a company, the objects that are part of the systems e.g orders, customers, must be accessible even if the system was temporarily shut down for a while. ORM [http://en.wikipedia.org/wiki/Object-relational_mapping] helps in achieving this very essential requirement by bringing the database into the picture, more specifically bringing the RDBMS into the picture.

== Why ORM, why not another solution? ==
The answer to this is quite an obvious one. ORM brings to the table something(s) that another solution hasn’t done so far. These “something(s)” that ORM contributes are listed below:
#Alleviates the problem that hinders a transition from one database provider to another database vendor or even another database product.
#Enables to perform most of the database operations (mainly CRUD[http://en.wikipedia.org/wiki/Create,_read,_update_and_delete]) without having to write any SQL [http://en.wikipedia.org/wiki/SQL] statements, thereby permitting a shift from one SQL dialect to another. This also allows the software solutions to focus more on the actual problem being solved rather that performing supplementary functions extensively.

[[Image:Example.jpg]]

==Flavors of ORM solutions.==
The term ORM is a very generic name for the class of solutions. Typically, ORM support in object oriented languages comes in two flavors; one that comes in separate packages which can be imported into our application, the other is the variety that comes incorporated into a language.
When there is an option of choosing among the two flavors, the solution that come incorporated into the language is preferred. This choice may be quite an obvious one depending on the language that is being considered.
Though the difference between the two might not be that apparent in the outset, the reason for this predilection towards the language incorporate solution over the other has mainly to do with design paradigm of the modern day software development of “convention over configuration”[http://en.wikipedia.org/wiki/Convention_over_configuration]. This paradigm emphasizes on the development by convention rather than development by configuration. The fact that the solution involving external packages and libraries involve a lot of configuration files which play the instructing role. In the language incorporated solution, such a problem doesn’t arise as the involvement of configuration files in the entire system itself is scanty. In the following sections we will take a look at two of the preferred language incorporated solutions.

==ORM implementation in specific languages.==
In this section, we will look at the language specific ORM examples illustrating the relation between creation of classes and tables, objects and rows, attributes and columns; and also examples for performing basic CRUD operations for two specific Object Oriented languages.
===Groovy, Grails and GROM:===
====Creating classes and tables:====
Classes, when created using the create-domain-class, also create the table of the same name as the class (not the plural).
For example,
grails create-domain-class Assignment
running the above command would create an empty class named Assignment and also create a table named Assignment in the database. Attributes to this class may be added in a fashion similar to the one followed in java. The attributes that are created in-turn gets automatically mapped to the columns in the table “Assignment”.

We may want to define the Assignment class as follows
class Assignment {
String title
Date dueDate
String weightage_on_final_grade
}
Having objects defined within a class would facilitate in achieving association between classes.

====Basic CRUD:====
:Creating objects also creates rows. This is done as illustrated below:
def a = new Assignment (title:"WikiTextChapter", dueDate:date, weightage_on_final_grade:3)
a.save()

The above statements would create a new Assignment object and also create a row in the Assignment table. The save method above may be considered analogous to a commit statement that may be used in SQL.
:Reading objects from the database. This can be done as in the below example.
def a = Assignment.get(1)
In the above statement, the parameter 1 passed to the get method is an identifier for the object. When an object is created in the database, an id is created transparently by the language specifics.
Apart from the get method, other ways of fetching objects from database would involve use of methods such as list(), findBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. This is achieved by updating the necessary attribute of an object and saving or committing the changes back to the database. This is illustrated in the below example.
def a = Assignment.get(1)
a. weightage_on_final_grade =5
a.save()
:Deleting objects. To perform a delete, we must first get an object and then call the delete method on that object. This is illustrated in the below example.
def a = Assignment.get(1)
a.delete()

===PHP ActiveRecord:===
====Creating classes and tables:====
Tables corresponding to classes can be created by
classes extending the ActiveRecord\Model class.
class Assignment extends ActiveRecord\Model
{
}
====Basic CRUD:====
:Creating objects also creates rows. This can be done by as shown below.
$a = new Assignment();
$a-> title=’ WikiTextChapter’;
$a->save();
:Reading objects from database. Objects can be read from the database as illustrated in the below example.
$a = Assignment::find(1);
::Apart from the get method, other ways of fetching objects from database would involve use of methods such as findBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. For this to be done, we need to find a record first and then change one of its attributes and finally commit the changes. This is illustrated below:
$a = Assignment::find(1);
$a->title = 'NewWikiTextChapter’';
$a->save();
:Deleting objects. For this to be done, we need to find a record first and then call the delete method on the object.
$a = Assignment::find(1);
$a->delete();
:This is similar to ActiveRecord in Ruby, so we will not explicitly deal with ORM in Ruby.

==Language support for ORM.==
To incorporate ORM into a language, the usual approach, is to implement the ActiveRecord Design Pattern [http://en.wikipedia.org/wiki/Active_record_pattern]. This approach considers persistence as a responsibility of the object rather than as a service. Following this approach, would hence expect the objects themselves implement methods to support database operations and like in the object oriented world the objects are expected to be able to manage themselves. Following the object oriented paradigm and adopting a modular approach the responsibility of implementing the methods facilitating the database operations are implemented by a class which is inherited by all other classes whose objects have to persist across sessions. The methods to support database operations include methods to create tables, create rows in the table when objects of a class are created; methods to read objects from the table; methods that facilitate updating the objects and finally methods to delete the objects. Apart from this basic CRUD functionality any extra functionality would always be welcome.

==References and Further Reading==
*Very informative and a nice place to start. http://www.slideshare.net/hominhchuc/grails-docs-presentation
*Insight into impedance mismatch. http://www.agiledata.org/essays/impedanceMismatch.html
*List of object-relational mapping software http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
*Active Record Design Pattern - Domain Driven Design and Domain Layer - Object Persistence. http://davidhayden.com/blog/dave/archive/2006/06/10/2984.aspx
*Grails home page. http://grails.org/
*ORM in php: php.active record http://www.phpactiverecord.org/
*Active Record Design Pattern http://en.wikipedia.org/wiki/Active_record_pattern

CSC/ECE 517 Fall 2010/ch2 2a aa

2010-10-06T23:05:36Z

Aamarna2:

[Language extensions for ORM]

== Introduction to Object Relational Mapping. ==
Object Relational Mapping is a technique of mapping the solution entities of an object oriented system, objects [http://en.wikipedia.org/wiki/Object_%28computer_science%29]to relational database [http://en.wikipedia.org/wiki/Relational_database_management_system] tables. This technique came into existence as an answer to the problem of lack of persistence of objects across session in Object Oriented Programming Systems [http://en.wikipedia.org/wiki/Object-oriented_programming]. For instance in a software solution to manage the order and inventory systems of a company, the objects that are part of the systems e.g orders, customers, must be accessible even if the system was temporarily shut down for a while. ORM [http://en.wikipedia.org/wiki/Object-relational_mapping] helps in achieving this very essential requirement by bringing the database into the picture, more specifically bringing the RDBMS into the picture.

== Why ORM, why not another solution? ==
The answer to this is quite an obvious one. ORM brings to the table something(s) that another solution hasn’t done so far. These “something(s)” that ORM contributes are listed below:
#Alleviates the problem that hinders a transition from one database provider to another database vendor or even another database product.
#Enables to perform most of the database operations (mainly CRUD[http://en.wikipedia.org/wiki/Create,_read,_update_and_delete]) without having to write any SQL [http://en.wikipedia.org/wiki/SQL] statements, thereby permitting a shift from one SQL dialect to another. This also allows the software solutions to focus more on the actual problem being solved rather that performing supplementary functions extensively.

==Flavors of ORM solutions.==
The term ORM is a very generic name for the class of solutions. Typically, ORM support in object oriented languages comes in two flavors; one that comes in separate packages which can be imported into our application, the other is the variety that comes incorporated into a language.
When there is an option of choosing among the two flavors, the solution that come incorporated into the language is preferred. This choice may be quite an obvious one depending on the language that is being considered.
Though the difference between the two might not be that apparent in the outset, the reason for this predilection towards the language incorporate solution over the other has mainly to do with design paradigm of the modern day software development of “convention over configuration”[http://en.wikipedia.org/wiki/Convention_over_configuration]. This paradigm emphasizes on the development by convention rather than development by configuration. The fact that the solution involving external packages and libraries involve a lot of configuration files which play the instructing role. In the language incorporated solution, such a problem doesn’t arise as the involvement of configuration files in the entire system itself is scanty. In the following sections we will take a look at two of the preferred language incorporated solutions.

==ORM implementation in specific languages.==
In this section, we will look at the language specific ORM examples illustrating the relation between creation of classes and tables, objects and rows, attributes and columns; and also examples for performing basic CRUD operations for two specific Object Oriented languages.
===Groovy, Grails and GROM:===
====Creating classes and tables:====
Classes, when created using the create-domain-class, also create the table of the same name as the class (not the plural).
For example,
grails create-domain-class Assignment
running the above command would create an empty class named Assignment and also create a table named Assignment in the database. Attributes to this class may be added in a fashion similar to the one followed in java. The attributes that are created in-turn gets automatically mapped to the columns in the table “Assignment”.

We may want to define the Assignment class as follows
class Assignment {
String title
Date dueDate
String weightage_on_final_grade
}
Having objects defined within a class would facilitate in achieving association between classes.

====Basic CRUD:====
:Creating objects also creates rows. This is done as illustrated below:
def a = new Assignment (title:"WikiTextChapter", dueDate:date, weightage_on_final_grade:3)
a.save()

The above statements would create a new Assignment object and also create a row in the Assignment table. The save method above may be considered analogous to a commit statement that may be used in SQL.
:Reading objects from the database. This can be done as in the below example.
def a = Assignment.get(1)
In the above statement, the parameter 1 passed to the get method is an identifier for the object. When an object is created in the database, an id is created transparently by the language specifics.
Apart from the get method, other ways of fetching objects from database would involve use of methods such as list(), findBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. This is achieved by updating the necessary attribute of an object and saving or committing the changes back to the database. This is illustrated in the below example.
def a = Assignment.get(1)
a. weightage_on_final_grade =5
a.save()
:Deleting objects. To perform a delete, we must first get an object and then call the delete method on that object. This is illustrated in the below example.
def a = Assignment.get(1)
a.delete()

===PHP ActiveRecord:===
====Creating classes and tables:====
Tables corresponding to classes can be created by
classes extending the ActiveRecord\Model class.
class Assignment extends ActiveRecord\Model
{
}
====Basic CRUD:====
:Creating objects also creates rows. This can be done by as shown below.
$a = new Assignment();
$a-> title=’ WikiTextChapter’;
$a->save();
:Reading objects from database. Objects can be read from the database as illustrated in the below example.
$a = Assignment::find(1);
::Apart from the get method, other ways of fetching objects from database would involve use of methods such as findBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. For this to be done, we need to find a record first and then change one of its attributes and finally commit the changes. This is illustrated below:
$a = Assignment::find(1);
$a->title = 'NewWikiTextChapter’';
$a->save();
:Deleting objects. For this to be done, we need to find a record first and then call the delete method on the object.
$a = Assignment::find(1);
$a->delete();
:This is similar to ActiveRecord in Ruby, so we will not explicitly deal with ORM in Ruby.

==Language support for ORM.==
To incorporate ORM into a language, the usual approach, is to implement the ActiveRecord Design Pattern [http://en.wikipedia.org/wiki/Active_record_pattern]. This approach considers persistence as a responsibility of the object rather than as a service. Following this approach, would hence expect the objects themselves implement methods to support database operations and like in the object oriented world the objects are expected to be able to manage themselves. Following the object oriented paradigm and adopting a modular approach the responsibility of implementing the methods facilitating the database operations are implemented by a class which is inherited by all other classes whose objects have to persist across sessions. The methods to support database operations include methods to create tables, create rows in the table when objects of a class are created; methods to read objects from the table; methods that facilitate updating the objects and finally methods to delete the objects. Apart from this basic CRUD functionality any extra functionality would always be welcome.

==References and Further Reading==
*Very informative and a nice place to start. http://www.slideshare.net/hominhchuc/grails-docs-presentation
*Insight into impedance mismatch. http://www.agiledata.org/essays/impedanceMismatch.html
*List of object-relational mapping software http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
*Active Record Design Pattern - Domain Driven Design and Domain Layer - Object Persistence. http://davidhayden.com/blog/dave/archive/2006/06/10/2984.aspx
*Grails home page. http://grails.org/
*ORM in php: php.active record http://www.phpactiverecord.org/
*Active Record Design Pattern http://en.wikipedia.org/wiki/Active_record_pattern

CSC/ECE 517 Fall 2010/ch2 2a aa

2010-09-30T03:42:09Z

Aamarna2:

[Language extensions for ORM]

== Introduction to Object Relational Mapping. ==
Object Relational Mapping is a technique of mapping the solution entities of an object oriented system, [http://en.wikipedia.org/wiki/Object_%28computer_science%29]objects to [http://en.wikipedia.org/wiki/Relational_database_management_system] relational database tables. This technique came into existence as an answer to the problem of lack of persistence of objects across session in [http://en.wikipedia.org/wiki/Object-oriented_programming]Object Oriented Programming Systems. For instance in a software solution to manage the order and inventory systems of a company, the objects that are part of the systems e.g orders, customers, must be accessible even if the system was temporarily shut down for a while. [http://en.wikipedia.org/wiki/Object-relational_mapping]ORM helps in achieving this very essential requirement by bringing the database into the picture, more specifically bringing the RDBMS into the picture.

== Why ORM, why not another solution? ==
The answer to this is quite an obvious one. ORM brings to the table something(s) that another solution hasn’t done so far. These “something(s)” that ORM contributes are listed below:
#Alleviates the problem that hinders a transition from one database provider to another database vendor or even another database product.
#Enables to perform most of the database operations ([http://en.wikipedia.org/wiki/Create,_read,_update_and_delete]mainly CRUD) without having to write any [http://en.wikipedia.org/wiki/SQL]SQL statements, thereby permitting a shift from one SQL dialect to another. This also allows the software solutions to focus more on the actual problem being solved rather that performing supplementary functions extensively.

==Flavors of ORM solutions.==
The term ORM is a very generic name for the class of solutions. Typically, ORM support in object oriented languages comes in two flavors; one that comes in separate packages which can be imported into our application, the other is the variety that comes incorporated into a language.
When there is an option of choosing among the two flavors, the solution that come incorporated into the language is preferred. This choice may be quite an obvious one depending on the language that is being considered.
Though the difference between the two might not be that apparent in the outset, the reason for this predilection towards the language incorporate solution over the other has mainly to do with design paradigm of the modern day software development of [http://en.wikipedia.org/wiki/Convention_over_configuration]“convention over configuration”. This paradigm emphasizes on the development by convention rather than development by configuration. The fact that the solution involving external packages and libraries involve a lot of configuration files which play the instructing role. In the language incorporated solution, such a problem doesn’t arise as the involvement of configuration files in the entire system itself is scanty. In the following sections we will take a look at two of the preferred language incorporated solutions.

==ORM implementation in specific languages.==
In this section, we will look at the language specific ORM examples illustrating the relation between creation of classes and tables, objects and rows, attributes and columns; and also examples for performing basic CRUD operations for two specific Object Oriented languages.
===Groovy, Grails and GROM:===
====Creating classes and tables:====
Classes, when created using the create-domain-class, also create the table of the same name as the class (not the plural).
For example,
grails create-domain-class Assignment
running the above command would create an empty class named Assignment and also create a table named Assignment in the database. Attributes to this class may be added in a fashion similar to the one followed in java. The attributes that are created in-turn gets automatically mapped to the columns in the table “Assignment”.

We may want to define the Assignment class as follows
class Assignment {
String title
Date dueDate
String weightage_on_final_grade
}
Having objects defined within a class would facilitate in achieving association between classes.

====Basic CRUD:====
:Creating objects also creates rows. This is done as illustrated below:
def a = new Assignment (title:"WikiTextChapter", dueDate:date, weightage_on_final_grade:3)
a.save()

The above statements would create a new Assignment object and also create a row in the Assignment table. The save method above may be considered analogous to a commit statement that may be used in SQL.
:Reading objects from the database. This can be done as in the below example.
def a = Assignment.get(1)
In the above statement, the parameter 1 passed to the get method is an identifier for the object. When an object is created in the database, an id is created transparently by the language specifics.
Apart from the get method, other ways of fetching objects from database would involve use of methods such as list(), findBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. This is achieved by updating the necessary attribute of an object and saving or committing the changes back to the database. This is illustrated in the below example.
def a = Assignment.get(1)
a. weightage_on_final_grade =5
a.save()
:Deleting objects. To perform a delete, we must first get an object and then call the delete method on that object. This is illustrated in the below example.
def a = Assignment.get(1)
a.delete()

===PHP ActiveRecord:===
====Creating classes and tables:====
Tables corresponding to classes can be created by
classes extending the ActiveRecord\Model class.
class Assignment extends ActiveRecord\Model
{
}
====Basic CRUD:====
:Creating objects also creates rows. This can be done by as shown below.
$a = new Assignment();
$a-> title=’ WikiTextChapter’;
$a->save();
:Reading objects from database. Objects can be read from the database as illustrated in the below example.
$a = Assignment::find(1);
::Apart from the get method, other ways of fetching objects from database would involve use of methods such as findBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. For this to be done, we need to find a record first and then change one of its attributes and finally commit the changes. This is illustrated below:
$a = Assignment::find(1);
$a->title = 'NewWikiTextChapter’';
$a->save();
:Deleting objects. For this to be done, we need to find a record first and then call the delete method on the object.
$a = Assignment::find(1);
$a->delete();
:This is similar to ActiveRecord in Ruby, so we will not explicitly deal with ORM in Ruby.

==Language support for ORM.==
To incorporate ORM into a language, the usual approach, is to implement the ActiveRecord Design Pattern [http://en.wikipedia.org/wiki/Active_record_pattern]. This approach considers persistence as a responsibility of the object rather than as a service. Following this approach, would hence expect the objects themselves implement methods to support database operations and like in the object oriented world the objects are expected to be able to manage themselves. Following the object oriented paradigm and adopting a modular approach the responsibility of implementing the methods facilitating the database operations are implemented by a class which is inherited by all other classes whose objects have to persist across sessions. The methods to support database operations include methods to create tables, create rows in the table when objects of a class are created; methods to read objects from the table; methods that facilitate updating the objects and finally methods to delete the objects. Apart from this basic CRUD functionality any extra functionality would always be welcome.

==References and Further Reading==
*Very informative and a nice place to start. http://www.slideshare.net/hominhchuc/grails-docs-presentation
*Insight into impedance mismatch. http://www.agiledata.org/essays/impedanceMismatch.html
*List of object-relational mapping software http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
*Active Record Design Pattern - Domain Driven Design and Domain Layer - Object Persistence. http://davidhayden.com/blog/dave/archive/2006/06/10/2984.aspx
*Grails home page. http://grails.org/
*ORM in php: php.active record http://www.phpactiverecord.org/
*Active Record Design Pattern http://en.wikipedia.org/wiki/Active_record_pattern

CSC/ECE 517 Fall 2010/ch2 2a aa

2010-09-30T03:30:03Z

Aamarna2:

[Language extensions for ORM]

== Introduction to Object Relational Mapping. ==
Object Relational Mapping is a technique of mapping the solution entities of an object oriented system, [http://en.wikipedia.org/wiki/Object_%28computer_science%29]objects to [http://en.wikipedia.org/wiki/Relational_database_management_system] relational database tables. This technique came into existence as an answer to the problem of lack of persistence of objects across session in [http://en.wikipedia.org/wiki/Object-oriented_programming]Object Oriented Programming Systems. For instance in a software solution to manage the order and inventory systems of a company, the objects that are part of the systems e.g orders, customers, must be accessible even if the system was temporarily shut down for a while. [http://en.wikipedia.org/wiki/Object-relational_mapping]ORM helps in achieving this very essential requirement by bringing the database into the picture, more specifically bringing the RDBMS into the picture.

== Why ORM, why not another solution? ==
The answer to this is quite an obvious one. ORM brings to the table something(s) that another solution hasn’t done so far. These “something(s)” that ORM contributes are listed below:
#Alleviates the problem that hinders a transition from one database provider to another database vendor or even another database product.
#Enables to perform most of the database operations ([http://en.wikipedia.org/wiki/Create,_read,_update_and_delete]mainly CRUD) without having to write any [http://en.wikipedia.org/wiki/SQL]SQL statements, thereby permitting a shift from one SQL dialect to another. This also allows the software solutions to focus more on the actual problem being solved rather that performing supplementary functions extensively.

==Flavors of ORM solutions.==
The term ORM is a very generic name for the class of solutions. Typically, ORM support in object oriented languages comes in two flavors; one that comes in separate packages which can be imported into our application, the other is the variety that comes incorporated into a language.
When there is an option of choosing among the two flavors, the solution that come incorporated into the language is preferred. This choice may be quite an obvious one depending on the language that is being considered.
Though the difference between the two might not be that apparent in the outset, the reason for this predilection towards the language incorporate solution over the other has mainly to do with design paradigm of the modern day software development of [http://en.wikipedia.org/wiki/Convention_over_configuration]“convention over configuration”. This paradigm emphasizes on the development by convention rather than development by configuration. The fact that the solution involving external packages and libraries involve a lot of configuration files which play the instructing role. In the language incorporated solution, such a problem doesn’t arise as the involvement of configuration files in the entire system itself is scanty. In the following sections we will take a look at two of the preferred language incorporated solutions.

==ORM implementation in specific languages.==
In this section, we will look at the language specific ORM examples illustrating the relation between creation of classes and tables, objects and rows, attributes and columns; and also examples for performing basic CRUD operations for two specific Object Oriented languages.
===Groovy, Grails and GROM:===
====Creating classes and tables:====
Classes, when created using the create-domain-class, also create the table of the same name as the class (not the plural).
For example,
grails create-domain-class Assignment
running the above command would create an empty class named Assignment and also create a table named Assignment in the database. Attributes to this class may be added in a fashion similar to the one followed in java. The attributes that are created in-turn gets automatically mapped to the columns in the table “Assignment”.

We may want to define the Assignment class as follows
class Assignment {
String title
Date dueDate
String weightage_on_final_grade
}
Having objects defined within a class would facilitate in achieving association between classes.

====Basic CRUD:====
:Creating objects also creates rows. This is done as illustrated below:
def a = new Assignment (title:"WikiTextChapter", dueDate:date, weightage_on_final_grade:3)
a.save()

The above statements would create a new Assignment object and also create a row in the Assignment table. The save method above may be considered analogous to a commit statement that may be used in SQL.
:Reading objects from the database. This can be done as in the below example.
def a = Assignment.get(1)
In the above statement, the parameter 1 passed to the get method is an identifier for the object. When an object is created in the database, an id is created transparently by the language specifics.
Apart from the get method, other ways of fetching objects from database would involve use of methods such as list(), findBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. This is achieved by updating the necessary attribute of an object and saving or committing the changes back to the database. This is illustrated in the below example.
def a = Assignment.get(1)
a. weightage_on_final_grade =5
a.save()
:Deleting objects. To perform a delete, we must first get an object and then call the delete method on that object. This is illustrated in the below example.
def a = Assignment.get(1)
a.delete()

===PHP ActiveRecord:===
====Creating classes and tables:====
Tables corresponding to classes can be created by
classes extending the ActiveRecord\Model class.
class Assignment extends ActiveRecord\Model
{
}
====Basic CRUD:====
:Creating objects also creates rows. This can be done by as shown below.
$a = new Assignment();
$a-> title=’ WikiTextChapter’;
$a->save();
:Reading objects from database. Objects can be read from the database as illustrated in the below example.
$a = Assignment::find(1);
::Apart from the get method, other ways of fetching objects from database would involve use of methods such as findBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. For this to be done, we need to find a record first and then change one of its attributes and finally commit the changes. This is illustrated below:
$a = Assignment::find(1);
$a->title = 'NewWikiTextChapter’';
$a->save();
:Deleting objects. For this to be done, we need to find a record first and then call the delete method on the object.
$a = Assignment::find(1);
$a->delete();
:This is similar to ActiveRecord in Ruby, so we will not explicitly deal with ORM in Ruby.

[[Image:Image.png]]

==Language support for ORM.==
To incorporate ORM into a language, the usual approach, is to implement the ActiveRecord Design Pattern [http://en.wikipedia.org/wiki/Active_record_pattern]. This approach considers persistence as a responsibility of the object rather than as a service. Following this approach, would hence expect the objects themselves implement methods to support database operations and like in the object oriented world the objects are expected to be able to manage themselves. Following the object oriented paradigm and adopting a modular approach the responsibility of implementing the methods facilitating the database operations are implemented by a class which is inherited by all other classes whose objects have to persist across sessions. The methods to support database operations include methods to create tables, create rows in the table when objects of a class are created; methods to read objects from the table; methods that facilitate updating the objects and finally methods to delete the objects. Apart from this basic CRUD functionality any extra functionality would always be welcome.

==References and Further Reading==
*Very informative and a nice place to start. http://www.slideshare.net/hominhchuc/grails-docs-presentation
*Insight into impedance mismatch. http://www.agiledata.org/essays/impedanceMismatch.html
*List of object-relational mapping software http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
*Active Record Design Pattern - Domain Driven Design and Domain Layer - Object Persistence. http://davidhayden.com/blog/dave/archive/2006/06/10/2984.aspx
*Grails home page. http://grails.org/
*ORM in php: php.active record http://www.phpactiverecord.org/
*Active Record Design Pattern http://en.wikipedia.org/wiki/Active_record_pattern

CSC/ECE 517 Fall 2010/ch2 2a aa

2010-09-30T03:22:04Z

Aamarna2:

[Language extensions for ORM]

== Introduction to Object Relational Mapping. ==
Object Relational Mapping is a technique of mapping the solution entities of an object oriented system, [http://en.wikipedia.org/wiki/Object_%28computer_science%29]objects to [http://en.wikipedia.org/wiki/Relational_database_management_system] relational database tables. This technique came into existence as an answer to the problem of lack of persistence of objects across session in [http://en.wikipedia.org/wiki/Object-oriented_programming]Object Oriented Programming Systems. For instance in a software solution to manage the order and inventory systems of a company, the objects that are part of the systems e.g orders, customers, must be accessible even if the system was temporarily shut down for a while. [http://en.wikipedia.org/wiki/Object-relational_mapping]ORM helps in achieving this very essential requirement by bringing the database into the picture, more specifically bringing the RDBMS into the picture.

== Why ORM, why not another solution? ==
The answer to this is quite an obvious one. ORM brings to the table something(s) that another solution hasn’t done so far. These “something(s)” that ORM contributes are listed below:
#Alleviates the problem that hinders a transition from one database provider to another database vendor or even another database product.
#Enables to perform most of the database operations ([http://en.wikipedia.org/wiki/Create,_read,_update_and_delete]mainly CRUD) without having to write any [http://en.wikipedia.org/wiki/SQL]SQL statements, thereby permitting a shift from one SQL dialect to another. This also allows the software solutions to focus more on the actual problem being solved rather that performing supplementary functions extensively.

==Flavors of ORM solutions.==
The term ORM is a very generic name for the class of solutions. Typically, ORM support in object oriented languages comes in two flavors; one that comes in separate packages which can be imported into our application, the other is the variety that comes incorporated into a language.
When there is an option of choosing among the two flavors, the solution that come incorporated into the language is preferred. This choice may be quite an obvious one depending on the language that is being considered.
Though the difference between the two might not be that apparent in the outset, the reason for this predilection towards the language incorporate solution over the other has mainly to do with design paradigm of the modern day software development of [http://en.wikipedia.org/wiki/Convention_over_configuration]“convention over configuration”. This paradigm emphasizes on the development by convention rather than development by configuration. The fact that the solution involving external packages and libraries involve a lot of configuration files which play the instructing role. In the language incorporated solution, such a problem doesn’t arise as the involvement of configuration files in the entire system itself is scanty. In the following sections we will take a look at two of the preferred language incorporated solutions.

==ORM implementation in specific languages.==
In this section, we will look at the language specific ORM examples illustrating the relation between creation of classes and tables, objects and rows, attributes and columns; and also examples for performing basic CRUD operations for the four OO languages.
===Groovy, Grails and GROM:===
====Creating classes and tables:====
Classes, when created using the create-domain-class, also create the table of the same name as the class (not the plural).
For example,
grails create-domain-class Assignment
running the above command would create an empty class named Assignment and also create a table named Assignment in the database. Attributes to this class may be added in a fashion similar to the one followed in java. The attributes that are created in-turn gets automatically mapped to the columns in the table “Assignment”.

We may want to define the Assignment class as follows
class Assignment {
String title
Date dueDate
String weightage_on_final_grade
}
Having objects defined within a class would facilitate in achieving association between classes.

====Basic CRUD:====
:Creating objects also creates rows. This is done as illustrated below:
def a = new Assignment (title:"WikiTextChapter", dueDate:date, weightage_on_final_grade:3)
a.save()

The above statements would create a new A
ssignment object and also create a row in the Assignment table. The save method above may be considered analogous to a commit statement that may be used in SQL.
:Reading objects from the database. This can be done as in the below example.
def a = Assignment.get(1)
In the above statement, the parameter 1 passed to the get method is an identifier for the object. When an object is created in the database, an id is created transparently by the language specifics.
Apart from the get method, other ways of fetching objects from database would involve use of methods such as list(), finfBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. This is achieved by updating the necessary attribute of an object and saving or committing the changes back to the database. This is illustrated in the below example.
def a = Assignment.get(1)
a. weightage_on_final_grade =5
a.save()
:Deleting objects. To perform a delete, we must first get an object and then call the delete method on that object. This is illustrated in the below example.
def a = Assignment.get(1)
a.delete()

===PHP ActiveRecord:===
====Creating classes and tables:====
Tables corresponding to classes can be created by
classes extending the ActiveRecord\Model class.
class Assignment extends ActiveRecord\Model
{
}
====Basic CRUD:====
:Creating objects also creates rows. This can be done by as shown below.
$a = new Assignment();
$a-> title=’ WikiTextChapter’;
$a->save();
:Reading objects from database. Objects can be read from the database as illustrated in the below example.
$a = Assignment::find(1);
::Apart from the get method, other ways of fetching objects from database would involve use of methods such as finfBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. For this to be done, we need to find a record first and then change one of its attributes and finally commit the changes. This is illustrated below:
$a = Assignment::find(1);
$a->title = 'NewWikiTextChapter’';
$a->save();
:Deleting objects. For this to be done, we need to find a record first and then call the delete method on the object.
$a = Assignment::find(1);
$a->delete();
:This is similar to ActiveRecord in Ruby, so we will not explicitly deal with ORM in Ruby.

[[Image:Image.png]]

==Incorporating ORM into the language.==
To incorporate ORM into a language, the usual approach, is to implement the ActiveRecord Design Pattern [http://en.wikipedia.org/wiki/Active_record_pattern]. This approach considers persistence as a responsibility rather than as a service. Following this approach, would hence expect the objects themselves implement methods to support database operations and like in the object oriented world the objects are expected to be able to manage themselves. Following the object oriented paradigm and adopting a modular approach the responsibility of implementing the methods facilitating the database operations are implemented by a class which is inherited by all other classes whose objects have to persist across sessions. The methods to support database operations include methods to create tables, create rows in the table when objects of a class are created; methods to read objects from the table; methods that facilitate updating the objects and finally methods to delete the objects. Apart from this basic CRUD functionality any extra functionality would always be welcome.

==References and Further Reading==
*Very informative and a nice place to start. http://www.slideshare.net/hominhchuc/grails-docs-presentation
*Insight into impedance mismatch. http://www.agiledata.org/essays/impedanceMismatch.html
*List of object-relational mapping software http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
*Active Record Design Pattern - Domain Driven Design and Domain Layer - Object Persistence. http://davidhayden.com/blog/dave/archive/2006/06/10/2984.aspx
*Grails home page. http://grails.org/
*ORM in php: php.active record http://www.phpactiverecord.org/
*Active Record Design Pattern http://en.wikipedia.org/wiki/Active_record_pattern

CSC/ECE 517 Fall 2010/ch2 2a aa

2010-09-30T03:20:16Z

Aamarna2: /* Introduction to Object Relational Mapping. */

[Language extensions for ORM]

== Introduction to Object Relational Mapping. ==
Object Relational Mapping is a technique of mapping the solution entities of an object oriented system, [http://en.wikipedia.org/wiki/Object_%28computer_science%29]objects to [http://en.wikipedia.org/wiki/Relational_database_management_system] relational database tables. This technique came into existence as an answer to the problem of lack of persistence of objects across session in [http://en.wikipedia.org/wiki/Object-oriented_programming]Object Oriented Programming Systems. For instance in a software solution to manage the order and inventory systems of a company, the objects that are part of the systems e.g orders, customers, must be accessible even if the system was temporarily shut down for a while. [http://en.wikipedia.org/wiki/Object-relational_mapping]ORM helps in achieving this very essential requirement by bringing the database into the picture, more specifically bringing the RDBMS into the picture.

== Why ORM, why not another solution? ==
The answer to this is quite an obvious one. ORM brings to the table something(s) that another solution hasn’t done so far. These “something(s)” that ORM contributes are listed below:
#Alleviates the problem that hinders a transition from one database provider to another database vendor or even another database product.
#Enables to perform most of the database operations ([http://en.wikipedia.org/wiki/Create,_read,_update_and_delete]mainly CRUD) without having to write any [http://en.wikipedia.org/wiki/SQL]SQL statements, thereby permitting a shift from one SQL dialect to another. This also allows the software solutions to focus more on the actual problem being solved rather that performing supplementary functions extensively.

==Flavors of ORM solutions.==
The term ORM is a very generic name for the class of solutions. Typically, ORM support in object oriented languages comes in two flavors; one that comes in separate packages which can be imported into our application, the other is the variety that comes incorporated into a language.
When there is an option of choosing among the two flavors, the solution that come incorporated into the language is preferred. This choice may be quite an obvious one depending on the language that is being considered.
Though the difference between the two might not be that apparent in the outset, the reason for this predilection towards the language incorporate solution over the other has mainly to do with design paradigm of the modern day software development of [http://en.wikipedia.org/wiki/Convention_over_configuration]“convention over configuration”. This paradigm emphasizes on the development by convention rather than development by configuration. The fact that the solution involving external packages and libraries involve a lot of configuration files which play the instructing role. In the language incorporated solution, such a problem doesn’t arise as the involvement of configuration files in the entire system itself is scanty. In the following sections we will take a look at two of the preferred language incorporated solutions.

==ORM implementation in specific languages.==
In this section, we will look at the language specific ORM examples illustrating the relation between creation of classes and tables, objects and rows, attributes and columns; and also examples for performing basic CRUD operations for the four OO languages.
===Groovy, Grails and GROM:===
====Creating classes and tables:====
Classes, when created using the create-domain-class, also create the table of the same name as the class (not the plural).
For example,
grails create-domain-class Assignment
running the above command would create an empty class named Assignment and also create a table named Assignment in the database. Attributes to this class may be added in a fashion similar to the one followed in java. The attributes that are created in-turn gets automatically mapped to the columns in the table “Assignment”.

We may want to define the Assignment class as follows
class Assignment {
String title
Date dueDate
String weightage_on_final_grade
}
Having objects defined within a class would facilitate in achieving association between classes.

====Basic CRUD:====
:Creating objects also creates rows. This is done as illustrated below:
def a = new Assignment (title:"WikiTextChapter", dueDate:date, weightage_on_final_grade:3)
a.save()

The above statements would create a new A
ssignment object and also create a row in the Assignment table. The save method above may be considered analogous to a commit statement that may be used in SQL.
:Reading objects from the database. This can be done as in the below example.
def a = Assignment.get(1)
In the above statement, the parameter 1 passed to the get method is an identifier for the object. When an object is created in the database, an id is created transparently by the language specifics.
Apart from the get method, other ways of fetching objects from database would involve use of methods such as list(), finfBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. This is achieved by updating the necessary attribute of an object and saving or committing the changes back to the database. This is illustrated in the below example.
def a = Assignment.get(1)
a. weightage_on_final_grade =5
a.save()
:Deleting objects. To perform a delete, we must first get an object and then call the delete method on that object. This is illustrated in the below example.
def a = Assignment.get(1)
a.delete()

===PHP ActiveRecord:===
====Creating classes and tables:====
Tables corresponding to classes can be created by
classes extending the ActiveRecord\Model class.
class Assignment extends ActiveRecord\Model
{
}
====Basic CRUD:====
:Creating objects also creates rows. This can be done by as shown below.
$a = new Assignment();
$a-> title=’ WikiTextChapter’;
$a->save();
:Reading objects from database. Objects can be read from the database as illustrated in the below example.
$a = Assignment::find(1);
::Apart from the get method, other ways of fetching objects from database would involve use of methods such as finfBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. For this to be done, we need to find a record first and then change one of its attributes and finally commit the changes. This is illustrated below:
$a = Assignment::find(1);
$a->title = 'NewWikiTextChapter’';
$a->save();
:Deleting objects. For this to be done, we need to find a record first and then call the delete method on the object.
$a = Assignment::find(1);
$a->delete();
:This is similar to ActiveRecord in Ruby, so we will not explicitly deal with ORM in Ruby.

[[Image:Image.png]]

==Incorporating ORM into the language.==
To incorporate ORM into a language, the usual approach, is to implement the ActiveRecord Design Pattern [http://en.wikipedia.org/wiki/Active_record_pattern]. This approach considers persistence as a responsibility rather than as a service. Following this approach, would hence expect the objects themselves implement methods to support database operations and like in the object oriented world the objects are expected to be able to manage themselves. Following the object oriented paradigm and adopting a modular approach the responsibility of implementing the methods facilitating the database operations are implemented by a class which is inherited by all other classes whose objects have to persist across sessions. The methods to support database operations include methods to create tables, create rows in the table when objects of a class are created; methods to read objects from the table; methods that facilitate updating the objects and finally methods to delete the objects. Apart from this basic CRUD functionality any extra functionality would always be welcome.

==References and Further Reading==
*Very informative and a nice place to start. http://www.slideshare.net/hominhchuc/grails-docs-presentation
*Insight into impedance mismatch. http://www.agiledata.org/essays/impedanceMismatch.html
*List of object-relational mapping software http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
----
==External links==
*Active Record Design Pattern - Domain Driven Design and Domain Layer - Object Persistence. http://davidhayden.com/blog/dave/archive/2006/06/10/2984.aspx
*Grails home page. http://grails.org/
*ORM in php: php.active record http://www.phpactiverecord.org/
*Active Record Design Pattern http://en.wikipedia.org/wiki/Active_record_pattern

CSC/ECE 517 Fall 2010/ch2 2a aa

2010-09-28T16:27:57Z

Aamarna2:

[Language extensions for ORM]

== Introduction to Object Relational Mapping. ==
Object Relational Mapping is a technique of mapping the solution entities of an object oriented system, [http://en.wikipedia.org/wiki/Object_%28computer_science%29]objects to [http://en.wikipedia.org/wiki/Relational_database_management_system] relational database tables. This technique came into existence as an answer to the problem of lack of persistence of objects across session in [http://en.wikipedia.org/wiki/Object-oriented_programming]Object Oriented Programming Systems. For instance in a software solution to manage the order and inventory systems of a company, the objects that are part of the systems (orders, customers . . .) must be accessible even if the system was temporarily shut down for a while. [http://en.wikipedia.org/wiki/Object-relational_mapping]ORM helps in achieving this very essential requirement by bringing the database into the picture, more specifically bringing the RDBMS into the picture.

== Why ORM, why not another solution? ==
The answer to this is quite an obvious one. ORM brings to the table something(s) that another solution hasn’t done so far. These “something(s)” that ORM contributes are listed below:
#Alleviates the problem that hinders a transition from one database provider to another database vendor or even another database product.
#Enables to perform most of the database operations ([http://en.wikipedia.org/wiki/Create,_read,_update_and_delete]mainly CRUD) without having to write any [http://en.wikipedia.org/wiki/SQL]SQL statements, thereby permitting a shift from one SQL dialect to another. This also allows the software solutions to focus more on the actual problem being solved rather that performing supplementary functions extensively.

==Flavors of ORM solutions.==
The term ORM is a very generic name for the class of solutions. Typically, ORM support in object oriented languages comes in two flavors; one that comes in separate packages which can be imported into our application, the other is the variety that comes incorporated into a language.
When there is an option of choosing among the two flavors, the solution that come incorporated into the language is preferred. This choice may be quite an obvious one depending on the language that is being considered.
Though the difference between the two might not be that apparent in the outset, the reason for this predilection towards the language incorporate solution over the other has mainly to do with design paradigm of the modern day software development of [http://en.wikipedia.org/wiki/Convention_over_configuration]“convention over configuration”. This paradigm emphasizes on the development by convention rather than development by configuration. The fact that the solution involving external packages and libraries involve a lot of configuration files which play the instructing role. In the language incorporated solution, such a problem doesn’t arise as the involvement of configuration files in the entire system itself is scanty. In the following sections we will take a look at two of the preferred language incorporated solutions.

==ORM implementation in specific languages.==
In this section, we will look at the language specific ORM examples illustrating the relation between creation of classes and tables, objects and rows, attributes and columns; and also examples for performing basic CRUD operations for the four OO languages.
===Groovy, Grails and GROM:===
====Creating classes and tables:====
Classes, when created using the create-domain-class, also create the table of the same name as the class (not the plural).
For example,
grails create-domain-class Assignment
running the above command would create an empty class named Assignment and also create a table named Assignment in the database. Attributes to this class may be added in a fashion similar to the one followed in java. The attributes that are created in-turn gets automatically mapped to the columns in the table “Assignment”.

We may want to define the Assignment class as follows
class Assignment {
String title
Date dueDate
String weightage_on_final_grade
}
Having objects defined within a class would facilitate in achieving association between classes.

====Basic CRUD:====
:Creating objects also creates rows. This is done as illustrated below:
def a = new Assignment (title:"WikiTextChapter", dueDate:date, weightage_on_final_grade:3)
a.save()

The above statements would create a new A
ssignment object and also create a row in the Assignment table. The save method above may be considered analogous to a commit statement that may be used in SQL.
:Reading objects from the database. This can be done as in the below example.
def a = Assignment.get(1)
In the above statement, the parameter 1 passed to the get method is an identifier for the object. When an object is created in the database, an id is created transparently by the language specifics.
Apart from the get method, other ways of fetching objects from database would involve use of methods such as list(), finfBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. This is achieved by updating the necessary attribute of an object and saving or committing the changes back to the database. This is illustrated in the below example.
def a = Assignment.get(1)
a. weightage_on_final_grade =5
a.save()
:Deleting objects. To perform a delete, we must first get an object and then call the delete method on that object. This is illustrated in the below example.
def a = Assignment.get(1)
a.delete()

===PHP ActiveRecord:===
====Creating classes and tables:====
Tables corresponding to classes can be created by
classes extending the ActiveRecord\Model class.
class Assignment extends ActiveRecord\Model
{
}
====Basic CRUD:====
:Creating objects also creates rows. This can be done by as shown below.
$a = new Assignment();
$a-> title=’ WikiTextChapter’;
$a->save();
:Reading objects from database. Objects can be read from the database as illustrated in the below example.
$a = Assignment::find(1);
::Apart from the get method, other ways of fetching objects from database would involve use of methods such as finfBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. For this to be done, we need to find a record first and then change one of its attributes and finally commit the changes. This is illustrated below:
$a = Assignment::find(1);
$a->title = 'NewWikiTextChapter’';
$a->save();
:Deleting objects. For this to be done, we need to find a record first and then call the delete method on the object.
$a = Assignment::find(1);
$a->delete();
:This is similar to ActiveRecord in Ruby, so we will not explicitly deal with ORM in Ruby.

[[Image:Image.png]]

==Incorporating ORM into the language.==
To incorporate ORM into a language, the usual approach, is to implement the ActiveRecord Design Pattern [http://en.wikipedia.org/wiki/Active_record_pattern]. This approach considers persistence as a responsibility rather than as a service. Following this approach, would hence expect the objects themselves implement methods to support database operations and like in the object oriented world the objects are expected to be able to manage themselves. Following the object oriented paradigm and adopting a modular approach the responsibility of implementing the methods facilitating the database operations are implemented by a class which is inherited by all other classes whose objects have to persist across sessions. The methods to support database operations include methods to create tables, create rows in the table when objects of a class are created; methods to read objects from the table; methods that facilitate updating the objects and finally methods to delete the objects. Apart from this basic CRUD functionality any extra functionality would always be welcome.

==References and Further Reading==
*Very informative and a nice place to start. http://www.slideshare.net/hominhchuc/grails-docs-presentation
*Insight into impedance mismatch. http://www.agiledata.org/essays/impedanceMismatch.html
*List of object-relational mapping software http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
----
==External links==
*Active Record Design Pattern - Domain Driven Design and Domain Layer - Object Persistence. http://davidhayden.com/blog/dave/archive/2006/06/10/2984.aspx
*Grails home page. http://grails.org/
*ORM in php: php.active record http://www.phpactiverecord.org/
*Active Record Design Pattern http://en.wikipedia.org/wiki/Active_record_pattern

CSC/ECE 517 Fall 2010/ch2 2a aa

2010-09-28T16:26:31Z

Aamarna2:

[Language extensions for ORM]

== Introduction to Object Relational Mapping. ==
Object Relational Mapping is a technique of mapping the solution entities of an object oriented system, [http://en.wikipedia.org/wiki/Object_%28computer_science%29]objects to [http://en.wikipedia.org/wiki/Relational_database_management_system] relational database tables. This technique came into existence as an answer to the problem of lack of persistence of objects across session in [http://en.wikipedia.org/wiki/Object-oriented_programming]Object Oriented Programming Systems. For instance in a software solution to manage the order and inventory systems of a company, the objects that are part of the systems (orders, customers . . .) must be accessible even if the system was temporarily shut down for a while. [http://en.wikipedia.org/wiki/Object-relational_mapping]ORM helps in achieving this very essential requirement by bringing the database into the picture, more specifically bringing the RDBMS into the picture.

== Why ORM, why not another solution? ==
The answer to this is quite an obvious one. ORM brings to the table something(s) that another solution hasn’t done so far. These “something(s)” that ORM contributes are listed below:
#Alleviates the problem that hinders a transition from one database provider to another database vendor or even another database product.
#Enables to perform most of the database operations ([http://en.wikipedia.org/wiki/Create,_read,_update_and_delete]mainly CRUD) without having to write any [http://en.wikipedia.org/wiki/SQL]SQL statements, thereby permitting a shift from one SQL dialect to another. This also allows the software solutions to focus more on the actual problem being solved rather that performing supplementary functions extensively.

==Flavors of ORM solutions.==
The term ORM is a very generic name for the class of solutions. Typically, ORM support in object oriented languages comes in two flavors; one that comes in separate packages which can be imported into our application, the other is the variety that comes incorporated into a language.
When there is an option of choosing among the two flavors, the solution that come incorporated into the language is preferred. This choice may be quite an obvious one depending on the language that is being considered.
Though the difference between the two might not be that apparent in the outset, the reason for this predilection towards the language incorporate solution over the other has mainly to do with design paradigm of the modern day software development of [http://en.wikipedia.org/wiki/Convention_over_configuration]“convention over configuration”. This paradigm emphasizes on the development by convention rather than development by configuration. The fact that the solution involving external packages and libraries involve a lot of configuration files which play the instructing role. In the language incorporated solution, such a problem doesn’t arise as the involvement of configuration files in the entire system itself is scanty. In the following sections we will take a look at two of the preferred language incorporated solutions.

==ORM implementation in specific languages.==
In this section, we will look at the language specific ORM examples illustrating the relation between creation of classes and tables, objects and rows, attributes and columns; and also examples for performing basic CRUD operations for the four OO languages.
===Groovy, Grails and GROM:===
====Creating classes and tables:====
Classes, when created using the create-domain-class, also create the table of the same name as the class (not the plural).
For example,
grails create-domain-class Assignment
running the above command would create an empty class named Assignment and also create a table named Assignment in the database. Attributes to this class may be added in a fashion similar to the one followed in java. The attributes that are created in-turn gets automatically mapped to the columns in the table “Assignment”.

We may want to define the Assignment class as follows
class Assignment {
String title
Date dueDate
String weightage_on_final_grade
}
Having objects defined within a class would facilitate in achieving association between classes.

====Basic CRUD:====
:Creating objects also creates rows. This is done as illustrated below:
def a = new Assignment (title:"WikiTextChapter", dueDate:date, weightage_on_final_grade:3)
a.save()

The above statements would create a new A
ssignment object and also create a row in the Assignment table. The save method above may be considered analogous to a commit statement that may be used in SQL.
:Reading objects from the database. This can be done as in the below example.
def a = Assignment.get(1)
In the above statement, the parameter 1 passed to the get method is an identifier for the object. When an object is created in the database, an id is created transparently by the language specifics.
Apart from the get method, other ways of fetching objects from database would involve use of methods such as list(), finfBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. This is achieved by updating the necessary attribute of an object and saving or committing the changes back to the database. This is illustrated in the below example.
def a = Assignment.get(1)
a. weightage_on_final_grade =5
a.save()
:Deleting objects. To perform a delete, we must first get an object and then call the delete method on that object. This is illustrated in the below example.
def a = Assignment.get(1)
a.delete()

===PHP ActiveRecord:===
====Creating classes and tables:====
Tables corresponding to classes can be created by
classes extending the ActiveRecord\Model class.
class Assignment extends ActiveRecord\Model
{
}
====Basic CRUD:====
:Creating objects also creates rows. This can be done by as shown below.
$a = new Assignment();
$a-> title=’ WikiTextChapter’;
$a->save();
:Reading objects from database. Objects can be read from the database as illustrated in the below example.
$a = Assignment::find(1);
::Apart from the get method, other ways of fetching objects from database would involve use of methods such as finfBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. For this to be done, we need to find a record first and then change one of its attributes and finally commit the changes. This is illustrated below:
$a = Assignment::find(1);
$a->title = 'NewWikiTextChapter’';
$a->save();
:Deleting objects. For this to be done, we need to find a record first and then call the delete method on the object.
$a = Assignment::find(1);
$a->delete();
:This is similar to ActiveRecord in Ruby, so we will not explicitly deal with ORM in Ruby.
[[Image:Image.png]]

==Incorporating ORM into the language.==
To incorporate ORM into a language, the usual approach, is to implement the ActiveRecord Design Pattern [http://en.wikipedia.org/wiki/Active_record_pattern]. This approach considers persistence as a responsibility rather than as a service. Following this approach, would hence expect the objects themselves implement methods to support database operations and like in the object oriented world the objects are expected to be able to manage themselves. Following the object oriented paradigm and adopting a modular approach the responsibility of implementing the methods facilitating the database operations are implemented by a class which is inherited by all other classes whose objects have to persist across sessions. The methods to support database operations include methods to create tables, create rows in the table when objects of a class are created; methods to read objects from the table; methods that facilitate updating the objects and finally methods to delete the objects. Apart from this basic CRUD functionality any extra functionality would always be welcome.

==References and Further Reading==
*Very informative and a nice place to start. http://www.slideshare.net/hominhchuc/grails-docs-presentation
*Insight into impedance mismatch. http://www.agiledata.org/essays/impedanceMismatch.html
*List of object-relational mapping software http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
----
==External links==
*Active Record Design Pattern - Domain Driven Design and Domain Layer - Object Persistence. http://davidhayden.com/blog/dave/archive/2006/06/10/2984.aspx
*Grails home page. http://grails.org/
*ORM in php: php.active record http://www.phpactiverecord.org/
*Active Record Design Pattern http://en.wikipedia.org/wiki/Active_record_pattern

CSC/ECE 517 Fall 2010/ch2 2a aa

2010-09-28T16:25:45Z

Aamarna2:

[Language extensions for ORM]

== Introduction to Object Relational Mapping. ==
Object Relational Mapping is a technique of mapping the solution entities of an object oriented system, [http://en.wikipedia.org/wiki/Object_%28computer_science%29]objects to [http://en.wikipedia.org/wiki/Relational_database_management_system] relational database tables. This technique came into existence as an answer to the problem of lack of persistence of objects across session in [http://en.wikipedia.org/wiki/Object-oriented_programming]Object Oriented Programming Systems. For instance in a software solution to manage the order and inventory systems of a company, the objects that are part of the systems (orders, customers . . .) must be accessible even if the system was temporarily shut down for a while. [http://en.wikipedia.org/wiki/Object-relational_mapping]ORM helps in achieving this very essential requirement by bringing the database into the picture, more specifically bringing the RDBMS into the picture.

== Why ORM, why not another solution? ==
The answer to this is quite an obvious one. ORM brings to the table something(s) that another solution hasn’t done so far. These “something(s)” that ORM contributes are listed below:
#Alleviates the problem that hinders a transition from one database provider to another database vendor or even another database product.
#Enables to perform most of the database operations ([http://en.wikipedia.org/wiki/Create,_read,_update_and_delete]mainly CRUD) without having to write any [http://en.wikipedia.org/wiki/SQL]SQL statements, thereby permitting a shift from one SQL dialect to another. This also allows the software solutions to focus more on the actual problem being solved rather that performing supplementary functions extensively.

==Flavors of ORM solutions.==
The term ORM is a very generic name for the class of solutions. Typically, ORM support in object oriented languages comes in two flavors; one that comes in separate packages which can be imported into our application, the other is the variety that comes incorporated into a language.
When there is an option of choosing among the two flavors, the solution that come incorporated into the language is preferred. This choice may be quite an obvious one depending on the language that is being considered.
Though the difference between the two might not be that apparent in the outset, the reason for this predilection towards the language incorporate solution over the other has mainly to do with design paradigm of the modern day software development of [http://en.wikipedia.org/wiki/Convention_over_configuration]“convention over configuration”. This paradigm emphasizes on the development by convention rather than development by configuration. The fact that the solution involving external packages and libraries involve a lot of configuration files which play the instructing role. In the language incorporated solution, such a problem doesn’t arise as the involvement of configuration files in the entire system itself is scanty. In the following sections we will take a look at two of the preferred language incorporated solutions.

==ORM implementation in specific languages.==
In this section, we will look at the language specific ORM examples illustrating the relation between creation of classes and tables, objects and rows, attributes and columns; and also examples for performing basic CRUD operations for the four OO languages.
===Groovy, Grails and GROM:===
====Creating classes and tables:====
Classes, when created using the create-domain-class, also create the table of the same name as the class (not the plural).
For example,
grails create-domain-class Assignment
running the above command would create an empty class named Assignment and also create a table named Assignment in the database. Attributes to this class may be added in a fashion similar to the one followed in java. The attributes that are created in-turn gets automatically mapped to the columns in the table “Assignment”.

We may want to define the Assignment class as follows
class Assignment {
String title
Date dueDate
String weightage_on_final_grade
}
Having objects defined within a class would facilitate in achieving association between classes.

====Basic CRUD:====
:Creating objects also creates rows. This is done as illustrated below:
def a = new Assignment (title:"WikiTextChapter", dueDate:date, weightage_on_final_grade:3)
a.save()

The above statements would create a new A
ssignment object and also create a row in the Assignment table. The save method above may be considered analogous to a commit statement that may be used in SQL.
:Reading objects from the database. This can be done as in the below example.
def a = Assignment.get(1)
In the above statement, the parameter 1 passed to the get method is an identifier for the object. When an object is created in the database, an id is created transparently by the language specifics.
Apart from the get method, other ways of fetching objects from database would involve use of methods such as list(), finfBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. This is achieved by updating the necessary attribute of an object and saving or committing the changes back to the database. This is illustrated in the below example.
def a = Assignment.get(1)
a. weightage_on_final_grade =5
a.save()
:Deleting objects. To perform a delete, we must first get an object and then call the delete method on that object. This is illustrated in the below example.
def a = Assignment.get(1)
a.delete()

===PHP ActiveRecord:===
====Creating classes and tables:====
Tables corresponding to classes can be created by
classes extending the ActiveRecord\Model class.
class Assignment extends ActiveRecord\Model
{
}
====Basic CRUD:====
:Creating objects also creates rows. This can be done by as shown below.
$a = new Assignment();
$a-> title=’ WikiTextChapter’;
$a->save();
:Reading objects from database. Objects can be read from the database as illustrated in the below example.
$a = Assignment::find(1);
::Apart from the get method, other ways of fetching objects from database would involve use of methods such as finfBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. For this to be done, we need to find a record first and then change one of its attributes and finally commit the changes. This is illustrated below:
$a = Assignment::find(1);
$a->title = 'NewWikiTextChapter’';
$a->save();
:Deleting objects. For this to be done, we need to find a record first and then call the delete method on the object.
$a = Assignment::find(1);
$a->delete();
:This is similar to ActiveRecord in Ruby, so we will not explicitly deal with ORM in Ruby.
[[Image:Image.png]]

[[Image:https://docs.google.com/leaf?id=0B1TgH20TU3BGMjA2MmY4NzUtMGExYS00N2YyLTg1NjYtZGI4Y2FhOTQ4NGZk&hl=en&authkey=CJ263YQF]]
==Incorporating ORM into the language.==
To incorporate ORM into a language, the usual approach, is to implement the ActiveRecord Design Pattern [http://en.wikipedia.org/wiki/Active_record_pattern]. This approach considers persistence as a responsibility rather than as a service. Following this approach, would hence expect the objects themselves implement methods to support database operations and like in the object oriented world the objects are expected to be able to manage themselves. Following the object oriented paradigm and adopting a modular approach the responsibility of implementing the methods facilitating the database operations are implemented by a class which is inherited by all other classes whose objects have to persist across sessions. The methods to support database operations include methods to create tables, create rows in the table when objects of a class are created; methods to read objects from the table; methods that facilitate updating the objects and finally methods to delete the objects. Apart from this basic CRUD functionality any extra functionality would always be welcome.

==References and Further Reading==
*Very informative and a nice place to start. http://www.slideshare.net/hominhchuc/grails-docs-presentation
*Insight into impedance mismatch. http://www.agiledata.org/essays/impedanceMismatch.html
*List of object-relational mapping software http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
----
==External links==
*Active Record Design Pattern - Domain Driven Design and Domain Layer - Object Persistence. http://davidhayden.com/blog/dave/archive/2006/06/10/2984.aspx
*Grails home page. http://grails.org/
*ORM in php: php.active record http://www.phpactiverecord.org/
*Active Record Design Pattern http://en.wikipedia.org/wiki/Active_record_pattern

File:Image.png

2010-09-28T16:24:27Z

Aamarna2:

CSC/ECE 517 Fall 2010/ch2 2a aa

2010-09-28T16:20:48Z

Aamarna2:

[Language extensions for ORM]

== Introduction to Object Relational Mapping. ==
Object Relational Mapping is a technique of mapping the solution entities of an object oriented system, [http://en.wikipedia.org/wiki/Object_%28computer_science%29]objects to [http://en.wikipedia.org/wiki/Relational_database_management_system] relational database tables. This technique came into existence as an answer to the problem of lack of persistence of objects across session in [http://en.wikipedia.org/wiki/Object-oriented_programming]Object Oriented Programming Systems. For instance in a software solution to manage the order and inventory systems of a company, the objects that are part of the systems (orders, customers . . .) must be accessible even if the system was temporarily shut down for a while. [http://en.wikipedia.org/wiki/Object-relational_mapping]ORM helps in achieving this very essential requirement by bringing the database into the picture, more specifically bringing the RDBMS into the picture.

== Why ORM, why not another solution? ==
The answer to this is quite an obvious one. ORM brings to the table something(s) that another solution hasn’t done so far. These “something(s)” that ORM contributes are listed below:
#Alleviates the problem that hinders a transition from one database provider to another database vendor or even another database product.
#Enables to perform most of the database operations ([http://en.wikipedia.org/wiki/Create,_read,_update_and_delete]mainly CRUD) without having to write any [http://en.wikipedia.org/wiki/SQL]SQL statements, thereby permitting a shift from one SQL dialect to another. This also allows the software solutions to focus more on the actual problem being solved rather that performing supplementary functions extensively.

==Flavors of ORM solutions.==
The term ORM is a very generic name for the class of solutions. Typically, ORM support in object oriented languages comes in two flavors; one that comes in separate packages which can be imported into our application, the other is the variety that comes incorporated into a language.
When there is an option of choosing among the two flavors, the solution that come incorporated into the language is preferred. This choice may be quite an obvious one depending on the language that is being considered.
Though the difference between the two might not be that apparent in the outset, the reason for this predilection towards the language incorporate solution over the other has mainly to do with design paradigm of the modern day software development of [http://en.wikipedia.org/wiki/Convention_over_configuration]“convention over configuration”. This paradigm emphasizes on the development by convention rather than development by configuration. The fact that the solution involving external packages and libraries involve a lot of configuration files which play the instructing role. In the language incorporated solution, such a problem doesn’t arise as the involvement of configuration files in the entire system itself is scanty. In the following sections we will take a look at two of the preferred language incorporated solutions.

==ORM implementation in specific languages.==
In this section, we will look at the language specific ORM examples illustrating the relation between creation of classes and tables, objects and rows, attributes and columns; and also examples for performing basic CRUD operations for the four OO languages.
===Groovy, Grails and GROM:===
====Creating classes and tables:====
Classes, when created using the create-domain-class, also create the table of the same name as the class (not the plural).
For example,
grails create-domain-class Assignment
running the above command would create an empty class named Assignment and also create a table named Assignment in the database. Attributes to this class may be added in a fashion similar to the one followed in java. The attributes that are created in-turn gets automatically mapped to the columns in the table “Assignment”.

We may want to define the Assignment class as follows
class Assignment {
String title
Date dueDate
String weightage_on_final_grade
}
Having objects defined within a class would facilitate in achieving association between classes.

====Basic CRUD:====
:Creating objects also creates rows. This is done as illustrated below:
def a = new Assignment (title:"WikiTextChapter", dueDate:date, weightage_on_final_grade:3)
a.save()

The above statements would create a new A
ssignment object and also create a row in the Assignment table. The save method above may be considered analogous to a commit statement that may be used in SQL.
:Reading objects from the database. This can be done as in the below example.
def a = Assignment.get(1)
In the above statement, the parameter 1 passed to the get method is an identifier for the object. When an object is created in the database, an id is created transparently by the language specifics.
Apart from the get method, other ways of fetching objects from database would involve use of methods such as list(), finfBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. This is achieved by updating the necessary attribute of an object and saving or committing the changes back to the database. This is illustrated in the below example.
def a = Assignment.get(1)
a. weightage_on_final_grade =5
a.save()
:Deleting objects. To perform a delete, we must first get an object and then call the delete method on that object. This is illustrated in the below example.
def a = Assignment.get(1)
a.delete()

===PHP ActiveRecord:===
====Creating classes and tables:====
Tables corresponding to classes can be created by
classes extending the ActiveRecord\Model class.
class Assignment extends ActiveRecord\Model
{
}
====Basic CRUD:====
:Creating objects also creates rows. This can be done by as shown below.
$a = new Assignment();
$a-> title=’ WikiTextChapter’;
$a->save();
:Reading objects from database. Objects can be read from the database as illustrated in the below example.
$a = Assignment::find(1);
::Apart from the get method, other ways of fetching objects from database would involve use of methods such as finfBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. For this to be done, we need to find a record first and then change one of its attributes and finally commit the changes. This is illustrated below:
$a = Assignment::find(1);
$a->title = 'NewWikiTextChapter’';
$a->save();
:Deleting objects. For this to be done, we need to find a record first and then call the delete method on the object.
$a = Assignment::find(1);
$a->delete();
:This is similar to ActiveRecord in Ruby, so we will not explicitly deal with ORM in Ruby.

[[Image:https://docs.google.com/leaf?id=0B1TgH20TU3BGMjA2MmY4NzUtMGExYS00N2YyLTg1NjYtZGI4Y2FhOTQ4NGZk&hl=en&authkey=CJ263YQF]]
==Incorporating ORM into the language.==
To incorporate ORM into a language, the usual approach, is to implement the ActiveRecord Design Pattern [http://en.wikipedia.org/wiki/Active_record_pattern]. This approach considers persistence as a responsibility rather than as a service. Following this approach, would hence expect the objects themselves implement methods to support database operations and like in the object oriented world the objects are expected to be able to manage themselves. Following the object oriented paradigm and adopting a modular approach the responsibility of implementing the methods facilitating the database operations are implemented by a class which is inherited by all other classes whose objects have to persist across sessions. The methods to support database operations include methods to create tables, create rows in the table when objects of a class are created; methods to read objects from the table; methods that facilitate updating the objects and finally methods to delete the objects. Apart from this basic CRUD functionality any extra functionality would always be welcome.

==Further Reading==
*Very informative and a nice place to start. http://www.slideshare.net/hominhchuc/grails-docs-presentation
*Insight into impedance mismatch. http://www.agiledata.org/essays/impedanceMismatch.html
*List of object-relational mapping software http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
----
==External links==
*Active Record Design Pattern - Domain Driven Design and Domain Layer - Object Persistence. http://davidhayden.com/blog/dave/archive/2006/06/10/2984.aspx
*Grails home page. http://grails.org/
*ORM in php: php.active record http://www.phpactiverecord.org/
*Active Record Design Pattern http://en.wikipedia.org/wiki/Active_record_pattern

CSC/ECE 517 Fall 2010/ch2 2a aa

2010-09-28T16:17:50Z

Aamarna2:

[Language extensions for ORM]

== Introduction to Object Relational Mapping. ==
Object Relational Mapping is a technique of mapping the solution entities of an object oriented system, [http://en.wikipedia.org/wiki/Object_%28computer_science%29]objects to [http://en.wikipedia.org/wiki/Relational_database_management_system] relational database tables. This technique came into existence as an answer to the problem of lack of persistence of objects across session in [http://en.wikipedia.org/wiki/Object-oriented_programming]Object Oriented Programming Systems. For instance in a software solution to manage the order and inventory systems of a company, the objects that are part of the systems (orders, customers . . .) must be accessible even if the system was temporarily shut down for a while. [http://en.wikipedia.org/wiki/Object-relational_mapping]ORM helps in achieving this very essential requirement by bringing the database into the picture, more specifically bringing the RDBMS into the picture.

== Why ORM, why not another solution? ==
The answer to this is quite an obvious one. ORM brings to the table something(s) that another solution hasn’t done so far. These “something(s)” that ORM contributes are listed below:
#Alleviates the problem that hinders a transition from one database provider to another database vendor or even another database product.
#Enables to perform most of the database operations ([http://en.wikipedia.org/wiki/Create,_read,_update_and_delete]mainly CRUD) without having to write any [http://en.wikipedia.org/wiki/SQL]SQL statements, thereby permitting a shift from one SQL dialect to another. This also allows the software solutions to focus more on the actual problem being solved rather that performing supplementary functions extensively.

==Flavors of ORM solutions.==
The term ORM is a very generic name for the class of solutions. Typically, ORM support in object oriented languages comes in two flavors; one that comes in separate packages which can be imported into our application, the other is the variety that comes incorporated into a language.
When there is an option of choosing among the two flavors, the solution that come incorporated into the language is preferred. This choice may be quite an obvious one depending on the language that is being considered.
Though the difference between the two might not be that apparent in the outset, the reason for this predilection towards the language incorporate solution over the other has mainly to do with design paradigm of the modern day software development of [http://en.wikipedia.org/wiki/Convention_over_configuration]“convention over configuration”. This paradigm emphasizes on the development by convention rather than development by configuration. The fact that the solution involving external packages and libraries involve a lot of configuration files which play the instructing role. In the language incorporated solution, such a problem doesn’t arise as the involvement of configuration files in the entire system itself is scanty. In the following sections we will take a look at two of the preferred language incorporated solutions.

==ORM implementation in specific languages.==
In this section, we will look at the language specific ORM examples illustrating the relation between creation of classes and tables, objects and rows, attributes and columns; and also examples for performing basic CRUD operations for the four OO languages.
===Groovy, Grails and GROM:===
====Creating classes and tables:====
Classes, when created using the create-domain-class, also create the table of the same name as the class (not the plural).
For example,
grails create-domain-class Assignment
running the above command would create an empty class named Assignment and also create a table named Assignment in the database. Attributes to this class may be added in a fashion similar to the one followed in java. The attributes that are created in-turn gets automatically mapped to the columns in the table “Assignment”.

We may want to define the Assignment class as follows
class Assignment {
String title
Date dueDate
String weightage_on_final_grade
}
Having objects defined within a class would facilitate in achieving association between classes.

====Basic CRUD:====
:Creating objects also creates rows. This is done as illustrated below:
def a = new Assignment (title:"WikiTextChapter", dueDate:date, weightage_on_final_grade:3)
a.save()

The above statements would create a new A
ssignment object and also create a row in the Assignment table. The save method above may be considered analogous to a commit statement that may be used in SQL.
:Reading objects from the database. This can be done as in the below example.
def a = Assignment.get(1)
In the above statement, the parameter 1 passed to the get method is an identifier for the object. When an object is created in the database, an id is created transparently by the language specifics.
Apart from the get method, other ways of fetching objects from database would involve use of methods such as list(), finfBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. This is achieved by updating the necessary attribute of an object and saving or committing the changes back to the database. This is illustrated in the below example.
def a = Assignment.get(1)
a. weightage_on_final_grade =5
a.save()
:Deleting objects. To perform a delete, we must first get an object and then call the delete method on that object. This is illustrated in the below example.
def a = Assignment.get(1)
a.delete()

===PHP ActiveRecord:===
====Creating classes and tables:====
Tables corresponding to classes can be created by
classes extending the ActiveRecord\Model class.
class Assignment extends ActiveRecord\Model
{
}
====Basic CRUD:====
:Creating objects also creates rows. This can be done by as shown below.
$a = new Assignment();
$a-> title=’ WikiTextChapter’;
$a->save();
:Reading objects from database. Objects can be read from the database as illustrated in the below example.
$a = Assignment::find(1);
::Apart from the get method, other ways of fetching objects from database would involve use of methods such as finfBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. For this to be done, we need to find a record first and then change one of its attributes and finally commit the changes. This is illustrated below:
$a = Assignment::find(1);
$a->title = 'NewWikiTextChapter’';
$a->save();
:Deleting objects. For this to be done, we need to find a record first and then call the delete method on the object.
$a = Assignment::find(1);
$a->delete();
:This is similar to ActiveRecord in Ruby, so we will not explicitly deal with ORM in Ruby.

[[Image:https://docs.google.com/a/ncsu.edu/leaf?id=0B1TgH20TU3BGMjA2MmY4NzUtMGExYS00N2YyLTg1NjYtZGI4Y2FhOTQ4NGZk&hl=en]]
==Incorporating ORM into the language.==
To incorporate ORM into a language, the usual approach, is to implement the ActiveRecord Design Pattern [http://en.wikipedia.org/wiki/Active_record_pattern]. This approach considers persistence as a responsibility rather than as a service. Following this approach, would hence expect the objects themselves implement methods to support database operations and like in the object oriented world the objects are expected to be able to manage themselves. Following the object oriented paradigm and adopting a modular approach the responsibility of implementing the methods facilitating the database operations are implemented by a class which is inherited by all other classes whose objects have to persist across sessions. The methods to support database operations include methods to create tables, create rows in the table when objects of a class are created; methods to read objects from the table; methods that facilitate updating the objects and finally methods to delete the objects. Apart from this basic CRUD functionality any extra functionality would always be welcome.

==Further Reading==
*Very informative and a nice place to start. http://www.slideshare.net/hominhchuc/grails-docs-presentation
*Insight into impedance mismatch. http://www.agiledata.org/essays/impedanceMismatch.html
*List of object-relational mapping software http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
----
==External links==
*Active Record Design Pattern - Domain Driven Design and Domain Layer - Object Persistence. http://davidhayden.com/blog/dave/archive/2006/06/10/2984.aspx
*Grails home page. http://grails.org/
*ORM in php: php.active record http://www.phpactiverecord.org/
*Active Record Design Pattern http://en.wikipedia.org/wiki/Active_record_pattern

CSC/ECE 517 Fall 2010/ch2 2a aa

2010-09-28T16:14:23Z

Aamarna2:

[Language extensions for ORM]

== Introduction to Object Relational Mapping. ==
Object Relational Mapping is a technique of mapping the solution entities of an object oriented system, [http://en.wikipedia.org/wiki/Object_%28computer_science%29]objects to [http://en.wikipedia.org/wiki/Relational_database_management_system] relational database tables. This technique came into existence as an answer to the problem of lack of persistence of objects across session in [http://en.wikipedia.org/wiki/Object-oriented_programming]Object Oriented Programming Systems. For instance in a software solution to manage the order and inventory systems of a company, the objects that are part of the systems (orders, customers . . .) must be accessible even if the system was temporarily shut down for a while. [http://en.wikipedia.org/wiki/Object-relational_mapping]ORM helps in achieving this very essential requirement by bringing the database into the picture, more specifically bringing the RDBMS into the picture.

== Why ORM, why not another solution? ==
The answer to this is quite an obvious one. ORM brings to the table something(s) that another solution hasn’t done so far. These “something(s)” that ORM contributes are listed below:
#Alleviates the problem that hinders a transition from one database provider to another database vendor or even another database product.
#Enables to perform most of the database operations ([http://en.wikipedia.org/wiki/Create,_read,_update_and_delete]mainly CRUD) without having to write any [http://en.wikipedia.org/wiki/SQL]SQL statements, thereby permitting a shift from one SQL dialect to another. This also allows the software solutions to focus more on the actual problem being solved rather that performing supplementary functions extensively.

==Flavors of ORM solutions.==
The term ORM is a very generic name for the class of solutions. Typically, ORM support in object oriented languages comes in two flavors; one that comes in separate packages which can be imported into our application, the other is the variety that comes incorporated into a language.
When there is an option of choosing among the two flavors, the solution that come incorporated into the language is preferred. This choice may be quite an obvious one depending on the language that is being considered.
Though the difference between the two might not be that apparent in the outset, the reason for this predilection towards the language incorporate solution over the other has mainly to do with design paradigm of the modern day software development of [http://en.wikipedia.org/wiki/Convention_over_configuration]“convention over configuration”. This paradigm emphasizes on the development by convention rather than development by configuration. The fact that the solution involving external packages and libraries involve a lot of configuration files which play the instructing role. In the language incorporated solution, such a problem doesn’t arise as the involvement of configuration files in the entire system itself is scanty. In the following sections we will take a look at two of the preferred language incorporated solutions.

==ORM implementation in specific languages.==
In this section, we will look at the language specific ORM examples illustrating the relation between creation of classes and tables, objects and rows, attributes and columns; and also examples for performing basic CRUD operations for the four OO languages.
===Groovy, Grails and GROM:===
====Creating classes and tables:====
Classes, when created using the create-domain-class, also create the table of the same name as the class (not the plural).
For example,
grails create-domain-class Assignment
running the above command would create an empty class named Assignment and also create a table named Assignment in the database. Attributes to this class may be added in a fashion similar to the one followed in java. The attributes that are created in-turn gets automatically mapped to the columns in the table “Assignment”.

We may want to define the Assignment class as follows
class Assignment {
String title
Date dueDate
String weightage_on_final_grade
}
Having objects defined within a class would facilitate in achieving association between classes.

====Basic CRUD:====
:Creating objects also creates rows. This is done as illustrated below:
def a = new Assignment (title:"WikiTextChapter", dueDate:date, weightage_on_final_grade:3)
a.save()

The above statements would create a new A
ssignment object and also create a row in the Assignment table. The save method above may be considered analogous to a commit statement that may be used in SQL.
:Reading objects from the database. This can be done as in the below example.
def a = Assignment.get(1)
In the above statement, the parameter 1 passed to the get method is an identifier for the object. When an object is created in the database, an id is created transparently by the language specifics.
Apart from the get method, other ways of fetching objects from database would involve use of methods such as list(), finfBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. This is achieved by updating the necessary attribute of an object and saving or committing the changes back to the database. This is illustrated in the below example.
def a = Assignment.get(1)
a. weightage_on_final_grade =5
a.save()
:Deleting objects. To perform a delete, we must first get an object and then call the delete method on that object. This is illustrated in the below example.
def a = Assignment.get(1)
a.delete()

===PHP ActiveRecord:===
====Creating classes and tables:====
Tables corresponding to classes can be created by
classes extending the ActiveRecord\Model class.
class Assignment extends ActiveRecord\Model
{
}
====Basic CRUD:====
:Creating objects also creates rows. This can be done by as shown below.
$a = new Assignment();
$a-> title=’ WikiTextChapter’;
$a->save();
:Reading objects from database. Objects can be read from the database as illustrated in the below example.
$a = Assignment::find(1);
::Apart from the get method, other ways of fetching objects from database would involve use of methods such as finfBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. For this to be done, we need to find a record first and then change one of its attributes and finally commit the changes. This is illustrated below:
$a = Assignment::find(1);
$a->title = 'NewWikiTextChapter’';
$a->save();
:Deleting objects. For this to be done, we need to find a record first and then call the delete method on the object.
$a = Assignment::find(1);
$a->delete();
:This is similar to ActiveRecord in Ruby, so we will not explicitly deal with ORM in Ruby.
[[Image:https://docs.google.com/a/ncsu.edu/leaf?id=0B1TgH20TU3BGMjA2MmY4NzUtMGExYS00N2YyLTg1NjYtZGI4Y2FhOTQ4NGZk&hl=en]]
==Incorporating ORM into the language.==
To incorporate ORM into a language, the usual approach, is to implement the ActiveRecord Design Pattern [http://en.wikipedia.org/wiki/Active_record_pattern]. This approach considers persistence as a responsibility rather than as a service. Following this approach, would hence expect the objects themselves implement methods to support database operations and like in the object oriented world the objects are expected to be able to manage themselves. Following the object oriented paradigm and adopting a modular approach the responsibility of implementing the methods facilitating the database operations are implemented by a class which is inherited by all other classes whose objects have to persist across sessions. The methods to support database operations include methods to create tables, create rows in the table when objects of a class are created; methods to read objects from the table; methods that facilitate updating the objects and finally methods to delete the objects. Apart from this basic CRUD functionality any extra functionality would always be welcome.

==Further Reading==
*Very informative and a nice place to start. http://www.slideshare.net/hominhchuc/grails-docs-presentation
*Insight into impedance mismatch. http://www.agiledata.org/essays/impedanceMismatch.html
*List of object-relational mapping software http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
----
==External links==
[1]Active Record Design Pattern - Domain Driven Design and Domain Layer - Object Persistence. http://davidhayden.com/blog/dave/archive/2006/06/10/2984.aspx
[2]Grails home page. http://grails.org/
[3]ORM in php: php.active record http://www.phpactiverecord.org/
[4]Active Record Design Pattern http://en.wikipedia.org/wiki/Active_record_pattern

CSC/ECE 517 Fall 2010/ch2 2a aa

2010-09-21T01:42:33Z

Aamarna2:

[Language extensions for ORM]

== Introduction to Object Relational Mapping. ==
Object Relational Mapping is a technique of mapping the solution entities of an object oriented system, [http://en.wikipedia.org/wiki/Object_%28computer_science%29]objects to [http://en.wikipedia.org/wiki/Relational_database_management_system] relational database tables. This technique came into existence as an answer to the problem of lack of persistence of objects across session in [http://en.wikipedia.org/wiki/Object-oriented_programming]Object Oriented Programming Systems. For instance in a software solution to manage the order and inventory systems of a company, the objects that are part of the systems (orders, customers . . .) must be accessible even if the system was temporarily shut down for a while. [http://en.wikipedia.org/wiki/Object-relational_mapping]ORM helps in achieving this very essential requirement by bringing the database into the picture, more specifically bringing the RDBMS into the picture.

== Why ORM, why not another solution? ==
The answer to this is quite an obvious one. ORM brings to the table something(s) that another solution hasn’t done so far. These “something(s)” that ORM contributes are listed below:
#Alleviates the problem that hinders a transition from one database provider to another database vendor or even another database product.
#Enables to perform most of the database operations ([http://en.wikipedia.org/wiki/Create,_read,_update_and_delete]mainly CRUD) without having to write any [http://en.wikipedia.org/wiki/SQL]SQL statements, thereby permitting a shift from one SQL dialect to another. This also allows the software solutions to focus more on the actual problem being solved rather that performing supplementary functions extensively.

==Flavors of ORM solutions.==
The term ORM is a very generic name for the class of solutions. Typically, ORM support in object oriented languages comes in two flavors; one that comes in separate packages which can be imported into our application, the other is the variety that comes incorporated into a language.
When there is an option of choosing among the two flavors, the solution that come incorporated into the language is preferred. This choice may be quite an obvious one depending on the language that is being considered.
Though the difference between the two might not be that apparent in the outset, the reason for this predilection towards the language incorporate solution over the other has mainly to do with design paradigm of the modern day software development of [http://en.wikipedia.org/wiki/Convention_over_configuration]“convention over configuration”. This paradigm emphasizes on the development by convention rather than development by configuration. The fact that the solution involving external packages and libraries involve a lot of configuration files which play the instructing role. In the language incorporated solution, such a problem doesn’t arise as the involvement of configuration files in the entire system itself is scanty. In the following sections we will take a look at two of the preferred language incorporated solutions.

==ORM implementation in specific languages.==
In this section, we will look at the language specific ORM examples illustrating the relation between creation of classes and tables, objects and rows, attributes and columns; and also examples for performing basic CRUD operations for the four OO languages.
===Groovy, Grails and GROM:===
====Creating classes and tables:====
Classes, when created using the create-domain-class, also create the table of the same name as the class (not the plural).
For example,
grails create-domain-class Assignment
running the above command would create an empty class named Assignment and also create a table named Assignment in the database. Attributes to this class may be added in a fashion similar to the one followed in java. The attributes that are created in-turn gets automatically mapped to the columns in the table “Assignment”.

We may want to define the Assignment class as follows
class Assignment {
String title
Date dueDate
String weightage_on_final_grade
}
Having objects defined within a class would facilitate in achieving association between classes.

====Basic CRUD:====
:Creating objects also creates rows. This is done as illustrated below:
def a = new Assignment (title:"WikiTextChapter", dueDate:date, weightage_on_final_grade:3)
a.save()

The above statements would create a new A
ssignment object and also create a row in the Assignment table. The save method above may be considered analogous to a commit statement that may be used in SQL.
:Reading objects from the database. This can be done as in the below example.
def a = Assignment.get(1)
In the above statement, the parameter 1 passed to the get method is an identifier for the object. When an object is created in the database, an id is created transparently by the language specifics.
Apart from the get method, other ways of fetching objects from database would involve use of methods such as list(), finfBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. This is achieved by updating the necessary attribute of an object and saving or committing the changes back to the database. This is illustrated in the below example.
def a = Assignment.get(1)
a. weightage_on_final_grade =5
a.save()
:Deleting objects. To perform a delete, we must first get an object and then call the delete method on that object. This is illustrated in the below example.
def a = Assignment.get(1)
a.delete()

===PHP ActiveRecord:===
====Creating classes and tables:====
Tables corresponding to classes can be created by
classes extending the ActiveRecord\Model class.
class Assignment extends ActiveRecord\Model
{
}
====Basic CRUD:====
:Creating objects also creates rows. This can be done by as shown below.
$a = new Assignment();
$a-> title=’ WikiTextChapter’;
$a->save();
:Reading objects from database. Objects can be read from the database as illustrated in the below example.
$a = Assignment::find(1);
::Apart from the get method, other ways of fetching objects from database would involve use of methods such as finfBy<attributeName>() few among the many other methods that is on offer.
:Updating objects. For this to be done, we need to find a record first and then change one of its attributes and finally commit the changes. This is illustrated below:
$a = Assignment::find(1);
$a->title = 'NewWikiTextChapter’';
$a->save();
:Deleting objects. For this to be done, we need to find a record first and then call the delete method on the object.
$a = Assignment::find(1);
$a->delete();
:This is similar to ActiveRecord in Ruby, so we will not explicitly deal with ORM in Ruby.
[[Image:https://docs.google.com/a/ncsu.edu/leaf?id=0B1TgH20TU3BGMjA2MmY4NzUtMGExYS00N2YyLTg1NjYtZGI4Y2FhOTQ4NGZk&hl=en]]
==Incorporating ORM into the language.==
To incorporate ORM into a language, the usual approach, is to implement the ActiveRecord Design Pattern [http://en.wikipedia.org/wiki/Active_record_pattern]. This approach considers persistence as a responsibility rather than as a service. Following this approach, would hence expect the objects themselves implement methods to support database operations and like in the object oriented world the objects are expected to be able to manage themselves. Following the object oriented paradigm and adopting a modular approach the responsibility of implementing the methods facilitating the database operations are implemented by a class which is inherited by all other classes whose objects have to persist across sessions. The methods to support database operations include methods to create tables, create rows in the table when objects of a class are created; methods to read objects from the table; methods that facilitate updating the objects and finally methods to delete the objects. Apart from this basic CRUD functionality any extra functionality would always be welcome.

==Further Reading==
*Very informative and a nice place to start. http://www.slideshare.net/hominhchuc/grails-docs-presentation
*Insight into impedance mismatch. http://www.agiledata.org/essays/impedanceMismatch.html
*List of object-relational mapping software http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
----
==External links==
*Active Record Design Pattern - Domain Driven Design and Domain Layer - Object Persistence. http://davidhayden.com/blog/dave/archive/2006/06/10/2984.aspx
*Grails home page. http://grails.org/
*ORM in php: php.active record http://www.phpactiverecord.org/
*Actve Record Design Pattern http://en.wikipedia.org/wiki/Active_record_pattern