Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2013/OSS M604

2013-03-23T14:36:32Z

Ashray:

=OpenMRS Change Patient Relationships=

== README ==
The design document for the project can be found [https://wiki.openmrs.org/display/projects/Change+relationship+for+multiple+patients+at+once here]

The project is currently hosted at a long term VCL image found [http://152.46.17.15:8081/openmrs-standalone/index.htm here]

The code for our module is hosted on github [https://github.com/ashrayn/openmrs-module-m604 here]

The module's github readme file can be seen [https://github.com/ashrayn/openmrs-module-m604/blob/master/README.txt here]

Quick Start:
<ol><li>Login to OpenMRS with user:Admin password:Admin123.</li>
<li>Click the 'Administration' button in the top-right corner.</li>
<li>In the bottom-right corner, under 'patients' there should be a link for "change patient relationships".</li>
<li>Click on the 'change patient relationships' link</li>
<li>The content of the change patient relationships module should be displayed.</li></ol>

To see a list of possible patients, it may be useful to open a separate tab with the 'Find/Create Patient" menu from the main menu bar.
To open a list of all data created for demonstration purposes, one would have to access the code [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/api/src/main/java/org/openmrs/data/SampleData.java here]. If the user decides to add his/her data of his own, please refer to the section [https://github.com/ashrayn/openmrs-module-m604/blob/master/README.txt User Guide in readme.txt]
This is not necessary if in case the user already has the relevant data on his/her local machine.

==Writing Exercise 2==
===Design Overview of the Module===
OpenMRS modules utilize a modified Spring MVC framework [http://en.wikipedia.org/wiki/Spring_Framework]. The skeleton for the module is first generated using convenient maven[http://maven.apache.org/] artifacts provided here [https://wiki.openmrs.org/display/docs/Creating+Your+First+Module].

The 'change patient relationships' module utilizes 5 basic files.
<ol>
<li>The main page is a .jsp [http://en.wikipedia.org/wiki/JavaServer_Pages] page, the code can be found at [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/webapp/manage.jsp].</li>

<li>This .jsp page is linked to a spring annotated controller [http://javapapers.com/spring/spring-annotation-based-controllers/], the code can be found at [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/java/org/openmrs/module/changerelationships/web/controller/ChangeRelationshipsManageController.java]. The annotated controller maps the manage.jsp form actions using the '@RequestMapping' annotations. This pattern can be observed by viewing the manage.jsp code and comparing the <form> tags to the @RequestMapping annotations in the java code.</li>

<li/><li>The controller along with the spring framework link the form actions from the 'manage.jsp' page to java objects defined in the following .java files. [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/java/org/openmrs/module/changerelationships/PatientSearch.java] and [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/java/org/openmrs/module/changerelationships/UpdateRecord.java]</li>

<li>The module utilizes OpenMRS's services infrastructure to create services with the following code [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/api/src/main/java/org/openmrs/module/changerelationships/api/impl/ChangeRelationshipsServiceImpl.java]. The services found within this class are retrieved from the OpenMRS context object inside of the above controller code (#2). The ChangePatientRelationshipsServiceImpl.java class utilizes OpenMRS database APIs [https://wiki.openmrs.org/display/docs/API] to actually change the patient data in the OpenMRS database. </li>
</ol>

The entire module is packaged in an OpenMRS .omod file using maven and pre-created packaging scripts. The .omod file can be found here [https://github.com/ashrayn/openmrs-module-m604/tree/master/changerelationships/omod/target] and installed into any OpenMRS server using the 'Administration'>Manage modules page.

===Object-Oriented Design Principles===
Encapsulation
 
There were several instances of encapsulation used through out our implementation code in the OpenMRS module. For example, to get access to relationships between people in the database in OpenMRS, we first had to use the Context class to get a PersonService object type and then use that object type to access a list of relationships:
personService = Context.getPersonService();
Here, getPersonService() is a static method in class Context that doesn't require instantiating a Context object to call the method. getPersonService() can be directly used as a class method without having to know the details of how the method has been implemented and designed.
 
Another example is making helper methods and instance variables private.
private Person getPersonOut(List<Relationship> relationshipList, String nameOut)
This is a helper method to the changePatientRelationships() method that helps locate the Person object for updating the patient relationship. As it is not directly used in the manage.jsp page for the user-interface, it is made private to restrict access to it.

private ChangeRelationshipsDAO dao;
private List<Person> people;
private List<Relationship> allRelatedPeople;
private List<RelationshipType> existingRelationshipTypes;
private int noOfRelatedPeople;
These instance variables are also made private in our module class to prevent the potential corruption of data if they were to be accessed publicly.
 
 
Open-Closed Principle
 
In the OpenMRS module, existing classes that had already been tested were not modified, which exemplifies the open-closed principle [http://en.wikipedia.org/wiki/Open/closed_principle]. This module is an extension of the OpenMRS functionality. Our ChangeRelationshipsServiceImpl class is an added class to specifically add the functionality of being able to update the relationships of several patients at one time. Specifically, in our the ChangeRelationshipServiceImpl, we extend the class BaseOpenmrsService to implement the new functionality:
public class ChangeRelationshipsServiceImpl extends BaseOpenmrsService implements ChangeRelationshipsService

==Design Patterns==
Quite a few design patterns were used to design this module.
===Model View Controller===
As there was significant UI and Database functionality, the use of MVC was inevitable [http://domino.watson.ibm.com/library/cyberdig.nsf/1e4115aea78b6e7c85256b360066f0d4/696cfba5d4b1e68985256a1e00626e27!OpenDocument MVC]
The class [https://github.com/ashrayn/openmrs-module-m604/tree/master/changerelationships/api/src/main/java/org/openmrs/module/changerelationships/api/impl ChangeRelationshipServiceImpl] corresponds to the model. This class contains the functions to fire queries to the database and also insert new records/update existing records. Following is the code snippet for the class
public class ChangeRelationshipsServiceImpl extends BaseOpenmrsService implements ChangeRelationshipsService {

public Person getPersonObjectFromInputname(String fromPerson) {
/*Matches the input string to an existing person object and returns the first person*/
}

public RelationshipType findRelationshipTypeFromInput(String relation) {
/*Matches the input string to an existing relationship type*/
}

public int numberOfRelationships(Person fromPerson, RelationshipType fromPersonRelationship) {
/*Function returns the number of people who are related to fromPerson as a fromPersonRelationshiptype */
}

public int numberOfRelationships(Person fromPerson) {
/*Function returns the number of people who are related to fromPerson in any way */
}

public boolean updateRelativesToNewPerson(Person toPerson, RelationshipType toRelationshipType){
/*Updates relations of all relatives of old person to new toRelationshipType of toPerson. If unable to update the records of any of the
relatives, the failure message is logged and the rest of the records are updated*/
}

The class [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/java/org/openmrs/module/changerelationships/web/controller/ChangeRelationshipsManageController.java ChangeRelationshipsManageController] is the controller. This class contains the functions and attributes required for the view and also acts as an interface between the model and view. Code snippet for this class follows
public void manage(ModelMap model) {
/*Function to render the view and add attributes that are accessible in the view*/
}

public String checkPatients(){
/*Function accepts string input of name of person and relationship type and maps it to function in the model that returns the number of
related people*/
}

public String updateRecord(){
/*Function accepts string input of name of new person and new relationship type and maps it to the function in the model that updates the
records to reflect the relationships*/
}

The file [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/webapp/manage.jsp manage.jsp] is responsible for the view and contains 2 forms. One to search for all the related people and the other to confirm the changes that have to be made with respect to the new person/new relationshiptype or both

===Front Controller Pattern===
Similar to the MVC pattern, the [http://en.wikipedia.org/wiki/Front_Controller_pattern Front Controller Pattern] provides a centralized entry point for handling requests.[2]
The class ChangeRelationshipsManageController (link to source code above) demonstrates this design pattern. As all the requests from the manage page are mapped onto functions in this page, this class is the centralized controller in the design.

===Iterator===
[http://en.wikipedia.org/wiki/Iterator_pattern Iterator] is a behavioral design pattern used to implement accessing elements of a list quite frequently in the code. A code snippet example would be

for(Relationship relationship : allRelatedPeople)
{
if(toPerson.equals(relationship.getPersonB()))
{
areAllUpdatesSuccessful = false; //as Person1 related to Person1, so avoid by skipping. Boundary case.
myLogger.print("Unable to update record for " + toPerson);
continue;
}
relationship.setPersonA(toPerson);
relationship.setRelationshipType(toRelationshipType);
personService.saveRelationship(relationship);
}

===Strategy===
Although, this pattern is not a strong contender for a design pattern used for this code, the [http://en.wikipedia.org/wiki/Strategy_pattern Strategy Pattern] does show itself in the controller function checkPatients()

public String checkPatients(@ModelAttribute("patientSearch") PatientSearch patientSearch){
if(fromPersonRelation.equals("All")) //in case all relations of a person have to be changed call
{ // a different overloaded function
noOfRelations = changeRelationshipService.numberOfRelationships(fromPersonObject);
}
else
{
RelationshipType fromPersonOldRelationshipTypeObject =
changeRelationshipService.findRelationshipTypeFromInput(fromPersonRelation);
noOfRelations = changeRelationshipService.numberOfRelationships(fromPersonObject,
fromPersonOldRelationshipTypeObject);
}
}

Depending on the input relationship type selected, two different functions are used to find all the related people. There may not a be a significantly different algorithm used to find the result, but at the database layer, the queries are different.

==Testing==
The framework used here for testing is [http://junit.org/ JUnit4]
All the code for the test functions are at [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/api/src/test/java/org/openmrs/module/changerelationships/api/ChangeRelationshipsServiceTest.java ChangeRelationshipsServiceTest.java]

The test class consists of simple unit tests to test the working of each function used in the ChangeRelationshipService class.
===Setup()===
The setup() function is the one responsible for setting up the background before testing all the functions. It initializes all the objects used for testing later. The code for setup() is as
private void setup()
{
personService = Context.getPersonService();
this.testCangeRelationshipService = Context.getService(ChangeRelationshipsService.class);
this.testPeople = new ArrayList();
this.testRelations = new ArrayList();
this.testRelationshipTypes = new ArrayList();
}

===Test Data===
The createTestPeopleAndRelations() functions is similar to the setup function, as it too sets up the background data required for some of the testing, but since not all of the unit tests require a sample data, they are in a separate function and only those functions that require the data call them. Code snippet for the function :
private void createTestPeopleAndRelations()
{
setup();
testPeople.add(createAndSavePerson("Person1", "For1", "Testing1", "Male", 1967, 8,3 ));
testPeople.add(createAndSavePerson("Person2", "For2", "Testing2", "Male", 1967, 8,3 ));
//some more sample person objects
testRelationshipTypes.add(createNewRelationType("TestRType1", "TestRType2"));
//some more sample relationshiptypes objects
testRelations.add(new Relationship(testPeople.get(0), testPeople.get(1), testRelationshipTypes.get(0) ));
//some more sample relationships objects
}

Similarly the function deleteDataCreatedForTests() is a cleanup function that removes all the data created specifically for the tests. Code snippet for the function :
private void deleteDataCreatedForTests() {
/*Purge all relations*/
/*Purge all relationshipTypes*/
/*Purge all persons*/
}

The functions createNewRelationType() and createAndSavePerson() are helper functions for the test data setup functions mentioned above. The createAndSavePerson() saves each person to the database while the createNewRelationType() function saves each new relationship type to the database

===Unit test : shouldSetupContext() and shouldSetupPersonService()===
Makes sure that the service objects are initialized and not null.
public void shouldSetupContext() {
assertNotNull(Context.getService(ChangeRelationshipsService.class));
}

public void shouldSetupPersonService(){
setup();

===Unit test : getPersonObjectFromInputnameTest ===
Asserts that the function getPersonObjectFromInputname() returns exactly one person in case a record matching the given name is found, else returns a record not found error
public void getPersonObjectFromInputnameTest()
{
setup();
Person testPerson = createAndSavePerson("Person4", "For4", "Testing4", "Male", 1909, 12, 12);
Person testPerson2 = this.testCangeRelationshipService.getPersonObjectFromInputname(testPerson.getFamilyName());
assertNotNull(testPerson2);
assertArrayEquals(testPerson2.getFamilyName().toCharArray(), testPerson.getFamilyName().toCharArray());
//Some more similar test cases
}

===Unit test : findRelationshipTypeFromInputTest()===
Asserts that the function findRelationshipTypeFromInputTest() returns the relationship type in case a record matching the given type name is found, else returns a record not found error.
public void findRelationshipTypeFromInputTest()
{
setup();
String relationName;
List<RelationshipType> testTypes = personService.getAllRelationshipTypes();
for(RelationshipType trstype : testTypes)
{
relationName = trstype.getaIsToB() + "/" + trstype.getbIsToA();
assertNotNull(this.testCangeRelationshipService.findRelationshipTypeFromInput(relationName));
}
}

===unit Test : numberOfRelationshipGivenPersonAndRelationshipTypeTest()===
Tests wether the function numberOfRelationships() returns the right number of related people given the name of a person and the relationship type.
public void numberOfRelationshipGivenPersonAndRelationshipTypeTest()
{
setup();
createTestPeopleAndRelations();
assertEquals(3, this.testCangeRelationshipService.numberOfRelationships(testPeople.get(0), testRelationshipTypes.get(0)));
}

===Unit Test : numberOfRelationshipsWhenAllSelected()===
In case the user chose to change all the relationships for a given person, this test case checks to see if the function numberOfRelationships() returns the right number of people related to the given person in any possible way.
public void numberOfRelationshipsWhenAllSelected()
{
setup();
createTestPeopleAndRelations();
assertEquals(4, this.testCangeRelationshipService.numberOfRelationships(testPeople.get(0)));
assertEquals(0, this.testCangeRelationshipService.numberOfRelationships(testPeople.get(3)));
deleteDataCreatedForTests();
}

===Unit Test : updateRelativesToNewPersonTest()===
Checks if the required updates are being made in the database correctly
public void updateRelativesToNewPersonTest()
{
setup();
createTestPeopleAndRelations();
this.testCangeRelationshipService.numberOfRelationships(testPeople.get(0), testRelationshipTypes.get(1));
boolean updateSuccessful = this.testCangeRelationshipService.updateRelativesToNewPerson(testPeople.get(2), testRelationshipTypes.get(0));
assertTrue(updateSuccessful);
this.testCangeRelationshipService.numberOfRelationships(testPeople.get(0));
updateSuccessful = this.testCangeRelationshipService.updateRelativesToNewPerson(testPeople.get(2), testRelationshipTypes.get(0));
assertFalse(updateSuccessful);
deleteDataCreatedForTests();
}

==References==
[1] [http://domino.watson.ibm.com/library/cyberdig.nsf/1e4115aea78b6e7c85256b360066f0d4/696cfba5d4b1e68985256a1e00626e27!OpenDocument Model View Controller]

[2] [http://en.wikipedia.org/wiki/Front_Controller_pattern Front Controller Pattern]

[3] [http://en.wikipedia.org/wiki/Iterator_pattern Iterator]

CSC/ECE 517 Spring 2013/OSS M604

2013-03-23T14:17:05Z

Ashray:

=OpenMRS Change Patient Relationships=

== README ==
The design document for the project can be found at [https://wiki.openmrs.org/display/projects/Change+relationship+for+multiple+patients+at+once]

The project is currently hosted at a long term VCL image found at [http://152.46.17.15:8081/openmrs-standalone/index.htm]

The code for our module is hosted on github at [https://github.com/ashrayn/openmrs-module-m604]

The module's github readme file can be seen at [https://github.com/ashrayn/openmrs-module-m604/blob/master/README.txt]

Quick Start:
<ol><li>Login to OpenMRS with user:Admin password:Admin123.</li>
<li>Click the 'Administration' button in the top-right corner.</li>
<li>In the bottom-right corner, under 'patients' there should be a link for "change patient relationships".</li>
<li>Click on the 'change patient relationships' link</li>
<li>The content of the change patient relationships module should be displayed.</li></ol>

To see a list of possible patients, it may be useful to open a separate tab with the 'Find/Create Patient" menu from the main menu bar.

==Writing Exercise 2==
===Design Overview of the Module===
OpenMRS modules utilize a modified Spring MVC framework [http://en.wikipedia.org/wiki/Spring_Framework]. The skeleton for the module is first generated using convenient maven[http://maven.apache.org/] artifacts provided here [https://wiki.openmrs.org/display/docs/Creating+Your+First+Module].

The 'change patient relationships' module utilizes 5 basic files.
<ol>
<li>The main page is a .jsp [http://en.wikipedia.org/wiki/JavaServer_Pages] page, the code can be found at [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/webapp/manage.jsp].</li>

<li>This .jsp page is linked to a spring annotated controller [http://javapapers.com/spring/spring-annotation-based-controllers/], the code can be found at [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/java/org/openmrs/module/changerelationships/web/controller/ChangeRelationshipsManageController.java]. The annotated controller maps the manage.jsp form actions using the '@RequestMapping' annotations. This pattern can be observed by viewing the manage.jsp code and comparing the <form> tags to the @RequestMapping annotations in the java code.</li>

<li/><li>The controller along with the spring framework link the form actions from the 'manage.jsp' page to java objects defined in the following .java files. [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/java/org/openmrs/module/changerelationships/PatientSearch.java] and [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/java/org/openmrs/module/changerelationships/UpdateRecord.java]</li>

<li>The module utilizes OpenMRS's services infrastructure to create services with the following code [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/api/src/main/java/org/openmrs/module/changerelationships/api/impl/ChangeRelationshipsServiceImpl.java]. The services found within this class are retrieved from the OpenMRS context object inside of the above controller code (#2). The ChangePatientRelationshipsServiceImpl.java class utilizes OpenMRS database APIs [https://wiki.openmrs.org/display/docs/API] to actually change the patient data in the OpenMRS database. </li>
</ol>

The entire module is packaged in an OpenMRS .omod file using maven and pre-created packaging scripts. The .omod file can be found here [https://github.com/ashrayn/openmrs-module-m604/tree/master/changerelationships/omod/target] and installed into any OpenMRS server using the 'Administration'>Manage modules page.

===Object-Oriented Design Principles===
Encapsulation
 
There were several instances of encapsulation used through out our implementation code in the OpenMRS module. For example, to get access to relationships between people in the database in OpenMRS, we first had to use the Context class to get a PersonService object type and then use that object type to access a list of relationships:
personService = Context.getPersonService();
Here, getPersonService() is a static method in class Context that doesn't require instantiating a Context object to call the method. getPersonService() can be directly used as a class method without having to know the details of how the method has been implemented and designed.
 
Another example is making helper methods and instance variables private.
private Person getPersonOut(List<Relationship> relationshipList, String nameOut)
This is a helper method to the changePatientRelationships() method that helps locate the Person object for updating the patient relationship. As it is not directly used in the manage.jsp page for the user-interface, it is made private to restrict access to it.

private ChangeRelationshipsDAO dao;
private List<Person> people;
private List<Relationship> allRelatedPeople;
private List<RelationshipType> existingRelationshipTypes;
private int noOfRelatedPeople;
These instance variables are also made private in our module class to prevent the potential corruption of data if they were to be accessed publicly.
 
 
Open-Closed Principle
 
In the OpenMRS module, existing classes that had already been tested were not modified, which exemplifies the open-closed principle [http://en.wikipedia.org/wiki/Open/closed_principle]. This module is an extension of the OpenMRS functionality. Our ChangeRelationshipsServiceImpl class is an added class to specifically add the functionality of being able to update the relationships of several patients at one time. Specifically, in our the ChangeRelationshipServiceImpl, we extend the class BaseOpenmrsService to implement the new functionality:
public class ChangeRelationshipsServiceImpl extends BaseOpenmrsService implements ChangeRelationshipsService

==Design Patterns==
Quite a few design patterns were used to design this module.
===Model View Controller===
As there was significant UI and Database functionality, the use of MVC was inevitable [http://domino.watson.ibm.com/library/cyberdig.nsf/1e4115aea78b6e7c85256b360066f0d4/696cfba5d4b1e68985256a1e00626e27!OpenDocument MVC]
The class [https://github.com/ashrayn/openmrs-module-m604/tree/master/changerelationships/api/src/main/java/org/openmrs/module/changerelationships/api/impl ChangeRelationshipServiceImpl] corresponds to the model. This class contains the functions to fire queries to the database and also insert new records/update existing records. Following is the code snippet for the class
public class ChangeRelationshipsServiceImpl extends BaseOpenmrsService implements ChangeRelationshipsService {

public Person getPersonObjectFromInputname(String fromPerson) {
/*Matches the input string to an existing person object and returns the first person*/
}

public RelationshipType findRelationshipTypeFromInput(String relation) {
/*Matches the input string to an existing relationship type*/
}

public int numberOfRelationships(Person fromPerson, RelationshipType fromPersonRelationship) {
/*Function returns the number of people who are related to fromPerson as a fromPersonRelationshiptype */
}

public int numberOfRelationships(Person fromPerson) {
/*Function returns the number of people who are related to fromPerson in any way */
}

public boolean updateRelativesToNewPerson(Person toPerson, RelationshipType toRelationshipType){
/*Updates relations of all relatives of old person to new toRelationshipType of toPerson. If unable to update the records of any of the
relatives, the failure message is logged and the rest of the records are updated*/
}

The class [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/java/org/openmrs/module/changerelationships/web/controller/ChangeRelationshipsManageController.java ChangeRelationshipsManageController] is the controller. This class contains the functions and attributes required for the view and also acts as an interface between the model and view. Code snippet for this class follows
public void manage(ModelMap model) {
/*Function to render the view and add attributes that are accessible in the view*/
}

public String checkPatients(){
/*Function accepts string input of name of person and relationship type and maps it to function in the model that returns the number of
related people*/
}

public String updateRecord(){
/*Function accepts string input of name of new person and new relationship type and maps it to the function in the model that updates the
records to reflect the relationships*/
}

The file [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/webapp/manage.jsp manage.jsp] is responsible for the view and contains 2 forms. One to search for all the related people and the other to confirm the changes that have to be made with respect to the new person/new relationshiptype or both

===Front Controller Pattern===
Similar to the MVC pattern, the [http://en.wikipedia.org/wiki/Front_Controller_pattern Front Controller Pattern] provides a centralized entry point for handling requests.[2]
The class ChangeRelationshipsManageController (link to source code above) demonstrates this design pattern. As all the requests from the manage page are mapped onto functions in this page, this class is the centralized controller in the design.

===Iterator===
[http://en.wikipedia.org/wiki/Iterator_pattern Iterator] is a behavioral design pattern used to implement accessing elements of a list quite frequently in the code. A code snippet example would be

for(Relationship relationship : allRelatedPeople)
{
if(toPerson.equals(relationship.getPersonB()))
{
areAllUpdatesSuccessful = false; //as Person1 related to Person1, so avoid by skipping. Boundary case.
myLogger.print("Unable to update record for " + toPerson);
continue;
}
relationship.setPersonA(toPerson);
relationship.setRelationshipType(toRelationshipType);
personService.saveRelationship(relationship);
}

===Strategy===
Although, this pattern is not a strong contender for a design pattern used for this code, the [http://en.wikipedia.org/wiki/Strategy_pattern Strategy Pattern] does show itself in the controller function checkPatients()

public String checkPatients(@ModelAttribute("patientSearch") PatientSearch patientSearch){
if(fromPersonRelation.equals("All")) //in case all relations of a person have to be changed call
{ // a different overloaded function
noOfRelations = changeRelationshipService.numberOfRelationships(fromPersonObject);
}
else
{
RelationshipType fromPersonOldRelationshipTypeObject =
changeRelationshipService.findRelationshipTypeFromInput(fromPersonRelation);
noOfRelations = changeRelationshipService.numberOfRelationships(fromPersonObject,
fromPersonOldRelationshipTypeObject);
}
}

Depending on the input relationship type selected, two different functions are used to find all the related people. There may not a be a significantly different algorithm used to find the result, but at the database layer, the queries are different.

==Testing==
The framework used here for testing is [http://junit.org/ JUnit4]
All the code for the test functions are at [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/api/src/test/java/org/openmrs/module/changerelationships/api/ChangeRelationshipsServiceTest.java ChangeRelationshipsServiceTest.java]

The test class consists of simple unit tests to test the working of each function used in the ChangeRelationshipService class.
===Setup()===
The setup() function is the one responsible for setting up the background before testing all the functions. It initializes all the objects used for testing later. The code for setup() is as
private void setup()
{
personService = Context.getPersonService();
this.testCangeRelationshipService = Context.getService(ChangeRelationshipsService.class);
this.testPeople = new ArrayList();
this.testRelations = new ArrayList();
this.testRelationshipTypes = new ArrayList();
}

===Test Data===
The createTestPeopleAndRelations() functions is similar to the setup function, as it too sets up the background data required for some of the testing, but since not all of the unit tests require a sample data, they are in a separate function and only those functions that require the data call them. Code snippet for the function :
private void createTestPeopleAndRelations()
{
setup();
testPeople.add(createAndSavePerson("Person1", "For1", "Testing1", "Male", 1967, 8,3 ));
testPeople.add(createAndSavePerson("Person2", "For2", "Testing2", "Male", 1967, 8,3 ));
//some more sample person objects
testRelationshipTypes.add(createNewRelationType("TestRType1", "TestRType2"));
//some more sample relationshiptypes objects
testRelations.add(new Relationship(testPeople.get(0), testPeople.get(1), testRelationshipTypes.get(0) ));
//some more sample relationships objects
}

Similarly the function deleteDataCreatedForTests() is a cleanup function that removes all the data created specifically for the tests. Code snippet for the function :
private void deleteDataCreatedForTests() {
/*Purge all relations*/
/*Purge all relationshipTypes*/
/*Purge all persons*/
}

The functions createNewRelationType() and createAndSavePerson() are helper functions for the test data setup functions mentioned above. The createAndSavePerson() saves each person to the database while the createNewRelationType() function saves each new relationship type to the database

===Unit test : shouldSetupContext() and shouldSetupPersonService()===
Makes sure that the service objects are initialized and not null.
public void shouldSetupContext() {
assertNotNull(Context.getService(ChangeRelationshipsService.class));
}

public void shouldSetupPersonService(){
setup();

===Unit test : getPersonObjectFromInputnameTest ===
Asserts that the function getPersonObjectFromInputname() returns exactly one person in case a record matching the given name is found, else returns a record not found error
public void getPersonObjectFromInputnameTest()
{
setup();
Person testPerson = createAndSavePerson("Person4", "For4", "Testing4", "Male", 1909, 12, 12);
Person testPerson2 = this.testCangeRelationshipService.getPersonObjectFromInputname(testPerson.getFamilyName());
assertNotNull(testPerson2);
assertArrayEquals(testPerson2.getFamilyName().toCharArray(), testPerson.getFamilyName().toCharArray());
//Some more similar test cases
}

===Unit test : findRelationshipTypeFromInputTest()===
Asserts that the function findRelationshipTypeFromInputTest() returns the relationship type in case a record matching the given type name is found, else returns a record not found error.
public void findRelationshipTypeFromInputTest()
{
setup();
String relationName;
List<RelationshipType> testTypes = personService.getAllRelationshipTypes();
for(RelationshipType trstype : testTypes)
{
relationName = trstype.getaIsToB() + "/" + trstype.getbIsToA();
assertNotNull(this.testCangeRelationshipService.findRelationshipTypeFromInput(relationName));
}
}

===unit Test : numberOfRelationshipGivenPersonAndRelationshipTypeTest()===
Tests wether the function numberOfRelationships() returns the right number of related people given the name of a person and the relationship type.
public void numberOfRelationshipGivenPersonAndRelationshipTypeTest()
{
setup();
createTestPeopleAndRelations();
assertEquals(3, this.testCangeRelationshipService.numberOfRelationships(testPeople.get(0), testRelationshipTypes.get(0)));
}

===Unit Test : numberOfRelationshipsWhenAllSelected()===
In case the user chose to change all the relationships for a given person, this test case checks to see if the function numberOfRelationships() returns the right number of people related to the given person in any possible way.
public void numberOfRelationshipsWhenAllSelected()
{
setup();
createTestPeopleAndRelations();
assertEquals(4, this.testCangeRelationshipService.numberOfRelationships(testPeople.get(0)));
assertEquals(0, this.testCangeRelationshipService.numberOfRelationships(testPeople.get(3)));
deleteDataCreatedForTests();
}

===Unit Test : updateRelativesToNewPersonTest()===
Checks if the required updates are being made in the database correctly
public void updateRelativesToNewPersonTest()
{
setup();
createTestPeopleAndRelations();
this.testCangeRelationshipService.numberOfRelationships(testPeople.get(0), testRelationshipTypes.get(1));
boolean updateSuccessful = this.testCangeRelationshipService.updateRelativesToNewPerson(testPeople.get(2), testRelationshipTypes.get(0));
assertTrue(updateSuccessful);
this.testCangeRelationshipService.numberOfRelationships(testPeople.get(0));
updateSuccessful = this.testCangeRelationshipService.updateRelativesToNewPerson(testPeople.get(2), testRelationshipTypes.get(0));
assertFalse(updateSuccessful);
deleteDataCreatedForTests();
}

==References==
[1] [http://domino.watson.ibm.com/library/cyberdig.nsf/1e4115aea78b6e7c85256b360066f0d4/696cfba5d4b1e68985256a1e00626e27!OpenDocument Model View Controller]

[2] [http://en.wikipedia.org/wiki/Front_Controller_pattern Front Controller Pattern]

[3] [http://en.wikipedia.org/wiki/Iterator_pattern Iterator]

CSC/ECE 517 Spring 2013/OSS M604

2013-03-22T04:40:32Z

Ashray:

=OpenMRS Change Patient Relationships=

== README ==
The design document for the project can be found at [https://wiki.openmrs.org/display/projects/Change+relationship+for+multiple+patients+at+once]

The project is currently hosted at a long term VCL image found at [http://152.46.17.15:8081/openmrs-standalone/index.htm]

The code for our module is hosted on github at [https://github.com/ashrayn/openmrs-module-m604]

To Use:
<ol><li>Login with user:Admin password:Admin123.</li>
<li>Click the 'Administration' button in the top-right corner.</li>
<li>In the bottom-right corner, under 'patients' there should be a link for "change patient relationships".</li>
<li>Click on the 'change patient relationships' link</li>
<li>The content of the change patient relationships module should be displayed.</li></ol>

To see a list of possible patients, it may be useful to open a separate tab with the 'Find/Create Patient" menu from the main menu bar.

==Writing Exercise 2==
===Design Overview of the Module===
OpenMRS modules utilize a modified Spring MVC framework [http://en.wikipedia.org/wiki/Spring_Framework]. The skeleton for the module is first generated using convenient maven[http://maven.apache.org/] artifacts provided here [https://wiki.openmrs.org/display/docs/Creating+Your+First+Module].

The 'change patient relationships' module utilizes 5 basic files.
<ol>
<li>The main page is a .jsp [http://en.wikipedia.org/wiki/JavaServer_Pages] page, the code can be found at [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/webapp/manage.jsp].</li>

<li>This .jsp page is linked to a spring annotated controller [http://javapapers.com/spring/spring-annotation-based-controllers/], the code can be found at [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/java/org/openmrs/module/changerelationships/web/controller/ChangeRelationshipsManageController.java]. The annotated controller maps the manage.jsp form actions using the '@RequestMapping' annotations. This pattern can be observed by viewing the manage.jsp code and comparing the <form> tags to the @RequestMapping annotations in the java code.</li>

<li/><li>The controller along with the spring framework link the form actions from the 'manage.jsp' page to java objects defined in the following .java files. [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/java/org/openmrs/module/changerelationships/PatientSearch.java] and [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/java/org/openmrs/module/changerelationships/UpdateRecord.java]</li>

<li>The module utilizes OpenMRS's services infrastructure to create services with the following code [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/api/src/main/java/org/openmrs/module/changerelationships/api/impl/ChangeRelationshipsServiceImpl.java]. The services found within this class are retrieved from the OpenMRS context object inside of the above controller code (#2). The ChangePatientRelationshipsServiceImpl.java class utilizes OpenMRS database APIs [https://wiki.openmrs.org/display/docs/API] to actually change the patient data in the OpenMRS database. </li>
</ol>

The entire module is packaged in an OpenMRS .omod file using maven and pre-created packaging scripts. The .omod file can be found here [https://github.com/ashrayn/openmrs-module-m604/tree/master/changerelationships/omod/target] and installed into any OpenMRS server using the 'Administration'>Manage modules page.

===Object-Oriented Design Principles Used===
Encapsulation
 
There were several instances of encapsulation used through out our implementation code in the OpenMRS module. For example, to get access to relationships between people in the database in OpenMRS, we first had to use the Context class to get a PersonService object type and then use that object type to access a list of relationships:
personService = Context.getPersonService();
Here, getPersonService() is a static method in class Context that doesn't require instantiating a Context object to call the method. getPersonService() can be directly used as a class method without having to know the details of how the method has been implemented and designed.
 
Another example is making helper methods and instance variables private.
private Person getPersonOut(List<Relationship> relationshipList, String nameOut)
This is a helper method to the changePatientRelationships() method that helps locate the Person object for updating the patient relationship. As it is not directly used in the manage.jsp page for the user-interface, it is made private to restrict access to it.

private ChangeRelationshipsDAO dao;
private List<Person> people;
private List<Relationship> allRelatedPeople;
private List<RelationshipType> existingRelationshipTypes;
private int noOfRelatedPeople;
These instance variables are also made private in our module class to prevent the potential corruption of data if they were to be accessed publicly.
 
 
Open-Closed Principle
 
In the OpenMRS module, existing classes that had already been tested were not modified, which exemplifies the open-closed principle [http://en.wikipedia.org/wiki/Open/closed_principle]. This module is an extension of the OpenMRS functionality. Our ChangeRelationshipsServiceImpl class is an added class to specifically add the functionality of being able to update the relationships of several patients at one time. Specifically, in our the ChangeRelationshipServiceImpl, we extend the class BaseOpenmrsService to implement the new functionality:
public class ChangeRelationshipsServiceImpl extends BaseOpenmrsService implements ChangeRelationshipsService

==Design Patterns==
Quite a few design patterns were used to design this module.
===Model View Controller===
As there was significant UI and Database functionality, the use of MVC was inevitable [http://domino.watson.ibm.com/library/cyberdig.nsf/1e4115aea78b6e7c85256b360066f0d4/696cfba5d4b1e68985256a1e00626e27!OpenDocument MVC]
The class [https://github.com/ashrayn/openmrs-module-m604/tree/master/changerelationships/api/src/main/java/org/openmrs/module/changerelationships/api/impl ChangeRelationshipServiceImpl] corresponds to the model. This class contains the functions to fire queries to the database and also insert new records/update existing records. Following is the code snippet for the class
public class ChangeRelationshipsServiceImpl extends BaseOpenmrsService implements ChangeRelationshipsService {

public Person getPersonObjectFromInputname(String fromPerson) {
/*Matches the input string to an existing person object and returns the first person*/
}

public RelationshipType findRelationshipTypeFromInput(String relation) {
/*Matches the input string to an existing relationship type*/
}

public int numberOfRelationships(Person fromPerson, RelationshipType fromPersonRelationship) {
/*Function returns the number of people who are related to fromPerson as a fromPersonRelationshiptype */
}

public int numberOfRelationships(Person fromPerson) {
/*Function returns the number of people who are related to fromPerson in any way */
}

public boolean updateRelativesToNewPerson(Person toPerson, RelationshipType toRelationshipType){
/*Updates relations of all relatives of old person to new toRelationshipType of toPerson. If unable to update the records of any of the
relatives, the failure message is logged and the rest of the records are updated*/
}

The class [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/java/org/openmrs/module/changerelationships/web/controller/ChangeRelationshipsManageController.java ChangeRelationshipsManageController] is the controller. This class contains the functions and attributes required for the view and also acts as an interface between the model and view. Code snippet for this class follows
public void manage(ModelMap model) {
/*Function to render the view and add attributes that are accessible in the view*/
}

public String checkPatients(){
/*Function accepts string input of name of person and relationship type and maps it to function in the model that returns the number of
related people*/
}

public String updateRecord(){
/*Function accepts string input of name of new person and new relationship type and maps it to the function in the model that updates the
records to reflect the relationships*/
}

The file [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/webapp/manage.jsp manage.jsp] is responsible for the view and contains 2 forms. One to search for all the related people and the other to confirm the changes that have to be made with respect to the new person/new relationshiptype or both

===Front Controller Pattern===
Similar to the MVC pattern, the [http://en.wikipedia.org/wiki/Front_Controller_pattern Front Controller Pattern] provides a centralized entry point for handling requests.[2]
The class ChangeRelationshipsManageController (link to source code above) demonstrates this design pattern. As all the requests from the manage page are mapped onto functions in this page, this class is the centralized controller in the design.

===Iterator===
[http://en.wikipedia.org/wiki/Iterator_pattern Iterator] is a behavioral design pattern used to implement accessing elements of a list quite frequently in the code. A code snippet example would be

for(Relationship relationship : allRelatedPeople)
{
if(toPerson.equals(relationship.getPersonB()))
{
areAllUpdatesSuccessful = false; //as Person1 related to Person1, so avoid by skipping. Boundary case.
myLogger.print("Unable to update record for " + toPerson);
continue;
}
relationship.setPersonA(toPerson);
relationship.setRelationshipType(toRelationshipType);
personService.saveRelationship(relationship);
}

===Strategy===
Although, this pattern is not a strong contender for a design pattern used for this code, the [http://en.wikipedia.org/wiki/Strategy_pattern Strategy Pattern] does show itself in the controller function checkPatients()

public String checkPatients(@ModelAttribute("patientSearch") PatientSearch patientSearch){
if(fromPersonRelation.equals("All")) //in case all relations of a person have to be changed call
{ // a different overloaded function
noOfRelations = changeRelationshipService.numberOfRelationships(fromPersonObject);
}
else
{
RelationshipType fromPersonOldRelationshipTypeObject =
changeRelationshipService.findRelationshipTypeFromInput(fromPersonRelation);
noOfRelations = changeRelationshipService.numberOfRelationships(fromPersonObject,
fromPersonOldRelationshipTypeObject);
}
}

Depending on the input relationship type selected, two different functions are used to find all the related people. There may not a be a significantly different algorithm used to find the result, but at the database layer, the queries are different.

==Testing==
The framework used here for testing is [http://junit.org/ JUnit4]
All the code for the test functions are at [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/api/src/test/java/org/openmrs/module/changerelationships/api/ChangeRelationshipsServiceTest.java ChangeRelationshipsServiceTest.java]

The test class consists of simple unit tests to test the working of each function used in the ChangeRelationshipService class.
===Setup()===
The setup() function is the one responsible for setting up the background before testing all the functions. It initializes all the objects used for testing later. The code for setup() is as

===Test Data===
The createTestPeopleAndRelations() functions is similar to the setup function, as it too sets up the background data required for some of the testing, but since not all of the unit tests require a sample data, they are in a separate function and only those functions that require the data call them. Code snippet for the function :

Similarly the function deleteDataCreatedForTests() is a cleanup function that removes all the data created specifically for the tests. Code snippet for the function :

The functions createNewRelationType() and createAndSavePerson() are helper functions for the test data setup functions mentioned above. The createAndSavePerson() saves each person to the database while the createNewRelationType() function saves each new relationship type tothe database

===Unit test : shouldSetupContext() and shouldSetupPersonService()===
Makes sure that the service objects are initialized and not null.

===Unit test : getPersonObjectFromInputnameTest ===
Asserts that the function getPersonObjectFromInputname() returns exactly one person in case a record matching the given name is found, else returns a record not found error

===Unit test : findRelationshipTypeFromInputTest()===
Asserts that the function findRelationshipTypeFromInputTest() returns the relationship type in case a record matching the given type name is found, else returns a record not found error.

===unit Test : numberOfRelationshipGivenPersonAndRelationshipTypeTest()===
Tests wether the function numberOfRelationships() returns the right number of related people given the name of a person and the relationship type.

===unit Test : numberOfRelationshipsWhenAllSelected()===
In case the user chose to change all the relationships for a given person, this test case checks to see if the function numberOfRelationships() returns the right number of people related to the given person in any possible way.

==References==
[1] [http://domino.watson.ibm.com/library/cyberdig.nsf/1e4115aea78b6e7c85256b360066f0d4/696cfba5d4b1e68985256a1e00626e27!OpenDocument Model View Controller]
[2] [http://en.wikipedia.org/wiki/Front_Controller_pattern Front Controller Pattern]
[3] [http://en.wikipedia.org/wiki/Iterator_pattern Iterator]

CSC/ECE 517 Spring 2013/OSS M604

2013-03-22T04:28:41Z

Ashray:

=OpenMRS Change Patient Relationships=

== README ==
The design document for the project can be found at [https://wiki.openmrs.org/display/projects/Change+relationship+for+multiple+patients+at+once]

The project is currently hosted at a long term VCL image found at [http://152.46.17.15:8081/openmrs-standalone/index.htm]

The code for our module is hosted on github at [https://github.com/ashrayn/openmrs-module-m604]

To Use:
<ol><li>Login with user:Admin password:Admin123.</li>
<li>Click the 'Administration' button in the top-right corner.</li>
<li>In the bottom-right corner, under 'patients' there should be a link for "change patient relationships".</li>
<li>Click on the 'change patient relationships' link</li>
<li>The content of the change patient relationships module should be displayed.</li></ol>

To see a list of possible patients, it may be useful to open a separate tab with the 'Find/Create Patient" menu from the main menu bar.

==Writing Exercise 2==
===Design Overview of the Module===
OpenMRS modules utilize a modified Spring MVC framework [http://en.wikipedia.org/wiki/Spring_Framework]. The skeleton for the module is first generated using convenient maven[http://maven.apache.org/] artifacts provided here [https://wiki.openmrs.org/display/docs/Creating+Your+First+Module].

The 'change patient relationships' module utilizes 5 basic files.
<ol>
<li>The main page is a .jsp [http://en.wikipedia.org/wiki/JavaServer_Pages] page, the code can be found at [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/webapp/manage.jsp].</li>

<li>This .jsp page is linked to a spring annotated controller [http://javapapers.com/spring/spring-annotation-based-controllers/], the code can be found at [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/java/org/openmrs/module/changerelationships/web/controller/ChangeRelationshipsManageController.java]. The annotated controller maps the manage.jsp form actions using the '@RequestMapping' annotations. This pattern can be observed by viewing the manage.jsp code and comparing the <form> tags to the @RequestMapping annotations in the java code.</li>

<li/><li>The controller along with the spring framework link the form actions from the 'manage.jsp' page to java objects defined in the following .java files. [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/java/org/openmrs/module/changerelationships/PatientSearch.java] and [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/java/org/openmrs/module/changerelationships/UpdateRecord.java]</li>

<li>The module utilizes OpenMRS's services infrastructure to create services with the following code [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/api/src/main/java/org/openmrs/module/changerelationships/api/impl/ChangeRelationshipsServiceImpl.java]. The services found within this class are retrieved from the OpenMRS context object inside of the above controller code (#2). The ChangePatientRelationshipsServiceImpl.java class utilizes OpenMRS database APIs [https://wiki.openmrs.org/display/docs/API] to actually change the patient data in the OpenMRS database. </li>
</ol>

The entire module is packaged in an OpenMRS .omod file using maven and pre-created packaging scripts. The .omod file can be found here [https://github.com/ashrayn/openmrs-module-m604/tree/master/changerelationships/omod/target] and installed into any OpenMRS server using the 'Administration'>Manage modules page.

===Object-Oriented Design Principles Used===
Encapsulation
 
There were several instances of encapsulation used through out our implementation code in the OpenMRS module. For example, to get access to relationships between people in the database in OpenMRS, we first had to use the Context class to get a PersonService object type and then use that object type to access a list of relationships:
personService = Context.getPersonService();
Here, getPersonService() is a static method in class Context that doesn't require instantiating a Context object to call the method. getPersonService() can be directly used as a class method without having to know the details of how the method has been implemented and designed.
 
Another example is making helper methods and instance variables private.
private Person getPersonOut(List<Relationship> relationshipList, String nameOut)
This is a helper method to the changePatientRelationships() method that helps locate the Person object for updating the patient relationship. As it is not directly used in the manage.jsp page for the user-interface, it is made private to restrict access to it.

private ChangeRelationshipsDAO dao;
private List<Person> people;
private List<Relationship> allRelatedPeople;
private List<RelationshipType> existingRelationshipTypes;
private int noOfRelatedPeople;
These instance variables are also made private in our module class to prevent the potential corruption of data if they were to be accessed publicly.
 
 
Open-Closed Principle
 
In the OpenMRS module, existing classes that had already been tested were not modified, which exemplifies the open-closed principle [http://en.wikipedia.org/wiki/Open/closed_principle]. This module is an extension of the OpenMRS functionality. Our ChangeRelationshipsServiceImpl class is an added class to specifically add the functionality of being able to update the relationships of several patients at one time. Specifically, in our the ChangeRelationshipServiceImpl, we extend the class BaseOpenmrsService to implement the new functionality:
public class ChangeRelationshipsServiceImpl extends BaseOpenmrsService implements ChangeRelationshipsService

==Design Patterns==
Quite a few design patterns were used to design this module.
===Model View Controller===
As there was significant UI and Database functionality, the use of MVC was inevitable [http://domino.watson.ibm.com/library/cyberdig.nsf/1e4115aea78b6e7c85256b360066f0d4/696cfba5d4b1e68985256a1e00626e27!OpenDocument MVC]
The class [https://github.com/ashrayn/openmrs-module-m604/tree/master/changerelationships/api/src/main/java/org/openmrs/module/changerelationships/api/impl ChangeRelationshipServiceImpl] corresponds to the model. This class contains the functions to fire queries to the database and also insert new records/update existing records. Following is the code snippet for the class
public class ChangeRelationshipsServiceImpl extends BaseOpenmrsService implements ChangeRelationshipsService {

public Person getPersonObjectFromInputname(String fromPerson) {
/*Matches the input string to an existing person object and returns the first person*/
}

public RelationshipType findRelationshipTypeFromInput(String relation) {
/*Matches the input string to an existing relationship type*/
}

public int numberOfRelationships(Person fromPerson, RelationshipType fromPersonRelationship) {
/*Function returns the number of people who are related to fromPerson as a fromPersonRelationshiptype */
}

public int numberOfRelationships(Person fromPerson) {
/*Function returns the number of people who are related to fromPerson in any way */
}

public boolean updateRelativesToNewPerson(Person toPerson, RelationshipType toRelationshipType){
/*Updates relations of all relatives of old person to new toRelationshipType of toPerson. If unable to update the records of any of the
relatives, the failure message is logged and the rest of the records are updated*/
}

The class [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/java/org/openmrs/module/changerelationships/web/controller/ChangeRelationshipsManageController.java ChangeRelationshipsManageController] is the controller. This class contains the functions and attributes required for the view and also acts as an interface between the model and view. Code snippet for this class follows
public void manage(ModelMap model) {
/*Function to render the view and add attributes that are accessible in the view*/
}

public String checkPatients(){
/*Function accepts string input of name of person and relationship type and maps it to function in the model that returns the number of
related people*/
}

public String updateRecord(){
/*Function accepts string input of name of new person and new relationship type and maps it to the function in the model that updates the
records to reflect the relationships*/
}

The file [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/omod/src/main/webapp/manage.jsp manage.jsp] is responsible for the view and contains 2 forms. One to search for all the related people and the other to confirm the changes that have to be made with respect to the new person/new relationshiptype or both

===Front Controller Pattern===
Similar to the MVC pattern, the [http://en.wikipedia.org/wiki/Front_Controller_pattern Front Controller Pattern] provides a centralized entry point for handling requests.[2]
The class ChangeRelationshipsManageController (link to source code above) demonstrates this design pattern. As all the requests from the manage page are mapped onto functions in this page, this class is the centralized controller in the design.

===Iterator===
[http://en.wikipedia.org/wiki/Iterator_pattern Iterator] is a behavioral design pattern used to implement accessing elements of a list quite frequently in the code. A code snippet example would be

for(Relationship relationship : allRelatedPeople)
{
if(toPerson.equals(relationship.getPersonB()))
{
areAllUpdatesSuccessful = false; //as Person1 related to Person1, so avoid by skipping. Boundary case.
myLogger.print("Unable to update record for " + toPerson);
continue;
}
relationship.setPersonA(toPerson);
relationship.setRelationshipType(toRelationshipType);
personService.saveRelationship(relationship);
}

==Testing==
The framework used here for testing is [http://junit.org/ JUnit4]
All the code for the test functions are at [https://github.com/ashrayn/openmrs-module-m604/blob/master/changerelationships/api/src/test/java/org/openmrs/module/changerelationships/api/ChangeRelationshipsServiceTest.java ChangeRelationshipsServiceTest.java]

The test class consists of simple unit tests to test the working of each function used in the ChangeRelationshipService class.
===Setup()===
The setup() function is the one responsible for setting up the background before testing all the functions. It initializes all the objects used for testing later. The code for setup() is as

===Test Data===
The createTestPeopleAndRelations() functions is similar to the setup function, as it too sets up the background data required for some of the testing, but since not all of the unit tests require a sample data, they are in a separate function and only those functions that require the data call them. Code snippet for the function :

Similarly the function deleteDataCreatedForTests() is a cleanup function that removes all the data created specifically for the tests. Code snippet for the function :

The functions createNewRelationType() and createAndSavePerson() are helper functions for the test data setup functions mentioned above. The createAndSavePerson() saves each person to the database while the createNewRelationType() function saves each new relationship type tothe database

===Unit test : shouldSetupContext() and shouldSetupPersonService()===
Makes sure that the service objects are initialized and not null.

===Unit test : getPersonObjectFromInputnameTest ===
Asserts that the function getPersonObjectFromInputname() returns exactly one person in case a record matching the given name is found, else returns a record not found error

===Unit test : findRelationshipTypeFromInputTest()===
Asserts that the function findRelationshipTypeFromInputTest() returns the relationship type in case a record matching the given type name is found, else returns a record not found error.

===unit Test : numberOfRelationshipGivenPersonAndRelationshipTypeTest()===
Tests wether the function numberOfRelationships() returns the right number of related people given the name of a person and the relationship type.

===unit Test : numberOfRelationshipsWhenAllSelected()===
In case the user chose to change all the relationships for a given person, this test case checks to see if the function numberOfRelationships() returns the right number of people related to the given person in any possible way.

==References==
[1] [http://domino.watson.ibm.com/library/cyberdig.nsf/1e4115aea78b6e7c85256b360066f0d4/696cfba5d4b1e68985256a1e00626e27!OpenDocument Model View Controller]
[2] [http://en.wikipedia.org/wiki/Front_Controller_pattern Front Controller Pattern]
[3] [http://en.wikipedia.org/wiki/Iterator_pattern Iterator]

CSC/ECE 517 Spring 2013/OSS M604

2013-03-22T03:49:18Z

Ashray:

CSC/ECE 517 Spring 2013/OSS M604

2013-03-22T03:44:49Z

Ashray:

CSC/ECE 517 Spring 2013/OSS M604

2013-03-21T22:09:13Z

Ashray:

CSC/ECE 517 Spring 2013/OSS M604

2013-03-21T22:07:58Z

Ashray:

CSC/ECE 517 Spring 2013/OSS M604

2013-03-21T21:46:30Z

Ashray:

CSC/ECE 517 Spring 2013/OSS M604

2013-03-21T21:25:26Z

Ashray:

CSC/ECE 517 Spring 2013/OSS M604

2013-03-21T20:52:49Z

Ashray:

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-15T05:41:54Z

Ashray:

=='''Inheritance'''==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

=='''Means of achieving inheritance'''==
===Classical Inheritance===
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]
[http://expressionflow.com/2007/04/14/reusing-code-by-inheritance/ Image from Expression Flow]

===Prototype Based Inheritance(1)===
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning(3)] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation(2)] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

=='''Classical Inheritance v/s Prototype based inheritance'''==

===Object Creation(1)===
While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

===Using Preexisting modules(5)===

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

===Support for one-of-a-kind objects(5)===

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique
behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for
the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit
from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in
prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

===Elimination of meta-regress(4)===

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its
properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be
defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the
medium truck would inherit this functionality completely. It is not likely to have its own move() function.

===Transfer of state information on extending the functionality of an object(5)===

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps
object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state
from the existing marine corp object to the new Green Beret object.

===Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based(5)===
if you want to [http://en.wikipedia.org/wiki/Cloning_(programming) clone] an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex [http://www.go4expert.com/articles/object-cloning-java-t5424 cloning-logic] for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a
new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class
based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone
the existing delta soldier.

===Prototype based inheritance is more suited for a [http://en.wikipedia.org/wiki/Functional_programming "functional" style of programming](5)===
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be
embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate
function for the object.

===Prototype based inheritance requires dynamic typing whereas the classical based approach does not(4)===
Since objects are being inherited rather than classes, it is necessary that the language support [http://c2.com/cgi/wiki?DynamicTyping dynamic typing], otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman
basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler
error (unless it supported runtime polymorhism).

===Refactorings don't work the same way(5)===
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs /[http://c2.com/cgi/wiki?WhatIsRefactoring refactoring] tools can't really help us since they can't guess our approach.

Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each
of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass.
This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the
3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent
out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member
of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning
occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

===Static typing assurances(5)===
The classical approach offers [http://c2.com/cgi/wiki?StaticTyping static typing] wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

=='''Which is the better approach'''(5)==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical
approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would
seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since
each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it
would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

=='''References'''==
<references/>
[http://en.wikipedia.org/wiki/Prototype-based_programming (1)Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) (2)Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) (3)Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr (4)Work by students from previous semesters]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop (5)advantages-of-prototype-based-oop-over-class-based-oop]
[http://javascript.crockford.com/prototypal.html (6)Prototype based inheritance in javascript]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-15T05:38:07Z

Ashray:

=='''Inheritance'''==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

=='''Means of achieving inheritance'''==
===Classical Inheritance===
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]
[http://expressionflow.com/2007/04/14/reusing-code-by-inheritance/ Image from Expression Flow]

===Prototype Based Inheritance===
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

=='''Classical Inheritance v/s Prototype based inheritance'''==

===Object Creation[]===
While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

===Using Preexisting modules===

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

===Support for one-of-a-kind objects===

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique
behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for
the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit
from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in
prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

===Elimination of meta-regress===

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its
properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be
defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the
medium truck would inherit this functionality completely. It is not likely to have its own move() function.

===Transfer of state information on extending the functionality of an object===

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps
object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state
from the existing marine corp object to the new Green Beret object.

===Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based===
if you want to [http://en.wikipedia.org/wiki/Cloning_(programming) clone] an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex [http://www.go4expert.com/articles/object-cloning-java-t5424 cloning-logic] for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a
new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class
based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone
the existing delta soldier.

===Prototype based inheritance is more suited for a [http://en.wikipedia.org/wiki/Functional_programming "functional" style of programming]===
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be
embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate
function for the object.

===Prototype based inheritance requires dynamic typing whereas the classical based approach does not===
Since objects are being inherited rather than classes, it is necessary that the language support [http://c2.com/cgi/wiki?DynamicTyping dynamic typing], otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman
basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler
error (unless it supported runtime polymorhism).

===Refactorings don't work the same way===
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs /[http://c2.com/cgi/wiki?WhatIsRefactoring refactoring] tools can't really help us since they can't guess our approach.

Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each
of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass.
This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the
3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent
out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member
of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning
occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

===Static typing assurances===
The classical approach offers [http://c2.com/cgi/wiki?StaticTyping static typing] wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

=='''Which is the better approach'''==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical
approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would
seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since
each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it
would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

=='''References'''==
<references/>
[http://en.wikipedia.org/wiki/Prototype-based_programming (1)Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) (2)Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) (3)Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr (4)Work by students from previous semesters]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop (5)advantages-of-prototype-based-oop-over-class-based-oop]
[http://javascript.crockford.com/prototypal.html (6)Prototype based inheritance in javascript]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-15T05:37:15Z

Ashray:

=='''Inheritance'''==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

=='''Means of achieving inheritance'''==
===Classical Inheritance===
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]
[http://expressionflow.com/2007/04/14/reusing-code-by-inheritance/ Image from Expression Flow]

===Prototype Based Inheritance===
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

=='''Classical Inheritance v/s Prototype based inheritance'''==

===Object Creation[]===
While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

===Using Preexisting modules===

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

===Support for one-of-a-kind objects===

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique
behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for
the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit
from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in
prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

===Elimination of meta-regress===

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its
properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be
defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the
medium truck would inherit this functionality completely. It is not likely to have its own move() function.

===Transfer of state information on extending the functionality of an object===

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps
object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state
from the existing marine corp object to the new Green Beret object.

===Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based===
if you want to [http://en.wikipedia.org/wiki/Cloning_(programming) clone] an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex [http://www.go4expert.com/articles/object-cloning-java-t5424 cloning-logic] for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a
new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class
based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone
the existing delta soldier.

===Prototype based inheritance is more suited for a [http://en.wikipedia.org/wiki/Functional_programming "functional" style of programming]===
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be
embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate
function for the object.

===Prototype based inheritance requires dynamic typing whereas the classical based approach does not===
Since objects are being inherited rather than classes, it is necessary that the language support [http://c2.com/cgi/wiki?DynamicTyping dynamic typing], otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman
basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler
error (unless it supported runtime polymorhism).

===Refactorings don't work the same way===
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs /[http://c2.com/cgi/wiki?WhatIsRefactoring refactoring] tools can't really help us since they can't guess our approach.

Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each
of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass.
This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the
3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent
out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member
of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning
occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

===Static typing assurances===
The classical approach offers [http://c2.com/cgi/wiki?StaticTyping static typing] wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

=='''Which is the better approach'''==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical
approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would
seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since
each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it
would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

=='''References'''==
<references/>
[http://en.wikipedia.org/wiki/Prototype-based_programming [1/]Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) [2]Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) [3]Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr [4]Work by students from previous semesters]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop [5]advantages-of-prototype-based-oop-over-class-based-oop]
[http://javascript.crockford.com/prototypal.html [6]Prototype based inheritance in javascript]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-15T05:36:47Z

Ashray:

=='''Inheritance'''==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

=='''Means of achieving inheritance'''==
===Classical Inheritance===
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]
[http://expressionflow.com/2007/04/14/reusing-code-by-inheritance/ Image from Expression Flow]

===Prototype Based Inheritance===
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

=='''Classical Inheritance v/s Prototype based inheritance'''==

===Object Creation[]===
While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

===Using Preexisting modules===

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

===Support for one-of-a-kind objects===

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique
behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for
the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit
from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in
prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

===Elimination of meta-regress===

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its
properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be
defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the
medium truck would inherit this functionality completely. It is not likely to have its own move() function.

===Transfer of state information on extending the functionality of an object===

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps
object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state
from the existing marine corp object to the new Green Beret object.

===Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based===
if you want to [http://en.wikipedia.org/wiki/Cloning_(programming) clone] an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex [http://www.go4expert.com/articles/object-cloning-java-t5424 cloning-logic] for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a
new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class
based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone
the existing delta soldier.

===Prototype based inheritance is more suited for a [http://en.wikipedia.org/wiki/Functional_programming "functional" style of programming]===
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be
embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate
function for the object.

===Prototype based inheritance requires dynamic typing whereas the classical based approach does not===
Since objects are being inherited rather than classes, it is necessary that the language support [http://c2.com/cgi/wiki?DynamicTyping dynamic typing], otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman
basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler
error (unless it supported runtime polymorhism).

===Refactorings don't work the same way===
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs /[http://c2.com/cgi/wiki?WhatIsRefactoring refactoring] tools can't really help us since they can't guess our approach.

Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each
of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass.
This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the
3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent
out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member
of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning
occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

===Static typing assurances===
The classical approach offers [http://c2.com/cgi/wiki?StaticTyping static typing] wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

=='''Which is the better approach'''==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical
approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would
seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since
each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it
would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

=='''References'''==
<references/>
[http://en.wikipedia.org/wiki/Prototype-based_programming [1]Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) [2]Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) [3]Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr [4]Work by students from previous semesters]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop [5]advantages-of-prototype-based-oop-over-class-based-oop]
[http://javascript.crockford.com/prototypal.html [6]Prototype based inheritance in javascript]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-15T05:34:44Z

Ashray:

=='''Inheritance'''==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

=='''Means of achieving inheritance'''==
===Classical Inheritance===
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]
[http://expressionflow.com/2007/04/14/reusing-code-by-inheritance/ Image from Expression Flow]

===Prototype Based Inheritance===
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

=='''Classical Inheritance v/s Prototype based inheritance'''==

[[===Object Creation===]]
While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

===Using Preexisting modules===

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

===Support for one-of-a-kind objects===

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique
behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for
the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit
from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in
prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

===Elimination of meta-regress===

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its
properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be
defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the
medium truck would inherit this functionality completely. It is not likely to have its own move() function.

===Transfer of state information on extending the functionality of an object===

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps
object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state
from the existing marine corp object to the new Green Beret object.

===Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based===
if you want to [http://en.wikipedia.org/wiki/Cloning_(programming) clone] an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex [http://www.go4expert.com/articles/object-cloning-java-t5424 cloning-logic] for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a
new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class
based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone
the existing delta soldier.

===Prototype based inheritance is more suited for a [http://en.wikipedia.org/wiki/Functional_programming "functional" style of programming]===
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be
embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate
function for the object.

===Prototype based inheritance requires dynamic typing whereas the classical based approach does not===
Since objects are being inherited rather than classes, it is necessary that the language support [http://c2.com/cgi/wiki?DynamicTyping dynamic typing], otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman
basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler
error (unless it supported runtime polymorhism).

===Refactorings don't work the same way===
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs /[http://c2.com/cgi/wiki?WhatIsRefactoring refactoring] tools can't really help us since they can't guess our approach.

Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each
of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass.
This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the
3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent
out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member
of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning
occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

===Static typing assurances===
The classical approach offers [http://c2.com/cgi/wiki?StaticTyping static typing] wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

=='''Which is the better approach'''==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical
approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would
seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since
each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it
would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

=='''References'''==
<references/>
[http://en.wikipedia.org/wiki/Prototype-based_programming Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr Work by students from previous semesters]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop advantages-of-prototype-based-oop-over-class-based-oop]
[http://javascript.crockford.com/prototypal.html Prototype based inheritance in javascript]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-15T05:30:56Z

Ashray:

=='''Inheritance'''==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

=='''Means of achieving inheritance'''==
===Classical Inheritance===
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]
[http://expressionflow.com/2007/04/14/reusing-code-by-inheritance/ Image from Expression Flow]

===Prototype Based Inheritance===
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

=='''Classical Inheritance v/s Prototype based inheritance'''==

===Object Creation===
While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

===Using Preexisting modules===

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

===Support for one-of-a-kind objects===

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique
behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for
the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit
from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in
prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

===Elimination of meta-regress===

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its
properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be
defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the
medium truck would inherit this functionality completely. It is not likely to have its own move() function.

===Transfer of state information on extending the functionality of an object===

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps
object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state
from the existing marine corp object to the new Green Beret object.

===Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based===
if you want to [http://en.wikipedia.org/wiki/Cloning_(programming) clone] an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex [http://www.go4expert.com/articles/object-cloning-java-t5424 cloning-logic] for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a
new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class
based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone
the existing delta soldier.

===Prototype based inheritance is more suited for a [http://en.wikipedia.org/wiki/Functional_programming "functional" style of programming]===
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be
embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate
function for the object.

===Prototype based inheritance requires dynamic typing whereas the classical based approach does not===
Since objects are being inherited rather than classes, it is necessary that the language support [http://c2.com/cgi/wiki?DynamicTyping dynamic typing], otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman
basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler
error (unless it supported runtime polymorhism).

===Refactorings don't work the same way===
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs /[http://c2.com/cgi/wiki?WhatIsRefactoring refactoring] tools can't really help us since they can't guess our approach.

Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each
of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass.
This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the
3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent
out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member
of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning
occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

===Static typing assurances===
The classical approach offers [http://c2.com/cgi/wiki?StaticTyping static typing] wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

=='''Which is the better approach'''==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical
approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would
seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since
each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it
would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

=='''References'''==
<references/>
[http://en.wikipedia.org/wiki/Prototype-based_programming Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr Work by students from previous semesters]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop advantages-of-prototype-based-oop-over-class-based-oop]
[http://javascript.crockford.com/prototypal.html Prototype based inheritance in javascript]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-15T05:30:20Z

Ashray:

=='''Inheritance'''==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

=='''Means of achieving inheritance'''==
===Classical Inheritance===
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]
[http://expressionflow.com/2007/04/14/reusing-code-by-inheritance/ Image from Expression Flow|center ]

===Prototype Based Inheritance===
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

=='''Classical Inheritance v/s Prototype based inheritance'''==

===Object Creation===
While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

===Using Preexisting modules===

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

===Support for one-of-a-kind objects===

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique
behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for
the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit
from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in
prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

===Elimination of meta-regress===

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its
properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be
defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the
medium truck would inherit this functionality completely. It is not likely to have its own move() function.

===Transfer of state information on extending the functionality of an object===

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps
object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state
from the existing marine corp object to the new Green Beret object.

===Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based===
if you want to [http://en.wikipedia.org/wiki/Cloning_(programming) clone] an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex [http://www.go4expert.com/articles/object-cloning-java-t5424 cloning-logic] for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a
new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class
based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone
the existing delta soldier.

===Prototype based inheritance is more suited for a [http://en.wikipedia.org/wiki/Functional_programming "functional" style of programming]===
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be
embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate
function for the object.

===Prototype based inheritance requires dynamic typing whereas the classical based approach does not===
Since objects are being inherited rather than classes, it is necessary that the language support [http://c2.com/cgi/wiki?DynamicTyping dynamic typing], otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman
basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler
error (unless it supported runtime polymorhism).

===Refactorings don't work the same way===
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs /[http://c2.com/cgi/wiki?WhatIsRefactoring refactoring] tools can't really help us since they can't guess our approach.

Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each
of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass.
This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the
3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent
out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member
of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning
occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

===Static typing assurances===
The classical approach offers [http://c2.com/cgi/wiki?StaticTyping static typing] wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

=='''Which is the better approach'''==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical
approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would
seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since
each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it
would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

=='''References'''==
<references/>
[http://en.wikipedia.org/wiki/Prototype-based_programming Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr Work by students from previous semesters]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop advantages-of-prototype-based-oop-over-class-based-oop]
[http://javascript.crockford.com/prototypal.html Prototype based inheritance in javascript]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-15T05:21:29Z

Ashray:

=='''Inheritance'''==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

=='''Means of achieving inheritance'''==
===Classical Inheritance===
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]

===Prototype Based Inheritance===
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

=='''Classical Inheritance v/s Prototype based inheritance'''==

===Object Creation===
While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

===Using Preexisting modules===

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

===Support for one-of-a-kind objects===

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique
behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for
the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit
from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in
prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

===Elimination of meta-regress===

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its
properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be
defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the
medium truck would inherit this functionality completely. It is not likely to have its own move() function.

===Transfer of state information on extending the functionality of an object===

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps
object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state
from the existing marine corp object to the new Green Beret object.

===Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based===
if you want to [http://en.wikipedia.org/wiki/Cloning_(programming) clone] an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex [http://www.go4expert.com/articles/object-cloning-java-t5424 cloning-logic] for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a
new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class
based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone
the existing delta soldier.

===Prototype based inheritance is more suited for a [http://en.wikipedia.org/wiki/Functional_programming "functional" style of programming]===
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be
embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate
function for the object.

===Prototype based inheritance requires dynamic typing whereas the classical based approach does not===
Since objects are being inherited rather than classes, it is necessary that the language support [http://c2.com/cgi/wiki?DynamicTyping dynamic typing], otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman
basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler
error (unless it supported runtime polymorhism).

===Refactorings don't work the same way===
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs /[http://c2.com/cgi/wiki?WhatIsRefactoring refactoring] tools can't really help us since they can't guess our approach.

Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each
of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass.
This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the
3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent
out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member
of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning
occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

===Static typing assurances===
The classical approach offers [http://c2.com/cgi/wiki?StaticTyping static typing] wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

=='''Which is the better approach'''==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical
approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would
seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since
each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it
would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

=='''References'''==
<references/>
[http://en.wikipedia.org/wiki/Prototype-based_programming Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr Work by students from previous semesters]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop advantages-of-prototype-based-oop-over-class-based-oop]
[http://javascript.crockford.com/prototypal.html Prototype based inheritance in javascript]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-15T05:20:29Z

Ashray:

=='''Inheritance'''==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

=='''Means of achieving inheritance'''==
===Classical Inheritance===
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]

===Prototype Based Inheritance===
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

=='''Classical Inheritance v/s Prototype based inheritance'''==

===Object Creation===
While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

===Using Preexisting modules===

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

===Support for one-of-a-kind objects===

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique
behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for
the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit
from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in
prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

===Elimination of meta-regress===

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its
properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be
defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the
medium truck would inherit this functionality completely. It is not likely to have its own move() function.

===Transfer of state information on extending the functionality of an object===

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps
object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state
from the existing marine corp object to the new Green Beret object.

===Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based===
if you want to [http://en.wikipedia.org/wiki/Cloning_(programming) clone] an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex [http://www.go4expert.com/articles/object-cloning-java-t5424 cloning-logic] for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a
new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class
based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone
the existing delta soldier.

===Prototype based inheritance is more suited for a [http://en.wikipedia.org/wiki/Functional_programming "functional" style of programming]===
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be
embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate
function for the object.

===Prototype based inheritance requires dynamic typing whereas the classical based approach does not===
Since objects are being inherited rather than classes, it is necessary that the language support [http://c2.com/cgi/wiki?DynamicTyping dynamic typing], otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman
basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler
error (unless it supported runtime polymorhism).

===Refactorings don't work the same way===
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs /[http://c2.com/cgi/wiki?WhatIsRefactoring refactoring] tools can't really help us since they can't guess our approach.

Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each
of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass.
This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the
3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent
out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member
of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning
occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

===Static typing assurances===
The classical approach offers [http://c2.com/cgi/wiki?StaticTyping static typing] wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

==Which is the better approach==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical
approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would
seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since
each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it
would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

==References==
<references/>
[http://en.wikipedia.org/wiki/Prototype-based_programming Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr Work by students from previous semesters]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop advantages-of-prototype-based-oop-over-class-based-oop]
[http://javascript.crockford.com/prototypal.html Prototype based inheritance in javascript]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-15T04:59:16Z

Ashray:

== Inheritance ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

== Means of achieving inheritance ==
===Classical Inheritance===
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]

===Prototype Based Inheritance===
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

==Classical Inheritance v/s Prototype based inheritance==

===Object Creation===
While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

===Using Preexisting modules===

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

===Support for one-of-a-kind objects===

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique
behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for
the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit
from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in
prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

===Elimination of meta-regress===

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its
properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be
defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the
medium truck would inherit this functionality completely. It is not likely to have its own move() function.

===Transfer of state information on extending the functionality of an object===

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps
object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state
from the existing marine corp object to the new Green Beret object.

===Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based===
if you want to [http://en.wikipedia.org/wiki/Cloning_(programming) clone] an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex [http://www.go4expert.com/articles/object-cloning-java-t5424 cloning-logic] for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a
new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class
based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone
the existing delta soldier.

===Prototype based inheritance is more suited for a [http://en.wikipedia.org/wiki/Functional_programming "functional" style of programming]===
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be
embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate
function for the object.

===Prototype based inheritance requires dynamic typing whereas the classical based approach does not===
Since objects are being inherited rather than classes, it is necessary that the language support [http://c2.com/cgi/wiki?DynamicTyping dynamic typing], otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman
basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler
error (unless it supported runtime polymorhism).

===Refactorings don't work the same way===
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs /[http://c2.com/cgi/wiki?WhatIsRefactoring refactoring] tools can't really help us since they can't guess our approach.

Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each
of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass.
This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the
3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent
out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member
of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning
occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

===Static typing assurances===
The classical approach offers [http://c2.com/cgi/wiki?StaticTyping static typing] wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

==Which is the better approach==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical
approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would
seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since
each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it
would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

==References==
<references/>
[http://en.wikipedia.org/wiki/Prototype-based_programming Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr Work by students from previous semesters]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop advantages-of-prototype-based-oop-over-class-based-oop]
[http://javascript.crockford.com/prototypal.html Prototype based inheritance in javascript]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-15T04:56:48Z

Ashray:

== Inheritance ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

== Means of achieving inheritance ==
===Classical Inheritance===
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]

===Prototype Based Inheritance===
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

==Classical Inheritance v/s Prototype based inheritance==

===Object Creation===
While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

===Using Preexisting modules===

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

===Support for one-of-a-kind objects===

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique
behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for
the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit
from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in
prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

===Elimination of meta-regress===

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its
properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be
defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the
medium truck would inherit this functionality completely. It is not likely to have its own move() function.

===Transfer of state information on extending the functionality of an object===

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps
object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state
from the existing marine corp object to the new Green Beret object.

===Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based===
if you want to [ http://en.wikipedia.org/wiki/Cloning_(programming) clone] an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex [http://www.go4expert.com/articles/object-cloning-java-t5424 cloning-logic] for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a
new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class
based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone
the existing delta soldier.

===Prototype based inheritance is more suited for a [http://en.wikipedia.org/wiki/Functional_programming "functional" style of programming]===
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be
embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate
function for the object.

===Prototype based inheritance requires dynamic typing whereas the classical based approach does not===
Since objects are being inherited rather than classes, it is necessary that the language support [http://c2.com/cgi/wiki?DynamicTyping dynamic typing], otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman
basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler
error (unless it supported runtime polymorhism).

===Refactorings don't work the same way===
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs /[http://c2.com/cgi/wiki?WhatIsRefactoring refactoring] tools can't really help us since they can't guess our approach.

Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each
of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass.
This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the
3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent
out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member
of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning
occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

===Static typing assurances===
The classical approach offers [http://c2.com/cgi/wiki?StaticTyping static typing] wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

==Which is the better approach==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical
approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would
seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since
each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it
would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

==References==
<references/>
[http://en.wikipedia.org/wiki/Prototype-based_programming Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr Work by students from previous semesters]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop advantages-of-prototype-based-oop-over-class-based-oop]
[http://javascript.crockford.com/prototypal.html Prototype based inheritance in javascript]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-15T04:55:32Z

Ashray:

== Inheritance ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

== Means of achieving inheritance ==
===Classical Inheritance===
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]

===Prototype Based Inheritance===
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

==Classical Inheritance v/s Prototype based inheritance==

===Object Creation===
While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

===Using Preexisting modules===

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

===Support for one-of-a-kind objects===

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique
behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for
the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit
from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in
prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

===Elimination of meta-regress===

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its
properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be
defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the
medium truck would inherit this functionality completely. It is not likely to have its own move() function.

===Transfer of state information on extending the functionality of an object===

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps
object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state
from the existing marine corp object to the new Green Beret object.

===Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based===
if you want to [ http://en.wikipedia.org/wiki/Cloning_(programming) clone] an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex [ http://www.go4expert.com/articles/object-cloning-java-t5424 cloning logic] for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a
new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class
based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone
the existing delta soldier.

===Prototype based inheritance is more suited for a [http://en.wikipedia.org/wiki/Functional_programming "functional" style of programming]===
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be
embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate
function for the object.

===Prototype based inheritance requires dynamic typing whereas the classical based approach does not===
Since objects are being inherited rather than classes, it is necessary that the language support [http://c2.com/cgi/wiki?DynamicTyping dynamic typing], otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman
basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler
error (unless it supported runtime polymorhism).

===Refactorings don't work the same way===
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs /[http://c2.com/cgi/wiki?WhatIsRefactoring refactoring] tools can't really help us since they can't guess our approach.

Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each
of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass.
This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the
3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent
out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member
of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning
occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

===Static typing assurances===
The classical approach offers [http://c2.com/cgi/wiki?StaticTyping static typing] wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

==Which is the better approach==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical
approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would
seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since
each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it
would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

==References==
<references/>
[http://en.wikipedia.org/wiki/Prototype-based_programming Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr Work by students from previous semesters]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop advantages-of-prototype-based-oop-over-class-based-oop]
[http://javascript.crockford.com/prototypal.html Prototype based inheritance in javascript]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-15T04:53:52Z

Ashray:

== Inheritance ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

== Means of achieving inheritance ==
===Classical Inheritance===
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]

===Prototype Based Inheritance===
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

==Classical Inheritance v/s Prototype based inheritance==

===Object Creation===
While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

===Using Preexisting modules===

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

===Support for one-of-a-kind objects===

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique
behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for
the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit
from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in
prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

===Elimination of meta-regress===

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its
properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be
defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the
medium truck would inherit this functionality completely. It is not likely to have its own move() function.

===Transfer of state information on extending the functionality of an object===

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps
object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state
from the existing marine corp object to the new Green Beret object.

===Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based===
if you want to [http://en.wikipedia.org/wiki/Cloning_(programming) "clone"] an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex [ http://www.go4expert.com/articles/object-cloning-java-t5424/ cloning logic] for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a
new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class
based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone
the existing delta soldier.

===Prototype based inheritance is more suited for a [http://en.wikipedia.org/wiki/Functional_programming "functional" style of programming]===
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be
embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate
function for the object.

===Prototype based inheritance requires dynamic typing whereas the classical based approach does not===
Since objects are being inherited rather than classes, it is necessary that the language support [http://c2.com/cgi/wiki?DynamicTyping dynamic typing], otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman
basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler
error (unless it supported runtime polymorhism).

===Refactorings don't work the same way===
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs /[http://c2.com/cgi/wiki?WhatIsRefactoring refactoring] tools can't really help us since they can't guess our approach.

Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each
of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass.
This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the
3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent
out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member
of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning
occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

===Static typing assurances===
The classical approach offers [http://c2.com/cgi/wiki?StaticTyping static typing] wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

==Which is the better approach==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical
approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would
seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since
each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it
would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

==References==
<references/>
[http://en.wikipedia.org/wiki/Prototype-based_programming Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr Work by students from previous semesters]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop advantages-of-prototype-based-oop-over-class-based-oop]
[http://javascript.crockford.com/prototypal.html Prototype based inheritance in javascript]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-15T04:19:36Z

Ashray:

== Inheritance ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

== Means of achieving inheritance ==
===Classical Inheritance===
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]

===Prototype Based Inheritance===
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

==Classical Inheritance v/s Prototype based inheritance==

===Object Creation===
While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

===Using Preexisting modules===

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

===Support for one-of-a-kind objects===

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique
behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for
the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit
from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in
prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

===Elimination of meta-regress===

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its
properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be
defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the
medium truck would inherit this functionality completely. It is not likely to have its own move() function.

===Transfer of state information on extending the functionality of an object===

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps
object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state
from the existing marine corp object to the new Green Beret object.

===Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based===
if you want to "clone" an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex cloning logic for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a
new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class
based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone
the existing delta soldier.

===Prototype based inheritance is more suited for a "functional" style of programming===
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be
embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate
function for the object.

===Prototype based inheritance requires dynamic typing whereas the classical based approach does not===
Since objects are being inherited rather than classes, it is necessary that the language support dynamic typing, otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman
basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler
error (unless it supported runtime polymorhism).

===Refactorings don't work the same way===
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs / refactoring tools can't really help us since they can't guess our approach.

Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each
of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass.
This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the
3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent
out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member
of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning
occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

===Static typing assurances===
The classical approach offers static typing wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

==Which is the better approach==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

==References==
<references/>
[http://en.wikipedia.org/wiki/Prototype-based_programming Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr Work by students from previous semesters]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop advantages-of-prototype-based-oop-over-class-based-oop]
[http://javascript.crockford.com/prototypal.html Prototype based inheritance in javascript]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-09T03:43:01Z

Ashray:

== Inheritance ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

== Means of achieving inheritance ==
===Classical Inheritance===
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]

===Prototype Based Inheritance===
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

==Classical Inheritance v/s Prototype based inheritance==

===Object Creation===
While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

===Using Preexisting modules===

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

===Support for one-of-a-kind objects===

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique
behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for
the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit
from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in
prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

===Elimination of meta-regress===

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its
properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be
defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the
medium truck would inherit this functionality completely. It is not likely to have its own move() function.

===Transfer of state information on extending the functionality of an object===

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps
object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state
from the existing marine corp object to the new Green Beret object.

===Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based===
if you want to "clone" an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex cloning logic for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a
new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class
based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone
the existing delta soldier.

===Prototype based inheritance is more suited for a "functional" style of programming===
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be
embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate
function for the object.

===Prototype based inheritance requires dynamic typing whereas the classical based approach does not===
Since objects are being inherited rather than classes, it is necessary that the language support dynamic typing, otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman
basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler
error (unless it supported runtime polymorhism).

===Refactorings don't work the same way===
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs / refactoring tools can't really help us since they can't guess our approach.

Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each
of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass.
This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the
3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent
out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member
of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning
occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

===Static typing assurances===
The classical approach offers static typing wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

==Which is the better approach==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

==References==
<references/>
[http://en.wikipedia.org/wiki/Prototype-based_programming http://en.wikipedia.org/wiki/Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) http://en.wikipedia.org/wiki/Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) http://en.wikipedia.org/wiki/Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop]
[http://javascript.crockford.com/prototypal.html http://javascript.crockford.com/prototypal.html]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-09T03:36:28Z

Ashray:

== Inheritance ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

== Means of achieving inheritance ==
===Classical Inheritance===
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]

===Prototype Based Inheritance===
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

==Classical Inheritance v/s Prototype based inheritance==

===Object Creation===
While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

===Using Preexisting modules===

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

===Support for one-of-a-kind objects===

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique
behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for
the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit
from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in
prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

===Elimination of meta-regress===

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its
properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be
defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the
medium truck would inherit this functionality completely. It is not likely to have its own move() function.

===Transfer of state information on extending the functionality of an object===

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps
object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state
from the existing marine corp object to the new Green Beret object.

===Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based===
if you want to "clone" an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex cloning logic for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a
new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class
based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone
the existing delta soldier.

===Prototype based inheritance is more suited for a "functional" style of programming===
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be
embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate
function for the object.

===Prototype based inheritance requires dynamic typing whereas the classical based approach does not===
Since objects are being inherited rather than classes, it is necessary that the language support dynamic typing, otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman
basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler
error (unless it supported runtime polymorhism).

===Refactorings don't work the same way===
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs / refactoring tools can't really help us since they can't guess our approach.

Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each
of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass.
This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the
3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent
out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member
of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning
occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

===Static typing assurances===
The classical approach offers static typing wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

==Which is the better approach==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

==References==
<references/>
[http://en.wikipedia.org/wiki/Prototype-based_programming http://en.wikipedia.org/wiki/Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) http://en.wikipedia.org/wiki/Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) http://en.wikipedia.org/wiki/Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop]
[http://javascript.crockford.com/prototypal.html http://javascript.crockford.com/prototypal.html]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-09T03:33:20Z

Ashray:

== Inheritance ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

== Means of achieving inheritance ==
===Classical Inheritance===
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]

===Prototype Based Inheritance===
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

==Classical Inheritance v/s Prototype based inheritance==

===Object Creation===
While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

===Using Preexisting modules===

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

===Support for one-of-a-kind objects===

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique
behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for
the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit
from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in
prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

===Elimination of meta-regress===

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the medium truck would inherit this functionality completely. It is not likely to have its own move() function.

===Transfer of state information on extending the functionality of an object===

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state from the existing marine corp object to the new Green Beret object.

===Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based===
if you want to "clone" an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex cloning logic for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone the existing delta soldier.

===Prototype based inheritance is more suited for a "functional" style of programming===
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate function for the object.

===Prototype based inheritance requires dynamic typing whereas the classical based approach does not===
Since objects are being inherited rather than classes, it is necessary that the language support dynamic typing, otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler error (unless it supported runtime polymorhism).

===Refactorings don't work the same way===
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs / refactoring tools can't really help us since they can't guess our approach.
Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass. This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the 3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

===Static typing assurances===
The classical approach offers static typing wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

==Which is the better approach==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

==References==
<references/>
[http://en.wikipedia.org/wiki/Prototype-based_programming http://en.wikipedia.org/wiki/Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) http://en.wikipedia.org/wiki/Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) http://en.wikipedia.org/wiki/Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop]
[http://javascript.crockford.com/prototypal.html http://javascript.crockford.com/prototypal.html]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-09T03:29:55Z

Ashray:

== Inheritance ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

== Means of achieving inheritance ==
'''Classical Inheritance'''
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]

'''Prototype Based Inheritance'''
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

==Classical Inheritance v/s Prototype based inheritance==

===Object Creation===
While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

===Using Preexisting modules===

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

===Support for one-of-a-kind objects===

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

===Elimination of meta-regress===

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the medium truck would inherit this functionality completely. It is not likely to have its own move() function.

===Transfer of state information on extending the functionality of an object===

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state from the existing marine corp object to the new Green Beret object.

===Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based===
if you want to "clone" an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex cloning logic for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone the existing delta soldier.

===Prototype based inheritance is more suited for a "functional" style of programming===
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate function for the object.

===Prototype based inheritance requires dynamic typing whereas the classical based approach does not===
Since objects are being inherited rather than classes, it is necessary that the language support dynamic typing, otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler error (unless it supported runtime polymorhism).

===Refactorings don't work the same way===
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs / refactoring tools can't really help us since they can't guess our approach.
Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass. This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the 3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

===Static typing assurances===
The classical approach offers static typing wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

==Which is the better approach==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

==References==
<references/>
[http://en.wikipedia.org/wiki/Prototype-based_programming http://en.wikipedia.org/wiki/Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) http://en.wikipedia.org/wiki/Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) http://en.wikipedia.org/wiki/Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop]
[http://javascript.crockford.com/prototypal.html http://javascript.crockford.com/prototypal.html]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-09T03:28:43Z

Ashray:

== Inheritance ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

== Means of achieving inheritance ==
'''Classical Inheritance'''
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]

'''Prototype Based Inheritance'''
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

==Classical Inheritance v/s Prototype based inheritance==

===Object Creation===
While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

===Using Preexisting modules===

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

===Support for one-of-a-kind objects===

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

===Elimination of meta-regress===

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the medium truck would inherit this functionality completely. It is not likely to have its own move() function.

===Transfer of state information on extending the functionality of an object===

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state from the existing marine corp object to the new Green Beret object.

===Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based===
if you want to "clone" an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex cloning logic for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone the existing delta soldier.

===Prototype based inheritance is more suited for a "functional" style of programming===
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate function for the object.

===Prototype based inheritance requires dynamic typing whereas the classical based approach does not===
Since objects are being inherited rather than classes, it is necessary that the language support dynamic typing, otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler error (unless it supported runtime polymorhism).

===Refactorings don't work the same way===
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs / refactoring tools can't really help us since they can't guess our approach.
Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass. This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the 3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

===Static typing assurances===
The classical approach offers static typing wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

==Which is the better approach==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

==References==
<references/>

[http://en.wikipedia.org/wiki/Prototype-based_programming http://en.wikipedia.org/wiki/Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) http://en.wikipedia.org/wiki/Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) http://en.wikipedia.org/wiki/Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-09T03:27:11Z

Ashray:

== Inheritance ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

== Means of achieving inheritance ==
'''Classical Inheritance'''
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]

'''Prototype Based Inheritance'''
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

==Classical Inheritance v/s Prototype based inheritance==

===Object Creation===
While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

*'''Using Preexisting modules'''

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

*'''Support for one-of-a-kind objects'''

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

*'''Elimination of meta-regress'''

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the medium truck would inherit this functionality completely. It is not likely to have its own move() function.

*'''Transfer of state information on extending the functionality of an object'''

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state from the existing marine corp object to the new Green Beret object.

*'''Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based'''
if you want to "clone" an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex cloning logic for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone the existing delta soldier.

*'''Prototype based inheritance is more suited for a "functional" style of programming'''
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate function for the object.

*'''Prototype based inheritance requires dynamic typing whereas the classical based approach does not'''
Since objects are being inherited rather than classes, it is necessary that the language support dynamic typing, otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler error (unless it supported runtime polymorhism).

*'''Refactorings don't work the same way'''
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs / refactoring tools can't really help us since they can't guess our approach.
Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass. This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the 3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

*'''Static typing assurances'''
The classical approach offers static typing wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

==Which is the better approach==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

==References==
<references/>

[http://en.wikipedia.org/wiki/Prototype-based_programming http://en.wikipedia.org/wiki/Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) http://en.wikipedia.org/wiki/Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) http://en.wikipedia.org/wiki/Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-09T03:22:42Z

Ashray:

== Inheritance ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

== Means of achieving inheritance ==
'''Classical Inheritance'''
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]

'''Prototype Based Inheritance'''
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

==Classical Inheritance v/s Prototype based inheritance==
===Object Creation===:While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

*'''Using Preexisting modules'''

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

*'''Support for one-of-a-kind objects'''

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

*'''Elimination of meta-regress'''

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the medium truck would inherit this functionality completely. It is not likely to have its own move() function.

*'''Transfer of state information on extending the functionality of an object'''

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state from the existing marine corp object to the new Green Beret object.

*'''Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based'''
if you want to "clone" an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex cloning logic for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone the existing delta soldier.

*'''Prototype based inheritance is more suited for a "functional" style of programming'''
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate function for the object.

*'''Prototype based inheritance requires dynamic typing whereas the classical based approach does not'''
Since objects are being inherited rather than classes, it is necessary that the language support dynamic typing, otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler error (unless it supported runtime polymorhism).

*'''Refactorings don't work the same way'''
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs / refactoring tools can't really help us since they can't guess our approach.
Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass. This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the 3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

*'''Static typing assurances'''
The classical approach offers static typing wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

==Which is the better approach==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

==References==
<references/>

[http://en.wikipedia.org/wiki/Prototype-based_programming http://en.wikipedia.org/wiki/Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) http://en.wikipedia.org/wiki/Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) http://en.wikipedia.org/wiki/Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-09T03:22:25Z

Ashray:

== Inheritance ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

== Means of achieving inheritance ==
'''Classical Inheritance'''
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]

'''Prototype Based Inheritance'''
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

==Classical Inheritance v/s Prototype based inheritance==
*===Object Creation===:While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

*'''Using Preexisting modules'''

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

*'''Support for one-of-a-kind objects'''

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

*'''Elimination of meta-regress'''

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the medium truck would inherit this functionality completely. It is not likely to have its own move() function.

*'''Transfer of state information on extending the functionality of an object'''

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state from the existing marine corp object to the new Green Beret object.

*'''Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based'''
if you want to "clone" an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex cloning logic for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone the existing delta soldier.

*'''Prototype based inheritance is more suited for a "functional" style of programming'''
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate function for the object.

*'''Prototype based inheritance requires dynamic typing whereas the classical based approach does not'''
Since objects are being inherited rather than classes, it is necessary that the language support dynamic typing, otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler error (unless it supported runtime polymorhism).

*'''Refactorings don't work the same way'''
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs / refactoring tools can't really help us since they can't guess our approach.
Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass. This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the 3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

*'''Static typing assurances'''
The classical approach offers static typing wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

==Which is the better approach==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

==References==
<references/>

[http://en.wikipedia.org/wiki/Prototype-based_programming http://en.wikipedia.org/wiki/Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) http://en.wikipedia.org/wiki/Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) http://en.wikipedia.org/wiki/Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-09T03:20:42Z

Ashray:

== Inheritance ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

== Means of achieving inheritance ==
'''Classical Inheritance'''
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]

'''Prototype Based Inheritance'''
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

==Classical Inheritance v/s Prototype based inheritance==
*====Object Creation====:While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

*'''Using Preexisting modules'''

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

*'''Support for one-of-a-kind objects'''

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

*'''Elimination of meta-regress'''

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the medium truck would inherit this functionality completely. It is not likely to have its own move() function.

*'''Transfer of state information on extending the functionality of an object'''

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state from the existing marine corp object to the new Green Beret object.

*'''Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based'''
if you want to "clone" an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex cloning logic for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone the existing delta soldier.

*'''Prototype based inheritance is more suited for a "functional" style of programming'''
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate function for the object.

*'''Prototype based inheritance requires dynamic typing whereas the classical based approach does not'''
Since objects are being inherited rather than classes, it is necessary that the language support dynamic typing, otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler error (unless it supported runtime polymorhism).

*'''Refactorings don't work the same way'''
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs / refactoring tools can't really help us since they can't guess our approach.
Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass. This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the 3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

*'''Static typing assurances'''
The classical approach offers static typing wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

==Which is the better approach==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

==References==
<references/>

[http://en.wikipedia.org/wiki/Prototype-based_programming http://en.wikipedia.org/wiki/Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) http://en.wikipedia.org/wiki/Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) http://en.wikipedia.org/wiki/Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-09T03:18:49Z

Ashray:

== Inheritance ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

== Means of achieving inheritance ==
'''Classical Inheritance'''
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]

'''Prototype Based Inheritance'''
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

==Classical Inheritance v/s Prototype based inheritance==
*'''Object Creation''' :While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

*'''Using Preexisting modules'''

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

*'''Support for one-of-a-kind objects'''

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

*'''Elimination of meta-regress'''

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the medium truck would inherit this functionality completely. It is not likely to have its own move() function.

*'''Transfer of state information on extending the functionality of an object'''

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state from the existing marine corp object to the new Green Beret object.

*'''Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based'''
if you want to "clone" an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex cloning logic for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone the existing delta soldier.

*'''Prototype based inheritance is more suited for a "functional" style of programming'''
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate function for the object.

*'''Prototype based inheritance requires dynamic typing whereas the classical based approach does not'''
Since objects are being inherited rather than classes, it is necessary that the language support dynamic typing, otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler error (unless it supported runtime polymorhism).

*'''Refactorings don't work the same way'''
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs / refactoring tools can't really help us since they can't guess our approach.
Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass. This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the 3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

*'''Static typing assurances'''
The classical approach offers static typing wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

==Which is the better approach==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

==References==
<references/>

[http://en.wikipedia.org/wiki/Prototype-based_programming http://en.wikipedia.org/wiki/Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) http://en.wikipedia.org/wiki/Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) http://en.wikipedia.org/wiki/Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-09T03:17:02Z

Ashray:

=== Inheritance ===
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

=== Means of achieving inheritance ===
'''Classical Inheritance'''
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]

'''Prototype Based Inheritance'''
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''

This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

==Classical Inheritance v/s Prototype based inheritance==
*'''Object Creation''' :While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

*'''Using Preexisting modules'''

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

*'''Support for one-of-a-kind objects'''

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

*'''Elimination of meta-regress'''

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the medium truck would inherit this functionality completely. It is not likely to have its own move() function.

*'''Transfer of state information on extending the functionality of an object'''

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state from the existing marine corp object to the new Green Beret object.

*'''Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based'''
if you want to "clone" an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex cloning logic for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone the existing delta soldier.

*'''Prototype based inheritance is more suited for a "functional" style of programming'''
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate function for the object.

*'''Prototype based inheritance requires dynamic typing whereas the classical based approach does not'''
Since objects are being inherited rather than classes, it is necessary that the language support dynamic typing, otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler error (unless it supported runtime polymorhism).

*'''Refactorings don't work the same way'''
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs / refactoring tools can't really help us since they can't guess our approach.
Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass. This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the 3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

*'''Static typing assurances'''
The classical approach offers static typing wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

==Which is the better approach==
The classical based method is more traditional and purist compared to the prototype based approach.
People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?"
It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.
For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

==References==
<references/>

[http://en.wikipedia.org/wiki/Prototype-based_programming http://en.wikipedia.org/wiki/Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) http://en.wikipedia.org/wiki/Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) http://en.wikipedia.org/wiki/Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-09T02:55:08Z

Ashray:

=== Inheritance ===
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

=== Means of achieving inheritance ===
'''Classical Inheritance'''
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]

'''Prototype Based Inheritance'''
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of naming a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)
''
This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

==Classical Inheritance v/s Prototype based inheritance==
*'''Object Creation''' :While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

*'''Using Preexisting modules'''

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

*'''Support for one-of-a-kind objects'''

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

*'''Elimination of meta-regress'''

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the medium truck would inherit this functionality completely. It is not likely to have its own move() function.

*'''Transfer of state information on extending the functionality of an object'''

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state from the existing marine corp object to the new Green Beret object.

*'''Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based'''
if you want to "clone" an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex cloning logic for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone the existing delta soldier.

*'''Prototype based inheritance is more suited for a "functional" style of programming'''
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate function for the object.

*'''Prototype based inheritance requires dynamic typing whereas the classical based approach does not'''
Since objects are being inherited rather than classes, it is necessary that the language support dynamic typing, otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler error (unless it supported runtime polymorhism).

*'''Refactorings don't work the same way'''
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs / refactoring tools can't really help us since they can't guess our approach.
Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass. This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the 3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.

*'''Static typing assurances'''
The classical approach offers static typing wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

==References==
<references/>

[http://en.wikipedia.org/wiki/Prototype-based_programming http://en.wikipedia.org/wiki/Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) http://en.wikipedia.org/wiki/Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) http://en.wikipedia.org/wiki/Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-09T02:32:34Z

Ashray:

=== Inheritance ===
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

=== Means of achieving inheritance ===
'''Classical Inheritance'''
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]

'''Prototype Based Inheritance'''
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of naming a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)
''
This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

==Classical Inheritance v/s Prototype based inheritance==
*'''Object Creation''' :While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

*'''Using Preexisting modules'''

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

*'''Support for one-of-a-kind objects'''

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

*'''Elimination of meta-regress'''

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the medium truck would inherit this functionality completely. It is not likely to have its own move() function.

*'''Transfer of state information on extending the functionality of an object'''

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state from the existing marine corp object to the new Green Beret object.

*'''Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based'''
if you want to "clone" an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex cloning logic for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone the existing delta soldier.

*'''Prototype based inheritance is more suited for a "functional" style of programming'''
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate function for the object.

*'''Prototype based inheritance requires dynamic typing whereas the classical based approach does not'''
Since objects are being inherited rather than classes, it is necessary that the language support dynamic typing, otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.

In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler error (unless it supported runtime polymorhism).

*'''Static typing assurances'''
The classical approach offers static typing wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.

==References==
<references/>

[http://en.wikipedia.org/wiki/Prototype-based_programming http://en.wikipedia.org/wiki/Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) http://en.wikipedia.org/wiki/Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) http://en.wikipedia.org/wiki/Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-09T01:57:56Z

Ashray:

=== Inheritance ===
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both

=== Means of achieving inheritance ===
'''Classical Inheritance'''
Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

[[File:Inheritance(Classical Inheritance).png| center]]

'''Prototype Based Inheritance'''
A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is the language feature that supports prototype-based programming.

A simple example of Prototype Based Inheritance could be depicted as

[[File:Priority Inheritnce Fig2.jpg|300px|center]].
''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of naming a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)
''
This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.

==Classical Inheritance v/s Prototype based inheritance==
*'''Object Creation''' :While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

Classical inheritance example
class Vehicle
{
//properties
}
class Car inherits Land Vehicle
{
}
class trucks inherits inherits Car
{
}
class medium Truck inherits Truck
{
//properties
}

Prototype based inheritance example

class Soldier
{
//properties
}
Private = Soldier.new()
GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")

*'''Using Preexisting modules'''

Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

*'''Support for one-of-a-kind objects'''

Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.

*'''Elimination of meta-regress'''

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its properties even though it inherits from the same.
However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the medium truck would inherit this functionality completely. It is not likely to have its own move() function.

*'''Transfer of state information on extending the functionality of an object'''

Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.

Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state from the existing marine corp object to the new Green Beret object.

*'''Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based'''
if you want to "clone" an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex cloning logic for different classes.

For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone the existing delta soldier.

*'''Prototype based inheritance is more suited for a "functional" style of programming'''
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate function for the object.

<references/>

[http://en.wikipedia.org/wiki/Prototype-based_programming http://en.wikipedia.org/wiki/Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) http://en.wikipedia.org/wiki/Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) http://en.wikipedia.org/wiki/Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop]

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-09T01:22:13Z

Ashray:

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-09T00:16:53Z

Ashray:

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-09T00:01:03Z

Ashray:

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-08T23:59:55Z

Ashray:

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-08T23:51:06Z

Ashray:

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-08T23:49:04Z

Ashray:

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-08T23:22:25Z

Ashray:

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-08T22:09:59Z

Ashray:

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-08T22:08:56Z

Ashray:

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-08T21:59:22Z

Ashray:

CSC/ECE 517 Spring 2013/ch1a 1e pi

2013-02-08T20:57:41Z

Ashray: