Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2011/ch7 7d rt

2011-11-30T00:57:01Z

Rbjeffer:

AntiPatterns in Software Development
__TOC__

==Introduction==
The term ''antipattern'' was coined by Andrew Koenig<ref name = koenig/>, in 1995. His inspiration was a story told about Thomas Edison's many failed attempts to find a suitable material for the filament of a light bulb. When asked if he was discouraged, Edison replied that indeed he was not; he now knew hundreds of items that wouldn't work.

Koenig believed that the same philosophy should be applied to software development. As he studied the book ''Design Patterns'' presented by the Gang of Four<ref name = gof/>, he felt that it was just as important to identify potential pitfalls as well as positive practices. He named these non-solutions ''antipatterns''. He defined an ''antipattern'' as "just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn't one." <ref name = koenig/>

In 1998, a different group of four expanded on this idea publishing '''''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis'''''<ref name = ap/>. The book identified antipatterns from three different viewpoints: the software developer, the software architect and the software manager. The authors used two criteria to distinguish antipatterns:
* It was a frequent occurrence, that initially seemed to be beneficial, but ultimately was not and
* There is a alternate, preferred solution that is proven and repeatable.

Through the years the concept of antipatterns has been further extended to apply to additional areas of software development as well as areas outside the realm of programming. This article will address software development antipatterns.

Just like patterns, antipatterns have certain elements. They include:
# Name so that they can be identified.
# A description of why the bad solution might be attractive.
# An explanation of how that solution is bad long-term.
# Suggestions for other patterns that provide better solutions.

There are several catalogs of antipatterns available as well as a number of books that address the topic. Below we will explore a few of the more common antipatterns.

==AntiPatterns==
===Call Super===

====Description====
We are all familiar with the concept of inheritance in object-oriented programming where a subclass takes on the properties and actions of a superclass. The subclass can then override the methods of the superclass either replacing or augmenting the functionality provided in the superclass. The '''call super''' antipattern requires subclasses to override methods of the super class and then call back the overridden method at some point. This requirement may stem from the fact that the superclass does some set up operations that cannot be done in the subclass or if the subclass is expanding the superclass task rather than replacing it.

Calling a superclass method from a subclass is not in general a bad practice, but '''requiring''' it to do so is. Imposing such a constraint can lead to several problems. Future developers may forget to call the superclass causing untold bugs and system errors. Additionally, it requires anyone using the interface to have an understanding of the inner workings of the superclass. Ideally, they would only need to understand the public interface. Finally, if the superclass expects specific actions from the subclass, it may not perform well (or at all) if those actions aren't performed as expected.

A better approach to obtaining the desired functionality would be to use the [http://en.wikipedia.org/wiki/Template_method_pattern Template Method] pattern. Here the superclass would include a public method and define a separate method (often called a hook method) for the subclass to override. The superclass method would then call the hook method. The hook method can either be an abstract method in the superclass and fully implemented in the subclass, or have some basic functionality in the superclass and augmented in the superclass. Either way the subclass does not have to worry about calling the superclass.

====Example====

Let's say we have a class registration framework with an EventHandler superclass. The EventHandler is used to process all "transactions" - administrators adding classes, students registering for classes, students dropping classes, etc. It has to do some basic setup and housekeeping functions (checking availability, permissions, etc.) before the registration event can be processed. Our original code for a student registering for a class might be something like the following.

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
}

public class StudentClassRegistrationHandler extends EventHandler...
public void handle(RegistrationEvent e) {
super.handle(e);
RegisterStudent(e);
}

The method StudentClassRegistrationHandler must call super.handle() before it can begin its task of registering the student. If we refactor this code using the Template Method pattern, we could get the following code:

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
doAction(e);
}
protected void doAction(RegistrationEvent e) {
}

public class StudentClassRegistrationHandler extends EventHandler ...
protected void doAction(RegistrationEvent e) {
RegisterStudent(e);
}

The subclass is now only responsible for its own functionality. This arrangement also allows the superclass to call some follow-up or clean-up methods after the subclass method if necessary.

===BaseBean===

====Description====
Similar to the Call Super antipattern is the BaseBean antipattern. It is found in object-oriented programming when a concrete domain class is formed using inheritance from a utility class. This relationship is used simply to inherit utility methods from the utility class. This is sometimes referred to as inheritance for implementation.

Inheritance for the sake of gaining the functionality in the parent class is not good style. This obviously is not an "is-a" a relationship and may violate the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle]. By inheriting from the utility class, the domain class becomes dependent on the internals of the utility class. This can make the system difficult to maintain. Additionally, the domain class now has all the functionality of the utility class - some of which it might not need. This blurs the concept of the domain class and may cause it to have more than a single responsibility.

In good object-oriented programming, objects should be representative of the real-world entities they exemplify and should relate to each other as such. In this scenario a "has-a" relationship would be more appropriate. The inherited functionality can be obtained using delegation instead of inheritance. By using the [http://en.wikipedia.org/wiki/Composition_over_inheritance composition over inheritance] principle, we can avoid the BaseBean antipattern.

====Example====

Let's say we want to create a class that emulates a toll booth. The cars at the toll booth form a queue, so our toll booth will need the functionality (queue, dequeue, isEmpty, etc.) of a queue. We could implement our toll booth by inheriting this functionality from a Queue class as such:

public class TollBooth extends Queue{
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Obviously, a tollbooth is not a queue, but more appropriately, has a queue. Hence, our toll booth class should be created to contain a queue to model the line of cars.

public class TollBooth
private Queue<Vehicles>
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Our TollBooth class now has the functionality it needs without the inherent liabilities of extending the Queue class.

===The Blob===
====Description====
'''The Blob''', also called a '''God Class''', is a development antipattern that results when one single class has too many attributes, operations, or both.<ref name = sourcemaking_tb/> '''The Blob''' is usually an indicator of poor object-oriented design, or a poorly-migrated legacy program.<ref name = ap/> It can often resemble a procedural 'main' program, and may even encapsulate most or all of the functionality of an application. '''The Blob''' class violates the ''One Responsibility Rule'', which makes it unlikely to be reusable. Because it has many responsibilities, it would be difficult to reuse in a future project. '''The Blob''' class may be expensive to load into memory, and wasteful if only part of the functionality is used. It also will likely be difficult to effectively test.<ref name = ap/> '''The Blob''' is typically caused by a lack of an object-oriented architecture.<ref name = ap/> It can also be the result of an up-front object-oriented design that did not take into account a requirement, and developers choosing not to rearrange the class hierarchy after the initial design. It can also be a ''Specified Disaster''; the result of requirements that specify a procedural solution.<ref name = ap/>

The solution to '''The Blob''' is to refactor the code, with the goal of moving behavior away from the offending class.<ref name = sourcemaking_tb /> If '''The Blob''' encapsulates data in some other objects, then code manipulating that data should be moved to the other classes, in an effort to make the other classes more complex and '''The Blob''' less complex. If possible, the developers should try to split '''The Blob''' into multiple classes with class minimal coupling.

====Example====
An example of class approaching '''The Blob''' that may be familiar to many students this semester is the [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza] Project's assignment model.<ref name="expertiza" /> The assignment model in Expertiza does not encapsulate the majority of functionality in the entire application, but it is out of proportion with most of the other classes, and it does include functionality that should be in some other classes.<ref name="fall2011_oss" /> One of the Open-Source Software projects for this semester is to correct some of these problems. The project assignment contains the following notes:<ref name="fall2011_oss" />

<blockquote>[The assignment model] contains functionality for adding and removing participants for this assignment, which should really be in a participant class, for assigning reviewers, which should probably be in a reviewer class, and for computing the maximum score possible on a questionnaire. Functions like compute_scores, and candidate_topics_to_review, among others, should be moved to other classes.</blockquote>

These notes describe some of the excessive functionality of assignment.rb. It also suggests some other classes that would be more appropriate locations for some functionalities. If these modifications are made, then the assignment model will be of a more manageable size, and will not be in danger of becoming '''The Blob'''.

===Golden Hammer===
====Description====
The '''Golden Hammer''' design AntiPattern, also known as the '''Law of the instrument''', is an over-reliance on a familiar tool.<ref name="wiki_gh" /> It is one of the most common antipatterns seen in the industry.<ref name="sourcemaking_gh" />

Many software engineering projects solve problems or use techniques that programmers are strongly familiar with. Programmers often reuse strategies, algorithms, or entire sections of code that they or another programmer has applied to a different project in the past. Reuse in this manner can save development time and cost, but only when reused code is appropriate for the new application.

The '''Golden Hammer''' design anti-pattern results from reusing a familiar solution that is a poor match for a new problem.<ref name="sourcemaking_gh" /> This can occur if the developers are simply comfortable with or used to an existing approach, or even the result of narrow-mindedness or hubris. It can also be the direct result of reliance on proprietary technologies or products, or a deliberate effort to try to build a previous projects' success into a new program. A '''Golden Hammer''' will typically manifest itself with poor performance or scalability.<ref name="sourcemaking_gh" />

====Example====

When [http://en.wikipedia.org/wiki/Automated_teller_machine Automated Teller Machines (ATMs)] were popularized in the 1970s, they were often designed using [http://en.wikipedia.org/wiki/Computer_terminal Dumb Terminals], a contemporary computer technology. In the 1990s and 2000s, many banks began replacing their aging ATMs with more modern ones that were physically more difficult to break into. Many of these banks have not changed the communication protocols that the ATMs use to conduct transactions with the bank's servers or mainframe, because weaknesses in the protocol or cryptography is not the cause of most ATM fraud.<ref name="crypto" /> As a result, many banks designed new ATMs that were required to somehow use the existing technology: encrypted dumb terminal sessions. The majority of these systems that have been deployed used a familiar '''Golden Hammer''' to do this: [http://en.wikipedia.org/wiki/Terminal_emulator Terminal Emulator] software installed on a variant of the [http://en.wikipedia.org/wiki/Microsoft_windows Microsoft Windows] operating system.<ref name="wikipedia_atm" /> This design decision has several negative effects, including:
* Increased unit cost of ATMs, because each one must have a licensed copy of a commercial operating system
* Concerns about the reliability and trustworthiness of the underlying ATM software<ref name=windowsatm />

==Conclusion==

In this article, we have described some of the most commonly occurring AntiPatterns. AntiPatterns comprise a set of defective processes and pitfalls in software development. They describe common errors in judgment or design made by both software engineers and project managers. They explain the causes of these errors, and offer suggestions for correcting the errors. AntiPatterns also define a standard set of vocabulary, so that they can be understood broadly. They are important for both programmers and managers to know and understand, in order to avoid costly mistakes.

==Resources==

For additional information regarding antipatterns, check out the following resources.

===Books===

* [http://www.amazon.com/exec/obidos/ISBN=0471197130/portlandpatternrA/ ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''.] Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, (ed) (1998).

* [http://sourcemaking.com/antipatterns-book ''AntiPatterns: The Survival Guide'']

* [http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612 ''Design Patterns: Elements of Reusable Object-Oriented Software''] by Erich Gamma, Richard Helm], Ralph Johnson, and John Vlissides(the Gang Of Four)

===Websites===

* [http://c2.com/cgi/wiki?AntiPatternsCatalog AntiPatterns Catalog]

* [http://www.antipatterns.com/ AntiPatterns.com] Web site for the ''AntiPatterns'' book

* [http://en.wikipedia.org/wiki/Category:Anti-patterns Wikipedia Antipatterns Category]

==References==
<references>
<ref name = koenig> Koenig, Andrew (March/April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming 8 (1): 46–48.; was later re-printed in the: Rising, Linda (1998). [http://books.google.com/?id=HBAuixGMYWEC&pg=PT1&dq=0-521-64818-1 The patterns handbook: techniques, strategies, and applications]. Cambridge, U.K.: Cambridge University Press. p. 387. </ref>
<ref name = gof> [http://en.wikipedia.org/wiki/Design_Patterns_%28book%29 Design Patterns] by the Gang of Four</ref>
<ref name = ap> Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, Theresa Hudson (ed) (1998). [http://www.antipatterns.com/AntiPatterns/Welcome.html ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''. ]</ref>
<ref name = sourcemaking_tb> [http://sourcemaking.com/antipatterns/the-blob http://sourcemaking.com/antipatterns/the-blob]</ref>
<ref name = wiki_gh> [http://en.wikipedia.org/wiki/Golden_hammer http://en.wikipedia.org/wiki/Golden_hammer] </ref>
<ref name = sourcemaking_gh> [http://sourcemaking.com/antipatterns/golden-hammer http://sourcemaking.com/antipatterns/golden-hammer] </ref>
<ref name = expertiza> [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza - Reusable learning objects through peer review] </ref>
<ref name = fall2011_oss> [https://docs.google.com/a/ncsu.edu/document/d/1zZ-a_tkLGrbYJbG-2QBCRqe_Y9XLR4AZMH0rc6KvrYU/edit?hl=en_US CSC/ECE517 Fall 2011 OSS Projects in Expertiza] </ref>
<ref name = crypto> Anderson, R. 1993. Why cryptosystems fail. In Proceedings of the 1st ACM Conference on Computer and Communications Security (Fairfax, Virginia, United States, November 03 - 05, 1993). CCS '93 [http://www.cl.cam.ac.uk/~rja14/Papers/wcf.pdf]</ref>
<ref name = wikipedia_atm> [http://en.wikipedia.org/wiki/Automatic_Teller_Machine http://en.wikipedia.org/wiki/Automatic_Teller_Machine]</ref>
<ref name = windowsatm> [http://www.technewsworld.com/story/32350.html "Technology News: Security: Windows Cash-Machine Worm Generates Concern". Technewsworld.com] </ref>
</ref>
</references>

CSC/ECE 517 Fall 2011/ch7 7d rt

2011-11-30T00:55:35Z

Rbjeffer:

AntiPatterns in Software Development
__TOC__

==Introduction==
The term ''antipattern'' was coined by Andrew Koenig<ref name = koenig/>, in 1995. His inspiration was a story told about Thomas Edison's many failed attempts to find a suitable material for the filament of a light bulb. When asked if he was discouraged, Edison replied that indeed he was not; he now knew hundreds of items that wouldn't work.

Koenig believed that the same philosophy should be applied to software development. As he studied the book ''Design Patterns'' presented by the Gang of Four<ref name = gof/>, he felt that it was just as important to identify potential pitfalls as well as positive practices. He named these non-solutions ''antipatterns''. He defined an ''antipattern'' as "just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn't one." <ref name = koenig/>

In 1998, a different group of four expanded on this idea publishing '''''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis'''''<ref name = ap/>. The book identified antipatterns from three different viewpoints: the software developer, the software architect and the software manager. The authors used two criteria to distinguish antipatterns:
* It was a frequent occurrence, that initially seemed to be beneficial, but ultimately was not and
* There is a alternate, preferred solution that is proven and repeatable.

Through the years the concept of antipatterns has been further extended to apply to additional areas of software development as well as areas outside the realm of programming. This article will address software development antipatterns.

Just like patterns, antipatterns have certain elements. They include:
# Name so that they can be identified.
# A description of why the bad solution might be attractive.
# An explanation of how that solution is bad long-term.
# Suggestions for other patterns that provide better solutions.

There are several catalogs of antipatterns available as well as a number of books that address the topic. Below we will explore a few of the more common antipatterns.

==AntiPatterns==
===Call Super===

====Description====
We are all familiar with the concept of inheritance in object-oriented programming where a subclass takes on the properties and actions of a superclass. The subclass can then override the methods of the superclass either replacing or augmenting the functionality provided in the superclass. The '''call super''' antipattern requires subclasses to override methods of the super class and then call back the overridden method at some point. This requirement may stem from the fact that the superclass does some set up operations that cannot be done in the subclass or if the subclass is expanding the superclass task rather than replacing it.

Calling a superclass method from a subclass is not in general a bad practice, but '''requiring''' it to do so is. Imposing such a constraint can lead to several problems. Future developers may forget to call the superclass causing untold bugs and system errors. Additionally, it requires anyone using the interface to have an understanding of the inner workings of the superclass. Ideally, they would only need to understand the public interface. Finally, if the superclass expects specific actions from the subclass, it may not perform well (or at all) if those actions aren't performed as expected.

A better approach to obtaining the desired functionality would be to use the [http://en.wikipedia.org/wiki/Template_method_pattern Template Method] pattern. Here the superclass would include a public method and define a separate method (often called a hook method) for the subclass to override. The superclass method would then call the hook method. The hook method can either be an abstract method in the superclass and fully implemented in the subclass, or have some basic functionality in the superclass and augmented in the superclass. Either way the subclass does not have to worry about calling the superclass.

====Example====

Let's say we have a class registration framework with an EventHandler superclass. The EventHandler is used to process all "transactions" - administrators adding classes, students registering for classes, students dropping classes, etc. It has to do some basic setup and housekeeping functions (checking availability, permissions, etc.) before the registration event can be processed. Our original code for a student registering for a class might be something like the following.

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
}

public class StudentClassRegistrationHandler extends EventHandler...
public void handle(RegistrationEvent e) {
super.handle(e);
RegisterStudent(e);
}

The method StudentClassRegistrationHandler must call super.handle() before it can begin its task of registering the student. If we refactor this code using the Template Method pattern, we could get the following code:

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
doAction(e);
}
protected void doAction(RegistrationEvent e) {
}

public class StudentClassRegistrationHandler extends EventHandler ...
protected void doAction(RegistrationEvent e) {
RegisterStudent(e);
}

The subclass is now only responsible for its own functionality. This arrangement also allows the superclass to call some follow-up or clean-up methods after the subclass method if necessary.

===BaseBean===

====Description====
Similar to the Call Super antipattern is the BaseBean antipattern. It is found in object-oriented programming when a concrete domain class is formed using inheritance from a utility class. This relationship is used simply to inherit utility methods from the utility class. This is sometimes referred to as inheritance for implementation.

Inheritance for the sake of gaining the functionality in the parent class is not good style. This obviously is not an "is-a" a relationship and may violate the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle]. By inheriting from the utility class, the domain class becomes dependent on the internals of the utility class. This can make the system difficult to maintain. Additionally, the domain class now has all the functionality of the utility class - some of which it might not need. This blurs the concept of the domain class and may cause it to have more than a single responsibility.

In good object-oriented programming, objects should be representative of the real-world entities they exemplify and should relate to each other as such. In this scenario a "has-a" relationship would be more appropriate. The inherited functionality can be obtained using delegation instead of inheritance. By using the [http://en.wikipedia.org/wiki/Composition_over_inheritance composition over inheritance] principle, we can avoid the BaseBean antipattern.

====Example====

Let's say we want to create a class that emulates a toll booth. The cars at the toll booth form a queue, so our toll booth will need the functionality (queue, dequeue, isEmpty, etc.) of a queue. We could implement our toll booth by inheriting this functionality from a Queue class as such:

public class TollBooth extends Queue{
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Obviously, a tollbooth is not a queue, but more appropriately, has a queue. Hence, our toll booth class should be created to contain a queue to model the line of cars.

public class TollBooth
private Queue<Vehicles>
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Our TollBooth class now has the functionality it needs without the inherent liabilities of extending the Queue class.

===The Blob===
====Description====
'''The Blob''', also called a '''God Class''', is a development antipattern that results when one single class has too many attributes, operations, or both.<ref name = sourcemaking_tb/> '''The Blob''' is usually an indicator of poor object-oriented design, or a poorly-migrated legacy program.<ref name = ap/> It can often resemble a procedural 'main' program, and may even encapsulate most or all of the functionality of an application. '''The Blob''' class violates the ''One Responsibility Rule'', which makes it unlikely to be reusable. Because it has many responsibilities, it would be difficult to reuse in a future project. '''The Blob''' class may be expensive to load into memory, and wasteful if only part of the functionality is used. It also will likely be difficult to effectively test.<ref name = ap/> '''The Blob''' is typically caused by a lack of an object-oriented architecture.<ref name = ap/> It can also be the result of an up-front object-oriented design that did not take into account a requirement, and developers choosing not to rearrange the class hierarchy after the initial design. It can also be a ''Specified Disaster''; the result of requirements that specify a procedural solution.<ref name = ap/>

The solution to '''The Blob''' is to refactor the code, with the goal of moving behavior away from the offending class.<ref name = sourcemaking_tb /> If '''The Blob''' encapsulates data in some other objects, then code manipulating that data should be moved to the other classes, in an effort to make the other classes more complex and '''The Blob''' less complex. If possible, the developers should try to split '''The Blob''' into multiple classes with class minimal coupling.

====Example====
An example of class approaching '''The Blob''' that may be familiar to many students this semester is the [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza] Project's assignment model.<ref name="expertiza" /> The assignment model in Expertiza does not encapsulate the majority of functionality in the entire application, but it is out of proportion with most of the other classes, and it does include functionality that should be in some other classes.<ref name="fall2011_oss" /> One of the Open-Source Software projects for this semester is to correct some of these problems. The project assignment contains the following notes:<ref name="fall2011_oss" />

<blockquote>[The assignment model] contains functionality for adding and removing participants for this assignment, which should really be in a participant class, for assigning reviewers, which should probably be in a reviewer class, and for computing the maximum score possible on a questionnaire. Functions like compute_scores, and candidate_topics_to_review, among others, should be moved to other classes.</blockquote>

These notes describe some of the excessive functionality of assignment.rb. It also suggests some other classes that would be more appropriate locations for some functionalities. If these modifications are made, then the assignment model will be of a more manageable size, and will not be in danger of becoming '''The Blob'''.

===Golden Hammer===
====Description====
The '''Golden Hammer''' design AntiPattern, also known as the '''Law of the instrument''', is an over-reliance on a familiar tool.<ref name="wiki_gh" /> It is one of the most common antipatterns seen in the industry.<ref name="sourcemaking_gh" />

Many software engineering projects solve problems or use techniques that programmers are strongly familiar with. Programmers often reuse strategies, algorithms, or entire sections of code that they or another programmer has applied to a different project in the past. Reuse in this manner can save development time and cost, but only when reused code is appropriate for the new application.

The '''Golden Hammer''' design anti-pattern results from reusing a familiar solution that is a poor match for a new problem.<ref name="sourcemaking_gh" /> This can occur if the developers are simply comfortable with or used to an existing approach, or even the result of narrow-mindedness or hubris. It can also be the direct result of reliance on proprietary technologies or products, or a deliberate effort to try to build a previous projects' success into a new program. A '''Golden Hammer''' will typically manifest itself with poor performance or scalability.<ref name="sourcemaking_gh" />

====Example====

When [http://en.wikipedia.org/wiki/Automated_teller_machine Automated Teller Machines (ATMs)] were popularized in the 1970s, they were often designed using [http://en.wikipedia.org/wiki/Computer_terminal Dumb Terminals], a contemporary computer technology. In the 1990s and 2000s, many banks began replacing their aging ATMs with more modern ones that were physically more difficult to break into. Many of these banks have not changed the communication protocols that the ATMs use to conduct transactions with the bank's servers or mainframe, because weaknesses in the protocol or cryptography is not the cause of most ATM fraud.<ref name="crypto" /> As a result, many banks designed new ATMs that were required to somehow use the existing technology: encrypted dumb terminal sessions. The majority of these systems that have been deployed used a familiar '''Golden Hammer''' to do this: [http://en.wikipedia.org/wiki/Terminal_emulator Terminal Emulator] software installed on a variant of the [http://en.wikipedia.org/wiki/Microsoft_windows Microsoft Windows] operating system.<ref name="wikipedia_atm" />

==Conclusion==

In this article, we have described some of the most commonly occurring AntiPatterns. AntiPatterns comprise a set of defective processes and pitfalls in software development. They describe common errors in judgment or design made by both software engineers and project managers. They explain the causes of these errors, and offer suggestions for correcting the errors. AntiPatterns also define a standard set of vocabulary, so that they can be understood broadly. They are important for both programmers and managers to know and understand, in order to avoid costly mistakes. This design decision has several negative effects, including:
* Increased unit cost of ATMs, because each one must have a licensed copy of a commercial operating system
* Concerns about the reliability and trustworthiness of the underlying ATM software<ref name=windowsatm />

==Resources==

For additional information regarding antipatterns, check out the following resources.

===Books===

* [http://www.amazon.com/exec/obidos/ISBN=0471197130/portlandpatternrA/ ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''.] Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, (ed) (1998).

* [http://sourcemaking.com/antipatterns-book ''AntiPatterns: The Survival Guide'']

* [http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612 ''Design Patterns: Elements of Reusable Object-Oriented Software''] by Erich Gamma, Richard Helm], Ralph Johnson, and John Vlissides(the Gang Of Four)

===Websites===

* [http://c2.com/cgi/wiki?AntiPatternsCatalog AntiPatterns Catalog]

* [http://www.antipatterns.com/ AntiPatterns.com] Web site for the ''AntiPatterns'' book

* [http://en.wikipedia.org/wiki/Category:Anti-patterns Wikipedia Antipatterns Category]

==References==
<references>
<ref name = koenig> Koenig, Andrew (March/April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming 8 (1): 46–48.; was later re-printed in the: Rising, Linda (1998). [http://books.google.com/?id=HBAuixGMYWEC&pg=PT1&dq=0-521-64818-1 The patterns handbook: techniques, strategies, and applications]. Cambridge, U.K.: Cambridge University Press. p. 387. </ref>
<ref name = gof> [http://en.wikipedia.org/wiki/Design_Patterns_%28book%29 Design Patterns] by the Gang of Four</ref>
<ref name = ap> Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, Theresa Hudson (ed) (1998). [http://www.antipatterns.com/AntiPatterns/Welcome.html ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''. ]</ref>
<ref name = sourcemaking_tb> [http://sourcemaking.com/antipatterns/the-blob http://sourcemaking.com/antipatterns/the-blob]</ref>
<ref name = wiki_gh> [http://en.wikipedia.org/wiki/Golden_hammer http://en.wikipedia.org/wiki/Golden_hammer] </ref>
<ref name = sourcemaking_gh> [http://sourcemaking.com/antipatterns/golden-hammer http://sourcemaking.com/antipatterns/golden-hammer] </ref>
<ref name = expertiza> [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza - Reusable learning objects through peer review] </ref>
<ref name = fall2011_oss> [https://docs.google.com/a/ncsu.edu/document/d/1zZ-a_tkLGrbYJbG-2QBCRqe_Y9XLR4AZMH0rc6KvrYU/edit?hl=en_US CSC/ECE517 Fall 2011 OSS Projects in Expertiza] </ref>
<ref name = crypto> Anderson, R. 1993. Why cryptosystems fail. In Proceedings of the 1st ACM Conference on Computer and Communications Security (Fairfax, Virginia, United States, November 03 - 05, 1993). CCS '93 [http://www.cl.cam.ac.uk/~rja14/Papers/wcf.pdf]</ref>
<ref name = wikipedia_atm> [http://en.wikipedia.org/wiki/Automatic_Teller_Machine http://en.wikipedia.org/wiki/Automatic_Teller_Machine]</ref>
<ref name = windowsatm> [http://www.technewsworld.com/story/32350.html "Technology News: Security: Windows Cash-Machine Worm Generates Concern". Technewsworld.com] </ref>
</ref>
</references>

CSC/ECE 517 Fall 2011/ch7 7d rt

2011-11-30T00:55:05Z

Rbjeffer:

AntiPatterns in Software Development
__TOC__

==Introduction==
The term ''antipattern'' was coined by Andrew Koenig<ref name = koenig/>, in 1995. His inspiration was a story told about Thomas Edison's many failed attempts to find a suitable material for the filament of a light bulb. When asked if he was discouraged, Edison replied that indeed he was not; he now knew hundreds of items that wouldn't work.

Koenig believed that the same philosophy should be applied to software development. As he studied the book ''Design Patterns'' presented by the Gang of Four<ref name = gof/>, he felt that it was just as important to identify potential pitfalls as well as positive practices. He named these non-solutions ''antipatterns''. He defined an ''antipattern'' as "just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn't one." <ref name = koenig/>

In 1998, a different group of four expanded on this idea publishing '''''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis'''''<ref name = ap/>. The book identified antipatterns from three different viewpoints: the software developer, the software architect and the software manager. The authors used two criteria to distinguish antipatterns:
* It was a frequent occurrence, that initially seemed to be beneficial, but ultimately was not and
* There is a alternate, preferred solution that is proven and repeatable.

Through the years the concept of antipatterns has been further extended to apply to additional areas of software development as well as areas outside the realm of programming. This article will address software development antipatterns.

Just like patterns, antipatterns have certain elements. They include:
# Name so that they can be identified.
# A description of why the bad solution might be attractive.
# An explanation of how that solution is bad long-term.
# Suggestions for other patterns that provide better solutions.

There are several catalogs of antipatterns available as well as a number of books that address the topic. Below we will explore a few of the more common antipatterns.

==AntiPatterns==
===Call Super===

====Description====
We are all familiar with the concept of inheritance in object-oriented programming where a subclass takes on the properties and actions of a superclass. The subclass can then override the methods of the superclass either replacing or augmenting the functionality provided in the superclass. The '''call super''' antipattern requires subclasses to override methods of the super class and then call back the overridden method at some point. This requirement may stem from the fact that the superclass does some set up operations that cannot be done in the subclass or if the subclass is expanding the superclass task rather than replacing it.

Calling a superclass method from a subclass is not in general a bad practice, but '''requiring''' it to do so is. Imposing such a constraint can lead to several problems. Future developers may forget to call the superclass causing untold bugs and system errors. Additionally, it requires anyone using the interface to have an understanding of the inner workings of the superclass. Ideally, they would only need to understand the public interface. Finally, if the superclass expects specific actions from the subclass, it may not perform well (or at all) if those actions aren't performed as expected.

A better approach to obtaining the desired functionality would be to use the [http://en.wikipedia.org/wiki/Template_method_pattern Template Method] pattern. Here the superclass would include a public method and define a separate method (often called a hook method) for the subclass to override. The superclass method would then call the hook method. The hook method can either be an abstract method in the superclass and fully implemented in the subclass, or have some basic functionality in the superclass and augmented in the superclass. Either way the subclass does not have to worry about calling the superclass.

====Example====

Let's say we have a class registration framework with an EventHandler superclass. The EventHandler is used to process all "transactions" - administrators adding classes, students registering for classes, students dropping classes, etc. It has to do some basic setup and housekeeping functions (checking availability, permissions, etc.) before the registration event can be processed. Our original code for a student registering for a class might be something like the following.

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
}

public class StudentClassRegistrationHandler extends EventHandler...
public void handle(RegistrationEvent e) {
super.handle(e);
RegisterStudent(e);
}

The method StudentClassRegistrationHandler must call super.handle() before it can begin its task of registering the student. If we refactor this code using the Template Method pattern, we could get the following code:

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
doAction(e);
}
protected void doAction(RegistrationEvent e) {
}

public class StudentClassRegistrationHandler extends EventHandler ...
protected void doAction(RegistrationEvent e) {
RegisterStudent(e);
}

The subclass is now only responsible for its own functionality. This arrangement also allows the superclass to call some follow-up or clean-up methods after the subclass method if necessary.

===BaseBean===

====Description====
Similar to the Call Super antipattern is the BaseBean antipattern. It is found in object-oriented programming when a concrete domain class is formed using inheritance from a utility class. This relationship is used simply to inherit utility methods from the utility class. This is sometimes referred to as inheritance for implementation.

Inheritance for the sake of gaining the functionality in the parent class is not good style. This obviously is not an "is-a" a relationship and may violate the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle]. By inheriting from the utility class, the domain class becomes dependent on the internals of the utility class. This can make the system difficult to maintain. Additionally, the domain class now has all the functionality of the utility class - some of which it might not need. This blurs the concept of the domain class and may cause it to have more than a single responsibility.

In good object-oriented programming, objects should be representative of the real-world entities they exemplify and should relate to each other as such. In this scenario a "has-a" relationship would be more appropriate. The inherited functionality can be obtained using delegation instead of inheritance. By using the [http://en.wikipedia.org/wiki/Composition_over_inheritance composition over inheritance] principle, we can avoid the BaseBean antipattern.

====Example====

Let's say we want to create a class that emulates a toll booth. The cars at the toll booth form a queue, so our toll booth will need the functionality (queue, dequeue, isEmpty, etc.) of a queue. We could implement our toll booth by inheriting this functionality from a Queue class as such:

public class TollBooth extends Queue{
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Obviously, a tollbooth is not a queue, but more appropriately, has a queue. Hence, our toll booth class should be created to contain a queue to model the line of cars.

public class TollBooth
private Queue<Vehicles>
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Our TollBooth class now has the functionality it needs without the inherent liabilities of extending the Queue class.

===The Blob===
====Description====
'''The Blob''', also called a '''God Class''', is a development antipattern that results when one single class has too many attributes, operations, or both.<ref name = sourcemaking_tb/> '''The Blob''' is usually an indicator of poor object-oriented design, or a poorly-migrated legacy program.<ref name = ap/> It can often resemble a procedural 'main' program, and may even encapsulate most or all of the functionality of an application. '''The Blob''' class violates the ''One Responsibility Rule'', which makes it unlikely to be reusable. Because it has many responsibilities, it would be difficult to reuse in a future project. '''The Blob''' class may be expensive to load into memory, and wasteful if only part of the functionality is used. It also will likely be difficult to effectively test.<ref name = ap/> '''The Blob''' is typically caused by a lack of an object-oriented architecture.<ref name = ap/> It can also be the result of an up-front object-oriented design that did not take into account a requirement, and developers choosing not to rearrange the class hierarchy after the initial design. It can also be a ''Specified Disaster''; the result of requirements that specify a procedural solution.<ref name = ap/>

The solution to '''The Blob''' is to refactor the code, with the goal of moving behavior away from the offending class.<ref name = sourcemaking_tb /> If '''The Blob''' encapsulates data in some other objects, then code manipulating that data should be moved to the other classes, in an effort to make the other classes more complex and '''The Blob''' less complex. If possible, the developers should try to split '''The Blob''' into multiple classes with class minimal coupling.

====Example====
An example of class approaching '''The Blob''' that may be familiar to many students this semester is the [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza] Project's assignment model.<ref name="expertiza" /> The assignment model in Expertiza does not encapsulate the majority of functionality in the entire application, but it is out of proportion with most of the other classes, and it does include functionality that should be in some other classes.<ref name="fall2011_oss" /> One of the Open-Source Software projects for this semester is to correct some of these problems. The project assignment contains the following notes:<ref name="fall2011_oss" />

<blockquote>[The assignment model] contains functionality for adding and removing participants for this assignment, which should really be in a participant class, for assigning reviewers, which should probably be in a reviewer class, and for computing the maximum score possible on a questionnaire. Functions like compute_scores, and candidate_topics_to_review, among others, should be moved to other classes.</blockquote>

These notes describe some of the excessive functionality of assignment.rb. It also suggests some other classes that would be more appropriate locations for some functionalities. If these modifications are made, then the assignment model will be of a more manageable size, and will not be in danger of becoming '''The Blob'''.

===Golden Hammer===
====Description====
The '''Golden Hammer''' design AntiPattern, also known as the '''Law of the instrument''', is an over-reliance on a familiar tool.<ref name="wiki_gh" /> It is one of the most common antipatterns seen in the industry.<ref name="sourcemaking_gh" />

Many software engineering projects solve problems or use techniques that programmers are strongly familiar with. Programmers often reuse strategies, algorithms, or entire sections of code that they or another programmer has applied to a different project in the past. Reuse in this manner can save development time and cost, but only when reused code is appropriate for the new application.

The '''Golden Hammer''' design anti-pattern results from reusing a familiar solution that is a poor match for a new problem.<ref name="sourcemaking_gh" /> This can occur if the developers are simply comfortable with or used to an existing approach, or even the result of narrow-mindedness or hubris. It can also be the direct result of reliance on proprietary technologies or products, or a deliberate effort to try to build a previous projects' success into a new program. A '''Golden Hammer''' will typically manifest itself with poor performance or scalability.<ref name="sourcemaking_gh" />

====Example====

When [http://en.wikipedia.org/wiki/Automated_teller_machine Automated Teller Machines (ATMs)] were popularized in the 1970s, they were often designed using [http://en.wikipedia.org/wiki/Computer_terminal Dumb Terminals], a contemporary computer technology. In the 1990s and 2000s, many banks began replacing their aging ATMs with more modern ones that were physically more difficult to break into. Many of these banks have not changed the communication protocols that the ATMs use to conduct transactions with the bank's servers or mainframe, because weaknesses in the protocol or cryptography is not the cause of most ATM fraud.<ref name="crypto" /> As a result, many banks designed new ATMs that were required to somehow use the existing technology: encrypted dumb terminal sessions. The majority of these systems that have been deployed used a familiar '''Golden Hammer''' to do this: [http://en.wikipedia.org/wiki/Terminal_emulator Terminal Emulator] software installed on a variant of the [http://en.wikipedia.org/wiki/Microsoft_windows Microsoft Windows] operating system.<ref name="wikipedia_atm" />

==Conclusion==

In this article, we have described some of the most commonly occurring AntiPatterns. AntiPatterns comprise a set of defective processes and pitfalls in software development. They describe common errors in judgment or design made by both software engineers and project managers. They explain the causes of these errors, and offer suggestions for correcting the errors. AntiPatterns also define a standard set of vocabulary, so that they can be understood broadly. They are important for both programmers and managers to know and understand, in order to avoid costly mistakes. This design decision has several negative effects, including:
+ Increased unit cost of ATMs, because each one must have a licensed copy of a commercial operating system
+ Concerns about the reliability and trustworthiness of the underlying ATM software<ref name=windowsatm />

==Resources==

For additional information regarding antipatterns, check out the following resources.

===Books===

* [http://www.amazon.com/exec/obidos/ISBN=0471197130/portlandpatternrA/ ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''.] Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, (ed) (1998).

* [http://sourcemaking.com/antipatterns-book ''AntiPatterns: The Survival Guide'']

* [http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612 ''Design Patterns: Elements of Reusable Object-Oriented Software''] by Erich Gamma, Richard Helm], Ralph Johnson, and John Vlissides(the Gang Of Four)

===Websites===

* [http://c2.com/cgi/wiki?AntiPatternsCatalog AntiPatterns Catalog]

* [http://www.antipatterns.com/ AntiPatterns.com] Web site for the ''AntiPatterns'' book

* [http://en.wikipedia.org/wiki/Category:Anti-patterns Wikipedia Antipatterns Category]

==References==
<references>
<ref name = koenig> Koenig, Andrew (March/April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming 8 (1): 46–48.; was later re-printed in the: Rising, Linda (1998). [http://books.google.com/?id=HBAuixGMYWEC&pg=PT1&dq=0-521-64818-1 The patterns handbook: techniques, strategies, and applications]. Cambridge, U.K.: Cambridge University Press. p. 387. </ref>
<ref name = gof> [http://en.wikipedia.org/wiki/Design_Patterns_%28book%29 Design Patterns] by the Gang of Four</ref>
<ref name = ap> Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, Theresa Hudson (ed) (1998). [http://www.antipatterns.com/AntiPatterns/Welcome.html ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''. ]</ref>
<ref name = sourcemaking_tb> [http://sourcemaking.com/antipatterns/the-blob http://sourcemaking.com/antipatterns/the-blob]</ref>
<ref name = wiki_gh> [http://en.wikipedia.org/wiki/Golden_hammer http://en.wikipedia.org/wiki/Golden_hammer] </ref>
<ref name = sourcemaking_gh> [http://sourcemaking.com/antipatterns/golden-hammer http://sourcemaking.com/antipatterns/golden-hammer] </ref>
<ref name = expertiza> [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza - Reusable learning objects through peer review] </ref>
<ref name = fall2011_oss> [https://docs.google.com/a/ncsu.edu/document/d/1zZ-a_tkLGrbYJbG-2QBCRqe_Y9XLR4AZMH0rc6KvrYU/edit?hl=en_US CSC/ECE517 Fall 2011 OSS Projects in Expertiza] </ref>
<ref name = crypto> Anderson, R. 1993. Why cryptosystems fail. In Proceedings of the 1st ACM Conference on Computer and Communications Security (Fairfax, Virginia, United States, November 03 - 05, 1993). CCS '93 [http://www.cl.cam.ac.uk/~rja14/Papers/wcf.pdf]</ref>
<ref name = wikipedia_atm> [http://en.wikipedia.org/wiki/Automatic_Teller_Machine http://en.wikipedia.org/wiki/Automatic_Teller_Machine]</ref>
<ref name = windowsatm> [http://www.technewsworld.com/story/32350.html "Technology News: Security: Windows Cash-Machine Worm Generates Concern". Technewsworld.com] </ref>
</ref>
</references>

CSC/ECE 517 Fall 2011/ch7 7d rt

2011-11-30T00:46:53Z

Rbjeffer:

AntiPatterns in Software Development
__TOC__

==Introduction==
The term ''antipattern'' was coined by Andrew Koenig<ref name = koenig/>, in 1995. His inspiration was a story told about Thomas Edison's many failed attempts to find a suitable material for the filament of a light bulb. When asked if he was discouraged, Edison replied that indeed he was not; he now knew hundreds of items that wouldn't work.

Koenig believed that the same philosophy should be applied to software development. As he studied the book ''Design Patterns'' presented by the Gang of Four<ref name = gof/>, he felt that it was just as important to identify potential pitfalls as well as positive practices. He named these non-solutions ''antipatterns''. He defined an ''antipattern'' as "just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn't one." <ref name = koenig/>

In 1998, a different group of four expanded on this idea publishing '''''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis'''''<ref name = ap/>. The book identified antipatterns from three different viewpoints: the software developer, the software architect and the software manager. The authors used two criteria to distinguish antipatterns:
* It was a frequent occurrence, that initially seemed to be beneficial, but ultimately was not and
* There is a alternate, preferred solution that is proven and repeatable.

Through the years the concept of antipatterns has been further extended to apply to additional areas of software development as well as areas outside the realm of programming. This article will address software development antipatterns.

Just like patterns, antipatterns have certain elements. They include:
# Name so that they can be identified.
# A description of why the bad solution might be attractive.
# An explanation of how that solution is bad long-term.
# Suggestions for other patterns that provide better solutions.

There are several catalogs of antipatterns available as well as a number of books that address the topic. Below we will explore a few of the more common antipatterns.

==AntiPatterns==
===Call Super===

====Description====
We are all familiar with the concept of inheritance in object-oriented programming where a subclass takes on the properties and actions of a superclass. The subclass can then override the methods of the superclass either replacing or augmenting the functionality provided in the superclass. The '''call super''' antipattern requires subclasses to override methods of the super class and then call back the overridden method at some point. This requirement may stem from the fact that the superclass does some set up operations that cannot be done in the subclass or if the subclass is expanding the superclass task rather than replacing it.

Calling a superclass method from a subclass is not in general a bad practice, but '''requiring''' it to do so is. Imposing such a constraint can lead to several problems. Future developers may forget to call the superclass causing untold bugs and system errors. Additionally, it requires anyone using the interface to have an understanding of the inner workings of the superclass. Ideally, they would only need to understand the public interface. Finally, if the superclass expects specific actions from the subclass, it may not perform well (or at all) if those actions aren't performed as expected.

A better approach to obtaining the desired functionality would be to use the [http://en.wikipedia.org/wiki/Template_method_pattern Template Method] pattern. Here the superclass would include a public method and define a separate method (often called a hook method) for the subclass to override. The superclass method would then call the hook method. The hook method can either be an abstract method in the superclass and fully implemented in the subclass, or have some basic functionality in the superclass and augmented in the superclass. Either way the subclass does not have to worry about calling the superclass.

====Example====

Let's say we have a class registration framework with an EventHandler superclass. The EventHandler is used to process all "transactions" - administrators adding classes, students registering for classes, students dropping classes, etc. It has to do some basic setup and housekeeping functions (checking availability, permissions, etc.) before the registration event can be processed. Our original code for a student registering for a class might be something like the following.

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
}

public class StudentClassRegistrationHandler extends EventHandler...
public void handle(RegistrationEvent e) {
super.handle(e);
RegisterStudent(e);
}

The method StudentClassRegistrationHandler must call super.handle() before it can begin its task of registering the student. If we refactor this code using the Template Method pattern, we could get the following code:

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
doAction(e);
}
protected void doAction(RegistrationEvent e) {
}

public class StudentClassRegistrationHandler extends EventHandler ...
protected void doAction(RegistrationEvent e) {
RegisterStudent(e);
}

The subclass is now only responsible for its own functionality. This arrangement also allows the superclass to call some follow-up or clean-up methods after the subclass method if necessary.

===BaseBean===

====Description====
Similar to the Call Super antipattern is the BaseBean antipattern. It is found in object-oriented programming when a concrete domain class is formed using inheritance from a utility class. This relationship is used simply to inherit utility methods from the utility class. This is sometimes referred to as inheritance for implementation.

Inheritance for the sake of gaining the functionality in the parent class is not good style. This obviously is not an "is-a" a relationship and may violate the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle]. By inheriting from the utility class, the domain class becomes dependent on the internals of the utility class. This can make the system difficult to maintain. Additionally, the domain class now has all the functionality of the utility class - some of which it might not need. This blurs the concept of the domain class and may cause it to have more than a single responsibility.

In good object-oriented programming, objects should be representative of the real-world entities they exemplify and should relate to each other as such. In this scenario a "has-a" relationship would be more appropriate. The inherited functionality can be obtained using delegation instead of inheritance. By using the [http://en.wikipedia.org/wiki/Composition_over_inheritance composition over inheritance] principle, we can avoid the BaseBean antipattern.

====Example====

Let's say we want to create a class that emulates a toll booth. The cars at the toll booth form a queue, so our toll booth will need the functionality (queue, dequeue, isEmpty, etc.) of a queue. We could implement our toll booth by inheriting this functionality from a Queue class as such:

public class TollBooth extends Queue{
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Obviously, a tollbooth is not a queue, but more appropriately, has a queue. Hence, our toll booth class should be created to contain a queue to model the line of cars.

public class TollBooth
private Queue<Vehicles>
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Our TollBooth class now has the functionality it needs without the inherent liabilities of extending the Queue class.

===The Blob===
====Description====
'''The Blob''', also called a '''God Class''', is a development antipattern that results when one single class has too many attributes, operations, or both.<ref name = sourcemaking_tb/> '''The Blob''' is usually an indicator of poor object-oriented design, or a poorly-migrated legacy program.<ref name = ap/> It can often resemble a procedural 'main' program, and may even encapsulate most or all of the functionality of an application. '''The Blob''' class violates the ''One Responsibility Rule'', which makes it unlikely to be reusable. Because it has many responsibilities, it would be difficult to reuse in a future project. '''The Blob''' class may be expensive to load into memory, and wasteful if only part of the functionality is used. It also will likely be difficult to effectively test.<ref name = ap/> '''The Blob''' is typically caused by a lack of an object-oriented architecture.<ref name = ap/> It can also be the result of an up-front object-oriented design that did not take into account a requirement, and developers choosing not to rearrange the class hierarchy after the initial design. It can also be a ''Specified Disaster''; the result of requirements that specify a procedural solution.<ref name = ap/>

The solution to '''The Blob''' is to refactor the code, with the goal of moving behavior away from the offending class.<ref name = sourcemaking_tb /> If '''The Blob''' encapsulates data in some other objects, then code manipulating that data should be moved to the other classes, in an effort to make the other classes more complex and '''The Blob''' less complex. If possible, the developers should try to split '''The Blob''' into multiple classes with class minimal coupling.

====Example====
An example of class approaching '''The Blob''' that may be familiar to many students this semester is the [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza] Project's assignment model.<ref name="expertiza" /> The assignment model in Expertiza does not encapsulate the majority of functionality in the entire application, but it is out of proportion with most of the other classes, and it does include functionality that should be in some other classes.<ref name="fall2011_oss" /> One of the Open-Source Software projects for this semester is to correct some of these problems. The project assignment contains the following notes:<ref name="fall2011_oss" />

<blockquote>[The assignment model] contains functionality for adding and removing participants for this assignment, which should really be in a participant class, for assigning reviewers, which should probably be in a reviewer class, and for computing the maximum score possible on a questionnaire. Functions like compute_scores, and candidate_topics_to_review, among others, should be moved to other classes.</blockquote>

These notes describe some of the excessive functionality of assignment.rb. It also suggests some other classes that would be more appropriate locations for some functionalities. If these modifications are made, then the assignment model will be of a more manageable size, and will not be in danger of becoming '''The Blob'''.

===Golden Hammer===
====Description====
The '''Golden Hammer''' design AntiPattern, also known as the '''Law of the instrument''', is an over-reliance on a familiar tool.<ref name="wiki_gh" /> It is one of the most common antipatterns seen in the industry.<ref name="sourcemaking_gh" />

Many software engineering projects solve problems or use techniques that programmers are strongly familiar with. Programmers often reuse strategies, algorithms, or entire sections of code that they or another programmer has applied to a different project in the past. Reuse in this manner can save development time and cost, but only when reused code is appropriate for the new application.

The '''Golden Hammer''' design anti-pattern results from reusing a familiar solution that is a poor match for a new problem.<ref name="sourcemaking_gh" /> This can occur if the developers are simply comfortable with or used to an existing approach, or even the result of narrow-mindedness or hubris. It can also be the direct result of reliance on proprietary technologies or products, or a deliberate effort to try to build a previous projects' success into a new program. A '''Golden Hammer''' will typically manifest itself with poor performance or scalability.<ref name="sourcemaking_gh" />

====Example====

When [http://en.wikipedia.org/wiki/Automated_teller_machine Automated Teller Machines (ATMs)] were popularized in the 1970s, they were often designed using [http://en.wikipedia.org/wiki/Computer_terminal Dumb Terminals], a contemporary computer technology. In the 1990s and 2000s, many banks began replacing their aging ATMs with more modern ones that were physically more difficult to break into. Many of these banks have not changed the communication protocols that the ATMs use to conduct transactions with the bank's servers or mainframe, because weaknesses in the protocol or cryptography is not the cause of most ATM fraud.<ref name="crypto" /> As a result, many banks designed new ATMs that were required to somehow use the existing technology: encrypted dumb terminal sessions. The majority of these systems that have been deployed used a familiar '''Golden Hammer''' to do this: [http://en.wikipedia.org/wiki/Terminal_emulator Terminal Emulator] software installed on a variant of the [http://en.wikipedia.org/wiki/Microsoft_windows Microsoft Windows] operating system.

==Conclusion==

In this article, we have described some of the most commonly occurring AntiPatterns. AntiPatterns comprise a set of defective processes and pitfalls in software development. They describe common errors in judgment or design made by both software engineers and project managers. They explain the causes of these errors, and offer suggestions for correcting the errors. AntiPatterns also define a standard set of vocabulary, so that they can be understood broadly. They are important for both programmers and managers to know and understand, in order to avoid costly mistakes.

==Resources==

For additional information regarding antipatterns, check out the following resources.

===Books===

* [http://www.amazon.com/exec/obidos/ISBN=0471197130/portlandpatternrA/ ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''.] Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, (ed) (1998).

* [http://sourcemaking.com/antipatterns-book ''AntiPatterns: The Survival Guide'']

* [http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612 ''Design Patterns: Elements of Reusable Object-Oriented Software''] by Erich Gamma, Richard Helm], Ralph Johnson, and John Vlissides(the Gang Of Four)

===Websites===

* [http://c2.com/cgi/wiki?AntiPatternsCatalog AntiPatterns Catalog]

* [http://www.antipatterns.com/ AntiPatterns.com] Web site for the ''AntiPatterns'' book

* [http://en.wikipedia.org/wiki/Category:Anti-patterns Wikipedia Antipatterns Category]

==References==
<references>
<ref name = koenig> Koenig, Andrew (March/April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming 8 (1): 46–48.; was later re-printed in the: Rising, Linda (1998). [http://books.google.com/?id=HBAuixGMYWEC&pg=PT1&dq=0-521-64818-1 The patterns handbook: techniques, strategies, and applications]. Cambridge, U.K.: Cambridge University Press. p. 387. </ref>
<ref name = gof> [http://en.wikipedia.org/wiki/Design_Patterns_%28book%29 Design Patterns] by the Gang of Four</ref>
<ref name = ap> Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, Theresa Hudson (ed) (1998). [http://www.antipatterns.com/AntiPatterns/Welcome.html ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''. ]</ref>
<ref name = sourcemaking_tb> [http://sourcemaking.com/antipatterns/the-blob http://sourcemaking.com/antipatterns/the-blob]</ref>
<ref name = wiki_gh> [http://en.wikipedia.org/wiki/Golden_hammer http://en.wikipedia.org/wiki/Golden_hammer] </ref>
<ref name = sourcemaking_gh> [http://sourcemaking.com/antipatterns/golden-hammer http://sourcemaking.com/antipatterns/golden-hammer] </ref>
<ref name = expertiza> [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza - Reusable learning objects through peer review] </ref>
<ref name = fall2011_oss> [https://docs.google.com/a/ncsu.edu/document/d/1zZ-a_tkLGrbYJbG-2QBCRqe_Y9XLR4AZMH0rc6KvrYU/edit?hl=en_US CSC/ECE517 Fall 2011 OSS Projects in Expertiza] </ref>
<ref name = crypto> Anderson, R. 1993. Why cryptosystems fail. In Proceedings of the 1st ACM Conference on Computer and Communications Security (Fairfax, Virginia, United States, November 03 - 05, 1993). CCS '93 [http://www.cl.cam.ac.uk/~rja14/Papers/wcf.pdf]</ref>
</ref>
</references>

CSC/ECE 517 Fall 2011/ch7 7d rt

2011-11-30T00:20:16Z

Rbjeffer:

AntiPatterns in Software Development
__TOC__

==Introduction==
The term ''antipattern'' was coined by Andrew Koenig<ref name = koenig/>, in 1995. His inspiration was a story told about Thomas Edison's many failed attempts to find a suitable material for the filament of a light bulb. When asked if he was discouraged, Edison replied that indeed he was not; he now knew hundreds of items that wouldn't work.

Koenig believed that the same philosophy should be applied to software development. As he studied the book ''Design Patterns'' presented by the Gang of Four<ref name = gof/>, he felt that it was just as important to identify potential pitfalls as well as positive practices. He named these non-solutions ''antipatterns''. He defined an ''antipattern'' as "just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn't one." <ref name = koenig/>

In 1998, a different group of four expanded on this idea publishing '''''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis'''''<ref name = ap/>. The book identified antipatterns from three different viewpoints: the software developer, the software architect and the software manager. The authors used two criteria to distinguish antipatterns:
* It was a frequent occurrence, that initially seemed to be beneficial, but ultimately was not and
* There is a alternate, preferred solution that is proven and repeatable.

Through the years the concept of antipatterns has been further extended to apply to additional areas of software development as well as areas outside the realm of programming. This article will address software development antipatterns.

Just like patterns, antipatterns have certain elements. They include:
# Name so that they can be identified.
# A description of why the bad solution might be attractive.
# An explanation of how that solution is bad long-term.
# Suggestions for other patterns that provide better solutions.

There are several catalogs of antipatterns available as well as a number of books that address the topic. Below we will explore a few of the more common antipatterns.

==AntiPatterns==
===Call Super===

====Description====
We are all familiar with the concept of inheritance in object-oriented programming where a subclass takes on the properties and actions of a superclass. The subclass can then override the methods of the superclass either replacing or augmenting the functionality provided in the superclass. The '''call super''' antipattern requires subclasses to override methods of the super class and then call back the overridden method at some point. This requirement may stem from the fact that the superclass does some set up operations that cannot be done in the subclass or if the subclass is expanding the superclass task rather than replacing it.

Calling a superclass method from a subclass is not in general a bad practice, but '''requiring''' it to do so is. Imposing such a constraint can lead to several problems. Future developers may forget to call the superclass causing untold bugs and system errors. Additionally, it requires anyone using the interface to have an understanding of the inner workings of the superclass. Ideally, they would only need to understand the public interface. Finally, if the superclass expects specific actions from the subclass, it may not perform well (or at all) if those actions aren't performed as expected.

A better approach to obtaining the desired functionality would be to use the [http://en.wikipedia.org/wiki/Template_method_pattern Template Method] pattern. Here the superclass would include a public method and define a separate method (often called a hook method) for the subclass to override. The superclass method would then call the hook method. The hook method can either be an abstract method in the superclass and fully implemented in the subclass, or have some basic functionality in the superclass and augmented in the superclass. Either way the subclass does not have to worry about calling the superclass.

====Example====

Let's say we have a class registration framework with an EventHandler superclass. The EventHandler is used to process all "transactions" - administrators adding classes, students registering for classes, students dropping classes, etc. It has to do some basic setup and housekeeping functions (checking availability, permissions, etc.) before the registration event can be processed. Our original code for a student registering for a class might be something like the following.

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
}

public class StudentClassRegistrationHandler extends EventHandler...
public void handle(RegistrationEvent e) {
super.handle(e);
RegisterStudent(e);
}

The method StudentClassRegistrationHandler must call super.handle() before it can begin its task of registering the student. If we refactor this code using the Template Method pattern, we could get the following code:

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
doAction(e);
}
protected void doAction(RegistrationEvent e) {
}

public class StudentClassRegistrationHandler extends EventHandler ...
protected void doAction(RegistrationEvent e) {
RegisterStudent(e);
}

The subclass is now only responsible for its own functionality. This arrangement also allows the superclass to call some follow-up or clean-up methods after the subclass method if necessary.

===BaseBean===

====Description====
Similar to the Call Super antipattern is the BaseBean antipattern. It is found in object-oriented programming when a concrete domain class is formed using inheritance from a utility class. This relationship is used simply to inherit utility methods from the utility class. This is sometimes referred to as inheritance for implementation.

Inheritance for the sake of gaining the functionality in the parent class is not good style. This obviously is not an "is-a" a relationship and may violate the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle]. By inheriting from the utility class, the domain class becomes dependent on the internals of the utility class. This can make the system difficult to maintain. Additionally, the domain class now has all the functionality of the utility class - some of which it might not need. This blurs the concept of the domain class and may cause it to have more than a single responsibility.

In good object-oriented programming, objects should be representative of the real-world entities they exemplify and should relate to each other as such. In this scenario a "has-a" relationship would be more appropriate. The inherited functionality can be obtained using delegation instead of inheritance. By using the [http://en.wikipedia.org/wiki/Composition_over_inheritance composition over inheritance] principle, we can avoid the BaseBean antipattern.

====Example====

Let's say we want to create a class that emulates a toll booth. The cars at the toll booth form a queue, so our toll booth will need the functionality (queue, dequeue, isEmpty, etc.) of a queue. We could implement our toll booth by inheriting this functionality from a Queue class as such:

public class TollBooth extends Queue{
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Obviously, a tollbooth is not a queue, but more appropriately, has a queue. Hence, our toll booth class should be created to contain a queue to model the line of cars.

public class TollBooth
private Queue<Vehicles>
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Our TollBooth class now has the functionality it needs without the inherent liabilities of extending the Queue class.

===The Blob===
====Description====
'''The Blob''', also called a '''God Class''', is a development antipattern that results when one single class has too many attributes, operations, or both.<ref name = sourcemaking_tb/> '''The Blob''' is usually an indicator of poor object-oriented design, or a poorly-migrated legacy program.<ref name = ap/> It can often resemble a procedural 'main' program, and may even encapsulate most or all of the functionality of an application. '''The Blob''' class violates the ''One Responsibility Rule'', which makes it unlikely to be reusable. Because it has many responsibilities, it would be difficult to reuse in a future project. '''The Blob''' class may be expensive to load into memory, and wasteful if only part of the functionality is used. It also will likely be difficult to effectively test.<ref name = ap/> '''The Blob''' is typically caused by a lack of an object-oriented architecture.<ref name = ap/> It can also be the result of an up-front object-oriented design that did not take into account a requirement, and developers choosing not to rearrange the class hierarchy after the initial design. It can also be a ''Specified Disaster''; the result of requirements that specify a procedural solution.<ref name = ap/>

The solution to '''The Blob''' is to refactor the code, with the goal of moving behavior away from the offending class.<ref name = sourcemaking_tb /> If '''The Blob''' encapsulates data in some other objects, then code manipulating that data should be moved to the other classes, in an effort to make the other classes more complex and '''The Blob''' less complex. If possible, the developers should try to split '''The Blob''' into multiple classes with class minimal coupling.

====Example====
An example of class approaching '''The Blob''' that may be familiar to many students this semester is the [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza] Project's assignment model.<ref name="expertiza" /> The assignment model in Expertiza does not encapsulate the majority of functionality in the entire application, but it is out of proportion with most of the other classes, and it does include functionality that should be in some other classes.<ref name="fall2011_oss" /> One of the Open-Source Software projects for this semester is to correct some of these problems. The project assignment contains the following notes:<ref name="fall2011_oss" />

<blockquote>[The assignment model] contains functionality for adding and removing participants for this assignment, which should really be in a participant class, for assigning reviewers, which should probably be in a reviewer class, and for computing the maximum score possible on a questionnaire. Functions like compute_scores, and candidate_topics_to_review, among others, should be moved to other classes.</blockquote>

These notes describe some of the excessive functionality of assignment.rb. It also suggests some other classes that would be more appropriate locations for some functionalities. If these modifications are made, then the assignment model will be of a more manageable size, and will not be in danger of becoming '''The Blob'''.

===Golden Hammer===
====Description====
The '''Golden Hammer''' design AntiPattern, also known as the '''Law of the instrument''', is an over-reliance on a familiar tool.<ref name="wiki_gh" /> It is one of the most common antipatterns seen in the industry.<ref name="sourcemaking_gh" />

Many software engineering projects solve problems or use techniques that programmers are strongly familiar with. Programmers often reuse strategies, algorithms, or entire sections of code that they or another programmer has applied to a different project in the past. Reuse in this manner can save development time and cost, but only when reused code is appropriate for the new application.

The '''Golden Hammer''' design anti-pattern results from reusing a familiar solution that is a poor match for a new problem.<ref name="sourcemaking_gh" /> This can occur if the developers are simply comfortable with or used to an existing approach, or even the result of narrow-mindedness or hubris. It can also be the direct result of reliance on proprietary technologies or products, or a deliberate effort to try to build a previous projects' success into a new program. A '''Golden Hammer''' will typically manifest itself with poor performance or scalability.<ref name="sourcemaking_gh" />
==Conclusion==

In this article, we have described some of the most commonly occurring AntiPatterns. AntiPatterns comprise a set of defective processes and pitfalls in software development. They describe common errors in judgment or design made by both software engineers and project managers. They explain the causes of these errors, and offer suggestions for correcting the errors. AntiPatterns also define a standard set of vocabulary, so that they can be understood broadly. They are important for both programmers and managers to know and understand, in order to avoid costly mistakes.

==Resources==

For additional information regarding antipatterns, check out the following resources.

===Books===

* [http://www.amazon.com/exec/obidos/ISBN=0471197130/portlandpatternrA/ ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''.] Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, (ed) (1998).

* [http://sourcemaking.com/antipatterns-book ''AntiPatterns: The Survival Guide'']

* [http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612 ''Design Patterns: Elements of Reusable Object-Oriented Software''] by Erich Gamma, Richard Helm], Ralph Johnson, and John Vlissides(the Gang Of Four)

===Websites===

* [http://c2.com/cgi/wiki?AntiPatternsCatalog AntiPatterns Catalog]

* [http://www.antipatterns.com/ AntiPatterns.com] Web site for the ''AntiPatterns'' book

* [http://en.wikipedia.org/wiki/Category:Anti-patterns Wikipedia Antipatterns Category]

==References==
<references>
<ref name = koenig> Koenig, Andrew (March/April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming 8 (1): 46–48.; was later re-printed in the: Rising, Linda (1998). [http://books.google.com/?id=HBAuixGMYWEC&pg=PT1&dq=0-521-64818-1 The patterns handbook: techniques, strategies, and applications]. Cambridge, U.K.: Cambridge University Press. p. 387. </ref>
<ref name = gof> [http://en.wikipedia.org/wiki/Design_Patterns_%28book%29 Design Patterns] by the Gang of Four</ref>
<ref name = ap> Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, Theresa Hudson (ed) (1998). [http://www.antipatterns.com/AntiPatterns/Welcome.html ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''. ]</ref>
<ref name = sourcemaking_tb> [http://sourcemaking.com/antipatterns/the-blob http://sourcemaking.com/antipatterns/the-blob]</ref>
<ref name = wiki_gh> [http://en.wikipedia.org/wiki/Golden_hammer http://en.wikipedia.org/wiki/Golden_hammer] </ref>
<ref name = sourcemaking_gh> [http://sourcemaking.com/antipatterns/golden-hammer http://sourcemaking.com/antipatterns/golden-hammer] </ref>
<ref name = expertiza> [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza - Reusable learning objects through peer review] </ref>
<ref name = fall2011_oss> [https://docs.google.com/a/ncsu.edu/document/d/1zZ-a_tkLGrbYJbG-2QBCRqe_Y9XLR4AZMH0rc6KvrYU/edit?hl=en_US CSC/ECE517 Fall 2011 OSS Projects in Expertiza] </ref>
</ref>
</references>

CSC/ECE 517 Fall 2011/ch7 7d rt

2011-11-30T00:17:30Z

Rbjeffer:

AntiPatterns in Software Development
__TOC__

==Introduction==
The term ''antipattern'' was coined by Andrew Koenig<ref name = koenig/>, in 1995. His inspiration was a story told about Thomas Edison's many failed attempts to find a suitable material for the filament of a light bulb. When asked if he was discouraged, Edison replied that indeed he was not; he now knew hundreds of items that wouldn't work.

Koenig believed that the same philosophy should be applied to software development. As he studied the book ''Design Patterns'' presented by the Gang of Four<ref name = gof/>, he felt that it was just as important to identify potential pitfalls as well as positive practices. He named these non-solutions ''antipatterns''. He defined an ''antipattern'' as "just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn't one." <ref name = koenig/>

In 1998, a different group of four expanded on this idea publishing '''''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis'''''<ref name = ap/>. The book identified antipatterns from three different viewpoints: the software developer, the software architect and the software manager. The authors used two criteria to distinguish antipatterns:
* It was a frequent occurrence, that initially seemed to be beneficial, but ultimately was not and
* There is a alternate, preferred solution that is proven and repeatable.

Through the years the concept of antipatterns has been further extended to apply to additional areas of software development as well as areas outside the realm of programming. This article will address software development antipatterns.

Just like patterns, antipatterns have certain elements. They include:
# Name so that they can be identified.
# A description of why the bad solution might be attractive.
# An explanation of how that solution is bad long-term.
# Suggestions for other patterns that provide better solutions.

There are several catalogs of antipatterns available as well as a number of books that address the topic. Below we will explore a few of the more common antipatterns.

==AntiPatterns==
===Call Super===

====Description====
We are all familiar with the concept of inheritance in object-oriented programming where a subclass takes on the properties and actions of a superclass. The subclass can then override the methods of the superclass either replacing or augmenting the functionality provided in the superclass. The '''call super''' antipattern requires subclasses to override methods of the super class and then call back the overridden method at some point. This requirement may stem from the fact that the superclass does some set up operations that cannot be done in the subclass or if the subclass is expanding the superclass task rather than replacing it.

Calling a superclass method from a subclass is not in general a bad practice, but '''requiring''' it to do so is. Imposing such a constraint can lead to several problems. Future developers may forget to call the superclass causing untold bugs and system errors. Additionally, it requires anyone using the interface to have an understanding of the inner workings of the superclass. Ideally, they would only need to understand the public interface. Finally, if the superclass expects specific actions from the subclass, it may not perform well (or at all) if those actions aren't performed as expected.

A better approach to obtaining the desired functionality would be to use the [http://en.wikipedia.org/wiki/Template_method_pattern Template Method] pattern. Here the superclass would include a public method and define a separate method (often called a hook method) for the subclass to override. The superclass method would then call the hook method. The hook method can either be an abstract method in the superclass and fully implemented in the subclass, or have some basic functionality in the superclass and augmented in the superclass. Either way the subclass does not have to worry about calling the superclass.

====Example====

Let's say we have a class registration framework with an EventHandler superclass. The EventHandler is used to process all "transactions" - administrators adding classes, students registering for classes, students dropping classes, etc. It has to do some basic setup and housekeeping functions (checking availability, permissions, etc.) before the registration event can be processed. Our original code for a student registering for a class might be something like the following.

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
}

public class StudentClassRegistrationHandler extends EventHandler...
public void handle(RegistrationEvent e) {
super.handle(e);
RegisterStudent(e);
}

The method StudentClassRegistrationHandler must call super.handle() before it can begin its task of registering the student. If we refactor this code using the Template Method pattern, we could get the following code:

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
doAction(e);
}
protected void doAction(RegistrationEvent e) {
}

public class StudentClassRegistrationHandler extends EventHandler ...
protected void doAction(RegistrationEvent e) {
RegisterStudent(e);
}

The subclass is now only responsible for its own functionality. This arrangement also allows the superclass to call some follow-up or clean-up methods after the subclass method if necessary.

===BaseBean===

====Description====
Similar to the Call Super antipattern is the BaseBean antipattern. It is found in object-oriented programming when a concrete domain class is formed using inheritance from a utility class. This relationship is used simply to inherit utility methods from the utility class. This is sometimes referred to as inheritance for implementation.

Inheritance for the sake of gaining the functionality in the parent class is not good style. This obviously is not an "is-a" a relationship and may violate the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle]. By inheriting from the utility class, the domain class becomes dependent on the internals of the utility class. This can make the system difficult to maintain. Additionally, the domain class now has all the functionality of the utility class - some of which it might not need. This blurs the concept of the domain class and may cause it to have more than a single responsibility.

In good object-oriented programming, objects should be representative of the real-world entities they exemplify and should relate to each other as such. In this scenario a "has-a" relationship would be more appropriate. The inherited functionality can be obtained using delegation instead of inheritance. By using the [http://en.wikipedia.org/wiki/Composition_over_inheritance composition over inheritance] principle, we can avoid the BaseBean antipattern.

====Example====

Let's say we want to create a class that emulates a toll booth. The cars at the toll booth form a queue, so our toll booth will need the functionality (queue, dequeue, isEmpty, etc.) of a queue. We could implement our toll booth by inheriting this functionality from a Queue class as such:

public class TollBooth extends Queue{
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Obviously, a tollbooth is not a queue, but more appropriately, has a queue. Hence, our toll booth class should be created to contain a queue to model the line of cars.

public class TollBooth
private Queue<Vehicles>
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Our TollBooth class now has the functionality it needs without the inherent liabilities of extending the Queue class.

===The Blob===
====Description====
'''The Blob''', also called a '''God Class''', is a development antipattern that results when one single class has too many attributes, operations, or both.<ref name = sourcemaking_tb/> '''The Blob''' is usually an indicator of poor object-oriented design, or a poorly-migrated legacy program.<ref name = ap/> It can often resemble a procedural 'main' program, and may even encapsulate most or all of the functionality of an application. '''The Blob''' class violates the ''One Responsibility Rule'', which makes it unlikely to be reusable. Because it has many responsibilities, it would be difficult to reuse in a future project. '''The Blob''' class may be expensive to load into memory, and wasteful if only part of the functionality is used. It also will likely be difficult to effectively test.<ref name = ap/> '''The Blob''' is typically caused by a lack of an object-oriented architecture.<ref name = ap/> It can also be the result of an up-front object-oriented design that did not take into account a requirement, and developers choosing not to rearrange the class hierarchy after the initial design. It can also be a ''Specified Disaster''; the result of requirements that specify a procedural solution.<ref name = ap/>

The solution to '''The Blob''' is to refactor the code, with the goal of moving behavior away from the offending class.<ref name = sourcemaking_tb /> If '''The Blob''' encapsulates data in some other objects, then code manipulating that data should be moved to the other classes, in an effort to make the other classes more complex and '''The Blob''' less complex. If possible, the developers should try to split '''The Blob''' into multiple classes with class minimal coupling.

====Example====
An example of class approaching '''The Blob''' that may be familiar to many students this semester is the [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza] Project's assignment model.<ref name="expertiza" /> The assignment model in Expertiza does not encapsulate the majority of functionality in the entire application, but it is out of proportion with most of the other classes, and it does include functionality that should be in some other classes.<ref name="fall2011_oss" /> One of the Open-Source Software projects for this semester is to correct some of these problems. The project assignment contains the following notes:<ref name="fall2011_oss" />

<blockquote>[The assignment model] contains functionality for adding and removing participants for this assignment, which should really be in a participant class, for assigning reviewers, which should probably be in a reviewer class, and for computing the maximum score possible on a questionnaire. Functions like compute_scores, and candidate_topics_to_review, among others, should be moved to other classes.</blockquote>

These notes describe some of the excessive functionality of assignment.rb. It also suggests some other classes that would be more appropriate locations for some functionalities. If these modifications are made, then the assignment model will be of a more manageable size, and will not be in danger of becoming '''The Blob'''.

===Golden Hammer===
====Description====
The '''Golden Hammer''' design AntiPattern, also known as the '''Law of the instrument''', is an over-reliance on a familiar tool.<ref name="wiki_gh" /> It is one of the most common antipatterns seen in the industry.<ref name="sourcemaking_gh" />

Many software engineering projects solve problems or use techniques that programmers are strongly familiar with. Programmers often reuse strategies, algorithms, or entire sections of code that they or another programmer has applied to a different project in the past. Reuse in this manner can save development time and cost, but only when reused code is appropriate for the new application.

The '''Golden Hammer''' design anti-pattern results from reusing a familiar solution that is a poor match for a new problem.<ref name="sourcemaking_gh" /> This can occur if the developers are simply comfortable with or used to an existing approach, or even the result of narrow-mindedness or hubris. It can also be the direct result of reliance on proprietary technologies or products, or a deliberate effort to try to build a previous projects' success into a new program. A '''Golden Hammer''' will typically manifest itself with poor performance or scalability.<ref name="sourcemaking_gh" />
==Conclusion==

In this article, we have described some of the most commonly occurring AntiPatterns. AntiPatterns comprise a set of defective processes and pitfalls in software development. They describe common errors in judgment or design made by both software engineers and project managers. They explain the causes of these errors, and offer suggestions for correcting the errors. AntiPatterns also define a standard set of vocabulary, so that they can be understood broadly. They are important for both programmers and managers to know and understand, in order to avoid costly mistakes.

==Resources==

For additional information regarding antipatterns, check out the following resources.

===Books===

* [http://www.amazon.com/exec/obidos/ISBN=0471197130/portlandpatternrA/ ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''.] Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, (ed) (1998).

* [http://sourcemaking.com/antipatterns-book ''AntiPatterns: The Survival Guide'']

* [http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612 ''Design Patterns: Elements of Reusable Object-Oriented Software''] by Erich Gamma, Richard Helm], Ralph Johnson, and John Vlissides(the Gang Of Four)

===Websites===

* [http://c2.com/cgi/wiki?AntiPatternsCatalog AntiPatterns Catalog]

* [http://www.antipatterns.com/ AntiPatterns.com] Web site for the ''AntiPatterns'' book

* [http://en.wikipedia.org/wiki/Category:Anti-patterns Wikipedia Antipatterns Category]

==References==
<references>
<ref name = koenig> Koenig, Andrew (March/April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming 8 (1): 46–48.; was later re-printed in the: Rising, Linda (1998). [http://books.google.com/?id=HBAuixGMYWEC&pg=PT1&dq=0-521-64818-1 The patterns handbook: techniques, strategies, and applications]. Cambridge, U.K.: Cambridge University Press. p. 387. </ref>
<ref name = gof> [http://en.wikipedia.org/wiki/Design_Patterns_%28book%29 Design Patterns] by Gang of Four</ref>
<ref name = ap> Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, Theresa Hudson (ed) (1998). [http://www.antipatterns.com/AntiPatterns/Welcome.html ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''. ]</ref>
<ref name = sourcemaking_tb> [http://sourcemaking.com/antipatterns/the-blob http://sourcemaking.com/antipatterns/the-blob]</ref>
<ref name = wiki_gh> [http://en.wikipedia.org/wiki/Golden_hammer http://en.wikipedia.org/wiki/Golden_hammer] </ref>
<ref name = sourcemaking_gh> [http://sourcemaking.com/antipatterns/golden-hammer http://sourcemaking.com/antipatterns/golden-hammer] </ref>
<ref name = expertiza> [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza - Reusable learning objects through peer review] </ref>
<ref name = fall2011_oss> [https://docs.google.com/a/ncsu.edu/document/d/1zZ-a_tkLGrbYJbG-2QBCRqe_Y9XLR4AZMH0rc6KvrYU/edit?hl=en_US CSC/ECE517 Fall 2011 OSS Projects in Expertiza] </ref>
</ref>
</references>

CSC/ECE 517 Fall 2011/ch7 7d rt

2011-11-30T00:17:07Z

Rbjeffer:

AntiPatterns in Software Development
__TOC__

==Introduction==
The term ''antipattern'' was coined by Andrew Koenig<ref name = koenig/>, in 1995. His inspiration was a story told about Thomas Edison's many failed attempts to find a suitable material for the filament of a light bulb. When asked if he was discouraged, Edison replied that indeed he was not; he now knew hundreds of items that wouldn't work.

Koenig believed that the same philosophy should be applied to software development. As he studied the book ''Design Patterns'' presented by the Gang of Four<ref name = gof/>, he felt that it was just as important to identify potential pitfalls as well as positive practices. He named these non-solutions ''antipatterns''. He defined an ''antipattern'' as "just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn't one." <ref name = koenig/>

In 1998, a different group of four expanded on this idea publishing '''''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis'''''<ref name = ap/>. The book identified antipatterns from three different viewpoints: the software developer, the software architect and the software manager. The authors used two criteria to distinguish antipatterns:
* It was a frequent occurrence, that initially seemed to be beneficial, but ultimately was not and
* There is a alternate, preferred solution that is proven and repeatable.

Through the years the concept of antipatterns has been further extended to apply to additional areas of software development as well as areas outside the realm of programming. This article will address software development antipatterns.

Just like patterns, antipatterns have certain elements. They include:
# Name so that they can be identified.
# A description of why the bad solution might be attractive.
# An explanation of how that solution is bad long-term.
# Suggestions for other patterns that provide better solutions.

There are several catalogs of antipatterns available as well as a number of books that address the topic. Below we will explore a few of the more common antipatterns.

==AntiPatterns==
===Call Super===

====Description====
We are all familiar with the concept of inheritance in object-oriented programming where a subclass takes on the properties and actions of a superclass. The subclass can then override the methods of the superclass either replacing or augmenting the functionality provided in the superclass. The '''call super''' antipattern requires subclasses to override methods of the super class and then call back the overridden method at some point. This requirement may stem from the fact that the superclass does some set up operations that cannot be done in the subclass or if the subclass is expanding the superclass task rather than replacing it.

Calling a superclass method from a subclass is not in general a bad practice, but '''requiring''' it to do so is. Imposing such a constraint can lead to several problems. Future developers may forget to call the superclass causing untold bugs and system errors. Additionally, it requires anyone using the interface to have an understanding of the inner workings of the superclass. Ideally, they would only need to understand the public interface. Finally, if the superclass expects specific actions from the subclass, it may not perform well (or at all) if those actions aren't performed as expected.

A better approach to obtaining the desired functionality would be to use the [http://en.wikipedia.org/wiki/Template_method_pattern Template Method] pattern. Here the superclass would include a public method and define a separate method (often called a hook method) for the subclass to override. The superclass method would then call the hook method. The hook method can either be an abstract method in the superclass and fully implemented in the subclass, or have some basic functionality in the superclass and augmented in the superclass. Either way the subclass does not have to worry about calling the superclass.

====Example====

Let's say we have a class registration framework with an EventHandler superclass. The EventHandler is used to process all "transactions" - administrators adding classes, students registering for classes, students dropping classes, etc. It has to do some basic setup and housekeeping functions (checking availability, permissions, etc.) before the registration event can be processed. Our original code for a student registering for a class might be something like the following.

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
}

public class StudentClassRegistrationHandler extends EventHandler...
public void handle(RegistrationEvent e) {
super.handle(e);
RegisterStudent(e);
}

The method StudentClassRegistrationHandler must call super.handle() before it can begin its task of registering the student. If we refactor this code using the Template Method pattern, we could get the following code:

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
doAction(e);
}
protected void doAction(RegistrationEvent e) {
}

public class StudentClassRegistrationHandler extends EventHandler ...
protected void doAction(RegistrationEvent e) {
RegisterStudent(e);
}

The subclass is now only responsible for its own functionality. This arrangement also allows the superclass to call some follow-up or clean-up methods after the subclass method if necessary.

===BaseBean===

====Description====
Similar to the Call Super antipattern is the BaseBean antipattern. It is found in object-oriented programming when a concrete domain class is formed using inheritance from a utility class. This relationship is used simply to inherit utility methods from the utility class. This is sometimes referred to as inheritance for implementation.

Inheritance for the sake of gaining the functionality in the parent class is not good style. This obviously is not an "is-a" a relationship and may violate the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle]. By inheriting from the utility class, the domain class becomes dependent on the internals of the utility class. This can make the system difficult to maintain. Additionally, the domain class now has all the functionality of the utility class - some of which it might not need. This blurs the concept of the domain class and may cause it to have more than a single responsibility.

In good object-oriented programming, objects should be representative of the real-world entities they exemplify and should relate to each other as such. In this scenario a "has-a" relationship would be more appropriate. The inherited functionality can be obtained using delegation instead of inheritance. By using the [http://en.wikipedia.org/wiki/Composition_over_inheritance composition over inheritance] principle, we can avoid the BaseBean antipattern.

====Example====

Let's say we want to create a class that emulates a toll booth. The cars at the toll booth form a queue, so our toll booth will need the functionality (queue, dequeue, isEmpty, etc.) of a queue. We could implement our toll booth by inheriting this functionality from a Queue class as such:

public class TollBooth extends Queue{
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Obviously, a tollbooth is not a queue, but more appropriately, has a queue. Hence, our toll booth class should be created to contain a queue to model the line of cars.

public class TollBooth
private Queue<Vehicles>
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Our TollBooth class now has the functionality it needs without the inherent liabilities of extending the Queue class.

===The Blob===
====Description====
'''The Blob''', also called a '''God Class''', is a development antipattern that results when one single class has too many attributes, operations, or both.<ref name = sourcemaking_tb/> '''The Blob''' is usually an indicator of poor object-oriented design, or a poorly-migrated legacy program.<ref name = ap/> It can often resemble a procedural 'main' program, and may even encapsulate most or all of the functionality of an application. '''The Blob''' class violates the ''One Responsibility Rule'', which makes it unlikely to be reusable. Because it has many responsibilities, it would be difficult to reuse in a future project. '''The Blob''' class may be expensive to load into memory, and wasteful if only part of the functionality is used. It also will likely be difficult to effectively test.<ref name = ap/> '''The Blob''' is typically caused by a lack of an object-oriented architecture.<ref name = ap/> It can also be the result of an up-front object-oriented design that did not take into account a requirement, and developers choosing not to rearrange the class hierarchy after the initial design. It can also be a ''Specified Disaster''; the result of requirements that specify a procedural solution.<ref name = ap/>

The solution to '''The Blob''' is to refactor the code, with the goal of moving behavior away from the offending class.<ref name = sourcemaking_tb /> If '''The Blob''' encapsulates data in some other objects, then code manipulating that data should be moved to the other classes, in an effort to make the other classes more complex and '''The Blob''' less complex. If possible, the developers should try to split '''The Blob''' into multiple classes with class minimal coupling.

====Example====
An example of class approaching '''The Blob''' that may be familiar to many students this semester is the [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza] Project's assignment model.<ref name="expertiza" /> The assignment model in Expertiza does not encapsulate the majority of functionality in the entire application, but it is out of proportion with most of the other classes, and it does include functionality that should be in some other classes.<ref name="fall2011_oss" /> One of the Open-Source Software projects for this semester is to correct some of these problems. The project assignment contains the following notes:<ref name="fall2011_oss" />

<blockquote>[The assignment model] contains functionality for adding and removing participants for this assignment, which should really be in a participant class, for assigning reviewers, which should probably be in a reviewer class, and for computing the maximum score possible on a questionnaire. Functions like compute_scores, and candidate_topics_to_review, among others, should be moved to other classes.</blockquote>

These notes describe some of the excessive functionality of assignment.rb. It also suggests some other classes that would be more appropriate locations for some functionalities. If these modifications are made, then the assignment model will be of a more manageable size, and will not be in danger of becoming '''The Blob'''.

===Golden Hammer===
====Description====
The '''Golden Hammer''' design AntiPattern, also known as the '''Law of the instrument''', is an over-reliance on a familiar tool.<ref name="wiki_gh" /> It is one of the most common antipatterns seen in the industry.<ref name="sourcemaking_gh" />

Many software engineering projects solve problems or use techniques that programmers are strongly familiar with. Programmers often reuse strategies, algorithms, or entire sections of code that they or another programmer has applied to a different project in the past. Reuse in this manner can save development time and cost, but only when reused code is appropriate for the new application.

The '''Golden Hammer''' design anti-pattern results from reusing a familiar solution that is a poor match for a new problem.<ref name="sourcemaking_gh" /> This can occur if the developers are simply comfortable with or used to an existing approach, or even the result of narrow-mindedness or hubris. It can also be the direct result of reliance on proprietary technologies or products, or a deliberate effort to try to build a previous projects' success into a new program. A '''Golden Hammer''' will typically manifest itself with poor performance or scalability.<ref name="sourcemaking_gh" />
==Conclusions==

In this article, we have described some of the most commonly occurring AntiPatterns. AntiPatterns comprise a set of defective processes and pitfalls in software development. They describe common errors in judgment or design made by both software engineers and project managers. They explain the causes of these errors, and offer suggestions for correcting the errors. AntiPatterns also define a standard set of vocabulary, so that they can be understood broadly. They are important for both programmers and managers to know and understand, in order to avoid costly mistakes.

==Resources==

For additional information regarding antipatterns, check out the following resources.

===Books===

* [http://www.amazon.com/exec/obidos/ISBN=0471197130/portlandpatternrA/ ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''.] Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, (ed) (1998).

* [http://sourcemaking.com/antipatterns-book ''AntiPatterns: The Survival Guide'']

* [http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612 ''Design Patterns: Elements of Reusable Object-Oriented Software''] by Erich Gamma, Richard Helm], Ralph Johnson, and John Vlissides(the Gang Of Four)

===Websites===

* [http://c2.com/cgi/wiki?AntiPatternsCatalog AntiPatterns Catalog]

* [http://www.antipatterns.com/ AntiPatterns.com] Web site for the ''AntiPatterns'' book

* [http://en.wikipedia.org/wiki/Category:Anti-patterns Wikipedia Antipatterns Category]

==References==
<references>
<ref name = koenig> Koenig, Andrew (March/April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming 8 (1): 46–48.; was later re-printed in the: Rising, Linda (1998). [http://books.google.com/?id=HBAuixGMYWEC&pg=PT1&dq=0-521-64818-1 The patterns handbook: techniques, strategies, and applications]. Cambridge, U.K.: Cambridge University Press. p. 387. </ref>
<ref name = gof> [http://en.wikipedia.org/wiki/Design_Patterns_%28book%29 Design Patterns] by Gang of Four</ref>
<ref name = ap> Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, Theresa Hudson (ed) (1998). [http://www.antipatterns.com/AntiPatterns/Welcome.html ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''. ]</ref>
<ref name = sourcemaking_tb> [http://sourcemaking.com/antipatterns/the-blob http://sourcemaking.com/antipatterns/the-blob]</ref>
<ref name = wiki_gh> [http://en.wikipedia.org/wiki/Golden_hammer http://en.wikipedia.org/wiki/Golden_hammer] </ref>
<ref name = sourcemaking_gh> [http://sourcemaking.com/antipatterns/golden-hammer http://sourcemaking.com/antipatterns/golden-hammer] </ref>
<ref name = expertiza> [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza - Reusable learning objects through peer review] </ref>
<ref name = fall2011_oss> [https://docs.google.com/a/ncsu.edu/document/d/1zZ-a_tkLGrbYJbG-2QBCRqe_Y9XLR4AZMH0rc6KvrYU/edit?hl=en_US CSC/ECE517 Fall 2011 OSS Projects in Expertiza] </ref>
</ref>
</references>

CSC/ECE 517 Fall 2011/ch7 7d rt

2011-11-29T23:26:10Z

Rbjeffer:

AntiPatterns in Software Development
__TOC__

==Introduction==
The term ''antipattern'' was coined by Andrew Koenig<ref name = koenig/>, in 1995. His inspiration was a story told about Thomas Edison's many failed attempts to find a suitable material for the filament of a light bulb. When asked if he was discouraged, Edison replied that indeed he was not; he now knew hundreds of items that wouldn't work.

Koenig believed that the same philosophy should be applied to software development. As he studied the book ''Design Patterns'' presented by the Gang of Four<ref name = gof/>, he felt that it was just as important to identify potential pitfalls as well as positive practices. He named these non-solutions ''antipatterns''. He defined an ''antipattern'' as "just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn't one." <ref name = koenig/>

In 1998, a different group of four expanded on this idea publishing '''''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis'''''<ref name = ap/>. The book identified antipatterns from three different viewpoints: the software developer, the software architect and the software manager. The authors used two criteria to distinguish antipatterns:
* It was a frequent occurrence, that initially seemed to be beneficial, but ultimately was not and
* There is a alternate, preferred solution that is proven and repeatable.

Through the years the concept of antipatterns has been further extended to apply to additional areas of software development as well as areas outside the realm of programming. This article will address software development antipatterns.

Just like patterns, antipatterns have certain elements. They include:
# Name so that they can be identified.
# A description of why the bad solution might be attractive.
# An explanation of how that solution is bad long-term.
# Suggestions for other patterns that provide better solutions.

There are several catalogs of antipatterns available as well as a number of books that address the topic. Below we will explore a few of the more common antipatterns.

==AntiPatterns==
===Call Super===

====Description====
We are all familiar with the concept of inheritance in object-oriented programming where a subclass takes on the properties and actions of a superclass. The subclass can then override the methods of the superclass either replacing or augmenting the functionality provided in the superclass. The '''call super''' antipattern requires subclasses to override methods of the super class and then call back the overridden method at some point. This requirement may stem from the fact that the superclass does some set up operations that cannot be done in the subclass or if the subclass is expanding the superclass task rather than replacing it.

Calling a superclass method from a subclass is not in general a bad practice, but '''requiring''' it to do so is. Imposing such a constraint can lead to several problems. Future developers may forget to call the superclass causing untold bugs and system errors. Additionally, it requires anyone using the interface to have an understanding of the inner workings of the superclass. Ideally, they would only need to understand the public interface. Finally, if the superclass expects specific actions from the subclass, it may not perform well (or at all) if those actions aren't performed as expected.

A better approach to obtaining the desired functionality would be to use the [http://en.wikipedia.org/wiki/Template_method_pattern Template Method] pattern. Here the superclass would include a public method and define a separate method (often called a hook method) for the subclass to override. The superclass method would then call the hook method. The hook method can either be an abstract method in the superclass and fully implemented in the subclass, or have some basic functionality in the superclass and augmented in the superclass. Either way the subclass does not have to worry about calling the superclass.

====Example====

Let's say we have a class registration framework with an EventHandler superclass. The EventHandler is used to process all "transactions" - administrators adding classes, students registering for classes, students dropping classes, etc. It has to do some basic setup and housekeeping functions (checking availability, permissions, etc.) before the registration event can be processed. Our original code for a student registering for a class might be something like the following.

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
}

public class StudentClassRegistrationHandler extends EventHandler...
public void handle(RegistrationEvent e) {
super.handle(e);
RegisterStudent(e);
}

The method StudentClassRegistrationHandler must call super.handle() before it can begin its task of registering the student. If we refactor this code using the Template Method pattern, we could get the following code:

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
doAction(e);
}
protected void doAction(RegistrationEvent e) {
}

public class StudentClassRegistrationHandler extends EventHandler ...
protected void doAction(RegistrationEvent e) {
RegisterStudent(e);
}

The subclass is now only responsible for its own functionality. This arrangement also allows the superclass to call some follow-up or clean-up methods after the subclass method if necessary.

===BaseBean===

====Description====
Similar to the Call Super antipattern is the BaseBean antipattern. It is found in object-oriented programming when a concrete domain class is formed using inheritance from a utility class. This relationship is used simply to inherit utility methods from the utility class. This is sometimes referred to as inheritance for implementation.

Inheritance for the sake of gaining the functionality in the parent class is not good style. This obviously is not an "is-a" a relationship and may violate the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle]. By inheriting from the utility class, the domain class becomes dependent on the internals of the utility class. This can make the system difficult to maintain. Additionally, the domain class now has all the functionality of the utility class - some of which it might not need. This blurs the concept of the domain class and may cause it to have more than a single responsibility.

In good object-oriented programming, objects should be representative of the real-world entities they exemplify and should relate to each other as such. In this scenario a "has-a" relationship would be more appropriate. The inherited functionality can be obtained using delegation instead of inheritance. By using the [http://en.wikipedia.org/wiki/Composition_over_inheritance composition over inheritance] principle, we can avoid the BaseBean antipattern.

====Example====

Let's say we want to create a class that emulates a toll booth. The cars at the toll booth form a queue, so our toll booth will need the functionality (queue, dequeue, isEmpty, etc.) of a queue. We could implement our toll booth by inheriting this functionality from a Queue class as such:

public class TollBooth extends Queue{
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Obviously, a tollbooth is not a queue, but more appropriately, has a queue. Hence, our toll booth class should be created to contain a queue to model the line of cars.

public class TollBooth
private Queue<Vehicles>
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Our TollBooth class now has the functionality it needs without the inherent liabilities of extending the Queue class.

===The Blob===
====Description====
'''The Blob''', also called a '''God Class''', is a development antipattern that results when one single class has too many attributes, operations, or both.<ref name = sourcemaking_tb/> '''The Blob''' is usually an indicator of poor object-oriented design, or a poorly-migrated legacy program.<ref name = ap/> It can often resemble a procedural 'main' program, and may even encapsulate most or all of the functionality of an application. '''The Blob''' class violates the ''One Responsibility Rule'', which makes it unlikely to be reusable. Because it has many responsibilities, it would be difficult to reuse in a future project. '''The Blob''' class may be expensive to load into memory, and wasteful if only part of the functionality is used. It also will likely be difficult to effectively test.<ref name = ap/> '''The Blob''' is typically caused by a lack of an object-oriented architecture.<ref name = ap/> It can also be the result of an up-front object-oriented design that did not take into account a requirement, and developers choosing not to rearrange the class hierarchy after the initial design. It can also be a ''Specified Disaster''; the result of requirements that specify a procedural solution.<ref name = ap/>

The solution to '''The Blob''' is to refactor the code, with the goal of moving behavior away from the offending class.<ref name = sourcemaking_tb /> If '''The Blob''' encapsulates data in some other objects, then code manipulating that data should be moved to the other classes, in an effort to make the other classes more complex and '''The Blob''' less complex. If possible, the developers should try to split '''The Blob''' into multiple classes with class minimal coupling.

====Example====
An example of class approaching '''The Blob''' that may be familiar to many students this semester is the [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza] Project's assignment model.<ref name="expertiza" /> The assignment model in Expertiza does not encapsulate the majority of functionality in the entire application, but it is out of proportion with most of the other classes, and it does include functionality that should be in some other classes.<ref name="fall2011_oss" /> One of the Open-Source Software projects for this semester is to correct some of these problems. The project assignment contains the following notes:<ref name="fall2011_oss" />

<blockquote>[The assignment model] contains functionality for adding and removing participants for this assignment, which should really be in a participant class, for assigning reviewers, which should probably be in a reviewer class, and for computing the maximum score possible on a questionnaire. Functions like compute_scores, and candidate_topics_to_review, among others, should be moved to other classes.</blockquote>

These notes describe some of the excessive functionality of assignment.rb. It also suggests some other classes that would be more appropriate locations for some functionalities. If these modifications are made, then the assignment model will be of a more manageable size, and will not be in danger of becoming '''The Blob'''.

===Golden Hammer===
====Description====
The '''Golden Hammer''' design AntiPattern, also known as the '''Law of the instrument''', is an over-reliance on a familiar tool.<ref name="wiki_gh" /> It is one of the most common antipatterns seen in the industry.<ref name="sourcemaking_gh" />

Many software engineering projects solve problems or use techniques that programmers are strongly familiar with. Programmers often reuse strategies, algorithms, or entire sections of code that they or another programmer has applied to a different project in the past. Reuse in this manner can save development time and cost, but only when reused code is appropriate for the new application.

The '''Golden Hammer''' design anti-pattern results from reusing a familiar solution that is a poor match for a new problem.<ref name="sourcemaking_gh" /> This can occur if the developers are simply comfortable with or used to an existing approach, or even the result of narrow-mindedness or hubris. It can also be the direct result of reliance on proprietary technologies or products, or a deliberate effort to try to build a previous projects' success into a new program. A '''Golden Hammer''' will typically manifest itself with poor performance or scalability.<ref name="sourcemaking_gh" />
==Conclusions==
==Resources==

For additional information regarding antipatterns, check out the following resources.

===Books===

* [http://www.amazon.com/exec/obidos/ISBN=0471197130/portlandpatternrA/ ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''.] Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, (ed) (1998).

* [http://sourcemaking.com/antipatterns-book ''AntiPatterns: The Survival Guide'']

* [http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612 ''Design Patterns: Elements of Reusable Object-Oriented Software''] by Erich Gamma, Richard Helm], Ralph Johnson, and John Vlissides(the Gang Of Four)

===Websites===

* [http://c2.com/cgi/wiki?AntiPatternsCatalog AntiPatterns Catalog]

* [http://www.antipatterns.com/ AntiPatterns.com] Web site for the ''AntiPatterns'' book

* [http://en.wikipedia.org/wiki/Category:Anti-patterns Wikipedia Antipatterns Category]

==References==
<references>
<ref name = koenig> Koenig, Andrew (March/April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming 8 (1): 46–48.; was later re-printed in the: Rising, Linda (1998). [http://books.google.com/?id=HBAuixGMYWEC&pg=PT1&dq=0-521-64818-1 The patterns handbook: techniques, strategies, and applications]. Cambridge, U.K.: Cambridge University Press. p. 387. </ref>
<ref name = gof> [http://en.wikipedia.org/wiki/Design_Patterns_%28book%29 Design Patterns] by Gang of Four</ref>
<ref name = ap> Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, Theresa Hudson (ed) (1998). [http://www.antipatterns.com/AntiPatterns/Welcome.html ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''. ]</ref>
<ref name = sourcemaking_tb> [http://sourcemaking.com/antipatterns/the-blob http://sourcemaking.com/antipatterns/the-blob]</ref>
<ref name = wiki_gh> [http://en.wikipedia.org/wiki/Golden_hammer http://en.wikipedia.org/wiki/Golden_hammer] </ref>
<ref name = sourcemaking_gh> [http://sourcemaking.com/antipatterns/golden-hammer http://sourcemaking.com/antipatterns/golden-hammer] </ref>
<ref name = expertiza> [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza - Reusable learning objects through peer review] </ref>
<ref name = fall2011_oss> [https://docs.google.com/a/ncsu.edu/document/d/1zZ-a_tkLGrbYJbG-2QBCRqe_Y9XLR4AZMH0rc6KvrYU/edit?hl=en_US CSC/ECE517 Fall 2011 OSS Projects in Expertiza] </ref>
</ref>
</references>

CSC/ECE 517 Fall 2011/ch7 7d rt

2011-11-29T23:13:38Z

Rbjeffer:

AntiPatterns in Software Development
__TOC__

==Introduction==
The term ''antipattern'' was coined by Andrew Koenig<ref name = koenig/>, in 1995. His inspiration was a story told about Thomas Edison's many failed attempts to find a suitable material for the filament of a light bulb. When asked if he was discouraged, Edison replied that indeed he was not; he now knew hundreds of items that wouldn't work.

Koenig believed that the same philosophy should be applied to software development. As he studied the book ''Design Patterns'' presented by the GoF<ref name = gof/>, he felt that it was just as important to identify potential pitfalls as well as positive practices. He named these non-solutions ''antipatterns''. He defined an ''antipattern'' as "just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn't one." <ref name = koenig/>

In 1998, a different group of four expanded on this idea publishing '''''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis'''''<ref name = ap/>. The book identified antipatterns from three different viewpoints: the software developer, the software architect and the software manager. The authors used two criteria to distinguish antipatterns:
* It was a frequent occurrence, that initially seemed to be beneficial, but ultimately was not and
* There is a alternate, preferred solution that is proven and repeatable.

Through the years the concept of antipatterns has been further extended to apply to additional areas of software development as well as areas outside the realm of programming. This article will address software development antipatterns.

Just like patterns, antipatterns have certain elements. They include:
# Name so that they can be identified.
# A description of why the bad solution might be attractive.
# An explanation of how that solution is bad long-term.
# Suggestions for other patterns that provide better solutions.

There are several catalogs of antipatterns available as well as a number of books that address the topic. Below we will explore a few of the more common antipatterns.

==AntiPatterns==
===Call Super===

====Description====
We are all familiar with the concept of inheritance in object-oriented programming where a subclass takes on the properties and actions of a superclass. The subclass can then override the methods of the superclass either replacing or augmenting the functionality provided in the superclass. The '''call super''' antipattern requires subclasses to override methods of the super class and then call back the overridden method at some point. This requirement may stem from the fact that the superclass does some set up operations that cannot be done in the subclass or if the subclass is expanding the superclass task rather than replacing it.

Calling a superclass method from a subclass is not in general a bad practice, but '''requiring''' it to do so is. Imposing such a constraint can lead to several problems. Future developers may forget to call the superclass causing untold bugs and system errors. Additionally, it requires anyone using the interface to have an understanding of the inner workings of the superclass. Ideally, they would only need to understand the public interface. Finally, if the superclass expects specific actions from the subclass, it may not perform well (or at all) if those actions aren't performed as expected.

A better approach to obtaining the desired functionality would be to use the [http://en.wikipedia.org/wiki/Template_method_pattern Template Method] pattern. Here the superclass would include a public method and define a separate method (often called a hook method) for the subclass to override. The superclass method would then call the hook method. The hook method can either be an abstract method in the superclass and fully implemented in the subclass, or have some basic functionality in the superclass and augmented in the superclass. Either way the subclass does not have to worry about calling the superclass.

====Example====

Let's say we have a class registration framework with an EventHandler superclass. The EventHandler is used to process all "transactions" - administrators adding classes, students registering for classes, students dropping classes, etc. It has to do some basic setup and housekeeping functions (checking availability, permissions, etc.) before the registration event can be processed. Our original code for a student registering for a class might be something like the following.

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
}

public class StudentClassRegistrationHandler extends EventHandler...
public void handle(RegistrationEvent e) {
super.handle(e);
RegisterStudent(e);
}

The method StudentClassRegistrationHandler must call super.handle() before it can begin its task of registering the student. If we refactor this code using the Template Method pattern, we could get the following code:

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
doAction(e);
}
protected void doAction(RegistrationEvent e) {
}

public class StudentClassRegistrationHandler extends EventHandler ...
protected void doAction(RegistrationEvent e) {
RegisterStudent(e);
}

The subclass is now only responsible for its own functionality. This arrangement also allows the superclass to call some follow-up or clean-up methods after the subclass method if necessary.

===BaseBean===

====Description====
Similar to the Call Super antipattern is the BaseBean antipattern. It is found in object-oriented programming when a concrete domain class is formed using inheritance from a utility class. This relationship is used simply to inherit utility methods from the utility class. This is sometimes referred to as inheritance for implementation.

Inheritance for the sake of gaining the functionality in the parent class is not good style. This obviously is not an "is-a" a relationship and may violate the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle]. By inheriting from the utility class, the domain class becomes dependent on the internals of the utility class. This can make the system difficult to maintain. Additionally, the domain class now has all the functionality of the utility class - some of which it might not need. This blurs the concept of the domain class and may cause it to have more than a single responsibility.

In good object-oriented programming, objects should be representative of the real-world entities they exemplify and should relate to each other as such. In this scenario a "has-a" relationship would be more appropriate. The inherited functionality can be obtained using delegation instead of inheritance. By using the [http://en.wikipedia.org/wiki/Composition_over_inheritance composition over inheritance] principle, we can avoid the BaseBean antipattern.

====Example====

Let's say we want to create a class that emulates a toll booth. The cars at the toll booth form a queue, so our toll booth will need the functionality (queue, dequeue, isEmpty, etc.) of a queue. We could implement our toll booth by inheriting this functionality from a Queue class as such:

public class TollBooth extends Queue{
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Obviously, a tollbooth is not a queue, but more appropriately, has a queue. Hence, our toll booth class should be created to contain a queue to model the line of cars.

public class TollBooth
private Queue<Vehicles>
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Our TollBooth class now has the functionality it needs without the inherent liabilities of extending the Queue class.

===The Blob===
====Description====
'''The Blob''', also called a '''God Class''', is a development antipattern that results when one single class has too many attributes, operations, or both.<ref name = sourcemaking_tb/> '''The Blob''' is usually an indicator of poor object-oriented design, or a poorly-migrated legacy program.<ref name = ap/> It can often resemble a procedural 'main' program, and may even encapsulate most or all of the functionality of an application. '''The Blob''' class violates the ''One Responsibility Rule'', which makes it unlikely to be reusable. Because it has many responsibilities, it would be difficult to reuse in a future project. '''The Blob''' class may be expensive to load into memory, and wasteful if only part of the functionality is used. It also will likely be difficult to effectively test.<ref name = ap/> '''The Blob''' is typically caused by a lack of an object-oriented architecture.<ref name = ap/> It can also be the result of an up-front object-oriented design that did not take into account a requirement, and developers choosing not to rearrange the class hierarchy after the initial design. It can also be a ''Specified Disaster''; the result of requirements that specify a procedural solution.<ref name = ap/>

The solution to '''The Blob''' is to refactor the code, with the goal of moving behavior away from the offending class.<ref name = sourcemaking_tb /> If '''The Blob''' encapsulates data in some other objects, then code manipulating that data should be moved to the other classes, in an effort to make the other classes more complex and '''The Blob''' less complex. If possible, the developers should try to split '''The Blob''' into multiple classes with class minimal coupling.

====Example====
An example of class approaching '''The Blob''' that may be familiar to many students this semester is the [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza] Project's assignment model.<ref name="expertiza" /> The assignment model in Expertiza does not encapsulate the majority of functionality in the entire application, but it is out of proportion with most of the other classes, and it does include functionality that should be in some other classes.<ref name="fall2011_oss" /> One of the Open-Source Software projects for this semester is to correct some of these problems. The project assignment contains the following notes:<ref name="fall2011_oss" />

<blockquote>[The assignment model] contains functionality for adding and removing participants for this assignment, which should really be in a participant class, for assigning reviewers, which should probably be in a reviewer class, and for computing the maximum score possible on a questionnaire. Functions like compute_scores, and candidate_topics_to_review, among others, should be moved to other classes.</blockquote>

These notes describe some of the excessive functionality of assignment.rb. It also suggests some other classes that would be more appropriate locations for some functionalities. If these modifications are made, then the assignment model will be of a more manageable size, and will not be in danger of becoming '''The Blob'''.

===Golden Hammer===
====Description====
The '''Golden Hammer''' design AntiPattern, also known as the '''Law of the instrument''', is an over-reliance on a familiar tool.<ref name="wiki_gh" /> It is one of the most common antipatterns seen in the industry.<ref name="sourcemaking_gh" />

Many software engineering projects solve problems or use techniques that programmers are strongly familiar with. Programmers often reuse strategies, algorithms, or entire sections of code that they or another programmer has applied to a different project in the past. Reuse in this manner can save development time and cost, but only when reused code is appropriate for the new application.

The '''Golden Hammer''' design anti-pattern results from reusing a familiar solution that is a poor match for a new problem.<ref name="sourcemaking_gh" /> This can occur if the developers are simply comfortable with or used to an existing approach, or even the result of narrow-mindedness or hubris. It can also be the direct result of reliance on proprietary technologies or products, or a deliberate effort to try to build a previous projects' success into a new program. A '''Golden Hammer''' will typically manifest itself with poor performance or scalability.<ref name="sourcemaking_gh" />
==Conclusions==
==Resources==

For additional information regarding antipatterns, check out the following resources.

===Books===

* [http://www.amazon.com/exec/obidos/ISBN=0471197130/portlandpatternrA/ ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''.] Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, (ed) (1998).

* [http://sourcemaking.com/antipatterns-book ''AntiPatterns: The Survival Guide'']

* [http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612 ''Design Patterns: Elements of Reusable Object-Oriented Software''] by Erich Gamma, Richard Helm], Ralph Johnson, and John Vlissides(the Gang Of Four)

===Websites===

* [http://c2.com/cgi/wiki?AntiPatternsCatalog AntiPatterns Catalog]

* [http://www.antipatterns.com/ AntiPatterns.com] Web site for the ''AntiPatterns'' book

* [http://en.wikipedia.org/wiki/Category:Anti-patterns Wikipedia Anitpatterns Category]

==References==
<references>
<ref name = koenig> Koenig, Andrew (March/April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming 8 (1): 46–48.; was later re-printed in the: Rising, Linda (1998). [http://books.google.com/?id=HBAuixGMYWEC&pg=PT1&dq=0-521-64818-1 The patterns handbook: techniques, strategies, and applications]. Cambridge, U.K.: Cambridge University Press. p. 387. </ref>
<ref name = gof> [http://en.wikipedia.org/wiki/Design_Patterns_%28book%29 Design Patterns] by Gang of Four</ref>
<ref name = ap> Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, Theresa Hudson (ed) (1998). [http://www.antipatterns.com/AntiPatterns/Welcome.html ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''. ]</ref>
<ref name = sourcemaking_tb> [http://sourcemaking.com/antipatterns/the-blob http://sourcemaking.com/antipatterns/the-blob]</ref>
<ref name = wiki_gh> [http://en.wikipedia.org/wiki/Golden_hammer http://en.wikipedia.org/wiki/Golden_hammer] </ref>
<ref name = sourcemaking_gh> [http://sourcemaking.com/antipatterns/golden-hammer http://sourcemaking.com/antipatterns/golden-hammer] </ref>
<ref name = expertiza> [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza - Reusable learning objects through peer review] </ref>
<ref name = fall2011_oss> [https://docs.google.com/a/ncsu.edu/document/d/1zZ-a_tkLGrbYJbG-2QBCRqe_Y9XLR4AZMH0rc6KvrYU/edit?hl=en_US CSC/ECE517 Fall 2011 OSS Projects in Expertiza] </ref>
</ref>
</references>

CSC/ECE 517 Fall 2011/ch7 7d rt

2011-11-29T23:06:43Z

Rbjeffer:

AntiPatterns in Software Development
__TOC__

==Introduction==
The term ''antipattern'' was coined by Andrew Koenig<ref name = koenig/>, in 1995. His inspiration was a story told about Thomas Edison's many failed attempts to find a suitable material for the filament of a light bulb. When asked if he was discouraged, Edison replied that indeed he was not; he now knew hundreds of items that wouldn't work.

Koenig believed that the same philosophy should be applied to software development. As he studied the book ''Design Patterns'' presented by the GoF<ref name = gof/>, he felt that it was just as important to identify potential pitfalls as well as positive practices. He named these non-solutions ''antipatterns''. He defined an ''antipattern'' as "just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn't one." <ref name = koenig/>

In 1998, a different group of four expanded on this idea publishing '''''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis'''''<ref name = ap/>. The book identified antipatterns from three different viewpoints: the software developer, the software architect and the software manager. The authors used two criteria to distinguish antipatterns:
* It was a frequent occurrence, that initially seemed to be beneficial, but ultimately was not and
* There is a alternate, preferred solution that is proven and repeatable.

Through the years the concept of antipatterns has been further extended to apply to additional areas of software development as well as areas outside the realm of programming. This article will address software development antipatterns.

Just like patterns, antipatterns have certain elements. They include:
# Name so that they can be identified.
# A description of why the bad solution might be attractive.
# An explanation of how that solution is bad long-term.
# Suggestions for other patterns that provide better solutions.

There are several catalogs of antipatterns available as well as a number of books that address the topic. Below we will explore a few of the more common antipatterns.

==AntiPatterns==
===Call Super===

====Description====
We are all familiar with the concept of inheritance in object-oriented programming where a subclass takes on the properties and actions of a superclass. The subclass can then override the methods of the superclass either replacing or augmenting the functionality provided in the superclass. The '''call super''' antipattern requires subclasses to override methods of the super class and then call back the overridden method at some point. This requirement may stem from the fact that the superclass does some set up operations that cannot be done in the subclass or if the subclass is expanding the superclass task rather than replacing it.

Calling a superclass method from a subclass is not in general a bad practice, but '''requiring''' it to do so is. Imposing such a constraint can lead to several problems. Future developers may forget to call the superclass causing untold bugs and system errors. Additionally, it requires anyone using the interface to have an understanding of the inner workings of the superclass. Ideally, they would only need to understand the public interface. Finally, if the superclass expects specific actions from the subclass, it may not perform well (or at all) if those actions aren't performed as expected.

A better approach to obtaining the desired functionality would be to use the [http://en.wikipedia.org/wiki/Template_method_pattern Template Method] pattern. Here the superclass would include a public method and define a separate method (often called a hook method) for the subclass to override. The superclass method would then call the hook method. The hook method can either be an abstract method in the superclass and fully implemented in the subclass, or have some basic functionality in the superclass and augmented in the superclass. Either way the subclass does not have to worry about calling the superclass.

====Example====

Let's say we have a class registration framework with an EventHandler superclass. The EventHandler is used to process all "transactions" - administrators adding classes, students registering for classes, students dropping classes, etc. It has to do some basic setup and housekeeping functions (checking availability, permissions, etc.) before the registration event can be processed. Our original code for a student registering for a class might be something like the following.

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
}

public class StudentClassRegistrationHandler extends EventHandler...
public void handle(RegistrationEvent e) {
super.handle(e);
RegisterStudent(e);
}

The method StudentClassRegistrationHandler must call super.handle() before it can begin its task of registering the student. If we refactor this code using the Template Method pattern, we could get the following code:

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
doAction(e);
}
protected void doAction(RegistrationEvent e) {
}

public class StudentClassRegistrationHandler extends EventHandler ...
protected void doAction(RegistrationEvent e) {
RegisterStudent(e);
}

The subclass is now only responsible for its own functionality. This arrangement also allows the superclass to call some follow-up or clean-up methods after the subclass method if necessary.

===BaseBean===

====Description====
Similar to the Call Super antipattern is the BaseBean antipattern. It is found in object-oriented programming when a concrete domain class is formed using inheritance from a utility class. This relationship is used simply to inherit utility methods from the utility class. This is sometimes referred to as inheritance for implementation.

Inheritance for the sake of gaining the functionality in the parent class is not good style. This obviously is not an "is-a" a relationship and may violate the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle]. By inheriting from the utility class, the domain class becomes dependent on the internals of the utility class. This can make the system difficult to maintain. Additionally, the domain class now has all the functionality of the utility class - some of which it might not need. This blurs the concept of the domain class and may cause it to have more than a single responsibility.

In good object-oriented programming, objects should be representative of the real-world entities they exemplify and should relate to each other as such. In this scenario a "has-a" relationship would be more appropriate. The inherited functionality can be obtained using delegation instead of inheritance. By using the [http://en.wikipedia.org/wiki/Composition_over_inheritance composition over inheritance] principle, we can avoid the BaseBean antipattern.

====Example====

Let's say we want to create a class that emulates a toll booth. The cars at the toll booth form a queue, so our toll booth will need the functionality (queue, dequeue, isEmpty, etc.) of a queue. We could implement our toll booth by inheriting this functionality from a Queue class as such:

public class TollBooth extends Queue{
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Obviously, a tollbooth is not a queue, but more appropriately, has a queue. Hence, our toll booth class should be created to contain a queue to model the line of cars.

public class TollBooth
private Queue<Vehicles>
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Our TollBooth class now has the functionality it needs without the inherent liabilities of extending the Queue class.

===The Blob===
====Description====
'''The Blob''', also called a '''God Class''', is a development antipattern that results when one single class has too many attributes, operations, or both.<ref name = sourcemaking_tb/> '''The Blob''' is usually an indicator of poor object-oriented design, or a poorly-migrated legacy program.<ref name = ap/> It can often resemble a procedural 'main' program, and may even encapsulate most or all of the functionality of an application. '''The Blob''' class violates the ''One Responsibility Rule'', which makes it unlikely to be reusable. Because it has many responsibilities, it would be difficult to reuse in a future project. '''The Blob''' class may be expensive to load into memory, and wasteful if only part of the functionality is used. It also will likely be difficult to effectively test.<ref name = ap/> '''The Blob''' is typically caused by a lack of an object-oriented architecture.<ref name = ap/> It can also be the result of an up-front object-oriented design that did not take into account a requirement, and developers choosing not to rearrange the class hierarchy after the initial design. It can also be a ''Specified Disaster''; the result of requirements that specify a procedural solution.<ref name = ap/>

The solution to '''The Blob''' is to refactor the code, with the goal of moving behavior away from the offending class.<ref name = sourcemaking_tb /> If '''The Blob''' encapsulates data in some other objects, then code manipulating that data should be moved to the other classes, in an effort to make the other classes more complex and '''The Blob''' less complex. If possible, the developers should try to split '''The Blob''' into multiple classes with class minimal coupling.

====Example====
An example of class approaching '''The Blob''' that may be familiar to many students this semester is the [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza] Project's assignment model.<ref name="expertiza" /> The assignment model in Expertiza does not encapsulate the majority of functionality in the entire application, but it is out of proportion with most of the other classes, and it does include functionality that should be in some other classes.<ref name="fall2011_oss" /> One of the Open-Source Software projects for this semester is to correct some of these problems. The project assignment contains the following notes:<ref name="fall2011_oss" />

<blockquote>[The assignment model] contains functionality for adding and removing participants for this assignment, which should really be in a participant class, for assigning reviewers, which should probably be in a reviewer class, and for computing the maximum score possible on a questionnaire. Functions like compute_scores, and candidate_topics_to_review, among others, should be moved to other classes.</blockquote>

These notes describe some of the excessive functionality of assignment.rb. It also suggests some other classes that would be more appropriate locations for some functionalities. If these modifications are made, then the assignment model will be of a more manageable size, and will not be in danger of becoming '''The Blob'''.

===Golden Hammer===
====Description====
The '''Golden Hammer''' design AntiPattern, also known as the '''Law of the instrument''', is an over-reliance on a familiar tool.<ref name="wiki_gh" /> It is one of the most common antipatterns seen in the industry.<ref name="sourcemaking_gh" />

Many software engineering projects solve problems or use techniques that programmers are strongly familiar with. Programmers often reuse strategies, algorithms, or entire sections of code that they or another programmer has applied to a different project in the past. Reuse in this manner can save development time and cost, but only when reused code is appropriate for the new application.

The '''Golden Hammer''' design anti-pattern results from reusing a familiar solution that is a poor match for a new problem.<ref name="sourcemaking_gh" /> This can occur if the developers are simply comfortable with or used to an existing approach, or even the result of narrow-mindedness or hubris. It can also be the direct result of reliance on proprietary technologies or products, or a deliberate effort to try to build a previous projects' success into a new program. A '''Golden Hammer''' will typically manifest itself with poor performance or scalability.<ref name="sourcemaking_gh" />
==Conclusions==
==Resources==

For additional information regarding antipatterns, check out the following resources.

===Books===

* [http://www.amazon.com/exec/obidos/ISBN=0471197130/portlandpatternrA/ ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''.] Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, (ed) (1998).

* [http://sourcemaking.com/antipatterns-book ''AntiPatterns: The Survival Guide'']

* [http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612 ''Design Patterns: Elements of Reusable Object-Oriented Software''] by Erich Gamma, Richard Helm], Ralph Johnson, and John Vlissides(the Gang Of Four)

===Websites===

* [http://c2.com/cgi/wiki?AntiPatternsCatalog AntiPatterns Catalog]

* [http://www.antipatterns.com/ AntiPatterns.com] Web site for the ''AntiPatterns'' book

* [http://en.wikipedia.org/wiki/Category:Anti-patterns Wikipedia Anitpatterns Category]

==References==
<references>
<ref name = koenig> Koenig, Andrew (March/April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming 8 (1): 46–48.; was later re-printed in the: Rising, Linda (1998). [http://books.google.com/?id=HBAuixGMYWEC&pg=PT1&dq=0-521-64818-1 The patterns handbook: techniques, strategies, and applications]. Cambridge, U.K.: Cambridge University Press. p. 387. </ref>
<ref name = gof> [http://en.wikipedia.org/wiki/Design_Patterns_%28book%29 Design Patterns] by Gang of Four</ref>
<ref name = ap> Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, Theresa Hudson (ed) (1998). [http://www.antipatterns.com/AntiPatterns/Welcome.html ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''. ]</ref>
<ref name = sourcemaking_tb> [http://sourcemaking.com/antipatterns/the-blob]</ref>
<ref name = wiki_gh> http://en.wikipedia.org/wiki/Golden_hammer [http://en.wikipedia.org/wiki/Golden_hammer] ''Golden Hammer''</ref>
<ref name = sourcemaking_gh> http://sourcemaking.com/antipatterns/golden-hammer [http://sourcemaking.com/antipatterns/golden-hammer] </ref>
<ref name = expertiza> Expertiza - Reusable learning objects through peer review [http://wikis.lib.ncsu.edu/index.php/Expertiza] </ref>
<ref name = fall2011_oss> CSC/ECE517 Fall 2011 OSS Projects in Expertiza [https://docs.google.com/a/ncsu.edu/document/d/1zZ-a_tkLGrbYJbG-2QBCRqe_Y9XLR4AZMH0rc6KvrYU/edit?hl=en_US] </ref>
</ref>
</references>

CSC/ECE 517 Fall 2011/ch7 7d rt

2011-11-29T21:43:47Z

Rbjeffer:

AntiPatterns in Software Development
__TOC__

==Introduction==
The term ''antipattern'' was coined by Andrew Koenig<ref name = koenig/>, in 1995. His inspiration was a story told about Thomas Edison's many failed attempts to find a suitable material for the filament of a light bulb. When asked if he was discouraged, Edison replied that indeed he was not; he now knew hundreds of items that wouldn't work.

Koenig believed that the same philosophy should be applied to software development. As he studied the book ''Design Patterns'' presented by the GoF<ref name = gof/>, he felt that it was just as important to identify potential pitfalls as well as positive practices. He named these non-solutions ''antipatterns''. He defined an ''antipattern'' as "just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn't one." <ref name = koenig/>

In 1998, a different group of four expanded on this idea publishing '''''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis'''''<ref name = ap/>. The book identified antipatterns from three different viewpoints: the software developer, the software architect and the software manager. The authors used two criteria to distinguish antipatterns:
* It was a frequent occurrence, that initially seemed to be beneficial, but ultimately was not and
* There is a alternate, preferred solution that is proven and repeatable.

Through the years the concept of antipatterns has been further extended to apply to additional areas of software development as well as areas outside the realm of programming. This article will address software development antipatterns.

Just like patterns, antipatterns have certain elements. They include:
# Name so that they can be identified.
# A description of why the bad solution might be attractive.
# An explanation of how that solution is bad long-term.
# Suggestions for other patterns that provide better solutions.

There are several catalogs of antipatterns available as well as a number of books that address the topic. Below we will explore a few of the more common antipatterns.

==AntiPatterns==
===Call Super===

====Description====
We are all familiar with the concept of inheritance in object-oriented programming where a subclass takes on the properties and actions of a superclass. The subclass can then override the methods of the superclass either replacing or augmenting the functionality provided in the superclass. The '''call super''' antipattern requires subclasses to override methods of the super class and then call back the overridden method at some point. This requirement may stem from the fact that the superclass does some set up operations that cannot be done in the subclass or if the subclass is expanding the superclass task rather than replacing it.

Calling a superclass method from a subclass is not in general a bad practice, but '''requiring''' it to do so is. Imposing such a constraint can lead to several problems. Future developers may forget to call the superclass causing untold bugs and system errors. Additionally, it requires anyone using the interface to have an understanding of the inner workings of the superclass. Ideally, they would only need to understand the public interface. Finally, if the superclass expects specific actions from the subclass, it may not perform well (or at all) if those actions aren't performed as expected.

A better approach to obtaining the desired functionality would be to use the [http://en.wikipedia.org/wiki/Template_method_pattern Template Method] pattern. Here the superclass would include a public method and define a separate method (often called a hook method) for the subclass to override. The superclass method would then call the hook method. The hook method can either be an abstract method in the superclass and fully implemented in the subclass, or have some basic functionality in the superclass and augmented in the superclass. Either way the subclass does not have to worry about calling the superclass.

====Example====

Let's say we have a class registration framework with an EventHandler superclass. The EventHandler is used to process all "transactions" - administrators adding classes, students registering for classes, students dropping classes, etc. It has to do some basic setup and housekeeping functions (checking availability, permissions, etc.) before the registration event can be processed. Our original code for a student registering for a class might be something like the following.

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
}

public class StudentClassRegistrationHandler extends EventHandler...
public void handle(RegistrationEvent e) {
super.handle(e);
RegisterStudent(e);
}

The method StudentClassRegistrationHandler must call super.handle() before it can begin its task of registering the student. If we refactor this code using the Template Method pattern, we could get the following code:

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
doAction(e);
}
protected void doAction(RegistrationEvent e) {
}

public class StudentClassRegistrationHandler extends EventHandler ...
protected void doAction(RegistrationEvent e) {
RegisterStudent(e);
}

The subclass is now only responsible for its own functionality. This arrangement also allows the superclass to call some follow-up or clean-up methods after the subclass method if necessary.

===BaseBean===

====Description====
Similar to the Call Super antipattern is the BaseBean antipattern. It is found in object-oriented programming when a concrete domain class is formed using inheritance from a utility class. This relationship is used simply to inherit utility methods from the utility class. This is sometimes referred to as inheritance for implementation.

Inheritance for the sake of gaining the functionality in the parent class is not good style. This obviously is not an "is-a" a relationship and may violate the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle]. By inheriting from the utility class, the domain class becomes dependent on the internals of the utility class. This can make the system difficult to maintain. Additionally, the domain class now has all the functionality of the utility class - some of which it might not need. This blurs the concept of the domain class and may cause it to have more than a single responsibility.

In good object-oriented programming, objects should be representative of the real-world entities they exemplify and should relate to each other as such. In this scenario a "has-a" relationship would be more appropriate. The inherited functionality can be obtained using delegation instead of inheritance. By using the [http://en.wikipedia.org/wiki/Composition_over_inheritance composition over inheritance] principle, we can avoid the BaseBean antipattern.

====Example====

Let's say we want to create a class that emulates a toll booth. The cars at the toll booth form a queue, so our toll booth will need the functionality (queue, dequeue, isEmpty, etc.) of a queue. We could implement our toll booth by inheriting this functionality from a Queue class as such:

public class TollBooth extends Queue{
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Obviously, a tollbooth is not a queue, but more appropriately, has a queue. Hence, our toll booth class should be created to contain a queue to model the line of cars.

public class TollBooth
private Queue<Vehicles>
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Our TollBooth class now has the functionality it needs without the inherent liabilities of extending the Queue class.

===The Blob===
====Description====
'''The Blob''', also called a '''God Class''', is a development antipattern that results when one single class has too many attributes, operations, or both.<ref name = sourcemaking_tb/> '''The Blob''' is usually an indicator of poor object-oriented design, or a poorly-migrated legacy program.<ref name = ap/> It can often resemble a procedural 'main' program, and may even encapsulate most or all of the functionality of an application. '''The Blob''' class violates the ''One Responsibility Rule'', which makes it unlikely to be reusable. '''The Blob''' class may be expensive to load into memory, and wasteful if only part of the functionality is used. It also will likely be difficult to effectively test.<ref name = ap/> '''The Blob''' is typically caused by a lack of an object-oriented architecture.<ref name = ap/> It can also be the result of an up-front object-oriented design that did not take into account a requirement, and developers choosing not to rearrange the class hierarchy after the initial design. It can also be a ''Specified Disaster''; the result of requirements that specify a procedural solution.<ref name = ap/>

The solution to '''The Blob''' is to refactor the code, with the goal of moving behavior away from the offending class.<ref name = sourcemaking_tb /> If '''The Blob''' encapsulates data in some other objects, then code manipulating that data should be moved to the other classes, in an effort to make the other classes more complex and '''The Blob''' less complex. If possible, the developers should try to split '''The Blob''' into multiple classes with class minimal coupling.

====Example====
An example of class approaching '''The Blob''' status that may be familiar to many students this semester is the [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza] Project's assignment model.<ref name="expertiza" /> The assignment model in Expertiza does not encapsulate the majority of functionality in the entire application, but it is out of proportion with most of the other classes, and it does include functionality that should be in some other classes.<ref name="fall2011_oss" /> One of the Open-Source Software projects for this semester is to correct some of these problems. The project assignment contains the following notes:<ref name="fall2011_oss" />

<blockquote>It contains functionality for adding and removing participants for this assignment, which should really be in a participant class, for assigning reviewers, which should probably be in a reviewer class, and for computing the maximum score possible on a questionnaire. Functions like compute_scores, and candidate_topics_to_review, among others, should be moved to other classes.</blockquote>

These notes describe some of the excessive functionality of assignment.rb. It also suggests some other classes that would be more appropriate locations for some functionalities. If these modifications are made, then the assignment model will not be in danger of becoming '''The Blob'''.

===Golden Hammer===
====Description====
The '''Golden Hammer''' design AntiPattern, also known as the '''Law of the instrument''', is an over-reliance on a familiar tool.<ref name="wiki_gh" /> It is one of the most common antipatterns seen in the industry.<ref name="sourcemaking_gh" />

Many software engineering projects solve problems or use techniques that programmers are strongly familiar with. Programmers often reuse strategies, algorithms, or entire sections of code that they or another programmer has applied to a different project in the past. Reuse in this manner can save development time and cost, but only when reused code is appropriate for the new application.

The '''Golden Hammer''' design anti-pattern results from reusing a familiar solution that is a poor match for a new problem.<ref name="sourcemaking_gh" /> This can occur if the developers are simply comfortable with or used to an existing approach, or even the result of narrow-mindedness or hubris. It can also be the direct result of reliance on proprietary technologies or products, or a deliberate effort to try to build a previous projects' success into a new program. A '''Golden Hammer''' will typically manifest itself with poor performance or scalability.<ref name="sourcemaking_gh" />
==Conclusions==
==Resources==
==References==
<references>
<ref name = koenig> Koenig, Andrew (March/April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming 8 (1): 46–48.; was later re-printed in the: Rising, Linda (1998). [http://books.google.com/?id=HBAuixGMYWEC&pg=PT1&dq=0-521-64818-1 The patterns handbook: techniques, strategies, and applications]. Cambridge, U.K.: Cambridge University Press. p. 387. </ref>
<ref name = gof> [http://en.wikipedia.org/wiki/Design_Patterns_%28book%29 Design Patterns] by Gang of Four</ref>
<ref name = ap> Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, Theresa Hudson (ed) (1998). [http://www.antipatterns.com/AntiPatterns/Welcome.html ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''. ]</ref>
<ref name = sourcemaking_tb> [http://sourcemaking.com/antipatterns/the-blob]</ref>
<ref name = wiki_gh> http://en.wikipedia.org/wiki/Golden_hammer [http://en.wikipedia.org/wiki/Golden_hammer] ''Golden Hammer''</ref>
<ref name = sourcemaking_gh> http://sourcemaking.com/antipatterns/golden-hammer [http://sourcemaking.com/antipatterns/golden-hammer] </ref>
<ref name = expertiza> Expertiza - Reusable learning objects through peer review [http://wikis.lib.ncsu.edu/index.php/Expertiza] </ref>
<ref name = fall2011_oss> CSC/ECE517 Fall 2011 OSS Projects in Expertiza [https://docs.google.com/a/ncsu.edu/document/d/1zZ-a_tkLGrbYJbG-2QBCRqe_Y9XLR4AZMH0rc6KvrYU/edit?hl=en_US] </ref>
</ref>
</references>

CSC/ECE 517 Fall 2011/ch7 7d rt

2011-11-29T18:20:44Z

Rbjeffer:

AntiPatterns in Software Development
__TOC__

==Introduction==
The term ''antipattern'' was coined by Andrew Koenig<ref name = koenig/>, in 1995. His inspiration was a story told about Thomas Edison's many failed attempts to find a suitable material for the filament of a light bulb. When asked if he was discouraged, Edison replied that indeed he was not; he now knew hundreds of items that wouldn't work.

Koenig believed that the same philosophy should be applied to software development. As he studied the book ''Design Patterns'' presented by the GoF<ref name = gof/>, he felt that it was just as important to identify potential pitfalls as well as positive practices. He named these non-solutions ''antipatterns''. He defined an ''antipattern'' as "just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn't one." <ref name = koenig/>

In 1998, a different group of four expanded on this idea publishing '''''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis'''''<ref name = ap/>. The book identified antipatterns from three different viewpoints: the software developer, the software architect and the software manager. The authors used two criteria to distinguish antipatterns:
* It was a frequent occurrence, that initially seemed to be beneficial, but ultimately was not and
* There is a alternate, preferred solution that is proven and repeatable.

Through the years the concept of antipatterns has been further extended to apply to additional areas of software development as well as areas outside the realm of programming. This article will address software development antipatterns.

Just like patterns, antipatterns have certain elements. They include:
# Name so that they can be identified.
# A description of why the bad solution might be attractive.
# An explanation of how that solution is bad long-term.
# Suggestions for other patterns that provide better solutions.

There are several catalogs of antipatterns available as well as a number of books that address the topic. Below we will explore a few of the more common antipatterns.

==AntiPatterns==
===Call Super===

====Description====
We are all familiar with the concept of inheritance in object-oriented programming where a subclass takes on the properties and actions of a superclass. The subclass can then override the methods of the superclass either replacing or augmenting the functionality provided in the superclass. The '''call super''' antipattern requires subclasses to override methods of the super class and then call back the overridden method at some point. This requirement may stem from the fact that the superclass does some set up operations that cannot be done in the subclass or if the subclass is expanding the superclass task rather than replacing it.

Calling a superclass method from a subclass is not in general a bad practice, but '''requiring''' it to do so is. Imposing such a constraint can lead to several problems. Future developers may forget to call the superclass causing untold bugs and system errors. Additionally, it requires anyone using the interface to have an understanding of the inner workings of the superclass. Ideally, they would only need to understand the public interface. Finally, if the superclass expects specific actions from the subclass, it may not perform well (or at all) if those actions aren't performed as expected.

A better approach to obtaining the desired functionality would be to use the [http://en.wikipedia.org/wiki/Template_method_pattern Template Method] pattern. Here the superclass would include a public method and define a separate method (often called a hook method) for the subclass to override. The superclass method would then call the hook method. The hook method can either be an abstract method in the superclass and fully implemented in the subclass, or have some basic functionality in the superclass and augmented in the superclass. Either way the subclass does not have to worry about calling the superclass.

====Example====

Let's say we have a class registration framework with an EventHandler superclass. The EventHandler is used to process all "transactions" - administrators adding classes, students registering for classes, students dropping classes, etc. It has to do some basic setup and housekeeping functions (checking availability, permissions, etc.) before the registration event can be processed. Our original code for a student registering for a class might be something like the following.

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
}

public class StudentClassRegistrationHandler extends EventHandler...
public void handle(RegistrationEvent e) {
super.handle(e);
RegisterStudent(e);
}

The method StudentClassRegistrationHandler must call super.handle() before it can begin its task of registering the student. If we refactor this code using the Template Method pattern, we could get the following code:

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
doAction(e);
}
protected void doAction(RegistrationEvent e) {
}

public class StudentClassRegistrationHandler extends EventHandler ...
protected void doAction(RegistrationEvent e) {
RegisterStudent(e);
}

The subclass is now only responsible for its own functionality. This arrangement also allows the superclass to call some follow-up or clean-up methods after the subclass method if necessary.

===BaseBean===

====Description====
Similar to the Call Super antipattern is the BaseBean antipattern. It is found in object-oriented programming when a concrete domain class is formed using inheritance from a utility class. This relationship is used simply to inherit utility methods from the utility class. This is sometimes referred to as inheritance for implementation.

Inheritance for the sake of gaining the functionality in the parent class is not good style. This obviously is not an "is-a" a relationship and may violate the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle]. By inheriting from the utility class, the domain class becomes dependent on the internals of the utility class. This can make the system difficult to maintain. Additionally, the domain class now has all the functionality of the utility class - some of which it might not need. This blurs the concept of the domain class and may cause it to have more than a single responsibility.

In good object-oriented programming, objects should be representative of the real-world entities they exemplify and should relate to each other as such. In this scenario a "has-a" relationship would be more appropriate. The inherited functionality can be obtained using delegation instead of inheritance. By using the [http://en.wikipedia.org/wiki/Composition_over_inheritance composition over inheritance] principle, we can avoid the BaseBean antipattern.

====Example====

Let's say we want to create a class that emulates a toll booth. The cars at the toll booth form a queue, so our toll booth will need the functionality (queue, dequeue, isEmpty, etc.) of a queue. We could implement our toll booth by inheriting this functionality from a Queue class as such:

public class TollBooth extends Queue{
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Obviously, a tollbooth is not a queue, but more appropriately, has a queue. Hence, our toll booth class should be created to contain a queue to model the line of cars.

public class TollBooth
private Queue<Vehicles>
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Our TollBooth class now has the functionality it needs without the inherent liabilities of extending the Queue class.

===The Blob===
====Description====
'''The Blob''', also called a '''God Class''', is a development antipattern that results when one single class has too many attributes, operations, or both.<ref name = sourcemaking_tb/> '''The Blob''' is usually an indicator of poor object-oriented design, or a poorly-migrated legacy program.<ref name = ap/> It can often resemble a procedural 'main' program, and may even encapsulate most or all of the functionality of an application. '''The Blob''' class violates the ''One Responsibility Rule'', which makes it unlikely to be reusable. '''The Blob''' class may be expensive to load into memory, and wasteful if only part of the functionality is used. It also will likely be difficult to effectively test.<ref name = ap/> '''The Blob''' is typically caused by a lack of an object-oriented architecture.<ref name = ap/> It can also be the result of an up-front object-oriented design that did not take into account a requirement, and developers choosing not to rearrange the class hierarchy after the initial design. It can also be a ''Specified Disaster''; the result of requirements that specify a procedural solution.<ref name = ap/>

The solution to '''The Blob''' is to refactor the code, with the goal of moving behavior away from the offending class.<ref name = sourcemaking_tb /> If '''The Blob''' encapsulates data in some other objects, then code manipulating that data should be moved to the other classes, in an effort to make the other classes more complex and '''The Blob''' less complex. If possible, the developers should try to split '''The Blob''' into multiple classes with class minimal coupling.

====Example====
An example of class approaching '''The Blob''' status that may be familiar to many students this semester is the [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza Project]'s assignment controller.<ref name="expertiza" /> The assignment controller in Expertiza does not encapsulate the majority of functionality in the entire application, but it is out of proportion with most of the other classes, and it does include functionality that should be in some other classes.<ref name="fall2011_oss" /> The project assignment contains the following notes:

<blockquote>It contains functionality for adding and removing participants for this assignment, which should really be in a participant class, for assigning reviewers, which should probably be in a reviewer class, and for computing the maximum score possible on a questionnaire. Functions like compute_scores, and candidate_topics_to_review, among others, should be moved to other classes.</blockquote><ref name="fall2011_oss" />

===Golden Hammer===
====Description====
The '''Golden Hammer''' design AntiPattern, also known as the '''Law of the instrument''', is an over-reliance on a familiar tool.<ref name="wiki_gh" /> It is one of the most common antipatterns seen in the industry.<ref name="sourcemaking_gh" />

Many software engineering projects solve problems or use techniques that programmers are strongly familiar with. Programmers often reuse strategies, algorithms, or entire sections of code that they or another programmer has applied to a different project in the past. Reuse in this manner can save development time and cost, but only when reused code is appropriate for the new application.

The '''Golden Hammer''' design anti-pattern results from reusing a familiar solution that is a poor match for a new problem.<ref name="sourcemaking_gh" /> This can occur if the developers are simply comfortable with or used to an existing approach, or even the result of narrow-mindedness or hubris. It can also be the direct result of reliance on proprietary technologies or products, or a deliberate effort to try to build a previous projects' success into a new program. A '''Golden Hammer''' will typically manifest itself with poor performance or scalability.<ref name="sourcemaking_gh" />
==Conclusions==
==Resources==
==References==
<references>
<ref name = koenig> Koenig, Andrew (March/April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming 8 (1): 46–48.; was later re-printed in the: Rising, Linda (1998). [http://books.google.com/?id=HBAuixGMYWEC&pg=PT1&dq=0-521-64818-1 The patterns handbook: techniques, strategies, and applications]. Cambridge, U.K.: Cambridge University Press. p. 387. </ref>
<ref name = gof> [http://en.wikipedia.org/wiki/Design_Patterns_%28book%29 Design Patterns] by Gang of Four</ref>
<ref name = ap> Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, Theresa Hudson (ed) (1998). [http://www.antipatterns.com/AntiPatterns/Welcome.html ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''. ]</ref>
<ref name = sourcemaking_tb> [http://sourcemaking.com/antipatterns/the-blob]</ref>
<ref name = wiki_gh> http://en.wikipedia.org/wiki/Golden_hammer [http://en.wikipedia.org/wiki/Golden_hammer] ''Golden Hammer''</ref>
<ref name = sourcemaking_gh> http://sourcemaking.com/antipatterns/golden-hammer [http://sourcemaking.com/antipatterns/golden-hammer] </ref>
<ref name = expertiza> Expertiza - Reusable learning objects through peer review [http://wikis.lib.ncsu.edu/index.php/Expertiza] </ref>
<ref name = fall2011_oss> CSC/ECE517 Fall 2011 OSS Projects in Expertiza [https://docs.google.com/a/ncsu.edu/document/d/1zZ-a_tkLGrbYJbG-2QBCRqe_Y9XLR4AZMH0rc6KvrYU/edit?hl=en_US] </ref>
</ref>
</references>

CSC/ECE 517 Fall 2011/ch7 7d rt

2011-11-29T18:19:21Z

Rbjeffer:

AntiPatterns in Software Development
__TOC__

==Introduction==
The term ''antipattern'' was coined by Andrew Koenig<ref name = koenig/>, in 1995. His inspiration was a story told about Thomas Edison's many failed attempts to find a suitable material for the filament of a light bulb. When asked if he was discouraged, Edison replied that indeed he was not; he now knew hundreds of items that wouldn't work.

Koenig believed that the same philosophy should be applied to software development. As he studied the book ''Design Patterns'' presented by the GoF<ref name = gof/>, he felt that it was just as important to identify potential pitfalls as well as positive practices. He named these non-solutions ''antipatterns''. He defined an ''antipattern'' as "just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn't one." <ref name = koenig/>

In 1998, a different group of four expanded on this idea publishing '''''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis'''''<ref name = ap/>. The book identified antipatterns from three different viewpoints: the software developer, the software architect and the software manager. The authors used two criteria to distinguish antipatterns:
* It was a frequent occurrence, that initially seemed to be beneficial, but ultimately was not and
* There is a alternate, preferred solution that is proven and repeatable.

Through the years the concept of antipatterns has been further extended to apply to additional areas of software development as well as areas outside the realm of programming. This article will address software development antipatterns.

Just like patterns, antipatterns have certain elements. They include:
# Name so that they can be identified.
# A description of why the bad solution might be attractive.
# An explanation of how that solution is bad long-term.
# Suggestions for other patterns that provide better solutions.

There are several catalogs of antipatterns available as well as a number of books that address the topic. Below we will explore a few of the more common antipatterns.

==AntiPatterns==
===Call Super===

====Description====
We are all familiar with the concept of inheritance in object-oriented programming where a subclass takes on the properties and actions of a superclass. The subclass can then override the methods of the superclass either replacing or augmenting the functionality provided in the superclass. The '''call super''' antipattern requires subclasses to override methods of the super class and then call back the overridden method at some point. This requirement may stem from the fact that the superclass does some set up operations that cannot be done in the subclass or if the subclass is expanding the superclass task rather than replacing it.

Calling a superclass method from a subclass is not in general a bad practice, but '''requiring''' it to do so is. Imposing such a constraint can lead to several problems. Future developers may forget to call the superclass causing untold bugs and system errors. Additionally, it requires anyone using the interface to have an understanding of the inner workings of the superclass. Ideally, they would only need to understand the public interface. Finally, if the superclass expects specific actions from the subclass, it may not perform well (or at all) if those actions aren't performed as expected.

A better approach to obtaining the desired functionality would be to use the [http://en.wikipedia.org/wiki/Template_method_pattern Template Method] pattern. Here the superclass would include a public method and define a separate method (often called a hook method) for the subclass to override. The superclass method would then call the hook method. The hook method can either be an abstract method in the superclass and fully implemented in the subclass, or have some basic functionality in the superclass and augmented in the superclass. Either way the subclass does not have to worry about calling the superclass.

====Example====

Let's say we have a class registration framework with an EventHandler superclass. The EventHandler is used to process all "transactions" - administrators adding classes, students registering for classes, students dropping classes, etc. It has to do some basic setup and housekeeping functions (checking availability, permissions, etc.) before the registration event can be processed. Our original code for a student registering for a class might be something like the following.

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
}

public class StudentClassRegistrationHandler extends EventHandler...
public void handle(RegistrationEvent e) {
super.handle(e);
RegisterStudent(e);
}

The method StudentClassRegistrationHandler must call super.handle() before it can begin its task of registering the student. If we refactor this code using the Template Method pattern, we could get the following code:

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
doAction(e);
}
protected void doAction(RegistrationEvent e) {
}

public class StudentClassRegistrationHandler extends EventHandler ...
protected void doAction(RegistrationEvent e) {
RegisterStudent(e);
}

The subclass is now only responsible for its own functionality. This arrangement also allows the superclass to call some follow-up or clean-up methods after the subclass method if necessary.

===BaseBean===

====Description====
Similar to the Call Super antipattern is the BaseBean antipattern. It is found in object-oriented programming when a concrete domain class is formed using inheritance from a utility class. This relationship is used simply to inherit utility methods from the utility class. This is sometimes referred to as inheritance for implementation.

Inheritance for the sake of gaining the functionality in the parent class is not good style. This obviously is not an "is-a" a relationship and may violate the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle]. By inheriting from the utility class, the domain class becomes dependent on the internals of the utility class. This can make the system difficult to maintain. Additionally, the domain class now has all the functionality of the utility class - some of which it might not need. This blurs the concept of the domain class and may cause it to have more than a single responsibility.

In good object-oriented programming, objects should be representative of the real-world entities they exemplify and should relate to each other as such. In this scenario a "has-a" relationship would be more appropriate. The inherited functionality can be obtained using delegation instead of inheritance. By using the [http://en.wikipedia.org/wiki/Composition_over_inheritance composition over inheritance] principle, we can avoid the BaseBean antipattern.

====Example====

Let's say we want to create a class that emulates a toll booth. The cars at the toll booth form a queue, so our toll booth will need the functionality (queue, dequeue, isEmpty, etc.) of a queue. We could implement our toll booth by inheriting this functionality from a Queue class as such:

public class TollBooth extends Queue{
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Obviously, a tollbooth is not a queue, but more appropriately, has a queue. Hence, our toll booth class should be created to contain a queue to model the line of cars.

public class TollBooth
private Queue<Vehicles>
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Our TollBooth class now has the functionality it needs without the inherent liabilities of extending the Queue class.

===The Blob===
====Description====
'''The Blob''', also called a '''God Class''', is a development antipattern that results when one single class has too many attributes, operations, or both.<ref name = sourcemaking_tb/> '''The Blob''' is usually an indicator of poor object-oriented design, or a poorly-migrated legacy program.<ref name = ap/> It can often resemble a procedural 'main' program, and may even encapsulate most or all of the functionality of an application. '''The Blob''' class violates the ''One Responsibility Rule'', which makes it unlikely to be reusable. '''The Blob''' class may be expensive to load into memory, and wasteful if only part of the functionality is used. It also will likely be difficult to effectively test.<ref name = ap/> '''The Blob''' is typically caused by a lack of an object-oriented architecture.<ref name = ap/> It can also be the result of an up-front object-oriented design that did not take into account a requirement, and developers choosing not to rearrange the class hierarchy after the initial design. It can also be a ''Specified Disaster''; the result of requirements that specify a procedural solution.<ref name = ap/>

The solution to '''The Blob''' is to refactor the code, with the goal of moving behavior away from the offending class.<ref name = sourcemaking_tb /> If '''The Blob''' encapsulates data in some other objects, then code manipulating that data should be moved to the other classes, in an effort to make the other classes more complex and '''The Blob''' less complex. If possible, the developers should try to split '''The Blob''' into multiple classes with class minimal coupling.

====Example====
An example of class approaching '''The Blob''' status that may be familiar to many students this semester is the [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza Project]'s assignment controller.<ref name="expertiza" /> The assignment controller in Expertiza does not encapsulate the majority of functionality in the entire application, but it is out of proportion with most of the other classes, and it does include functionality that should be in some other classes.<ref name="fall2011_oss" /> The project assignment contains the following notes:<ref name="fall2011_oss" />

<blockquote>It contains functionality for adding and removing participants for this assignment, which should really be in a participant class, for assigning reviewers, which should probably be in a reviewer class, and for computing the maximum score possible on a questionnaire. Functions like compute_scores, and candidate_topics_to_review, among others, should be moved to other classes.</blockquote>

===Golden Hammer===
====Description====
The '''Golden Hammer''' design AntiPattern, also known as the '''Law of the instrument''', is an over-reliance on a familiar tool.<ref name="wiki_gh" /> It is one of the most common antipatterns seen in the industry.<ref name="sourcemaking_gh" />

Many software engineering projects solve problems or use techniques that programmers are strongly familiar with. Programmers often reuse strategies, algorithms, or entire sections of code that they or another programmer has applied to a different project in the past. Reuse in this manner can save development time and cost, but only when reused code is appropriate for the new application.

The '''Golden Hammer''' design anti-pattern results from reusing a familiar solution that is a poor match for a new problem.<ref name="sourcemaking_gh" /> This can occur if the developers are simply comfortable with or used to an existing approach, or even the result of narrow-mindedness or hubris. It can also be the direct result of reliance on proprietary technologies or products, or a deliberate effort to try to build a previous projects' success into a new program. A '''Golden Hammer''' will typically manifest itself with poor performance or scalability.<ref name="sourcemaking_gh" />
==Conclusions==
==Resources==
==References==
<references>
<ref name = koenig> Koenig, Andrew (March/April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming 8 (1): 46–48.; was later re-printed in the: Rising, Linda (1998). [http://books.google.com/?id=HBAuixGMYWEC&pg=PT1&dq=0-521-64818-1 The patterns handbook: techniques, strategies, and applications]. Cambridge, U.K.: Cambridge University Press. p. 387. </ref>
<ref name = gof> [http://en.wikipedia.org/wiki/Design_Patterns_%28book%29 Design Patterns] by Gang of Four</ref>
<ref name = ap> Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, Theresa Hudson (ed) (1998). [http://www.antipatterns.com/AntiPatterns/Welcome.html ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''. ]</ref>
<ref name = sourcemaking_tb> http://sourcemaking.com/antipatterns/the-blob [http://sourcemaking.com/antipatterns/the-blob]</ref>
<ref name = wiki_gh> http://en.wikipedia.org/wiki/Golden_hammer [http://en.wikipedia.org/wiki/Golden_hammer]</ref>
<ref name = sourcemaking_gh> http://sourcemaking.com/antipatterns/golden-hammer [http://sourcemaking.com/antipatterns/golden-hammer] </ref>
<ref name = expertiza> Expertiza - Reusable learning objects through peer review [http://wikis.lib.ncsu.edu/index.php/Expertiza] </ref>
<ref name = fall2011_oss> CSC/ECE517 Fall 2011 OSS Projects in Expertiza [https://docs.google.com/a/ncsu.edu/document/d/1zZ-a_tkLGrbYJbG-2QBCRqe_Y9XLR4AZMH0rc6KvrYU/edit?hl=en_US] </ref>
</ref>
</references>

CSC/ECE 517 Fall 2011/ch7 7d rt

2011-11-29T18:18:18Z

Rbjeffer:

AntiPatterns in Software Development
__TOC__

==Introduction==
The term ''antipattern'' was coined by Andrew Koenig<ref name = koenig/>, in 1995. His inspiration was a story told about Thomas Edison's many failed attempts to find a suitable material for the filament of a light bulb. When asked if he was discouraged, Edison replied that indeed he was not; he now knew hundreds of items that wouldn't work.

Koenig believed that the same philosophy should be applied to software development. As he studied the book ''Design Patterns'' presented by the GoF<ref name = gof/>, he felt that it was just as important to identify potential pitfalls as well as positive practices. He named these non-solutions ''antipatterns''. He defined an ''antipattern'' as "just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn't one." <ref name = koenig/>

In 1998, a different group of four expanded on this idea publishing '''''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis'''''<ref name = ap/>. The book identified antipatterns from three different viewpoints: the software developer, the software architect and the software manager. The authors used two criteria to distinguish antipatterns:
* It was a frequent occurrence, that initially seemed to be beneficial, but ultimately was not and
* There is a alternate, preferred solution that is proven and repeatable.

Through the years the concept of antipatterns has been further extended to apply to additional areas of software development as well as areas outside the realm of programming. This article will address software development antipatterns.

Just like patterns, antipatterns have certain elements. They include:
# Name so that they can be identified.
# A description of why the bad solution might be attractive.
# An explanation of how that solution is bad long-term.
# Suggestions for other patterns that provide better solutions.

There are several catalogs of antipatterns available as well as a number of books that address the topic. Below we will explore a few of the more common antipatterns.

==AntiPatterns==
===Call Super===

====Description====
We are all familiar with the concept of inheritance in object-oriented programming where a subclass takes on the properties and actions of a superclass. The subclass can then override the methods of the superclass either replacing or augmenting the functionality provided in the superclass. The '''call super''' antipattern requires subclasses to override methods of the super class and then call back the overridden method at some point. This requirement may stem from the fact that the superclass does some set up operations that cannot be done in the subclass or if the subclass is expanding the superclass task rather than replacing it.

Calling a superclass method from a subclass is not in general a bad practice, but '''requiring''' it to do so is. Imposing such a constraint can lead to several problems. Future developers may forget to call the superclass causing untold bugs and system errors. Additionally, it requires anyone using the interface to have an understanding of the inner workings of the superclass. Ideally, they would only need to understand the public interface. Finally, if the superclass expects specific actions from the subclass, it may not perform well (or at all) if those actions aren't performed as expected.

A better approach to obtaining the desired functionality would be to use the [http://en.wikipedia.org/wiki/Template_method_pattern Template Method] pattern. Here the superclass would include a public method and define a separate method (often called a hook method) for the subclass to override. The superclass method would then call the hook method. The hook method can either be an abstract method in the superclass and fully implemented in the subclass, or have some basic functionality in the superclass and augmented in the superclass. Either way the subclass does not have to worry about calling the superclass.

====Example====

Let's say we have a class registration framework with an EventHandler superclass. The EventHandler is used to process all "transactions" - administrators adding classes, students registering for classes, students dropping classes, etc. It has to do some basic setup and housekeeping functions (checking availability, permissions, etc.) before the registration event can be processed. Our original code for a student registering for a class might be something like the following.

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
}

public class StudentClassRegistrationHandler extends EventHandler...
public void handle(RegistrationEvent e) {
super.handle(e);
RegisterStudent(e);
}

The method StudentClassRegistrationHandler must call super.handle() before it can begin its task of registering the student. If we refactor this code using the Template Method pattern, we could get the following code:

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
doAction(e);
}
protected void doAction(RegistrationEvent e) {
}

public class StudentClassRegistrationHandler extends EventHandler ...
protected void doAction(RegistrationEvent e) {
RegisterStudent(e);
}

The subclass is now only responsible for its own functionality. This arrangement also allows the superclass to call some follow-up or clean-up methods after the subclass method if necessary.

===BaseBean===

====Description====
Similar to the Call Super antipattern is the BaseBean antipattern. It is found in object-oriented programming when a concrete domain class is formed using inheritance from a utility class. This relationship is used simply to inherit utility methods from the utility class. This is sometimes referred to as inheritance for implementation.

Inheritance for the sake of gaining the functionality in the parent class is not good style. This obviously is not an "is-a" a relationship and may violate the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle]. By inheriting from the utility class, the domain class becomes dependent on the internals of the utility class. This can make the system difficult to maintain. Additionally, the domain class now has all the functionality of the utility class - some of which it might not need. This blurs the concept of the domain class and may cause it to have more than a single responsibility.

In good object-oriented programming, objects should be representative of the real-world entities they exemplify and should relate to each other as such. In this scenario a "has-a" relationship would be more appropriate. The inherited functionality can be obtained using delegation instead of inheritance. By using the [http://en.wikipedia.org/wiki/Composition_over_inheritance composition over inheritance] principle, we can avoid the BaseBean antipattern.

====Example====

Let's say we want to create a class that emulates a toll booth. The cars at the toll booth form a queue, so our toll booth will need the functionality (queue, dequeue, isEmpty, etc.) of a queue. We could implement our toll booth by inheriting this functionality from a Queue class as such:

public class TollBooth extends Queue{
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Obviously, a tollbooth is not a queue, but more appropriately, has a queue. Hence, our toll booth class should be created to contain a queue to model the line of cars.

public class TollBooth
private Queue<Vehicles>
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Our TollBooth class now has the functionality it needs without the inherent liabilities of extending the Queue class.

===The Blob===
====Description====
'''The Blob''', also called a '''God Class''', is a development antipattern that results when one single class has too many attributes, operations, or both.<ref name = sourcemaking_tb/> '''The Blob''' is usually an indicator of poor object-oriented design, or a poorly-migrated legacy program.<ref name = ap/> It can often resemble a procedural 'main' program, and may even encapsulate most or all of the functionality of an application. '''The Blob''' class violates the ''One Responsibility Rule'', which makes it unlikely to be reusable. '''The Blob''' class may be expensive to load into memory, and wasteful if only part of the functionality is used. It also will likely be difficult to effectively test.<ref name = ap/> '''The Blob''' is typically caused by a lack of an object-oriented architecture.<ref name = ap/> It can also be the result of an up-front object-oriented design that did not take into account a requirement, and developers choosing not to rearrange the class hierarchy after the initial design. It can also be a ''Specified Disaster''; the result of requirements that specify a procedural solution.<ref name = ap/>

The solution to '''The Blob''' is to refactor the code, with the goal of moving behavior away from the offending class.<ref name = sourcemaking_tb /> If '''The Blob''' encapsulates data in some other objects, then code manipulating that data should be moved to the other classes, in an effort to make the other classes more complex and '''The Blob''' less complex. If possible, the developers should try to split '''The Blob''' into multiple classes with class minimal coupling.

====Example====
An example of class approaching '''The Blob''' status that may be familiar to many students this semester is the [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza Project]'s assignment controller.<ref name="expertiza" /> The assignment controller in Expertiza does not encapsulate the majority of functionality in the entire application, but it is out of proportion with most of the other classes, and it does include functionality that should be in some other classes.<ref name="fall2011_oss" /> The project assignment contains the following notes:

<blockquote>It contains functionality for adding and removing participants for this assignment, which should really be in a participant class, for assigning reviewers, which should probably be in a reviewer class, and for computing the maximum score possible on a questionnaire. Functions like compute_scores, and candidate_topics_to_review, among others, should be moved to other classes.</blockquote><ref name="fall2011_oss" />

===Golden Hammer===
====Description====
The '''Golden Hammer''' design AntiPattern, also known as the '''Law of the instrument''', is an over-reliance on a familiar tool.<ref name="wiki_gh" /> It is one of the most common antipatterns seen in the industry.<ref name="sourcemaking_gh" />

Many software engineering projects solve problems or use techniques that programmers are strongly familiar with. Programmers often reuse strategies, algorithms, or entire sections of code that they or another programmer has applied to a different project in the past. Reuse in this manner can save development time and cost, but only when reused code is appropriate for the new application.

The '''Golden Hammer''' design anti-pattern results from reusing a familiar solution that is a poor match for a new problem.<ref name="sourcemaking_gh" /> This can occur if the developers are simply comfortable with or used to an existing approach, or even the result of narrow-mindedness or hubris. It can also be the direct result of reliance on proprietary technologies or products, or a deliberate effort to try to build a previous projects' success into a new program. A '''Golden Hammer''' will typically manifest itself with poor performance or scalability.<ref name="sourcemaking_gh" />
==Conclusions==
==Resources==
==References==
<references>
<ref name = koenig> Koenig, Andrew (March/April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming 8 (1): 46–48.; was later re-printed in the: Rising, Linda (1998). [http://books.google.com/?id=HBAuixGMYWEC&pg=PT1&dq=0-521-64818-1 The patterns handbook: techniques, strategies, and applications]. Cambridge, U.K.: Cambridge University Press. p. 387. </ref>
<ref name = gof> [http://en.wikipedia.org/wiki/Design_Patterns_%28book%29 Design Patterns] by Gang of Four</ref>
<ref name = ap> Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, Theresa Hudson (ed) (1998). [http://www.antipatterns.com/AntiPatterns/Welcome.html ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''. ]</ref>
<ref name = sourcemaking_tb> http://sourcemaking.com/antipatterns/the-blob [http://sourcemaking.com/antipatterns/the-blob]</ref>
<ref name = wiki_gh> http://en.wikipedia.org/wiki/Golden_hammer [http://en.wikipedia.org/wiki/Golden_hammer]</ref>
<ref name = sourcemaking_gh> http://sourcemaking.com/antipatterns/golden-hammer [http://sourcemaking.com/antipatterns/golden-hammer]
<ref name = expertiza> Expertiza - Reusable learning objects through peer review [http://wikis.lib.ncsu.edu/index.php/Expertiza] </ref>
<ref name = fall2011_oss> CSC/ECE517 Fall 2011 OSS Projects in Expertiza [https://docs.google.com/a/ncsu.edu/document/d/1zZ-a_tkLGrbYJbG-2QBCRqe_Y9XLR4AZMH0rc6KvrYU/edit?hl=en_US] </ref>
</ref>
</references>

CSC/ECE 517 Fall 2011/ch7 7d rt

2011-11-29T18:15:46Z

Rbjeffer:

AntiPatterns in Software Development
__TOC__

==Introduction==
The term ''antipattern'' was coined by Andrew Koenig<ref name = koenig/>, in 1995. His inspiration was a story told about Thomas Edison's many failed attempts to find a suitable material for the filament of a light bulb. When asked if he was discouraged, Edison replied that indeed he was not; he now knew hundreds of items that wouldn't work.

Koenig believed that the same philosophy should be applied to software development. As he studied the book ''Design Patterns'' presented by the GoF<ref name = gof/>, he felt that it was just as important to identify potential pitfalls as well as positive practices. He named these non-solutions ''antipatterns''. He defined an ''antipattern'' as "just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn't one." <ref name = koenig/>

In 1998, a different group of four expanded on this idea publishing '''''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis'''''<ref name = ap/>. The book identified antipatterns from three different viewpoints: the software developer, the software architect and the software manager. The authors used two criteria to distinguish antipatterns:
* It was a frequent occurrence, that initially seemed to be beneficial, but ultimately was not and
* There is a alternate, preferred solution that is proven and repeatable.

Through the years the concept of antipatterns has been further extended to apply to additional areas of software development as well as areas outside the realm of programming. This article will address software development antipatterns.

Just like patterns, antipatterns have certain elements. They include:
# Name so that they can be identified.
# A description of why the bad solution might be attractive.
# An explanation of how that solution is bad long-term.
# Suggestions for other patterns that provide better solutions.

There are several catalogs of antipatterns available as well as a number of books that address the topic. Below we will explore a few of the more common antipatterns.

==AntiPatterns==
===Call Super===

====Description====
We are all familiar with the concept of inheritance in object-oriented programming where a subclass takes on the properties and actions of a superclass. The subclass can then override the methods of the superclass either replacing or augmenting the functionality provided in the superclass. The '''call super''' antipattern requires subclasses to override methods of the super class and then call back the overridden method at some point. This requirement may stem from the fact that the superclass does some set up operations that cannot be done in the subclass or if the subclass is expanding the superclass task rather than replacing it.

Calling a superclass method from a subclass is not in general a bad practice, but '''requiring''' it to do so is. Imposing such a constraint can lead to several problems. Future developers may forget to call the superclass causing untold bugs and system errors. Additionally, it requires anyone using the interface to have an understanding of the inner workings of the superclass. Ideally, they would only need to understand the public interface. Finally, if the superclass expects specific actions from the subclass, it may not perform well (or at all) if those actions aren't performed as expected.

A better approach to obtaining the desired functionality would be to use the [http://en.wikipedia.org/wiki/Template_method_pattern Template Method] pattern. Here the superclass would include a public method and define a separate method (often called a hook method) for the subclass to override. The superclass method would then call the hook method. The hook method can either be an abstract method in the superclass and fully implemented in the subclass, or have some basic functionality in the superclass and augmented in the superclass. Either way the subclass does not have to worry about calling the superclass.

====Example====

Let's say we have a class registration framework with an EventHandler superclass. The EventHandler is used to process all "transactions" - administrators adding classes, students registering for classes, students dropping classes, etc. It has to do some basic setup and housekeeping functions (checking availability, permissions, etc.) before the registration event can be processed. Our original code for a student registering for a class might be something like the following.

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
}

public class StudentClassRegistrationHandler extends EventHandler...
public void handle(RegistrationEvent e) {
super.handle(e);
RegisterStudent(e);
}

The method StudentClassRegistrationHandler must call super.handle() before it can begin its task of registering the student. If we refactor this code using the Template Method pattern, we could get the following code:

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
doAction(e);
}
protected void doAction(RegistrationEvent e) {
}

public class StudentClassRegistrationHandler extends EventHandler ...
protected void doAction(RegistrationEvent e) {
RegisterStudent(e);
}

The subclass is now only responsible for its own functionality. This arrangement also allows the superclass to call some follow-up or clean-up methods after the subclass method if necessary.

===BaseBean===

====Description====
Similar to the Call Super antipattern is the BaseBean antipattern. It is found in object-oriented programming when a concrete domain class is formed using inheritance from a utility class. This relationship is used simply to inherit utility methods from the utility class. This is sometimes referred to as inheritance for implementation.

Inheritance for the sake of gaining the functionality in the parent class is not good style. This obviously is not an "is-a" a relationship and may violate the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle]. By inheriting from the utility class, the domain class becomes dependent on the internals of the utility class. This can make the system difficult to maintain. Additionally, the domain class now has all the functionality of the utility class - some of which it might not need. This blurs the concept of the domain class and may cause it to have more than a single responsibility.

In good object-oriented programming, objects should be representative of the real-world entities they exemplify and should relate to each other as such. In this scenario a "has-a" relationship would be more appropriate. The inherited functionality can be obtained using delegation instead of inheritance. By using the [http://en.wikipedia.org/wiki/Composition_over_inheritance composition over inheritance] principle, we can avoid the BaseBean antipattern.

====Example====

Let's say we want to create a class that emulates a toll booth. The cars at the toll booth form a queue, so our toll booth will need the functionality (queue, dequeue, isEmpty, etc.) of a queue. We could implement our toll booth by inheriting this functionality from a Queue class as such:

public class TollBooth extends Queue{
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Obviously, a tollbooth is not a queue, but more appropriately, has a queue. Hence, our toll booth class should be created to contain a queue to model the line of cars.

public class TollBooth
private Queue<Vehicles>
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Our TollBooth class now has the functionality it needs without the inherent liabilities of extending the Queue class.

===The Blob===
====Description====
'''The Blob''', also called a '''God Class''', is a development antipattern that results when one single class has too many attributes, operations, or both.<ref name = sourcemaking_tb/> '''The Blob''' is usually an indicator of poor object-oriented design, or a poorly-migrated legacy program.<ref name = ap/> It can often resemble a procedural 'main' program, and may even encapsulate most or all of the functionality of an application. '''The Blob''' class violates the ''One Responsibility Rule'', which makes it unlikely to be reusable. '''The Blob''' class may be expensive to load into memory, and wasteful if only part of the functionality is used. It also will likely be difficult to effectively test.<ref name = ap/> '''The Blob''' is typically caused by a lack of an object-oriented architecture.<ref name = ap/> It can also be the result of an up-front object-oriented design that did not take into account a requirement, and developers choosing not to rearrange the class hierarchy after the initial design. It can also be a ''Specified Disaster''; the result of requirements that specify a procedural solution.<ref name = ap/>

The solution to '''The Blob''' is to refactor the code, with the goal of moving behavior away from the offending class.<ref name = sourcemaking_tb /> If '''The Blob''' encapsulates data in some other objects, then code manipulating that data should be moved to the other classes, in an effort to make the other classes more complex and '''The Blob''' less complex. If possible, the developers should try to split '''The Blob''' into multiple classes with class minimal coupling.

====Example====
An example of class approaching '''The Blob''' status that may be familiar to many students this semester is the [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza Project]'s assignment controller.<ref name="expertiza" /> The assignment controller in Expertiza does not encapsulate the majority of functionality in the entire application, but it is out of proportion with most of the other classes, and it does include functionality that should be in some other classes.<ref name="fall2011_oss" /> The project assignment contains the following notes:

It contains functionality for adding and removing participants for this assignment, which should really be in a participant class, for assigning reviewers, which should probably be in a reviewer class, and for computing the maximum score possible on a questionnaire. Functions like compute_scores, and candidate_topics_to_review, among others, should be moved to other classes.<ref name="fall2011_oss" />

===Golden Hammer===
====Description====
The '''Golden Hammer''' design AntiPattern, also known as the '''Law of the instrument''', is an over-reliance on a familiar tool.<ref name="wiki_gh" /> It is one of the most common antipatterns seen in the industry.<ref name="sourcemaking_gh" />

Many software engineering projects solve problems or use techniques that programmers are strongly familiar with. Programmers often reuse strategies, algorithms, or entire sections of code that they or another programmer has applied to a different project in the past. Reuse in this manner can save development time and cost, but only when reused code is appropriate for the new application.

The '''Golden Hammer''' design anti-pattern results from reusing a familiar solution that is a poor match for a new problem.<ref name="sourcemaking_gh" /> This can occur if the developers are simply comfortable with or used to an existing approach, or even the result of narrow-mindedness or hubris. It can also be the direct result of reliance on proprietary technologies or products, or a deliberate effort to try to build a previous projects' success into a new program. A '''Golden Hammer''' will typically manifest itself with poor performance or scalability.<ref name="sourcemaking_gh" />
==Conclusions==
==Resources==
==References==
<references>
<ref name = koenig> Koenig, Andrew (March/April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming 8 (1): 46–48.; was later re-printed in the: Rising, Linda (1998). [http://books.google.com/?id=HBAuixGMYWEC&pg=PT1&dq=0-521-64818-1 The patterns handbook: techniques, strategies, and applications]. Cambridge, U.K.: Cambridge University Press. p. 387. </ref>
<ref name = gof> [http://en.wikipedia.org/wiki/Design_Patterns_%28book%29 Design Patterns] by Gang of Four</ref>
<ref name = ap> Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, Theresa Hudson (ed) (1998). [http://www.antipatterns.com/AntiPatterns/Welcome.html ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''. ]</ref>
<ref name = sourcemaking_tb> http://sourcemaking.com/antipatterns/the-blob [http://sourcemaking.com/antipatterns/the-blob]</ref>
<ref name = wiki_gh> http://en.wikipedia.org/wiki/Golden_hammer [http://en.wikipedia.org/wiki/Golden_hammer]</ref>
<ref name = sourcemaking_gh> http://sourcemaking.com/antipatterns/golden-hammer [http://sourcemaking.com/antipatterns/golden-hammer]
<ref name = expertiza> Expertiza - Reusable learning objects through peer review [http://wikis.lib.ncsu.edu/index.php/Expertiza] </ref>
<ref name = fall2011_oss> CSC/ECE517 Fall 2011 OSS Projects in Expertiza [https://docs.google.com/a/ncsu.edu/document/d/1zZ-a_tkLGrbYJbG-2QBCRqe_Y9XLR4AZMH0rc6KvrYU/edit?hl=en_US] </ref>
</ref>
</references>

CSC/ECE 517 Fall 2011/ch7 7d rt

2011-11-29T18:02:34Z

Rbjeffer:

AntiPatterns in Software Development
__TOC__

==Introduction==
The term ''antipattern'' was coined by Andrew Koenig<ref name = koenig/>, in 1995. His inspiration was a story told about Thomas Edison's many failed attempts to find a suitable material for the filament of a light bulb. When asked if he was discouraged, Edison replied that indeed he was not; he now knew hundreds of items that wouldn't work.

Koenig believed that the same philosophy should be applied to software development. As he studied the book ''Design Patterns'' presented by the GoF<ref name = gof/>, he felt that it was just as important to identify potential pitfalls as well as positive practices. He named these non-solutions ''antipatterns''. He defined an ''antipattern'' as "just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn't one." <ref name = koenig/>

In 1998, a different group of four expanded on this idea publishing '''''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis'''''<ref name = ap/>. The book identified antipatterns from three different viewpoints: the software developer, the software architect and the software manager. The authors used two criteria to distinguish antipatterns:
* It was a frequent occurrence, that initially seemed to be beneficial, but ultimately was not and
* There is a alternate, preferred solution that is proven and repeatable.

Through the years the concept of antipatterns has been further extended to apply to additional areas of software development as well as areas outside the realm of programming. This article will address software development antipatterns.

Just like patterns, antipatterns have certain elements. They include:
# Name so that they can be identified.
# A description of why the bad solution might be attractive.
# An explanation of how that solution is bad long-term.
# Suggestions for other patterns that provide better solutions.

There are several catalogs of antipatterns available as well as a number of books that address the topic. Below we will explore a few of the more common antipatterns.

==AntiPatterns==
===Call Super===

====Description====
We are all familiar with the concept of inheritance in object-oriented programming where a subclass takes on the properties and actions of a superclass. The subclass can then override the methods of the superclass either replacing or augmenting the functionality provided in the superclass. The '''call super''' antipattern requires subclasses to override methods of the super class and then call back the overridden method at some point. This requirement may stem from the fact that the superclass does some set up operations that cannot be done in the subclass or if the subclass is expanding the superclass task rather than replacing it.

Calling a superclass method from a subclass is not in general a bad practice, but '''requiring''' it to do so is. Imposing such a constraint can lead to several problems. Future developers may forget to call the superclass causing untold bugs and system errors. Additionally, it requires anyone using the interface to have an understanding of the inner workings of the superclass. Ideally, they would only need to understand the public interface. Finally, if the superclass expects specific actions from the subclass, it may not perform well (or at all) if those actions aren't performed as expected.

A better approach to obtaining the desired functionality would be to use the [http://en.wikipedia.org/wiki/Template_method_pattern Template Method] pattern. Here the superclass would include a public method and define a separate method (often called a hook method) for the subclass to override. The superclass method would then call the hook method. The hook method can either be an abstract method in the superclass and fully implemented in the subclass, or have some basic functionality in the superclass and augmented in the superclass. Either way the subclass does not have to worry about calling the superclass.

====Example====

Let's say we have a class registration framework with an EventHandler superclass. The EventHandler is used to process all "transactions" - administrators adding classes, students registering for classes, students dropping classes, etc. It has to do some basic setup and housekeeping functions (checking availability, permissions, etc.) before the registration event can be processed. Our original code for a student registering for a class might be something like the following.

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
}

public class StudentClassRegistrationHandler extends EventHandler...
public void handle(RegistrationEvent e) {
super.handle(e);
RegisterStudent(e);
}

The method StudentClassRegistrationHandler must call super.handle() before it can begin its task of registering the student. If we refactor this code using the Template Method pattern, we could get the following code:

public class EventHandler ...
public void handle (RegistrationEvent e) {
setup(e);
doAction(e);
}
protected void doAction(RegistrationEvent e) {
}

public class StudentClassRegistrationHandler extends EventHandler ...
protected void doAction(RegistrationEvent e) {
RegisterStudent(e);
}

The subclass is now only responsible for its own functionality. This arrangement also allows the superclass to call some follow-up or clean-up methods after the subclass method if necessary.

===BaseBean===

====Description====
Similar to the Call Super antipattern is the BaseBean antipattern. It is found in object-oriented programming when a concrete domain class is formed using inheritance from a utility class. This relationship is used simply to inherit utility methods from the utility class. This is sometimes referred to as inheritance for implementation.

Inheritance for the sake of gaining the functionality in the parent class is not good style. This obviously is not an "is-a" a relationship and may violate the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle]. By inheriting from the utility class, the domain class becomes dependent on the internals of the utility class. This can make the system difficult to maintain. Additionally, the domain class now has all the functionality of the utility class - some of which it might not need. This blurs the concept of the domain class and may cause it to have more than a single responsibility.

In good object-oriented programming, objects should be representative of the real-world entities they exemplify and should relate to each other as such. In this scenario a "has-a" relationship would be more appropriate. The inherited functionality can be obtained using delegation instead of inheritance. By using the [http://en.wikipedia.org/wiki/Composition_over_inheritance composition over inheritance] principle, we can avoid the BaseBean antipattern.

====Example====

Let's say we want to create a class that emulates a toll booth. The cars at the toll booth form a queue, so our toll booth will need the functionality (queue, dequeue, isEmpty, etc.) of a queue. We could implement our toll booth by inheriting this functionality from a Queue class as such:

public class TollBooth extends Queue{
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Obviously, a tollbooth is not a queue, but more appropriately, has a queue. Hence, our toll booth class should be created to contain a queue to model the line of cars.

public class TollBooth
private Queue<Vehicles>
/*additional methods and properties for toll booth such as
toll booth operator, token processor, cross arm, change processor, etc. */

Our TollBooth class now has the functionality it needs without the inherent liabilities of extending the Queue class.

===The Blob===
====Description====
'''The Blob''', also called a '''God Class''', is a development antipattern that results when one single class has too many attributes, operations, or both.<ref name = sourcemaking_tb/> '''The Blob''' is usually an indicator of poor object-oriented design, or a poorly-migrated legacy program.<ref name = ap/> It can often resemble a procedural 'main' program, and may even encapsulate most or all of the functionality of an application. '''The Blob''' class violates the ''One Responsibility Rule'', which makes it unlikely to be reusable. '''The Blob''' class may be expensive to load into memory, and wasteful if only part of the functionality is used. It also will likely be difficult to effectively test.<ref name = ap/> '''The Blob''' is typically caused by a lack of an object-oriented architecture.<ref name = ap/> It can also be the result of an up-front object-oriented design that did not take into account a requirement, and developers choosing not to rearrange the class hierarchy after the initial design. It can also be a ''Specified Disaster''; the result of requirements that specify a procedural solution.<ref name = ap/>

The solution to '''The Blob''' is to refactor the code, with the goal of moving behavior away from the offending class.<ref name = sourcemaking_tb /> If '''The Blob''' encapsulates data in some other objects, then code manipulating that data should be moved to the other classes, in an effort to make the other classes more complex and '''The Blob''' less complex. If possible, the developers should try to split '''The Blob''' into multiple classes with class minimal coupling.

====Example====
An example of class approaching '''The Blob''' status that may be familiar to many students this semester is the [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza Project]'s assignment controller. The assignment controller in Expertiza does not encapsulate the majority of functionality in the entire application, but it is out of proportion with most of the other classes, and it does include functionality that should be

===Golden Hammer===
====Description====
The '''Golden Hammer''' design AntiPattern, also known as the '''Law of the instrument''', is an over-reliance on a familiar tool.<ref name="wiki_gh" /> It is one of the most common antipatterns seen in the industry.<ref name="sourcemaking_gh" />

Many software engineering projects solve problems or use techniques that programmers are strongly familiar with. Programmers often reuse strategies, algorithms, or entire sections of code that they or another programmer has applied to a different project in the past. Reuse in this manner can save development time and cost, but only when reused code is appropriate for the new application.

The '''Golden Hammer''' design anti-pattern results from reusing a familiar solution that is a poor match for a new problem.<ref name="sourcemaking_gh" /> This can occur if the developers are simply comfortable with or used to an existing approach, or even the result of narrow-mindedness or hubris. It can also be the direct result of reliance on proprietary technologies or products, or a deliberate effort to try to build a previous projects' success into a new program. A '''Golden Hammer''' will typically manifest itself with poor performance or scalability.<ref name="sourcemaking_gh" />
==Conclusions==
==Resources==
==References==
<references>
<ref name = koenig> Koenig, Andrew (March/April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming 8 (1): 46–48.; was later re-printed in the: Rising, Linda (1998). [http://books.google.com/?id=HBAuixGMYWEC&pg=PT1&dq=0-521-64818-1 The patterns handbook: techniques, strategies, and applications]. Cambridge, U.K.: Cambridge University Press. p. 387. </ref>
<ref name = gof> [http://en.wikipedia.org/wiki/Design_Patterns_%28book%29 Design Patterns] by Gang of Four</ref>
<ref name = ap> Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, Theresa Hudson (ed) (1998). [http://www.antipatterns.com/AntiPatterns/Welcome.html ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''. ]</ref>
<ref name = sourcemaking_tb> http://sourcemaking.com/antipatterns/the-blob [http://sourcemaking.com/antipatterns/the-blob]</ref>
<ref name = wiki_gh> http://en.wikipedia.org/wiki/Golden_hammer [http://en.wikipedia.org/wiki/Golden_hammer]</ref>
<ref name = sourcemaking_gh> http://sourcemaking.com/antipatterns/golden-hammer [http://sourcemaking.com/antipatterns/golden-hammer]
<ref name = expertiza> Expertiza - Reusable learning objects through peer review [http://wikis.lib.ncsu.edu/index.php/Expertiza] </ref>
<ref name = fall2011_fp> CSC/ECE517 Fall 2011 Final Projects in Expertiza [https://docs.google.com/a/ncsu.edu/document/d/1LDWHpdIaaQ37NwHfOuSq-baqCr5SvQgaouSPeVM7qNA/edit?authkey=CMusubYH] </ref>
</ref>
</references>

CSC/ECE 517 Fall 2011/ch7 7d rt

2011-11-28T21:36:38Z

Rbjeffer:

CSC/ECE 517 Fall 2011/ch7 7d rt

2011-11-28T21:25:47Z

Rbjeffer:

CSC/ECE 517 Fall 2011/ch7 7d rt

2011-11-28T21:15:13Z

Rbjeffer:

CSC/ECE 517 Fall 2011/ch7 7d rt

2011-11-28T21:14:14Z

Rbjeffer:

CSC/ECE 517 Fall 2011/ch7 7d rt

2011-11-27T20:03:19Z

Rbjeffer:

CSC/ECE 517 Fall 2011/ch3 3h rr

2011-10-29T22:01:34Z

Rbjeffer:

''3h. Primitive objects. At the beginning of Lecture 11, we discovered that Fixnums and Bignums are handled differently behind the scenes in Ruby. Other languages, like Java, have made similar distinctions. By contrast, languages such as C# and Eiffel try to hide these implementation differences from users. Answer two questions: (1) How have different o-o languages implemented primitive objects? E.g., how are they represented in memory, how are they tested for, do comparisons do anything different than for class objects, etc. (2) What are the advantages and disadvantages of treating primitives differently from class objects in source code?''

== Introduction ==
Programming languages, whether statically or dynamically typed, have support for certain in-built data types. These data types, known as primitive types, are the basic representation of information in programs and have certain fixed attributes for a specific language[http://en.wikipedia.org/wiki/Primitive_data_type]. Statically typed languages such as C++, Java, Perl etc. support primitive data types, whereas with dynamically typed languages such as Ruby, Smalltalk, Lisp etc. they are actually in the form of primitive objects. These primitive types are used to store the basic types of information that a computer can store and manipulate, and can also be used as building blocks for creating more complex data types.
This article explains the way different primitive types are implemented in certain object oriented languages. An analysis of the benefits and drawbacks of such types and the methods used to operate on them is also presented.

== Primitive Types ==
The primitive types commonly included in most programming languages are:
* Boolean
* Character
* Integer
* Floating-point number
* Fixed-point number
* Reference

=== Boolean ===
A Boolean is a primitive data type used to store one of two logical types: true or false. Boolean data types are most commonly used as input paramters to a conditional statement (such as an ‘if’ statement), or as the output of a comparison between two comparable data types. Booleans can be implemented in languages as either a discrete logical type, or implicitly as a numerical type. In many languages, booleans can be implicitly converted to and from integer types.

=== Character ===
A character is a data type that represents an element of a written language, such as a letter, number, or symbol. A character can also represent a control character, such as a carriage return or newline, which does not have a written meaning but controls how other characters are stored or displayed. Characters are commonly stored as integers, and encoded using a character map.

=== Integer ===
An integer is a data type that represents one element of a finite subset of mathematical integers. Integer, or Integral, data types can be either unsigned (able to store only positive whole numbers) or signed (able to store either positive or negative whole numbers). The range of values that can be represented by an integer depends on the number of bits used to store the integer, whether or not it is a signed integer, and the encoding scheme (if it is signed). Typically, an integer has a minimum and maximum value, and can store any integer in the range between those values. The minimum value for unsigned integers is typically 0, and the maximum value is typically determined by the amount of memory used to store the integer. For example, a un unsigned 8-bit number can store 2^8 (or 256) possible integral values; and would typically store any value from 0 to 255. More generally, an n-bit unsigned integer can store from 0 to (2^n)-1. For signed integers, modern computers use the Two’s Complement encoding scheme. This allows for a range of −2^(n−1) through 2^(n−1)−1. For example, an 8-bit signed integer could store any whole number in the range from -128 through +127.

=== Floating-Point Number ===
A floating point number is a data type used to represent real numbers in a large range with varying degrees of precision. In this representation, numbers are represented with a variable number of significant digits, and a variable number of exponential digits.

=== Fixed-Point number ===
A fixed-point number is a data type used to represent real numbers. Fixed-point numbers are called fixed-point because they have a set number of digits before and after a decimal mark. In this regard, fixed-point numbers are represented as an integer, but are scaled by a predetermined factor.

Fixed-point numbers are commonly used in microprocessors that do not have a floating-point unit, or in systems in which computational efficiency is critical. Fixed-point numbers can be treated as integers by an arithmetic logic unit (ALU) and scaled after a result is obtained, which can significantly lower the amount of time needed for a processor to obtain the result for some algorithms.

Implementing algorithms using fixed-point arithmetic requires great care, because of the potential for information loss. Fixed-point arithmetic operations -- multiplication in particular, has the potential to cause overflow. Algorithms must be written with care to ensure that each term of an equation has a similar range and that the result will not cause an overflow.

=== Reference ===

A Reference is a data type that enables a program to access another item in memory. A reference differs from other primitive data types in that it does not store data itself; instead it stores a value referring to another data object. References are commonly used to refer to objects of large non-primitive data types. References commonly store the physical memory address of the data that they are referring to. Accessing the data referred to by a Reference is called dereferencing.

== Primitive Data Types in C++ ==

C++ is a statically-typed object oriented language. C++ is based on the C programming language, which is procedural, and adds support for object-oriented code.

These data types are defined in C++: [http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php]

{| border="1" style="border-spacing: 0" cellpadding="5"
! Name
! Size
! Description
! Range
|-
| void
| N/A
| the void data type is used to explicitly identify that a data has no type
| N/A
|-
| int
| 32 bits
| simple numerical type
| See [[http://www.jk-technology.com/c/inttypes.html]]
|-
| float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 8 bits
| a char is a single 8-bit character encoded using ASCII
| Ascii character 0x00 through ascii character 0xFF
|}
C++ supports Pointers for all of the types listed in the table above, as well as more complex data types (such as structs). A Pointer in C++ is a data type that stores the physical address of some other data. Pointers are created in C++ by using the * operator. For example, a *Double[] is a pointer to an array of double-precision floating point numbers. C++ Also supports function pointers -- pointers that reference the beginning address of a function in memory. They are commonly used to implement callback functions [http://newty.de/fpt/intro.html#what]

== Primitive Data Types in Java ==

Java is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. These data types are defined in Java: [http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html]
{| border="1" style="border-spacing: 0" cellpadding="5"
! align="left"|Name
! Size
! Description
! Range
|-
|byte
|8 bits
|signed two's complement integer
|128 to 127
|-
| short
|16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| int
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| long
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
|float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|}

Java also defines a String class, which is used to create objects of many chars. The String class provides functionality commonly implemented using arrays of chars in other languages, such as C.

Java also defines the 'unsigned' keyword, which can be used to as a modifier to any of the integral types listed in the table above. If the 'unsigned' keyword is used, the integral type will be unsigned instead of signed, and its range will change correspondingly.

Java is capable of using any two objects of the same primitive data type for comparison. Java defines a class for each data type, which have the same name but a capitalized first letter (e.g. Float instead of float). These classes, called wrapper classes provide a series of methods that can manipulate their associated primitive data type, as well as convert to and from other data types.

== Primitive Data Types in C# ==

C# is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. C# has all of the data types that are available in Java, as well as some additional ones.

Similar to Java, C# defines a String class which is used to create objects of many chars. These data types are defined in C#: [http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx]

{| border="1" style="border-spacing: 0" cellpadding="5"
! align="left"| Name
! .NET Class
! width="50" | Size
! Description
! Range
|-
|byte
| Byte
| 8 bits
|signed two's complement integer
| -128 to 127
|-
| sbyte
| SByte
| 8 bits
| signed two's complement integer
| -0 to 255
|-
| short
| Int16
| 16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| ushort
| UInt16
| 16 bits
| unsigned integer
| 0 to 65,535
|-
| int
| Int32
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| uint
| UInt32
| 32 bits
| unsigned integer
| 0 to 4,294,967,295
|-
| long
| Int64
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
| ulong
| UInt64
| 64 bits
| unsigned integer
| 0 to 18,446,744,073,709,551,615
|-
|float
| Float
| 32 bits
| single-precision IEEE 754 floating point
| -3.402823e38 to 3.02823e38
|-
| double
| Double
| 64 bits
| double-precision IEEE 754 floating point
| -1.79769313486232e308 to 1.79769313486232e308
|-
| boolean
| Boolean
| 1 bit
| boolean
| false, true
|-
| char
| Char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|-
| object
| Object
| N/A
| Object is the base type of all other types
| N/A
|-
| string
| String
| N/A
| String is the base type for a sequence of chars
| N/A
|-
| decimal
| Decimal
| 128
| Decimal is an integral type that can represent a decimal number with 29 significant digits
| ±1.0 × 10e−28 to ±7.9 × 10e28
|}

Like Java, each primitive data type in C# also has a class associated with it that. These classes serve a similar purpose to their associated ones in Java. They are used for comparison of objects, as well as conversion between other similar types.

== Primitive Objects in Ruby ==
Ruby is a pure object oriented language as compared to languages such as Java or C#, which use a more hybrid approach. In Ruby, all data types are represented as Objects. There are some [http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html inbuilt classes] that are provided to users in Ruby. However, only some of them are a basic building block for forming other types. This subset shown below gives us a list of primitive objects that can be used for data representation and manipulation:

{| border="1" style="border-spacing: 0" cellpadding="5"
! align="left"| Name
! Description
! Range
|-
| TrueClass
| Singleton instance "true" allowed
| true
|-
| FalseClass
| Singleton instance "false" allowed
| false
|-
| Integer [http://www.ruby-doc.org/core/Integer.html]
| Abstract class that forms the basis for Fixnum and Bignum
| See Fixnum and Bignum
|-
| Fixnum [http://www.ruby-doc.org/core-1.8.7/Fixnum.html]
| Integer representations that fit in native machine word
| Machine architecture dependent. 2^30-1 to -2^30 on 32-bit machines.
|-
| Bignum [http://www.ruby-doc.org/core/Bignum.html]
| Integer representations that do not fit in Fixnum width
| Machine architecture dependent. Values above Fixnum range.
|-
| Float [http://www.ruby-doc.org/core/Float.html]
| Real numbers using double precision representation
| Value after decimal point can be formatted
|-
| String [http://corelib.rubyonrails.org/classes/String.html]
| Contains sequence of characters
| No physical limit, but can be decided by machine architecture
|}

One interesting observation from the above table is that Ruby does not have a Boolean class; instead it has a separate TrueClass and FalseClass [http://www.skorks.com/2009/09/true-false-and-nil-objects-in-ruby].

puts true.class
=> TrueClass
puts false.class
=> FalseClass

Although types such as Array, Hash are also in-built types, they can be further composed of elements that are internally represented in one of the primitive types. Hence, they will not be treated by us as primitive objects, in the traditional definition of the term.
Each of the primitive objects listed above also provide certain convenience methods that are applicable for the underlying type.
For example, the Fixnum, Bignum and Float types provide support for arithmetic operations such as addition (+), subtraction(--), multiplication(*) and so on.
As with all other classes in Ruby, users can add functionality to existing primitive objects by reopening classes. The amount of memory required to implement the primitive objects in Ruby is machine dependent in some cases.

== Merit Analysis of Primitive Types ==
This section deals with a brief analysis of the relative merits and demerits of primitive data types. While we focus on Java or Ruby for this purpose, most of these points are applicable across all object oriented languages.

=== Advantages ===
Primitive types in object oriented languages have certain advantages over their class object counterparts.
* Simplicity: Primitive types/objects provide users a simple mechanism of manipulating data without relying on additional objects to achieve the same functionality. Operations on primitive types are more intuitive.
* Efficiency: This statement is applicable if the underlying primitive object definition is not modified (a feature that languages such as Ruby provide to users). As the representation in memory is designed to be make most efficient use of the underlying datatype, use of primitives can provide a benefit to the user, over the use of class objects to store the same data.
Eg. Java provides wrappers [http://www.glenmccl.com/tip_016.htm] for certain primitive types. There is a certain performance and space cost associated with these.
So, to maximize efficiency, direct use of the primitive types would provide the most benefit.
* Ability to use inbuilt methods: Depending on the primitive type, languages such as Ruby provide methods that can be used specifically to probe or manipulate objects.
Eg. [http://corelib.rubyonrails.org/classes/String.html String] primitive object provides convenience methods such as upcase to convert the entire string to upper case, or capitalize, which converts only the first character to upper case.
* Ease of testing for comparison: With primitive types, the equality testing operators such as == can be used. These essentially compare the values stored in the primitive types. Regular objects also offer the eql? method for testing equality. However, the following are not equivalent:
a=10
=> 10
a==10
=> true
a==10.0
=> true
a.eql?(10.0)
=> false
The reason the .eql? fails is that this operator tests for value and type being the same. 10 is type Fixnum and 10.0 is type Float.
The eql? can be overridden by == for primitive objects if you wish to compare only the values, but that can have a negative impact on performance [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html].

=== Disadvantages ===
* Lack of inheritance capability: The primitive data types in languages such as Java cannot be inherited to create further subtypes.
* Unexpected results due to method overriding: There are certain examples such as [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html], which show that overriding inbuilt methods such as == and eql? can lead to unexpected results.

== Conclusion ==
Object oriented languages have varying levels of support for primitive data types and objects. Whether they are beneficial or not depends on the application to a great deal. If handled correctly, they can make object oriented programs more efficient. However, the user needs to be aware of the underlying representation of these types to handle any unexpected results.

== References ==
# http://en.wikipedia.org/wiki/Primitive_data_type
# http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php
# http://www.jk-technology.com/c/inttypes.html
# http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html
# http://newty.de/fpt/intro.html
# http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
# http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx
# http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html
# http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html
# http://www.glenmccl.com/tip_016.htm
# http://www.skorks.com/2009/09/ruby-equality-and-object-comparison/

CSC/ECE 517 Fall 2011/ch3 3h rr

2011-10-29T22:01:19Z

Rbjeffer:

''3h. Primitive objects. At the beginning of Lecture 11, we discovered that Fixnums and Bignums are handled differently behind the scenes in Ruby. Other languages, like Java, have made similar distinctions. By contrast, languages such as C# and Eiffel try to hide these implementation differences from users. Answer two questions: (1) How have different o-o languages implemented primitive objects? E.g., how are they represented in memory, how are they tested for, do comparisons do anything different than for class objects, etc. (2) What are the advantages and disadvantages of treating primitives differently from class objects in source code?''

== Introduction ==
Programming languages, whether statically or dynamically typed, have support for certain in-built data types. These data types, known as primitive types, are the basic representation of information in programs and have certain fixed attributes for a specific language[http://en.wikipedia.org/wiki/Primitive_data_type]. Statically typed languages such as C++, Java, Perl etc. support primitive data types, whereas with dynamically typed languages such as Ruby, Smalltalk, Lisp etc. they are actually in the form of primitive objects. These primitive types are used to store the basic types of information that a computer can store and manipulate, and can also be used as building blocks for creating more complex data types.
This article explains the way different primitive types are implemented in certain object oriented languages. An analysis of the benefits and drawbacks of such types and the methods used to operate on them is also presented.

== Primitive Types ==
The primitive types commonly included in most programming languages are:
* Boolean
* Character
* Integer
* Floating-point number
* Fixed-point number
* Reference

=== Boolean ===
A Boolean is a primitive data type used to store one of two logical types: true or false. Boolean data types are most commonly used as input paramters to a conditional statement (such as an ‘if’ statement), or as the output of a comparison between two comparable data types. Booleans can be implemented in languages as either a discrete logical type, or implicitly as a numerical type. In many languages, booleans can be implicitly converted to and from integer types.

=== Character ===
A character is a data type that represents an element of a written language, such as a letter, number, or symbol. A character can also represent a control character, such as a carriage return or newline, which does not have a written meaning but controls how other characters are stored or displayed. Characters are commonly stored as integers, and encoded using a character map.

=== Integer ===
An integer is a data type that represents one element of a finite subset of mathematical integers. Integer, or Integral, data types can be either unsigned (able to store only positive whole numbers) or signed (able to store either positive or negative whole numbers). The range of values that can be represented by an integer depends on the number of bits used to store the integer, whether or not it is a signed integer, and the encoding scheme (if it is signed). Typically, an integer has a minimum and maximum value, and can store any integer in the range between those values. The minimum value for unsigned integers is typically 0, and the maximum value is typically determined by the amount of memory used to store the integer. For example, a un unsigned 8-bit number can store 2^8 (or 256) possible integral values; and would typically store any value from 0 to 255. More generally, an n-bit unsigned integer can store from 0 to (2^n)-1. For signed integers, modern computers use the Two’s Complement encoding scheme. This allows for a range of −2^(n−1) through 2^(n−1)−1. For example, an 8-bit signed integer could store any whole number in the range from -128 through +127.

=== Floating-Point Number ===
A floating point number is a data type used to represent real numbers in a large range with varying degrees of precision. In this representation, numbers are represented with a variable number of significant digits, and a variable number of exponential digits.

=== Fixed-Point number ===
A fixed-point number is a data type used to represent real numbers. Fixed-point numbers are called fixed-point because they have a set number of digits before and after a decimal mark. In this regard, fixed-point numbers are represented as an integer, but are scaled by a predetermined factor.

Fixed-point numbers are commonly used in microprocessors that do not have a floating-point unit, or in systems in which computational efficiency is critical. Fixed-point numbers can be treated as integers by an arithmetic logic unit (ALU) and scaled after a result is obtained, which can significantly lower the amount of time needed for a processor to obtain the result for some algorithms.

Implementing algorithms using fixed-point arithmetic requires great care, because of the potential for information loss. Fixed-point arithmetic operations -- multiplication in particular, has the potential to cause overflow. Algorithms must be written with care to ensure that each term of an equation has a similar range and that the result will not cause an overflow.

=== Reference ===

A Reference is a data type that enables a program to access another item in memory. A reference differs from other primitive data types in that it does not store data itself; instead it stores a value referring to another data object. References are commonly used to refer to objects of large non-primitive data types. References commonly store the physical memory address of the data that they are referring to. Accessing the data referred to by a Reference is called dereferencing.

== Primitive Data Types in C++ ==

C++ is a statically-typed object oriented language. C++ is based on the C programming language, which is procedural, and adds support for object-oriented code.

These data types are defined in C++: [http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php]

{| border="1" style="border-spacing: 0" cellpadding="5"
! Name
! Size
! Description
! Range
|-
| void
| N/A
| the void data type is used to explicitly identify that a data has no type
| N/A
|-
| int
| 32 bits
| simple numerical type
| See [[http://www.jk-technology.com/c/inttypes.html]]
|-
| float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 8 bits
| a char is a single 8-bit character encoded using ASCII
| Ascii character 0x00 through ascii character 0xFF
|}
C++ supports Pointers for all of the types listed in the table above, as well as more complex data types (such as structs). A Pointer in C++ is a data type that stores the physical address of some other data. Pointers are created in C++ by using the * operator. For example, a *Double[] is a pointer to an array of double-precision floating point numbers. C++ Also supports function pointers -- pointers that reference the beginning address of a function in memory. They are commonly used to implement callback functions [http://newty.de/fpt/intro.html#what]

== Primitive Data Types in Java ==

Java is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. These data types are defined in Java: [http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html]
{| border="1" style="border-spacing: 0" cellpadding="5"
! align="left"|Name
! Size
! Description
! Range
|-
|byte
|8 bits
|signed two's complement integer
|128 to 127
|-
| short
|16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| int
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| long
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
|float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|}

Java also defines a String class, which is used to create objects of many chars. The String class provides functionality commonly implemented using arrays of chars in other languages, such as C.

Java also defines the 'unsigned' keyword, which can be used to as a modifier to any of the integral types listed in the table above. If the 'unsigned' keyword is used, the integral type will be unsigned instead of signed, and its range will change correspondingly.

Java is capable of using any two objects of the same primitive data type for comparison. Java defines a class for each data type, which have the same name but a capitalized first letter (e.g. Float instead of float). These classes, called wrapper classes provide a series of methods that can manipulate their associated primitive data type, as well as convert to and from other data types.

== Primitive Data Types in C# ==

C# is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. C# has all of the data types that are available in Java, as well as some additional ones.

Similar to Java, C# defines a String class which is used to create objects of many chars. These data types are defined in C#: [http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx]

{| border="1" style="border-spacing: 0" cellpadding="5"
! align="left"| Name
! .NET Class
! width="80" | Size
! Description
! Range
|-
|byte
| Byte
| 8 bits
|signed two's complement integer
| -128 to 127
|-
| sbyte
| SByte
| 8 bits
| signed two's complement integer
| -0 to 255
|-
| short
| Int16
| 16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| ushort
| UInt16
| 16 bits
| unsigned integer
| 0 to 65,535
|-
| int
| Int32
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| uint
| UInt32
| 32 bits
| unsigned integer
| 0 to 4,294,967,295
|-
| long
| Int64
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
| ulong
| UInt64
| 64 bits
| unsigned integer
| 0 to 18,446,744,073,709,551,615
|-
|float
| Float
| 32 bits
| single-precision IEEE 754 floating point
| -3.402823e38 to 3.02823e38
|-
| double
| Double
| 64 bits
| double-precision IEEE 754 floating point
| -1.79769313486232e308 to 1.79769313486232e308
|-
| boolean
| Boolean
| 1 bit
| boolean
| false, true
|-
| char
| Char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|-
| object
| Object
| N/A
| Object is the base type of all other types
| N/A
|-
| string
| String
| N/A
| String is the base type for a sequence of chars
| N/A
|-
| decimal
| Decimal
| 128
| Decimal is an integral type that can represent a decimal number with 29 significant digits
| ±1.0 × 10e−28 to ±7.9 × 10e28
|}

Like Java, each primitive data type in C# also has a class associated with it that. These classes serve a similar purpose to their associated ones in Java. They are used for comparison of objects, as well as conversion between other similar types.

== Primitive Objects in Ruby ==
Ruby is a pure object oriented language as compared to languages such as Java or C#, which use a more hybrid approach. In Ruby, all data types are represented as Objects. There are some [http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html inbuilt classes] that are provided to users in Ruby. However, only some of them are a basic building block for forming other types. This subset shown below gives us a list of primitive objects that can be used for data representation and manipulation:

{| border="1" style="border-spacing: 0" cellpadding="5"
! align="left"| Name
! Description
! Range
|-
| TrueClass
| Singleton instance "true" allowed
| true
|-
| FalseClass
| Singleton instance "false" allowed
| false
|-
| Integer [http://www.ruby-doc.org/core/Integer.html]
| Abstract class that forms the basis for Fixnum and Bignum
| See Fixnum and Bignum
|-
| Fixnum [http://www.ruby-doc.org/core-1.8.7/Fixnum.html]
| Integer representations that fit in native machine word
| Machine architecture dependent. 2^30-1 to -2^30 on 32-bit machines.
|-
| Bignum [http://www.ruby-doc.org/core/Bignum.html]
| Integer representations that do not fit in Fixnum width
| Machine architecture dependent. Values above Fixnum range.
|-
| Float [http://www.ruby-doc.org/core/Float.html]
| Real numbers using double precision representation
| Value after decimal point can be formatted
|-
| String [http://corelib.rubyonrails.org/classes/String.html]
| Contains sequence of characters
| No physical limit, but can be decided by machine architecture
|}

One interesting observation from the above table is that Ruby does not have a Boolean class; instead it has a separate TrueClass and FalseClass [http://www.skorks.com/2009/09/true-false-and-nil-objects-in-ruby].

puts true.class
=> TrueClass
puts false.class
=> FalseClass

Although types such as Array, Hash are also in-built types, they can be further composed of elements that are internally represented in one of the primitive types. Hence, they will not be treated by us as primitive objects, in the traditional definition of the term.
Each of the primitive objects listed above also provide certain convenience methods that are applicable for the underlying type.
For example, the Fixnum, Bignum and Float types provide support for arithmetic operations such as addition (+), subtraction(--), multiplication(*) and so on.
As with all other classes in Ruby, users can add functionality to existing primitive objects by reopening classes. The amount of memory required to implement the primitive objects in Ruby is machine dependent in some cases.

== Merit Analysis of Primitive Types ==
This section deals with a brief analysis of the relative merits and demerits of primitive data types. While we focus on Java or Ruby for this purpose, most of these points are applicable across all object oriented languages.

=== Advantages ===
Primitive types in object oriented languages have certain advantages over their class object counterparts.
* Simplicity: Primitive types/objects provide users a simple mechanism of manipulating data without relying on additional objects to achieve the same functionality. Operations on primitive types are more intuitive.
* Efficiency: This statement is applicable if the underlying primitive object definition is not modified (a feature that languages such as Ruby provide to users). As the representation in memory is designed to be make most efficient use of the underlying datatype, use of primitives can provide a benefit to the user, over the use of class objects to store the same data.
Eg. Java provides wrappers [http://www.glenmccl.com/tip_016.htm] for certain primitive types. There is a certain performance and space cost associated with these.
So, to maximize efficiency, direct use of the primitive types would provide the most benefit.
* Ability to use inbuilt methods: Depending on the primitive type, languages such as Ruby provide methods that can be used specifically to probe or manipulate objects.
Eg. [http://corelib.rubyonrails.org/classes/String.html String] primitive object provides convenience methods such as upcase to convert the entire string to upper case, or capitalize, which converts only the first character to upper case.
* Ease of testing for comparison: With primitive types, the equality testing operators such as == can be used. These essentially compare the values stored in the primitive types. Regular objects also offer the eql? method for testing equality. However, the following are not equivalent:
a=10
=> 10
a==10
=> true
a==10.0
=> true
a.eql?(10.0)
=> false
The reason the .eql? fails is that this operator tests for value and type being the same. 10 is type Fixnum and 10.0 is type Float.
The eql? can be overridden by == for primitive objects if you wish to compare only the values, but that can have a negative impact on performance [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html].

=== Disadvantages ===
* Lack of inheritance capability: The primitive data types in languages such as Java cannot be inherited to create further subtypes.
* Unexpected results due to method overriding: There are certain examples such as [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html], which show that overriding inbuilt methods such as == and eql? can lead to unexpected results.

== Conclusion ==
Object oriented languages have varying levels of support for primitive data types and objects. Whether they are beneficial or not depends on the application to a great deal. If handled correctly, they can make object oriented programs more efficient. However, the user needs to be aware of the underlying representation of these types to handle any unexpected results.

== References ==
# http://en.wikipedia.org/wiki/Primitive_data_type
# http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php
# http://www.jk-technology.com/c/inttypes.html
# http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html
# http://newty.de/fpt/intro.html
# http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
# http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx
# http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html
# http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html
# http://www.glenmccl.com/tip_016.htm
# http://www.skorks.com/2009/09/ruby-equality-and-object-comparison/

CSC/ECE 517 Fall 2011/ch3 3h rr

2011-10-29T22:00:49Z

Rbjeffer:

''3h. Primitive objects. At the beginning of Lecture 11, we discovered that Fixnums and Bignums are handled differently behind the scenes in Ruby. Other languages, like Java, have made similar distinctions. By contrast, languages such as C# and Eiffel try to hide these implementation differences from users. Answer two questions: (1) How have different o-o languages implemented primitive objects? E.g., how are they represented in memory, how are they tested for, do comparisons do anything different than for class objects, etc. (2) What are the advantages and disadvantages of treating primitives differently from class objects in source code?''

== Introduction ==
Programming languages, whether statically or dynamically typed, have support for certain in-built data types. These data types, known as primitive types, are the basic representation of information in programs and have certain fixed attributes for a specific language[http://en.wikipedia.org/wiki/Primitive_data_type]. Statically typed languages such as C++, Java, Perl etc. support primitive data types, whereas with dynamically typed languages such as Ruby, Smalltalk, Lisp etc. they are actually in the form of primitive objects. These primitive types are used to store the basic types of information that a computer can store and manipulate, and can also be used as building blocks for creating more complex data types.
This article explains the way different primitive types are implemented in certain object oriented languages. An analysis of the benefits and drawbacks of such types and the methods used to operate on them is also presented.

== Primitive Types ==
The primitive types commonly included in most programming languages are:
* Boolean
* Character
* Integer
* Floating-point number
* Fixed-point number
* Reference

=== Boolean ===
A Boolean is a primitive data type used to store one of two logical types: true or false. Boolean data types are most commonly used as input paramters to a conditional statement (such as an ‘if’ statement), or as the output of a comparison between two comparable data types. Booleans can be implemented in languages as either a discrete logical type, or implicitly as a numerical type. In many languages, booleans can be implicitly converted to and from integer types.

=== Character ===
A character is a data type that represents an element of a written language, such as a letter, number, or symbol. A character can also represent a control character, such as a carriage return or newline, which does not have a written meaning but controls how other characters are stored or displayed. Characters are commonly stored as integers, and encoded using a character map.

=== Integer ===
An integer is a data type that represents one element of a finite subset of mathematical integers. Integer, or Integral, data types can be either unsigned (able to store only positive whole numbers) or signed (able to store either positive or negative whole numbers). The range of values that can be represented by an integer depends on the number of bits used to store the integer, whether or not it is a signed integer, and the encoding scheme (if it is signed). Typically, an integer has a minimum and maximum value, and can store any integer in the range between those values. The minimum value for unsigned integers is typically 0, and the maximum value is typically determined by the amount of memory used to store the integer. For example, a un unsigned 8-bit number can store 2^8 (or 256) possible integral values; and would typically store any value from 0 to 255. More generally, an n-bit unsigned integer can store from 0 to (2^n)-1. For signed integers, modern computers use the Two’s Complement encoding scheme. This allows for a range of −2^(n−1) through 2^(n−1)−1. For example, an 8-bit signed integer could store any whole number in the range from -128 through +127.

=== Floating-Point Number ===
A floating point number is a data type used to represent real numbers in a large range with varying degrees of precision. In this representation, numbers are represented with a variable number of significant digits, and a variable number of exponential digits.

=== Fixed-Point number ===
A fixed-point number is a data type used to represent real numbers. Fixed-point numbers are called fixed-point because they have a set number of digits before and after a decimal mark. In this regard, fixed-point numbers are represented as an integer, but are scaled by a predetermined factor.

Fixed-point numbers are commonly used in microprocessors that do not have a floating-point unit, or in systems in which computational efficiency is critical. Fixed-point numbers can be treated as integers by an arithmetic logic unit (ALU) and scaled after a result is obtained, which can significantly lower the amount of time needed for a processor to obtain the result for some algorithms.

Implementing algorithms using fixed-point arithmetic requires great care, because of the potential for information loss. Fixed-point arithmetic operations -- multiplication in particular, has the potential to cause overflow. Algorithms must be written with care to ensure that each term of an equation has a similar range and that the result will not cause an overflow.

=== Reference ===

A Reference is a data type that enables a program to access another item in memory. A reference differs from other primitive data types in that it does not store data itself; instead it stores a value referring to another data object. References are commonly used to refer to objects of large non-primitive data types. References commonly store the physical memory address of the data that they are referring to. Accessing the data referred to by a Reference is called dereferencing.

== Primitive Data Types in C++ ==

C++ is a statically-typed object oriented language. C++ is based on the C programming language, which is procedural, and adds support for object-oriented code.

These data types are defined in C++: [http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php]

{| border="1" style="border-spacing: 0" cellpadding="5"
! Name
! Size
! Description
! Range
|-
| void
| N/A
| the void data type is used to explicitly identify that a data has no type
| N/A
|-
| int
| 32 bits
| simple numerical type
| See [[http://www.jk-technology.com/c/inttypes.html]]
|-
| float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 8 bits
| a char is a single 8-bit character encoded using ASCII
| Ascii character 0x00 through ascii character 0xFF
|}
C++ supports Pointers for all of the types listed in the table above, as well as more complex data types (such as structs). A Pointer in C++ is a data type that stores the physical address of some other data. Pointers are created in C++ by using the * operator. For example, a *Double[] is a pointer to an array of double-precision floating point numbers. C++ Also supports function pointers -- pointers that reference the beginning address of a function in memory. They are commonly used to implement callback functions [http://newty.de/fpt/intro.html#what]

== Primitive Data Types in Java ==

Java is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. These data types are defined in Java: [http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html]
{| border="1" style="border-spacing: 0" cellpadding="5"
! align="left"|Name
! Size
! Description
! Range
|-
|byte
|8 bits
|signed two's complement integer
|128 to 127
|-
| short
|16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| int
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| long
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
|float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|}

Java also defines a String class, which is used to create objects of many chars. The String class provides functionality commonly implemented using arrays of chars in other languages, such as C.

Java also defines the 'unsigned' keyword, which can be used to as a modifier to any of the integral types listed in the table above. If the 'unsigned' keyword is used, the integral type will be unsigned instead of signed, and its range will change correspondingly.

Java is capable of using any two objects of the same primitive data type for comparison. Java defines a class for each data type, which have the same name but a capitalized first letter (e.g. Float instead of float). These classes, called wrapper classes provide a series of methods that can manipulate their associated primitive data type, as well as convert to and from other data types.

== Primitive Data Types in C# ==

C# is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. C# has all of the data types that are available in Java, as well as some additional ones.

Similar to Java, C# defines a String class which is used to create objects of many chars. These data types are defined in C#: [http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx]

{| border="1" style="border-spacing: 0" cellpadding="5"
! align="left"| Name
! .NET Class
! width="40" | Size
! Description
! Range
|-
|byte
| Byte
| 8 bits
|signed two's complement integer
| -128 to 127
|-
| sbyte
| SByte
| 8 bits
| signed two's complement integer
| -0 to 255
|-
| short
| Int16
| 16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| ushort
| UInt16
| 16 bits
| unsigned integer
| 0 to 65,535
|-
| int
| Int32
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| uint
| UInt32
| 32 bits
| unsigned integer
| 0 to 4,294,967,295
|-
| long
| Int64
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
| ulong
| UInt64
| 64 bits
| unsigned integer
| 0 to 18,446,744,073,709,551,615
|-
|float
| Float
| 32 bits
| single-precision IEEE 754 floating point
| -3.402823e38 to 3.02823e38
|-
| double
| Double
| 64 bits
| double-precision IEEE 754 floating point
| -1.79769313486232e308 to 1.79769313486232e308
|-
| boolean
| Boolean
| 1 bit
| boolean
| false, true
|-
| char
| Char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|-
| object
| Object
| N/A
| Object is the base type of all other types
| N/A
|-
| string
| String
| N/A
| String is the base type for a sequence of chars
| N/A
|-
| decimal
| Decimal
| 128
| Decimal is an integral type that can represent a decimal number with 29 significant digits
| ±1.0 × 10e−28 to ±7.9 × 10e28
|}

Like Java, each primitive data type in C# also has a class associated with it that. These classes serve a similar purpose to their associated ones in Java. They are used for comparison of objects, as well as conversion between other similar types.

== Primitive Objects in Ruby ==
Ruby is a pure object oriented language as compared to languages such as Java or C#, which use a more hybrid approach. In Ruby, all data types are represented as Objects. There are some [http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html inbuilt classes] that are provided to users in Ruby. However, only some of them are a basic building block for forming other types. This subset shown below gives us a list of primitive objects that can be used for data representation and manipulation:

{| border="1" style="border-spacing: 0" cellpadding="5"
! align="left"| Name
! Description
! Range
|-
| TrueClass
| Singleton instance "true" allowed
| true
|-
| FalseClass
| Singleton instance "false" allowed
| false
|-
| Integer [http://www.ruby-doc.org/core/Integer.html]
| Abstract class that forms the basis for Fixnum and Bignum
| See Fixnum and Bignum
|-
| Fixnum [http://www.ruby-doc.org/core-1.8.7/Fixnum.html]
| Integer representations that fit in native machine word
| Machine architecture dependent. 2^30-1 to -2^30 on 32-bit machines.
|-
| Bignum [http://www.ruby-doc.org/core/Bignum.html]
| Integer representations that do not fit in Fixnum width
| Machine architecture dependent. Values above Fixnum range.
|-
| Float [http://www.ruby-doc.org/core/Float.html]
| Real numbers using double precision representation
| Value after decimal point can be formatted
|-
| String [http://corelib.rubyonrails.org/classes/String.html]
| Contains sequence of characters
| No physical limit, but can be decided by machine architecture
|}

One interesting observation from the above table is that Ruby does not have a Boolean class; instead it has a separate TrueClass and FalseClass [http://www.skorks.com/2009/09/true-false-and-nil-objects-in-ruby].

puts true.class
=> TrueClass
puts false.class
=> FalseClass

Although types such as Array, Hash are also in-built types, they can be further composed of elements that are internally represented in one of the primitive types. Hence, they will not be treated by us as primitive objects, in the traditional definition of the term.
Each of the primitive objects listed above also provide certain convenience methods that are applicable for the underlying type.
For example, the Fixnum, Bignum and Float types provide support for arithmetic operations such as addition (+), subtraction(--), multiplication(*) and so on.
As with all other classes in Ruby, users can add functionality to existing primitive objects by reopening classes. The amount of memory required to implement the primitive objects in Ruby is machine dependent in some cases.

== Merit Analysis of Primitive Types ==
This section deals with a brief analysis of the relative merits and demerits of primitive data types. While we focus on Java or Ruby for this purpose, most of these points are applicable across all object oriented languages.

=== Advantages ===
Primitive types in object oriented languages have certain advantages over their class object counterparts.
* Simplicity: Primitive types/objects provide users a simple mechanism of manipulating data without relying on additional objects to achieve the same functionality. Operations on primitive types are more intuitive.
* Efficiency: This statement is applicable if the underlying primitive object definition is not modified (a feature that languages such as Ruby provide to users). As the representation in memory is designed to be make most efficient use of the underlying datatype, use of primitives can provide a benefit to the user, over the use of class objects to store the same data.
Eg. Java provides wrappers [http://www.glenmccl.com/tip_016.htm] for certain primitive types. There is a certain performance and space cost associated with these.
So, to maximize efficiency, direct use of the primitive types would provide the most benefit.
* Ability to use inbuilt methods: Depending on the primitive type, languages such as Ruby provide methods that can be used specifically to probe or manipulate objects.
Eg. [http://corelib.rubyonrails.org/classes/String.html String] primitive object provides convenience methods such as upcase to convert the entire string to upper case, or capitalize, which converts only the first character to upper case.
* Ease of testing for comparison: With primitive types, the equality testing operators such as == can be used. These essentially compare the values stored in the primitive types. Regular objects also offer the eql? method for testing equality. However, the following are not equivalent:
a=10
=> 10
a==10
=> true
a==10.0
=> true
a.eql?(10.0)
=> false
The reason the .eql? fails is that this operator tests for value and type being the same. 10 is type Fixnum and 10.0 is type Float.
The eql? can be overridden by == for primitive objects if you wish to compare only the values, but that can have a negative impact on performance [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html].

=== Disadvantages ===
* Lack of inheritance capability: The primitive data types in languages such as Java cannot be inherited to create further subtypes.
* Unexpected results due to method overriding: There are certain examples such as [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html], which show that overriding inbuilt methods such as == and eql? can lead to unexpected results.

== Conclusion ==
Object oriented languages have varying levels of support for primitive data types and objects. Whether they are beneficial or not depends on the application to a great deal. If handled correctly, they can make object oriented programs more efficient. However, the user needs to be aware of the underlying representation of these types to handle any unexpected results.

== References ==
# http://en.wikipedia.org/wiki/Primitive_data_type
# http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php
# http://www.jk-technology.com/c/inttypes.html
# http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html
# http://newty.de/fpt/intro.html
# http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
# http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx
# http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html
# http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html
# http://www.glenmccl.com/tip_016.htm
# http://www.skorks.com/2009/09/ruby-equality-and-object-comparison/

CSC/ECE 517 Fall 2011/ch3 3h rr

2011-10-29T21:59:54Z

Rbjeffer:

''3h. Primitive objects. At the beginning of Lecture 11, we discovered that Fixnums and Bignums are handled differently behind the scenes in Ruby. Other languages, like Java, have made similar distinctions. By contrast, languages such as C# and Eiffel try to hide these implementation differences from users. Answer two questions: (1) How have different o-o languages implemented primitive objects? E.g., how are they represented in memory, how are they tested for, do comparisons do anything different than for class objects, etc. (2) What are the advantages and disadvantages of treating primitives differently from class objects in source code?''

== Introduction ==
Programming languages, whether statically or dynamically typed, have support for certain in-built data types. These data types, known as primitive types, are the basic representation of information in programs and have certain fixed attributes for a specific language[http://en.wikipedia.org/wiki/Primitive_data_type]. Statically typed languages such as C++, Java, Perl etc. support primitive data types, whereas with dynamically typed languages such as Ruby, Smalltalk, Lisp etc. they are actually in the form of primitive objects. These primitive types are used to store the basic types of information that a computer can store and manipulate, and can also be used as building blocks for creating more complex data types.
This article explains the way different primitive types are implemented in certain object oriented languages. An analysis of the benefits and drawbacks of such types and the methods used to operate on them is also presented.

== Primitive Types ==
The primitive types commonly included in most programming languages are:
* Boolean
* Character
* Integer
* Floating-point number
* Fixed-point number
* Reference

=== Boolean ===
A Boolean is a primitive data type used to store one of two logical types: true or false. Boolean data types are most commonly used as input paramters to a conditional statement (such as an ‘if’ statement), or as the output of a comparison between two comparable data types. Booleans can be implemented in languages as either a discrete logical type, or implicitly as a numerical type. In many languages, booleans can be implicitly converted to and from integer types.

=== Character ===
A character is a data type that represents an element of a written language, such as a letter, number, or symbol. A character can also represent a control character, such as a carriage return or newline, which does not have a written meaning but controls how other characters are stored or displayed. Characters are commonly stored as integers, and encoded using a character map.

=== Integer ===
An integer is a data type that represents one element of a finite subset of mathematical integers. Integer, or Integral, data types can be either unsigned (able to store only positive whole numbers) or signed (able to store either positive or negative whole numbers). The range of values that can be represented by an integer depends on the number of bits used to store the integer, whether or not it is a signed integer, and the encoding scheme (if it is signed). Typically, an integer has a minimum and maximum value, and can store any integer in the range between those values. The minimum value for unsigned integers is typically 0, and the maximum value is typically determined by the amount of memory used to store the integer. For example, a un unsigned 8-bit number can store 2^8 (or 256) possible integral values; and would typically store any value from 0 to 255. More generally, an n-bit unsigned integer can store from 0 to (2^n)-1. For signed integers, modern computers use the Two’s Complement encoding scheme. This allows for a range of −2^(n−1) through 2^(n−1)−1. For example, an 8-bit signed integer could store any whole number in the range from -128 through +127.

=== Floating-Point Number ===
A floating point number is a data type used to represent real numbers in a large range with varying degrees of precision. In this representation, numbers are represented with a variable number of significant digits, and a variable number of exponential digits.

=== Fixed-Point number ===
A fixed-point number is a data type used to represent real numbers. Fixed-point numbers are called fixed-point because they have a set number of digits before and after a decimal mark. In this regard, fixed-point numbers are represented as an integer, but are scaled by a predetermined factor.

Fixed-point numbers are commonly used in microprocessors that do not have a floating-point unit, or in systems in which computational efficiency is critical. Fixed-point numbers can be treated as integers by an arithmetic logic unit (ALU) and scaled after a result is obtained, which can significantly lower the amount of time needed for a processor to obtain the result for some algorithms.

Implementing algorithms using fixed-point arithmetic requires great care, because of the potential for information loss. Fixed-point arithmetic operations -- multiplication in particular, has the potential to cause overflow. Algorithms must be written with care to ensure that each term of an equation has a similar range and that the result will not cause an overflow.

=== Reference ===

A Reference is a data type that enables a program to access another item in memory. A reference differs from other primitive data types in that it does not store data itself; instead it stores a value referring to another data object. References are commonly used to refer to objects of large non-primitive data types. References commonly store the physical memory address of the data that they are referring to. Accessing the data referred to by a Reference is called dereferencing.

== Primitive Data Types in C++ ==

C++ is a statically-typed object oriented language. C++ is based on the C programming language, which is procedural, and adds support for object-oriented code.

These data types are defined in C++: [http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php]

{| border="1" style="border-spacing: 0" cellpadding="5"
! Name
! Size
! Description
! Range
|-
| void
| N/A
| the void data type is used to explicitly identify that a data has no type
| N/A
|-
| int
| 32 bits
| simple numerical type
| See [[http://www.jk-technology.com/c/inttypes.html]]
|-
| float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 8 bits
| a char is a single 8-bit character encoded using ASCII
| Ascii character 0x00 through ascii character 0xFF
|}
C++ supports Pointers for all of the types listed in the table above, as well as more complex data types (such as structs). A Pointer in C++ is a data type that stores the physical address of some other data. Pointers are created in C++ by using the * operator. For example, a *Double[] is a pointer to an array of double-precision floating point numbers. C++ Also supports function pointers -- pointers that reference the beginning address of a function in memory. They are commonly used to implement callback functions [http://newty.de/fpt/intro.html#what]

== Primitive Data Types in Java ==

Java is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. These data types are defined in Java: [http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html]
{| border="1" style="border-spacing: 0" cellpadding="5"
! align="left"|Name
! Size
! Description
! Range
|-
|byte
|8 bits
|signed two's complement integer
|128 to 127
|-
| short
|16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| int
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| long
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
|float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|}

Java also defines a String class, which is used to create objects of many chars. The String class provides functionality commonly implemented using arrays of chars in other languages, such as C.

Java also defines the 'unsigned' keyword, which can be used to as a modifier to any of the integral types listed in the table above. If the 'unsigned' keyword is used, the integral type will be unsigned instead of signed, and its range will change correspondingly.

Java is capable of using any two objects of the same primitive data type for comparison. Java defines a class for each data type, which have the same name but a capitalized first letter (e.g. Float instead of float). These classes, called wrapper classes provide a series of methods that can manipulate their associated primitive data type, as well as convert to and from other data types.

== Primitive Data Types in C# ==

C# is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. C# has all of the data types that are available in Java, as well as some additional ones.

Similar to Java, C# defines a String class which is used to create objects of many chars. These data types are defined in C#: [http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx]

{| border="1" style="border-spacing: 0" cellpadding="5"
! align="left"| Name
! .NET Class
! Size
! Description
! Range
|-
|byte
| Byte
| 8 bits
|signed two's complement integer
| -128 to 127
|-
| sbyte
| SByte
| 8 bits
| signed two's complement integer
| -0 to 255
|-
| short
| Int16
| 16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| ushort
| UInt16
| 16 bits
| unsigned integer
| 0 to 65,535
|-
| int
| Int32
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| uint
| UInt32
| 32 bits
| unsigned integer
| 0 to 4,294,967,295
|-
| long
| Int64
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
| ulong
| UInt64
| 64 bits
| unsigned integer
| 0 to 18,446,744,073,709,551,615
|-
|float
| Float
| 32 bits
| single-precision IEEE 754 floating point
| -3.402823e38 to 3.02823e38
|-
| double
| Double
| 64 bits
| double-precision IEEE 754 floating point
| -1.79769313486232e308 to 1.79769313486232e308
|-
| boolean
| Boolean
| 1 bit
| boolean
| false, true
|-
| char
| Char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|-
| object
| Object
| N/A
| Object is the base type of all other types
| N/A
|-
| string
| String
| N/A
| String is the base type for a sequence of chars
| N/A
|-
| decimal
| Decimal
| 128
| Decimal is an integral type that can represent a decimal number with 29 significant digits
| ±1.0 × 10e−28 to ±7.9 × 10e28
|}

Like Java, each primitive data type in C# also has a class associated with it that. These classes serve a similar purpose to their associated ones in Java. They are used for comparison of objects, as well as conversion between other similar types.

== Primitive Objects in Ruby ==
Ruby is a pure object oriented language as compared to languages such as Java or C#, which use a more hybrid approach. In Ruby, all data types are represented as Objects. There are some [http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html inbuilt classes] that are provided to users in Ruby. However, only some of them are a basic building block for forming other types. This subset shown below gives us a list of primitive objects that can be used for data representation and manipulation:

{| border="1" style="border-spacing: 0" cellpadding="5"
! align="left"| Name
! Description
! Range
|-
| TrueClass
| Singleton instance "true" allowed
| true
|-
| FalseClass
| Singleton instance "false" allowed
| false
|-
| Integer [http://www.ruby-doc.org/core/Integer.html]
| Abstract class that forms the basis for Fixnum and Bignum
| See Fixnum and Bignum
|-
| Fixnum [http://www.ruby-doc.org/core-1.8.7/Fixnum.html]
| Integer representations that fit in native machine word
| Machine architecture dependent. 2^30-1 to -2^30 on 32-bit machines.
|-
| Bignum [http://www.ruby-doc.org/core/Bignum.html]
| Integer representations that do not fit in Fixnum width
| Machine architecture dependent. Values above Fixnum range.
|-
| Float [http://www.ruby-doc.org/core/Float.html]
| Real numbers using double precision representation
| Value after decimal point can be formatted
|-
| String [http://corelib.rubyonrails.org/classes/String.html]
| Contains sequence of characters
| No physical limit, but can be decided by machine architecture
|}

One interesting observation from the above table is that Ruby does not have a Boolean class; instead it has a separate TrueClass and FalseClass [http://www.skorks.com/2009/09/true-false-and-nil-objects-in-ruby].

puts true.class
=> TrueClass
puts false.class
=> FalseClass

Although types such as Array, Hash are also in-built types, they can be further composed of elements that are internally represented in one of the primitive types. Hence, they will not be treated by us as primitive objects, in the traditional definition of the term.
Each of the primitive objects listed above also provide certain convenience methods that are applicable for the underlying type.
For example, the Fixnum, Bignum and Float types provide support for arithmetic operations such as addition (+), subtraction(--), multiplication(*) and so on.
As with all other classes in Ruby, users can add functionality to existing primitive objects by reopening classes. The amount of memory required to implement the primitive objects in Ruby is machine dependent in some cases.

== Merit Analysis of Primitive Types ==
This section deals with a brief analysis of the relative merits and demerits of primitive data types. While we focus on Java or Ruby for this purpose, most of these points are applicable across all object oriented languages.

=== Advantages ===
Primitive types in object oriented languages have certain advantages over their class object counterparts.
* Simplicity: Primitive types/objects provide users a simple mechanism of manipulating data without relying on additional objects to achieve the same functionality. Operations on primitive types are more intuitive.
* Efficiency: This statement is applicable if the underlying primitive object definition is not modified (a feature that languages such as Ruby provide to users). As the representation in memory is designed to be make most efficient use of the underlying datatype, use of primitives can provide a benefit to the user, over the use of class objects to store the same data.
Eg. Java provides wrappers [http://www.glenmccl.com/tip_016.htm] for certain primitive types. There is a certain performance and space cost associated with these.
So, to maximize efficiency, direct use of the primitive types would provide the most benefit.
* Ability to use inbuilt methods: Depending on the primitive type, languages such as Ruby provide methods that can be used specifically to probe or manipulate objects.
Eg. [http://corelib.rubyonrails.org/classes/String.html String] primitive object provides convenience methods such as upcase to convert the entire string to upper case, or capitalize, which converts only the first character to upper case.
* Ease of testing for comparison: With primitive types, the equality testing operators such as == can be used. These essentially compare the values stored in the primitive types. Regular objects also offer the eql? method for testing equality. However, the following are not equivalent:
a=10
=> 10
a==10
=> true
a==10.0
=> true
a.eql?(10.0)
=> false
The reason the .eql? fails is that this operator tests for value and type being the same. 10 is type Fixnum and 10.0 is type Float.
The eql? can be overridden by == for primitive objects if you wish to compare only the values, but that can have a negative impact on performance [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html].

=== Disadvantages ===
* Lack of inheritance capability: The primitive data types in languages such as Java cannot be inherited to create further subtypes.
* Unexpected results due to method overriding: There are certain examples such as [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html], which show that overriding inbuilt methods such as == and eql? can lead to unexpected results.

== Conclusion ==
Object oriented languages have varying levels of support for primitive data types and objects. Whether they are beneficial or not depends on the application to a great deal. If handled correctly, they can make object oriented programs more efficient. However, the user needs to be aware of the underlying representation of these types to handle any unexpected results.

== References ==
# http://en.wikipedia.org/wiki/Primitive_data_type
# http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php
# http://www.jk-technology.com/c/inttypes.html
# http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html
# http://newty.de/fpt/intro.html
# http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
# http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx
# http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html
# http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html
# http://www.glenmccl.com/tip_016.htm
# http://www.skorks.com/2009/09/ruby-equality-and-object-comparison/

CSC/ECE 517 Fall 2011/ch3 3h rr

2011-10-29T21:59:22Z

Rbjeffer:

''3h. Primitive objects. At the beginning of Lecture 11, we discovered that Fixnums and Bignums are handled differently behind the scenes in Ruby. Other languages, like Java, have made similar distinctions. By contrast, languages such as C# and Eiffel try to hide these implementation differences from users. Answer two questions: (1) How have different o-o languages implemented primitive objects? E.g., how are they represented in memory, how are they tested for, do comparisons do anything different than for class objects, etc. (2) What are the advantages and disadvantages of treating primitives differently from class objects in source code?''

== Introduction ==
Programming languages, whether statically or dynamically typed, have support for certain in-built data types. These data types, known as primitive types, are the basic representation of information in programs and have certain fixed attributes for a specific language[http://en.wikipedia.org/wiki/Primitive_data_type]. Statically typed languages such as C++, Java, Perl etc. support primitive data types, whereas with dynamically typed languages such as Ruby, Smalltalk, Lisp etc. they are actually in the form of primitive objects. These primitive types are used to store the basic types of information that a computer can store and manipulate, and can also be used as building blocks for creating more complex data types.
This article explains the way different primitive types are implemented in certain object oriented languages. An analysis of the benefits and drawbacks of such types and the methods used to operate on them is also presented.

== Primitive Types ==
The primitive types commonly included in most programming languages are:
* Boolean
* Character
* Integer
* Floating-point number
* Fixed-point number
* Reference

=== Boolean ===
A Boolean is a primitive data type used to store one of two logical types: true or false. Boolean data types are most commonly used as input paramters to a conditional statement (such as an ‘if’ statement), or as the output of a comparison between two comparable data types. Booleans can be implemented in languages as either a discrete logical type, or implicitly as a numerical type. In many languages, booleans can be implicitly converted to and from integer types.

=== Character ===
A character is a data type that represents an element of a written language, such as a letter, number, or symbol. A character can also represent a control character, such as a carriage return or newline, which does not have a written meaning but controls how other characters are stored or displayed. Characters are commonly stored as integers, and encoded using a character map.

=== Integer ===
An integer is a data type that represents one element of a finite subset of mathematical integers. Integer, or Integral, data types can be either unsigned (able to store only positive whole numbers) or signed (able to store either positive or negative whole numbers). The range of values that can be represented by an integer depends on the number of bits used to store the integer, whether or not it is a signed integer, and the encoding scheme (if it is signed). Typically, an integer has a minimum and maximum value, and can store any integer in the range between those values. The minimum value for unsigned integers is typically 0, and the maximum value is typically determined by the amount of memory used to store the integer. For example, a un unsigned 8-bit number can store 2^8 (or 256) possible integral values; and would typically store any value from 0 to 255. More generally, an n-bit unsigned integer can store from 0 to (2^n)-1. For signed integers, modern computers use the Two’s Complement encoding scheme. This allows for a range of −2^(n−1) through 2^(n−1)−1. For example, an 8-bit signed integer could store any whole number in the range from -128 through +127.

=== Floating-Point Number ===
A floating point number is a data type used to represent real numbers in a large range with varying degrees of precision. In this representation, numbers are represented with a variable number of significant digits, and a variable number of exponential digits.

=== Fixed-Point number ===
A fixed-point number is a data type used to represent real numbers. Fixed-point numbers are called fixed-point because they have a set number of digits before and after a decimal mark. In this regard, fixed-point numbers are represented as an integer, but are scaled by a predetermined factor.

Fixed-point numbers are commonly used in microprocessors that do not have a floating-point unit, or in systems in which computational efficiency is critical. Fixed-point numbers can be treated as integers by an arithmetic logic unit (ALU) and scaled after a result is obtained, which can significantly lower the amount of time needed for a processor to obtain the result for some algorithms.

Implementing algorithms using fixed-point arithmetic requires great care, because of the potential for information loss. Fixed-point arithmetic operations -- multiplication in particular, has the potential to cause overflow. Algorithms must be written with care to ensure that each term of an equation has a similar range and that the result will not cause an overflow.

=== Reference ===

A Reference is a data type that enables a program to access another item in memory. A reference differs from other primitive data types in that it does not store data itself; instead it stores a value referring to another data object. References are commonly used to refer to objects of large non-primitive data types. References commonly store the physical memory address of the data that they are referring to. Accessing the data referred to by a Reference is called dereferencing.

== Primitive Data Types in C++ ==

C++ is a statically-typed object oriented language. C++ is based on the C programming language, which is procedural, and adds support for object-oriented code.

These data types are defined in C++: [http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php]

{| border="1" style="border-spacing: 0" cellpadding="20"
! Name
! Size
! Description
! Range
|-
| void
| N/A
| the void data type is used to explicitly identify that a data has no type
| N/A
|-
| int
| 32 bits
| simple numerical type
| See [[http://www.jk-technology.com/c/inttypes.html]]
|-
| float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 8 bits
| a char is a single 8-bit character encoded using ASCII
| Ascii character 0x00 through ascii character 0xFF
|}
C++ supports Pointers for all of the types listed in the table above, as well as more complex data types (such as structs). A Pointer in C++ is a data type that stores the physical address of some other data. Pointers are created in C++ by using the * operator. For example, a *Double[] is a pointer to an array of double-precision floating point numbers. C++ Also supports function pointers -- pointers that reference the beginning address of a function in memory. They are commonly used to implement callback functions [http://newty.de/fpt/intro.html#what]

== Primitive Data Types in Java ==

Java is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. These data types are defined in Java: [http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html]
{| border="1" style="border-spacing: 0"
! align="left"|Name
! Size
! Description
! Range
|-
|byte
|8 bits
|signed two's complement integer
|128 to 127
|-
| short
|16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| int
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| long
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
|float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|}

Java also defines a String class, which is used to create objects of many chars. The String class provides functionality commonly implemented using arrays of chars in other languages, such as C.

Java also defines the 'unsigned' keyword, which can be used to as a modifier to any of the integral types listed in the table above. If the 'unsigned' keyword is used, the integral type will be unsigned instead of signed, and its range will change correspondingly.

Java is capable of using any two objects of the same primitive data type for comparison. Java defines a class for each data type, which have the same name but a capitalized first letter (e.g. Float instead of float). These classes, called wrapper classes provide a series of methods that can manipulate their associated primitive data type, as well as convert to and from other data types.

== Primitive Data Types in C# ==

C# is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. C# has all of the data types that are available in Java, as well as some additional ones.

Similar to Java, C# defines a String class which is used to create objects of many chars. These data types are defined in C#: [http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx]

{| border="1" style="border-spacing: 0"
! align="left"| Name
! .NET Class
! Size
! Description
! Range
|-
|byte
| Byte
| 8 bits
|signed two's complement integer
| -128 to 127
|-
| sbyte
| SByte
| 8 bits
| signed two's complement integer
| -0 to 255
|-
| short
| Int16
| 16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| ushort
| UInt16
| 16 bits
| unsigned integer
| 0 to 65,535
|-
| int
| Int32
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| uint
| UInt32
| 32 bits
| unsigned integer
| 0 to 4,294,967,295
|-
| long
| Int64
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
| ulong
| UInt64
| 64 bits
| unsigned integer
| 0 to 18,446,744,073,709,551,615
|-
|float
| Float
| 32 bits
| single-precision IEEE 754 floating point
| -3.402823e38 to 3.02823e38
|-
| double
| Double
| 64 bits
| double-precision IEEE 754 floating point
| -1.79769313486232e308 to 1.79769313486232e308
|-
| boolean
| Boolean
| 1 bit
| boolean
| false, true
|-
| char
| Char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|-
| object
| Object
| N/A
| Object is the base type of all other types
| N/A
|-
| string
| String
| N/A
| String is the base type for a sequence of chars
| N/A
|-
| decimal
| Decimal
| 128
| Decimal is an integral type that can represent a decimal number with 29 significant digits
| ±1.0 × 10e−28 to ±7.9 × 10e28
|}

Like Java, each primitive data type in C# also has a class associated with it that. These classes serve a similar purpose to their associated ones in Java. They are used for comparison of objects, as well as conversion between other similar types.

== Primitive Objects in Ruby ==
Ruby is a pure object oriented language as compared to languages such as Java or C#, which use a more hybrid approach. In Ruby, all data types are represented as Objects. There are some [http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html inbuilt classes] that are provided to users in Ruby. However, only some of them are a basic building block for forming other types. This subset shown below gives us a list of primitive objects that can be used for data representation and manipulation:

{| border="1" style="border-spacing: 0"
! align="left"| Name
! Description
! Range
|-
| TrueClass
| Singleton instance "true" allowed
| true
|-
| FalseClass
| Singleton instance "false" allowed
| false
|-
| Integer [http://www.ruby-doc.org/core/Integer.html]
| Abstract class that forms the basis for Fixnum and Bignum
| See Fixnum and Bignum
|-
| Fixnum [http://www.ruby-doc.org/core-1.8.7/Fixnum.html]
| Integer representations that fit in native machine word
| Machine architecture dependent. 2^30-1 to -2^30 on 32-bit machines.
|-
| Bignum [http://www.ruby-doc.org/core/Bignum.html]
| Integer representations that do not fit in Fixnum width
| Machine architecture dependent. Values above Fixnum range.
|-
| Float [http://www.ruby-doc.org/core/Float.html]
| Real numbers using double precision representation
| Value after decimal point can be formatted
|-
| String [http://corelib.rubyonrails.org/classes/String.html]
| Contains sequence of characters
| No physical limit, but can be decided by machine architecture
|}

One interesting observation from the above table is that Ruby does not have a Boolean class; instead it has a separate TrueClass and FalseClass [http://www.skorks.com/2009/09/true-false-and-nil-objects-in-ruby].

puts true.class
=> TrueClass
puts false.class
=> FalseClass

Although types such as Array, Hash are also in-built types, they can be further composed of elements that are internally represented in one of the primitive types. Hence, they will not be treated by us as primitive objects, in the traditional definition of the term.
Each of the primitive objects listed above also provide certain convenience methods that are applicable for the underlying type.
For example, the Fixnum, Bignum and Float types provide support for arithmetic operations such as addition (+), subtraction(--), multiplication(*) and so on.
As with all other classes in Ruby, users can add functionality to existing primitive objects by reopening classes. The amount of memory required to implement the primitive objects in Ruby is machine dependent in some cases.

== Merit Analysis of Primitive Types ==
This section deals with a brief analysis of the relative merits and demerits of primitive data types. While we focus on Java or Ruby for this purpose, most of these points are applicable across all object oriented languages.

=== Advantages ===
Primitive types in object oriented languages have certain advantages over their class object counterparts.
* Simplicity: Primitive types/objects provide users a simple mechanism of manipulating data without relying on additional objects to achieve the same functionality. Operations on primitive types are more intuitive.
* Efficiency: This statement is applicable if the underlying primitive object definition is not modified (a feature that languages such as Ruby provide to users). As the representation in memory is designed to be make most efficient use of the underlying datatype, use of primitives can provide a benefit to the user, over the use of class objects to store the same data.
Eg. Java provides wrappers [http://www.glenmccl.com/tip_016.htm] for certain primitive types. There is a certain performance and space cost associated with these.
So, to maximize efficiency, direct use of the primitive types would provide the most benefit.
* Ability to use inbuilt methods: Depending on the primitive type, languages such as Ruby provide methods that can be used specifically to probe or manipulate objects.
Eg. [http://corelib.rubyonrails.org/classes/String.html String] primitive object provides convenience methods such as upcase to convert the entire string to upper case, or capitalize, which converts only the first character to upper case.
* Ease of testing for comparison: With primitive types, the equality testing operators such as == can be used. These essentially compare the values stored in the primitive types. Regular objects also offer the eql? method for testing equality. However, the following are not equivalent:
a=10
=> 10
a==10
=> true
a==10.0
=> true
a.eql?(10.0)
=> false
The reason the .eql? fails is that this operator tests for value and type being the same. 10 is type Fixnum and 10.0 is type Float.
The eql? can be overridden by == for primitive objects if you wish to compare only the values, but that can have a negative impact on performance [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html].

=== Disadvantages ===
* Lack of inheritance capability: The primitive data types in languages such as Java cannot be inherited to create further subtypes.
* Unexpected results due to method overriding: There are certain examples such as [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html], which show that overriding inbuilt methods such as == and eql? can lead to unexpected results.

== Conclusion ==
Object oriented languages have varying levels of support for primitive data types and objects. Whether they are beneficial or not depends on the application to a great deal. If handled correctly, they can make object oriented programs more efficient. However, the user needs to be aware of the underlying representation of these types to handle any unexpected results.

== References ==
# http://en.wikipedia.org/wiki/Primitive_data_type
# http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php
# http://www.jk-technology.com/c/inttypes.html
# http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html
# http://newty.de/fpt/intro.html
# http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
# http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx
# http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html
# http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html
# http://www.glenmccl.com/tip_016.htm
# http://www.skorks.com/2009/09/ruby-equality-and-object-comparison/

CSC/ECE 517 Fall 2011/ch3 3h rr

2011-10-29T21:58:57Z

Rbjeffer:

''3h. Primitive objects. At the beginning of Lecture 11, we discovered that Fixnums and Bignums are handled differently behind the scenes in Ruby. Other languages, like Java, have made similar distinctions. By contrast, languages such as C# and Eiffel try to hide these implementation differences from users. Answer two questions: (1) How have different o-o languages implemented primitive objects? E.g., how are they represented in memory, how are they tested for, do comparisons do anything different than for class objects, etc. (2) What are the advantages and disadvantages of treating primitives differently from class objects in source code?''

== Introduction ==
Programming languages, whether statically or dynamically typed, have support for certain in-built data types. These data types, known as primitive types, are the basic representation of information in programs and have certain fixed attributes for a specific language[http://en.wikipedia.org/wiki/Primitive_data_type]. Statically typed languages such as C++, Java, Perl etc. support primitive data types, whereas with dynamically typed languages such as Ruby, Smalltalk, Lisp etc. they are actually in the form of primitive objects. These primitive types are used to store the basic types of information that a computer can store and manipulate, and can also be used as building blocks for creating more complex data types.
This article explains the way different primitive types are implemented in certain object oriented languages. An analysis of the benefits and drawbacks of such types and the methods used to operate on them is also presented.

== Primitive Types ==
The primitive types commonly included in most programming languages are:
* Boolean
* Character
* Integer
* Floating-point number
* Fixed-point number
* Reference

=== Boolean ===
A Boolean is a primitive data type used to store one of two logical types: true or false. Boolean data types are most commonly used as input paramters to a conditional statement (such as an ‘if’ statement), or as the output of a comparison between two comparable data types. Booleans can be implemented in languages as either a discrete logical type, or implicitly as a numerical type. In many languages, booleans can be implicitly converted to and from integer types.

=== Character ===
A character is a data type that represents an element of a written language, such as a letter, number, or symbol. A character can also represent a control character, such as a carriage return or newline, which does not have a written meaning but controls how other characters are stored or displayed. Characters are commonly stored as integers, and encoded using a character map.

=== Integer ===
An integer is a data type that represents one element of a finite subset of mathematical integers. Integer, or Integral, data types can be either unsigned (able to store only positive whole numbers) or signed (able to store either positive or negative whole numbers). The range of values that can be represented by an integer depends on the number of bits used to store the integer, whether or not it is a signed integer, and the encoding scheme (if it is signed). Typically, an integer has a minimum and maximum value, and can store any integer in the range between those values. The minimum value for unsigned integers is typically 0, and the maximum value is typically determined by the amount of memory used to store the integer. For example, a un unsigned 8-bit number can store 2^8 (or 256) possible integral values; and would typically store any value from 0 to 255. More generally, an n-bit unsigned integer can store from 0 to (2^n)-1. For signed integers, modern computers use the Two’s Complement encoding scheme. This allows for a range of −2^(n−1) through 2^(n−1)−1. For example, an 8-bit signed integer could store any whole number in the range from -128 through +127.

=== Floating-Point Number ===
A floating point number is a data type used to represent real numbers in a large range with varying degrees of precision. In this representation, numbers are represented with a variable number of significant digits, and a variable number of exponential digits.

=== Fixed-Point number ===
A fixed-point number is a data type used to represent real numbers. Fixed-point numbers are called fixed-point because they have a set number of digits before and after a decimal mark. In this regard, fixed-point numbers are represented as an integer, but are scaled by a predetermined factor.

Fixed-point numbers are commonly used in microprocessors that do not have a floating-point unit, or in systems in which computational efficiency is critical. Fixed-point numbers can be treated as integers by an arithmetic logic unit (ALU) and scaled after a result is obtained, which can significantly lower the amount of time needed for a processor to obtain the result for some algorithms.

Implementing algorithms using fixed-point arithmetic requires great care, because of the potential for information loss. Fixed-point arithmetic operations -- multiplication in particular, has the potential to cause overflow. Algorithms must be written with care to ensure that each term of an equation has a similar range and that the result will not cause an overflow.

=== Reference ===

A Reference is a data type that enables a program to access another item in memory. A reference differs from other primitive data types in that it does not store data itself; instead it stores a value referring to another data object. References are commonly used to refer to objects of large non-primitive data types. References commonly store the physical memory address of the data that they are referring to. Accessing the data referred to by a Reference is called dereferencing.

== Primitive Data Types in C++ ==

C++ is a statically-typed object oriented language. C++ is based on the C programming language, which is procedural, and adds support for object-oriented code.

These data types are defined in C++: [http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php]

{| border="1" style="border-spacing: 0" cellpadding="2"
! Name
! Size
! Description
! Range
|-
| void
| N/A
| the void data type is used to explicitly identify that a data has no type
| N/A
|-
| int
| 32 bits
| simple numerical type
| See [[http://www.jk-technology.com/c/inttypes.html]]
|-
| float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 8 bits
| a char is a single 8-bit character encoded using ASCII
| Ascii character 0x00 through ascii character 0xFF
|}
C++ supports Pointers for all of the types listed in the table above, as well as more complex data types (such as structs). A Pointer in C++ is a data type that stores the physical address of some other data. Pointers are created in C++ by using the * operator. For example, a *Double[] is a pointer to an array of double-precision floating point numbers. C++ Also supports function pointers -- pointers that reference the beginning address of a function in memory. They are commonly used to implement callback functions [http://newty.de/fpt/intro.html#what]

== Primitive Data Types in Java ==

Java is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. These data types are defined in Java: [http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html]
{| border="1" style="border-spacing: 0"
! align="left"|Name
! Size
! Description
! Range
|-
|byte
|8 bits
|signed two's complement integer
|128 to 127
|-
| short
|16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| int
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| long
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
|float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|}

Java also defines a String class, which is used to create objects of many chars. The String class provides functionality commonly implemented using arrays of chars in other languages, such as C.

Java also defines the 'unsigned' keyword, which can be used to as a modifier to any of the integral types listed in the table above. If the 'unsigned' keyword is used, the integral type will be unsigned instead of signed, and its range will change correspondingly.

Java is capable of using any two objects of the same primitive data type for comparison. Java defines a class for each data type, which have the same name but a capitalized first letter (e.g. Float instead of float). These classes, called wrapper classes provide a series of methods that can manipulate their associated primitive data type, as well as convert to and from other data types.

== Primitive Data Types in C# ==

C# is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. C# has all of the data types that are available in Java, as well as some additional ones.

Similar to Java, C# defines a String class which is used to create objects of many chars. These data types are defined in C#: [http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx]

{| border="1" style="border-spacing: 0"
! align="left"| Name
! .NET Class
! Size
! Description
! Range
|-
|byte
| Byte
| 8 bits
|signed two's complement integer
| -128 to 127
|-
| sbyte
| SByte
| 8 bits
| signed two's complement integer
| -0 to 255
|-
| short
| Int16
| 16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| ushort
| UInt16
| 16 bits
| unsigned integer
| 0 to 65,535
|-
| int
| Int32
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| uint
| UInt32
| 32 bits
| unsigned integer
| 0 to 4,294,967,295
|-
| long
| Int64
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
| ulong
| UInt64
| 64 bits
| unsigned integer
| 0 to 18,446,744,073,709,551,615
|-
|float
| Float
| 32 bits
| single-precision IEEE 754 floating point
| -3.402823e38 to 3.02823e38
|-
| double
| Double
| 64 bits
| double-precision IEEE 754 floating point
| -1.79769313486232e308 to 1.79769313486232e308
|-
| boolean
| Boolean
| 1 bit
| boolean
| false, true
|-
| char
| Char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|-
| object
| Object
| N/A
| Object is the base type of all other types
| N/A
|-
| string
| String
| N/A
| String is the base type for a sequence of chars
| N/A
|-
| decimal
| Decimal
| 128
| Decimal is an integral type that can represent a decimal number with 29 significant digits
| ±1.0 × 10e−28 to ±7.9 × 10e28
|}

Like Java, each primitive data type in C# also has a class associated with it that. These classes serve a similar purpose to their associated ones in Java. They are used for comparison of objects, as well as conversion between other similar types.

== Primitive Objects in Ruby ==
Ruby is a pure object oriented language as compared to languages such as Java or C#, which use a more hybrid approach. In Ruby, all data types are represented as Objects. There are some [http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html inbuilt classes] that are provided to users in Ruby. However, only some of them are a basic building block for forming other types. This subset shown below gives us a list of primitive objects that can be used for data representation and manipulation:

{| border="1" style="border-spacing: 0"
! align="left"| Name
! Description
! Range
|-
| TrueClass
| Singleton instance "true" allowed
| true
|-
| FalseClass
| Singleton instance "false" allowed
| false
|-
| Integer [http://www.ruby-doc.org/core/Integer.html]
| Abstract class that forms the basis for Fixnum and Bignum
| See Fixnum and Bignum
|-
| Fixnum [http://www.ruby-doc.org/core-1.8.7/Fixnum.html]
| Integer representations that fit in native machine word
| Machine architecture dependent. 2^30-1 to -2^30 on 32-bit machines.
|-
| Bignum [http://www.ruby-doc.org/core/Bignum.html]
| Integer representations that do not fit in Fixnum width
| Machine architecture dependent. Values above Fixnum range.
|-
| Float [http://www.ruby-doc.org/core/Float.html]
| Real numbers using double precision representation
| Value after decimal point can be formatted
|-
| String [http://corelib.rubyonrails.org/classes/String.html]
| Contains sequence of characters
| No physical limit, but can be decided by machine architecture
|}

One interesting observation from the above table is that Ruby does not have a Boolean class; instead it has a separate TrueClass and FalseClass [http://www.skorks.com/2009/09/true-false-and-nil-objects-in-ruby].

puts true.class
=> TrueClass
puts false.class
=> FalseClass

Although types such as Array, Hash are also in-built types, they can be further composed of elements that are internally represented in one of the primitive types. Hence, they will not be treated by us as primitive objects, in the traditional definition of the term.
Each of the primitive objects listed above also provide certain convenience methods that are applicable for the underlying type.
For example, the Fixnum, Bignum and Float types provide support for arithmetic operations such as addition (+), subtraction(--), multiplication(*) and so on.
As with all other classes in Ruby, users can add functionality to existing primitive objects by reopening classes. The amount of memory required to implement the primitive objects in Ruby is machine dependent in some cases.

== Merit Analysis of Primitive Types ==
This section deals with a brief analysis of the relative merits and demerits of primitive data types. While we focus on Java or Ruby for this purpose, most of these points are applicable across all object oriented languages.

=== Advantages ===
Primitive types in object oriented languages have certain advantages over their class object counterparts.
* Simplicity: Primitive types/objects provide users a simple mechanism of manipulating data without relying on additional objects to achieve the same functionality. Operations on primitive types are more intuitive.
* Efficiency: This statement is applicable if the underlying primitive object definition is not modified (a feature that languages such as Ruby provide to users). As the representation in memory is designed to be make most efficient use of the underlying datatype, use of primitives can provide a benefit to the user, over the use of class objects to store the same data.
Eg. Java provides wrappers [http://www.glenmccl.com/tip_016.htm] for certain primitive types. There is a certain performance and space cost associated with these.
So, to maximize efficiency, direct use of the primitive types would provide the most benefit.
* Ability to use inbuilt methods: Depending on the primitive type, languages such as Ruby provide methods that can be used specifically to probe or manipulate objects.
Eg. [http://corelib.rubyonrails.org/classes/String.html String] primitive object provides convenience methods such as upcase to convert the entire string to upper case, or capitalize, which converts only the first character to upper case.
* Ease of testing for comparison: With primitive types, the equality testing operators such as == can be used. These essentially compare the values stored in the primitive types. Regular objects also offer the eql? method for testing equality. However, the following are not equivalent:
a=10
=> 10
a==10
=> true
a==10.0
=> true
a.eql?(10.0)
=> false
The reason the .eql? fails is that this operator tests for value and type being the same. 10 is type Fixnum and 10.0 is type Float.
The eql? can be overridden by == for primitive objects if you wish to compare only the values, but that can have a negative impact on performance [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html].

=== Disadvantages ===
* Lack of inheritance capability: The primitive data types in languages such as Java cannot be inherited to create further subtypes.
* Unexpected results due to method overriding: There are certain examples such as [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html], which show that overriding inbuilt methods such as == and eql? can lead to unexpected results.

== Conclusion ==
Object oriented languages have varying levels of support for primitive data types and objects. Whether they are beneficial or not depends on the application to a great deal. If handled correctly, they can make object oriented programs more efficient. However, the user needs to be aware of the underlying representation of these types to handle any unexpected results.

== References ==
# http://en.wikipedia.org/wiki/Primitive_data_type
# http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php
# http://www.jk-technology.com/c/inttypes.html
# http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html
# http://newty.de/fpt/intro.html
# http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
# http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx
# http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html
# http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html
# http://www.glenmccl.com/tip_016.htm
# http://www.skorks.com/2009/09/ruby-equality-and-object-comparison/

CSC/ECE 517 Fall 2011/ch3 3h rr

2011-10-29T21:58:17Z

Rbjeffer:

''3h. Primitive objects. At the beginning of Lecture 11, we discovered that Fixnums and Bignums are handled differently behind the scenes in Ruby. Other languages, like Java, have made similar distinctions. By contrast, languages such as C# and Eiffel try to hide these implementation differences from users. Answer two questions: (1) How have different o-o languages implemented primitive objects? E.g., how are they represented in memory, how are they tested for, do comparisons do anything different than for class objects, etc. (2) What are the advantages and disadvantages of treating primitives differently from class objects in source code?''

== Introduction ==
Programming languages, whether statically or dynamically typed, have support for certain in-built data types. These data types, known as primitive types, are the basic representation of information in programs and have certain fixed attributes for a specific language[http://en.wikipedia.org/wiki/Primitive_data_type]. Statically typed languages such as C++, Java, Perl etc. support primitive data types, whereas with dynamically typed languages such as Ruby, Smalltalk, Lisp etc. they are actually in the form of primitive objects. These primitive types are used to store the basic types of information that a computer can store and manipulate, and can also be used as building blocks for creating more complex data types.
This article explains the way different primitive types are implemented in certain object oriented languages. An analysis of the benefits and drawbacks of such types and the methods used to operate on them is also presented.

== Primitive Types ==
The primitive types commonly included in most programming languages are:
* Boolean
* Character
* Integer
* Floating-point number
* Fixed-point number
* Reference

=== Boolean ===
A Boolean is a primitive data type used to store one of two logical types: true or false. Boolean data types are most commonly used as input paramters to a conditional statement (such as an ‘if’ statement), or as the output of a comparison between two comparable data types. Booleans can be implemented in languages as either a discrete logical type, or implicitly as a numerical type. In many languages, booleans can be implicitly converted to and from integer types.

=== Character ===
A character is a data type that represents an element of a written language, such as a letter, number, or symbol. A character can also represent a control character, such as a carriage return or newline, which does not have a written meaning but controls how other characters are stored or displayed. Characters are commonly stored as integers, and encoded using a character map.

=== Integer ===
An integer is a data type that represents one element of a finite subset of mathematical integers. Integer, or Integral, data types can be either unsigned (able to store only positive whole numbers) or signed (able to store either positive or negative whole numbers). The range of values that can be represented by an integer depends on the number of bits used to store the integer, whether or not it is a signed integer, and the encoding scheme (if it is signed). Typically, an integer has a minimum and maximum value, and can store any integer in the range between those values. The minimum value for unsigned integers is typically 0, and the maximum value is typically determined by the amount of memory used to store the integer. For example, a un unsigned 8-bit number can store 2^8 (or 256) possible integral values; and would typically store any value from 0 to 255. More generally, an n-bit unsigned integer can store from 0 to (2^n)-1. For signed integers, modern computers use the Two’s Complement encoding scheme. This allows for a range of −2^(n−1) through 2^(n−1)−1. For example, an 8-bit signed integer could store any whole number in the range from -128 through +127.

=== Floating-Point Number ===
A floating point number is a data type used to represent real numbers in a large range with varying degrees of precision. In this representation, numbers are represented with a variable number of significant digits, and a variable number of exponential digits.

=== Fixed-Point number ===
A fixed-point number is a data type used to represent real numbers. Fixed-point numbers are called fixed-point because they have a set number of digits before and after a decimal mark. In this regard, fixed-point numbers are represented as an integer, but are scaled by a predetermined factor.

Fixed-point numbers are commonly used in microprocessors that do not have a floating-point unit, or in systems in which computational efficiency is critical. Fixed-point numbers can be treated as integers by an arithmetic logic unit (ALU) and scaled after a result is obtained, which can significantly lower the amount of time needed for a processor to obtain the result for some algorithms.

Implementing algorithms using fixed-point arithmetic requires great care, because of the potential for information loss. Fixed-point arithmetic operations -- multiplication in particular, has the potential to cause overflow. Algorithms must be written with care to ensure that each term of an equation has a similar range and that the result will not cause an overflow.

=== Reference ===

A Reference is a data type that enables a program to access another item in memory. A reference differs from other primitive data types in that it does not store data itself; instead it stores a value referring to another data object. References are commonly used to refer to objects of large non-primitive data types. References commonly store the physical memory address of the data that they are referring to. Accessing the data referred to by a Reference is called dereferencing.

== Primitive Data Types in C++ ==

C++ is a statically-typed object oriented language. C++ is based on the C programming language, which is procedural, and adds support for object-oriented code.

These data types are defined in C++: [http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php]

{| border="1" style="border-spacing: 0; cellpadding=2"
! Name
! Size
! Description
! Range
|-
| void
| N/A
| the void data type is used to explicitly identify that a data has no type
| N/A
|-
| int
| 32 bits
| simple numerical type
| See [[http://www.jk-technology.com/c/inttypes.html]]
|-
| float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 8 bits
| a char is a single 8-bit character encoded using ASCII
| Ascii character 0x00 through ascii character 0xFF
|}
C++ supports Pointers for all of the types listed in the table above, as well as more complex data types (such as structs). A Pointer in C++ is a data type that stores the physical address of some other data. Pointers are created in C++ by using the * operator. For example, a *Double[] is a pointer to an array of double-precision floating point numbers. C++ Also supports function pointers -- pointers that reference the beginning address of a function in memory. They are commonly used to implement callback functions [http://newty.de/fpt/intro.html#what]

== Primitive Data Types in Java ==

Java is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. These data types are defined in Java: [http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html]
{| border="1" style="border-spacing: 0"
! align="left"|Name
! Size
! Description
! Range
|-
|byte
|8 bits
|signed two's complement integer
|128 to 127
|-
| short
|16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| int
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| long
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
|float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|}

Java also defines a String class, which is used to create objects of many chars. The String class provides functionality commonly implemented using arrays of chars in other languages, such as C.

Java also defines the 'unsigned' keyword, which can be used to as a modifier to any of the integral types listed in the table above. If the 'unsigned' keyword is used, the integral type will be unsigned instead of signed, and its range will change correspondingly.

Java is capable of using any two objects of the same primitive data type for comparison. Java defines a class for each data type, which have the same name but a capitalized first letter (e.g. Float instead of float). These classes, called wrapper classes provide a series of methods that can manipulate their associated primitive data type, as well as convert to and from other data types.

== Primitive Data Types in C# ==

C# is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. C# has all of the data types that are available in Java, as well as some additional ones.

Similar to Java, C# defines a String class which is used to create objects of many chars. These data types are defined in C#: [http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx]

{| border="1" style="border-spacing: 0"
! align="left"| Name
! .NET Class
! Size
! Description
! Range
|-
|byte
| Byte
| 8 bits
|signed two's complement integer
| -128 to 127
|-
| sbyte
| SByte
| 8 bits
| signed two's complement integer
| -0 to 255
|-
| short
| Int16
| 16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| ushort
| UInt16
| 16 bits
| unsigned integer
| 0 to 65,535
|-
| int
| Int32
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| uint
| UInt32
| 32 bits
| unsigned integer
| 0 to 4,294,967,295
|-
| long
| Int64
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
| ulong
| UInt64
| 64 bits
| unsigned integer
| 0 to 18,446,744,073,709,551,615
|-
|float
| Float
| 32 bits
| single-precision IEEE 754 floating point
| -3.402823e38 to 3.02823e38
|-
| double
| Double
| 64 bits
| double-precision IEEE 754 floating point
| -1.79769313486232e308 to 1.79769313486232e308
|-
| boolean
| Boolean
| 1 bit
| boolean
| false, true
|-
| char
| Char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|-
| object
| Object
| N/A
| Object is the base type of all other types
| N/A
|-
| string
| String
| N/A
| String is the base type for a sequence of chars
| N/A
|-
| decimal
| Decimal
| 128
| Decimal is an integral type that can represent a decimal number with 29 significant digits
| ±1.0 × 10e−28 to ±7.9 × 10e28
|}

Like Java, each primitive data type in C# also has a class associated with it that. These classes serve a similar purpose to their associated ones in Java. They are used for comparison of objects, as well as conversion between other similar types.

== Primitive Objects in Ruby ==
Ruby is a pure object oriented language as compared to languages such as Java or C#, which use a more hybrid approach. In Ruby, all data types are represented as Objects. There are some [http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html inbuilt classes] that are provided to users in Ruby. However, only some of them are a basic building block for forming other types. This subset shown below gives us a list of primitive objects that can be used for data representation and manipulation:

{| border="1" style="border-spacing: 0"
! align="left"| Name
! Description
! Range
|-
| TrueClass
| Singleton instance "true" allowed
| true
|-
| FalseClass
| Singleton instance "false" allowed
| false
|-
| Integer [http://www.ruby-doc.org/core/Integer.html]
| Abstract class that forms the basis for Fixnum and Bignum
| See Fixnum and Bignum
|-
| Fixnum [http://www.ruby-doc.org/core-1.8.7/Fixnum.html]
| Integer representations that fit in native machine word
| Machine architecture dependent. 2^30-1 to -2^30 on 32-bit machines.
|-
| Bignum [http://www.ruby-doc.org/core/Bignum.html]
| Integer representations that do not fit in Fixnum width
| Machine architecture dependent. Values above Fixnum range.
|-
| Float [http://www.ruby-doc.org/core/Float.html]
| Real numbers using double precision representation
| Value after decimal point can be formatted
|-
| String [http://corelib.rubyonrails.org/classes/String.html]
| Contains sequence of characters
| No physical limit, but can be decided by machine architecture
|}

One interesting observation from the above table is that Ruby does not have a Boolean class; instead it has a separate TrueClass and FalseClass [http://www.skorks.com/2009/09/true-false-and-nil-objects-in-ruby].

puts true.class
=> TrueClass
puts false.class
=> FalseClass

Although types such as Array, Hash are also in-built types, they can be further composed of elements that are internally represented in one of the primitive types. Hence, they will not be treated by us as primitive objects, in the traditional definition of the term.
Each of the primitive objects listed above also provide certain convenience methods that are applicable for the underlying type.
For example, the Fixnum, Bignum and Float types provide support for arithmetic operations such as addition (+), subtraction(--), multiplication(*) and so on.
As with all other classes in Ruby, users can add functionality to existing primitive objects by reopening classes. The amount of memory required to implement the primitive objects in Ruby is machine dependent in some cases.

== Merit Analysis of Primitive Types ==
This section deals with a brief analysis of the relative merits and demerits of primitive data types. While we focus on Java or Ruby for this purpose, most of these points are applicable across all object oriented languages.

=== Advantages ===
Primitive types in object oriented languages have certain advantages over their class object counterparts.
* Simplicity: Primitive types/objects provide users a simple mechanism of manipulating data without relying on additional objects to achieve the same functionality. Operations on primitive types are more intuitive.
* Efficiency: This statement is applicable if the underlying primitive object definition is not modified (a feature that languages such as Ruby provide to users). As the representation in memory is designed to be make most efficient use of the underlying datatype, use of primitives can provide a benefit to the user, over the use of class objects to store the same data.
Eg. Java provides wrappers [http://www.glenmccl.com/tip_016.htm] for certain primitive types. There is a certain performance and space cost associated with these.
So, to maximize efficiency, direct use of the primitive types would provide the most benefit.
* Ability to use inbuilt methods: Depending on the primitive type, languages such as Ruby provide methods that can be used specifically to probe or manipulate objects.
Eg. [http://corelib.rubyonrails.org/classes/String.html String] primitive object provides convenience methods such as upcase to convert the entire string to upper case, or capitalize, which converts only the first character to upper case.
* Ease of testing for comparison: With primitive types, the equality testing operators such as == can be used. These essentially compare the values stored in the primitive types. Regular objects also offer the eql? method for testing equality. However, the following are not equivalent:
a=10
=> 10
a==10
=> true
a==10.0
=> true
a.eql?(10.0)
=> false
The reason the .eql? fails is that this operator tests for value and type being the same. 10 is type Fixnum and 10.0 is type Float.
The eql? can be overridden by == for primitive objects if you wish to compare only the values, but that can have a negative impact on performance [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html].

=== Disadvantages ===
* Lack of inheritance capability: The primitive data types in languages such as Java cannot be inherited to create further subtypes.
* Unexpected results due to method overriding: There are certain examples such as [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html], which show that overriding inbuilt methods such as == and eql? can lead to unexpected results.

== Conclusion ==
Object oriented languages have varying levels of support for primitive data types and objects. Whether they are beneficial or not depends on the application to a great deal. If handled correctly, they can make object oriented programs more efficient. However, the user needs to be aware of the underlying representation of these types to handle any unexpected results.

== References ==
# http://en.wikipedia.org/wiki/Primitive_data_type
# http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php
# http://www.jk-technology.com/c/inttypes.html
# http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html
# http://newty.de/fpt/intro.html
# http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
# http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx
# http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html
# http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html
# http://www.glenmccl.com/tip_016.htm
# http://www.skorks.com/2009/09/ruby-equality-and-object-comparison/

CSC/ECE 517 Fall 2011/ch3 3h rr

2011-10-29T21:55:14Z

Rbjeffer:

''3h. Primitive objects. At the beginning of Lecture 11, we discovered that Fixnums and Bignums are handled differently behind the scenes in Ruby. Other languages, like Java, have made similar distinctions. By contrast, languages such as C# and Eiffel try to hide these implementation differences from users. Answer two questions: (1) How have different o-o languages implemented primitive objects? E.g., how are they represented in memory, how are they tested for, do comparisons do anything different than for class objects, etc. (2) What are the advantages and disadvantages of treating primitives differently from class objects in source code?''

== Introduction ==
Programming languages, whether statically or dynamically typed, have support for certain in-built data types. These data types, known as primitive types, are the basic representation of information in programs and have certain fixed attributes for a specific language[http://en.wikipedia.org/wiki/Primitive_data_type]. Statically typed languages such as C++, Java, Perl etc. support primitive data types, whereas with dynamically typed languages such as Ruby, Smalltalk, Lisp etc. they are actually in the form of primitive objects. These primitive types are used to store the basic types of information that a computer can store and manipulate, and can also be used as building blocks for creating more complex data types.
This article explains the way different primitive types are implemented in certain object oriented languages. An analysis of the benefits and drawbacks of such types and the methods used to operate on them is also presented.

== Primitive Types ==
The primitive types commonly included in most programming languages are:
* Boolean
* Character
* Integer
* Floating-point number
* Fixed-point number
* Reference

=== Boolean ===
A Boolean is a primitive data type used to store one of two logical types: true or false. Boolean data types are most commonly used as input paramters to a conditional statement (such as an ‘if’ statement), or as the output of a comparison between two comparable data types. Booleans can be implemented in languages as either a discrete logical type, or implicitly as a numerical type. In many languages, booleans can be implicitly converted to and from integer types.

=== Character ===
A character is a data type that represents an element of a written language, such as a letter, number, or symbol. A character can also represent a control character, such as a carriage return or newline, which does not have a written meaning but controls how other characters are stored or displayed. Characters are commonly stored as integers, and encoded using a character map.

=== Integer ===
An integer is a data type that represents one element of a finite subset of mathematical integers. Integer, or Integral, data types can be either unsigned (able to store only positive whole numbers) or signed (able to store either positive or negative whole numbers). The range of values that can be represented by an integer depends on the number of bits used to store the integer, whether or not it is a signed integer, and the encoding scheme (if it is signed). Typically, an integer has a minimum and maximum value, and can store any integer in the range between those values. The minimum value for unsigned integers is typically 0, and the maximum value is typically determined by the amount of memory used to store the integer. For example, a un unsigned 8-bit number can store 2^8 (or 256) possible integral values; and would typically store any value from 0 to 255. More generally, an n-bit unsigned integer can store from 0 to (2^n)-1. For signed integers, modern computers use the Two’s Complement encoding scheme. This allows for a range of −2^(n−1) through 2^(n−1)−1. For example, an 8-bit signed integer could store any whole number in the range from -128 through +127.

=== Floating-Point Number ===
A floating point number is a data type used to represent real numbers in a large range with varying degrees of precision. In this representation, numbers are represented with a variable number of significant digits, and a variable number of exponential digits.

=== Fixed-Point number ===
A fixed-point number is a data type used to represent real numbers. Fixed-point numbers are called fixed-point because they have a set number of digits before and after a decimal mark. In this regard, fixed-point numbers are represented as an integer, but are scaled by a predetermined factor.

Fixed-point numbers are commonly used in microprocessors that do not have a floating-point unit, or in systems in which computational efficiency is critical. Fixed-point numbers can be treated as integers by an arithmetic logic unit (ALU) and scaled after a result is obtained, which can significantly lower the amount of time needed for a processor to obtain the result for some algorithms.

Implementing algorithms using fixed-point arithmetic requires great care, because of the potential for information loss. Fixed-point arithmetic operations -- multiplication in particular, has the potential to cause overflow. Algorithms must be written with care to ensure that each term of an equation has a similar range and that the result will not cause an overflow.

=== Reference ===

A Reference is a data type that enables a program to access another item in memory. A reference differs from other primitive data types in that it does not store data itself; instead it stores a value referring to another data object. References are commonly used to refer to objects of large non-primitive data types. References commonly store the physical memory address of the data that they are referring to. Accessing the data referred to by a Reference is called dereferencing.

== Primitive Data Types in C++ ==

C++ is a statically-typed object oriented language. C++ is based on the C programming language, which is procedural, and adds support for object-oriented code.

These data types are defined in C++: [http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php]

{| border="1" style="border-spacing: 0"
! Name
! Size
! Description
! Range
|-
| void
| N/A
| the void data type is used to explicitly identify that a data has no type
| N/A
|-
| int
| 32 bits
| simple numerical type
| See [[http://www.jk-technology.com/c/inttypes.html]]
|-
| float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 8 bits
| a char is a single 8-bit character encoded using ASCII
| Ascii character 0x00 through ascii character 0xFF
|}
C++ supports Pointers for all of the types listed in the table above, as well as more complex data types (such as structs). A Pointer in C++ is a data type that stores the physical address of some other data. Pointers are created in C++ by using the * operator. For example, a *Double[] is a pointer to an array of double-precision floating point numbers. C++ Also supports function pointers -- pointers that reference the beginning address of a function in memory. They are commonly used to implement callback functions [http://newty.de/fpt/intro.html#what]

== Primitive Data Types in Java ==

Java is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. These data types are defined in Java: [http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html]
{| border="1" style="border-spacing: 0"
! align="left"|Name
! Size
! Description
! Range
|-
|byte
|8 bits
|signed two's complement integer
|128 to 127
|-
| short
|16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| int
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| long
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
|float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|}

Java also defines a String class, which is used to create objects of many chars. The String class provides functionality commonly implemented using arrays of chars in other languages, such as C.

Java also defines the 'unsigned' keyword, which can be used to as a modifier to any of the integral types listed in the table above. If the 'unsigned' keyword is used, the integral type will be unsigned instead of signed, and its range will change correspondingly.

Java is capable of using any two objects of the same primitive data type for comparison. Java defines a class for each data type, which have the same name but a capitalized first letter (e.g. Float instead of float). These classes, called wrapper classes provide a series of methods that can manipulate their associated primitive data type, as well as convert to and from other data types.

== Primitive Data Types in C# ==

C# is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. C# has all of the data types that are available in Java, as well as some additional ones.

Similar to Java, C# defines a String class which is used to create objects of many chars. These data types are defined in C#: [http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx]

{| border="1" style="border-spacing: 0"
! align="left"| Name
! .NET Class
! Size
! Description
! Range
|-
|byte
| Byte
| 8 bits
|signed two's complement integer
| -128 to 127
|-
| sbyte
| SByte
| 8 bits
| signed two's complement integer
| -0 to 255
|-
| short
| Int16
| 16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| ushort
| UInt16
| 16 bits
| unsigned integer
| 0 to 65,535
|-
| int
| Int32
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| uint
| UInt32
| 32 bits
| unsigned integer
| 0 to 4,294,967,295
|-
| long
| Int64
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
| ulong
| UInt64
| 64 bits
| unsigned integer
| 0 to 18,446,744,073,709,551,615
|-
|float
| Float
| 32 bits
| single-precision IEEE 754 floating point
| -3.402823e38 to 3.02823e38
|-
| double
| Double
| 64 bits
| double-precision IEEE 754 floating point
| -1.79769313486232e308 to 1.79769313486232e308
|-
| boolean
| Boolean
| 1 bit
| boolean
| false, true
|-
| char
| Char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|-
| object
| Object
| N/A
| Object is the base type of all other types
| N/A
|-
| string
| String
| N/A
| String is the base type for a sequence of chars
| N/A
|-
| decimal
| Decimal
| 128
| Decimal is an integral type that can represent a decimal number with 29 significant digits
| ±1.0 × 10e−28 to ±7.9 × 10e28
|}

Like Java, each primitive data type in C# also has a class associated with it that. These classes serve a similar purpose to their associated ones in Java. They are used for comparison of objects, as well as conversion between other similar types.

== Primitive Objects in Ruby ==
Ruby is a pure object oriented language as compared to languages such as Java or C#, which use a more hybrid approach. In Ruby, all data types are represented as Objects. There are some [http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html inbuilt classes] that are provided to users in Ruby. However, only some of them are a basic building block for forming other types. This subset shown below gives us a list of primitive objects that can be used for data representation and manipulation:

{| border="1" style="border-spacing: 0"
! align="left"| Name
! Description
! Range
|-
| TrueClass
| Singleton instance "true" allowed
| true
|-
| FalseClass
| Singleton instance "false" allowed
| false
|-
| Integer [http://www.ruby-doc.org/core/Integer.html]
| Abstract class that forms the basis for Fixnum and Bignum
| See Fixnum and Bignum
|-
| Fixnum [http://www.ruby-doc.org/core-1.8.7/Fixnum.html]
| Integer representations that fit in native machine word
| Machine architecture dependent. 2^30-1 to -2^30 on 32-bit machines.
|-
| Bignum [http://www.ruby-doc.org/core/Bignum.html]
| Integer representations that do not fit in Fixnum width
| Machine architecture dependent. Values above Fixnum range.
|-
| Float [http://www.ruby-doc.org/core/Float.html]
| Real numbers using double precision representation
| Value after decimal point can be formatted
|-
| String [http://corelib.rubyonrails.org/classes/String.html]
| Contains sequence of characters
| No physical limit, but can be decided by machine architecture
|}

One interesting observation from the above table is that Ruby does not have a Boolean class; instead it has a separate TrueClass and FalseClass [http://www.skorks.com/2009/09/true-false-and-nil-objects-in-ruby].

puts true.class
=> TrueClass
puts false.class
=> FalseClass

Although types such as Array, Hash are also in-built types, they can be further composed of elements that are internally represented in one of the primitive types. Hence, they will not be treated by us as primitive objects, in the traditional definition of the term.
Each of the primitive objects listed above also provide certain convenience methods that are applicable for the underlying type.
For example, the Fixnum, Bignum and Float types provide support for arithmetic operations such as addition (+), subtraction(--), multiplication(*) and so on.
As with all other classes in Ruby, users can add functionality to existing primitive objects by reopening classes. The amount of memory required to implement the primitive objects in Ruby is machine dependent in some cases.

== Merit Analysis of Primitive Types ==
This section deals with a brief analysis of the relative merits and demerits of primitive data types. While we focus on Java or Ruby for this purpose, most of these points are applicable across all object oriented languages.

=== Advantages ===
Primitive types in object oriented languages have certain advantages over their class object counterparts.
* Simplicity: Primitive types/objects provide users a simple mechanism of manipulating data without relying on additional objects to achieve the same functionality. Operations on primitive types are more intuitive.
* Efficiency: This statement is applicable if the underlying primitive object definition is not modified (a feature that languages such as Ruby provide to users). As the representation in memory is designed to be make most efficient use of the underlying datatype, use of primitives can provide a benefit to the user, over the use of class objects to store the same data.
Eg. Java provides wrappers [http://www.glenmccl.com/tip_016.htm] for certain primitive types. There is a certain performance and space cost associated with these.
So, to maximize efficiency, direct use of the primitive types would provide the most benefit.
* Ability to use inbuilt methods: Depending on the primitive type, languages such as Ruby provide methods that can be used specifically to probe or manipulate objects.
Eg. [http://corelib.rubyonrails.org/classes/String.html String] primitive object provides convenience methods such as upcase to convert the entire string to upper case, or capitalize, which converts only the first character to upper case.
* Ease of testing for comparison: With primitive types, the equality testing operators such as == can be used. These essentially compare the values stored in the primitive types. Regular objects also offer the eql? method for testing equality. However, the following are not equivalent:
a=10
=> 10
a==10
=> true
a==10.0
=> true
a.eql?(10.0)
=> false
The reason the .eql? fails is that this operator tests for value and type being the same. 10 is type Fixnum and 10.0 is type Float.
The eql? can be overridden by == for primitive objects if you wish to compare only the values, but that can have a negative impact on performance [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html].

=== Disadvantages ===
* Lack of inheritance capability: The primitive data types in languages such as Java cannot be inherited to create further subtypes.
* Unexpected results due to method overriding: There are certain examples such as [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html], which show that overriding inbuilt methods such as == and eql? can lead to unexpected results.

== Conclusion ==
Object oriented languages have varying levels of support for primitive data types and objects. Whether they are beneficial or not depends on the application to a great deal. If handled correctly, they can make object oriented programs more efficient. However, the user needs to be aware of the underlying representation of these types to handle any unexpected results.

== References ==
# http://en.wikipedia.org/wiki/Primitive_data_type
# http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php
# http://www.jk-technology.com/c/inttypes.html
# http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html
# http://newty.de/fpt/intro.html
# http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
# http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx
# http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html
# http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html
# http://www.glenmccl.com/tip_016.htm
# http://www.skorks.com/2009/09/ruby-equality-and-object-comparison/

CSC/ECE 517 Fall 2011/ch3 3h rr

2011-10-29T21:54:18Z

Rbjeffer:

''3h. Primitive objects. At the beginning of Lecture 11, we discovered that Fixnums and Bignums are handled differently behind the scenes in Ruby. Other languages, like Java, have made similar distinctions. By contrast, languages such as C# and Eiffel try to hide these implementation differences from users. Answer two questions: (1) How have different o-o languages implemented primitive objects? E.g., how are they represented in memory, how are they tested for, do comparisons do anything different than for class objects, etc. (2) What are the advantages and disadvantages of treating primitives differently from class objects in source code?''

== Introduction ==
Programming languages, whether statically or dynamically typed, have support for certain in-built data types. These data types, known as primitive types, are the basic representation of information in programs and have certain fixed attributes for a specific language[http://en.wikipedia.org/wiki/Primitive_data_type]. Statically typed languages such as C++, Java, Perl etc. support primitive data types, whereas with dynamically typed languages such as Ruby, Smalltalk, Lisp etc. they are actually in the form of primitive objects. These primitive types are used to store the basic types of information that a computer can store and manipulate, and can also be used as building blocks for creating more complex data types.
This article explains the way different primitive types are implemented in certain object oriented languages. An analysis of the benefits and drawbacks of such types and the methods used to operate on them is also presented.

== Primitive Types ==
The primitive types commonly included in most programming languages are:
* Boolean
* Character
* Integer
* Floating-point number
* Fixed-point number
* Reference

=== Boolean ===
A Boolean is a primitive data type used to store one of two logical types: true or false. Boolean data types are most commonly used as input paramters to a conditional statement (such as an ‘if’ statement), or as the output of a comparison between two comparable data types. Booleans can be implemented in languages as either a discrete logical type, or implicitly as a numerical type. In many languages, booleans can be implicitly converted to and from integer types.

=== Character ===
A character is a data type that represents an element of a written language, such as a letter, number, or symbol. A character can also represent a control character, such as a carriage return or newline, which does not have a written meaning but controls how other characters are stored or displayed. Characters are commonly stored as integers, and encoded using a character map.

=== Integer ===
An integer is a data type that represents one element of a finite subset of mathematical integers. Integer, or Integral, data types can be either unsigned (able to store only positive whole numbers) or signed (able to store either positive or negative whole numbers). The range of values that can be represented by an integer depends on the number of bits used to store the integer, whether or not it is a signed integer, and the encoding scheme (if it is signed). Typically, an integer has a minimum and maximum value, and can store any integer in the range between those values. The minimum value for unsigned integers is typically 0, and the maximum value is typically determined by the amount of memory used to store the integer. For example, a un unsigned 8-bit number can store 2^8 (or 256) possible integral values; and would typically store any value from 0 to 255. More generally, an n-bit unsigned integer can store from 0 to (2^n)-1. For signed integers, modern computers use the Two’s Complement encoding scheme. This allows for a range of −2^(n−1) through 2^(n−1)−1. For example, an 8-bit signed integer could store any whole number in the range from -128 through +127.

=== Floating-Point Number ===
A floating point number is a data type used to represent real numbers in a large range with varying degrees of precision. In this representation, numbers are represented with a variable number of significant digits, and a variable number of exponential digits.

=== Fixed-Point number ===
A fixed-point number is a data type used to represent real numbers. Fixed-point numbers are called fixed-point because they have a set number of digits before and after a decimal mark. In this regard, fixed-point numbers are represented as an integer, but are scaled by a predetermined factor.

Fixed-point numbers are commonly used in microprocessors that do not have a floating-point unit, or in systems in which computational efficiency is critical. Fixed-point numbers can be treated as integers by an arithmetic logic unit (ALU) and scaled after a result is obtained, which can significantly lower the amount of time needed for a processor to obtain the result for some algorithms.

Implementing algorithms using fixed-point arithmetic requires great care, because of the potential for information loss. Fixed-point arithmetic operations -- multiplication in particular, has the potential to cause overflow. Algorithms must be written with care to ensure that each term of an equation has a similar range and that the result will not cause an overflow.

=== Reference ===

A Reference is a data type that enables a program to access another item in memory. A reference differs from other primitive data types in that it does not store data itself; instead it stores a value referring to another data object. References are commonly used to refer to objects of large non-primitive data types. References commonly store the physical memory address of the data that they are referring to. Accessing the data referred to by a Reference is called dereferencing.

== Primitive Data Types in C++ ==

C++ is a statically-typed object oriented language. C++ is based on the C programming language, which is procedural, and adds support for object-oriented code.

These data types are defined in C++: [http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php]

{| border="1" style="border-spacing: 0"
! Name
! Size
! Description
! Range
|-
| void
| N/A
| the void data type is used to explicitly identify that a data has no type
| N/A
|-
| int
| 32 bits
| simple numerical type
| See [[http://www.jk-technology.com/c/inttypes.html]]
|-
| float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 8 bits
| a char is a single 8-bit character encoded using ASCII
| Ascii character 0x00 through ascii character 0xFF
|}
C++ supports Pointers for all of the types listed in the table above, as well as more complex data types (such as structs). A Pointer in C++ is a data type that stores the physical address of some other data. Pointers are created in C++ by using the * operator. For example, a *Double[] is a pointer to an array of double-precision floating point numbers. C++ Also supports function pointers -- pointers that reference the beginning address of a function in memory. They are commonly used to implement callback functions [http://newty.de/fpt/intro.html#what]

== Primitive Data Types in Java ==

Java is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. These data types are defined in Java: [http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html]
{| border="1" style="border-spacing: 0"
! align="left"|Name
! Size
! Description
! Range
|-
|byte
|8 bits
|signed two's complement integer
|128 to 127
|-
| short
|16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| int
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| long
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
|float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|}

Java also defines a String class, which is used to create objects of many chars. The String class provides functionality commonly implemented using arrays of chars in other languages, such as C.

Java also defines the 'unsigned' keyword, which can be used to as a modifier to any of the integral types listed in the table above. If the 'unsigned' keyword is used, the integral type will be unsigned instead of signed, and its range will change correspondingly.

Java is capable of using any two objects of the same primitive data type for comparison. Java defines a class for each data type, which have the same name but a capitalized first letter (e.g. Float instead of float). These classes, called wrapper classes provide a series of methods that can manipulate their associated primitive data type, as well as convert to and from other data types.

== Primitive Data Types in C# ==

C# is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. C# has all of the data types that are available in Java, as well as some additional ones.

Similar to Java, C# defines a String class which is used to create objects of many chars. These data types are defined in C#: [http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx]

{| border="1" style="border-spacing: 0"
! align="left"| Name
! .NET Class
! Size
! Description
! Range
|-
|byte
| Byte
| 8 bits
|signed two's complement integer
| -128 to 127
|-
| sbyte
| SByte
| 8 bits
| signed two's complement integer
| -0 to 255
|-
| short
| Int16
| 16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| ushort
| UInt16
| 16 bits
| unsigned integer
| 0 to 65,535
|-
| int
| Int32
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| uint
| UInt32
| 32 bits
| unsigned integer
| 0 to 4,294,967,295
|-
| long
| Int64
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
| ulong
| UInt64
| 64 bits
| unsigned integer
| 0 to 18,446,744,073,709,551,615
|-
|float
| Float
| 32 bits
| single-precision IEEE 754 floating point
| -3.402823e38 to 3.02823e38
|-
| double
| Double
| 64 bits
| double-precision IEEE 754 floating point
| -1.79769313486232e308 to 1.79769313486232e308
|-
| boolean
| Boolean
| 1 bit
| boolean
| false, true
|-
| char
| Char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|-
| object
| Object
| N/A
| Object is the base type of all other types
|-
| string
| String
| N/A
| String is the base type for a sequence of chars
|-
| decimal
| Decimal
| 128
| Decimal is an integral type that can represent a decimal number with 29 significant digits ±1.0 × 10e−28 to ±7.9 × 10e28
|}

Like Java, each primitive data type in C# also has a class associated with it that. These classes serve a similar purpose to their associated ones in Java. They are used for comparison of objects, as well as conversion between other similar types.

== Primitive Objects in Ruby ==
Ruby is a pure object oriented language as compared to languages such as Java or C#, which use a more hybrid approach. In Ruby, all data types are represented as Objects. There are some [http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html inbuilt classes] that are provided to users in Ruby. However, only some of them are a basic building block for forming other types. This subset shown below gives us a list of primitive objects that can be used for data representation and manipulation:

{| border="1" style="border-spacing: 0"
! align="left"| Name
! Description
! Range
|-
| TrueClass
| Singleton instance "true" allowed
| true
|-
| FalseClass
| Singleton instance "false" allowed
| false
|-
| Integer [http://www.ruby-doc.org/core/Integer.html]
| Abstract class that forms the basis for Fixnum and Bignum
| See Fixnum and Bignum
|-
| Fixnum [http://www.ruby-doc.org/core-1.8.7/Fixnum.html]
| Integer representations that fit in native machine word
| Machine architecture dependent. 2^30-1 to -2^30 on 32-bit machines.
|-
| Bignum [http://www.ruby-doc.org/core/Bignum.html]
| Integer representations that do not fit in Fixnum width
| Machine architecture dependent. Values above Fixnum range.
|-
| Float [http://www.ruby-doc.org/core/Float.html]
| Real numbers using double precision representation
| Value after decimal point can be formatted
|-
| String [http://corelib.rubyonrails.org/classes/String.html]
| Contains sequence of characters
| No physical limit, but can be decided by machine architecture
|}

One interesting observation from the above table is that Ruby does not have a Boolean class; instead it has a separate TrueClass and FalseClass [http://www.skorks.com/2009/09/true-false-and-nil-objects-in-ruby].

puts true.class
=> TrueClass
puts false.class
=> FalseClass

Although types such as Array, Hash are also in-built types, they can be further composed of elements that are internally represented in one of the primitive types. Hence, they will not be treated by us as primitive objects, in the traditional definition of the term.
Each of the primitive objects listed above also provide certain convenience methods that are applicable for the underlying type.
For example, the Fixnum, Bignum and Float types provide support for arithmetic operations such as addition (+), subtraction(--), multiplication(*) and so on.
As with all other classes in Ruby, users can add functionality to existing primitive objects by reopening classes. The amount of memory required to implement the primitive objects in Ruby is machine dependent in some cases.

== Merit Analysis of Primitive Types ==
This section deals with a brief analysis of the relative merits and demerits of primitive data types. While we focus on Java or Ruby for this purpose, most of these points are applicable across all object oriented languages.

=== Advantages ===
Primitive types in object oriented languages have certain advantages over their class object counterparts.
* Simplicity: Primitive types/objects provide users a simple mechanism of manipulating data without relying on additional objects to achieve the same functionality. Operations on primitive types are more intuitive.
* Efficiency: This statement is applicable if the underlying primitive object definition is not modified (a feature that languages such as Ruby provide to users). As the representation in memory is designed to be make most efficient use of the underlying datatype, use of primitives can provide a benefit to the user, over the use of class objects to store the same data.
Eg. Java provides wrappers [http://www.glenmccl.com/tip_016.htm] for certain primitive types. There is a certain performance and space cost associated with these.
So, to maximize efficiency, direct use of the primitive types would provide the most benefit.
* Ability to use inbuilt methods: Depending on the primitive type, languages such as Ruby provide methods that can be used specifically to probe or manipulate objects.
Eg. [http://corelib.rubyonrails.org/classes/String.html String] primitive object provides convenience methods such as upcase to convert the entire string to upper case, or capitalize, which converts only the first character to upper case.
* Ease of testing for comparison: With primitive types, the equality testing operators such as == can be used. These essentially compare the values stored in the primitive types. Regular objects also offer the eql? method for testing equality. However, the following are not equivalent:
a=10
=> 10
a==10
=> true
a==10.0
=> true
a.eql?(10.0)
=> false
The reason the .eql? fails is that this operator tests for value and type being the same. 10 is type Fixnum and 10.0 is type Float.
The eql? can be overridden by == for primitive objects if you wish to compare only the values, but that can have a negative impact on performance [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html].

=== Disadvantages ===
* Lack of inheritance capability: The primitive data types in languages such as Java cannot be inherited to create further subtypes.
* Unexpected results due to method overriding: There are certain examples such as [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html], which show that overriding inbuilt methods such as == and eql? can lead to unexpected results.

== Conclusion ==
Object oriented languages have varying levels of support for primitive data types and objects. Whether they are beneficial or not depends on the application to a great deal. If handled correctly, they can make object oriented programs more efficient. However, the user needs to be aware of the underlying representation of these types to handle any unexpected results.

== References ==
# http://en.wikipedia.org/wiki/Primitive_data_type
# http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php
# http://www.jk-technology.com/c/inttypes.html
# http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html
# http://newty.de/fpt/intro.html
# http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
# http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx
# http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html
# http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html
# http://www.glenmccl.com/tip_016.htm
# http://www.skorks.com/2009/09/ruby-equality-and-object-comparison/

CSC/ECE 517 Fall 2011/ch3 3h rr

2011-10-29T21:52:33Z

Rbjeffer:

''3h. Primitive objects. At the beginning of Lecture 11, we discovered that Fixnums and Bignums are handled differently behind the scenes in Ruby. Other languages, like Java, have made similar distinctions. By contrast, languages such as C# and Eiffel try to hide these implementation differences from users. Answer two questions: (1) How have different o-o languages implemented primitive objects? E.g., how are they represented in memory, how are they tested for, do comparisons do anything different than for class objects, etc. (2) What are the advantages and disadvantages of treating primitives differently from class objects in source code?''

== Introduction ==
Programming languages, whether statically or dynamically typed, have support for certain in-built data types. These data types, known as primitive types, are the basic representation of information in programs and have certain fixed attributes for a specific language[http://en.wikipedia.org/wiki/Primitive_data_type]. Statically typed languages such as C++, Java, Perl etc. support primitive data types, whereas with dynamically typed languages such as Ruby, Smalltalk, Lisp etc. they are actually in the form of primitive objects. These primitive types are used to store the basic types of information that a computer can store and manipulate, and can also be used as building blocks for creating more complex data types.
This article explains the way different primitive types are implemented in certain object oriented languages. An analysis of the benefits and drawbacks of such types and the methods used to operate on them is also presented.

== Primitive Types ==
The primitive types commonly included in most programming languages are:
* Boolean
* Character
* Integer
* Floating-point number
* Fixed-point number
* Reference

=== Boolean ===
A Boolean is a primitive data type used to store one of two logical types: true or false. Boolean data types are most commonly used as input paramters to a conditional statement (such as an ‘if’ statement), or as the output of a comparison between two comparable data types. Booleans can be implemented in languages as either a discrete logical type, or implicitly as a numerical type. In many languages, booleans can be implicitly converted to and from integer types.

=== Character ===
A character is a data type that represents an element of a written language, such as a letter, number, or symbol. A character can also represent a control character, such as a carriage return or newline, which does not have a written meaning but controls how other characters are stored or displayed. Characters are commonly stored as integers, and encoded using a character map.

=== Integer ===
An integer is a data type that represents one element of a finite subset of mathematical integers. Integer, or Integral, data types can be either unsigned (able to store only positive whole numbers) or signed (able to store either positive or negative whole numbers). The range of values that can be represented by an integer depends on the number of bits used to store the integer, whether or not it is a signed integer, and the encoding scheme (if it is signed). Typically, an integer has a minimum and maximum value, and can store any integer in the range between those values. The minimum value for unsigned integers is typically 0, and the maximum value is typically determined by the amount of memory used to store the integer. For example, a un unsigned 8-bit number can store 2^8 (or 256) possible integral values; and would typically store any value from 0 to 255. More generally, an n-bit unsigned integer can store from 0 to (2^n)-1. For signed integers, modern computers use the Two’s Complement encoding scheme. This allows for a range of −2^(n−1) through 2^(n−1)−1. For example, an 8-bit signed integer could store any whole number in the range from -128 through +127.

=== Floating-Point Number ===
A floating point number is a data type used to represent real numbers in a large range with varying degrees of precision. In this representation, numbers are represented with a variable number of significant digits, and a variable number of exponential digits.

=== Fixed-Point number ===
A fixed-point number is a data type used to represent real numbers. Fixed-point numbers are called fixed-point because they have a set number of digits before and after a decimal mark. In this regard, fixed-point numbers are represented as an integer, but are scaled by a predetermined factor.

Fixed-point numbers are commonly used in microprocessors that do not have a floating-point unit, or in systems in which computational efficiency is critical. Fixed-point numbers can be treated as integers by an arithmetic logic unit (ALU) and scaled after a result is obtained, which can significantly lower the amount of time needed for a processor to obtain the result for some algorithms.

Implementing algorithms using fixed-point arithmetic requires great care, because of the potential for information loss. Fixed-point arithmetic operations -- multiplication in particular, has the potential to cause overflow. Algorithms must be written with care to ensure that each term of an equation has a similar range and that the result will not cause an overflow.

=== Reference ===

A Reference is a data type that enables a program to access another item in memory. A reference differs from other primitive data types in that it does not store data itself; instead it stores a value referring to another data object. References are commonly used to refer to objects of large non-primitive data types. References commonly store the physical memory address of the data that they are referring to. Accessing the data referred to by a Reference is called dereferencing.

== Primitive Data Types in C++ ==

C++ is a statically-typed object oriented language. C++ is based on the C programming language, which is procedural, and adds support for object-oriented code.

These data types are defined in C++: [http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php]

{| border="1" style="border-spacing: 0"
! Name
! Size
! Description
! Range
|-
| void
| N/A
| the void data type is used to explicitly identify that a data has no type
| N/A
|-
| int
| 32 bits
| simple numerical type
| See [[http://www.jk-technology.com/c/inttypes.html]]
|-
| float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 8 bits
| a char is a single 8-bit character encoded using ASCII
| Ascii character 0x00 through ascii character 0xFF
|}
C++ supports Pointers for all of the types listed in the table above, as well as more complex data types (such as structs). A Pointer in C++ is a data type that stores the physical address of some other data. Pointers are created in C++ by using the * operator. For example, a *Double[] is a pointer to an array of double-precision floating point numbers. C++ Also supports function pointers -- pointers that reference the beginning address of a function in memory. They are commonly used to implement callback functions [http://newty.de/fpt/intro.html#what]

== Primitive Data Types in Java ==

Java is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. These data types are defined in Java: [http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html]
{| border="1" style="border-spacing: 0"
! align="left"|Name
! Size
! Description
! Range
|-
|byte
|8 bits
|signed two's complement integer
|-128 to 127
|-
| short
|16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| int
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| long
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
|float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|}

Java also defines a String class, which is used to create objects of many chars. The String class provides functionality commonly implemented using arrays of chars in other languages, such as C.

Java also defines the 'unsigned' keyword, which can be used to as a modifier to any of the integral types listed in the table above. If the 'unsigned' keyword is used, the integral type will be unsigned instead of signed, and its range will change correspondingly.

Java is capable of using any two objects of the same primitive data type for comparison. Java defines a class for each data type, which have the same name but a capitalized first letter (e.g. Float instead of float). These classes, called wrapper classes provide a series of methods that can manipulate their associated primitive data type, as well as convert to and from other data types.

== Primitive Data Types in C# ==

C# is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. C# has all of the data types that are available in Java, as well as some additional ones.

Similar to Java, C# defines a String class which is used to create objects of many chars. These data types are defined in C#: [http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx]

{| border="1" style="border-spacing: 0"
! align="left"| Name
! .NET Class
! Size
! Description
! Range
|-
|byte
| Byte
| 8 bits
|signed two's complement integer
| -128 to 127
|-
| sbyte
| SByte
| 8 bits
| signed two's complement integer
| -0 to 255
|-
| short
| Int16
| 16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| ushort
| UInt16
| 16 bits
| unsigned integer
| 0 to 65,535
|-
| int
| Int32
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| uint
| UInt32
| 32 bits
| unsigned integer
| 0 to 4,294,967,295
|-
| long
| Int64
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
| ulong
| UInt64
| 64 bits
| unsigned integer
| 0 to 18,446,744,073,709,551,615
|-
|float
| Float
| 32 bits
| single-precision IEEE 754 floating point
| -3.402823e38 to 3.02823e38
|-
| double
| Double
| 64 bits
| double-precision IEEE 754 floating point
| -1.79769313486232e308 to 1.79769313486232e308
|-
| boolean
| Boolean
| 1 bit
| boolean
| false, true
|-
| char
| Char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|-
| object
| Object
| N/A
| Object is the base type of all other types
|-
| string
| String
| N/A
| String is the base type for a sequence of chars
|-
| decimal
| Decimal
| 128
| Decimal is an integral type that can represent a decimal number with 29 significant digits ±1.0 × 10e−28 to ±7.9 × 10e28
|}

Like Java, each primitive data type in C# also has a class associated with it that. These classes serve a similar purpose to their associated ones in Java. They are used for comparison of objects, as well as conversion between other similar types.

== Primitive Objects in Ruby ==
Ruby is a pure object oriented language as compared to languages such as Java or C#, which use a more hybrid approach. In Ruby, all data types are represented as Objects. There are some [http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html inbuilt classes] that are provided to users in Ruby. However, only some of them are a basic building block for forming other types. This subset shown below gives us a list of primitive objects that can be used for data representation and manipulation:

{| border="1" style="border-spacing: 0"
! align="left"| Name
! Description
! Range
|-
| TrueClass
| Singleton instance "true" allowed
| true
|-
| FalseClass
| Singleton instance "false" allowed
| false
|-
| Integer [http://www.ruby-doc.org/core/Integer.html]
| Abstract class that forms the basis for Fixnum and Bignum
| See Fixnum and Bignum
|-
| Fixnum [http://www.ruby-doc.org/core-1.8.7/Fixnum.html]
| Integer representations that fit in native machine word
| Machine architecture dependent. 2^30-1 to -2^30 on 32-bit machines.
|-
| Bignum [http://www.ruby-doc.org/core/Bignum.html]
| Integer representations that do not fit in Fixnum width
| Machine architecture dependent. Values above Fixnum range.
|-
| Float [http://www.ruby-doc.org/core/Float.html]
| Real numbers using double precision representation
| Value after decimal point can be formatted
|-
| String [http://corelib.rubyonrails.org/classes/String.html]
| Contains sequence of characters
| No physical limit, but can be decided by machine architecture
|}

One interesting observation from the above table is that Ruby does not have a Boolean class; instead it has a separate TrueClass and FalseClass [http://www.skorks.com/2009/09/true-false-and-nil-objects-in-ruby].

puts true.class
=> TrueClass
puts false.class
=> FalseClass

Although types such as Array, Hash are also in-built types, they can be further composed of elements that are internally represented in one of the primitive types. Hence, they will not be treated by us as primitive objects, in the traditional definition of the term.
Each of the primitive objects listed above also provide certain convenience methods that are applicable for the underlying type.
For example, the Fixnum, Bignum and Float types provide support for arithmetic operations such as addition (+), subtraction(--), multiplication(*) and so on.
As with all other classes in Ruby, users can add functionality to existing primitive objects by reopening classes. The amount of memory required to implement the primitive objects in Ruby is machine dependent in some cases.

== Merit Analysis of Primitive Types ==
This section deals with a brief analysis of the relative merits and demerits of primitive data types. While we focus on Java or Ruby for this purpose, most of these points are applicable across all object oriented languages.

=== Advantages ===
Primitive types in object oriented languages have certain advantages over their class object counterparts.
* Simplicity: Primitive types/objects provide users a simple mechanism of manipulating data without relying on additional objects to achieve the same functionality. Operations on primitive types are more intuitive.
* Efficiency: This statement is applicable if the underlying primitive object definition is not modified (a feature that languages such as Ruby provide to users). As the representation in memory is designed to be make most efficient use of the underlying datatype, use of primitives can provide a benefit to the user, over the use of class objects to store the same data.
Eg. Java provides wrappers [http://www.glenmccl.com/tip_016.htm] for certain primitive types. There is a certain performance and space cost associated with these.
So, to maximize efficiency, direct use of the primitive types would provide the most benefit.
* Ability to use inbuilt methods: Depending on the primitive type, languages such as Ruby provide methods that can be used specifically to probe or manipulate objects.
Eg. [http://corelib.rubyonrails.org/classes/String.html String] primitive object provides convenience methods such as upcase to convert the entire string to upper case, or capitalize, which converts only the first character to upper case.
* Ease of testing for comparison: With primitive types, the equality testing operators such as == can be used. These essentially compare the values stored in the primitive types. Regular objects also offer the eql? method for testing equality. However, the following are not equivalent:
a=10
=> 10
a==10
=> true
a==10.0
=> true
a.eql?(10.0)
=> false
The reason the .eql? fails is that this operator tests for value and type being the same. 10 is type Fixnum and 10.0 is type Float.
The eql? can be overridden by == for primitive objects if you wish to compare only the values, but that can have a negative impact on performance [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html].

=== Disadvantages ===
* Lack of inheritance capability: The primitive data types in languages such as Java cannot be inherited to create further subtypes.
* Unexpected results due to method overriding: There are certain examples such as [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html], which show that overriding inbuilt methods such as == and eql? can lead to unexpected results.

== Conclusion ==
Object oriented languages have varying levels of support for primitive data types and objects. Whether they are beneficial or not depends on the application to a great deal. If handled correctly, they can make object oriented programs more efficient. However, the user needs to be aware of the underlying representation of these types to handle any unexpected results.

== References ==
# http://en.wikipedia.org/wiki/Primitive_data_type
# http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php
# http://www.jk-technology.com/c/inttypes.html
# http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html
# http://newty.de/fpt/intro.html
# http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
# http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx
# http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html
# http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html
# http://www.glenmccl.com/tip_016.htm
# http://www.skorks.com/2009/09/ruby-equality-and-object-comparison/

CSC/ECE 517 Fall 2011/ch3 3h rr

2011-10-29T21:51:47Z

Rbjeffer:

''3h. Primitive objects. At the beginning of Lecture 11, we discovered that Fixnums and Bignums are handled differently behind the scenes in Ruby. Other languages, like Java, have made similar distinctions. By contrast, languages such as C# and Eiffel try to hide these implementation differences from users. Answer two questions: (1) How have different o-o languages implemented primitive objects? E.g., how are they represented in memory, how are they tested for, do comparisons do anything different than for class objects, etc. (2) What are the advantages and disadvantages of treating primitives differently from class objects in source code?''

== Introduction ==
Programming languages, whether statically or dynamically typed, have support for certain in-built data types. These data types, known as primitive types, are the basic representation of information in programs and have certain fixed attributes for a specific language[http://en.wikipedia.org/wiki/Primitive_data_type]. Statically typed languages such as C++, Java, Perl etc. support primitive data types, whereas with dynamically typed languages such as Ruby, Smalltalk, Lisp etc. they are actually in the form of primitive objects. These primitive types are used to store the basic types of information that a computer can store and manipulate, and can also be used as building blocks for creating more complex data types.
This article explains the way different primitive types are implemented in certain object oriented languages. An analysis of the benefits and drawbacks of such types and the methods used to operate on them is also presented.

== Primitive Types ==
The primitive types commonly included in most programming languages are:
* Boolean
* Character
* Integer
* Floating-point number
* Fixed-point number
* Reference

=== Boolean ===
A Boolean is a primitive data type used to store one of two logical types: true or false. Boolean data types are most commonly used as input paramters to a conditional statement (such as an ‘if’ statement), or as the output of a comparison between two comparable data types. Booleans can be implemented in languages as either a discrete logical type, or implicitly as a numerical type. In many languages, booleans can be implicitly converted to and from integer types.

=== Character ===
A character is a data type that represents an element of a written language, such as a letter, number, or symbol. A character can also represent a control character, such as a carriage return or newline, which does not have a written meaning but controls how other characters are stored or displayed. Characters are commonly stored as integers, and encoded using a character map.

=== Integer ===
An integer is a data type that represents one element of a finite subset of mathematical integers. Integer, or Integral, data types can be either unsigned (able to store only positive whole numbers) or signed (able to store either positive or negative whole numbers). The range of values that can be represented by an integer depends on the number of bits used to store the integer, whether or not it is a signed integer, and the encoding scheme (if it is signed). Typically, an integer has a minimum and maximum value, and can store any integer in the range between those values. The minimum value for unsigned integers is typically 0, and the maximum value is typically determined by the amount of memory used to store the integer. For example, a un unsigned 8-bit number can store 2^8 (or 256) possible integral values; and would typically store any value from 0 to 255. More generally, an n-bit unsigned integer can store from 0 to (2^n)-1. For signed integers, modern computers use the Two’s Complement encoding scheme. This allows for a range of −2^(n−1) through 2^(n−1)−1. For example, an 8-bit signed integer could store any whole number in the range from -128 through +127.

=== Floating-Point Number ===
A floating point number is a data type used to represent real numbers in a large range with varying degrees of precision. In this representation, numbers are represented with a variable number of significant digits, and a variable number of exponential digits.

=== Fixed-Point number ===
A fixed-point number is a data type used to represent real numbers. Fixed-point numbers are called fixed-point because they have a set number of digits before and after a decimal mark. In this regard, fixed-point numbers are represented as an integer, but are scaled by a predetermined factor.

Fixed-point numbers are commonly used in microprocessors that do not have a floating-point unit, or in systems in which computational efficiency is critical. Fixed-point numbers can be treated as integers by an arithmetic logic unit (ALU) and scaled after a result is obtained, which can significantly lower the amount of time needed for a processor to obtain the result for some algorithms.

Implementing algorithms using fixed-point arithmetic requires great care, because of the potential for information loss. Fixed-point arithmetic operations -- multiplication in particular, has the potential to cause overflow. Algorithms must be written with care to ensure that each term of an equation has a similar range and that the result will not cause an overflow.

=== Reference ===

A Reference is a data type that enables a program to access another item in memory. A reference differs from other primitive data types in that it does not store data itself; instead it stores a value referring to another data object. References are commonly used to refer to objects of large non-primitive data types. References commonly store the physical memory address of the data that they are referring to. Accessing the data referred to by a Reference is called dereferencing.

== Primitive Data Types in C++ ==

C++ is a statically-typed object oriented language. C++ is based on the C programming language, which is procedural, and adds support for object-oriented code.

These data types are defined in C++: [http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php]

{| border="1" style="border-spacing: 0"
! Name
! Size
! Description
! Range
|-
| void
| N/A
| the void data type is used to explicitly identify that a data has no type
| N/A
|-
| int
| 32 bits
| simple numerical type
| See [[http://www.jk-technology.com/c/inttypes.html]]
|-
| float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 8 bits
| a char is a single 8-bit character encoded using ASCII
| Ascii character 0x00 through ascii character 0xFF
|}
C++ supports Pointers for all of the types listed in the table above, as well as more complex data types (such as structs). A Pointer in C++ is a data type that stores the physical address of some other data. Pointers are created in C++ by using the * operator. For example, a *Double[] is a pointer to an array of double-precision floating point numbers. C++ Also supports function pointers -- pointers that reference the beginning address of a function in memory. They are commonly used to implement callback functions [http://newty.de/fpt/intro.html#what]

== Primitive Data Types in Java ==

Java is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. These data types are defined in Java: [http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html]
{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
! align="left"|Name
! Size
! Description
! Range
|-
|byte
|8 bits
|signed two's complement integer
|-128 to 127
|-
| short
|16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| int
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| long
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
|float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|}

Java also defines a String class, which is used to create objects of many chars. The String class provides functionality commonly implemented using arrays of chars in other languages, such as C.

Java also defines the 'unsigned' keyword, which can be used to as a modifier to any of the integral types listed in the table above. If the 'unsigned' keyword is used, the integral type will be unsigned instead of signed, and its range will change correspondingly.

Java is capable of using any two objects of the same primitive data type for comparison. Java defines a class for each data type, which have the same name but a capitalized first letter (e.g. Float instead of float). These classes, called wrapper classes provide a series of methods that can manipulate their associated primitive data type, as well as convert to and from other data types.

== Primitive Data Types in C# ==

C# is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. C# has all of the data types that are available in Java, as well as some additional ones.

Similar to Java, C# defines a String class which is used to create objects of many chars. These data types are defined in C#: [http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx]

{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
! align="left"| Name
! .NET Class
! Size
! Description
! Range
|-
|byte
| Byte
| 8 bits
|signed two's complement integer
| -128 to 127
|-
| sbyte
| SByte
| 8 bits
| signed two's complement integer
| -0 to 255
|-
| short
| Int16
| 16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| ushort
| UInt16
| 16 bits
| unsigned integer
| 0 to 65,535
|-
| int
| Int32
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| uint
| UInt32
| 32 bits
| unsigned integer
| 0 to 4,294,967,295
|-
| long
| Int64
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
| ulong
| UInt64
| 64 bits
| unsigned integer
| 0 to 18,446,744,073,709,551,615
|-
|float
| Float
| 32 bits
| single-precision IEEE 754 floating point
| -3.402823e38 to 3.02823e38
|-
| double
| Double
| 64 bits
| double-precision IEEE 754 floating point
| -1.79769313486232e308 to 1.79769313486232e308
|-
| boolean
| Boolean
| 1 bit
| boolean
| false, true
|-
| char
| Char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|-
| object
| Object
| N/A
| Object is the base type of all other types
|-
| string
| String
| N/A
| String is the base type for a sequence of chars
|-
| decimal
| Decimal
| 128
| Decimal is an integral type that can represent a decimal number with 29 significant digits ±1.0 × 10e−28 to ±7.9 × 10e28
|}

Like Java, each primitive data type in C# also has a class associated with it that. These classes serve a similar purpose to their associated ones in Java. They are used for comparison of objects, as well as conversion between other similar types.

== Primitive Objects in Ruby ==
Ruby is a pure object oriented language as compared to languages such as Java or C#, which use a more hybrid approach. In Ruby, all data types are represented as Objects. There are some [http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html inbuilt classes] that are provided to users in Ruby. However, only some of them are a basic building block for forming other types. This subset shown below gives us a list of primitive objects that can be used for data representation and manipulation:

{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
! align="left"| Name
! Description
! Range
|-
| TrueClass
| Singleton instance "true" allowed
| true
|-
| FalseClass
| Singleton instance "false" allowed
| false
|-
| Integer [http://www.ruby-doc.org/core/Integer.html]
| Abstract class that forms the basis for Fixnum and Bignum
| See Fixnum and Bignum
|-
| Fixnum [http://www.ruby-doc.org/core-1.8.7/Fixnum.html]
| Integer representations that fit in native machine word
| Machine architecture dependent. 2^30-1 to -2^30 on 32-bit machines.
|-
| Bignum [http://www.ruby-doc.org/core/Bignum.html]
| Integer representations that do not fit in Fixnum width
| Machine architecture dependent. Values above Fixnum range.
|-
| Float [http://www.ruby-doc.org/core/Float.html]
| Real numbers using double precision representation
| Value after decimal point can be formatted
|-
| String [http://corelib.rubyonrails.org/classes/String.html]
| Contains sequence of characters
| No physical limit, but can be decided by machine architecture
|}

One interesting observation from the above table is that Ruby does not have a Boolean class; instead it has a separate TrueClass and FalseClass [http://www.skorks.com/2009/09/true-false-and-nil-objects-in-ruby].

puts true.class
=> TrueClass
puts false.class
=> FalseClass

Although types such as Array, Hash are also in-built types, they can be further composed of elements that are internally represented in one of the primitive types. Hence, they will not be treated by us as primitive objects, in the traditional definition of the term.
Each of the primitive objects listed above also provide certain convenience methods that are applicable for the underlying type.
For example, the Fixnum, Bignum and Float types provide support for arithmetic operations such as addition (+), subtraction(--), multiplication(*) and so on.
As with all other classes in Ruby, users can add functionality to existing primitive objects by reopening classes. The amount of memory required to implement the primitive objects in Ruby is machine dependent in some cases.

== Merit Analysis of Primitive Types ==
This section deals with a brief analysis of the relative merits and demerits of primitive data types. While we focus on Java or Ruby for this purpose, most of these points are applicable across all object oriented languages.

=== Advantages ===
Primitive types in object oriented languages have certain advantages over their class object counterparts.
* Simplicity: Primitive types/objects provide users a simple mechanism of manipulating data without relying on additional objects to achieve the same functionality. Operations on primitive types are more intuitive.
* Efficiency: This statement is applicable if the underlying primitive object definition is not modified (a feature that languages such as Ruby provide to users). As the representation in memory is designed to be make most efficient use of the underlying datatype, use of primitives can provide a benefit to the user, over the use of class objects to store the same data.
Eg. Java provides wrappers [http://www.glenmccl.com/tip_016.htm] for certain primitive types. There is a certain performance and space cost associated with these.
So, to maximize efficiency, direct use of the primitive types would provide the most benefit.
* Ability to use inbuilt methods: Depending on the primitive type, languages such as Ruby provide methods that can be used specifically to probe or manipulate objects.
Eg. [http://corelib.rubyonrails.org/classes/String.html String] primitive object provides convenience methods such as upcase to convert the entire string to upper case, or capitalize, which converts only the first character to upper case.
* Ease of testing for comparison: With primitive types, the equality testing operators such as == can be used. These essentially compare the values stored in the primitive types. Regular objects also offer the eql? method for testing equality. However, the following are not equivalent:
a=10
=> 10
a==10
=> true
a==10.0
=> true
a.eql?(10.0)
=> false
The reason the .eql? fails is that this operator tests for value and type being the same. 10 is type Fixnum and 10.0 is type Float.
The eql? can be overridden by == for primitive objects if you wish to compare only the values, but that can have a negative impact on performance [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html].

=== Disadvantages ===
* Lack of inheritance capability: The primitive data types in languages such as Java cannot be inherited to create further subtypes.
* Unexpected results due to method overriding: There are certain examples such as [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html], which show that overriding inbuilt methods such as == and eql? can lead to unexpected results.

== Conclusion ==
Object oriented languages have varying levels of support for primitive data types and objects. Whether they are beneficial or not depends on the application to a great deal. If handled correctly, they can make object oriented programs more efficient. However, the user needs to be aware of the underlying representation of these types to handle any unexpected results.

== References ==
# http://en.wikipedia.org/wiki/Primitive_data_type
# http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php
# http://www.jk-technology.com/c/inttypes.html
# http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html
# http://newty.de/fpt/intro.html
# http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
# http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx
# http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html
# http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html
# http://www.glenmccl.com/tip_016.htm
# http://www.skorks.com/2009/09/ruby-equality-and-object-comparison/

CSC/ECE 517 Fall 2011/ch3 3h rr

2011-10-29T21:50:53Z

Rbjeffer:

''3h. Primitive objects. At the beginning of Lecture 11, we discovered that Fixnums and Bignums are handled differently behind the scenes in Ruby. Other languages, like Java, have made similar distinctions. By contrast, languages such as C# and Eiffel try to hide these implementation differences from users. Answer two questions: (1) How have different o-o languages implemented primitive objects? E.g., how are they represented in memory, how are they tested for, do comparisons do anything different than for class objects, etc. (2) What are the advantages and disadvantages of treating primitives differently from class objects in source code?''

== Introduction ==
Programming languages, whether statically or dynamically typed, have support for certain in-built data types. These data types, known as primitive types, are the basic representation of information in programs and have certain fixed attributes for a specific language[http://en.wikipedia.org/wiki/Primitive_data_type]. Statically typed languages such as C++, Java, Perl etc. support primitive data types, whereas with dynamically typed languages such as Ruby, Smalltalk, Lisp etc. they are actually in the form of primitive objects. These primitive types are used to store the basic types of information that a computer can store and manipulate, and can also be used as building blocks for creating more complex data types.
This article explains the way different primitive types are implemented in certain object oriented languages. An analysis of the benefits and drawbacks of such types and the methods used to operate on them is also presented.

== Primitive Types ==
The primitive types commonly included in most programming languages are:
* Boolean
* Character
* Integer
* Floating-point number
* Fixed-point number
* Reference

=== Boolean ===
A Boolean is a primitive data type used to store one of two logical types: true or false. Boolean data types are most commonly used as input paramters to a conditional statement (such as an ‘if’ statement), or as the output of a comparison between two comparable data types. Booleans can be implemented in languages as either a discrete logical type, or implicitly as a numerical type. In many languages, booleans can be implicitly converted to and from integer types.

=== Character ===
A character is a data type that represents an element of a written language, such as a letter, number, or symbol. A character can also represent a control character, such as a carriage return or newline, which does not have a written meaning but controls how other characters are stored or displayed. Characters are commonly stored as integers, and encoded using a character map.

=== Integer ===
An integer is a data type that represents one element of a finite subset of mathematical integers. Integer, or Integral, data types can be either unsigned (able to store only positive whole numbers) or signed (able to store either positive or negative whole numbers). The range of values that can be represented by an integer depends on the number of bits used to store the integer, whether or not it is a signed integer, and the encoding scheme (if it is signed). Typically, an integer has a minimum and maximum value, and can store any integer in the range between those values. The minimum value for unsigned integers is typically 0, and the maximum value is typically determined by the amount of memory used to store the integer. For example, a un unsigned 8-bit number can store 2^8 (or 256) possible integral values; and would typically store any value from 0 to 255. More generally, an n-bit unsigned integer can store from 0 to (2^n)-1. For signed integers, modern computers use the Two’s Complement encoding scheme. This allows for a range of −2^(n−1) through 2^(n−1)−1. For example, an 8-bit signed integer could store any whole number in the range from -128 through +127.

=== Floating-Point Number ===
A floating point number is a data type used to represent real numbers in a large range with varying degrees of precision. In this representation, numbers are represented with a variable number of significant digits, and a variable number of exponential digits.

=== Fixed-Point number ===
A fixed-point number is a data type used to represent real numbers. Fixed-point numbers are called fixed-point because they have a set number of digits before and after a decimal mark. In this regard, fixed-point numbers are represented as an integer, but are scaled by a predetermined factor.

Fixed-point numbers are commonly used in microprocessors that do not have a floating-point unit, or in systems in which computational efficiency is critical. Fixed-point numbers can be treated as integers by an arithmetic logic unit (ALU) and scaled after a result is obtained, which can significantly lower the amount of time needed for a processor to obtain the result for some algorithms.

Implementing algorithms using fixed-point arithmetic requires great care, because of the potential for information loss. Fixed-point arithmetic operations -- multiplication in particular, has the potential to cause overflow. Algorithms must be written with care to ensure that each term of an equation has a similar range and that the result will not cause an overflow.

=== Reference ===

A Reference is a data type that enables a program to access another item in memory. A reference differs from other primitive data types in that it does not store data itself; instead it stores a value referring to another data object. References are commonly used to refer to objects of large non-primitive data types. References commonly store the physical memory address of the data that they are referring to. Accessing the data referred to by a Reference is called dereferencing.

== Primitive Data Types in C++ ==

C++ is a statically-typed object oriented language. C++ is based on the C programming language, which is procedural, and adds support for object-oriented code.

These data types are defined in C++: [http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php]

{| border="1"
! Name
! Size
! Description
! Range
|-
| void
| N/A
| the void data type is used to explicitly identify that a data has no type
| N/A
|-
| int
| 32 bits
| simple numerical type
| See [[http://www.jk-technology.com/c/inttypes.html]]
|-
| float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 8 bits
| a char is a single 8-bit character encoded using ASCII
| Ascii character 0x00 through ascii character 0xFF
|}
C++ supports Pointers for all of the types listed in the table above, as well as more complex data types (such as structs). A Pointer in C++ is a data type that stores the physical address of some other data. Pointers are created in C++ by using the * operator. For example, a *Double[] is a pointer to an array of double-precision floating point numbers. C++ Also supports function pointers -- pointers that reference the beginning address of a function in memory. They are commonly used to implement callback functions [http://newty.de/fpt/intro.html#what]

== Primitive Data Types in Java ==

Java is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. These data types are defined in Java: [http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html]
{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
! align="left"|Name
! Size
! Description
! Range
|-
|byte
|8 bits
|signed two's complement integer
|-128 to 127
|-
| short
|16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| int
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| long
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
|float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|}

Java also defines a String class, which is used to create objects of many chars. The String class provides functionality commonly implemented using arrays of chars in other languages, such as C.

Java also defines the 'unsigned' keyword, which can be used to as a modifier to any of the integral types listed in the table above. If the 'unsigned' keyword is used, the integral type will be unsigned instead of signed, and its range will change correspondingly.

Java is capable of using any two objects of the same primitive data type for comparison. Java defines a class for each data type, which have the same name but a capitalized first letter (e.g. Float instead of float). These classes, called wrapper classes provide a series of methods that can manipulate their associated primitive data type, as well as convert to and from other data types.

== Primitive Data Types in C# ==

C# is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. C# has all of the data types that are available in Java, as well as some additional ones.

Similar to Java, C# defines a String class which is used to create objects of many chars. These data types are defined in C#: [http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx]

{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
! align="left"| Name
! .NET Class
! Size
! Description
! Range
|-
|byte
| Byte
| 8 bits
|signed two's complement integer
| -128 to 127
|-
| sbyte
| SByte
| 8 bits
| signed two's complement integer
| -0 to 255
|-
| short
| Int16
| 16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| ushort
| UInt16
| 16 bits
| unsigned integer
| 0 to 65,535
|-
| int
| Int32
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| uint
| UInt32
| 32 bits
| unsigned integer
| 0 to 4,294,967,295
|-
| long
| Int64
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
| ulong
| UInt64
| 64 bits
| unsigned integer
| 0 to 18,446,744,073,709,551,615
|-
|float
| Float
| 32 bits
| single-precision IEEE 754 floating point
| -3.402823e38 to 3.02823e38
|-
| double
| Double
| 64 bits
| double-precision IEEE 754 floating point
| -1.79769313486232e308 to 1.79769313486232e308
|-
| boolean
| Boolean
| 1 bit
| boolean
| false, true
|-
| char
| Char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|-
| object
| Object
| N/A
| Object is the base type of all other types
|-
| string
| String
| N/A
| String is the base type for a sequence of chars
|-
| decimal
| Decimal
| 128
| Decimal is an integral type that can represent a decimal number with 29 significant digits ±1.0 × 10e−28 to ±7.9 × 10e28
|}

Like Java, each primitive data type in C# also has a class associated with it that. These classes serve a similar purpose to their associated ones in Java. They are used for comparison of objects, as well as conversion between other similar types.

== Primitive Objects in Ruby ==
Ruby is a pure object oriented language as compared to languages such as Java or C#, which use a more hybrid approach. In Ruby, all data types are represented as Objects. There are some [http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html inbuilt classes] that are provided to users in Ruby. However, only some of them are a basic building block for forming other types. This subset shown below gives us a list of primitive objects that can be used for data representation and manipulation:

{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
! align="left"| Name
! Description
! Range
|-
| TrueClass
| Singleton instance "true" allowed
| true
|-
| FalseClass
| Singleton instance "false" allowed
| false
|-
| Integer [http://www.ruby-doc.org/core/Integer.html]
| Abstract class that forms the basis for Fixnum and Bignum
| See Fixnum and Bignum
|-
| Fixnum [http://www.ruby-doc.org/core-1.8.7/Fixnum.html]
| Integer representations that fit in native machine word
| Machine architecture dependent. 2^30-1 to -2^30 on 32-bit machines.
|-
| Bignum [http://www.ruby-doc.org/core/Bignum.html]
| Integer representations that do not fit in Fixnum width
| Machine architecture dependent. Values above Fixnum range.
|-
| Float [http://www.ruby-doc.org/core/Float.html]
| Real numbers using double precision representation
| Value after decimal point can be formatted
|-
| String [http://corelib.rubyonrails.org/classes/String.html]
| Contains sequence of characters
| No physical limit, but can be decided by machine architecture
|}

One interesting observation from the above table is that Ruby does not have a Boolean class; instead it has a separate TrueClass and FalseClass [http://www.skorks.com/2009/09/true-false-and-nil-objects-in-ruby].

puts true.class
=> TrueClass
puts false.class
=> FalseClass

Although types such as Array, Hash are also in-built types, they can be further composed of elements that are internally represented in one of the primitive types. Hence, they will not be treated by us as primitive objects, in the traditional definition of the term.
Each of the primitive objects listed above also provide certain convenience methods that are applicable for the underlying type.
For example, the Fixnum, Bignum and Float types provide support for arithmetic operations such as addition (+), subtraction(--), multiplication(*) and so on.
As with all other classes in Ruby, users can add functionality to existing primitive objects by reopening classes. The amount of memory required to implement the primitive objects in Ruby is machine dependent in some cases.

== Merit Analysis of Primitive Types ==
This section deals with a brief analysis of the relative merits and demerits of primitive data types. While we focus on Java or Ruby for this purpose, most of these points are applicable across all object oriented languages.

=== Advantages ===
Primitive types in object oriented languages have certain advantages over their class object counterparts.
* Simplicity: Primitive types/objects provide users a simple mechanism of manipulating data without relying on additional objects to achieve the same functionality. Operations on primitive types are more intuitive.
* Efficiency: This statement is applicable if the underlying primitive object definition is not modified (a feature that languages such as Ruby provide to users). As the representation in memory is designed to be make most efficient use of the underlying datatype, use of primitives can provide a benefit to the user, over the use of class objects to store the same data.
Eg. Java provides wrappers [http://www.glenmccl.com/tip_016.htm] for certain primitive types. There is a certain performance and space cost associated with these.
So, to maximize efficiency, direct use of the primitive types would provide the most benefit.
* Ability to use inbuilt methods: Depending on the primitive type, languages such as Ruby provide methods that can be used specifically to probe or manipulate objects.
Eg. [http://corelib.rubyonrails.org/classes/String.html String] primitive object provides convenience methods such as upcase to convert the entire string to upper case, or capitalize, which converts only the first character to upper case.
* Ease of testing for comparison: With primitive types, the equality testing operators such as == can be used. These essentially compare the values stored in the primitive types. Regular objects also offer the eql? method for testing equality. However, the following are not equivalent:
a=10
=> 10
a==10
=> true
a==10.0
=> true
a.eql?(10.0)
=> false
The reason the .eql? fails is that this operator tests for value and type being the same. 10 is type Fixnum and 10.0 is type Float.
The eql? can be overridden by == for primitive objects if you wish to compare only the values, but that can have a negative impact on performance [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html].

=== Disadvantages ===
* Lack of inheritance capability: The primitive data types in languages such as Java cannot be inherited to create further subtypes.
* Unexpected results due to method overriding: There are certain examples such as [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html], which show that overriding inbuilt methods such as == and eql? can lead to unexpected results.

== Conclusion ==
Object oriented languages have varying levels of support for primitive data types and objects. Whether they are beneficial or not depends on the application to a great deal. If handled correctly, they can make object oriented programs more efficient. However, the user needs to be aware of the underlying representation of these types to handle any unexpected results.

== References ==
# http://en.wikipedia.org/wiki/Primitive_data_type
# http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php
# http://www.jk-technology.com/c/inttypes.html
# http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html
# http://newty.de/fpt/intro.html
# http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
# http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx
# http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html
# http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html
# http://www.glenmccl.com/tip_016.htm
# http://www.skorks.com/2009/09/ruby-equality-and-object-comparison/

CSC/ECE 517 Fall 2011/ch3 3h rr

2011-10-29T21:47:56Z

Rbjeffer:

''3h. Primitive objects. At the beginning of Lecture 11, we discovered that Fixnums and Bignums are handled differently behind the scenes in Ruby. Other languages, like Java, have made similar distinctions. By contrast, languages such as C# and Eiffel try to hide these implementation differences from users. Answer two questions: (1) How have different o-o languages implemented primitive objects? E.g., how are they represented in memory, how are they tested for, do comparisons do anything different than for class objects, etc. (2) What are the advantages and disadvantages of treating primitives differently from class objects in source code?''

== Introduction ==
Programming languages, whether statically or dynamically typed, have support for certain in-built data types. These data types, known as primitive types, are the basic representation of information in programs and have certain fixed attributes for a specific language[http://en.wikipedia.org/wiki/Primitive_data_type]. Statically typed languages such as C++, Java, Perl etc. support primitive data types, whereas with dynamically typed languages such as Ruby, Smalltalk, Lisp etc. they are actually in the form of primitive objects. These primitive types are used to store the basic types of information that a computer can store and manipulate, and can also be used as building blocks for creating more complex data types.
This article explains the way different primitive types are implemented in certain object oriented languages. An analysis of the benefits and drawbacks of such types and the methods used to operate on them is also presented.

== Primitive Types ==
The primitive types commonly included in most programming languages are:
* Boolean
* Character
* Integer
* Floating-point number
* Fixed-point number
* Reference

=== Boolean ===
A Boolean is a primitive data type used to store one of two logical types: true or false. Boolean data types are most commonly used as input paramters to a conditional statement (such as an ‘if’ statement), or as the output of a comparison between two comparable data types. Booleans can be implemented in languages as either a discrete logical type, or implicitly as a numerical type. In many languages, booleans can be implicitly converted to and from integer types.

=== Character ===
A character is a data type that represents an element of a written language, such as a letter, number, or symbol. A character can also represent a control character, such as a carriage return or newline, which does not have a written meaning but controls how other characters are stored or displayed. Characters are commonly stored as integers, and encoded using a character map.

=== Integer ===
An integer is a data type that represents one element of a finite subset of mathematical integers. Integer, or Integral, data types can be either unsigned (able to store only positive whole numbers) or signed (able to store either positive or negative whole numbers). The range of values that can be represented by an integer depends on the number of bits used to store the integer, whether or not it is a signed integer, and the encoding scheme (if it is signed). Typically, an integer has a minimum and maximum value, and can store any integer in the range between those values. The minimum value for unsigned integers is typically 0, and the maximum value is typically determined by the amount of memory used to store the integer. For example, a un unsigned 8-bit number can store 2^8 (or 256) possible integral values; and would typically store any value from 0 to 255. More generally, an n-bit unsigned integer can store from 0 to (2^n)-1. For signed integers, modern computers use the Two’s Complement encoding scheme. This allows for a range of −2^(n−1) through 2^(n−1)−1. For example, an 8-bit signed integer could store any whole number in the range from -128 through +127.

=== Floating-Point Number ===
A floating point number is a data type used to represent real numbers in a large range with varying degrees of precision. In this representation, numbers are represented with a variable number of significant digits, and a variable number of exponential digits.

=== Fixed-Point number ===
A fixed-point number is a data type used to represent real numbers. Fixed-point numbers are called fixed-point because they have a set number of digits before and after a decimal mark. In this regard, fixed-point numbers are represented as an integer, but are scaled by a predetermined factor.

Fixed-point numbers are commonly used in microprocessors that do not have a floating-point unit, or in systems in which computational efficiency is critical. Fixed-point numbers can be treated as integers by an arithmetic logic unit (ALU) and scaled after a result is obtained, which can significantly lower the amount of time needed for a processor to obtain the result for some algorithms.

Implementing algorithms using fixed-point arithmetic requires great care, because of the potential for information loss. Fixed-point arithmetic operations -- multiplication in particular, has the potential to cause overflow. Algorithms must be written with care to ensure that each term of an equation has a similar range and that the result will not cause an overflow.

=== Reference ===

A Reference is a data type that enables a program to access another item in memory. A reference differs from other primitive data types in that it does not store data itself; instead it stores a value referring to another data object. References are commonly used to refer to objects of large non-primitive data types. References commonly store the physical memory address of the data that they are referring to. Accessing the data referred to by a Reference is called dereferencing.

== Primitive Data Types in C++ ==

C++ is a statically-typed object oriented language. C++ is based on the C programming language, which is procedural, and adds support for object-oriented code.

These data types are defined in C++: [http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php]

{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
!style="border-style: solid; border-width: 1px" align="left"| Name
!style="border-style: solid; border-width: 1px" align="left"| Size
!style="border-style: solid; border-width: 1px" align="left"| Description
!style="border-style: solid; border-width: 1px" align="left"| Range
|-
| void
| N/A
| the void data type is used to explicitly identify that a data has no type
| N/A
|-
| int
| 32 bits
| simple numerical type
| See [[http://www.jk-technology.com/c/inttypes.html]]
|-
| float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 8 bits
| a char is a single 8-bit character encoded using ASCII
| Ascii character 0x00 through ascii character 0xFF
|}
C++ supports Pointers for all of the types listed in the table above, as well as more complex data types (such as structs). A Pointer in C++ is a data type that stores the physical address of some other data. Pointers are created in C++ by using the * operator. For example, a *Double[] is a pointer to an array of double-precision floating point numbers. C++ Also supports function pointers -- pointers that reference the beginning address of a function in memory. They are commonly used to implement callback functions [http://newty.de/fpt/intro.html#what]

== Primitive Data Types in Java ==

Java is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. These data types are defined in Java: [http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html]
{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
! align="left"|Name
! Size
! Description
! Range
|-
|byte
|8 bits
|signed two's complement integer
|-128 to 127
|-
| short
|16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| int
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| long
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
|float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|}

Java also defines a String class, which is used to create objects of many chars. The String class provides functionality commonly implemented using arrays of chars in other languages, such as C.

Java also defines the 'unsigned' keyword, which can be used to as a modifier to any of the integral types listed in the table above. If the 'unsigned' keyword is used, the integral type will be unsigned instead of signed, and its range will change correspondingly.

Java is capable of using any two objects of the same primitive data type for comparison. Java defines a class for each data type, which have the same name but a capitalized first letter (e.g. Float instead of float). These classes, called wrapper classes provide a series of methods that can manipulate their associated primitive data type, as well as convert to and from other data types.

== Primitive Data Types in C# ==

C# is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. C# has all of the data types that are available in Java, as well as some additional ones.

Similar to Java, C# defines a String class which is used to create objects of many chars. These data types are defined in C#: [http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx]

{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
! align="left"| Name
! .NET Class
! Size
! Description
! Range
|-
|byte
| Byte
| 8 bits
|signed two's complement integer
| -128 to 127
|-
| sbyte
| SByte
| 8 bits
| signed two's complement integer
| -0 to 255
|-
| short
| Int16
| 16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| ushort
| UInt16
| 16 bits
| unsigned integer
| 0 to 65,535
|-
| int
| Int32
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| uint
| UInt32
| 32 bits
| unsigned integer
| 0 to 4,294,967,295
|-
| long
| Int64
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
| ulong
| UInt64
| 64 bits
| unsigned integer
| 0 to 18,446,744,073,709,551,615
|-
|float
| Float
| 32 bits
| single-precision IEEE 754 floating point
| -3.402823e38 to 3.02823e38
|-
| double
| Double
| 64 bits
| double-precision IEEE 754 floating point
| -1.79769313486232e308 to 1.79769313486232e308
|-
| boolean
| Boolean
| 1 bit
| boolean
| false, true
|-
| char
| Char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|-
| object
| Object
| N/A
| Object is the base type of all other types
|-
| string
| String
| N/A
| String is the base type for a sequence of chars
|-
| decimal
| Decimal
| 128
| Decimal is an integral type that can represent a decimal number with 29 significant digits ±1.0 × 10e−28 to ±7.9 × 10e28
|}

Like Java, each primitive data type in C# also has a class associated with it that. These classes serve a similar purpose to their associated ones in Java. They are used for comparison of objects, as well as conversion between other similar types.

== Primitive Objects in Ruby ==
Ruby is a pure object oriented language as compared to languages such as Java or C#, which use a more hybrid approach. In Ruby, all data types are represented as Objects. There are some [http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html inbuilt classes] that are provided to users in Ruby. However, only some of them are a basic building block for forming other types. This subset shown below gives us a list of primitive objects that can be used for data representation and manipulation:

{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
! align="left"| Name
! Description
! Range
|-
| TrueClass
| Singleton instance "true" allowed
| true
|-
| FalseClass
| Singleton instance "false" allowed
| false
|-
| Integer [http://www.ruby-doc.org/core/Integer.html]
| Abstract class that forms the basis for Fixnum and Bignum
| See Fixnum and Bignum
|-
| Fixnum [http://www.ruby-doc.org/core-1.8.7/Fixnum.html]
| Integer representations that fit in native machine word
| Machine architecture dependent. 2^30-1 to -2^30 on 32-bit machines.
|-
| Bignum [http://www.ruby-doc.org/core/Bignum.html]
| Integer representations that do not fit in Fixnum width
| Machine architecture dependent. Values above Fixnum range.
|-
| Float [http://www.ruby-doc.org/core/Float.html]
| Real numbers using double precision representation
| Value after decimal point can be formatted
|-
| String [http://corelib.rubyonrails.org/classes/String.html]
| Contains sequence of characters
| No physical limit, but can be decided by machine architecture
|}

One interesting observation from the above table is that Ruby does not have a Boolean class; instead it has a separate TrueClass and FalseClass [http://www.skorks.com/2009/09/true-false-and-nil-objects-in-ruby].

puts true.class
=> TrueClass
puts false.class
=> FalseClass

Although types such as Array, Hash are also in-built types, they can be further composed of elements that are internally represented in one of the primitive types. Hence, they will not be treated by us as primitive objects, in the traditional definition of the term.
Each of the primitive objects listed above also provide certain convenience methods that are applicable for the underlying type.
For example, the Fixnum, Bignum and Float types provide support for arithmetic operations such as addition (+), subtraction(--), multiplication(*) and so on.
As with all other classes in Ruby, users can add functionality to existing primitive objects by reopening classes. The amount of memory required to implement the primitive objects in Ruby is machine dependent in some cases.

== Merit Analysis of Primitive Types ==
This section deals with a brief analysis of the relative merits and demerits of primitive data types. While we focus on Java or Ruby for this purpose, most of these points are applicable across all object oriented languages.

=== Advantages ===
Primitive types in object oriented languages have certain advantages over their class object counterparts.
* Simplicity: Primitive types/objects provide users a simple mechanism of manipulating data without relying on additional objects to achieve the same functionality. Operations on primitive types are more intuitive.
* Efficiency: This statement is applicable if the underlying primitive object definition is not modified (a feature that languages such as Ruby provide to users). As the representation in memory is designed to be make most efficient use of the underlying datatype, use of primitives can provide a benefit to the user, over the use of class objects to store the same data.
Eg. Java provides wrappers [http://www.glenmccl.com/tip_016.htm] for certain primitive types. There is a certain performance and space cost associated with these.
So, to maximize efficiency, direct use of the primitive types would provide the most benefit.
* Ability to use inbuilt methods: Depending on the primitive type, languages such as Ruby provide methods that can be used specifically to probe or manipulate objects.
Eg. [http://corelib.rubyonrails.org/classes/String.html String] primitive object provides convenience methods such as upcase to convert the entire string to upper case, or capitalize, which converts only the first character to upper case.
* Ease of testing for comparison: With primitive types, the equality testing operators such as == can be used. These essentially compare the values stored in the primitive types. Regular objects also offer the eql? method for testing equality. However, the following are not equivalent:
a=10
=> 10
a==10
=> true
a==10.0
=> true
a.eql?(10.0)
=> false
The reason the .eql? fails is that this operator tests for value and type being the same. 10 is type Fixnum and 10.0 is type Float.
The eql? can be overridden by == for primitive objects if you wish to compare only the values, but that can have a negative impact on performance [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html].

=== Disadvantages ===
* Lack of inheritance capability: The primitive data types in languages such as Java cannot be inherited to create further subtypes.
* Unexpected results due to method overriding: There are certain examples such as [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html], which show that overriding inbuilt methods such as == and eql? can lead to unexpected results.

== Conclusion ==
Object oriented languages have varying levels of support for primitive data types and objects. Whether they are beneficial or not depends on the application to a great deal. If handled correctly, they can make object oriented programs more efficient. However, the user needs to be aware of the underlying representation of these types to handle any unexpected results.

== References ==
# http://en.wikipedia.org/wiki/Primitive_data_type
# http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php
# http://www.jk-technology.com/c/inttypes.html
# http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html
# http://newty.de/fpt/intro.html
# http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
# http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx
# http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html
# http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html
# http://www.glenmccl.com/tip_016.htm
# http://www.skorks.com/2009/09/ruby-equality-and-object-comparison/

CSC/ECE 517 Fall 2011/ch3 3h rr

2011-10-29T21:45:44Z

Rbjeffer:

''3h. Primitive objects. At the beginning of Lecture 11, we discovered that Fixnums and Bignums are handled differently behind the scenes in Ruby. Other languages, like Java, have made similar distinctions. By contrast, languages such as C# and Eiffel try to hide these implementation differences from users. Answer two questions: (1) How have different o-o languages implemented primitive objects? E.g., how are they represented in memory, how are they tested for, do comparisons do anything different than for class objects, etc. (2) What are the advantages and disadvantages of treating primitives differently from class objects in source code?''

== Introduction ==
Programming languages, whether statically or dynamically typed, have support for certain in-built data types. These data types, known as primitive types, are the basic representation of information in programs and have certain fixed attributes for a specific language[http://en.wikipedia.org/wiki/Primitive_data_type]. Statically typed languages such as C++, Java, Perl etc. support primitive data types, whereas with dynamically typed languages such as Ruby, Smalltalk, Lisp etc. they are actually in the form of primitive objects. These primitive types are used to store the basic types of information that a computer can store and manipulate, and can also be used as building blocks for creating more complex data types.
This article explains the way different primitive types are implemented in certain object oriented languages. An analysis of the benefits and drawbacks of such types and the methods used to operate on them is also presented.

== Primitive Types ==
The primitive types commonly included in most programming languages are:
* Boolean
* Character
* Integer
* Floating-point number
* Fixed-point number
* Reference

=== Boolean ===
A Boolean is a primitive data type used to store one of two logical types: true or false. Boolean data types are most commonly used as input paramters to a conditional statement (such as an ‘if’ statement), or as the output of a comparison between two comparable data types. Booleans can be implemented in languages as either a discrete logical type, or implicitly as a numerical type. In many languages, booleans can be implicitly converted to and from integer types.

=== Character ===
A character is a data type that represents an element of a written language, such as a letter, number, or symbol. A character can also represent a control character, such as a carriage return or newline, which does not have a written meaning but controls how other characters are stored or displayed. Characters are commonly stored as integers, and encoded using a character map.

=== Integer ===
An integer is a data type that represents one element of a finite subset of mathematical integers. Integer, or Integral, data types can be either unsigned (able to store only positive whole numbers) or signed (able to store either positive or negative whole numbers). The range of values that can be represented by an integer depends on the number of bits used to store the integer, whether or not it is a signed integer, and the encoding scheme (if it is signed). Typically, an integer has a minimum and maximum value, and can store any integer in the range between those values. The minimum value for unsigned integers is typically 0, and the maximum value is typically determined by the amount of memory used to store the integer. For example, a un unsigned 8-bit number can store 2^8 (or 256) possible integral values; and would typically store any value from 0 to 255. More generally, an n-bit unsigned integer can store from 0 to (2^n)-1. For signed integers, modern computers use the Two’s Complement encoding scheme. This allows for a range of −2^(n−1) through 2^(n−1)−1. For example, an 8-bit signed integer could store any whole number in the range from -128 through +127.

=== Floating-Point Number ===
A floating point number is a data type used to represent real numbers in a large range with varying degrees of precision. In this representation, numbers are represented with a variable number of significant digits, and a variable number of exponential digits.

=== Fixed-Point number ===
A fixed-point number is a data type used to represent real numbers. Fixed-point numbers are called fixed-point because they have a set number of digits before and after a decimal mark. In this regard, fixed-point numbers are represented as an integer, but are scaled by a predetermined factor.

Fixed-point numbers are commonly used in microprocessors that do not have a floating-point unit, or in systems in which computational efficiency is critical. Fixed-point numbers can be treated as integers by an arithmetic logic unit (ALU) and scaled after a result is obtained, which can significantly lower the amount of time needed for a processor to obtain the result for some algorithms.

Implementing algorithms using fixed-point arithmetic requires great care, because of the potential for information loss. Fixed-point arithmetic operations -- multiplication in particular, has the potential to cause overflow. Algorithms must be written with care to ensure that each term of an equation has a similar range and that the result will not cause an overflow.

=== Reference ===

A Reference is a data type that enables a program to access another item in memory. A reference differs from other primitive data types in that it does not store data itself; instead it stores a value referring to another data object. References are commonly used to refer to objects of large non-primitive data types. References commonly store the physical memory address of the data that they are referring to. Accessing the data referred to by a Reference is called dereferencing.

== Primitive Data Types in C++ ==

C++ is a statically-typed object oriented language. C++ is based on the C programming language, which is procedural, and adds support for object-oriented code.

These data types are defined in C++: [http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php]

{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
! align="left"|Name
! Size
! Description
! Range
|-
| void
| N/A
| the void data type is used to explicitly identify that a data has no type
| N/A
|-
| int
| 32 bits
| simple numerical type
| See [[http://www.jk-technology.com/c/inttypes.html]]
|-
| float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 8 bits
| a char is a single 8-bit character encoded using ASCII
| Ascii character 0x00 through ascii character 0xFF
|}
C++ supports Pointers for all of the types listed in the table above, as well as more complex data types (such as structs). A Pointer in C++ is a data type that stores the physical address of some other data. Pointers are created in C++ by using the * operator. For example, a *Double[] is a pointer to an array of double-precision floating point numbers. C++ Also supports function pointers -- pointers that reference the beginning address of a function in memory. They are commonly used to implement callback functions [http://newty.de/fpt/intro.html#what]

== Primitive Data Types in Java ==

Java is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. These data types are defined in Java: [http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html]
{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
! align="left"|Name
! Size
! Description
! Range
|-
|byte
|8 bits
|signed two's complement integer
|-128 to 127
|-
| short
|16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| int
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| long
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
|float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|}

Java also defines a String class, which is used to create objects of many chars. The String class provides functionality commonly implemented using arrays of chars in other languages, such as C.

Java also defines the 'unsigned' keyword, which can be used to as a modifier to any of the integral types listed in the table above. If the 'unsigned' keyword is used, the integral type will be unsigned instead of signed, and its range will change correspondingly.

Java is capable of using any two objects of the same primitive data type for comparison. Java defines a class for each data type, which have the same name but a capitalized first letter (e.g. Float instead of float). These classes, called wrapper classes provide a series of methods that can manipulate their associated primitive data type, as well as convert to and from other data types.

== Primitive Data Types in C# ==

C# is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. C# has all of the data types that are available in Java, as well as some additional ones.

Similar to Java, C# defines a String class which is used to create objects of many chars. These data types are defined in C#: [http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx]

{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
! align="left"| Name
! .NET Class
! Size
! Description
! Range
|-
|byte
| Byte
| 8 bits
|signed two's complement integer
| -128 to 127
|-
| sbyte
| SByte
| 8 bits
| signed two's complement integer
| -0 to 255
|-
| short
| Int16
| 16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| ushort
| UInt16
| 16 bits
| unsigned integer
| 0 to 65,535
|-
| int
| Int32
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| uint
| UInt32
| 32 bits
| unsigned integer
| 0 to 4,294,967,295
|-
| long
| Int64
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
| ulong
| UInt64
| 64 bits
| unsigned integer
| 0 to 18,446,744,073,709,551,615
|-
|float
| Float
| 32 bits
| single-precision IEEE 754 floating point
| -3.402823e38 to 3.02823e38
|-
| double
| Double
| 64 bits
| double-precision IEEE 754 floating point
| -1.79769313486232e308 to 1.79769313486232e308
|-
| boolean
| Boolean
| 1 bit
| boolean
| false, true
|-
| char
| Char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|-
| object
| Object
| N/A
| Object is the base type of all other types
|-
| string
| String
| N/A
| String is the base type for a sequence of chars
|-
| decimal
| Decimal
| 128
| Decimal is an integral type that can represent a decimal number with 29 significant digits ±1.0 × 10e−28 to ±7.9 × 10e28
|}

Like Java, each primitive data type in C# also has a class associated with it that. These classes serve a similar purpose to their associated ones in Java. They are used for comparison of objects, as well as conversion between other similar types.

== Primitive Objects in Ruby ==
Ruby is a pure object oriented language as compared to languages such as Java or C#, which use a more hybrid approach. In Ruby, all data types are represented as Objects. There are some [http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html inbuilt classes] that are provided to users in Ruby. However, only some of them are a basic building block for forming other types. This subset shown below gives us a list of primitive objects that can be used for data representation and manipulation:

{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
! align="left"| Name
! Description
! Range
|-
| TrueClass
| Singleton instance "true" allowed
| true
|-
| FalseClass
| Singleton instance "false" allowed
| false
|-
| Integer [http://www.ruby-doc.org/core/Integer.html]
| Abstract class that forms the basis for Fixnum and Bignum
| See Fixnum and Bignum
|-
| Fixnum [http://www.ruby-doc.org/core-1.8.7/Fixnum.html]
| Integer representations that fit in native machine word
| Machine architecture dependent. 2^30-1 to -2^30 on 32-bit machines.
|-
| Bignum [http://www.ruby-doc.org/core/Bignum.html]
| Integer representations that do not fit in Fixnum width
| Machine architecture dependent. Values above Fixnum range.
|-
| Float [http://www.ruby-doc.org/core/Float.html]
| Real numbers using double precision representation
| Value after decimal point can be formatted
|-
| String [http://corelib.rubyonrails.org/classes/String.html]
| Contains sequence of characters
| No physical limit, but can be decided by machine architecture
|}

One interesting observation from the above table is that Ruby does not have a Boolean class; instead it has a separate TrueClass and FalseClass [http://www.skorks.com/2009/09/true-false-and-nil-objects-in-ruby].

puts true.class
=> TrueClass
puts false.class
=> FalseClass

Although types such as Array, Hash are also in-built types, they can be further composed of elements that are internally represented in one of the primitive types. Hence, they will not be treated by us as primitive objects, in the traditional definition of the term.
Each of the primitive objects listed above also provide certain convenience methods that are applicable for the underlying type.
For example, the Fixnum, Bignum and Float types provide support for arithmetic operations such as addition (+), subtraction(--), multiplication(*) and so on.
As with all other classes in Ruby, users can add functionality to existing primitive objects by reopening classes. The amount of memory required to implement the primitive objects in Ruby is machine dependent in some cases.

== Merit Analysis of Primitive Types ==
This section deals with a brief analysis of the relative merits and demerits of primitive data types. While we focus on Java or Ruby for this purpose, most of these points are applicable across all object oriented languages.

=== Advantages ===
Primitive types in object oriented languages have certain advantages over their class object counterparts.
* Simplicity: Primitive types/objects provide users a simple mechanism of manipulating data without relying on additional objects to achieve the same functionality. Operations on primitive types are more intuitive.
* Efficiency: This statement is applicable if the underlying primitive object definition is not modified (a feature that languages such as Ruby provide to users). As the representation in memory is designed to be make most efficient use of the underlying datatype, use of primitives can provide a benefit to the user, over the use of class objects to store the same data.
Eg. Java provides wrappers [http://www.glenmccl.com/tip_016.htm] for certain primitive types. There is a certain performance and space cost associated with these.
So, to maximize efficiency, direct use of the primitive types would provide the most benefit.
* Ability to use inbuilt methods: Depending on the primitive type, languages such as Ruby provide methods that can be used specifically to probe or manipulate objects.
Eg. [http://corelib.rubyonrails.org/classes/String.html String] primitive object provides convenience methods such as upcase to convert the entire string to upper case, or capitalize, which converts only the first character to upper case.
* Ease of testing for comparison: With primitive types, the equality testing operators such as == can be used. These essentially compare the values stored in the primitive types. Regular objects also offer the eql? method for testing equality. However, the following are not equivalent:
a=10
=> 10
a==10
=> true
a==10.0
=> true
a.eql?(10.0)
=> false
The reason the .eql? fails is that this operator tests for value and type being the same. 10 is type Fixnum and 10.0 is type Float.
The eql? can be overridden by == for primitive objects if you wish to compare only the values, but that can have a negative impact on performance [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html].

=== Disadvantages ===
* Lack of inheritance capability: The primitive data types in languages such as Java cannot be inherited to create further subtypes.
* Unexpected results due to method overriding: There are certain examples such as [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html], which show that overriding inbuilt methods such as == and eql? can lead to unexpected results.

== Conclusion ==
Object oriented languages have varying levels of support for primitive data types and objects. Whether they are beneficial or not depends on the application to a great deal. If handled correctly, they can make object oriented programs more efficient. However, the user needs to be aware of the underlying representation of these types to handle any unexpected results.

== References ==
# http://en.wikipedia.org/wiki/Primitive_data_type
# http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php
# http://www.jk-technology.com/c/inttypes.html
# http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html
# http://newty.de/fpt/intro.html
# http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
# http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx
# http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html
# http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html
# http://www.glenmccl.com/tip_016.htm
# http://www.skorks.com/2009/09/ruby-equality-and-object-comparison/

CSC/ECE 517 Fall 2011/ch3 3h rr

2011-10-29T21:43:16Z

Rbjeffer:

''3h. Primitive objects. At the beginning of Lecture 11, we discovered that Fixnums and Bignums are handled differently behind the scenes in Ruby. Other languages, like Java, have made similar distinctions. By contrast, languages such as C# and Eiffel try to hide these implementation differences from users. Answer two questions: (1) How have different o-o languages implemented primitive objects? E.g., how are they represented in memory, how are they tested for, do comparisons do anything different than for class objects, etc. (2) What are the advantages and disadvantages of treating primitives differently from class objects in source code?''

== Introduction ==
Programming languages, whether statically or dynamically typed, have support for certain in-built data types. These data types, known as primitive types, are the basic representation of information in programs and have certain fixed attributes for a specific language[http://en.wikipedia.org/wiki/Primitive_data_type]. Statically typed languages such as C++, Java, Perl etc. support primitive data types, whereas with dynamically typed languages such as Ruby, Smalltalk, Lisp etc. they are actually in the form of primitive objects. These primitive types are used to store the basic types of information that a computer can store and manipulate, and can also be used as building blocks for creating more complex data types.
This article explains the way different primitive types are implemented in certain object oriented languages. An analysis of the benefits and drawbacks of such types and the methods used to operate on them is also presented.

== Primitive Types ==
The primitive types commonly included in most programming languages are:
* Boolean
* Character
* Integer
* Floating-point number
* Fixed-point number
* Reference

=== Boolean ===
A Boolean is a primitive data type used to store one of two logical types: true or false. Boolean data types are most commonly used as input paramters to a conditional statement (such as an ‘if’ statement), or as the output of a comparison between two comparable data types. Booleans can be implemented in languages as either a discrete logical type, or implicitly as a numerical type. In many languages, booleans can be implicitly converted to and from integer types.

=== Character ===
A character is a data type that represents an element of a written language, such as a letter, number, or symbol. A character can also represent a control character, such as a carriage return or newline, which does not have a written meaning but controls how other characters are stored or displayed. Characters are commonly stored as integers, and encoded using a character map.

=== Integer ===
An integer is a data type that represents one element of a finite subset of mathematical integers. Integer, or Integral, data types can be either unsigned (able to store only positive whole numbers) or signed (able to store either positive or negative whole numbers). The range of values that can be represented by an integer depends on the number of bits used to store the integer, whether or not it is a signed integer, and the encoding scheme (if it is signed). Typically, an integer has a minimum and maximum value, and can store any integer in the range between those values. The minimum value for unsigned integers is typically 0, and the maximum value is typically determined by the amount of memory used to store the integer. For example, a un unsigned 8-bit number can store 2^8 (or 256) possible integral values; and would typically store any value from 0 to 255. More generally, an n-bit unsigned integer can store from 0 to (2^n)-1. For signed integers, modern computers use the Two’s Complement encoding scheme. This allows for a range of −2^(n−1) through 2^(n−1)−1. For example, an 8-bit signed integer could store any whole number in the range from -128 through +127.

=== Floating-Point Number ===
A floating point number is a data type used to represent real numbers in a large range with varying degrees of precision. In this representation, numbers are represented with a variable number of significant digits, and a variable number of exponential digits.

=== Fixed-Point number ===
A fixed-point number is a data type used to represent real numbers. Fixed-point numbers are called fixed-point because they have a set number of digits before and after a decimal mark. In this regard, fixed-point numbers are represented as an integer, but are scaled by a predetermined factor.

Fixed-point numbers are commonly used in microprocessors that do not have a floating-point unit, or in systems in which computational efficiency is critical. Fixed-point numbers can be treated as integers by an arithmetic logic unit (ALU) and scaled after a result is obtained, which can significantly lower the amount of time needed for a processor to obtain the result for some algorithms.

Implementing algorithms using fixed-point arithmetic requires great care, because of the potential for information loss. Fixed-point arithmetic operations -- multiplication in particular, has the potential to cause overflow. Algorithms must be written with care to ensure that each term of an equation has a similar range and that the result will not cause an overflow.

=== Reference ===

A Reference is a data type that enables a program to access another item in memory. A reference differs from other primitive data types in that it does not store data itself; instead it stores a value referring to another data object. References are commonly used to refer to objects of large non-primitive data types. References commonly store the physical memory address of the data that they are referring to. Accessing the data referred to by a Reference is called dereferencing.

== Primitive Data Types in C++ ==

C++ is a statically-typed object oriented language. C++ is based on the C programming language, which is procedural, and adds support for object-oriented code.

These data types are defined in C++: [http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php]

{| cellpadding="2" style="border: 1px solid darkgray;"
! align="left"|Name
! Size
! Description
! Range
|-
| void
| N/A
| the void data type is used to explicitly identify that a data has no type
| N/A
|-
| int
| 32 bits
| simple numerical type
| See [[http://www.jk-technology.com/c/inttypes.html]]
|-
| float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 8 bits
| a char is a single 8-bit character encoded using ASCII
| Ascii character 0x00 through ascii character 0xFF
|}
C++ supports Pointers for all of the types listed in the table above, as well as more complex data types (such as structs). A Pointer in C++ is a data type that stores the physical address of some other data. Pointers are created in C++ by using the * operator. For example, a *Double[] is a pointer to an array of double-precision floating point numbers. C++ Also supports function pointers -- pointers that reference the beginning address of a function in memory. They are commonly used to implement callback functions [http://newty.de/fpt/intro.html#what]

== Primitive Data Types in Java ==

Java is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. These data types are defined in Java: [http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html]
{| cellpadding="2" style="border: 1px solid darkgray;"
! align="left"|Name
! Size
! Description
! Range
|-
|byte
|8 bits
|signed two's complement integer
|-128 to 127
|-
| short
|16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| int
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| long
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
|float
| 32 bits
| single-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| double
| 64 bits
| double-precision IEEE 754 floating point
| See [[http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]]
|-
| boolean
| 1 bit
| boolean
| false, true
|-
| char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|}

Java also defines a String class, which is used to create objects of many chars. The String class provides functionality commonly implemented using arrays of chars in other languages, such as C.

Java also defines the 'unsigned' keyword, which can be used to as a modifier to any of the integral types listed in the table above. If the 'unsigned' keyword is used, the integral type will be unsigned instead of signed, and its range will change correspondingly.

Java is capable of using any two objects of the same primitive data type for comparison. Java defines a class for each data type, which have the same name but a capitalized first letter (e.g. Float instead of float). These classes, called wrapper classes provide a series of methods that can manipulate their associated primitive data type, as well as convert to and from other data types.

== Primitive Data Types in C# ==

C# is a statically-typed object oriented programming language. Primitive types are defined in the language, and conversion between them must be explicitly performed. Primitive data types are created using a keyword, which is also the name of the data type. C# has all of the data types that are available in Java, as well as some additional ones.

Similar to Java, C# defines a String class which is used to create objects of many chars. These data types are defined in C#: [http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx]

{| cellpadding="2" style="border: 1px solid darkgray;"
! align="left"| Name
! .NET Class
! Size
! Description
! Range
|-
|byte
| Byte
| 8 bits
|signed two's complement integer
| -128 to 127
|-
| sbyte
| SByte
| 8 bits
| signed two's complement integer
| -0 to 255
|-
| short
| Int16
| 16 bits
| signed two's complement integer
| -32,768 to 32,767
|-
| ushort
| UInt16
| 16 bits
| unsigned integer
| 0 to 65,535
|-
| int
| Int32
| 32 bits
| signed two's complement integer
| -2,147,483,648 to 2,147,483,647
|-
| uint
| UInt32
| 32 bits
| unsigned integer
| 0 to 4,294,967,295
|-
| long
| Int64
| 64 bits
| signed two's complement integer
| -9,223,372,036,854,775,808 to 9,223,373,036,854,775,807
|-
| ulong
| UInt64
| 64 bits
| unsigned integer
| 0 to 18,446,744,073,709,551,615
|-
|float
| Float
| 32 bits
| single-precision IEEE 754 floating point
| -3.402823e38 to 3.02823e38
|-
| double
| Double
| 64 bits
| double-precision IEEE 754 floating point
| -1.79769313486232e308 to 1.79769313486232e308
|-
| boolean
| Boolean
| 1 bit
| boolean
| false, true
|-
| char
| Char
| 16 bits
| a char is a single 16-bit character encoded using Unicode
| Unicode character \u0000 through unicode character \uffff
|-
| object
| Object
| N/A
| Object is the base type of all other types
|-
| string
| String
| N/A
| String is the base type for a sequence of chars
|-
| decimal
| Decimal
| 128
| Decimal is an integral type that can represent a decimal number with 29 significant digits ±1.0 × 10e−28 to ±7.9 × 10e28
|}

Like Java, each primitive data type in C# also has a class associated with it that. These classes serve a similar purpose to their associated ones in Java. They are used for comparison of objects, as well as conversion between other similar types.

== Primitive Objects in Ruby ==
Ruby is a pure object oriented language as compared to languages such as Java or C#, which use a more hybrid approach. In Ruby, all data types are represented as Objects. There are some [http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html inbuilt classes] that are provided to users in Ruby. However, only some of them are a basic building block for forming other types. This subset shown below gives us a list of primitive objects that can be used for data representation and manipulation:

{| cellpadding="2" style="border: 1px solid darkgray;"
! align="left"| Name
! Description
! Range
|-
| TrueClass
| Singleton instance "true" allowed
| true
|-
| FalseClass
| Singleton instance "false" allowed
| false
|-
| Integer [http://www.ruby-doc.org/core/Integer.html]
| Abstract class that forms the basis for Fixnum and Bignum
| See Fixnum and Bignum
|-
| Fixnum [http://www.ruby-doc.org/core-1.8.7/Fixnum.html]
| Integer representations that fit in native machine word
| Machine architecture dependent. 2^30-1 to -2^30 on 32-bit machines.
|-
| Bignum [http://www.ruby-doc.org/core/Bignum.html]
| Integer representations that do not fit in Fixnum width
| Machine architecture dependent. Values above Fixnum range.
|-
| Float [http://www.ruby-doc.org/core/Float.html]
| Real numbers using double precision representation
| Value after decimal point can be formatted
|-
| String [http://corelib.rubyonrails.org/classes/String.html]
| Contains sequence of characters
| No physical limit, but can be decided by machine architecture
|}

One interesting observation from the above table is that Ruby does not have a Boolean class; instead it has a separate TrueClass and FalseClass [http://www.skorks.com/2009/09/true-false-and-nil-objects-in-ruby].

puts true.class
=> TrueClass
puts false.class
=> FalseClass

Although types such as Array, Hash are also in-built types, they can be further composed of elements that are internally represented in one of the primitive types. Hence, they will not be treated by us as primitive objects, in the traditional definition of the term.
Each of the primitive objects listed above also provide certain convenience methods that are applicable for the underlying type.
For example, the Fixnum, Bignum and Float types provide support for arithmetic operations such as addition (+), subtraction(--), multiplication(*) and so on.
As with all other classes in Ruby, users can add functionality to existing primitive objects by reopening classes. The amount of memory required to implement the primitive objects in Ruby is machine dependent in some cases.

== Merit Analysis of Primitive Types ==
This section deals with a brief analysis of the relative merits and demerits of primitive data types. While we focus on Java or Ruby for this purpose, most of these points are applicable across all object oriented languages.

=== Advantages ===
Primitive types in object oriented languages have certain advantages over their class object counterparts.
* Simplicity: Primitive types/objects provide users a simple mechanism of manipulating data without relying on additional objects to achieve the same functionality. Operations on primitive types are more intuitive.
* Efficiency: This statement is applicable if the underlying primitive object definition is not modified (a feature that languages such as Ruby provide to users). As the representation in memory is designed to be make most efficient use of the underlying datatype, use of primitives can provide a benefit to the user, over the use of class objects to store the same data.
Eg. Java provides wrappers [http://www.glenmccl.com/tip_016.htm] for certain primitive types. There is a certain performance and space cost associated with these.
So, to maximize efficiency, direct use of the primitive types would provide the most benefit.
* Ability to use inbuilt methods: Depending on the primitive type, languages such as Ruby provide methods that can be used specifically to probe or manipulate objects.
Eg. [http://corelib.rubyonrails.org/classes/String.html String] primitive object provides convenience methods such as upcase to convert the entire string to upper case, or capitalize, which converts only the first character to upper case.
* Ease of testing for comparison: With primitive types, the equality testing operators such as == can be used. These essentially compare the values stored in the primitive types. Regular objects also offer the eql? method for testing equality. However, the following are not equivalent:
a=10
=> 10
a==10
=> true
a==10.0
=> true
a.eql?(10.0)
=> false
The reason the .eql? fails is that this operator tests for value and type being the same. 10 is type Fixnum and 10.0 is type Float.
The eql? can be overridden by == for primitive objects if you wish to compare only the values, but that can have a negative impact on performance [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html].

=== Disadvantages ===
* Lack of inheritance capability: The primitive data types in languages such as Java cannot be inherited to create further subtypes.
* Unexpected results due to method overriding: There are certain examples such as [http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html], which show that overriding inbuilt methods such as == and eql? can lead to unexpected results.

== Conclusion ==
Object oriented languages have varying levels of support for primitive data types and objects. Whether they are beneficial or not depends on the application to a great deal. If handled correctly, they can make object oriented programs more efficient. However, the user needs to be aware of the underlying representation of these types to handle any unexpected results.

== References ==
# http://en.wikipedia.org/wiki/Primitive_data_type
# http://sparkcharts.sparknotes.com/cs/cplusplus/section2.php
# http://www.jk-technology.com/c/inttypes.html
# http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html
# http://newty.de/fpt/intro.html
# http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
# http://msdn.microsoft.com/en-us/library/ms228360%28v=vs.80%29.aspx
# http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html
# http://blog.vishnuiyengar.com/2009/09/primitive-obsession-in-ruby-aka-not.html
# http://www.glenmccl.com/tip_016.htm
# http://www.skorks.com/2009/09/ruby-equality-and-object-comparison/

CSC/ECE 517 Fall 2011

2011-10-06T14:19:14Z

Rbjeffer:

[[Link title]]
*[[CSC/ECE 517 Fall 2011/ch1 1a ms]]

*[[CSC/ECE 517 Fall 2011/ch1 1a cs]]

*[[CSC/ECE 517 Fall 2011/ch1 1a ri]]

*[[CSC/ECE 517 Fall 2011/ch1 1a lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1b sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1b ds]]

*[[CSC/ECE 517 Fall 2011/ch1 1b tj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c cm]]

*[[CSC/ECE 517 Fall 2011/ch1 1c sj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c ka]]

*[[CSC/ECE 517 Fall 2011/ch1 1d sr]]

*[[CSC/ECE 517 Fall 2011/ch1 1e vs]]

*[[CSC/ECE 517 Fall 2011/ch1 1e aa]]

*[[CSC/ECE 517 Fall 2011/ch1 1a sc]]

*[[CSC/ECE 517 Fall 2011/ch1 1e dm]]

*[[CSC/ECE 517 Fall 2011/ch1 1e an]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1e lm]]

*[[CSC/ECE 517 Fall 2011/ch1 1g vn]]

*[[CSC/ECE 517 Fall 2011/ch1 1f rs]]

*[[CSC/ECE 517 Fall 2011/ch1 1f sv]]

*[[CSC/ECE 517 Fall 2011/ch1 1g jn]]

*[[CSC/ECE 517 Fall 2011/ch1 1h ps]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sm]]

*[[CSC/ECE 517 Fall 2011/ch1 1i zf]]

*[[CSC/ECE 517 Fall 2011/ch1 1g rn]]

*[[CSC/ECE 517 Fall 2011/ch1 1i cl]]

*[[CSC/ECE 517 Fall 2011/ch1 1d ss]]

*[[CSC/ECE 517 Fall 2011/ch1 1i lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1h hs]]

*[[CSC/ECE 517 Fall 2011/ch1 1d gs]]

*[[CSC/ECE 517 Fall 2011/ch1 2b ns]]

*[[CSC/ECE 517 Fall 2011/ch1 2b jp]]

*[[CSC/ECE 517 Fall 2011/ch1 2a av]]

*[[CSC/ECE 517 Fall 2011/ch2 2f jm]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ad]]

*[[CSC/ECE 517 Fall 2011/ch2 2e kt]]

*[[CSC/ECE 517 Fall 2011/ch2 2e gp]]

*[[CSC/ECE 517 Fall 2011/ch1 2b qu]]

*[[CSC/ECE 517 Fall 2011/ch2 2c bs]]

*[[CSC/ECE 517 Fall 2011/ch1 2c rs]]

*[[CSC/ECE 517 Fall 2011/ch1 2a ca]]

*[[CSC/ECE 517 Fall 2011/ch1 2b rv]]

*[[CSC/ECE 517 Fall 2011/ch2 2c ds]]

*[[CSC/ECE 517 Fall 2011/ch2 2b sa]]

*[[CSC/ECE 517 Fall 2011/ch2 2f vh]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ps]]

*[[CSC/ECE 517 Fall 2011/ch3 3h rr]]

*[[trial]]