Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2011/ch1 1e ap

2011-11-03T22:02:21Z

Pramasw3: /* Design */

Introduction to Object Oriented Design
__TOC__
== Introduction to Object Oriented Programming ==
Object-oriented programming (OOP) is a programming language model organized around "objects" rather than "actions" and data rather than logic. It uses "objects" - data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.

Object-oriented programming takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them. Examples of objects range from human beings (described by name, address, and so forth) to buildings and floors (whose properties can be described and managed) down to the little widgets on your computer desktop (such as buttons and scroll bars).

Object-oriented programming is a method of programming based on a hierarchy of classes, and well-defined and cooperating objects.

*'''Classes'''
The class is the fundamental object-oriented unit. It is a structure that defines the data and the methods to work on that data. Classes define a set of objects that share a common structure and behavior. When you write programs in the Java language, all program data is wrapped in a class.All objects are created from classes, so it important to understand the structure of a class. In fact, it is the design of classes that has fueled the development of various Object Oriented languages.Object is an instance of a class.

*'''Objects'''
An "Object" is binding together of data and behavior, and Object Oriented programming, is the use of objects while solving the problem.
What makes an "object" unique is the formal and explicit combination of these smaller pieces' behavior with its' data into a single entity.

== Object Oriented Design ==

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design. Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis. Much of design involves refining the analysis model through the introduction of classes and algorithms that define exactly how certain required features are realized. Another common design activity is the development of an overall system architecture. This entails organizing the system as a set of major building blocks, such as subsystems or components. For a concurrent system, the architecture includes the basic task or process structure.For a distributed system, it includes the organization of hardware in terms of processors and their interconnections. Basically, object-oriented design (OOD) entails transforming the analysis model into a feasible design. Once the design reaches a sufficient level of specificity, it is translated into an implementation through object-oriented programming. This task can be either relatively straightforward or rather challenging, depending upon the amount of detail in the design.

The first question in OOD ,especially for newcomers, is "How can I decide what classes my program should have in it?" The fundamental rule is that a class should represent some abstraction. For example, a Date class might represent calendar dates, an Integer class might deal with integers, and a Matrix class would represent mathematical matrices. So you need to ask "What kinds of entities does my application manipulate?".

Some examples of potential classes in different application areas would include:

a) GUI/Graphics - Line, Circle, Window, TextArea, Button, Point

b) Architecture - Building, Plot, Room

b) Geography - River, Country, Sea, Continent

Instead of viewing an application as something that performs steps A, B, and C, that is, looking at the program in terms of its functions, instead ask what types of objects and data the application manipulates. Instead of taking a function-oriented approach, take an object-oriented one.

=== Object Oriented Concepts ===
*[http://en.wikipedia.org/wiki/Abstraction_(computer_science) '''Abstraction''']: To implement real world entity into program, class uses the concept of abstraction. Abstraction is a process that involves identifying the crucial behavior of an object and eliminating irrelevant and tedious details.

*[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) '''Encapsulation''']: Binding the data and code to access that data. Encapsulation only refers to a container which has a data and its related functions in it.

*[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) '''Inheritance''']: Defining new classes from the existing one. The new class will get all the methods and properties of the existing class.

*[http://en.wikipedia.org/wiki/Polymorphism_(object-oriented_programming) '''Polymorphism''']: Ability to acquire different forms. There are basically two types of polymorphism. Compile Time (also knows as Early binding) and Run Time (also knows as Late binding) Polymorphism.

*[http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding''']: As encapsulation bind data and methods together, data hiding restrict sensitive data accessing to the system. It is also achieved by using access modifiers i.e. Private, Protected and Public.

== Design principles and patterns ==

=== Object Oriented Design Principles ===

*[http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple '''The LiskovSubstitutionPrinciple (LSP)''']: "An instance of a derived should be able to replace any instance of its superclass"

*[http://c2.com/cgi/wiki?OpenClosedPrinciple '''The OpenClosedPrinciple (OCP)''']: "A reusable class should be open for extension, but closed for modification."

*[http://c2.com/cgi/wiki?DependencyInversionPrinciple '''The DependencyInversionPrinciple (DIP)''']: "The modules that implement a high level policy should not depend on the modules that implement the low level policies, but rather, they should depend on some well-defined interfaces."

*[http://c2.com/cgi/wiki?InterfaceSegregationPrinciple '''The InterfaceSegregationPrinciple (ISP)''']: "The dependency of one class to another one should depend on the smallest possible interface."

*[http://c2.com/cgi/wiki?ReuseReleaseEquivalencePrinciple '''The ReuseReleaseEquivalencePrinciple (REP)''']: "The granule of reuse is the granule of release." module == type, the fusion of distinct notions is what gives OO its distinctive flavor.

*[http://c2.com/cgi/wiki?CommonClosurePrinciple '''The CommonClosurePrinciple (CCP):''']: "The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package."

=== Object Oriented Design Patterns ===

*[http://en.wikipedia.org/wiki/Singleton_pattern '''Singleton'''] - Ensure that only one instance of a class is created and Provide a global access point to the object.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Factory'''] - Creates objects without exposing the instantiation logic to the client and Refers to the newly created object through a common interface.

*[http://en.wikipedia.org/wiki/Command_pattern'''Command'''] - Encapsulate a request in an object, Allows the parameterization of clients with different requests and Allows saving the requests in a queue.

*[http://en.wikipedia.org/wiki/Iterator_pattern '''Iterator'''] - Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Strategy'''] - Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Adapter'''] - Convert the interface of a class into another interface clients expect. / Adapter lets classes work together, that could not otherwise because of incompatible interfaces.

== Examples ==
This section discusses about the ATM example using OOD, developed by Dr.Bjork. The overview of this example is explained below.
Complete example can be found here http://math-cs.gordon.edu/courses/cs211/ATMExample/

The process of object oriented design starts with the requirements followed by analysis, design and the implementation. Let us dicuss about each of these steps in detail.

=== Requirements ===

This design model will help in developing a software that will control a simulated automatic teller machine (ATM).
For a complete list of requirements check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Requirements.html

Though there will be more detailed requirements with secuirty constraints, this page provides the basic requirements an ATM should satisfy.

1.) A customer must be able to make a cash withdrawal from any suitable account linked to the card, in multiples of $20.00. Approval must be obtained from the bank before cash is dispensed.
2.) A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to manual verification when the envelope is removed from the machine by an operator. Approval must be obtained from the bank before physically accepting the envelope.
3.) A customer must be able to make a transfer of money between any two accounts linked to the card.
4.) A customer must be able to make a balance inquiry of any account linked to the card.

=== Analysis ===

The analysis phase involves in finding the use cases, initial test cases and the basic parts (classes) involved in the system.

1.) Use cases:

With the above requirements, we will discuss two important use cases.

Withdrawal Transaction Use Case :

A withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g. checking) from a menu of possible accounts, and to choose a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. (If not, the customer is informed and asked to enter a different amount.) If the transaction is approved by the bank, the appropriate amount of cash is dispensed by the machine before it issues a receipt.

Deposit Transaction Use Case :

A deposit transaction asks the customer to choose a type of account to deposit to (e.g. checking) from a menu of possible accounts, and to type in a dollar amount on the keyboard. The transaction is initially sent to the bank to verify that the ATM can accept a deposit from this customer to this account. If the transaction is approved, the machine accepts an envelope from the customer containing cash and/or checks before it issues a receipt. Once the envelope has been received, a second message is sent to the bank, to confirm that the bank can credit the customer's account - contingent on manual verification of the deposit envelope contents by an operator later.

Use cases are represented using Interaction diagrams. This section is not going to explain the interaction diagrams.
For the interaction diagrams, check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Interactions.html#Startup

2.) Classes

The basic classes of the system can be found using the following conditions

is a singular noun,
does not really have the same functionality as some other class,
is not simply a primitive type.

The classes required for the ATM model will be,

Card reader.
Customer console, consisting of a display and keyboard.
Cash dispenser.
Envelope acceptor.
Receipt printer.
Session.
Transaction.

=== Design ===

The design part includes the process of finding the resposiblities and the interaction of the classes.

The designs can be represented using various methods like

CRC Cards
Class Diagram
State Charts
Interaction Diagrams

In this example we will examine CRC cards closely.

A CRC card has a class name, responsiblities of the class and collobarotars (other classes required to complete the responsiblity).

So for the "Withdrawl" class, a CRC card will be designed as follows,
{| class="wikitable" border="1"
! scope="col" | Responsibilities
! scope="col" | Collaborators
|-
| Perform operations peculiar to withdrawal transaction use case || CustomerConsole

CashDispenser

Message

Receipt
|}

So for the "Deposit" class, a CRC card will be designed as follows,
{| class="wikitable" border="1"
! scope="col" | Responsibilities
! scope="col" | Collaborators
|-
| Perform operations peculiar to deposit transaction use case || CustomerConsole

Message

EnvelopeAcceptor

Receipt
|}
With this the design is complete. So the rest of the software design includes implemenation and testing which will be convered under ibject oriented programming.
http://en.wikipedia.org/wiki/Object-oriented_programming

== Advantages of OOD ==

*'''Simplicity:''' software objects model real world objects, so the complexity is reduced and the program structure is very clear.

*'''Modularity:''' each object forms a separate entity whose internal workings are decoupled from other parts of the system.

*'''Maintainable:''' objects can be maintained separately, making locating and fixing problems easier.

*'''Re-usability:''' objects contain both data and functions that act on data, objects can be thought of as self-contained “boxes”.This feature
makes it easy to reuse code in new systems.

*'''Scalability:''' object’s interface provides a roadmap for reusing the object in new software and thus provides you with all the information
you need to replace the object without affecting other code.

== References ==

* Principles of Object Oriented Design - http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign

* Object Oriented Programming - http://en.wikipedia.org/wiki/Object-oriented_programming

* Object Oriented Design - http://en.wikipedia.org/wiki/Object-oriented_design

* Object Oriented Concepts - http://download.oracle.com/javase/tutorial/java/concepts

* ATM example - http://math-cs.gordon.edu/courses/cs211/ATMExample/

CSC/ECE 517 Fall 2011/ch1 1e ap

2011-11-03T22:01:38Z

Pramasw3: /* Design */

Introduction to Object Oriented Design
__TOC__
== Introduction to Object Oriented Programming ==
Object-oriented programming (OOP) is a programming language model organized around "objects" rather than "actions" and data rather than logic. It uses "objects" - data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.

Object-oriented programming takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them. Examples of objects range from human beings (described by name, address, and so forth) to buildings and floors (whose properties can be described and managed) down to the little widgets on your computer desktop (such as buttons and scroll bars).

Object-oriented programming is a method of programming based on a hierarchy of classes, and well-defined and cooperating objects.

*'''Classes'''
The class is the fundamental object-oriented unit. It is a structure that defines the data and the methods to work on that data. Classes define a set of objects that share a common structure and behavior. When you write programs in the Java language, all program data is wrapped in a class.All objects are created from classes, so it important to understand the structure of a class. In fact, it is the design of classes that has fueled the development of various Object Oriented languages.Object is an instance of a class.

*'''Objects'''
An "Object" is binding together of data and behavior, and Object Oriented programming, is the use of objects while solving the problem.
What makes an "object" unique is the formal and explicit combination of these smaller pieces' behavior with its' data into a single entity.

== Object Oriented Design ==

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design. Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis. Much of design involves refining the analysis model through the introduction of classes and algorithms that define exactly how certain required features are realized. Another common design activity is the development of an overall system architecture. This entails organizing the system as a set of major building blocks, such as subsystems or components. For a concurrent system, the architecture includes the basic task or process structure.For a distributed system, it includes the organization of hardware in terms of processors and their interconnections. Basically, object-oriented design (OOD) entails transforming the analysis model into a feasible design. Once the design reaches a sufficient level of specificity, it is translated into an implementation through object-oriented programming. This task can be either relatively straightforward or rather challenging, depending upon the amount of detail in the design.

The first question in OOD ,especially for newcomers, is "How can I decide what classes my program should have in it?" The fundamental rule is that a class should represent some abstraction. For example, a Date class might represent calendar dates, an Integer class might deal with integers, and a Matrix class would represent mathematical matrices. So you need to ask "What kinds of entities does my application manipulate?".

Some examples of potential classes in different application areas would include:

a) GUI/Graphics - Line, Circle, Window, TextArea, Button, Point

b) Architecture - Building, Plot, Room

b) Geography - River, Country, Sea, Continent

Instead of viewing an application as something that performs steps A, B, and C, that is, looking at the program in terms of its functions, instead ask what types of objects and data the application manipulates. Instead of taking a function-oriented approach, take an object-oriented one.

=== Object Oriented Concepts ===
*[http://en.wikipedia.org/wiki/Abstraction_(computer_science) '''Abstraction''']: To implement real world entity into program, class uses the concept of abstraction. Abstraction is a process that involves identifying the crucial behavior of an object and eliminating irrelevant and tedious details.

*[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) '''Encapsulation''']: Binding the data and code to access that data. Encapsulation only refers to a container which has a data and its related functions in it.

*[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) '''Inheritance''']: Defining new classes from the existing one. The new class will get all the methods and properties of the existing class.

*[http://en.wikipedia.org/wiki/Polymorphism_(object-oriented_programming) '''Polymorphism''']: Ability to acquire different forms. There are basically two types of polymorphism. Compile Time (also knows as Early binding) and Run Time (also knows as Late binding) Polymorphism.

*[http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding''']: As encapsulation bind data and methods together, data hiding restrict sensitive data accessing to the system. It is also achieved by using access modifiers i.e. Private, Protected and Public.

== Design principles and patterns ==

=== Object Oriented Design Principles ===

*[http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple '''The LiskovSubstitutionPrinciple (LSP)''']: "An instance of a derived should be able to replace any instance of its superclass"

*[http://c2.com/cgi/wiki?OpenClosedPrinciple '''The OpenClosedPrinciple (OCP)''']: "A reusable class should be open for extension, but closed for modification."

*[http://c2.com/cgi/wiki?DependencyInversionPrinciple '''The DependencyInversionPrinciple (DIP)''']: "The modules that implement a high level policy should not depend on the modules that implement the low level policies, but rather, they should depend on some well-defined interfaces."

*[http://c2.com/cgi/wiki?InterfaceSegregationPrinciple '''The InterfaceSegregationPrinciple (ISP)''']: "The dependency of one class to another one should depend on the smallest possible interface."

*[http://c2.com/cgi/wiki?ReuseReleaseEquivalencePrinciple '''The ReuseReleaseEquivalencePrinciple (REP)''']: "The granule of reuse is the granule of release." module == type, the fusion of distinct notions is what gives OO its distinctive flavor.

*[http://c2.com/cgi/wiki?CommonClosurePrinciple '''The CommonClosurePrinciple (CCP):''']: "The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package."

=== Object Oriented Design Patterns ===

*[http://en.wikipedia.org/wiki/Singleton_pattern '''Singleton'''] - Ensure that only one instance of a class is created and Provide a global access point to the object.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Factory'''] - Creates objects without exposing the instantiation logic to the client and Refers to the newly created object through a common interface.

*[http://en.wikipedia.org/wiki/Command_pattern'''Command'''] - Encapsulate a request in an object, Allows the parameterization of clients with different requests and Allows saving the requests in a queue.

*[http://en.wikipedia.org/wiki/Iterator_pattern '''Iterator'''] - Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Strategy'''] - Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Adapter'''] - Convert the interface of a class into another interface clients expect. / Adapter lets classes work together, that could not otherwise because of incompatible interfaces.

== Examples ==
This section discusses about the ATM example using OOD, developed by Dr.Bjork. The overview of this example is explained below.
Complete example can be found here http://math-cs.gordon.edu/courses/cs211/ATMExample/

The process of object oriented design starts with the requirements followed by analysis, design and the implementation. Let us dicuss about each of these steps in detail.

=== Requirements ===

This design model will help in developing a software that will control a simulated automatic teller machine (ATM).
For a complete list of requirements check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Requirements.html

Though there will be more detailed requirements with secuirty constraints, this page provides the basic requirements an ATM should satisfy.

1.) A customer must be able to make a cash withdrawal from any suitable account linked to the card, in multiples of $20.00. Approval must be obtained from the bank before cash is dispensed.
2.) A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to manual verification when the envelope is removed from the machine by an operator. Approval must be obtained from the bank before physically accepting the envelope.
3.) A customer must be able to make a transfer of money between any two accounts linked to the card.
4.) A customer must be able to make a balance inquiry of any account linked to the card.

=== Analysis ===

The analysis phase involves in finding the use cases, initial test cases and the basic parts (classes) involved in the system.

1.) Use cases:

With the above requirements, we will discuss two important use cases.

Withdrawal Transaction Use Case :

A withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g. checking) from a menu of possible accounts, and to choose a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. (If not, the customer is informed and asked to enter a different amount.) If the transaction is approved by the bank, the appropriate amount of cash is dispensed by the machine before it issues a receipt.

Deposit Transaction Use Case :

A deposit transaction asks the customer to choose a type of account to deposit to (e.g. checking) from a menu of possible accounts, and to type in a dollar amount on the keyboard. The transaction is initially sent to the bank to verify that the ATM can accept a deposit from this customer to this account. If the transaction is approved, the machine accepts an envelope from the customer containing cash and/or checks before it issues a receipt. Once the envelope has been received, a second message is sent to the bank, to confirm that the bank can credit the customer's account - contingent on manual verification of the deposit envelope contents by an operator later.

Use cases are represented using Interaction diagrams. This section is not going to explain the interaction diagrams.
For the interaction diagrams, check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Interactions.html#Startup

2.) Classes

The basic classes of the system can be found using the following conditions

is a singular noun,
does not really have the same functionality as some other class,
is not simply a primitive type.

The classes required for the ATM model will be,

Card reader.
Customer console, consisting of a display and keyboard.
Cash dispenser.
Envelope acceptor.
Receipt printer.
Session.
Transaction.

=== Design ===

The design part includes the process of finding the resposiblities and the interaction of the classes.

The designs can be represented using various methods like

CRC Cards
Class Diagram
State Charts
Interaction Diagrams

In this example we will examine CRC cards closely.

A CRC card has a class name, responsiblities of the class and collobarotars (other classes required to complete the responsiblity).

So for the "Withdrawl" class, a CRC card will be designed as follows,
{| class="wikitable" border="1"
! scope="col" | Responsibilities
! scope="col" | Collaborators
|-
| Perform operations peculiar to withdrawal transaction use case || CustomerConsole

CashDispenser

Message

Receipt
|}

{| class="wikitable" border="1"
! scope="col" | Responsibilities
! scope="col" | Collaborators
|-
| Perform operations peculiar to deposit transaction use case || CustomerConsole

Message

EnvelopeAcceptor

Receipt
|}
With this the design is complete. So the rest of the software design includes implemenation and testing which will be convered under ibject oriented programming.
http://en.wikipedia.org/wiki/Object-oriented_programming

== Advantages of OOD ==

*'''Simplicity:''' software objects model real world objects, so the complexity is reduced and the program structure is very clear.

*'''Modularity:''' each object forms a separate entity whose internal workings are decoupled from other parts of the system.

*'''Maintainable:''' objects can be maintained separately, making locating and fixing problems easier.

*'''Re-usability:''' objects contain both data and functions that act on data, objects can be thought of as self-contained “boxes”.This feature
makes it easy to reuse code in new systems.

*'''Scalability:''' object’s interface provides a roadmap for reusing the object in new software and thus provides you with all the information
you need to replace the object without affecting other code.

== References ==

* Principles of Object Oriented Design - http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign

* Object Oriented Programming - http://en.wikipedia.org/wiki/Object-oriented_programming

* Object Oriented Design - http://en.wikipedia.org/wiki/Object-oriented_design

* Object Oriented Concepts - http://download.oracle.com/javase/tutorial/java/concepts

* ATM example - http://math-cs.gordon.edu/courses/cs211/ATMExample/

CSC/ECE 517 Fall 2011/ch1 1e ap

2011-11-03T22:00:17Z

Pramasw3: /* Design */

Introduction to Object Oriented Design
__TOC__
== Introduction to Object Oriented Programming ==
Object-oriented programming (OOP) is a programming language model organized around "objects" rather than "actions" and data rather than logic. It uses "objects" - data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.

Object-oriented programming takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them. Examples of objects range from human beings (described by name, address, and so forth) to buildings and floors (whose properties can be described and managed) down to the little widgets on your computer desktop (such as buttons and scroll bars).

Object-oriented programming is a method of programming based on a hierarchy of classes, and well-defined and cooperating objects.

*'''Classes'''
The class is the fundamental object-oriented unit. It is a structure that defines the data and the methods to work on that data. Classes define a set of objects that share a common structure and behavior. When you write programs in the Java language, all program data is wrapped in a class.All objects are created from classes, so it important to understand the structure of a class. In fact, it is the design of classes that has fueled the development of various Object Oriented languages.Object is an instance of a class.

*'''Objects'''
An "Object" is binding together of data and behavior, and Object Oriented programming, is the use of objects while solving the problem.
What makes an "object" unique is the formal and explicit combination of these smaller pieces' behavior with its' data into a single entity.

== Object Oriented Design ==

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design. Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis. Much of design involves refining the analysis model through the introduction of classes and algorithms that define exactly how certain required features are realized. Another common design activity is the development of an overall system architecture. This entails organizing the system as a set of major building blocks, such as subsystems or components. For a concurrent system, the architecture includes the basic task or process structure.For a distributed system, it includes the organization of hardware in terms of processors and their interconnections. Basically, object-oriented design (OOD) entails transforming the analysis model into a feasible design. Once the design reaches a sufficient level of specificity, it is translated into an implementation through object-oriented programming. This task can be either relatively straightforward or rather challenging, depending upon the amount of detail in the design.

The first question in OOD ,especially for newcomers, is "How can I decide what classes my program should have in it?" The fundamental rule is that a class should represent some abstraction. For example, a Date class might represent calendar dates, an Integer class might deal with integers, and a Matrix class would represent mathematical matrices. So you need to ask "What kinds of entities does my application manipulate?".

Some examples of potential classes in different application areas would include:

a) GUI/Graphics - Line, Circle, Window, TextArea, Button, Point

b) Architecture - Building, Plot, Room

b) Geography - River, Country, Sea, Continent

Instead of viewing an application as something that performs steps A, B, and C, that is, looking at the program in terms of its functions, instead ask what types of objects and data the application manipulates. Instead of taking a function-oriented approach, take an object-oriented one.

=== Object Oriented Concepts ===
*[http://en.wikipedia.org/wiki/Abstraction_(computer_science) '''Abstraction''']: To implement real world entity into program, class uses the concept of abstraction. Abstraction is a process that involves identifying the crucial behavior of an object and eliminating irrelevant and tedious details.

*[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) '''Encapsulation''']: Binding the data and code to access that data. Encapsulation only refers to a container which has a data and its related functions in it.

*[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) '''Inheritance''']: Defining new classes from the existing one. The new class will get all the methods and properties of the existing class.

*[http://en.wikipedia.org/wiki/Polymorphism_(object-oriented_programming) '''Polymorphism''']: Ability to acquire different forms. There are basically two types of polymorphism. Compile Time (also knows as Early binding) and Run Time (also knows as Late binding) Polymorphism.

*[http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding''']: As encapsulation bind data and methods together, data hiding restrict sensitive data accessing to the system. It is also achieved by using access modifiers i.e. Private, Protected and Public.

== Design principles and patterns ==

=== Object Oriented Design Principles ===

*[http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple '''The LiskovSubstitutionPrinciple (LSP)''']: "An instance of a derived should be able to replace any instance of its superclass"

*[http://c2.com/cgi/wiki?OpenClosedPrinciple '''The OpenClosedPrinciple (OCP)''']: "A reusable class should be open for extension, but closed for modification."

*[http://c2.com/cgi/wiki?DependencyInversionPrinciple '''The DependencyInversionPrinciple (DIP)''']: "The modules that implement a high level policy should not depend on the modules that implement the low level policies, but rather, they should depend on some well-defined interfaces."

*[http://c2.com/cgi/wiki?InterfaceSegregationPrinciple '''The InterfaceSegregationPrinciple (ISP)''']: "The dependency of one class to another one should depend on the smallest possible interface."

*[http://c2.com/cgi/wiki?ReuseReleaseEquivalencePrinciple '''The ReuseReleaseEquivalencePrinciple (REP)''']: "The granule of reuse is the granule of release." module == type, the fusion of distinct notions is what gives OO its distinctive flavor.

*[http://c2.com/cgi/wiki?CommonClosurePrinciple '''The CommonClosurePrinciple (CCP):''']: "The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package."

=== Object Oriented Design Patterns ===

*[http://en.wikipedia.org/wiki/Singleton_pattern '''Singleton'''] - Ensure that only one instance of a class is created and Provide a global access point to the object.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Factory'''] - Creates objects without exposing the instantiation logic to the client and Refers to the newly created object through a common interface.

*[http://en.wikipedia.org/wiki/Command_pattern'''Command'''] - Encapsulate a request in an object, Allows the parameterization of clients with different requests and Allows saving the requests in a queue.

*[http://en.wikipedia.org/wiki/Iterator_pattern '''Iterator'''] - Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Strategy'''] - Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Adapter'''] - Convert the interface of a class into another interface clients expect. / Adapter lets classes work together, that could not otherwise because of incompatible interfaces.

== Examples ==
This section discusses about the ATM example using OOD, developed by Dr.Bjork. The overview of this example is explained below.
Complete example can be found here http://math-cs.gordon.edu/courses/cs211/ATMExample/

The process of object oriented design starts with the requirements followed by analysis, design and the implementation. Let us dicuss about each of these steps in detail.

=== Requirements ===

This design model will help in developing a software that will control a simulated automatic teller machine (ATM).
For a complete list of requirements check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Requirements.html

Though there will be more detailed requirements with secuirty constraints, this page provides the basic requirements an ATM should satisfy.

1.) A customer must be able to make a cash withdrawal from any suitable account linked to the card, in multiples of $20.00. Approval must be obtained from the bank before cash is dispensed.
2.) A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to manual verification when the envelope is removed from the machine by an operator. Approval must be obtained from the bank before physically accepting the envelope.
3.) A customer must be able to make a transfer of money between any two accounts linked to the card.
4.) A customer must be able to make a balance inquiry of any account linked to the card.

=== Analysis ===

The analysis phase involves in finding the use cases, initial test cases and the basic parts (classes) involved in the system.

1.) Use cases:

With the above requirements, we will discuss two important use cases.

Withdrawal Transaction Use Case :

A withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g. checking) from a menu of possible accounts, and to choose a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. (If not, the customer is informed and asked to enter a different amount.) If the transaction is approved by the bank, the appropriate amount of cash is dispensed by the machine before it issues a receipt.

Deposit Transaction Use Case :

A deposit transaction asks the customer to choose a type of account to deposit to (e.g. checking) from a menu of possible accounts, and to type in a dollar amount on the keyboard. The transaction is initially sent to the bank to verify that the ATM can accept a deposit from this customer to this account. If the transaction is approved, the machine accepts an envelope from the customer containing cash and/or checks before it issues a receipt. Once the envelope has been received, a second message is sent to the bank, to confirm that the bank can credit the customer's account - contingent on manual verification of the deposit envelope contents by an operator later.

Use cases are represented using Interaction diagrams. This section is not going to explain the interaction diagrams.
For the interaction diagrams, check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Interactions.html#Startup

2.) Classes

The basic classes of the system can be found using the following conditions

is a singular noun,
does not really have the same functionality as some other class,
is not simply a primitive type.

The classes required for the ATM model will be,

Card reader.
Customer console, consisting of a display and keyboard.
Cash dispenser.
Envelope acceptor.
Receipt printer.
Session.
Transaction.

=== Design ===

The design part includes the process of finding the resposiblities and the interaction of the classes.

The designs can be represented using various methods like

CRC Cards
Class Diagram
State Charts
Interaction Diagrams

In this example we will examine CRC cards closely.

A CRC card has a class name, responsiblities of the class and collobarotars (other classes required to complete the responsiblity).

So for the "Withdrawl" class, a CRC card will be designed as follows,
{| class="wikitable" border="1"
! scope="col" | Responsibilities
! scope="col" | Collaborators
|-
| Perform operations peculiar to withdrawal transaction use case || CustomerConsole

CashDispenser

Message

Receipt
|}

With this the design is complete. So the rest of the software design includes implemenation and testing which will be convered under ibject oriented programming.
http://en.wikipedia.org/wiki/Object-oriented_programming

== Advantages of OOD ==

*'''Simplicity:''' software objects model real world objects, so the complexity is reduced and the program structure is very clear.

*'''Modularity:''' each object forms a separate entity whose internal workings are decoupled from other parts of the system.

*'''Maintainable:''' objects can be maintained separately, making locating and fixing problems easier.

*'''Re-usability:''' objects contain both data and functions that act on data, objects can be thought of as self-contained “boxes”.This feature
makes it easy to reuse code in new systems.

*'''Scalability:''' object’s interface provides a roadmap for reusing the object in new software and thus provides you with all the information
you need to replace the object without affecting other code.

== References ==

* Principles of Object Oriented Design - http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign

* Object Oriented Programming - http://en.wikipedia.org/wiki/Object-oriented_programming

* Object Oriented Design - http://en.wikipedia.org/wiki/Object-oriented_design

* Object Oriented Concepts - http://download.oracle.com/javase/tutorial/java/concepts

* ATM example - http://math-cs.gordon.edu/courses/cs211/ATMExample/

CSC/ECE 517 Fall 2011/ch1 1e ap

2011-11-03T21:55:04Z

Pramasw3: /* Design */

Introduction to Object Oriented Design
__TOC__
== Introduction to Object Oriented Programming ==
Object-oriented programming (OOP) is a programming language model organized around "objects" rather than "actions" and data rather than logic. It uses "objects" - data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.

Object-oriented programming takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them. Examples of objects range from human beings (described by name, address, and so forth) to buildings and floors (whose properties can be described and managed) down to the little widgets on your computer desktop (such as buttons and scroll bars).

Object-oriented programming is a method of programming based on a hierarchy of classes, and well-defined and cooperating objects.

*'''Classes'''
The class is the fundamental object-oriented unit. It is a structure that defines the data and the methods to work on that data. Classes define a set of objects that share a common structure and behavior. When you write programs in the Java language, all program data is wrapped in a class.All objects are created from classes, so it important to understand the structure of a class. In fact, it is the design of classes that has fueled the development of various Object Oriented languages.Object is an instance of a class.

*'''Objects'''
An "Object" is binding together of data and behavior, and Object Oriented programming, is the use of objects while solving the problem.
What makes an "object" unique is the formal and explicit combination of these smaller pieces' behavior with its' data into a single entity.

== Object Oriented Design ==

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design. Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis. Much of design involves refining the analysis model through the introduction of classes and algorithms that define exactly how certain required features are realized. Another common design activity is the development of an overall system architecture. This entails organizing the system as a set of major building blocks, such as subsystems or components. For a concurrent system, the architecture includes the basic task or process structure.For a distributed system, it includes the organization of hardware in terms of processors and their interconnections. Basically, object-oriented design (OOD) entails transforming the analysis model into a feasible design. Once the design reaches a sufficient level of specificity, it is translated into an implementation through object-oriented programming. This task can be either relatively straightforward or rather challenging, depending upon the amount of detail in the design.

The first question in OOD ,especially for newcomers, is "How can I decide what classes my program should have in it?" The fundamental rule is that a class should represent some abstraction. For example, a Date class might represent calendar dates, an Integer class might deal with integers, and a Matrix class would represent mathematical matrices. So you need to ask "What kinds of entities does my application manipulate?".

Some examples of potential classes in different application areas would include:

a) GUI/Graphics - Line, Circle, Window, TextArea, Button, Point

b) Architecture - Building, Plot, Room

b) Geography - River, Country, Sea, Continent

Instead of viewing an application as something that performs steps A, B, and C, that is, looking at the program in terms of its functions, instead ask what types of objects and data the application manipulates. Instead of taking a function-oriented approach, take an object-oriented one.

=== Object Oriented Concepts ===
*[http://en.wikipedia.org/wiki/Abstraction_(computer_science) '''Abstraction''']: To implement real world entity into program, class uses the concept of abstraction. Abstraction is a process that involves identifying the crucial behavior of an object and eliminating irrelevant and tedious details.

*[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) '''Encapsulation''']: Binding the data and code to access that data. Encapsulation only refers to a container which has a data and its related functions in it.

*[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) '''Inheritance''']: Defining new classes from the existing one. The new class will get all the methods and properties of the existing class.

*[http://en.wikipedia.org/wiki/Polymorphism_(object-oriented_programming) '''Polymorphism''']: Ability to acquire different forms. There are basically two types of polymorphism. Compile Time (also knows as Early binding) and Run Time (also knows as Late binding) Polymorphism.

*[http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding''']: As encapsulation bind data and methods together, data hiding restrict sensitive data accessing to the system. It is also achieved by using access modifiers i.e. Private, Protected and Public.

== Design principles and patterns ==

=== Object Oriented Design Principles ===

*[http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple '''The LiskovSubstitutionPrinciple (LSP)''']: "An instance of a derived should be able to replace any instance of its superclass"

*[http://c2.com/cgi/wiki?OpenClosedPrinciple '''The OpenClosedPrinciple (OCP)''']: "A reusable class should be open for extension, but closed for modification."

*[http://c2.com/cgi/wiki?DependencyInversionPrinciple '''The DependencyInversionPrinciple (DIP)''']: "The modules that implement a high level policy should not depend on the modules that implement the low level policies, but rather, they should depend on some well-defined interfaces."

*[http://c2.com/cgi/wiki?InterfaceSegregationPrinciple '''The InterfaceSegregationPrinciple (ISP)''']: "The dependency of one class to another one should depend on the smallest possible interface."

*[http://c2.com/cgi/wiki?ReuseReleaseEquivalencePrinciple '''The ReuseReleaseEquivalencePrinciple (REP)''']: "The granule of reuse is the granule of release." module == type, the fusion of distinct notions is what gives OO its distinctive flavor.

*[http://c2.com/cgi/wiki?CommonClosurePrinciple '''The CommonClosurePrinciple (CCP):''']: "The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package."

=== Object Oriented Design Patterns ===

*[http://en.wikipedia.org/wiki/Singleton_pattern '''Singleton'''] - Ensure that only one instance of a class is created and Provide a global access point to the object.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Factory'''] - Creates objects without exposing the instantiation logic to the client and Refers to the newly created object through a common interface.

*[http://en.wikipedia.org/wiki/Command_pattern'''Command'''] - Encapsulate a request in an object, Allows the parameterization of clients with different requests and Allows saving the requests in a queue.

*[http://en.wikipedia.org/wiki/Iterator_pattern '''Iterator'''] - Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Strategy'''] - Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Adapter'''] - Convert the interface of a class into another interface clients expect. / Adapter lets classes work together, that could not otherwise because of incompatible interfaces.

== Examples ==
This section discusses about the ATM example using OOD, developed by Dr.Bjork. The overview of this example is explained below.
Complete example can be found here http://math-cs.gordon.edu/courses/cs211/ATMExample/

The process of object oriented design starts with the requirements followed by analysis, design and the implementation. Let us dicuss about each of these steps in detail.

=== Requirements ===

This design model will help in developing a software that will control a simulated automatic teller machine (ATM).
For a complete list of requirements check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Requirements.html

Though there will be more detailed requirements with secuirty constraints, this page provides the basic requirements an ATM should satisfy.

1.) A customer must be able to make a cash withdrawal from any suitable account linked to the card, in multiples of $20.00. Approval must be obtained from the bank before cash is dispensed.
2.) A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to manual verification when the envelope is removed from the machine by an operator. Approval must be obtained from the bank before physically accepting the envelope.
3.) A customer must be able to make a transfer of money between any two accounts linked to the card.
4.) A customer must be able to make a balance inquiry of any account linked to the card.

=== Analysis ===

The analysis phase involves in finding the use cases, initial test cases and the basic parts (classes) involved in the system.

1.) Use cases:

With the above requirements, we will discuss two important use cases.

Withdrawal Transaction Use Case :

A withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g. checking) from a menu of possible accounts, and to choose a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. (If not, the customer is informed and asked to enter a different amount.) If the transaction is approved by the bank, the appropriate amount of cash is dispensed by the machine before it issues a receipt.

Deposit Transaction Use Case :

A deposit transaction asks the customer to choose a type of account to deposit to (e.g. checking) from a menu of possible accounts, and to type in a dollar amount on the keyboard. The transaction is initially sent to the bank to verify that the ATM can accept a deposit from this customer to this account. If the transaction is approved, the machine accepts an envelope from the customer containing cash and/or checks before it issues a receipt. Once the envelope has been received, a second message is sent to the bank, to confirm that the bank can credit the customer's account - contingent on manual verification of the deposit envelope contents by an operator later.

Use cases are represented using Interaction diagrams. This section is not going to explain the interaction diagrams.
For the interaction diagrams, check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Interactions.html#Startup

2.) Classes

The basic classes of the system can be found using the following conditions

is a singular noun,
does not really have the same functionality as some other class,
is not simply a primitive type.

The classes required for the ATM model will be,

Card reader.
Customer console, consisting of a display and keyboard.
Cash dispenser.
Envelope acceptor.
Receipt printer.
Session.
Transaction.

=== Design ===

The design part includes the process of finding the resposiblities and the interaction of the classes.

The designs can be represented using various methods like

CRC Cards
Class Diagram
State Charts
Interaction Diagrams

In this example we will examine CRC cards closely.

A CRC card has a class name, responsiblities of the class and collobarotars (other classes required to complete the responsiblity).

So for the "Withdrawl" class, a CRC card will be designed as follows,
{| class="wikitable" border="1"
! scope="col" | Responsibilities
! scope="col" | Collaborators

|-
| Perform operations peculiar to withdrawal transaction use case || CustomerConsole

CashDispenser

Message

Receipt

|}

With this the design is complete. So the rest of the software design includes implemenation and testing which will be convered under ibject oriented programming.
http://en.wikipedia.org/wiki/Object-oriented_programming

== Advantages of OOD ==

*'''Simplicity:''' software objects model real world objects, so the complexity is reduced and the program structure is very clear.

*'''Modularity:''' each object forms a separate entity whose internal workings are decoupled from other parts of the system.

*'''Maintainable:''' objects can be maintained separately, making locating and fixing problems easier.

*'''Re-usability:''' objects contain both data and functions that act on data, objects can be thought of as self-contained “boxes”.This feature
makes it easy to reuse code in new systems.

*'''Scalability:''' object’s interface provides a roadmap for reusing the object in new software and thus provides you with all the information
you need to replace the object without affecting other code.

== References ==

* Principles of Object Oriented Design - http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign

* Object Oriented Programming - http://en.wikipedia.org/wiki/Object-oriented_programming

* Object Oriented Design - http://en.wikipedia.org/wiki/Object-oriented_design

* Object Oriented Concepts - http://download.oracle.com/javase/tutorial/java/concepts

* ATM example - http://math-cs.gordon.edu/courses/cs211/ATMExample/

CSC/ECE 517 Fall 2011/ch1 1e ap

2011-11-03T21:53:47Z

Pramasw3: /* Design */

Introduction to Object Oriented Design
__TOC__
== Introduction to Object Oriented Programming ==
Object-oriented programming (OOP) is a programming language model organized around "objects" rather than "actions" and data rather than logic. It uses "objects" - data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.

Object-oriented programming takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them. Examples of objects range from human beings (described by name, address, and so forth) to buildings and floors (whose properties can be described and managed) down to the little widgets on your computer desktop (such as buttons and scroll bars).

Object-oriented programming is a method of programming based on a hierarchy of classes, and well-defined and cooperating objects.

*'''Classes'''
The class is the fundamental object-oriented unit. It is a structure that defines the data and the methods to work on that data. Classes define a set of objects that share a common structure and behavior. When you write programs in the Java language, all program data is wrapped in a class.All objects are created from classes, so it important to understand the structure of a class. In fact, it is the design of classes that has fueled the development of various Object Oriented languages.Object is an instance of a class.

*'''Objects'''
An "Object" is binding together of data and behavior, and Object Oriented programming, is the use of objects while solving the problem.
What makes an "object" unique is the formal and explicit combination of these smaller pieces' behavior with its' data into a single entity.

== Object Oriented Design ==

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design. Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis. Much of design involves refining the analysis model through the introduction of classes and algorithms that define exactly how certain required features are realized. Another common design activity is the development of an overall system architecture. This entails organizing the system as a set of major building blocks, such as subsystems or components. For a concurrent system, the architecture includes the basic task or process structure.For a distributed system, it includes the organization of hardware in terms of processors and their interconnections. Basically, object-oriented design (OOD) entails transforming the analysis model into a feasible design. Once the design reaches a sufficient level of specificity, it is translated into an implementation through object-oriented programming. This task can be either relatively straightforward or rather challenging, depending upon the amount of detail in the design.

The first question in OOD ,especially for newcomers, is "How can I decide what classes my program should have in it?" The fundamental rule is that a class should represent some abstraction. For example, a Date class might represent calendar dates, an Integer class might deal with integers, and a Matrix class would represent mathematical matrices. So you need to ask "What kinds of entities does my application manipulate?".

Some examples of potential classes in different application areas would include:

a) GUI/Graphics - Line, Circle, Window, TextArea, Button, Point

b) Architecture - Building, Plot, Room

b) Geography - River, Country, Sea, Continent

Instead of viewing an application as something that performs steps A, B, and C, that is, looking at the program in terms of its functions, instead ask what types of objects and data the application manipulates. Instead of taking a function-oriented approach, take an object-oriented one.

=== Object Oriented Concepts ===
*[http://en.wikipedia.org/wiki/Abstraction_(computer_science) '''Abstraction''']: To implement real world entity into program, class uses the concept of abstraction. Abstraction is a process that involves identifying the crucial behavior of an object and eliminating irrelevant and tedious details.

*[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) '''Encapsulation''']: Binding the data and code to access that data. Encapsulation only refers to a container which has a data and its related functions in it.

*[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) '''Inheritance''']: Defining new classes from the existing one. The new class will get all the methods and properties of the existing class.

*[http://en.wikipedia.org/wiki/Polymorphism_(object-oriented_programming) '''Polymorphism''']: Ability to acquire different forms. There are basically two types of polymorphism. Compile Time (also knows as Early binding) and Run Time (also knows as Late binding) Polymorphism.

*[http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding''']: As encapsulation bind data and methods together, data hiding restrict sensitive data accessing to the system. It is also achieved by using access modifiers i.e. Private, Protected and Public.

== Design principles and patterns ==

=== Object Oriented Design Principles ===

*[http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple '''The LiskovSubstitutionPrinciple (LSP)''']: "An instance of a derived should be able to replace any instance of its superclass"

*[http://c2.com/cgi/wiki?OpenClosedPrinciple '''The OpenClosedPrinciple (OCP)''']: "A reusable class should be open for extension, but closed for modification."

*[http://c2.com/cgi/wiki?DependencyInversionPrinciple '''The DependencyInversionPrinciple (DIP)''']: "The modules that implement a high level policy should not depend on the modules that implement the low level policies, but rather, they should depend on some well-defined interfaces."

*[http://c2.com/cgi/wiki?InterfaceSegregationPrinciple '''The InterfaceSegregationPrinciple (ISP)''']: "The dependency of one class to another one should depend on the smallest possible interface."

*[http://c2.com/cgi/wiki?ReuseReleaseEquivalencePrinciple '''The ReuseReleaseEquivalencePrinciple (REP)''']: "The granule of reuse is the granule of release." module == type, the fusion of distinct notions is what gives OO its distinctive flavor.

*[http://c2.com/cgi/wiki?CommonClosurePrinciple '''The CommonClosurePrinciple (CCP):''']: "The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package."

=== Object Oriented Design Patterns ===

*[http://en.wikipedia.org/wiki/Singleton_pattern '''Singleton'''] - Ensure that only one instance of a class is created and Provide a global access point to the object.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Factory'''] - Creates objects without exposing the instantiation logic to the client and Refers to the newly created object through a common interface.

*[http://en.wikipedia.org/wiki/Command_pattern'''Command'''] - Encapsulate a request in an object, Allows the parameterization of clients with different requests and Allows saving the requests in a queue.

*[http://en.wikipedia.org/wiki/Iterator_pattern '''Iterator'''] - Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Strategy'''] - Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Adapter'''] - Convert the interface of a class into another interface clients expect. / Adapter lets classes work together, that could not otherwise because of incompatible interfaces.

== Examples ==
This section discusses about the ATM example using OOD, developed by Dr.Bjork. The overview of this example is explained below.
Complete example can be found here http://math-cs.gordon.edu/courses/cs211/ATMExample/

The process of object oriented design starts with the requirements followed by analysis, design and the implementation. Let us dicuss about each of these steps in detail.

=== Requirements ===

This design model will help in developing a software that will control a simulated automatic teller machine (ATM).
For a complete list of requirements check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Requirements.html

Though there will be more detailed requirements with secuirty constraints, this page provides the basic requirements an ATM should satisfy.

1.) A customer must be able to make a cash withdrawal from any suitable account linked to the card, in multiples of $20.00. Approval must be obtained from the bank before cash is dispensed.
2.) A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to manual verification when the envelope is removed from the machine by an operator. Approval must be obtained from the bank before physically accepting the envelope.
3.) A customer must be able to make a transfer of money between any two accounts linked to the card.
4.) A customer must be able to make a balance inquiry of any account linked to the card.

=== Analysis ===

The analysis phase involves in finding the use cases, initial test cases and the basic parts (classes) involved in the system.

1.) Use cases:

With the above requirements, we will discuss two important use cases.

Withdrawal Transaction Use Case :

A withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g. checking) from a menu of possible accounts, and to choose a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. (If not, the customer is informed and asked to enter a different amount.) If the transaction is approved by the bank, the appropriate amount of cash is dispensed by the machine before it issues a receipt.

Deposit Transaction Use Case :

A deposit transaction asks the customer to choose a type of account to deposit to (e.g. checking) from a menu of possible accounts, and to type in a dollar amount on the keyboard. The transaction is initially sent to the bank to verify that the ATM can accept a deposit from this customer to this account. If the transaction is approved, the machine accepts an envelope from the customer containing cash and/or checks before it issues a receipt. Once the envelope has been received, a second message is sent to the bank, to confirm that the bank can credit the customer's account - contingent on manual verification of the deposit envelope contents by an operator later.

Use cases are represented using Interaction diagrams. This section is not going to explain the interaction diagrams.
For the interaction diagrams, check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Interactions.html#Startup

2.) Classes

The basic classes of the system can be found using the following conditions

is a singular noun,
does not really have the same functionality as some other class,
is not simply a primitive type.

The classes required for the ATM model will be,

Card reader.
Customer console, consisting of a display and keyboard.
Cash dispenser.
Envelope acceptor.
Receipt printer.
Session.
Transaction.

=== Design ===

The design part includes the process of finding the resposiblities and the interaction of the classes.

The designs can be represented using various methods like

CRC Cards
Class Diagram
State Charts
Interaction Diagrams

In this example we will examine CRC cards closely.

A CRC card has a class name, responsiblities of the class and collobarotars (other classes required to complete the responsiblity).

So for the "Withdrawl" class, a CRC card will be designed as follows,
{| class="wikitable" border="1"
! scope="col" | Responsibilities
! scope="col" | Collaborators

|-
| Perform operations peculiar to withdrawal transaction use case || CustomerConsole

CashDispenser

Message

Receipt


|}

With this the design is complete. So the rest of the software design includes implemenation and testing which will be convered under ibject oriented programming.
http://en.wikipedia.org/wiki/Object-oriented_programming

== Advantages of OOD ==

*'''Simplicity:''' software objects model real world objects, so the complexity is reduced and the program structure is very clear.

*'''Modularity:''' each object forms a separate entity whose internal workings are decoupled from other parts of the system.

*'''Maintainable:''' objects can be maintained separately, making locating and fixing problems easier.

*'''Re-usability:''' objects contain both data and functions that act on data, objects can be thought of as self-contained “boxes”.This feature
makes it easy to reuse code in new systems.

*'''Scalability:''' object’s interface provides a roadmap for reusing the object in new software and thus provides you with all the information
you need to replace the object without affecting other code.

== References ==

* Principles of Object Oriented Design - http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign

* Object Oriented Programming - http://en.wikipedia.org/wiki/Object-oriented_programming

* Object Oriented Design - http://en.wikipedia.org/wiki/Object-oriented_design

* Object Oriented Concepts - http://download.oracle.com/javase/tutorial/java/concepts

* ATM example - http://math-cs.gordon.edu/courses/cs211/ATMExample/

CSC/ECE 517 Fall 2011/ch1 1e ap

2011-11-03T21:53:07Z

Pramasw3: /* Design */

Introduction to Object Oriented Design
__TOC__
== Introduction to Object Oriented Programming ==
Object-oriented programming (OOP) is a programming language model organized around "objects" rather than "actions" and data rather than logic. It uses "objects" - data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.

Object-oriented programming takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them. Examples of objects range from human beings (described by name, address, and so forth) to buildings and floors (whose properties can be described and managed) down to the little widgets on your computer desktop (such as buttons and scroll bars).

Object-oriented programming is a method of programming based on a hierarchy of classes, and well-defined and cooperating objects.

*'''Classes'''
The class is the fundamental object-oriented unit. It is a structure that defines the data and the methods to work on that data. Classes define a set of objects that share a common structure and behavior. When you write programs in the Java language, all program data is wrapped in a class.All objects are created from classes, so it important to understand the structure of a class. In fact, it is the design of classes that has fueled the development of various Object Oriented languages.Object is an instance of a class.

*'''Objects'''
An "Object" is binding together of data and behavior, and Object Oriented programming, is the use of objects while solving the problem.
What makes an "object" unique is the formal and explicit combination of these smaller pieces' behavior with its' data into a single entity.

== Object Oriented Design ==

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design. Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis. Much of design involves refining the analysis model through the introduction of classes and algorithms that define exactly how certain required features are realized. Another common design activity is the development of an overall system architecture. This entails organizing the system as a set of major building blocks, such as subsystems or components. For a concurrent system, the architecture includes the basic task or process structure.For a distributed system, it includes the organization of hardware in terms of processors and their interconnections. Basically, object-oriented design (OOD) entails transforming the analysis model into a feasible design. Once the design reaches a sufficient level of specificity, it is translated into an implementation through object-oriented programming. This task can be either relatively straightforward or rather challenging, depending upon the amount of detail in the design.

The first question in OOD ,especially for newcomers, is "How can I decide what classes my program should have in it?" The fundamental rule is that a class should represent some abstraction. For example, a Date class might represent calendar dates, an Integer class might deal with integers, and a Matrix class would represent mathematical matrices. So you need to ask "What kinds of entities does my application manipulate?".

Some examples of potential classes in different application areas would include:

a) GUI/Graphics - Line, Circle, Window, TextArea, Button, Point

b) Architecture - Building, Plot, Room

b) Geography - River, Country, Sea, Continent

Instead of viewing an application as something that performs steps A, B, and C, that is, looking at the program in terms of its functions, instead ask what types of objects and data the application manipulates. Instead of taking a function-oriented approach, take an object-oriented one.

=== Object Oriented Concepts ===
*[http://en.wikipedia.org/wiki/Abstraction_(computer_science) '''Abstraction''']: To implement real world entity into program, class uses the concept of abstraction. Abstraction is a process that involves identifying the crucial behavior of an object and eliminating irrelevant and tedious details.

*[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) '''Encapsulation''']: Binding the data and code to access that data. Encapsulation only refers to a container which has a data and its related functions in it.

*[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) '''Inheritance''']: Defining new classes from the existing one. The new class will get all the methods and properties of the existing class.

*[http://en.wikipedia.org/wiki/Polymorphism_(object-oriented_programming) '''Polymorphism''']: Ability to acquire different forms. There are basically two types of polymorphism. Compile Time (also knows as Early binding) and Run Time (also knows as Late binding) Polymorphism.

*[http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding''']: As encapsulation bind data and methods together, data hiding restrict sensitive data accessing to the system. It is also achieved by using access modifiers i.e. Private, Protected and Public.

== Design principles and patterns ==

=== Object Oriented Design Principles ===

*[http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple '''The LiskovSubstitutionPrinciple (LSP)''']: "An instance of a derived should be able to replace any instance of its superclass"

*[http://c2.com/cgi/wiki?OpenClosedPrinciple '''The OpenClosedPrinciple (OCP)''']: "A reusable class should be open for extension, but closed for modification."

*[http://c2.com/cgi/wiki?DependencyInversionPrinciple '''The DependencyInversionPrinciple (DIP)''']: "The modules that implement a high level policy should not depend on the modules that implement the low level policies, but rather, they should depend on some well-defined interfaces."

*[http://c2.com/cgi/wiki?InterfaceSegregationPrinciple '''The InterfaceSegregationPrinciple (ISP)''']: "The dependency of one class to another one should depend on the smallest possible interface."

*[http://c2.com/cgi/wiki?ReuseReleaseEquivalencePrinciple '''The ReuseReleaseEquivalencePrinciple (REP)''']: "The granule of reuse is the granule of release." module == type, the fusion of distinct notions is what gives OO its distinctive flavor.

*[http://c2.com/cgi/wiki?CommonClosurePrinciple '''The CommonClosurePrinciple (CCP):''']: "The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package."

=== Object Oriented Design Patterns ===

*[http://en.wikipedia.org/wiki/Singleton_pattern '''Singleton'''] - Ensure that only one instance of a class is created and Provide a global access point to the object.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Factory'''] - Creates objects without exposing the instantiation logic to the client and Refers to the newly created object through a common interface.

*[http://en.wikipedia.org/wiki/Command_pattern'''Command'''] - Encapsulate a request in an object, Allows the parameterization of clients with different requests and Allows saving the requests in a queue.

*[http://en.wikipedia.org/wiki/Iterator_pattern '''Iterator'''] - Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Strategy'''] - Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Adapter'''] - Convert the interface of a class into another interface clients expect. / Adapter lets classes work together, that could not otherwise because of incompatible interfaces.

== Examples ==
This section discusses about the ATM example using OOD, developed by Dr.Bjork. The overview of this example is explained below.
Complete example can be found here http://math-cs.gordon.edu/courses/cs211/ATMExample/

The process of object oriented design starts with the requirements followed by analysis, design and the implementation. Let us dicuss about each of these steps in detail.

=== Requirements ===

This design model will help in developing a software that will control a simulated automatic teller machine (ATM).
For a complete list of requirements check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Requirements.html

Though there will be more detailed requirements with secuirty constraints, this page provides the basic requirements an ATM should satisfy.

1.) A customer must be able to make a cash withdrawal from any suitable account linked to the card, in multiples of $20.00. Approval must be obtained from the bank before cash is dispensed.
2.) A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to manual verification when the envelope is removed from the machine by an operator. Approval must be obtained from the bank before physically accepting the envelope.
3.) A customer must be able to make a transfer of money between any two accounts linked to the card.
4.) A customer must be able to make a balance inquiry of any account linked to the card.

=== Analysis ===

The analysis phase involves in finding the use cases, initial test cases and the basic parts (classes) involved in the system.

1.) Use cases:

With the above requirements, we will discuss two important use cases.

Withdrawal Transaction Use Case :

A withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g. checking) from a menu of possible accounts, and to choose a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. (If not, the customer is informed and asked to enter a different amount.) If the transaction is approved by the bank, the appropriate amount of cash is dispensed by the machine before it issues a receipt.

Deposit Transaction Use Case :

A deposit transaction asks the customer to choose a type of account to deposit to (e.g. checking) from a menu of possible accounts, and to type in a dollar amount on the keyboard. The transaction is initially sent to the bank to verify that the ATM can accept a deposit from this customer to this account. If the transaction is approved, the machine accepts an envelope from the customer containing cash and/or checks before it issues a receipt. Once the envelope has been received, a second message is sent to the bank, to confirm that the bank can credit the customer's account - contingent on manual verification of the deposit envelope contents by an operator later.

Use cases are represented using Interaction diagrams. This section is not going to explain the interaction diagrams.
For the interaction diagrams, check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Interactions.html#Startup

2.) Classes

The basic classes of the system can be found using the following conditions

is a singular noun,
does not really have the same functionality as some other class,
is not simply a primitive type.

The classes required for the ATM model will be,

Card reader.
Customer console, consisting of a display and keyboard.
Cash dispenser.
Envelope acceptor.
Receipt printer.
Session.
Transaction.

=== Design ===

The design part includes the process of finding the resposiblities and the interaction of the classes.

The designs can be represented using various methods like

CRC Cards
Class Diagram
State Charts
Interaction Diagrams

In this example we will examine CRC cards closely.

A CRC card has a class name, responsiblities of the class and collobarotars (other classes required to complete the responsiblity).

So for the "Withdrawl" class, a CRC card will be designed as follows,

<table border = 1>
Responsibilities Collaborators
Perform operations peculiar to withdrawal transaction use case CustomerConsole
CashDispenser
Message
Receipt
</table>

{| class="wikitable" border="1"
! scope="col" | Responsibilities
! scope="col" | Collaborators

|-
| Perform operations peculiar to withdrawal transaction use case || CustomerConsole
CashDispenser
Message
Receipt

|}

With this the design is complete. So the rest of the software design includes implemenation and testing which will be convered under ibject oriented programming.
http://en.wikipedia.org/wiki/Object-oriented_programming

== Advantages of OOD ==

*'''Simplicity:''' software objects model real world objects, so the complexity is reduced and the program structure is very clear.

*'''Modularity:''' each object forms a separate entity whose internal workings are decoupled from other parts of the system.

*'''Maintainable:''' objects can be maintained separately, making locating and fixing problems easier.

*'''Re-usability:''' objects contain both data and functions that act on data, objects can be thought of as self-contained “boxes”.This feature
makes it easy to reuse code in new systems.

*'''Scalability:''' object’s interface provides a roadmap for reusing the object in new software and thus provides you with all the information
you need to replace the object without affecting other code.

== References ==

* Principles of Object Oriented Design - http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign

* Object Oriented Programming - http://en.wikipedia.org/wiki/Object-oriented_programming

* Object Oriented Design - http://en.wikipedia.org/wiki/Object-oriented_design

* Object Oriented Concepts - http://download.oracle.com/javase/tutorial/java/concepts

* ATM example - http://math-cs.gordon.edu/courses/cs211/ATMExample/

CSC/ECE 517 Fall 2011/ch1 1e ap

2011-11-03T21:52:23Z

Pramasw3: /* Design */

Introduction to Object Oriented Design
__TOC__
== Introduction to Object Oriented Programming ==
Object-oriented programming (OOP) is a programming language model organized around "objects" rather than "actions" and data rather than logic. It uses "objects" - data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.

Object-oriented programming takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them. Examples of objects range from human beings (described by name, address, and so forth) to buildings and floors (whose properties can be described and managed) down to the little widgets on your computer desktop (such as buttons and scroll bars).

Object-oriented programming is a method of programming based on a hierarchy of classes, and well-defined and cooperating objects.

*'''Classes'''
The class is the fundamental object-oriented unit. It is a structure that defines the data and the methods to work on that data. Classes define a set of objects that share a common structure and behavior. When you write programs in the Java language, all program data is wrapped in a class.All objects are created from classes, so it important to understand the structure of a class. In fact, it is the design of classes that has fueled the development of various Object Oriented languages.Object is an instance of a class.

*'''Objects'''
An "Object" is binding together of data and behavior, and Object Oriented programming, is the use of objects while solving the problem.
What makes an "object" unique is the formal and explicit combination of these smaller pieces' behavior with its' data into a single entity.

== Object Oriented Design ==

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design. Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis. Much of design involves refining the analysis model through the introduction of classes and algorithms that define exactly how certain required features are realized. Another common design activity is the development of an overall system architecture. This entails organizing the system as a set of major building blocks, such as subsystems or components. For a concurrent system, the architecture includes the basic task or process structure.For a distributed system, it includes the organization of hardware in terms of processors and their interconnections. Basically, object-oriented design (OOD) entails transforming the analysis model into a feasible design. Once the design reaches a sufficient level of specificity, it is translated into an implementation through object-oriented programming. This task can be either relatively straightforward or rather challenging, depending upon the amount of detail in the design.

The first question in OOD ,especially for newcomers, is "How can I decide what classes my program should have in it?" The fundamental rule is that a class should represent some abstraction. For example, a Date class might represent calendar dates, an Integer class might deal with integers, and a Matrix class would represent mathematical matrices. So you need to ask "What kinds of entities does my application manipulate?".

Some examples of potential classes in different application areas would include:

a) GUI/Graphics - Line, Circle, Window, TextArea, Button, Point

b) Architecture - Building, Plot, Room

b) Geography - River, Country, Sea, Continent

Instead of viewing an application as something that performs steps A, B, and C, that is, looking at the program in terms of its functions, instead ask what types of objects and data the application manipulates. Instead of taking a function-oriented approach, take an object-oriented one.

=== Object Oriented Concepts ===
*[http://en.wikipedia.org/wiki/Abstraction_(computer_science) '''Abstraction''']: To implement real world entity into program, class uses the concept of abstraction. Abstraction is a process that involves identifying the crucial behavior of an object and eliminating irrelevant and tedious details.

*[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) '''Encapsulation''']: Binding the data and code to access that data. Encapsulation only refers to a container which has a data and its related functions in it.

*[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) '''Inheritance''']: Defining new classes from the existing one. The new class will get all the methods and properties of the existing class.

*[http://en.wikipedia.org/wiki/Polymorphism_(object-oriented_programming) '''Polymorphism''']: Ability to acquire different forms. There are basically two types of polymorphism. Compile Time (also knows as Early binding) and Run Time (also knows as Late binding) Polymorphism.

*[http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding''']: As encapsulation bind data and methods together, data hiding restrict sensitive data accessing to the system. It is also achieved by using access modifiers i.e. Private, Protected and Public.

== Design principles and patterns ==

=== Object Oriented Design Principles ===

*[http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple '''The LiskovSubstitutionPrinciple (LSP)''']: "An instance of a derived should be able to replace any instance of its superclass"

*[http://c2.com/cgi/wiki?OpenClosedPrinciple '''The OpenClosedPrinciple (OCP)''']: "A reusable class should be open for extension, but closed for modification."

*[http://c2.com/cgi/wiki?DependencyInversionPrinciple '''The DependencyInversionPrinciple (DIP)''']: "The modules that implement a high level policy should not depend on the modules that implement the low level policies, but rather, they should depend on some well-defined interfaces."

*[http://c2.com/cgi/wiki?InterfaceSegregationPrinciple '''The InterfaceSegregationPrinciple (ISP)''']: "The dependency of one class to another one should depend on the smallest possible interface."

*[http://c2.com/cgi/wiki?ReuseReleaseEquivalencePrinciple '''The ReuseReleaseEquivalencePrinciple (REP)''']: "The granule of reuse is the granule of release." module == type, the fusion of distinct notions is what gives OO its distinctive flavor.

*[http://c2.com/cgi/wiki?CommonClosurePrinciple '''The CommonClosurePrinciple (CCP):''']: "The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package."

=== Object Oriented Design Patterns ===

*[http://en.wikipedia.org/wiki/Singleton_pattern '''Singleton'''] - Ensure that only one instance of a class is created and Provide a global access point to the object.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Factory'''] - Creates objects without exposing the instantiation logic to the client and Refers to the newly created object through a common interface.

*[http://en.wikipedia.org/wiki/Command_pattern'''Command'''] - Encapsulate a request in an object, Allows the parameterization of clients with different requests and Allows saving the requests in a queue.

*[http://en.wikipedia.org/wiki/Iterator_pattern '''Iterator'''] - Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Strategy'''] - Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Adapter'''] - Convert the interface of a class into another interface clients expect. / Adapter lets classes work together, that could not otherwise because of incompatible interfaces.

== Examples ==
This section discusses about the ATM example using OOD, developed by Dr.Bjork. The overview of this example is explained below.
Complete example can be found here http://math-cs.gordon.edu/courses/cs211/ATMExample/

The process of object oriented design starts with the requirements followed by analysis, design and the implementation. Let us dicuss about each of these steps in detail.

=== Requirements ===

This design model will help in developing a software that will control a simulated automatic teller machine (ATM).
For a complete list of requirements check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Requirements.html

Though there will be more detailed requirements with secuirty constraints, this page provides the basic requirements an ATM should satisfy.

1.) A customer must be able to make a cash withdrawal from any suitable account linked to the card, in multiples of $20.00. Approval must be obtained from the bank before cash is dispensed.
2.) A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to manual verification when the envelope is removed from the machine by an operator. Approval must be obtained from the bank before physically accepting the envelope.
3.) A customer must be able to make a transfer of money between any two accounts linked to the card.
4.) A customer must be able to make a balance inquiry of any account linked to the card.

=== Analysis ===

The analysis phase involves in finding the use cases, initial test cases and the basic parts (classes) involved in the system.

1.) Use cases:

With the above requirements, we will discuss two important use cases.

Withdrawal Transaction Use Case :

A withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g. checking) from a menu of possible accounts, and to choose a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. (If not, the customer is informed and asked to enter a different amount.) If the transaction is approved by the bank, the appropriate amount of cash is dispensed by the machine before it issues a receipt.

Deposit Transaction Use Case :

A deposit transaction asks the customer to choose a type of account to deposit to (e.g. checking) from a menu of possible accounts, and to type in a dollar amount on the keyboard. The transaction is initially sent to the bank to verify that the ATM can accept a deposit from this customer to this account. If the transaction is approved, the machine accepts an envelope from the customer containing cash and/or checks before it issues a receipt. Once the envelope has been received, a second message is sent to the bank, to confirm that the bank can credit the customer's account - contingent on manual verification of the deposit envelope contents by an operator later.

Use cases are represented using Interaction diagrams. This section is not going to explain the interaction diagrams.
For the interaction diagrams, check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Interactions.html#Startup

2.) Classes

The basic classes of the system can be found using the following conditions

is a singular noun,
does not really have the same functionality as some other class,
is not simply a primitive type.

The classes required for the ATM model will be,

Card reader.
Customer console, consisting of a display and keyboard.
Cash dispenser.
Envelope acceptor.
Receipt printer.
Session.
Transaction.

=== Design ===

The design part includes the process of finding the resposiblities and the interaction of the classes.

The designs can be represented using various methods like

CRC Cards
Class Diagram
State Charts
Interaction Diagrams

In this example we will examine CRC cards closely.

A CRC card has a class name, responsiblities of the class and collobarotars (other classes required to complete the responsiblity).

So for the "Withdrawl" class, a CRC card will be designed as follows,

<table border = 1>
Responsibilities Collaborators
Perform operations peculiar to withdrawal transaction use case CustomerConsole
CashDispenser
Message
Receipt
</table>

{| class="wikitable" border="1"
! scope="col" | Responsibilities
! scope="col" | Collaborators

|-
| Perform operations peculiar to withdrawal transaction use case
|-
| CustomerConsole
CashDispenser
Message
Receipt

|}

{| class="wikitable" border="1"
! scope="col" | Block-Structured Languages
! scope="col" | Object Oriented Languages
|-
| Block Structure involves section of code grouped together with one or more declaration and statements || Object Oriented Programming involves programming around objects which is an instance of a class representing data fields and methods for interaction.
|-
| Block Structure provides no means of access to variables and limits the scope within the block. || Object Oriented Programming allows to define different access specifiers(public,private,protected) when defining any field or method.
|-
| Maintainibility is difficult as the programs size increases || Easy to maintain as objects can be maintained separately thus making easy to locate and manage.
|-
| Program flow has a single point of entry and exit || Program flow depends on the state and interaction within objects.
|-
| Has limited modifiability where a procedure is defined for performing certain function which cannot be modified to a greater extent || Easy to make changes in the data representation and methods as changes within a class do not affect others.
|-
| No re-usability || Objects can be re-used in another programs.
|-
| Not preferable when working with large programs|| Can handle large programs due to its design, organization and flow of the program.
|-
| Limited Modularity || The objects form a separate entity whose internal workings are decoupled from other parts of the system.
|-
| Limited extensibility as very difficult to extend the modules and its function which requires re-structuring || Introduction of few new objects can help in adding or changing new features.
|-
| Example :- Algol 60,Pascal, C || Example:- Simula,C++,JAVA,Ruby
|}

With this the design is complete. So the rest of the software design includes implemenation and testing which will be convered under ibject oriented programming.
http://en.wikipedia.org/wiki/Object-oriented_programming

== Advantages of OOD ==

*'''Simplicity:''' software objects model real world objects, so the complexity is reduced and the program structure is very clear.

*'''Modularity:''' each object forms a separate entity whose internal workings are decoupled from other parts of the system.

*'''Maintainable:''' objects can be maintained separately, making locating and fixing problems easier.

*'''Re-usability:''' objects contain both data and functions that act on data, objects can be thought of as self-contained “boxes”.This feature
makes it easy to reuse code in new systems.

*'''Scalability:''' object’s interface provides a roadmap for reusing the object in new software and thus provides you with all the information
you need to replace the object without affecting other code.

== References ==

* Principles of Object Oriented Design - http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign

* Object Oriented Programming - http://en.wikipedia.org/wiki/Object-oriented_programming

* Object Oriented Design - http://en.wikipedia.org/wiki/Object-oriented_design

* Object Oriented Concepts - http://download.oracle.com/javase/tutorial/java/concepts

* ATM example - http://math-cs.gordon.edu/courses/cs211/ATMExample/

CSC/ECE 517 Fall 2011/ch1 1e ap

2011-11-03T21:51:44Z

Pramasw3: /* Design */

Introduction to Object Oriented Design
__TOC__
== Introduction to Object Oriented Programming ==
Object-oriented programming (OOP) is a programming language model organized around "objects" rather than "actions" and data rather than logic. It uses "objects" - data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.

Object-oriented programming takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them. Examples of objects range from human beings (described by name, address, and so forth) to buildings and floors (whose properties can be described and managed) down to the little widgets on your computer desktop (such as buttons and scroll bars).

Object-oriented programming is a method of programming based on a hierarchy of classes, and well-defined and cooperating objects.

*'''Classes'''
The class is the fundamental object-oriented unit. It is a structure that defines the data and the methods to work on that data. Classes define a set of objects that share a common structure and behavior. When you write programs in the Java language, all program data is wrapped in a class.All objects are created from classes, so it important to understand the structure of a class. In fact, it is the design of classes that has fueled the development of various Object Oriented languages.Object is an instance of a class.

*'''Objects'''
An "Object" is binding together of data and behavior, and Object Oriented programming, is the use of objects while solving the problem.
What makes an "object" unique is the formal and explicit combination of these smaller pieces' behavior with its' data into a single entity.

== Object Oriented Design ==

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design. Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis. Much of design involves refining the analysis model through the introduction of classes and algorithms that define exactly how certain required features are realized. Another common design activity is the development of an overall system architecture. This entails organizing the system as a set of major building blocks, such as subsystems or components. For a concurrent system, the architecture includes the basic task or process structure.For a distributed system, it includes the organization of hardware in terms of processors and their interconnections. Basically, object-oriented design (OOD) entails transforming the analysis model into a feasible design. Once the design reaches a sufficient level of specificity, it is translated into an implementation through object-oriented programming. This task can be either relatively straightforward or rather challenging, depending upon the amount of detail in the design.

The first question in OOD ,especially for newcomers, is "How can I decide what classes my program should have in it?" The fundamental rule is that a class should represent some abstraction. For example, a Date class might represent calendar dates, an Integer class might deal with integers, and a Matrix class would represent mathematical matrices. So you need to ask "What kinds of entities does my application manipulate?".

Some examples of potential classes in different application areas would include:

a) GUI/Graphics - Line, Circle, Window, TextArea, Button, Point

b) Architecture - Building, Plot, Room

b) Geography - River, Country, Sea, Continent

Instead of viewing an application as something that performs steps A, B, and C, that is, looking at the program in terms of its functions, instead ask what types of objects and data the application manipulates. Instead of taking a function-oriented approach, take an object-oriented one.

=== Object Oriented Concepts ===
*[http://en.wikipedia.org/wiki/Abstraction_(computer_science) '''Abstraction''']: To implement real world entity into program, class uses the concept of abstraction. Abstraction is a process that involves identifying the crucial behavior of an object and eliminating irrelevant and tedious details.

*[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) '''Encapsulation''']: Binding the data and code to access that data. Encapsulation only refers to a container which has a data and its related functions in it.

*[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) '''Inheritance''']: Defining new classes from the existing one. The new class will get all the methods and properties of the existing class.

*[http://en.wikipedia.org/wiki/Polymorphism_(object-oriented_programming) '''Polymorphism''']: Ability to acquire different forms. There are basically two types of polymorphism. Compile Time (also knows as Early binding) and Run Time (also knows as Late binding) Polymorphism.

*[http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding''']: As encapsulation bind data and methods together, data hiding restrict sensitive data accessing to the system. It is also achieved by using access modifiers i.e. Private, Protected and Public.

== Design principles and patterns ==

=== Object Oriented Design Principles ===

*[http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple '''The LiskovSubstitutionPrinciple (LSP)''']: "An instance of a derived should be able to replace any instance of its superclass"

*[http://c2.com/cgi/wiki?OpenClosedPrinciple '''The OpenClosedPrinciple (OCP)''']: "A reusable class should be open for extension, but closed for modification."

*[http://c2.com/cgi/wiki?DependencyInversionPrinciple '''The DependencyInversionPrinciple (DIP)''']: "The modules that implement a high level policy should not depend on the modules that implement the low level policies, but rather, they should depend on some well-defined interfaces."

*[http://c2.com/cgi/wiki?InterfaceSegregationPrinciple '''The InterfaceSegregationPrinciple (ISP)''']: "The dependency of one class to another one should depend on the smallest possible interface."

*[http://c2.com/cgi/wiki?ReuseReleaseEquivalencePrinciple '''The ReuseReleaseEquivalencePrinciple (REP)''']: "The granule of reuse is the granule of release." module == type, the fusion of distinct notions is what gives OO its distinctive flavor.

*[http://c2.com/cgi/wiki?CommonClosurePrinciple '''The CommonClosurePrinciple (CCP):''']: "The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package."

=== Object Oriented Design Patterns ===

*[http://en.wikipedia.org/wiki/Singleton_pattern '''Singleton'''] - Ensure that only one instance of a class is created and Provide a global access point to the object.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Factory'''] - Creates objects without exposing the instantiation logic to the client and Refers to the newly created object through a common interface.

*[http://en.wikipedia.org/wiki/Command_pattern'''Command'''] - Encapsulate a request in an object, Allows the parameterization of clients with different requests and Allows saving the requests in a queue.

*[http://en.wikipedia.org/wiki/Iterator_pattern '''Iterator'''] - Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Strategy'''] - Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Adapter'''] - Convert the interface of a class into another interface clients expect. / Adapter lets classes work together, that could not otherwise because of incompatible interfaces.

== Examples ==
This section discusses about the ATM example using OOD, developed by Dr.Bjork. The overview of this example is explained below.
Complete example can be found here http://math-cs.gordon.edu/courses/cs211/ATMExample/

The process of object oriented design starts with the requirements followed by analysis, design and the implementation. Let us dicuss about each of these steps in detail.

=== Requirements ===

This design model will help in developing a software that will control a simulated automatic teller machine (ATM).
For a complete list of requirements check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Requirements.html

Though there will be more detailed requirements with secuirty constraints, this page provides the basic requirements an ATM should satisfy.

1.) A customer must be able to make a cash withdrawal from any suitable account linked to the card, in multiples of $20.00. Approval must be obtained from the bank before cash is dispensed.
2.) A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to manual verification when the envelope is removed from the machine by an operator. Approval must be obtained from the bank before physically accepting the envelope.
3.) A customer must be able to make a transfer of money between any two accounts linked to the card.
4.) A customer must be able to make a balance inquiry of any account linked to the card.

=== Analysis ===

The analysis phase involves in finding the use cases, initial test cases and the basic parts (classes) involved in the system.

1.) Use cases:

With the above requirements, we will discuss two important use cases.

Withdrawal Transaction Use Case :

A withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g. checking) from a menu of possible accounts, and to choose a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. (If not, the customer is informed and asked to enter a different amount.) If the transaction is approved by the bank, the appropriate amount of cash is dispensed by the machine before it issues a receipt.

Deposit Transaction Use Case :

A deposit transaction asks the customer to choose a type of account to deposit to (e.g. checking) from a menu of possible accounts, and to type in a dollar amount on the keyboard. The transaction is initially sent to the bank to verify that the ATM can accept a deposit from this customer to this account. If the transaction is approved, the machine accepts an envelope from the customer containing cash and/or checks before it issues a receipt. Once the envelope has been received, a second message is sent to the bank, to confirm that the bank can credit the customer's account - contingent on manual verification of the deposit envelope contents by an operator later.

Use cases are represented using Interaction diagrams. This section is not going to explain the interaction diagrams.
For the interaction diagrams, check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Interactions.html#Startup

2.) Classes

The basic classes of the system can be found using the following conditions

is a singular noun,
does not really have the same functionality as some other class,
is not simply a primitive type.

The classes required for the ATM model will be,

Card reader.
Customer console, consisting of a display and keyboard.
Cash dispenser.
Envelope acceptor.
Receipt printer.
Session.
Transaction.

=== Design ===

The design part includes the process of finding the resposiblities and the interaction of the classes.

The designs can be represented using various methods like

CRC Cards
Class Diagram
State Charts
Interaction Diagrams

In this example we will examine CRC cards closely.

A CRC card has a class name, responsiblities of the class and collobarotars (other classes required to complete the responsiblity).

So for the "Withdrawl" class, a CRC card will be designed as follows,

<table border = 1>
Responsibilities Collaborators
Perform operations peculiar to withdrawal transaction use case CustomerConsole
CashDispenser
Message
Receipt
</table>

{| class="wikitable" border="1"
! scope="col" | Responsibilities
! scope="col" | Collaborators

|-
| Perform operations peculiar to withdrawal transaction use case
|-
| CustomerConsole
CashDispenser
Message
Receipt

|}

With this the design is complete. So the rest of the software design includes implemenation and testing which will be convered under ibject oriented programming.
http://en.wikipedia.org/wiki/Object-oriented_programming

== Advantages of OOD ==

*'''Simplicity:''' software objects model real world objects, so the complexity is reduced and the program structure is very clear.

*'''Modularity:''' each object forms a separate entity whose internal workings are decoupled from other parts of the system.

*'''Maintainable:''' objects can be maintained separately, making locating and fixing problems easier.

*'''Re-usability:''' objects contain both data and functions that act on data, objects can be thought of as self-contained “boxes”.This feature
makes it easy to reuse code in new systems.

*'''Scalability:''' object’s interface provides a roadmap for reusing the object in new software and thus provides you with all the information
you need to replace the object without affecting other code.

== References ==

* Principles of Object Oriented Design - http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign

* Object Oriented Programming - http://en.wikipedia.org/wiki/Object-oriented_programming

* Object Oriented Design - http://en.wikipedia.org/wiki/Object-oriented_design

* Object Oriented Concepts - http://download.oracle.com/javase/tutorial/java/concepts

* ATM example - http://math-cs.gordon.edu/courses/cs211/ATMExample/

CSC/ECE 517 Fall 2011/ch1 1e ap

2011-11-03T21:51:03Z

Pramasw3: /* Design */

Introduction to Object Oriented Design
__TOC__
== Introduction to Object Oriented Programming ==
Object-oriented programming (OOP) is a programming language model organized around "objects" rather than "actions" and data rather than logic. It uses "objects" - data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.

Object-oriented programming takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them. Examples of objects range from human beings (described by name, address, and so forth) to buildings and floors (whose properties can be described and managed) down to the little widgets on your computer desktop (such as buttons and scroll bars).

Object-oriented programming is a method of programming based on a hierarchy of classes, and well-defined and cooperating objects.

*'''Classes'''
The class is the fundamental object-oriented unit. It is a structure that defines the data and the methods to work on that data. Classes define a set of objects that share a common structure and behavior. When you write programs in the Java language, all program data is wrapped in a class.All objects are created from classes, so it important to understand the structure of a class. In fact, it is the design of classes that has fueled the development of various Object Oriented languages.Object is an instance of a class.

*'''Objects'''
An "Object" is binding together of data and behavior, and Object Oriented programming, is the use of objects while solving the problem.
What makes an "object" unique is the formal and explicit combination of these smaller pieces' behavior with its' data into a single entity.

== Object Oriented Design ==

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design. Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis. Much of design involves refining the analysis model through the introduction of classes and algorithms that define exactly how certain required features are realized. Another common design activity is the development of an overall system architecture. This entails organizing the system as a set of major building blocks, such as subsystems or components. For a concurrent system, the architecture includes the basic task or process structure.For a distributed system, it includes the organization of hardware in terms of processors and their interconnections. Basically, object-oriented design (OOD) entails transforming the analysis model into a feasible design. Once the design reaches a sufficient level of specificity, it is translated into an implementation through object-oriented programming. This task can be either relatively straightforward or rather challenging, depending upon the amount of detail in the design.

The first question in OOD ,especially for newcomers, is "How can I decide what classes my program should have in it?" The fundamental rule is that a class should represent some abstraction. For example, a Date class might represent calendar dates, an Integer class might deal with integers, and a Matrix class would represent mathematical matrices. So you need to ask "What kinds of entities does my application manipulate?".

Some examples of potential classes in different application areas would include:

a) GUI/Graphics - Line, Circle, Window, TextArea, Button, Point

b) Architecture - Building, Plot, Room

b) Geography - River, Country, Sea, Continent

Instead of viewing an application as something that performs steps A, B, and C, that is, looking at the program in terms of its functions, instead ask what types of objects and data the application manipulates. Instead of taking a function-oriented approach, take an object-oriented one.

=== Object Oriented Concepts ===
*[http://en.wikipedia.org/wiki/Abstraction_(computer_science) '''Abstraction''']: To implement real world entity into program, class uses the concept of abstraction. Abstraction is a process that involves identifying the crucial behavior of an object and eliminating irrelevant and tedious details.

*[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) '''Encapsulation''']: Binding the data and code to access that data. Encapsulation only refers to a container which has a data and its related functions in it.

*[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) '''Inheritance''']: Defining new classes from the existing one. The new class will get all the methods and properties of the existing class.

*[http://en.wikipedia.org/wiki/Polymorphism_(object-oriented_programming) '''Polymorphism''']: Ability to acquire different forms. There are basically two types of polymorphism. Compile Time (also knows as Early binding) and Run Time (also knows as Late binding) Polymorphism.

*[http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding''']: As encapsulation bind data and methods together, data hiding restrict sensitive data accessing to the system. It is also achieved by using access modifiers i.e. Private, Protected and Public.

== Design principles and patterns ==

=== Object Oriented Design Principles ===

*[http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple '''The LiskovSubstitutionPrinciple (LSP)''']: "An instance of a derived should be able to replace any instance of its superclass"

*[http://c2.com/cgi/wiki?OpenClosedPrinciple '''The OpenClosedPrinciple (OCP)''']: "A reusable class should be open for extension, but closed for modification."

*[http://c2.com/cgi/wiki?DependencyInversionPrinciple '''The DependencyInversionPrinciple (DIP)''']: "The modules that implement a high level policy should not depend on the modules that implement the low level policies, but rather, they should depend on some well-defined interfaces."

*[http://c2.com/cgi/wiki?InterfaceSegregationPrinciple '''The InterfaceSegregationPrinciple (ISP)''']: "The dependency of one class to another one should depend on the smallest possible interface."

*[http://c2.com/cgi/wiki?ReuseReleaseEquivalencePrinciple '''The ReuseReleaseEquivalencePrinciple (REP)''']: "The granule of reuse is the granule of release." module == type, the fusion of distinct notions is what gives OO its distinctive flavor.

*[http://c2.com/cgi/wiki?CommonClosurePrinciple '''The CommonClosurePrinciple (CCP):''']: "The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package."

=== Object Oriented Design Patterns ===

*[http://en.wikipedia.org/wiki/Singleton_pattern '''Singleton'''] - Ensure that only one instance of a class is created and Provide a global access point to the object.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Factory'''] - Creates objects without exposing the instantiation logic to the client and Refers to the newly created object through a common interface.

*[http://en.wikipedia.org/wiki/Command_pattern'''Command'''] - Encapsulate a request in an object, Allows the parameterization of clients with different requests and Allows saving the requests in a queue.

*[http://en.wikipedia.org/wiki/Iterator_pattern '''Iterator'''] - Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Strategy'''] - Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Adapter'''] - Convert the interface of a class into another interface clients expect. / Adapter lets classes work together, that could not otherwise because of incompatible interfaces.

== Examples ==
This section discusses about the ATM example using OOD, developed by Dr.Bjork. The overview of this example is explained below.
Complete example can be found here http://math-cs.gordon.edu/courses/cs211/ATMExample/

The process of object oriented design starts with the requirements followed by analysis, design and the implementation. Let us dicuss about each of these steps in detail.

=== Requirements ===

This design model will help in developing a software that will control a simulated automatic teller machine (ATM).
For a complete list of requirements check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Requirements.html

Though there will be more detailed requirements with secuirty constraints, this page provides the basic requirements an ATM should satisfy.

1.) A customer must be able to make a cash withdrawal from any suitable account linked to the card, in multiples of $20.00. Approval must be obtained from the bank before cash is dispensed.
2.) A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to manual verification when the envelope is removed from the machine by an operator. Approval must be obtained from the bank before physically accepting the envelope.
3.) A customer must be able to make a transfer of money between any two accounts linked to the card.
4.) A customer must be able to make a balance inquiry of any account linked to the card.

=== Analysis ===

The analysis phase involves in finding the use cases, initial test cases and the basic parts (classes) involved in the system.

1.) Use cases:

With the above requirements, we will discuss two important use cases.

Withdrawal Transaction Use Case :

A withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g. checking) from a menu of possible accounts, and to choose a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. (If not, the customer is informed and asked to enter a different amount.) If the transaction is approved by the bank, the appropriate amount of cash is dispensed by the machine before it issues a receipt.

Deposit Transaction Use Case :

A deposit transaction asks the customer to choose a type of account to deposit to (e.g. checking) from a menu of possible accounts, and to type in a dollar amount on the keyboard. The transaction is initially sent to the bank to verify that the ATM can accept a deposit from this customer to this account. If the transaction is approved, the machine accepts an envelope from the customer containing cash and/or checks before it issues a receipt. Once the envelope has been received, a second message is sent to the bank, to confirm that the bank can credit the customer's account - contingent on manual verification of the deposit envelope contents by an operator later.

Use cases are represented using Interaction diagrams. This section is not going to explain the interaction diagrams.
For the interaction diagrams, check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Interactions.html#Startup

2.) Classes

The basic classes of the system can be found using the following conditions

is a singular noun,
does not really have the same functionality as some other class,
is not simply a primitive type.

The classes required for the ATM model will be,

Card reader.
Customer console, consisting of a display and keyboard.
Cash dispenser.
Envelope acceptor.
Receipt printer.
Session.
Transaction.

=== Design ===

The design part includes the process of finding the resposiblities and the interaction of the classes.

The designs can be represented using various methods like

CRC Cards
Class Diagram
State Charts
Interaction Diagrams

In this example we will examine CRC cards closely.

A CRC card has a class name, responsiblities of the class and collobarotars (other classes required to complete the responsiblity).

So for the "Withdrawl" class, a CRC card will be designed as follows,

<table border = 1>
Responsibilities Collaborators
Perform operations peculiar to withdrawal transaction use case CustomerConsole
CashDispenser
Message
Receipt
</table>

{| class="wikitable" border="1"
! scope="col" | Responsibilities
! scope="col" | Collaborators

|-
| Perform operations peculiar to withdrawal transaction use case
|}

With this the design is complete. So the rest of the software design includes implemenation and testing which will be convered under ibject oriented programming.
http://en.wikipedia.org/wiki/Object-oriented_programming

== Advantages of OOD ==

*'''Simplicity:''' software objects model real world objects, so the complexity is reduced and the program structure is very clear.

*'''Modularity:''' each object forms a separate entity whose internal workings are decoupled from other parts of the system.

*'''Maintainable:''' objects can be maintained separately, making locating and fixing problems easier.

*'''Re-usability:''' objects contain both data and functions that act on data, objects can be thought of as self-contained “boxes”.This feature
makes it easy to reuse code in new systems.

*'''Scalability:''' object’s interface provides a roadmap for reusing the object in new software and thus provides you with all the information
you need to replace the object without affecting other code.

== References ==

* Principles of Object Oriented Design - http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign

* Object Oriented Programming - http://en.wikipedia.org/wiki/Object-oriented_programming

* Object Oriented Design - http://en.wikipedia.org/wiki/Object-oriented_design

* Object Oriented Concepts - http://download.oracle.com/javase/tutorial/java/concepts

* ATM example - http://math-cs.gordon.edu/courses/cs211/ATMExample/

CSC/ECE 517 Fall 2011/ch1 1e ap

2011-11-03T21:48:59Z

Pramasw3: /* Design */

Introduction to Object Oriented Design
__TOC__
== Introduction to Object Oriented Programming ==
Object-oriented programming (OOP) is a programming language model organized around "objects" rather than "actions" and data rather than logic. It uses "objects" - data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.

Object-oriented programming takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them. Examples of objects range from human beings (described by name, address, and so forth) to buildings and floors (whose properties can be described and managed) down to the little widgets on your computer desktop (such as buttons and scroll bars).

Object-oriented programming is a method of programming based on a hierarchy of classes, and well-defined and cooperating objects.

*'''Classes'''
The class is the fundamental object-oriented unit. It is a structure that defines the data and the methods to work on that data. Classes define a set of objects that share a common structure and behavior. When you write programs in the Java language, all program data is wrapped in a class.All objects are created from classes, so it important to understand the structure of a class. In fact, it is the design of classes that has fueled the development of various Object Oriented languages.Object is an instance of a class.

*'''Objects'''
An "Object" is binding together of data and behavior, and Object Oriented programming, is the use of objects while solving the problem.
What makes an "object" unique is the formal and explicit combination of these smaller pieces' behavior with its' data into a single entity.

== Object Oriented Design ==

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design. Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis. Much of design involves refining the analysis model through the introduction of classes and algorithms that define exactly how certain required features are realized. Another common design activity is the development of an overall system architecture. This entails organizing the system as a set of major building blocks, such as subsystems or components. For a concurrent system, the architecture includes the basic task or process structure.For a distributed system, it includes the organization of hardware in terms of processors and their interconnections. Basically, object-oriented design (OOD) entails transforming the analysis model into a feasible design. Once the design reaches a sufficient level of specificity, it is translated into an implementation through object-oriented programming. This task can be either relatively straightforward or rather challenging, depending upon the amount of detail in the design.

The first question in OOD ,especially for newcomers, is "How can I decide what classes my program should have in it?" The fundamental rule is that a class should represent some abstraction. For example, a Date class might represent calendar dates, an Integer class might deal with integers, and a Matrix class would represent mathematical matrices. So you need to ask "What kinds of entities does my application manipulate?".

Some examples of potential classes in different application areas would include:

a) GUI/Graphics - Line, Circle, Window, TextArea, Button, Point

b) Architecture - Building, Plot, Room

b) Geography - River, Country, Sea, Continent

Instead of viewing an application as something that performs steps A, B, and C, that is, looking at the program in terms of its functions, instead ask what types of objects and data the application manipulates. Instead of taking a function-oriented approach, take an object-oriented one.

=== Object Oriented Concepts ===
*[http://en.wikipedia.org/wiki/Abstraction_(computer_science) '''Abstraction''']: To implement real world entity into program, class uses the concept of abstraction. Abstraction is a process that involves identifying the crucial behavior of an object and eliminating irrelevant and tedious details.

*[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) '''Encapsulation''']: Binding the data and code to access that data. Encapsulation only refers to a container which has a data and its related functions in it.

*[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) '''Inheritance''']: Defining new classes from the existing one. The new class will get all the methods and properties of the existing class.

*[http://en.wikipedia.org/wiki/Polymorphism_(object-oriented_programming) '''Polymorphism''']: Ability to acquire different forms. There are basically two types of polymorphism. Compile Time (also knows as Early binding) and Run Time (also knows as Late binding) Polymorphism.

*[http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding''']: As encapsulation bind data and methods together, data hiding restrict sensitive data accessing to the system. It is also achieved by using access modifiers i.e. Private, Protected and Public.

== Design principles and patterns ==

=== Object Oriented Design Principles ===

*[http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple '''The LiskovSubstitutionPrinciple (LSP)''']: "An instance of a derived should be able to replace any instance of its superclass"

*[http://c2.com/cgi/wiki?OpenClosedPrinciple '''The OpenClosedPrinciple (OCP)''']: "A reusable class should be open for extension, but closed for modification."

*[http://c2.com/cgi/wiki?DependencyInversionPrinciple '''The DependencyInversionPrinciple (DIP)''']: "The modules that implement a high level policy should not depend on the modules that implement the low level policies, but rather, they should depend on some well-defined interfaces."

*[http://c2.com/cgi/wiki?InterfaceSegregationPrinciple '''The InterfaceSegregationPrinciple (ISP)''']: "The dependency of one class to another one should depend on the smallest possible interface."

*[http://c2.com/cgi/wiki?ReuseReleaseEquivalencePrinciple '''The ReuseReleaseEquivalencePrinciple (REP)''']: "The granule of reuse is the granule of release." module == type, the fusion of distinct notions is what gives OO its distinctive flavor.

*[http://c2.com/cgi/wiki?CommonClosurePrinciple '''The CommonClosurePrinciple (CCP):''']: "The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package."

=== Object Oriented Design Patterns ===

*[http://en.wikipedia.org/wiki/Singleton_pattern '''Singleton'''] - Ensure that only one instance of a class is created and Provide a global access point to the object.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Factory'''] - Creates objects without exposing the instantiation logic to the client and Refers to the newly created object through a common interface.

*[http://en.wikipedia.org/wiki/Command_pattern'''Command'''] - Encapsulate a request in an object, Allows the parameterization of clients with different requests and Allows saving the requests in a queue.

*[http://en.wikipedia.org/wiki/Iterator_pattern '''Iterator'''] - Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Strategy'''] - Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Adapter'''] - Convert the interface of a class into another interface clients expect. / Adapter lets classes work together, that could not otherwise because of incompatible interfaces.

== Examples ==
This section discusses about the ATM example using OOD, developed by Dr.Bjork. The overview of this example is explained below.
Complete example can be found here http://math-cs.gordon.edu/courses/cs211/ATMExample/

The process of object oriented design starts with the requirements followed by analysis, design and the implementation. Let us dicuss about each of these steps in detail.

=== Requirements ===

This design model will help in developing a software that will control a simulated automatic teller machine (ATM).
For a complete list of requirements check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Requirements.html

Though there will be more detailed requirements with secuirty constraints, this page provides the basic requirements an ATM should satisfy.

1.) A customer must be able to make a cash withdrawal from any suitable account linked to the card, in multiples of $20.00. Approval must be obtained from the bank before cash is dispensed.
2.) A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to manual verification when the envelope is removed from the machine by an operator. Approval must be obtained from the bank before physically accepting the envelope.
3.) A customer must be able to make a transfer of money between any two accounts linked to the card.
4.) A customer must be able to make a balance inquiry of any account linked to the card.

=== Analysis ===

The analysis phase involves in finding the use cases, initial test cases and the basic parts (classes) involved in the system.

1.) Use cases:

With the above requirements, we will discuss two important use cases.

Withdrawal Transaction Use Case :

A withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g. checking) from a menu of possible accounts, and to choose a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. (If not, the customer is informed and asked to enter a different amount.) If the transaction is approved by the bank, the appropriate amount of cash is dispensed by the machine before it issues a receipt.

Deposit Transaction Use Case :

A deposit transaction asks the customer to choose a type of account to deposit to (e.g. checking) from a menu of possible accounts, and to type in a dollar amount on the keyboard. The transaction is initially sent to the bank to verify that the ATM can accept a deposit from this customer to this account. If the transaction is approved, the machine accepts an envelope from the customer containing cash and/or checks before it issues a receipt. Once the envelope has been received, a second message is sent to the bank, to confirm that the bank can credit the customer's account - contingent on manual verification of the deposit envelope contents by an operator later.

Use cases are represented using Interaction diagrams. This section is not going to explain the interaction diagrams.
For the interaction diagrams, check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Interactions.html#Startup

2.) Classes

The basic classes of the system can be found using the following conditions

is a singular noun,
does not really have the same functionality as some other class,
is not simply a primitive type.

The classes required for the ATM model will be,

Card reader.
Customer console, consisting of a display and keyboard.
Cash dispenser.
Envelope acceptor.
Receipt printer.
Session.
Transaction.

=== Design ===

The design part includes the process of finding the resposiblities and the interaction of the classes.

The designs can be represented using various methods like

CRC Cards
Class Diagram
State Charts
Interaction Diagrams

In this example we will examine CRC cards closely.

A CRC card has a class name, responsiblities of the class and collobarotars (other classes required to complete the responsiblity).

So for the "Withdrawl" class, a CRC card will be designed as follows,

<table border = 1>
Responsibilities Collaborators
Perform operations peculiar to withdrawal transaction use case CustomerConsole
CashDispenser
Message
Receipt
</table>

{| class="wikitable" border="1"
! scope="col" | Responsibilities
! scope="col" | Collaborators
|}

With this the design is complete. So the rest of the software design includes implemenation and testing which will be convered under ibject oriented programming.
http://en.wikipedia.org/wiki/Object-oriented_programming

== Advantages of OOD ==

*'''Simplicity:''' software objects model real world objects, so the complexity is reduced and the program structure is very clear.

*'''Modularity:''' each object forms a separate entity whose internal workings are decoupled from other parts of the system.

*'''Maintainable:''' objects can be maintained separately, making locating and fixing problems easier.

*'''Re-usability:''' objects contain both data and functions that act on data, objects can be thought of as self-contained “boxes”.This feature
makes it easy to reuse code in new systems.

*'''Scalability:''' object’s interface provides a roadmap for reusing the object in new software and thus provides you with all the information
you need to replace the object without affecting other code.

== References ==

* Principles of Object Oriented Design - http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign

* Object Oriented Programming - http://en.wikipedia.org/wiki/Object-oriented_programming

* Object Oriented Design - http://en.wikipedia.org/wiki/Object-oriented_design

* Object Oriented Concepts - http://download.oracle.com/javase/tutorial/java/concepts

* ATM example - http://math-cs.gordon.edu/courses/cs211/ATMExample/

CSC/ECE 517 Fall 2011/ch1 1e ap

2011-11-03T06:32:19Z

Pramasw3: /* Requirements */

Introduction to Object Oriented Design
__TOC__
== Introduction to Object Oriented Programming ==
Object-oriented programming (OOP) is a programming language model organized around "objects" rather than "actions" and data rather than logic. It uses "objects" - data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.

Object-oriented programming takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them. Examples of objects range from human beings (described by name, address, and so forth) to buildings and floors (whose properties can be described and managed) down to the little widgets on your computer desktop (such as buttons and scroll bars).

Object-oriented programming is a method of programming based on a hierarchy of classes, and well-defined and cooperating objects.

*'''Classes'''
The class is the fundamental object-oriented unit. It is a structure that defines the data and the methods to work on that data. Classes define a set of objects that share a common structure and behavior. When you write programs in the Java language, all program data is wrapped in a class.All objects are created from classes, so it important to understand the structure of a class. In fact, it is the design of classes that has fueled the development of various Object Oriented languages.Object is an instance of a class.

*'''Objects'''
An "Object" is binding together of data and behavior, and Object Oriented programming, is the use of objects while solving the problem.
What makes an "object" unique is the formal and explicit combination of these smaller pieces' behavior with its' data into a single entity.

== Object Oriented Design ==

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design. Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis. Much of design involves refining the analysis model through the introduction of classes and algorithms that define exactly how certain required features are realized. Another common design activity is the development of an overall system architecture. This entails organizing the system as a set of major building blocks, such as subsystems or components. For a concurrent system, the architecture includes the basic task or process structure.For a distributed system, it includes the organization of hardware in terms of processors and their interconnections. Basically, object-oriented design (OOD) entails transforming the analysis model into a feasible design. Once the design reaches a sufficient level of specificity, it is translated into an implementation through object-oriented programming. This task can be either relatively straightforward or rather challenging, depending upon the amount of detail in the design.

The first question in OOD ,especially for newcomers, is "How can I decide what classes my program should have in it?" The fundamental rule is that a class should represent some abstraction. For example, a Date class might represent calendar dates, an Integer class might deal with integers, and a Matrix class would represent mathematical matrices. So you need to ask "What kinds of entities does my application manipulate?".

Some examples of potential classes in different application areas would include:

a) GUI/Graphics - Line, Circle, Window, TextArea, Button, Point

b) Architecture - Building, Plot, Room

b) Geography - River, Country, Sea, Continent

Instead of viewing an application as something that performs steps A, B, and C, that is, looking at the program in terms of its functions, instead ask what types of objects and data the application manipulates. Instead of taking a function-oriented approach, take an object-oriented one.

=== Object Oriented Concepts ===
*[http://en.wikipedia.org/wiki/Abstraction_(computer_science) '''Abstraction''']: To implement real world entity into program, class uses the concept of abstraction. Abstraction is a process that involves identifying the crucial behavior of an object and eliminating irrelevant and tedious details.

*[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) '''Encapsulation''']: Binding the data and code to access that data. Encapsulation only refers to a container which has a data and its related functions in it.

*[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) '''Inheritance''']: Defining new classes from the existing one. The new class will get all the methods and properties of the existing class.

*[http://en.wikipedia.org/wiki/Polymorphism_(object-oriented_programming) '''Polymorphism''']: Ability to acquire different forms. There are basically two types of polymorphism. Compile Time (also knows as Early binding) and Run Time (also knows as Late binding) Polymorphism.

*[http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding''']: As encapsulation bind data and methods together, data hiding restrict sensitive data accessing to the system. It is also achieved by using access modifiers i.e. Private, Protected and Public.

== Design principles and patterns ==

=== Object Oriented Design Principles ===

*[http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple '''The LiskovSubstitutionPrinciple (LSP)''']: "An instance of a derived should be able to replace any instance of its superclass"

*[http://c2.com/cgi/wiki?OpenClosedPrinciple '''The OpenClosedPrinciple (OCP)''']: "A reusable class should be open for extension, but closed for modification."

*[http://c2.com/cgi/wiki?DependencyInversionPrinciple '''The DependencyInversionPrinciple (DIP)''']: "The modules that implement a high level policy should not depend on the modules that implement the low level policies, but rather, they should depend on some well-defined interfaces."

*[http://c2.com/cgi/wiki?InterfaceSegregationPrinciple '''The InterfaceSegregationPrinciple (ISP)''']: "The dependency of one class to another one should depend on the smallest possible interface."

*[http://c2.com/cgi/wiki?ReuseReleaseEquivalencePrinciple '''The ReuseReleaseEquivalencePrinciple (REP)''']: "The granule of reuse is the granule of release." module == type, the fusion of distinct notions is what gives OO its distinctive flavor.

*[http://c2.com/cgi/wiki?CommonClosurePrinciple '''The CommonClosurePrinciple (CCP):''']: "The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package."

=== Object Oriented Design Patterns ===

*[http://en.wikipedia.org/wiki/Singleton_pattern '''Singleton'''] - Ensure that only one instance of a class is created and Provide a global access point to the object.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Factory'''] - Creates objects without exposing the instantiation logic to the client and Refers to the newly created object through a common interface.

*[http://en.wikipedia.org/wiki/Command_pattern'''Command'''] - Encapsulate a request in an object, Allows the parameterization of clients with different requests and Allows saving the requests in a queue.

*[http://en.wikipedia.org/wiki/Iterator_pattern '''Iterator'''] - Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Strategy'''] - Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Adapter'''] - Convert the interface of a class into another interface clients expect. / Adapter lets classes work together, that could not otherwise because of incompatible interfaces.

== Examples ==
This section discusses about the ATM example using OOD, developed by Dr.Bjork. The overview of this example is explained below.
Complete example can be found here http://math-cs.gordon.edu/courses/cs211/ATMExample/

The process of object oriented design starts with the requirements followed by analysis, design and the implementation. Let us dicuss about each of these steps in detail.

=== Requirements ===

This design model will help in developing a software that will control a simulated automatic teller machine (ATM).
For a complete list of requirements check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Requirements.html

Though there will be more detailed requirements with secuirty constraints, this page provides the basic requirements an ATM should satisfy.

1.) A customer must be able to make a cash withdrawal from any suitable account linked to the card, in multiples of $20.00. Approval must be obtained from the bank before cash is dispensed.
2.) A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to manual verification when the envelope is removed from the machine by an operator. Approval must be obtained from the bank before physically accepting the envelope.
3.) A customer must be able to make a transfer of money between any two accounts linked to the card.
4.) A customer must be able to make a balance inquiry of any account linked to the card.

=== Analysis ===

The analysis phase involves in finding the use cases, initial test cases and the basic parts (classes) involved in the system.

1.) Use cases:

With the above requirements, we will discuss two important use cases.

Withdrawal Transaction Use Case :

A withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g. checking) from a menu of possible accounts, and to choose a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. (If not, the customer is informed and asked to enter a different amount.) If the transaction is approved by the bank, the appropriate amount of cash is dispensed by the machine before it issues a receipt.

Deposit Transaction Use Case :

A deposit transaction asks the customer to choose a type of account to deposit to (e.g. checking) from a menu of possible accounts, and to type in a dollar amount on the keyboard. The transaction is initially sent to the bank to verify that the ATM can accept a deposit from this customer to this account. If the transaction is approved, the machine accepts an envelope from the customer containing cash and/or checks before it issues a receipt. Once the envelope has been received, a second message is sent to the bank, to confirm that the bank can credit the customer's account - contingent on manual verification of the deposit envelope contents by an operator later.

Use cases are represented using Interaction diagrams. This section is not going to explain the interaction diagrams.
For the interaction diagrams, check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Interactions.html#Startup

2.) Classes

The basic classes of the system can be found using the following conditions

is a singular noun,
does not really have the same functionality as some other class,
is not simply a primitive type.

The classes required for the ATM model will be,

Card reader.
Customer console, consisting of a display and keyboard.
Cash dispenser.
Envelope acceptor.
Receipt printer.
Session.
Transaction.

=== Design ===

The design part includes the process of finding the resposiblities and the interaction of the classes.

The designs can be represented using various methods like

CRC Cards
Class Diagram
State Charts
Interaction Diagrams

In this example we will examine CRC cards closely.

A CRC card has a class name, responsiblities of the class and collobarotars (other classes required to complete the responsiblity).

So for the "Withdrawl" class, a CRC card will be designed as follows,

<table border = 1>
Responsibilities Collaborators
Perform operations peculiar to withdrawal transaction use case CustomerConsole
CashDispenser
Message
Receipt
</table>

With this the design is complete. So the rest of the software design includes implemenation and testing which will be convered under ibject oriented programming.
http://en.wikipedia.org/wiki/Object-oriented_programming

== Advantages of OOD ==

*'''Simplicity:''' software objects model real world objects, so the complexity is reduced and the program structure is very clear.

*'''Modularity:''' each object forms a separate entity whose internal workings are decoupled from other parts of the system.

*'''Maintainable:''' objects can be maintained separately, making locating and fixing problems easier.

*'''Re-usability:''' objects contain both data and functions that act on data, objects can be thought of as self-contained “boxes”.This feature
makes it easy to reuse code in new systems.

*'''Scalability:''' object’s interface provides a roadmap for reusing the object in new software and thus provides you with all the information
you need to replace the object without affecting other code.

== References ==

* Principles of Object Oriented Design - http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign

* Object Oriented Programming - http://en.wikipedia.org/wiki/Object-oriented_programming

* Object Oriented Design - http://en.wikipedia.org/wiki/Object-oriented_design

* Object Oriented Concepts - http://download.oracle.com/javase/tutorial/java/concepts

* ATM example - http://math-cs.gordon.edu/courses/cs211/ATMExample/

CSC/ECE 517 Fall 2011/ch1 1e ap

2011-11-03T06:29:52Z

Pramasw3: /* References */

Introduction to Object Oriented Design
__TOC__
== Introduction to Object Oriented Programming ==
Object-oriented programming (OOP) is a programming language model organized around "objects" rather than "actions" and data rather than logic. It uses "objects" - data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.

Object-oriented programming takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them. Examples of objects range from human beings (described by name, address, and so forth) to buildings and floors (whose properties can be described and managed) down to the little widgets on your computer desktop (such as buttons and scroll bars).

Object-oriented programming is a method of programming based on a hierarchy of classes, and well-defined and cooperating objects.

*'''Classes'''
The class is the fundamental object-oriented unit. It is a structure that defines the data and the methods to work on that data. Classes define a set of objects that share a common structure and behavior. When you write programs in the Java language, all program data is wrapped in a class.All objects are created from classes, so it important to understand the structure of a class. In fact, it is the design of classes that has fueled the development of various Object Oriented languages.Object is an instance of a class.

*'''Objects'''
An "Object" is binding together of data and behavior, and Object Oriented programming, is the use of objects while solving the problem.
What makes an "object" unique is the formal and explicit combination of these smaller pieces' behavior with its' data into a single entity.

== Object Oriented Design ==

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design. Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis. Much of design involves refining the analysis model through the introduction of classes and algorithms that define exactly how certain required features are realized. Another common design activity is the development of an overall system architecture. This entails organizing the system as a set of major building blocks, such as subsystems or components. For a concurrent system, the architecture includes the basic task or process structure.For a distributed system, it includes the organization of hardware in terms of processors and their interconnections. Basically, object-oriented design (OOD) entails transforming the analysis model into a feasible design. Once the design reaches a sufficient level of specificity, it is translated into an implementation through object-oriented programming. This task can be either relatively straightforward or rather challenging, depending upon the amount of detail in the design.

The first question in OOD ,especially for newcomers, is "How can I decide what classes my program should have in it?" The fundamental rule is that a class should represent some abstraction. For example, a Date class might represent calendar dates, an Integer class might deal with integers, and a Matrix class would represent mathematical matrices. So you need to ask "What kinds of entities does my application manipulate?".

Some examples of potential classes in different application areas would include:

a) GUI/Graphics - Line, Circle, Window, TextArea, Button, Point

b) Architecture - Building, Plot, Room

b) Geography - River, Country, Sea, Continent

Instead of viewing an application as something that performs steps A, B, and C, that is, looking at the program in terms of its functions, instead ask what types of objects and data the application manipulates. Instead of taking a function-oriented approach, take an object-oriented one.

=== Object Oriented Concepts ===
*[http://en.wikipedia.org/wiki/Abstraction_(computer_science) '''Abstraction''']: To implement real world entity into program, class uses the concept of abstraction. Abstraction is a process that involves identifying the crucial behavior of an object and eliminating irrelevant and tedious details.

*[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) '''Encapsulation''']: Binding the data and code to access that data. Encapsulation only refers to a container which has a data and its related functions in it.

*[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) '''Inheritance''']: Defining new classes from the existing one. The new class will get all the methods and properties of the existing class.

*[http://en.wikipedia.org/wiki/Polymorphism_(object-oriented_programming) '''Polymorphism''']: Ability to acquire different forms. There are basically two types of polymorphism. Compile Time (also knows as Early binding) and Run Time (also knows as Late binding) Polymorphism.

*[http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding''']: As encapsulation bind data and methods together, data hiding restrict sensitive data accessing to the system. It is also achieved by using access modifiers i.e. Private, Protected and Public.

== Design principles and patterns ==

=== Object Oriented Design Principles ===

*[http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple '''The LiskovSubstitutionPrinciple (LSP)''']: "An instance of a derived should be able to replace any instance of its superclass"

*[http://c2.com/cgi/wiki?OpenClosedPrinciple '''The OpenClosedPrinciple (OCP)''']: "A reusable class should be open for extension, but closed for modification."

*[http://c2.com/cgi/wiki?DependencyInversionPrinciple '''The DependencyInversionPrinciple (DIP)''']: "The modules that implement a high level policy should not depend on the modules that implement the low level policies, but rather, they should depend on some well-defined interfaces."

*[http://c2.com/cgi/wiki?InterfaceSegregationPrinciple '''The InterfaceSegregationPrinciple (ISP)''']: "The dependency of one class to another one should depend on the smallest possible interface."

*[http://c2.com/cgi/wiki?ReuseReleaseEquivalencePrinciple '''The ReuseReleaseEquivalencePrinciple (REP)''']: "The granule of reuse is the granule of release." module == type, the fusion of distinct notions is what gives OO its distinctive flavor.

*[http://c2.com/cgi/wiki?CommonClosurePrinciple '''The CommonClosurePrinciple (CCP):''']: "The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package."

=== Object Oriented Design Patterns ===

*[http://en.wikipedia.org/wiki/Singleton_pattern '''Singleton'''] - Ensure that only one instance of a class is created and Provide a global access point to the object.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Factory'''] - Creates objects without exposing the instantiation logic to the client and Refers to the newly created object through a common interface.

*[http://en.wikipedia.org/wiki/Command_pattern'''Command'''] - Encapsulate a request in an object, Allows the parameterization of clients with different requests and Allows saving the requests in a queue.

*[http://en.wikipedia.org/wiki/Iterator_pattern '''Iterator'''] - Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Strategy'''] - Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Adapter'''] - Convert the interface of a class into another interface clients expect. / Adapter lets classes work together, that could not otherwise because of incompatible interfaces.

== Examples ==
This section discusses about the ATM example using OOD, developed by Dr.Bjork. The overview of this example is explained below.
Complete example can be found here http://math-cs.gordon.edu/courses/cs211/ATMExample/

The process of object oriented design starts with the requirements followed by analysis, design and the implementation. Let us dicuss about each of these steps in detail.

=== Requirements ===

This design model will help in designing a software that will control a simulated automatic teller machine (ATM).
For a complete list of requirements check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Requirements.html

Though there will be more detailed requirements with secuirty constraints, this page provides the basic requirements an ATM should satisfy.

1.) A customer must be able to make a cash withdrawal from any suitable account linked to the card, in multiples of $20.00. Approval must be obtained from the bank before cash is dispensed.
2.) A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to manual verification when the envelope is removed from the machine by an operator. Approval must be obtained from the bank before physically accepting the envelope.
3.) A customer must be able to make a transfer of money between any two accounts linked to the card.
4.) A customer must be able to make a balance inquiry of any account linked to the card.

=== Analysis ===

The analysis phase involves in finding the use cases, initial test cases and the basic parts (classes) involved in the system.

1.) Use cases:

With the above requirements, we will discuss two important use cases.

Withdrawal Transaction Use Case :

A withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g. checking) from a menu of possible accounts, and to choose a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. (If not, the customer is informed and asked to enter a different amount.) If the transaction is approved by the bank, the appropriate amount of cash is dispensed by the machine before it issues a receipt.

Deposit Transaction Use Case :

A deposit transaction asks the customer to choose a type of account to deposit to (e.g. checking) from a menu of possible accounts, and to type in a dollar amount on the keyboard. The transaction is initially sent to the bank to verify that the ATM can accept a deposit from this customer to this account. If the transaction is approved, the machine accepts an envelope from the customer containing cash and/or checks before it issues a receipt. Once the envelope has been received, a second message is sent to the bank, to confirm that the bank can credit the customer's account - contingent on manual verification of the deposit envelope contents by an operator later.

Use cases are represented using Interaction diagrams. This section is not going to explain the interaction diagrams.
For the interaction diagrams, check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Interactions.html#Startup

2.) Classes

The basic classes of the system can be found using the following conditions

is a singular noun,
does not really have the same functionality as some other class,
is not simply a primitive type.

The classes required for the ATM model will be,

Card reader.
Customer console, consisting of a display and keyboard.
Cash dispenser.
Envelope acceptor.
Receipt printer.
Session.
Transaction.

=== Design ===

The design part includes the process of finding the resposiblities and the interaction of the classes.

The designs can be represented using various methods like

CRC Cards
Class Diagram
State Charts
Interaction Diagrams

In this example we will examine CRC cards closely.

A CRC card has a class name, responsiblities of the class and collobarotars (other classes required to complete the responsiblity).

So for the "Withdrawl" class, a CRC card will be designed as follows,

<table border = 1>
Responsibilities Collaborators
Perform operations peculiar to withdrawal transaction use case CustomerConsole
CashDispenser
Message
Receipt
</table>

With this the design is complete. So the rest of the software design includes implemenation and testing which will be convered under ibject oriented programming.
http://en.wikipedia.org/wiki/Object-oriented_programming

== Advantages of OOD ==

*'''Simplicity:''' software objects model real world objects, so the complexity is reduced and the program structure is very clear.

*'''Modularity:''' each object forms a separate entity whose internal workings are decoupled from other parts of the system.

*'''Maintainable:''' objects can be maintained separately, making locating and fixing problems easier.

*'''Re-usability:''' objects contain both data and functions that act on data, objects can be thought of as self-contained “boxes”.This feature
makes it easy to reuse code in new systems.

*'''Scalability:''' object’s interface provides a roadmap for reusing the object in new software and thus provides you with all the information
you need to replace the object without affecting other code.

== References ==

* Principles of Object Oriented Design - http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign

* Object Oriented Programming - http://en.wikipedia.org/wiki/Object-oriented_programming

* Object Oriented Design - http://en.wikipedia.org/wiki/Object-oriented_design

* Object Oriented Concepts - http://download.oracle.com/javase/tutorial/java/concepts

* ATM example - http://math-cs.gordon.edu/courses/cs211/ATMExample/

CSC/ECE 517 Fall 2011/ch1 1e ap

2011-11-03T06:20:44Z

Pramasw3: /* Examples */

Introduction to Object Oriented Design
__TOC__
== Introduction to Object Oriented Programming ==
Object-oriented programming (OOP) is a programming language model organized around "objects" rather than "actions" and data rather than logic. It uses "objects" - data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.

Object-oriented programming takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them. Examples of objects range from human beings (described by name, address, and so forth) to buildings and floors (whose properties can be described and managed) down to the little widgets on your computer desktop (such as buttons and scroll bars).

Object-oriented programming is a method of programming based on a hierarchy of classes, and well-defined and cooperating objects.

*'''Classes'''
The class is the fundamental object-oriented unit. It is a structure that defines the data and the methods to work on that data. Classes define a set of objects that share a common structure and behavior. When you write programs in the Java language, all program data is wrapped in a class.All objects are created from classes, so it important to understand the structure of a class. In fact, it is the design of classes that has fueled the development of various Object Oriented languages.Object is an instance of a class.

*'''Objects'''
An "Object" is binding together of data and behavior, and Object Oriented programming, is the use of objects while solving the problem.
What makes an "object" unique is the formal and explicit combination of these smaller pieces' behavior with its' data into a single entity.

== Object Oriented Design ==

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design. Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis. Much of design involves refining the analysis model through the introduction of classes and algorithms that define exactly how certain required features are realized. Another common design activity is the development of an overall system architecture. This entails organizing the system as a set of major building blocks, such as subsystems or components. For a concurrent system, the architecture includes the basic task or process structure.For a distributed system, it includes the organization of hardware in terms of processors and their interconnections. Basically, object-oriented design (OOD) entails transforming the analysis model into a feasible design. Once the design reaches a sufficient level of specificity, it is translated into an implementation through object-oriented programming. This task can be either relatively straightforward or rather challenging, depending upon the amount of detail in the design.

The first question in OOD ,especially for newcomers, is "How can I decide what classes my program should have in it?" The fundamental rule is that a class should represent some abstraction. For example, a Date class might represent calendar dates, an Integer class might deal with integers, and a Matrix class would represent mathematical matrices. So you need to ask "What kinds of entities does my application manipulate?".

Some examples of potential classes in different application areas would include:

a) GUI/Graphics - Line, Circle, Window, TextArea, Button, Point

b) Architecture - Building, Plot, Room

b) Geography - River, Country, Sea, Continent

Instead of viewing an application as something that performs steps A, B, and C, that is, looking at the program in terms of its functions, instead ask what types of objects and data the application manipulates. Instead of taking a function-oriented approach, take an object-oriented one.

=== Object Oriented Concepts ===
*[http://en.wikipedia.org/wiki/Abstraction_(computer_science) '''Abstraction''']: To implement real world entity into program, class uses the concept of abstraction. Abstraction is a process that involves identifying the crucial behavior of an object and eliminating irrelevant and tedious details.

*[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) '''Encapsulation''']: Binding the data and code to access that data. Encapsulation only refers to a container which has a data and its related functions in it.

*[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) '''Inheritance''']: Defining new classes from the existing one. The new class will get all the methods and properties of the existing class.

*[http://en.wikipedia.org/wiki/Polymorphism_(object-oriented_programming) '''Polymorphism''']: Ability to acquire different forms. There are basically two types of polymorphism. Compile Time (also knows as Early binding) and Run Time (also knows as Late binding) Polymorphism.

*[http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding''']: As encapsulation bind data and methods together, data hiding restrict sensitive data accessing to the system. It is also achieved by using access modifiers i.e. Private, Protected and Public.

== Design principles and patterns ==

=== Object Oriented Design Principles ===

*[http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple '''The LiskovSubstitutionPrinciple (LSP)''']: "An instance of a derived should be able to replace any instance of its superclass"

*[http://c2.com/cgi/wiki?OpenClosedPrinciple '''The OpenClosedPrinciple (OCP)''']: "A reusable class should be open for extension, but closed for modification."

*[http://c2.com/cgi/wiki?DependencyInversionPrinciple '''The DependencyInversionPrinciple (DIP)''']: "The modules that implement a high level policy should not depend on the modules that implement the low level policies, but rather, they should depend on some well-defined interfaces."

*[http://c2.com/cgi/wiki?InterfaceSegregationPrinciple '''The InterfaceSegregationPrinciple (ISP)''']: "The dependency of one class to another one should depend on the smallest possible interface."

*[http://c2.com/cgi/wiki?ReuseReleaseEquivalencePrinciple '''The ReuseReleaseEquivalencePrinciple (REP)''']: "The granule of reuse is the granule of release." module == type, the fusion of distinct notions is what gives OO its distinctive flavor.

*[http://c2.com/cgi/wiki?CommonClosurePrinciple '''The CommonClosurePrinciple (CCP):''']: "The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package."

=== Object Oriented Design Patterns ===

*[http://en.wikipedia.org/wiki/Singleton_pattern '''Singleton'''] - Ensure that only one instance of a class is created and Provide a global access point to the object.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Factory'''] - Creates objects without exposing the instantiation logic to the client and Refers to the newly created object through a common interface.

*[http://en.wikipedia.org/wiki/Command_pattern'''Command'''] - Encapsulate a request in an object, Allows the parameterization of clients with different requests and Allows saving the requests in a queue.

*[http://en.wikipedia.org/wiki/Iterator_pattern '''Iterator'''] - Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Strategy'''] - Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Adapter'''] - Convert the interface of a class into another interface clients expect. / Adapter lets classes work together, that could not otherwise because of incompatible interfaces.

== Examples ==
This section discusses about the ATM example using OOD, developed by Dr.Bjork. The overview of this example is explained below.
Complete example can be found here http://math-cs.gordon.edu/courses/cs211/ATMExample/

The process of object oriented design starts with the requirements followed by analysis, design and the implementation. Let us dicuss about each of these steps in detail.

=== Requirements ===

This design model will help in designing a software that will control a simulated automatic teller machine (ATM).
For a complete list of requirements check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Requirements.html

Though there will be more detailed requirements with secuirty constraints, this page provides the basic requirements an ATM should satisfy.

1.) A customer must be able to make a cash withdrawal from any suitable account linked to the card, in multiples of $20.00. Approval must be obtained from the bank before cash is dispensed.
2.) A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to manual verification when the envelope is removed from the machine by an operator. Approval must be obtained from the bank before physically accepting the envelope.
3.) A customer must be able to make a transfer of money between any two accounts linked to the card.
4.) A customer must be able to make a balance inquiry of any account linked to the card.

=== Analysis ===

The analysis phase involves in finding the use cases, initial test cases and the basic parts (classes) involved in the system.

1.) Use cases:

With the above requirements, we will discuss two important use cases.

Withdrawal Transaction Use Case :

A withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g. checking) from a menu of possible accounts, and to choose a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. (If not, the customer is informed and asked to enter a different amount.) If the transaction is approved by the bank, the appropriate amount of cash is dispensed by the machine before it issues a receipt.

Deposit Transaction Use Case :

A deposit transaction asks the customer to choose a type of account to deposit to (e.g. checking) from a menu of possible accounts, and to type in a dollar amount on the keyboard. The transaction is initially sent to the bank to verify that the ATM can accept a deposit from this customer to this account. If the transaction is approved, the machine accepts an envelope from the customer containing cash and/or checks before it issues a receipt. Once the envelope has been received, a second message is sent to the bank, to confirm that the bank can credit the customer's account - contingent on manual verification of the deposit envelope contents by an operator later.

Use cases are represented using Interaction diagrams. This section is not going to explain the interaction diagrams.
For the interaction diagrams, check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Interactions.html#Startup

2.) Classes

The basic classes of the system can be found using the following conditions

is a singular noun,
does not really have the same functionality as some other class,
is not simply a primitive type.

The classes required for the ATM model will be,

Card reader.
Customer console, consisting of a display and keyboard.
Cash dispenser.
Envelope acceptor.
Receipt printer.
Session.
Transaction.

=== Design ===

The design part includes the process of finding the resposiblities and the interaction of the classes.

The designs can be represented using various methods like

CRC Cards
Class Diagram
State Charts
Interaction Diagrams

In this example we will examine CRC cards closely.

A CRC card has a class name, responsiblities of the class and collobarotars (other classes required to complete the responsiblity).

So for the "Withdrawl" class, a CRC card will be designed as follows,

<table border = 1>
Responsibilities Collaborators
Perform operations peculiar to withdrawal transaction use case CustomerConsole
CashDispenser
Message
Receipt
</table>

With this the design is complete. So the rest of the software design includes implemenation and testing which will be convered under ibject oriented programming.
http://en.wikipedia.org/wiki/Object-oriented_programming

== Advantages of OOD ==

*'''Simplicity:''' software objects model real world objects, so the complexity is reduced and the program structure is very clear.

*'''Modularity:''' each object forms a separate entity whose internal workings are decoupled from other parts of the system.

*'''Maintainable:''' objects can be maintained separately, making locating and fixing problems easier.

*'''Re-usability:''' objects contain both data and functions that act on data, objects can be thought of as self-contained “boxes”.This feature
makes it easy to reuse code in new systems.

*'''Scalability:''' object’s interface provides a roadmap for reusing the object in new software and thus provides you with all the information
you need to replace the object without affecting other code.

== References ==

* Principles of Object Oriented Design - http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign

* Object Oriented Programming - http://en.wikipedia.org/wiki/Object-oriented_programming

* Object Oriented Design - http://en.wikipedia.org/wiki/Object-oriented_design

* Object Oriented Concepts - http://download.oracle.com/javase/tutorial/java/concepts

CSC/ECE 517 Fall 2011/ch1 1e ap

2011-11-03T06:20:10Z

Pramasw3: /* Analysis */

Introduction to Object Oriented Design
__TOC__
== Introduction to Object Oriented Programming ==
Object-oriented programming (OOP) is a programming language model organized around "objects" rather than "actions" and data rather than logic. It uses "objects" - data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.

Object-oriented programming takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them. Examples of objects range from human beings (described by name, address, and so forth) to buildings and floors (whose properties can be described and managed) down to the little widgets on your computer desktop (such as buttons and scroll bars).

Object-oriented programming is a method of programming based on a hierarchy of classes, and well-defined and cooperating objects.

*'''Classes'''
The class is the fundamental object-oriented unit. It is a structure that defines the data and the methods to work on that data. Classes define a set of objects that share a common structure and behavior. When you write programs in the Java language, all program data is wrapped in a class.All objects are created from classes, so it important to understand the structure of a class. In fact, it is the design of classes that has fueled the development of various Object Oriented languages.Object is an instance of a class.

*'''Objects'''
An "Object" is binding together of data and behavior, and Object Oriented programming, is the use of objects while solving the problem.
What makes an "object" unique is the formal and explicit combination of these smaller pieces' behavior with its' data into a single entity.

== Object Oriented Design ==

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design. Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis. Much of design involves refining the analysis model through the introduction of classes and algorithms that define exactly how certain required features are realized. Another common design activity is the development of an overall system architecture. This entails organizing the system as a set of major building blocks, such as subsystems or components. For a concurrent system, the architecture includes the basic task or process structure.For a distributed system, it includes the organization of hardware in terms of processors and their interconnections. Basically, object-oriented design (OOD) entails transforming the analysis model into a feasible design. Once the design reaches a sufficient level of specificity, it is translated into an implementation through object-oriented programming. This task can be either relatively straightforward or rather challenging, depending upon the amount of detail in the design.

The first question in OOD ,especially for newcomers, is "How can I decide what classes my program should have in it?" The fundamental rule is that a class should represent some abstraction. For example, a Date class might represent calendar dates, an Integer class might deal with integers, and a Matrix class would represent mathematical matrices. So you need to ask "What kinds of entities does my application manipulate?".

Some examples of potential classes in different application areas would include:

a) GUI/Graphics - Line, Circle, Window, TextArea, Button, Point

b) Architecture - Building, Plot, Room

b) Geography - River, Country, Sea, Continent

Instead of viewing an application as something that performs steps A, B, and C, that is, looking at the program in terms of its functions, instead ask what types of objects and data the application manipulates. Instead of taking a function-oriented approach, take an object-oriented one.

=== Object Oriented Concepts ===
*[http://en.wikipedia.org/wiki/Abstraction_(computer_science) '''Abstraction''']: To implement real world entity into program, class uses the concept of abstraction. Abstraction is a process that involves identifying the crucial behavior of an object and eliminating irrelevant and tedious details.

*[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) '''Encapsulation''']: Binding the data and code to access that data. Encapsulation only refers to a container which has a data and its related functions in it.

*[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) '''Inheritance''']: Defining new classes from the existing one. The new class will get all the methods and properties of the existing class.

*[http://en.wikipedia.org/wiki/Polymorphism_(object-oriented_programming) '''Polymorphism''']: Ability to acquire different forms. There are basically two types of polymorphism. Compile Time (also knows as Early binding) and Run Time (also knows as Late binding) Polymorphism.

*[http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding''']: As encapsulation bind data and methods together, data hiding restrict sensitive data accessing to the system. It is also achieved by using access modifiers i.e. Private, Protected and Public.

== Design principles and patterns ==

=== Object Oriented Design Principles ===

*[http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple '''The LiskovSubstitutionPrinciple (LSP)''']: "An instance of a derived should be able to replace any instance of its superclass"

*[http://c2.com/cgi/wiki?OpenClosedPrinciple '''The OpenClosedPrinciple (OCP)''']: "A reusable class should be open for extension, but closed for modification."

*[http://c2.com/cgi/wiki?DependencyInversionPrinciple '''The DependencyInversionPrinciple (DIP)''']: "The modules that implement a high level policy should not depend on the modules that implement the low level policies, but rather, they should depend on some well-defined interfaces."

*[http://c2.com/cgi/wiki?InterfaceSegregationPrinciple '''The InterfaceSegregationPrinciple (ISP)''']: "The dependency of one class to another one should depend on the smallest possible interface."

*[http://c2.com/cgi/wiki?ReuseReleaseEquivalencePrinciple '''The ReuseReleaseEquivalencePrinciple (REP)''']: "The granule of reuse is the granule of release." module == type, the fusion of distinct notions is what gives OO its distinctive flavor.

*[http://c2.com/cgi/wiki?CommonClosurePrinciple '''The CommonClosurePrinciple (CCP):''']: "The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package."

=== Object Oriented Design Patterns ===

*[http://en.wikipedia.org/wiki/Singleton_pattern '''Singleton'''] - Ensure that only one instance of a class is created and Provide a global access point to the object.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Factory'''] - Creates objects without exposing the instantiation logic to the client and Refers to the newly created object through a common interface.

*[http://en.wikipedia.org/wiki/Command_pattern'''Command'''] - Encapsulate a request in an object, Allows the parameterization of clients with different requests and Allows saving the requests in a queue.

*[http://en.wikipedia.org/wiki/Iterator_pattern '''Iterator'''] - Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Strategy'''] - Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Adapter'''] - Convert the interface of a class into another interface clients expect. / Adapter lets classes work together, that could not otherwise because of incompatible interfaces.

== Examples ==
This section discusses about the ATM example using OOD, developed by Dr.Bjork. The overview of this example is explained below.
Complete example can be found here http://math-cs.gordon.edu/courses/cs211/ATMExample/

The process of object oriented design starts with the requirements followed by analysis, design and the implementation. Let us dicuss about each of these steps in detail.

=== Requirements ===

This design model will help in designing a software that will control a simulated automatic teller machine (ATM).
For a complete list of requirements check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Requirements.html

Though there will be more detailed requirements with secuirty constraints, this page provides the basic requirements an ATM should satisfy.

1.) A customer must be able to make a cash withdrawal from any suitable account linked to the card, in multiples of $20.00. Approval must be obtained from the bank before cash is dispensed.
2.) A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to manual verification when the envelope is removed from the machine by an operator. Approval must be obtained from the bank before physically accepting the envelope.
3.) A customer must be able to make a transfer of money between any two accounts linked to the card.
4.) A customer must be able to make a balance inquiry of any account linked to the card.

=== Analysis ===

The analysis phase involves in finding the use cases, initial test cases and the basic parts (classes) involved in the system.

1.) Use cases:

With the above requirements, we will discuss two important use cases.

Withdrawal Transaction Use Case :
A withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g. checking) from a menu of possible accounts, and to choose a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. (If not, the customer is informed and asked to enter a different amount.) If the transaction is approved by the bank, the appropriate amount of cash is dispensed by the machine before it issues a receipt.

Deposit Transaction Use Case :

A deposit transaction asks the customer to choose a type of account to deposit to (e.g. checking) from a menu of possible accounts, and to type in a dollar amount on the keyboard. The transaction is initially sent to the bank to verify that the ATM can accept a deposit from this customer to this account. If the transaction is approved, the machine accepts an envelope from the customer containing cash and/or checks before it issues a receipt. Once the envelope has been received, a second message is sent to the bank, to confirm that the bank can credit the customer's account - contingent on manual verification of the deposit envelope contents by an operator later.

Use cases are represented using Interaction diagrams. This section is not going to explain the interaction diagrams.
For the interaction diagrams, check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Interactions.html#Startup

2.) Classes

The basic classes of the system can be found using the following conditions

is a singular noun,
does not really have the same functionality as some other class,
is not simply a primitive type.

The classes required for the ATM model will be,

Card reader.
Customer console, consisting of a display and keyboard.
Cash dispenser.
Envelope acceptor.
Receipt printer.
Session.
Transaction.

=== Design ===

The design part includes the process of finding the resposiblities and the interaction of the classes.

The designs can be represented using various methods like

CRC Cards
Class Diagram
State Charts
Interaction Diagrams

In this example we will examine CRC cards closely.

A CRC card has a class name, responsiblities of the class and collobarotars (other classes required to complete the responsiblity).

So for the "Withdrawl" class, a CRC card will be designed as follows,

<table border = 1>
Responsibilities Collaborators
Perform operations peculiar to withdrawal transaction use case CustomerConsole
CashDispenser
Message
Receipt
</table>

With this the design is complete. So the rest of the software design includes implemenation and testing which will be convered under ibject oriented programming.
http://en.wikipedia.org/wiki/Object-oriented_programming

== Advantages of OOD ==

*'''Simplicity:''' software objects model real world objects, so the complexity is reduced and the program structure is very clear.

*'''Modularity:''' each object forms a separate entity whose internal workings are decoupled from other parts of the system.

*'''Maintainable:''' objects can be maintained separately, making locating and fixing problems easier.

*'''Re-usability:''' objects contain both data and functions that act on data, objects can be thought of as self-contained “boxes”.This feature
makes it easy to reuse code in new systems.

*'''Scalability:''' object’s interface provides a roadmap for reusing the object in new software and thus provides you with all the information
you need to replace the object without affecting other code.

== References ==

* Principles of Object Oriented Design - http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign

* Object Oriented Programming - http://en.wikipedia.org/wiki/Object-oriented_programming

* Object Oriented Design - http://en.wikipedia.org/wiki/Object-oriented_design

* Object Oriented Concepts - http://download.oracle.com/javase/tutorial/java/concepts

CSC/ECE 517 Fall 2011/ch1 1e ap

2011-11-03T06:19:04Z

Pramasw3: /* Examples */

Introduction to Object Oriented Design
__TOC__
== Introduction to Object Oriented Programming ==
Object-oriented programming (OOP) is a programming language model organized around "objects" rather than "actions" and data rather than logic. It uses "objects" - data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.

Object-oriented programming takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them. Examples of objects range from human beings (described by name, address, and so forth) to buildings and floors (whose properties can be described and managed) down to the little widgets on your computer desktop (such as buttons and scroll bars).

Object-oriented programming is a method of programming based on a hierarchy of classes, and well-defined and cooperating objects.

*'''Classes'''
The class is the fundamental object-oriented unit. It is a structure that defines the data and the methods to work on that data. Classes define a set of objects that share a common structure and behavior. When you write programs in the Java language, all program data is wrapped in a class.All objects are created from classes, so it important to understand the structure of a class. In fact, it is the design of classes that has fueled the development of various Object Oriented languages.Object is an instance of a class.

*'''Objects'''
An "Object" is binding together of data and behavior, and Object Oriented programming, is the use of objects while solving the problem.
What makes an "object" unique is the formal and explicit combination of these smaller pieces' behavior with its' data into a single entity.

== Object Oriented Design ==

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design. Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis. Much of design involves refining the analysis model through the introduction of classes and algorithms that define exactly how certain required features are realized. Another common design activity is the development of an overall system architecture. This entails organizing the system as a set of major building blocks, such as subsystems or components. For a concurrent system, the architecture includes the basic task or process structure.For a distributed system, it includes the organization of hardware in terms of processors and their interconnections. Basically, object-oriented design (OOD) entails transforming the analysis model into a feasible design. Once the design reaches a sufficient level of specificity, it is translated into an implementation through object-oriented programming. This task can be either relatively straightforward or rather challenging, depending upon the amount of detail in the design.

The first question in OOD ,especially for newcomers, is "How can I decide what classes my program should have in it?" The fundamental rule is that a class should represent some abstraction. For example, a Date class might represent calendar dates, an Integer class might deal with integers, and a Matrix class would represent mathematical matrices. So you need to ask "What kinds of entities does my application manipulate?".

Some examples of potential classes in different application areas would include:

a) GUI/Graphics - Line, Circle, Window, TextArea, Button, Point

b) Architecture - Building, Plot, Room

b) Geography - River, Country, Sea, Continent

Instead of viewing an application as something that performs steps A, B, and C, that is, looking at the program in terms of its functions, instead ask what types of objects and data the application manipulates. Instead of taking a function-oriented approach, take an object-oriented one.

=== Object Oriented Concepts ===
*[http://en.wikipedia.org/wiki/Abstraction_(computer_science) '''Abstraction''']: To implement real world entity into program, class uses the concept of abstraction. Abstraction is a process that involves identifying the crucial behavior of an object and eliminating irrelevant and tedious details.

*[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) '''Encapsulation''']: Binding the data and code to access that data. Encapsulation only refers to a container which has a data and its related functions in it.

*[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) '''Inheritance''']: Defining new classes from the existing one. The new class will get all the methods and properties of the existing class.

*[http://en.wikipedia.org/wiki/Polymorphism_(object-oriented_programming) '''Polymorphism''']: Ability to acquire different forms. There are basically two types of polymorphism. Compile Time (also knows as Early binding) and Run Time (also knows as Late binding) Polymorphism.

*[http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding''']: As encapsulation bind data and methods together, data hiding restrict sensitive data accessing to the system. It is also achieved by using access modifiers i.e. Private, Protected and Public.

== Design principles and patterns ==

=== Object Oriented Design Principles ===

*[http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple '''The LiskovSubstitutionPrinciple (LSP)''']: "An instance of a derived should be able to replace any instance of its superclass"

*[http://c2.com/cgi/wiki?OpenClosedPrinciple '''The OpenClosedPrinciple (OCP)''']: "A reusable class should be open for extension, but closed for modification."

*[http://c2.com/cgi/wiki?DependencyInversionPrinciple '''The DependencyInversionPrinciple (DIP)''']: "The modules that implement a high level policy should not depend on the modules that implement the low level policies, but rather, they should depend on some well-defined interfaces."

*[http://c2.com/cgi/wiki?InterfaceSegregationPrinciple '''The InterfaceSegregationPrinciple (ISP)''']: "The dependency of one class to another one should depend on the smallest possible interface."

*[http://c2.com/cgi/wiki?ReuseReleaseEquivalencePrinciple '''The ReuseReleaseEquivalencePrinciple (REP)''']: "The granule of reuse is the granule of release." module == type, the fusion of distinct notions is what gives OO its distinctive flavor.

*[http://c2.com/cgi/wiki?CommonClosurePrinciple '''The CommonClosurePrinciple (CCP):''']: "The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package."

=== Object Oriented Design Patterns ===

*[http://en.wikipedia.org/wiki/Singleton_pattern '''Singleton'''] - Ensure that only one instance of a class is created and Provide a global access point to the object.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Factory'''] - Creates objects without exposing the instantiation logic to the client and Refers to the newly created object through a common interface.

*[http://en.wikipedia.org/wiki/Command_pattern'''Command'''] - Encapsulate a request in an object, Allows the parameterization of clients with different requests and Allows saving the requests in a queue.

*[http://en.wikipedia.org/wiki/Iterator_pattern '''Iterator'''] - Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Strategy'''] - Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Adapter'''] - Convert the interface of a class into another interface clients expect. / Adapter lets classes work together, that could not otherwise because of incompatible interfaces.

== Examples ==
This section discusses about the ATM example using OOD, developed by Dr.Bjork. The overview of this example is explained below.
Complete example can be found here http://math-cs.gordon.edu/courses/cs211/ATMExample/

The process of object oriented design starts with the requirements followed by analysis, design and the implementation. Let us dicuss about each of these steps in detail.

=== Requirements ===

This design model will help in designing a software that will control a simulated automatic teller machine (ATM).
For a complete list of requirements check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Requirements.html

Though there will be more detailed requirements with secuirty constraints, this page provides the basic requirements an ATM should satisfy.

1.) A customer must be able to make a cash withdrawal from any suitable account linked to the card, in multiples of $20.00. Approval must be obtained from the bank before cash is dispensed.
2.) A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to manual verification when the envelope is removed from the machine by an operator. Approval must be obtained from the bank before physically accepting the envelope.
3.) A customer must be able to make a transfer of money between any two accounts linked to the card.
4.) A customer must be able to make a balance inquiry of any account linked to the card.

=== Analysis ===

The analysis phase involves in finding the use cases, initial test cases and the basic parts (classes) involved in the system.

1.) Use cases:

With the above requirements, we will discuss two important use cases.

Withdrawal Transaction Use Case : A withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g. checking) from a menu of possible accounts, and to choose a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. (If not, the customer is informed and asked to enter a different amount.) If the transaction is approved by the bank, the appropriate amount of cash is dispensed by the machine before it issues a receipt.

Deposit Transaction Use Case : A deposit transaction asks the customer to choose a type of account to deposit to (e.g. checking) from a menu of possible accounts, and to type in a dollar amount on the keyboard. The transaction is initially sent to the bank to verify that the ATM can accept a deposit from this customer to this account. If the transaction is approved, the machine accepts an envelope from the customer containing cash and/or checks before it issues a receipt. Once the envelope has been received, a second message is sent to the bank, to confirm that the bank can credit the customer's account - contingent on manual verification of the deposit envelope contents by an operator later.

Use cases are represented using Interaction diagrams. This section is not going to explain the interaction diagrams.
For the interaction diagrams, check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Interactions.html#Startup

2.) Classes

The basic classes of the system can be found using the following conditions

is a singular noun,
does not really have the same functionality as some other class,
is not simply a primitive type.

The classes required for the ATM model will be,

Card reader.
Customer console, consisting of a display and keyboard.
Cash dispenser.
Envelope acceptor.
Receipt printer.
Session.
Transaction.

=== Design ===

The design part includes the process of finding the resposiblities and the interaction of the classes.

The designs can be represented using various methods like

CRC Cards
Class Diagram
State Charts
Interaction Diagrams

In this example we will examine CRC cards closely.

A CRC card has a class name, responsiblities of the class and collobarotars (other classes required to complete the responsiblity).

So for the "Withdrawl" class, a CRC card will be designed as follows,

<table border = 1>
Responsibilities Collaborators
Perform operations peculiar to withdrawal transaction use case CustomerConsole
CashDispenser
Message
Receipt
</table>

With this the design is complete. So the rest of the software design includes implemenation and testing which will be convered under ibject oriented programming.
http://en.wikipedia.org/wiki/Object-oriented_programming

== Advantages of OOD ==

*'''Simplicity:''' software objects model real world objects, so the complexity is reduced and the program structure is very clear.

*'''Modularity:''' each object forms a separate entity whose internal workings are decoupled from other parts of the system.

*'''Maintainable:''' objects can be maintained separately, making locating and fixing problems easier.

*'''Re-usability:''' objects contain both data and functions that act on data, objects can be thought of as self-contained “boxes”.This feature
makes it easy to reuse code in new systems.

*'''Scalability:''' object’s interface provides a roadmap for reusing the object in new software and thus provides you with all the information
you need to replace the object without affecting other code.

== References ==

* Principles of Object Oriented Design - http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign

* Object Oriented Programming - http://en.wikipedia.org/wiki/Object-oriented_programming

* Object Oriented Design - http://en.wikipedia.org/wiki/Object-oriented_design

* Object Oriented Concepts - http://download.oracle.com/javase/tutorial/java/concepts

CSC/ECE 517 Fall 2011/ch1 1e ap

2011-11-03T06:15:51Z

Pramasw3: /* Examples */

Introduction to Object Oriented Design
__TOC__
== Introduction to Object Oriented Programming ==
Object-oriented programming (OOP) is a programming language model organized around "objects" rather than "actions" and data rather than logic. It uses "objects" - data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.

Object-oriented programming takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them. Examples of objects range from human beings (described by name, address, and so forth) to buildings and floors (whose properties can be described and managed) down to the little widgets on your computer desktop (such as buttons and scroll bars).

Object-oriented programming is a method of programming based on a hierarchy of classes, and well-defined and cooperating objects.

*'''Classes'''
The class is the fundamental object-oriented unit. It is a structure that defines the data and the methods to work on that data. Classes define a set of objects that share a common structure and behavior. When you write programs in the Java language, all program data is wrapped in a class.All objects are created from classes, so it important to understand the structure of a class. In fact, it is the design of classes that has fueled the development of various Object Oriented languages.Object is an instance of a class.

*'''Objects'''
An "Object" is binding together of data and behavior, and Object Oriented programming, is the use of objects while solving the problem.
What makes an "object" unique is the formal and explicit combination of these smaller pieces' behavior with its' data into a single entity.

== Object Oriented Design ==

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design. Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis. Much of design involves refining the analysis model through the introduction of classes and algorithms that define exactly how certain required features are realized. Another common design activity is the development of an overall system architecture. This entails organizing the system as a set of major building blocks, such as subsystems or components. For a concurrent system, the architecture includes the basic task or process structure.For a distributed system, it includes the organization of hardware in terms of processors and their interconnections. Basically, object-oriented design (OOD) entails transforming the analysis model into a feasible design. Once the design reaches a sufficient level of specificity, it is translated into an implementation through object-oriented programming. This task can be either relatively straightforward or rather challenging, depending upon the amount of detail in the design.

The first question in OOD ,especially for newcomers, is "How can I decide what classes my program should have in it?" The fundamental rule is that a class should represent some abstraction. For example, a Date class might represent calendar dates, an Integer class might deal with integers, and a Matrix class would represent mathematical matrices. So you need to ask "What kinds of entities does my application manipulate?".

Some examples of potential classes in different application areas would include:

a) GUI/Graphics - Line, Circle, Window, TextArea, Button, Point

b) Architecture - Building, Plot, Room

b) Geography - River, Country, Sea, Continent

Instead of viewing an application as something that performs steps A, B, and C, that is, looking at the program in terms of its functions, instead ask what types of objects and data the application manipulates. Instead of taking a function-oriented approach, take an object-oriented one.

=== Object Oriented Concepts ===
*[http://en.wikipedia.org/wiki/Abstraction_(computer_science) '''Abstraction''']: To implement real world entity into program, class uses the concept of abstraction. Abstraction is a process that involves identifying the crucial behavior of an object and eliminating irrelevant and tedious details.

*[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) '''Encapsulation''']: Binding the data and code to access that data. Encapsulation only refers to a container which has a data and its related functions in it.

*[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) '''Inheritance''']: Defining new classes from the existing one. The new class will get all the methods and properties of the existing class.

*[http://en.wikipedia.org/wiki/Polymorphism_(object-oriented_programming) '''Polymorphism''']: Ability to acquire different forms. There are basically two types of polymorphism. Compile Time (also knows as Early binding) and Run Time (also knows as Late binding) Polymorphism.

*[http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding''']: As encapsulation bind data and methods together, data hiding restrict sensitive data accessing to the system. It is also achieved by using access modifiers i.e. Private, Protected and Public.

== Design principles and patterns ==

=== Object Oriented Design Principles ===

*[http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple '''The LiskovSubstitutionPrinciple (LSP)''']: "An instance of a derived should be able to replace any instance of its superclass"

*[http://c2.com/cgi/wiki?OpenClosedPrinciple '''The OpenClosedPrinciple (OCP)''']: "A reusable class should be open for extension, but closed for modification."

*[http://c2.com/cgi/wiki?DependencyInversionPrinciple '''The DependencyInversionPrinciple (DIP)''']: "The modules that implement a high level policy should not depend on the modules that implement the low level policies, but rather, they should depend on some well-defined interfaces."

*[http://c2.com/cgi/wiki?InterfaceSegregationPrinciple '''The InterfaceSegregationPrinciple (ISP)''']: "The dependency of one class to another one should depend on the smallest possible interface."

*[http://c2.com/cgi/wiki?ReuseReleaseEquivalencePrinciple '''The ReuseReleaseEquivalencePrinciple (REP)''']: "The granule of reuse is the granule of release." module == type, the fusion of distinct notions is what gives OO its distinctive flavor.

*[http://c2.com/cgi/wiki?CommonClosurePrinciple '''The CommonClosurePrinciple (CCP):''']: "The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package."

=== Object Oriented Design Patterns ===

*[http://en.wikipedia.org/wiki/Singleton_pattern '''Singleton'''] - Ensure that only one instance of a class is created and Provide a global access point to the object.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Factory'''] - Creates objects without exposing the instantiation logic to the client and Refers to the newly created object through a common interface.

*[http://en.wikipedia.org/wiki/Command_pattern'''Command'''] - Encapsulate a request in an object, Allows the parameterization of clients with different requests and Allows saving the requests in a queue.

*[http://en.wikipedia.org/wiki/Iterator_pattern '''Iterator'''] - Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Strategy'''] - Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

*[http://en.wikipedia.org/wiki/Factory_pattern '''Adapter'''] - Convert the interface of a class into another interface clients expect. / Adapter lets classes work together, that could not otherwise because of incompatible interfaces.

== Examples ==
This section discusses about the ATM example using OOD, developed by Dr.Bjork. The overview of this example is explained below.
Complete example can be found here http://math-cs.gordon.edu/courses/cs211/ATMExample/

The process of object oriented design starts with the requirements followed by analysis, design and the implementation. Let us dicuss about each of these steps in detail.

Requirements:

This design model will help in designing a software that will control a simulated automatic teller machine (ATM).
For a complete list of requirements check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Requirements.html

Though there will be more detailed requirements with secuirty constraints, this page provides the basic requirements an ATM should satisfy.

1.) A customer must be able to make a cash withdrawal from any suitable account linked to the card, in multiples of $20.00. Approval must be obtained from the bank before cash is dispensed.
2.) A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to manual verification when the envelope is removed from the machine by an operator. Approval must be obtained from the bank before physically accepting the envelope.
3.) A customer must be able to make a transfer of money between any two accounts linked to the card.
4.) A customer must be able to make a balance inquiry of any account linked to the card.

Analysis:

The analysis phase involves in finding the use cases, initial test cases and the basic parts (classes) involved in the system.

1.) Use cases:

With the above requirements, we will discuss two important use cases.

Withdrawal Transaction Use Case : A withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g. checking) from a menu of possible accounts, and to choose a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. (If not, the customer is informed and asked to enter a different amount.) If the transaction is approved by the bank, the appropriate amount of cash is dispensed by the machine before it issues a receipt.

Deposit Transaction Use Case : A deposit transaction asks the customer to choose a type of account to deposit to (e.g. checking) from a menu of possible accounts, and to type in a dollar amount on the keyboard. The transaction is initially sent to the bank to verify that the ATM can accept a deposit from this customer to this account. If the transaction is approved, the machine accepts an envelope from the customer containing cash and/or checks before it issues a receipt. Once the envelope has been received, a second message is sent to the bank, to confirm that the bank can credit the customer's account - contingent on manual verification of the deposit envelope contents by an operator later.

Use cases are represented using Interaction diagrams. This section is not going to explain the interaction diagrams.
For the interaction diagrams, check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Interactions.html#Startup

2.) Classes

The basic classes of the system can be found using the following conditions

is a singular noun,
does not really have the same functionality as some other class,
is not simply a primitive type.

The classes required for the ATM model will be,

Card reader.
Customer console, consisting of a display and keyboard.
Cash dispenser.
Envelope acceptor.
Receipt printer.
Session.
Transaction.

Design :

The design part includes the process of finding the resposiblities and the interaction of the classes.

The designs can be represented using various methods like

CRC Cards
Class Diagram
State Charts
Interaction Diagrams

In this example we will examine CRC cards closely.

A CRC card has a class name, responsiblities of the class and collobarotars (other classes required to complete the responsiblity).

So for the "Withdrawl" class, a CRC card will be designed as follows,

Responsibilities Collaborators
Perform operations peculiar to withdrawal transaction use case CustomerConsole
CashDispenser
Message
Receipt

With this the design is complete. So the rest of the software design includes implemenation and testing which will be convered under ibject oriented programming.
http://en.wikipedia.org/wiki/Object-oriented_programming

== Advantages of OOD ==

*'''Simplicity:''' software objects model real world objects, so the complexity is reduced and the program structure is very clear.

*'''Modularity:''' each object forms a separate entity whose internal workings are decoupled from other parts of the system.

*'''Maintainable:''' objects can be maintained separately, making locating and fixing problems easier.

*'''Re-usability:''' objects contain both data and functions that act on data, objects can be thought of as self-contained “boxes”.This feature
makes it easy to reuse code in new systems.

*'''Scalability:''' object’s interface provides a roadmap for reusing the object in new software and thus provides you with all the information
you need to replace the object without affecting other code.

== References ==

* Principles of Object Oriented Design - http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign

* Object Oriented Programming - http://en.wikipedia.org/wiki/Object-oriented_programming

* Object Oriented Design - http://en.wikipedia.org/wiki/Object-oriented_design

* Object Oriented Concepts - http://download.oracle.com/javase/tutorial/java/concepts

CSC/ECE 517 Fall 2011/ch1 1e ap

2011-11-02T15:55:53Z

Pramasw3:

CSC/ECE 517 Fall 2011/ch1 1e ap

2011-11-02T15:51:45Z

Pramasw3:

CSC/ECE 517 Fall 2011/ch1 1e ap

2011-11-02T15:51:19Z

Pramasw3:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-26T01:21:46Z

Pramasw3: /* Introduction */

Common Attribute/Member Syntax 

Different object oriented programming languages include different ways of accessing the member variables and methods. This page discusses the various usages and their advantages and disadvantages.

== Introduction ==
The purpose of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] is to make programs model things the way people think or deal with the world i.e it's modeled around data rather than logic. An object-oriented program may be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. In OOP, each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent "machine" with a distinct role or responsibility. The actions (or "methods") on these objects are closely associated with the object. 

Objects form the basis of OOP. Every Object wraps the data within a set of functions which helps to handle different appropriately. Let us now look at objects, their manipulation and the ways to do so.

== Objects - Attributes and Methods ==
<table>
<tr>
<td>
Similar to real world objects, software objects also consist of state and related behavior. An object stores it's state in attributes and exposes its behavior through methods. Let's look at the pseudo code for a bicycle object.
<pre>
CLASS Bicycle
ATTRIBUTES:
speed: NUMBER
gear: NUMBER
pedal_cadence: NUMBER
METHODS:
ride(speed)
changeGear(gear)
changeCadence(pedal_cadence)
</pre>
</td>
<td>[[File:concepts-object.gif]]</td>
</tr>
</table>
In the above pseudo code, the attributes define the object and the methods provide a way of achieving the desired functionality from that object. The methods use the attributes to manipulate the object and achieve the functionality. From this we can observe that this manipulation is the very essence of programming using objects. Therefore the access of attributes and way of defining method calls very important in OOP.

== Method call / Instance Variable reference Syntax ==
A running debate in O-O languages is whether method calls and instance-variable references should have the same syntax. Different programming languages implement this in different ways. Let's look at them by examples.

=== Same Syntax ===
Languages like Ruby use the same syntax for method calls and variable references. There is no distinction between these. We can see this in the example below:
<pre>
class Song
def duration=(newDuration)
@duration = newDuration
end
end
aSong = Song.new("Bicylops", "Fleck", 260)
aSong.duration » 260
aSong.duration = 257 # set attribute with updated value
aSong.duration » 257
</pre>

This makes it simpler for the programmer to code. Also, it presents uniformity in the code.

=== Differing Syntax ===
Languages like Java employ different syntax for method calls and variable references as seen in this example below:
<pre>
class Song{
int duration;
Song(){}
void setDuration(int dur){
duration = dur;
}
}

Song sng = new Song();
sng.setDuration(260);
System.out.println("Song duration = "+sng.duration);
</pre>

As seen above, a method is always called using parenthesis, within which arguments may be included if required. However, instance variable is accessed directly.

== Getters and Setters and their Advantages ==
One of the principles of Objected Oriented Design is that an object's implementation should not be exposed to other classes. This is to avoid difficulty in maintenance. Getters and setters provide a way to read or write private data of a class for any kind of manipulation. They also provide for easy maintenance, in that, if any change needs to be made in the way the variable is set, only the setter method needs to be changed rather than looking for it and changing in every place. These methods also improve the code readability and bring about uniformity across the code.

== Comparison of syntax between various Programming Languages ==
The usage syntax of methods, instance variables, getters and setters is in the table below

{|class="wikitable"
|-
!Programming Languages
!Method call
!Fields/Attributes
!Getter / Setter
!Comparison
|-
|ABAP (Advanced Business Application Programming)
|<pre>
CALL METHOD <meth> EXPORTING... <ii> =.<f i>...
IMPORTING... <ei> =.<g i>...
CHANGING ... <ci> =.<f i>...
RECEIVING r = h
EXCEPTIONS... <ei> = rc i...
</pre>
|data field type type
|Same as other methods with the only difference that they start with SET or GET
|Syntax is different for method calls and instance-variable reference
|-
|C++
|ObjectName.MethodName(parameters)
|Same as methods. Example below:
<pre>
int getHealth() const { return health; }
void setHealth(int h) { health = h; }
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|C#
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|They are just like methods. Example below:
<pre>
public string GetName()
{
return m_name;
}

public void SetName(string name)
{
m_name = name;
}
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|Java
|ObjectName.MethodName(parameters) [Eg: x.method()]
|ObjectName.Attribute [Eg: x.field]
|They are nothing but method calls
|Different syntax is used to call methods and instance-variable references
|-
|D
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|No need for getters and setters. It can be directly accessed.
<pre>
import std.stdio;

class Car
{
float speed = 1.0;
}

void main(){
auto my_car = new Car();
my_car.speed = 2.5;
writefln(my_car.speed);
}
</pre>
|Syntax used for method calls and variable references is different
|-
|Objective C
|output = [object methodWithOutput]
|ObjectName->Attribute
|An example of getter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}

- (NSString*) caption;
- (NSString*) photographer;

@end
</pre>
An example of setter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}
- (NSString*) caption;
- (NSString*) photographer;

- (void) setCaption: (NSString*)input;
- (void) setPhotographer: (NSString*)input;

@end
</pre>
|Syntax used for method calls and variable references is different
|-
|Python
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|Pythonic way of implementing getters and setters is to using public members and turning them into properties when needed
|Syntax used for method calls and variable references is sometimes the same and different at times (when there are arguments)
|-
|Javascript
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
var lost = {
loc : "Island",
get location () {
return this.loc;
},
set location(val) {
this.loc = val;
}
};
lost.location = "Another island";
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|PHP
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference
|-
|VB.NET
|ObjectName.MethodName(Parameters);
ObjectNmae.MethodName
|ObjectName.Attribute
|<pre>
Public Property myProperty As String
Get
Return String.Empty
End Get
Private Set(ByVal value As String)
somethingElse = value
End Set
End Property
</pre>
|Syntax may be same for method calls and instance-variable reference
|-
|Ruby
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>
class Message
attr_reader :message
def message=(m)
@message = m.dup
end
end

class Message
attr_writer :message
def message
@message.encode!("UTF-8")
end
end
</pre>
|Syntax is same for method calls and instance-variable reference
|-
|Lua
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
local index = getters and
function(self, key)
-- read from getter, else from fallback
local func = getters[key]
if func then return func(self) else return fallback[key] end
end
or fallback -- default to fast property reads through table
local newindex = setters and
function(self, key, value)
-- write to setter, else to proxy
local func = setters[key]
if func then func(self, value)
else rawset(self, key, value) end
end
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|Perl
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>

BEGIN {
my @attr = qw(author title number);
no strict 'refs';
for my $a (@attr){
*{__PACKAGE__ . "::get_$a"} = sub { $_[0]->{$a} };
*{__PACKAGE__ . "::set_$a"} = sub { $_[0]->{$a} = $_[1] };
}
}
</pre>
|Syntax is different for method calls and instance-variable reference
|}

== Conclusion ==

Having getters and setters in the implementation has its own advantages and disadvantages. The advantages are that
<ol>
<li>They provide data encapsulation.</li>
<li>They improve the code readability.</li>
<li>Changes can be made only to the implementation without making changes to the code that uses the object.</li>
</ol>
Using getters and setters also has a disadvantage. They largely provide access to implementation details. But this could hinder data abstraction, i.e. hiding the object's implementation of a message handler. Consider a getter function that returns a number. Wherever this method is called, the variable which holds the return value must match the return type of this function. Now if we change they way this method is implemented by changing the return type, then there could be trouble.

Therefore it is important to design such that there is minimal data movement thereby minimizing possible errors.
Using the same syntax for method calls and instance variable references have some advantages and disadvantages. One could argue that having the same syntax makes it simpler for the programmer. It makes the code lighter in terms of lines of code, thus avoiding bulky code. However, including distinct ways for using methods and variables enhances readability by enabling better understanding. This is possible because the manipulation is visible whereas if the syntax were the same(i.e. compact), the one reading has no idea about what is happening "under the hood".

== References ==
<ol>
<li>[http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(object-oriented_programming)/ Comparison of Programming Languages]</li>
<li>[http://forums.sdn.sap.com/thread.jspa?threadID=529448&tstart=6135/ Setters and Getters in ABAP]</li>
<li>[http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?page=1/ Why getters and setters are evil?]</li>
<li>[http://www.zeuscmd.com/tutorials/cplusplus/50-GettersAndSetters.php/ Getters and Setters]</li>
<li>[http://cocoadevcentral.com/d/learn_objectivec/ Objective C]</li>
<li>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_classes.html/ Ruby Classes- Objects]</li>
<li>[http://www.vbtutor.in/getting-started-with-visual-basic-net/object-oriented-programming-in-vbnet/ VB.Net Object oriented programming]</li>
<li>[https://developer.mozilla.org/en/Introduction_to_Object-Oriented_JavaScript/ Javascript - Functions/Objects]</li>
<li>[http://www.massassi.com/php/articles/classes/ PHP - Objects]</li>
<li>[http://www.tutorialspoint.com/perl/perl_oo_perl.htm/ Perl - Objects]</li>
</ol>

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-26T01:20:57Z

Pramasw3: /* Introduction */

Common Attribute/Member Syntax 

Different object oriented programming languages include different ways of accessing the member variables and methods. This page discusses the various usages and their advantages and disadvantages.

== Introduction ==
The purpose of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] is to make programs model things the way people think or deal with the world i.e it's modeled around data rather than logic. An object-oriented program may be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. In OOP, each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent "machine" with a distinct role or responsibility. The actions (or "methods") on these objects are closely associated with the object. 
 

Objects form the basis of OOP. Every Object wraps the data within a set of functions which helps to handle different appropriately. Let us now look at objects, their manipulation and the ways to do so.

== Objects - Attributes and Methods ==
<table>
<tr>
<td>
Similar to real world objects, software objects also consist of state and related behavior. An object stores it's state in attributes and exposes its behavior through methods. Let's look at the pseudo code for a bicycle object.
<pre>
CLASS Bicycle
ATTRIBUTES:
speed: NUMBER
gear: NUMBER
pedal_cadence: NUMBER
METHODS:
ride(speed)
changeGear(gear)
changeCadence(pedal_cadence)
</pre>
</td>
<td>[[File:concepts-object.gif]]</td>
</tr>
</table>
In the above pseudo code, the attributes define the object and the methods provide a way of achieving the desired functionality from that object. The methods use the attributes to manipulate the object and achieve the functionality. From this we can observe that this manipulation is the very essence of programming using objects. Therefore the access of attributes and way of defining method calls very important in OOP.

== Method call / Instance Variable reference Syntax ==
A running debate in O-O languages is whether method calls and instance-variable references should have the same syntax. Different programming languages implement this in different ways. Let's look at them by examples.

=== Same Syntax ===
Languages like Ruby use the same syntax for method calls and variable references. There is no distinction between these. We can see this in the example below:
<pre>
class Song
def duration=(newDuration)
@duration = newDuration
end
end
aSong = Song.new("Bicylops", "Fleck", 260)
aSong.duration » 260
aSong.duration = 257 # set attribute with updated value
aSong.duration » 257
</pre>

This makes it simpler for the programmer to code. Also, it presents uniformity in the code.

=== Differing Syntax ===
Languages like Java employ different syntax for method calls and variable references as seen in this example below:
<pre>
class Song{
int duration;
Song(){}
void setDuration(int dur){
duration = dur;
}
}

Song sng = new Song();
sng.setDuration(260);
System.out.println("Song duration = "+sng.duration);
</pre>

As seen above, a method is always called using parenthesis, within which arguments may be included if required. However, instance variable is accessed directly.

== Getters and Setters and their Advantages ==
One of the principles of Objected Oriented Design is that an object's implementation should not be exposed to other classes. This is to avoid difficulty in maintenance. Getters and setters provide a way to read or write private data of a class for any kind of manipulation. They also provide for easy maintenance, in that, if any change needs to be made in the way the variable is set, only the setter method needs to be changed rather than looking for it and changing in every place. These methods also improve the code readability and bring about uniformity across the code.

== Comparison of syntax between various Programming Languages ==
The usage syntax of methods, instance variables, getters and setters is in the table below

{|class="wikitable"
|-
!Programming Languages
!Method call
!Fields/Attributes
!Getter / Setter
!Comparison
|-
|ABAP (Advanced Business Application Programming)
|<pre>
CALL METHOD <meth> EXPORTING... <ii> =.<f i>...
IMPORTING... <ei> =.<g i>...
CHANGING ... <ci> =.<f i>...
RECEIVING r = h
EXCEPTIONS... <ei> = rc i...
</pre>
|data field type type
|Same as other methods with the only difference that they start with SET or GET
|Syntax is different for method calls and instance-variable reference
|-
|C++
|ObjectName.MethodName(parameters)
|Same as methods. Example below:
<pre>
int getHealth() const { return health; }
void setHealth(int h) { health = h; }
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|C#
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|They are just like methods. Example below:
<pre>
public string GetName()
{
return m_name;
}

public void SetName(string name)
{
m_name = name;
}
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|Java
|ObjectName.MethodName(parameters) [Eg: x.method()]
|ObjectName.Attribute [Eg: x.field]
|They are nothing but method calls
|Different syntax is used to call methods and instance-variable references
|-
|D
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|No need for getters and setters. It can be directly accessed.
<pre>
import std.stdio;

class Car
{
float speed = 1.0;
}

void main(){
auto my_car = new Car();
my_car.speed = 2.5;
writefln(my_car.speed);
}
</pre>
|Syntax used for method calls and variable references is different
|-
|Objective C
|output = [object methodWithOutput]
|ObjectName->Attribute
|An example of getter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}

- (NSString*) caption;
- (NSString*) photographer;

@end
</pre>
An example of setter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}
- (NSString*) caption;
- (NSString*) photographer;

- (void) setCaption: (NSString*)input;
- (void) setPhotographer: (NSString*)input;

@end
</pre>
|Syntax used for method calls and variable references is different
|-
|Python
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|Pythonic way of implementing getters and setters is to using public members and turning them into properties when needed
|Syntax used for method calls and variable references is sometimes the same and different at times (when there are arguments)
|-
|Javascript
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
var lost = {
loc : "Island",
get location () {
return this.loc;
},
set location(val) {
this.loc = val;
}
};
lost.location = "Another island";
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|PHP
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference
|-
|VB.NET
|ObjectName.MethodName(Parameters);
ObjectNmae.MethodName
|ObjectName.Attribute
|<pre>
Public Property myProperty As String
Get
Return String.Empty
End Get
Private Set(ByVal value As String)
somethingElse = value
End Set
End Property
</pre>
|Syntax may be same for method calls and instance-variable reference
|-
|Ruby
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>
class Message
attr_reader :message
def message=(m)
@message = m.dup
end
end

class Message
attr_writer :message
def message
@message.encode!("UTF-8")
end
end
</pre>
|Syntax is same for method calls and instance-variable reference
|-
|Lua
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
local index = getters and
function(self, key)
-- read from getter, else from fallback
local func = getters[key]
if func then return func(self) else return fallback[key] end
end
or fallback -- default to fast property reads through table
local newindex = setters and
function(self, key, value)
-- write to setter, else to proxy
local func = setters[key]
if func then func(self, value)
else rawset(self, key, value) end
end
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|Perl
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>

BEGIN {
my @attr = qw(author title number);
no strict 'refs';
for my $a (@attr){
*{__PACKAGE__ . "::get_$a"} = sub { $_[0]->{$a} };
*{__PACKAGE__ . "::set_$a"} = sub { $_[0]->{$a} = $_[1] };
}
}
</pre>
|Syntax is different for method calls and instance-variable reference
|}

== Conclusion ==

Having getters and setters in the implementation has its own advantages and disadvantages. The advantages are that
<ol>
<li>They provide data encapsulation.</li>
<li>They improve the code readability.</li>
<li>Changes can be made only to the implementation without making changes to the code that uses the object.</li>
</ol>
Using getters and setters also has a disadvantage. They largely provide access to implementation details. But this could hinder data abstraction, i.e. hiding the object's implementation of a message handler. Consider a getter function that returns a number. Wherever this method is called, the variable which holds the return value must match the return type of this function. Now if we change they way this method is implemented by changing the return type, then there could be trouble.

Therefore it is important to design such that there is minimal data movement thereby minimizing possible errors.
Using the same syntax for method calls and instance variable references have some advantages and disadvantages. One could argue that having the same syntax makes it simpler for the programmer. It makes the code lighter in terms of lines of code, thus avoiding bulky code. However, including distinct ways for using methods and variables enhances readability by enabling better understanding. This is possible because the manipulation is visible whereas if the syntax were the same(i.e. compact), the one reading has no idea about what is happening "under the hood".

== References ==
<ol>
<li>[http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(object-oriented_programming)/ Comparison of Programming Languages]</li>
<li>[http://forums.sdn.sap.com/thread.jspa?threadID=529448&tstart=6135/ Setters and Getters in ABAP]</li>
<li>[http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?page=1/ Why getters and setters are evil?]</li>
<li>[http://www.zeuscmd.com/tutorials/cplusplus/50-GettersAndSetters.php/ Getters and Setters]</li>
<li>[http://cocoadevcentral.com/d/learn_objectivec/ Objective C]</li>
<li>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_classes.html/ Ruby Classes- Objects]</li>
<li>[http://www.vbtutor.in/getting-started-with-visual-basic-net/object-oriented-programming-in-vbnet/ VB.Net Object oriented programming]</li>
<li>[https://developer.mozilla.org/en/Introduction_to_Object-Oriented_JavaScript/ Javascript - Functions/Objects]</li>
<li>[http://www.massassi.com/php/articles/classes/ PHP - Objects]</li>
<li>[http://www.tutorialspoint.com/perl/perl_oo_perl.htm/ Perl - Objects]</li>
</ol>

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-25T22:58:19Z

Pramasw3: /* References */

Common Attribute/Member Syntax 

Different object oriented programming languages include different ways of accessing the member variables and methods. This page discusses the various usages and their advantages and disadvantages.

== Introduction ==
The purpose of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] is to make programs model things the way people think or deal with the world i.e it's modeled around data rather than logic. Objects form the basis of OOP. Let us now look at objects, their manipulation and the ways to do so.

== Objects - Attributes and Methods ==
<table>
<tr>
<td>
Similar to real world objects, software objects also consist of state and related behavior. An object stores it's state in attributes and exposes its behavior through methods. Let's look at the pseudo code for a bicycle object.
<pre>
CLASS Bicycle
ATTRIBUTES:
speed: NUMBER
gear: NUMBER
pedal_cadence: NUMBER
METHODS:
ride(speed)
changeGear(gear)
changeCadence(pedal_cadence)
</pre>
</td>
<td>[[File:concepts-object.gif]]</td>
</tr>
</table>
In the above pseudo code, the attributes define the object and the methods provide a way of achieving the desired functionality from that object. The methods use the attributes to manipulate the object and achieve the functionality. From this we can observe that this manipulation is the very essence of programming using objects. Therefore the access of attributes and way of defining method calls very important in OOP.

== Method call / Instance Variable reference Syntax ==
A running debate in O-O languages is whether method calls and instance-variable references should have the same syntax. Different programming languages implement this in different ways. Let's look at them by examples.

=== Same Syntax ===
Languages like Ruby use the same syntax for method calls and variable references. There is no distinction between these. We can see this in the example below:
<pre>
class Song
def duration=(newDuration)
@duration = newDuration
end
end
aSong = Song.new("Bicylops", "Fleck", 260)
aSong.duration » 260
aSong.duration = 257 # set attribute with updated value
aSong.duration » 257
</pre>

This makes it simpler for the programmer to code. Also, it presents uniformity in the code.

=== Differing Syntax ===
Languages like Java employ different syntax for method calls and variable references as seen in this example below:
<pre>
class Song{
int duration;
Song(){}
void setDuration(int dur){
duration = dur;
}
}

Song sng = new Song();
sng.setDuration(260);
System.out.println("Song duration = "+sng.duration);
</pre>

As seen above, a method is always called using parenthesis, within which arguments may be included if required. However, instance variable is accessed directly.

== Getters and Setters and their Advantages ==
One of the principles of Objected Oriented Design is that an object's implementation should not be exposed to other classes. This is to avoid difficulty in maintenance. Getters and setters provide a way to read or write private data of a class for any kind of manipulation. They also provide for easy maintenance, in that, if any change needs to be made in the way the variable is set, only the setter method needs to be changed rather than looking for it and changing in every place. These methods also improve the code readability and bring about uniformity across the code.

== Comparison of syntax between various Programming Languages ==
The usage syntax of methods, instance variables, getters and setters is in the table below

{|class="wikitable"
|-
!Programming Languages
!Method call
!Fields/Attributes
!Getter / Setter
!Comparison
|-
|ABAP (Advanced Business Application Programming)
|<pre>
CALL METHOD <meth> EXPORTING... <ii> =.<f i>...
IMPORTING... <ei> =.<g i>...
CHANGING ... <ci> =.<f i>...
RECEIVING r = h
EXCEPTIONS... <ei> = rc i...
</pre>
|data field type type
|Same as other methods with the only difference that they start with SET or GET
|Syntax is different for method calls and instance-variable reference
|-
|C++
|ObjectName.MethodName(parameters)
|Same as methods. Example below:
<pre>
int getHealth() const { return health; }
void setHealth(int h) { health = h; }
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|C#
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|They are just like methods. Example below:
<pre>
public string GetName()
{
return m_name;
}

public void SetName(string name)
{
m_name = name;
}
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|Java
|ObjectName.MethodName(parameters) [Eg: x.method()]
|ObjectName.Attribute [Eg: x.field]
|They are nothing but method calls
|Different syntax is used to call methods and instance-variable references
|-
|D
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|No need for getters and setters. It can be directly accessed.
<pre>
import std.stdio;

class Car
{
float speed = 1.0;
}

void main(){
auto my_car = new Car();
my_car.speed = 2.5;
writefln(my_car.speed);
}
</pre>
|Syntax used for method calls and variable references is different
|-
|Objective C
|output = [object methodWithOutput]
|ObjectName->Attribute
|An example of getter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}

- (NSString*) caption;
- (NSString*) photographer;

@end
</pre>
An example of setter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}
- (NSString*) caption;
- (NSString*) photographer;

- (void) setCaption: (NSString*)input;
- (void) setPhotographer: (NSString*)input;

@end
</pre>
|Syntax used for method calls and variable references is different
|-
|Python
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|Pythonic way of implementing getters and setters is to using public members and turning them into properties when needed
|Syntax used for method calls and variable references is sometimes the same and different at times (when there are arguments)
|-
|Javascript
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
var lost = {
loc : "Island",
get location () {
return this.loc;
},
set location(val) {
this.loc = val;
}
};
lost.location = "Another island";
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|PHP
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference
|-
|VB.NET
|ObjectName.MethodName(Parameters);
ObjectNmae.MethodName
|ObjectName.Attribute
|<pre>
Public Property myProperty As String
Get
Return String.Empty
End Get
Private Set(ByVal value As String)
somethingElse = value
End Set
End Property
</pre>
|Syntax may be same for method calls and instance-variable reference
|-
|Ruby
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>
class Message
attr_reader :message
def message=(m)
@message = m.dup
end
end

class Message
attr_writer :message
def message
@message.encode!("UTF-8")
end
end
</pre>
|Syntax is same for method calls and instance-variable reference
|-
|Lua
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
local index = getters and
function(self, key)
-- read from getter, else from fallback
local func = getters[key]
if func then return func(self) else return fallback[key] end
end
or fallback -- default to fast property reads through table
local newindex = setters and
function(self, key, value)
-- write to setter, else to proxy
local func = setters[key]
if func then func(self, value)
else rawset(self, key, value) end
end
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|Perl
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>

BEGIN {
my @attr = qw(author title number);
no strict 'refs';
for my $a (@attr){
*{__PACKAGE__ . "::get_$a"} = sub { $_[0]->{$a} };
*{__PACKAGE__ . "::set_$a"} = sub { $_[0]->{$a} = $_[1] };
}
}
</pre>
|Syntax is different for method calls and instance-variable reference
|}

== Conclusion ==

Having getters and setters in the implementation has its own advantages and disadvantages. The advantages are that
<ol>
<li>They provide data encapsulation.</li>
<li>They improve the code readability.</li>
<li>Changes can be made only to the implementation without making changes to the code that uses the object.</li>
</ol>
Using getters and setters also has a disadvantage. They largely provide access to implementation details. But this could hinder data abstraction, i.e. hiding the object's implementation of a message handler. Consider a getter function that returns a number. Wherever this method is called, the variable which holds the return value must match the return type of this function. Now if we change they way this method is implemented by changing the return type, then there could be trouble.

Therefore it is important to design such that there is minimal data movement thereby minimizing possible errors.
Using the same syntax for method calls and instance variable references have some advantages and disadvantages. One could argue that having the same syntax makes it simpler for the programmer. It makes the code lighter in terms of lines of code, thus avoiding bulky code. However, including distinct ways for using methods and variables enhances readability by enabling better understanding. This is possible because the manipulation is visible whereas if the syntax were the same(i.e. compact), the one reading has no idea about what is happening "under the hood".

== References ==
<ol>
<li>[http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(object-oriented_programming)/ Comparison of Programming Languages]</li>
<li>[http://forums.sdn.sap.com/thread.jspa?threadID=529448&tstart=6135/ Setters and Getters in ABAP]</li>
<li>[http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?page=1/ Why getters and setters are evil?]</li>
<li>[http://www.zeuscmd.com/tutorials/cplusplus/50-GettersAndSetters.php/ Getters and Setters]</li>
<li>[http://cocoadevcentral.com/d/learn_objectivec/ Objective C]</li>
<li>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_classes.html/ Ruby Classes- Objects]</li>
<li>[http://www.vbtutor.in/getting-started-with-visual-basic-net/object-oriented-programming-in-vbnet/ VB.Net Object oriented programming]</li>
<li>[https://developer.mozilla.org/en/Introduction_to_Object-Oriented_JavaScript/ Javascript - Functions/Objects]</li>
<li>[http://www.massassi.com/php/articles/classes/ PHP - Objects]</li>
<li>[http://www.tutorialspoint.com/perl/perl_oo_perl.htm/ Perl - Objects]</li>
</ol>

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-25T22:57:59Z

Pramasw3: /* References */

Common Attribute/Member Syntax 

Different object oriented programming languages include different ways of accessing the member variables and methods. This page discusses the various usages and their advantages and disadvantages.

== Introduction ==
The purpose of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] is to make programs model things the way people think or deal with the world i.e it's modeled around data rather than logic. Objects form the basis of OOP. Let us now look at objects, their manipulation and the ways to do so.

== Objects - Attributes and Methods ==
<table>
<tr>
<td>
Similar to real world objects, software objects also consist of state and related behavior. An object stores it's state in attributes and exposes its behavior through methods. Let's look at the pseudo code for a bicycle object.
<pre>
CLASS Bicycle
ATTRIBUTES:
speed: NUMBER
gear: NUMBER
pedal_cadence: NUMBER
METHODS:
ride(speed)
changeGear(gear)
changeCadence(pedal_cadence)
</pre>
</td>
<td>[[File:concepts-object.gif]]</td>
</tr>
</table>
In the above pseudo code, the attributes define the object and the methods provide a way of achieving the desired functionality from that object. The methods use the attributes to manipulate the object and achieve the functionality. From this we can observe that this manipulation is the very essence of programming using objects. Therefore the access of attributes and way of defining method calls very important in OOP.

== Method call / Instance Variable reference Syntax ==
A running debate in O-O languages is whether method calls and instance-variable references should have the same syntax. Different programming languages implement this in different ways. Let's look at them by examples.

=== Same Syntax ===
Languages like Ruby use the same syntax for method calls and variable references. There is no distinction between these. We can see this in the example below:
<pre>
class Song
def duration=(newDuration)
@duration = newDuration
end
end
aSong = Song.new("Bicylops", "Fleck", 260)
aSong.duration » 260
aSong.duration = 257 # set attribute with updated value
aSong.duration » 257
</pre>

This makes it simpler for the programmer to code. Also, it presents uniformity in the code.

=== Differing Syntax ===
Languages like Java employ different syntax for method calls and variable references as seen in this example below:
<pre>
class Song{
int duration;
Song(){}
void setDuration(int dur){
duration = dur;
}
}

Song sng = new Song();
sng.setDuration(260);
System.out.println("Song duration = "+sng.duration);
</pre>

As seen above, a method is always called using parenthesis, within which arguments may be included if required. However, instance variable is accessed directly.

== Getters and Setters and their Advantages ==
One of the principles of Objected Oriented Design is that an object's implementation should not be exposed to other classes. This is to avoid difficulty in maintenance. Getters and setters provide a way to read or write private data of a class for any kind of manipulation. They also provide for easy maintenance, in that, if any change needs to be made in the way the variable is set, only the setter method needs to be changed rather than looking for it and changing in every place. These methods also improve the code readability and bring about uniformity across the code.

== Comparison of syntax between various Programming Languages ==
The usage syntax of methods, instance variables, getters and setters is in the table below

{|class="wikitable"
|-
!Programming Languages
!Method call
!Fields/Attributes
!Getter / Setter
!Comparison
|-
|ABAP (Advanced Business Application Programming)
|<pre>
CALL METHOD <meth> EXPORTING... <ii> =.<f i>...
IMPORTING... <ei> =.<g i>...
CHANGING ... <ci> =.<f i>...
RECEIVING r = h
EXCEPTIONS... <ei> = rc i...
</pre>
|data field type type
|Same as other methods with the only difference that they start with SET or GET
|Syntax is different for method calls and instance-variable reference
|-
|C++
|ObjectName.MethodName(parameters)
|Same as methods. Example below:
<pre>
int getHealth() const { return health; }
void setHealth(int h) { health = h; }
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|C#
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|They are just like methods. Example below:
<pre>
public string GetName()
{
return m_name;
}

public void SetName(string name)
{
m_name = name;
}
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|Java
|ObjectName.MethodName(parameters) [Eg: x.method()]
|ObjectName.Attribute [Eg: x.field]
|They are nothing but method calls
|Different syntax is used to call methods and instance-variable references
|-
|D
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|No need for getters and setters. It can be directly accessed.
<pre>
import std.stdio;

class Car
{
float speed = 1.0;
}

void main(){
auto my_car = new Car();
my_car.speed = 2.5;
writefln(my_car.speed);
}
</pre>
|Syntax used for method calls and variable references is different
|-
|Objective C
|output = [object methodWithOutput]
|ObjectName->Attribute
|An example of getter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}

- (NSString*) caption;
- (NSString*) photographer;

@end
</pre>
An example of setter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}
- (NSString*) caption;
- (NSString*) photographer;

- (void) setCaption: (NSString*)input;
- (void) setPhotographer: (NSString*)input;

@end
</pre>
|Syntax used for method calls and variable references is different
|-
|Python
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|Pythonic way of implementing getters and setters is to using public members and turning them into properties when needed
|Syntax used for method calls and variable references is sometimes the same and different at times (when there are arguments)
|-
|Javascript
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
var lost = {
loc : "Island",
get location () {
return this.loc;
},
set location(val) {
this.loc = val;
}
};
lost.location = "Another island";
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|PHP
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference
|-
|VB.NET
|ObjectName.MethodName(Parameters);
ObjectNmae.MethodName
|ObjectName.Attribute
|<pre>
Public Property myProperty As String
Get
Return String.Empty
End Get
Private Set(ByVal value As String)
somethingElse = value
End Set
End Property
</pre>
|Syntax may be same for method calls and instance-variable reference
|-
|Ruby
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>
class Message
attr_reader :message
def message=(m)
@message = m.dup
end
end

class Message
attr_writer :message
def message
@message.encode!("UTF-8")
end
end
</pre>
|Syntax is same for method calls and instance-variable reference
|-
|Lua
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
local index = getters and
function(self, key)
-- read from getter, else from fallback
local func = getters[key]
if func then return func(self) else return fallback[key] end
end
or fallback -- default to fast property reads through table
local newindex = setters and
function(self, key, value)
-- write to setter, else to proxy
local func = setters[key]
if func then func(self, value)
else rawset(self, key, value) end
end
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|Perl
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>

BEGIN {
my @attr = qw(author title number);
no strict 'refs';
for my $a (@attr){
*{__PACKAGE__ . "::get_$a"} = sub { $_[0]->{$a} };
*{__PACKAGE__ . "::set_$a"} = sub { $_[0]->{$a} = $_[1] };
}
}
</pre>
|Syntax is different for method calls and instance-variable reference
|}

== Conclusion ==

Having getters and setters in the implementation has its own advantages and disadvantages. The advantages are that
<ol>
<li>They provide data encapsulation.</li>
<li>They improve the code readability.</li>
<li>Changes can be made only to the implementation without making changes to the code that uses the object.</li>
</ol>
Using getters and setters also has a disadvantage. They largely provide access to implementation details. But this could hinder data abstraction, i.e. hiding the object's implementation of a message handler. Consider a getter function that returns a number. Wherever this method is called, the variable which holds the return value must match the return type of this function. Now if we change they way this method is implemented by changing the return type, then there could be trouble.

Therefore it is important to design such that there is minimal data movement thereby minimizing possible errors.
Using the same syntax for method calls and instance variable references have some advantages and disadvantages. One could argue that having the same syntax makes it simpler for the programmer. It makes the code lighter in terms of lines of code, thus avoiding bulky code. However, including distinct ways for using methods and variables enhances readability by enabling better understanding. This is possible because the manipulation is visible whereas if the syntax were the same(i.e. compact), the one reading has no idea about what is happening "under the hood".

== References ==
<ol>
<li>[http://help.sap.com/saphelp_nw04/helpdata/en/08/d27c03b81011d194f60000e8353423/content.htm/ Declaring and Calling Methods]</li>
<li>[http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(object-oriented_programming)/ Comparison of Programming Languages]</li>
<li>[http://forums.sdn.sap.com/thread.jspa?threadID=529448&tstart=6135/ Setters and Getters in ABAP]</li>
<li>[http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?page=1/ Why getters and setters are evil?]</li>
<li>[http://www.zeuscmd.com/tutorials/cplusplus/50-GettersAndSetters.php/ Getters and Setters]</li>
<li>[http://cocoadevcentral.com/d/learn_objectivec/ Objective C]</li>
<li>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_classes.html/ Ruby Classes- Objects]</li>
<li>[http://www.vbtutor.in/getting-started-with-visual-basic-net/object-oriented-programming-in-vbnet/ VB.Net Object oriented programming]</li>
<li>[https://developer.mozilla.org/en/Introduction_to_Object-Oriented_JavaScript/ Javascript - Functions/Objects]</li>
<li>[http://www.massassi.com/php/articles/classes/ PHP - Objects]</li>
<li>[http://www.tutorialspoint.com/perl/perl_oo_perl.htm/ Perl - Objects]</li>
</ol>

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T05:22:41Z

Pramasw3:

Common Attribute/Member Syntax 

Different object oriented programming languages include different ways of accessing the member variables and methods. This page discusses the various usages and their advantages and disadvantages.

== Introduction ==
The purpose of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] is to make programs model things the way people think or deal with the world i.e it's modeled around data rather than logic. Objects form the basis of OOP. Let us now look at objects, their manipulation and the ways to do so.

== Objects - Attributes and Methods ==
<table>
<tr>
<td>
Similar to real world objects, software objects also consist of state and related behavior. An object stores it's state in attributes and exposes its behavior through methods. Let's look at the pseudo code for a bicycle object.
<pre>
CLASS Bicycle
ATTRIBUTES:
speed: NUMBER
gear: NUMBER
pedal_cadence: NUMBER
METHODS:
ride(speed)
changeGear(gear)
changeCadence(pedal_cadence)
</pre>
</td>
<td>[[File:concepts-object.gif]]</td>
</tr>
</table>
In the above pseudo code, the attributes define the object and the methods provide a way of achieving the desired functionality from that object. The methods use the attributes to manipulate the object and achieve the functionality. From this we can observe that this manipulation is the very essence of programming using objects. Therefore the access of attributes and way of defining method calls very important in OOP.

== Method call / Instance Variable reference Syntax ==
A running debate in O-O languages is whether method calls and instance-variable references should have the same syntax. Different programming languages implement this in different ways. Let's look at them by examples.

=== Same Syntax ===
Languages like Ruby use the same syntax for method calls and variable references. There is no distinction between these. We can see this in the example below:
<pre>
class Song
def duration=(newDuration)
@duration = newDuration
end
end
aSong = Song.new("Bicylops", "Fleck", 260)
aSong.duration » 260
aSong.duration = 257 # set attribute with updated value
aSong.duration » 257
</pre>

This makes it simpler for the programmer to code. Also, it presents uniformity in the code.

=== Differing Syntax ===
Languages like Java employ different syntax for method calls and variable references as seen in this example below:
<pre>
class Song{
int duration;
Song(){}
void setDuration(int dur){
duration = dur;
}
}

Song sng = new Song();
sng.setDuration(260);
System.out.println("Song duration = "+sng.duration);
</pre>

As seen above, a method is always called using parenthesis, within which arguments may be included if required. However, instance variable is accessed directly.

== Comparison of syntax between various Programming Languages ==
The usage syntax of methods, instance variables, getters and setters is in the table below

{|class="wikitable"
|-
!Programming Languages
!Method call
!Fields/Attributes
!Getter / Setter
!Comparison
|-
|ABAP (Advanced Business Application Programming)
|<pre>
CALL METHOD <meth> EXPORTING... <ii> =.<f i>...
IMPORTING... <ei> =.<g i>...
CHANGING ... <ci> =.<f i>...
RECEIVING r = h
EXCEPTIONS... <ei> = rc i...
</pre>
|data field type type
|Same as other methods with the only difference that they start with SET or GET
|Syntax is different for method calls and instance-variable reference
|-
|C++
|<instance-variable>.method(parameters) [Eg: x.method()]
|type field
|Same as methods. Example below:
<pre>
int getHealth() const { return health; }
void setHealth(int h) { health = h; }
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|C#
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|They are just like methods. Example below:
<pre>
public string GetName()
{
return m_name;
}

public void SetName(string name)
{
m_name = name;
}
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|Java
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|They are nothing but method calls
|Different syntax is used to call methods and instance-variable references
|-
|D
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|No need for getters and setters. It can be directly accessed.
<pre>
import std.stdio;

class Car
{
float speed = 1.0;
}

void main(){
auto my_car = new Car();
my_car.speed = 2.5;
writefln(my_car.speed);
}
</pre>
|Syntax used for method calls and variable references is different
|-
|Objective C
|output = [object methodWithOutput]
|x->field
|An example of getter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}

- (NSString*) caption;
- (NSString*) photographer;

@end
</pre>
An example of setter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}
- (NSString*) caption;
- (NSString*) photographer;

- (void) setCaption: (NSString*)input;
- (void) setPhotographer: (NSString*)input;

@end
</pre>
|Syntax used for method calls and variable references is different
|-
|Python
|x.method(parameters)
|x.field
|Pythonic way of implementing getters and setters is to using public members and turning them into properties when needed
|Syntax used for method calls and variable references is sometimes the same and different at times (when there are arguments)
|-
|Javascript
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
var lost = {
loc : "Island",
get location () {
return this.loc;
},
set location(val) {
this.loc = val;
}
};
lost.location = "Another island";
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|PHP
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference
|-
|VB.NET
|ObjectName.MethodName(Parameters);
ObjectNmae.MethodName
|ObjectName.Attribute
|<pre>
Public Property myProperty As String
Get
Return String.Empty
End Get
Private Set(ByVal value As String)
somethingElse = value
End Set
End Property
</pre>
|Syntax may be same for method calls and instance-variable reference
|-
|Ruby
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>
class Message
attr_reader :message
def message=(m)
@message = m.dup
end
end

class Message
attr_writer :message
def message
@message.encode!("UTF-8")
end
end
</pre>
|Syntax is same for method calls and instance-variable reference
|-
|Lua
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
local index = getters and
function(self, key)
-- read from getter, else from fallback
local func = getters[key]
if func then return func(self) else return fallback[key] end
end
or fallback -- default to fast property reads through table
local newindex = setters and
function(self, key, value)
-- write to setter, else to proxy
local func = setters[key]
if func then func(self, value)
else rawset(self, key, value) end
end
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|Perl
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>

BEGIN {
my @attr = qw(author title number);
no strict 'refs';
for my $a (@attr){
*{__PACKAGE__ . "::get_$a"} = sub { $_[0]->{$a} };
*{__PACKAGE__ . "::set_$a"} = sub { $_[0]->{$a} = $_[1] };
}
}
</pre>
|Syntax is different for method calls and instance-variable reference
|}

== Conclusion ==
Using the same syntax for method calls and instance variable references have some advantages and disadvantages. One could argue that having the same syntax makes it simpler for the programmer. It makes the code lighter in terms of lines of code, thus avoiding bulky code. However, including distinct ways for using methods and variables enhances readability by enabling better understanding. This is possible because the manipulation is visible whereas if the syntax were the same(i.e. compact), the one reading has no idea about what is happening "under the hood".

== References ==
<ol>
<li>[http://help.sap.com/saphelp_nw04/helpdata/en/08/d27c03b81011d194f60000e8353423/content.htm/ Declaring and Calling Methods]</li>
<li>[http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(object-oriented_programming)/ Comparison of Programming Languages]</li>
<li>[http://forums.sdn.sap.com/thread.jspa?threadID=529448&tstart=6135/ Setters and Getters in ABAP]</li>
<li>[http://www.zeuscmd.com/tutorials/cplusplus/50-GettersAndSetters.php/ Getters and Setters]</li>
<li>[http://cocoadevcentral.com/d/learn_objectivec/ Objective C]</li>
<li>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_classes.html/ Ruby Classes- Objects]</li>
<li>[http://www.vbtutor.in/getting-started-with-visual-basic-net/object-oriented-programming-in-vbnet/ VB.Net Object oriented programming]</li>
<li>[https://developer.mozilla.org/en/Introduction_to_Object-Oriented_JavaScript/ Javascript - Functions/Objects]</li>
<li>[http://www.massassi.com/php/articles/classes/ PHP - Objects]</li>
<li>[http://www.tutorialspoint.com/perl/perl_oo_perl.htm/ Perl - Objects]</li>
<li>[http://lua-users.org/wiki/SimpleLuaClasses/ Lua - Object oriented scripting]</li>
</ol>

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T05:21:00Z

Pramasw3:

Common Attribute/Member Syntax 

Different object oriented programming languages include different ways of accessing the member variables and methods. This page discusses the various usages and their advantages and disadvantages.

== Introduction ==
The purpose of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] is to make programs model things the way people think or deal with the world i.e it's modeled around data rather than logic. Objects form the basis of OOP. Let us now look at objects, their manipulation and the ways to do so.

== Objects - Attributes and Methods ==
<table>
<tr>
<td>
Similar to real world objects, software objects also consist of state and related behavior. An object stores it's state in attributes and exposes its behavior through methods. Let's look at the pseudo code for a bicycle object.
<pre>
CLASS Bicycle
ATTRIBUTES:
speed: NUMBER
gear: NUMBER
pedal_cadence: NUMBER
METHODS:
ride(speed)
changeGear(gear)
changeCadence(pedal_cadence)
</pre>
</td>
<td>[[File:concepts-object.gif]]</td>
</tr>
</table>
In the above pseudo code, the attributes define the object and the methods provide a way of achieving the desired functionality from that object. The methods use the attributes to manipulate the object and achieve the functionality. From this we can observe that this manipulation is the very essence of programming using objects. Therefore the access of attributes and way of defining method calls very important in OOP.

== Method call / Instance Variable reference Syntax ==
A running debate in O-O languages is whether method calls and instance-variable references should have the same syntax. Different programming languages implement this in different ways. Let's look at them by examples.

=== Same Syntax ===
Languages like Ruby use the same syntax for method calls and variable references. There is no distinction between these. We can see this in the example below:
<pre>
class Song
def duration=(newDuration)
@duration = newDuration
end
end
aSong = Song.new("Bicylops", "Fleck", 260)
aSong.duration » 260
aSong.duration = 257 # set attribute with updated value
aSong.duration » 257
</pre>

This makes it simpler for the programmer to code. Also, it presents uniformity in the code.

=== Differing Syntax ===
Languages like Java employ different syntax for method calls and variable references as seen in this example below:
<pre>
class Song{
int duration;
Song(){}
void setDuration(int dur){
duration = dur;
}
}

Song sng = new Song();
sng.setDuration(260);
System.out.println("Song duration = "+sng.duration);
</pre>

As seen above, a method is always called using parenthesis, within which arguments may be included if required. However, instance variable is accessed directly.

== Comparison of syntax between various Programming Languages ==
The usage syntax of methods, instance variables, getters and setters is in the table below

{|class="wikitable"
|-
!Programming Languages
!Method call
!Fields/Attributes
!Getter / Setter
!Comparison
|-
|ABAP (Advanced Business Application Programming)
|<pre>
CALL METHOD <meth> EXPORTING... <ii> =.<f i>...
IMPORTING... <ei> =.<g i>...
CHANGING ... <ci> =.<f i>...
RECEIVING r = h
EXCEPTIONS... <ei> = rc i...
</pre>
|data field type type
|Same as other methods with the only difference that they start with SET or GET
|Syntax is different for method calls and instance-variable reference
|-
|C++
|<instance-variable>.method(parameters) [Eg: x.method()]
|type field
|Same as methods. Example below:
<pre>
int getHealth() const { return health; }
void setHealth(int h) { health = h; }
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|C#
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|They are just like methods. Example below:
<pre>
public string GetName()
{
return m_name;
}

public void SetName(string name)
{
m_name = name;
}
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|Java
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|They are nothing but method calls
|Different syntax is used to call methods and instance-variable references
|-
|D
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|No need for getters and setters. It can be directly accessed.
<pre>
import std.stdio;

class Car
{
float speed = 1.0;
}

void main(){
auto my_car = new Car();
my_car.speed = 2.5;
writefln(my_car.speed);
}
</pre>
|Syntax used for method calls and variable references is different
|-
|Objective C
|output = [object methodWithOutput]
|x->field
|An example of getter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}

- (NSString*) caption;
- (NSString*) photographer;

@end
</pre>
An example of setter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}
- (NSString*) caption;
- (NSString*) photographer;

- (void) setCaption: (NSString*)input;
- (void) setPhotographer: (NSString*)input;

@end
</pre>
|Syntax used for method calls and variable references is different
|-
|Python
|x.method(parameters)
|x.field
|Pythonic way of implementing getters and setters is to using public members and turning them into properties when needed
|Syntax used for method calls and variable references is sometimes the same and different at times (when there are arguments)
|-
|Javascript
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
var lost = {
loc : "Island",
get location () {
return this.loc;
},
set location(val) {
this.loc = val;
}
};
lost.location = "Another island";
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|PHP
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference
|-
|VB.NET
|ObjectName.MethodName(Parameters);
ObjectNmae.MethodName
|ObjectName.Attribute
|<pre>
Public Property myProperty As String
Get
Return String.Empty
End Get
Private Set(ByVal value As String)
somethingElse = value
End Set
End Property
</pre>
|Syntax may be same for method calls and instance-variable reference
|-
|Ruby
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>
class Message
attr_reader :message
def message=(m)
@message = m.dup
end
end

class Message
attr_writer :message
def message
@message.encode!("UTF-8")
end
end
</pre>
|Syntax is same for method calls and instance-variable reference
|-
|Lua
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
local index = getters and
function(self, key)
-- read from getter, else from fallback
local func = getters[key]
if func then return func(self) else return fallback[key] end
end
or fallback -- default to fast property reads through table
local newindex = setters and
function(self, key, value)
-- write to setter, else to proxy
local func = setters[key]
if func then func(self, value)
else rawset(self, key, value) end
end
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|Perl
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>

BEGIN {
my @attr = qw(author title number);
no strict 'refs';
for my $a (@attr){
*{__PACKAGE__ . "::get_$a"} = sub { $_[0]->{$a} };
*{__PACKAGE__ . "::set_$a"} = sub { $_[0]->{$a} = $_[1] };
}
}
</pre>
|Syntax is different for method calls and instance-variable reference
|}

== Conclusion ==
Using the same syntax for method calls and instance variable references have some advantages and disadvantages. One could argue that having the same syntax makes it simpler for the programmer. It makes the code lighter in terms of lines of code, thus avoiding bulky code. However, including distinct ways for using methods and variables enhances readability by enabling better understanding. This is possible because the manipulation is visible whereas if the syntax were the same(i.e. compact), the one reading has no idea about what is happening "under the hood".

== References ==
<ol>
<li>[http://help.sap.com/saphelp_nw04/helpdata/en/08/d27c03b81011d194f60000e8353423/content.htm/ Declaring and Calling Methods]</li>
<li>[http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(object-oriented_programming)/ Comparison of Programming Languages]</li>
<li>[http://forums.sdn.sap.com/thread.jspa?threadID=529448&tstart=6135/ Setters and Getters in ABAP]</li>
<li>[http://www.zeuscmd.com/tutorials/cplusplus/50-GettersAndSetters.php/ Getters and Setters]</li>
<li>[http://cocoadevcentral.com/d/learn_objectivec/ Objective C]</li>
<li>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_classes.html]</li>
<li>[http://www.vbtutor.in/getting-started-with-visual-basic-net/object-oriented-programming-in-vbnet]</li>
<li>[https://developer.mozilla.org/en/Introduction_to_Object-Oriented_JavaScript]</li>
<li>[http://www.massassi.com/php/articles/classes/]</li>
<li>[http://www.tutorialspoint.com/perl/perl_oo_perl.htm]</li>
<li>[http://lua-users.org/wiki/SimpleLuaClasses]</li>
</ol>

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T05:18:28Z

Pramasw3:

Common Attribute/Member Syntax 

Different object oriented programming languages include different ways of accessing the member variables and methods. This page discusses the various usages and their advantages and disadvantages.

== Introduction ==
The purpose of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] is to make programs model things the way people think or deal with the world i.e it's modeled around data rather than logic. Objects form the basis of OOP. Let us now look at objects, their manipulation and the ways to do so.

== Objects - Attributes and Methods ==
<table>
<tr>
<td>
Similar to real world objects, software objects also consist of state and related behavior. An object stores it's state in attributes and exposes its behavior through methods. Let's look at the pseudo code for a bicycle object.
<pre>
CLASS Bicycle
ATTRIBUTES:
speed: NUMBER
gear: NUMBER
pedal_cadence: NUMBER
METHODS:
ride(speed)
changeGear(gear)
changeCadence(pedal_cadence)
</pre>
</td>
<td>[[File:concepts-object.gif]]</td>
</tr>
</table>
In the above pseudo code, the attributes define the object and the methods provide a way of achieving the desired functionality from that object. The methods use the attributes to manipulate the object and achieve the functionality. From this we can observe that this manipulation is the very essence of programming using objects. Therefore the access of attributes and way of defining method calls very important in OOP.

== Method call / Instance Variable reference Syntax ==
A running debate in O-O languages is whether method calls and instance-variable references should have the same syntax. Different programming languages implement this in different ways. Let's look at them by examples.

=== Same Syntax ===
Languages like Ruby use the same syntax for method calls and variable references. There is no distinction between these. We can see this in the example below:
<pre>
class Song
def duration=(newDuration)
@duration = newDuration
end
end
aSong = Song.new("Bicylops", "Fleck", 260)
aSong.duration » 260
aSong.duration = 257 # set attribute with updated value
aSong.duration » 257
</pre>

This makes it simpler for the programmer to code. Also, it presents uniformity in the code.

=== Differing Syntax ===
Languages like Java employ different syntax for method calls and variable references as seen in this example below:
<pre>
class Song{
int duration;
Song(){}
void setDuration(int dur){
duration = dur;
}
}

Song sng = new Song();
sng.setDuration(260);
System.out.println("Song duration = "+sng.duration);
</pre>

As seen above, a method is always called using parenthesis, within which arguments may be included if required. However, instance variable is accessed directly.

== Comparison of syntax between various Programming Languages ==
The usage syntax of methods, instance variables, getters and setters is in the table below

{|class="wikitable"
|-
!Programming Languages
!Method call
!Fields/Attributes
!Getter / Setter
!Comparison
|-
|ABAP (Advanced Business Application Programming)
|<pre>
CALL METHOD <meth> EXPORTING... <ii> =.<f i>...
IMPORTING... <ei> =.<g i>...
CHANGING ... <ci> =.<f i>...
RECEIVING r = h
EXCEPTIONS... <ei> = rc i...
</pre>
|data field type type
|Same as other methods with the only difference that they start with SET or GET
|Syntax is different for method calls and instance-variable reference
|-
|C++
|<instance-variable>.method(parameters) [Eg: x.method()]
|type field
|Same as methods. Example below:
<pre>
int getHealth() const { return health; }
void setHealth(int h) { health = h; }
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|C#
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|They are just like methods. Example below:
<pre>
public string GetName()
{
return m_name;
}

public void SetName(string name)
{
m_name = name;
}
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|Java
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|They are nothing but method calls
|Different syntax is used to call methods and instance-variable references
|-
|D
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|No need for getters and setters. It can be directly accessed.
<pre>
import std.stdio;

class Car
{
float speed = 1.0;
}

void main(){
auto my_car = new Car();
my_car.speed = 2.5;
writefln(my_car.speed);
}
</pre>
|Syntax used for method calls and variable references is different
|-
|Objective C
|output = [object methodWithOutput]
|x->field
|An example of getter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}

- (NSString*) caption;
- (NSString*) photographer;

@end
</pre>
An example of setter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}
- (NSString*) caption;
- (NSString*) photographer;

- (void) setCaption: (NSString*)input;
- (void) setPhotographer: (NSString*)input;

@end
</pre>
|Syntax used for method calls and variable references is different
|-
|Python
|x.method(parameters)
|x.field
|Pythonic way of implementing getters and setters is to using public members and turning them into properties when needed
|Syntax used for method calls and variable references is sometimes the same and different at times (when there are arguments)
|-
|Javascript
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
var lost = {
loc : "Island",
get location () {
return this.loc;
},
set location(val) {
this.loc = val;
}
};
lost.location = "Another island";
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|PHP
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference
|-
|VB.NET
|ObjectName.MethodName(Parameters);
ObjectNmae.MethodName
|ObjectName.Attribute
|<pre>
Public Property myProperty As String
Get
Return String.Empty
End Get
Private Set(ByVal value As String)
somethingElse = value
End Set
End Property
</pre>
|Syntax may be same for method calls and instance-variable reference
|-
|Ruby
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>
class Message
attr_reader :message
def message=(m)
@message = m.dup
end
end

class Message
attr_writer :message
def message
@message.encode!("UTF-8")
end
end
</pre>
|Syntax is same for method calls and instance-variable reference
|-
|Lua
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
local index = getters and
function(self, key)
-- read from getter, else from fallback
local func = getters[key]
if func then return func(self) else return fallback[key] end
end
or fallback -- default to fast property reads through table
local newindex = setters and
function(self, key, value)
-- write to setter, else to proxy
local func = setters[key]
if func then func(self, value)
else rawset(self, key, value) end
end
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|Perl
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>

BEGIN {
my @attr = qw(author title number);
no strict 'refs';
for my $a (@attr){
*{__PACKAGE__ . "::get_$a"} = sub { $_[0]->{$a} };
*{__PACKAGE__ . "::set_$a"} = sub { $_[0]->{$a} = $_[1] };
}
}
</pre>
|Syntax is different for method calls and instance-variable reference
|}

== Conclusion ==
Using the same syntax for method calls and instance variable references have some advantages and disadvantages. One could argue that having the same syntax makes it simpler for the programmer. It makes the code lighter in terms of lines of code, thus avoiding bulky code. However, including distinct ways for using methods and variables enhances readability by enabling better understanding. This is possible because the manipulation is visible whereas if the syntax were the same(i.e. compact), the one reading has no idea about what is happening "under the hood".

== References ==
<ol>
<li>[http://help.sap.com/saphelp_nw04/helpdata/en/08/d27c03b81011d194f60000e8353423/content.htm/ Declaring and Calling Methods]</li>
<li>[http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(object-oriented_programming)/ Comparison of Programming Languages]</li>
<li>[http://forums.sdn.sap.com/thread.jspa?threadID=529448&tstart=6135/ Setters and Getters in ABAP]</li>
<li>[http://www.zeuscmd.com/tutorials/cplusplus/50-GettersAndSetters.php/ Getters and Setters]</li>
<li>[http://cocoadevcentral.com/d/learn_objectivec/ Objective C]</li>
</ol>

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T05:18:11Z

Pramasw3:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T05:17:56Z

Pramasw3:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T05:17:28Z

Pramasw3:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T05:16:59Z

Pramasw3:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T05:15:07Z

Pramasw3:

Common Attribute/Member Syntax 

Different object oriented programming languages include different ways of accessing the member variables and methods. This page discusses the various usages and their advantages and disadvantages.

== Introduction ==
The purpose of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] is to make programs model things the way people think or deal with the world i.e it's modeled around data rather than logic. Objects form the basis of OOP. Let us now look at objects, their manipulation and the ways to do so.

== Objects - Attributes and Methods ==
<table>
<tr>
<td>
Similar to real world objects, software objects also consist of state and related behavior. An object stores it's state in attributes and exposes its behavior through methods. Let's look at the pseudo code for a bicycle object.
<pre>
CLASS Bicycle
ATTRIBUTES:
speed: NUMBER
gear: NUMBER
pedal_cadence: NUMBER
METHODS:
ride(speed)
changeGear(gear)
changeCadence(pedal_cadence)
</pre>
</td>
<td>[[File:concepts-object.gif]]</td>
</tr>
</table>
In the above pseudo code, the attributes define the object and the methods provide a way of achieving the desired functionality from that object. The methods use the attributes to manipulate the object and achieve the functionality. From this we can observe that this manipulation is the very essence of programming using objects. Therefore the access of attributes and way of defining method calls very important in OOP.

== Method call / Instance Variable reference Syntax ==
A running debate in O-O languages is whether method calls and instance-variable references should have the same syntax. Different programming languages implement this in different ways. Let's look at them by examples.

=== Same Syntax ===
Languages like Ruby use the same syntax for method calls and variable references. There is no distinction between these. We can see this in the example below:
<pre>
class Song
def duration=(newDuration)
@duration = newDuration
end
end
aSong = Song.new("Bicylops", "Fleck", 260)
aSong.duration » 260
aSong.duration = 257 # set attribute with updated value
aSong.duration » 257
</pre>

This makes it simpler for the programmer to code. Also, it presents uniformity in the code.

=== Differing Syntax ===
Languages like Java employ different syntax for method calls and variable references as seen in this example below:
<pre>
class Song{
int duration;
Song(){}
void setDuration(int dur){
duration = dur;
}
}

Song sng = new Song();
sng.setDuration(260);
System.out.println("Song duration = "+sng.duration);
</pre>

As seen above, a method is always called using parenthesis, within which arguments may be included if required. However, instance variable is accessed directly.

== Comparison of syntax between various Programming Languages ==
The usage syntax of methods, instance variables, getters and setters is in the table below

{|class="wikitable"
|-
!Programming Languages
!Method call
!Fields/Attributes
!Getter / Setter
!Comparison
|-
|ABAP (Advanced Business Application Programming)
|<pre>
CALL METHOD <meth> EXPORTING... <ii> =.<f i>...
IMPORTING... <ei> =.<g i>...
CHANGING ... <ci> =.<f i>...
RECEIVING r = h
EXCEPTIONS... <ei> = rc i...
</pre>
|data field type type
|Same as other methods with the only difference that they start with SET or GET
|Syntax is different for method calls and instance-variable reference
|-
|C++
|<instance-variable>.method(parameters) [Eg: x.method()]
|type field
|Same as methods. Example below:
<pre>
int getHealth() const { return health; }
void setHealth(int h) { health = h; }
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|C#
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|They are just like methods. Example below:
<pre>
public string GetName()
{
return m_name;
}

public void SetName(string name)
{
m_name = name;
}
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|Java
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|They are nothing but method calls
|Different syntax is used to call methods and instance-variable references
|-
|D
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|No need for getters and setters. It can be directly accessed.
<pre>
import std.stdio;

class Car
{
float speed = 1.0;
}

void main(){
auto my_car = new Car();
my_car.speed = 2.5;
writefln(my_car.speed);
}
</pre>
|Syntax used for method calls and variable references is different
|-
|Objective C
|output = [object methodWithOutput]
|x->field
|An example of getter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}

- (NSString*) caption;
- (NSString*) photographer;

@end
</pre>
An example of setter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}
- (NSString*) caption;
- (NSString*) photographer;

- (void) setCaption: (NSString*)input;
- (void) setPhotographer: (NSString*)input;

@end
</pre>
|Syntax used for method calls and variable references is different
|-
|Python
|x.method(parameters)
|x.field
|Pythonic way of implementing getters and setters is to using public members and turning them into properties when needed
|Syntax used for method calls and variable references is sometimes the same and different at times (when there are arguments)
|-
|Javascript
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
var lost = {
loc : "Island",
get location () {
return this.loc;
},
set location(val) {
this.loc = val;
}
};
lost.location = "Another island";
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|PHP
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference
|-
|VB.NET
|ObjectName.MethodName(Parameters);
ObjectNmae.MethodName
|ObjectName.Attribute
|<pre>
Public Property myProperty As String
Get
Return String.Empty
End Get
Private Set(ByVal value As String)
somethingElse = value
End Set
End Property
</pre>
|Syntax may be same for method calls and instance-variable reference
|-
|Ruby
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>
class Message
attr_reader :message
def message=(m)
@message = m.dup
end
end

class Message
attr_writer :message
def message
@message.encode!("UTF-8")
end
end
</pre>
|Syntax is same for method calls and instance-variable reference
|-
|Lua
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
local index = getters and
function(self, key)
-- read from getter, else from fallback
local func = getters[key]
if func then return func(self) else return fallback[key] end
end
or fallback -- default to fast property reads through table
local newindex = setters and
function(self, key, value)
-- write to setter, else to proxy
local func = setters[key]
if func then func(self, value)
else rawset(self, key, value) end
end
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|Perl
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>

BEGIN {
my @attr = qw(author title number);
no strict 'refs';
for my $a (@attr){
*{__PACKAGE__ . "::get_$a"} = sub { $_[0]->{$a} };
*{__PACKAGE__ . "::set_$a"} = sub { $_[0]->{$a} = $_[1] };
}
}
</pre>
|Syntax is different for method calls and instance-variable reference
|}

== Conclusion ==
Using the same syntax for method calls and instance variable references have some advantages and disadvantages. One could argue that having the same syntax makes it simpler for the programmer. It makes the code lighter in terms of lines of code, thus avoiding bulky code. However, including distinct ways for using methods and variables enhances readability by enabling better understanding. This is possible because the manipulation is visible whereas if the syntax were the same(i.e. compact), the one reading has no idea about what is happening "under the hood".

== References ==
<ol>
<li>[http://help.sap.com/saphelp_nw04/helpdata/en/08/d27c03b81011d194f60000e8353423/content.htm/ Declaring and Calling Methods]</li>
<li>[http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(object-oriented_programming)/ Comparison of Programming Languages]</li>
<li>[http://forums.sdn.sap.com/thread.jspa?threadID=529448&tstart=6135/ Setters and Getters in ABAP]</li>
<li>[http://www.zeuscmd.com/tutorials/cplusplus/50-GettersAndSetters.php/ Getters and Setters]</li>
<li>[http://cocoadevcentral.com/d/learn_objectivec/ Objective C]</li>
</ol>

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T05:05:42Z

Pramasw3:

Common Attribute/Member Syntax 

Different object oriented programming languages include different ways of accessing the member variables and methods. This page discusses the various usages and their advantages and disadvantages.

== Introduction ==
The purpose of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] is to make programs model things the way people think or deal with the world i.e it's modeled around data rather than logic. Objects form the basis of OOP. Let us now look at objects, their manipulation and the ways to do so.

== Objects - Attributes and Methods ==
<table>
<tr>
<td>
Similar to real world objects, software objects also consist of state and related behavior. An object stores it's state in attributes and exposes its behavior through methods. Let's look at the pseudo code for a bicycle object.
<pre>
CLASS Bicycle
ATTRIBUTES:
speed: NUMBER
gear: NUMBER
pedal_cadence: NUMBER
METHODS:
ride(speed)
changeGear(gear)
changeCadence(pedal_cadence)
</pre>
</td>
<td>[[File:concepts-object.gif]]</td>
</tr>
</table>
In the above pseudo code, the attributes define the object and the methods provide a way of achieving the desired functionality from that object. The methods use the attributes to manipulate the object and achieve the functionality. From this we can observe that this manipulation is the very essence of programming using objects. Therefore the access of attributes and way of defining method calls very important in OOP.

== Method call / Instance Variable reference Syntax ==
A running debate in O-O languages is whether method calls and instance-variable references should have the same syntax. Different programming languages implement this in different ways. Let's look at them by examples.

=== Same Syntax ===
Languages like Ruby use the same syntax for method calls and variable references. There is no distinction between these. We can see this in the example below:
<pre>
class Song
def duration=(newDuration)
@duration = newDuration
end
end
aSong = Song.new("Bicylops", "Fleck", 260)
aSong.duration » 260
aSong.duration = 257 # set attribute with updated value
aSong.duration » 257
</pre>

This makes it simpler for the programmer to code. Also, it presents uniformity in the code.

=== Differing Syntax ===
Languages like Java employ different syntax for method calls and variable references as seen in this example below:
<pre>
class Song{
int duration;
Song(){}
void setDuration(int dur){
duration = dur;
}
}

Song sng = new Song();
sng.setDuration(260);
System.out.println("Song duration = "+sng.duration);
</pre>

As seen above, a method is always called using parenthesis, within which arguments may be included if required. However, instance variable is accessed directly.

== Comparison of syntax between various Programming Languages ==
The usage syntax of methods, instance variables, getters and setters is in the table below

{|class="wikitable"
|-
!Programming Languages
!Method call
!Fields/Attributes
!Getter / Setter
!Comparison
|-
|ABAP (Advanced Business Application Programming)
|<pre>
CALL METHOD <meth> EXPORTING... <ii> =.<f i>...
IMPORTING... <ei> =.<g i>...
CHANGING ... <ci> =.<f i>...
RECEIVING r = h
EXCEPTIONS... <ei> = rc i...
</pre>
|data field type type
|Same as other methods with the only difference that they start with SET or GET
|Syntax is different for method calls and instance-variable reference
|-
|C++
|<instance-variable>.method(parameters) [Eg: x.method()]
|type field
|Same as methods. Example below:
<pre>
int getHealth() const { return health; }
void setHealth(int h) { health = h; }
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|C#
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|They are just like methods. Example below:
<pre>
public string GetName()
{
return m_name;
}

public void SetName(string name)
{
m_name = name;
}
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|Java
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|They are nothing but method calls
|Different syntax is used to call methods and instance-variable references
|-
|D
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|No need for getters and setters. It can be directly accessed.
<pre>
import std.stdio;

class Car
{
float speed = 1.0;
}

void main(){
auto my_car = new Car();
my_car.speed = 2.5;
writefln(my_car.speed);
}
</pre>
|Syntax used for method calls and variable references is different
|-
|Objective C
|output = [object methodWithOutput]
|x->field
|An example of getter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}

- (NSString*) caption;
- (NSString*) photographer;

@end
</pre>
An example of setter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}
- (NSString*) caption;
- (NSString*) photographer;

- (void) setCaption: (NSString*)input;
- (void) setPhotographer: (NSString*)input;

@end
</pre>
|Syntax used for method calls and variable references is different
|-
|Python
|x.method(parameters)
|x.field
|Pythonic way of implementing getters and setters is to using public members and turning them into properties when needed
|Syntax used for method calls and variable references is sometimes the same and different at times (when there are arguments)

|-
|Javascript
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
var lost = {
loc : "Island",
get location () {
return this.loc;
},
set location(val) {
this.loc = val;
}
};
lost.location = "Another island";
</pre>
|Syntax is different for method calls and instance-variable reference

|-
|PHP
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference

|-
|VB.NET
|
ObjectName.MethodName(Parameters);
ObjectNmae.MethodName
|ObjectName.Attribute
|<pre>
Public Property myProperty As String
Get
Return String.Empty
End Get
Private Set(ByVal value As String)
somethingElse = value
End Set
End Property
</pre>
|Syntax may be same for method calls and instance-variable reference

|-
|Ruby
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>
class Message
attr_reader :message
def message=(m)
@message = m.dup
end
end

class Message
attr_writer :message
def message
@message.encode!("UTF-8")
end
end
</pre>
|Syntax is same for method calls and instance-variable reference

|-
|Lua
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>
local index = getters and
function(self, key)
-- read from getter, else from fallback
local func = getters[key]
if func then return func(self) else return fallback[key] end
end
or fallback -- default to fast property reads through table
local newindex = setters and
function(self, key, value)
-- write to setter, else to proxy
local func = setters[key]
if func then func(self, value)
else rawset(self, key, value) end
end
</pre>
|Syntax is different for method calls and instance-variable reference

|-
|Perl
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>

BEGIN {
my @attr = qw(author title number);
no strict 'refs';
for my $a (@attr){
*{__PACKAGE__ . "::get_$a"} = sub { $_[0]->{$a} };
*{__PACKAGE__ . "::set_$a"} = sub { $_[0]->{$a} = $_[1] };
}
}
</pre>
|Syntax is different for method calls and instance-variable reference

|}

== Conclusion ==
Using the same syntax for method calls and instance variable references have some advantages and disadvantages. One could argue that having the same syntax makes it simpler for the programmer. It makes the code lighter in terms of lines of code, thus avoiding bulky code. However, including distinct ways for using methods and variables enhances readability by enabling better understanding. This is possible because the manipulation is visible whereas if the syntax were the same(i.e. compact), the one reading has no idea about what is happening "under the hood".

== References ==
<ol>
<li>[http://help.sap.com/saphelp_nw04/helpdata/en/08/d27c03b81011d194f60000e8353423/content.htm/ Declaring and Calling Methods]</li>
<li>[http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(object-oriented_programming)/ Comparison of Programming Languages]</li>
<li>[http://forums.sdn.sap.com/thread.jspa?threadID=529448&tstart=6135/ Setters and Getters in ABAP]</li>
<li>[http://www.zeuscmd.com/tutorials/cplusplus/50-GettersAndSetters.php/ Getters and Setters]</li>
<li>[http://cocoadevcentral.com/d/learn_objectivec/ Objective C]</li>
</ol>

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T04:55:19Z

Pramasw3:

Common Attribute/Member Syntax 

Different object oriented programming languages include different ways of accessing the member variables and methods. This page discusses the various usages and their advantages and disadvantages.

== Introduction ==
The purpose of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] is to make programs model things the way people think or deal with the world i.e it's modeled around data rather than logic. Objects form the basis of OOP. Let us now look at objects, their manipulation and the ways to do so.

== Objects - Attributes and Methods ==
<table>
<tr>
<td>
Similar to real world objects, software objects also consist of state and related behavior. An object stores it's state in attributes and exposes its behavior through methods. Let's look at the pseudo code for a bicycle object.
<pre>
CLASS Bicycle
ATTRIBUTES:
speed: NUMBER
gear: NUMBER
pedal_cadence: NUMBER
METHODS:
ride(speed)
changeGear(gear)
changeCadence(pedal_cadence)
</pre>
</td>
<td>[[File:concepts-object.gif]]</td>
</tr>
</table>
In the above pseudo code, the attributes define the object and the methods provide a way of achieving the desired functionality from that object. The methods use the attributes to manipulate the object and achieve the functionality. From this we can observe that this manipulation is the very essence of programming using objects. Therefore the access of attributes and way of defining method calls very important in OOP.

== Method call / Instance Variable reference Syntax ==
A running debate in O-O languages is whether method calls and instance-variable references should have the same syntax. Different programming languages implement this in different ways. Let's look at them by examples.

=== Same Syntax ===
Languages like Ruby use the same syntax for method calls and variable references. There is no distinction between these. We can see this in the example below:
<pre>
class Song
def duration=(newDuration)
@duration = newDuration
end
end
aSong = Song.new("Bicylops", "Fleck", 260)
aSong.duration » 260
aSong.duration = 257 # set attribute with updated value
aSong.duration » 257
</pre>

This makes it simpler for the programmer to code. Also, it presents uniformity in the code.

=== Differing Syntax ===
Languages like Java employ different syntax for method calls and variable references as seen in this example below:
<pre>
class Song{
int duration;
Song(){}
void setDuration(int dur){
duration = dur;
}
}

Song sng = new Song();
sng.setDuration(260);
System.out.println("Song duration = "+sng.duration);
</pre>

As seen above, a method is always called using parenthesis, within which arguments may be included if required. However, instance variable is accessed directly.

== Comparison of syntax between various Programming Languages ==
The usage syntax of methods, instance variables, getters and setters is in the table below

{|class="wikitable"
|-
!Programming Languages
!Method call
!Fields/Attributes
!Getter / Setter
!Comparison
|-
|ABAP (Advanced Business Application Programming)
|<pre>
CALL METHOD <meth> EXPORTING... <ii> =.<f i>...
IMPORTING... <ei> =.<g i>...
CHANGING ... <ci> =.<f i>...
RECEIVING r = h
EXCEPTIONS... <ei> = rc i...
</pre>
|data field type type
|Same as other methods with the only difference that they start with SET or GET
|Syntax is different for method calls and instance-variable reference
|-
|C++
|<instance-variable>.method(parameters) [Eg: x.method()]
|type field
|Same as methods. Example below:
<pre>
int getHealth() const { return health; }
void setHealth(int h) { health = h; }
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|C#
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|They are just like methods. Example below:
<pre>
public string GetName()
{
return m_name;
}

public void SetName(string name)
{
m_name = name;
}
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|Java
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|They are nothing but method calls
|Different syntax is used to call methods and instance-variable references
|-
|D
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|No need for getters and setters. It can be directly accessed.
<pre>
import std.stdio;

class Car
{
float speed = 1.0;
}

void main(){
auto my_car = new Car();
my_car.speed = 2.5;
writefln(my_car.speed);
}
</pre>
|Syntax used for method calls and variable references is different
|-
|Objective C
|output = [object methodWithOutput]
|x->field
|An example of getter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}

- (NSString*) caption;
- (NSString*) photographer;

@end
</pre>
An example of setter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}
- (NSString*) caption;
- (NSString*) photographer;

- (void) setCaption: (NSString*)input;
- (void) setPhotographer: (NSString*)input;

@end
</pre>
|Syntax used for method calls and variable references is different
|-
|Python
|x.method(parameters)
|x.field
|Pythonic way of implementing getters and setters is to using public members and turning them into properties when needed
|Syntax used for method calls and variable references is sometimes the same and different at times (when there are arguments)

|-
|Javascript
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
var lost = {
loc : "Island",
get location () {
return this.loc;
},
set location(val) {
this.loc = val;
}
};
lost.location = "Another island";
</pre>
|Syntax is different for method calls and instance-variable reference

|-
|PHP
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference

|-
|VB.NET
|
ObjectName.MethodName(Parameters);
ObjectNmae.MethodName
|ObjectName.Attribute
|<pre>
Public Property myProperty As String
Get
Return String.Empty
End Get
Private Set(ByVal value As String)
somethingElse = value
End Set
End Property
</pre>
|Syntax may be same for method calls and instance-variable reference

|-
|Ruby
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>
class Message
attr_reader :message
def message=(m)
@message = m.dup
end
end

class Message
attr_writer :message
def message
@message.encode!("UTF-8")
end
end
</pre>
|Syntax is same for method calls and instance-variable reference

|-
|Lua
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference

|-
|Perl
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>

BEGIN {
my @attr = qw(author title number);
no strict 'refs';
for my $a (@attr){
*{__PACKAGE__ . "::get_$a"} = sub { $_[0]->{$a} };
*{__PACKAGE__ . "::set_$a"} = sub { $_[0]->{$a} = $_[1] };
}
}
</pre>
|Syntax is different for method calls and instance-variable reference

|}

== Conclusion ==
Using the same syntax for method calls and instance variable references have some advantages and disadvantages. One could argue that having the same syntax makes it simpler for the programmer. It makes the code lighter in terms of lines of code, thus avoiding bulky code. However, including distinct ways for using methods and variables enhances readability by enabling better understanding. This is possible because the manipulation is visible whereas if the syntax were the same(i.e. compact), the one reading has no idea about what is happening "under the hood".

== References ==
<ol>
<li>[http://help.sap.com/saphelp_nw04/helpdata/en/08/d27c03b81011d194f60000e8353423/content.htm/ Declaring and Calling Methods]</li>
<li>[http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(object-oriented_programming)/ Comparison of Programming Languages]</li>
<li>[http://forums.sdn.sap.com/thread.jspa?threadID=529448&tstart=6135/ Setters and Getters in ABAP]</li>
<li>[http://www.zeuscmd.com/tutorials/cplusplus/50-GettersAndSetters.php/ Getters and Setters]</li>
<li>[http://cocoadevcentral.com/d/learn_objectivec/ Objective C]</li>
</ol>

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T04:47:34Z

Pramasw3:

Common Attribute/Member Syntax 

Different object oriented programming languages include different ways of accessing the member variables and methods. This page discusses the various usages and their advantages and disadvantages.

== Introduction ==
The purpose of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] is to make programs model things the way people think or deal with the world i.e it's modeled around data rather than logic. Objects form the basis of OOP. Let us now look at objects, their manipulation and the ways to do so.

== Objects - Attributes and Methods ==
<table>
<tr>
<td>
Similar to real world objects, software objects also consist of state and related behavior. An object stores it's state in attributes and exposes its behavior through methods. Let's look at the pseudo code for a bicycle object.
<pre>
CLASS Bicycle
ATTRIBUTES:
speed: NUMBER
gear: NUMBER
pedal_cadence: NUMBER
METHODS:
ride(speed)
changeGear(gear)
changeCadence(pedal_cadence)
</pre>
</td>
<td>[[File:concepts-object.gif]]</td>
</tr>
</table>
In the above pseudo code, the attributes define the object and the methods provide a way of achieving the desired functionality from that object. The methods use the attributes to manipulate the object and achieve the functionality. From this we can observe that this manipulation is the very essence of programming using objects. Therefore the access of attributes and way of defining method calls very important in OOP.

== Method call / Instance Variable reference Syntax ==
A running debate in O-O languages is whether method calls and instance-variable references should have the same syntax. Different programming languages implement this in different ways. Let's look at them by examples.

=== Same Syntax ===
Languages like Ruby use the same syntax for method calls and variable references. There is no distinction between these. We can see this in the example below:
<pre>
class Song
def duration=(newDuration)
@duration = newDuration
end
end
aSong = Song.new("Bicylops", "Fleck", 260)
aSong.duration » 260
aSong.duration = 257 # set attribute with updated value
aSong.duration » 257
</pre>

This makes it simpler for the programmer to code. Also, it presents uniformity in the code.

=== Differing Syntax ===
Languages like Java employ different syntax for method calls and variable references as seen in this example below:
<pre>
class Song{
int duration;
Song(){}
void setDuration(int dur){
duration = dur;
}
}

Song sng = new Song();
sng.setDuration(260);
System.out.println("Song duration = "+sng.duration);
</pre>

As seen above, a method is always called using parenthesis, within which arguments may be included if required. However, instance variable is accessed directly.

== Comparison of syntax between various Programming Languages ==
The usage syntax of methods, instance variables, getters and setters is in the table below

{|class="wikitable"
|-
!Programming Languages
!Method call
!Fields/Attributes
!Getter / Setter
!Comparison
|-
|ABAP (Advanced Business Application Programming)
|<pre>
CALL METHOD <meth> EXPORTING... <ii> =.<f i>...
IMPORTING... <ei> =.<g i>...
CHANGING ... <ci> =.<f i>...
RECEIVING r = h
EXCEPTIONS... <ei> = rc i...
</pre>
|data field type type
|Same as other methods with the only difference that they start with SET or GET
|Syntax is different for method calls and instance-variable reference
|-
|C++
|<instance-variable>.method(parameters) [Eg: x.method()]
|type field
|Same as methods. Example below:
<pre>
int getHealth() const { return health; }
void setHealth(int h) { health = h; }
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|C#
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|They are just like methods. Example below:
<pre>
public string GetName()
{
return m_name;
}

public void SetName(string name)
{
m_name = name;
}
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|Java
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|They are nothing but method calls
|Different syntax is used to call methods and instance-variable references
|-
|D
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|No need for getters and setters. It can be directly accessed.
<pre>
import std.stdio;

class Car
{
float speed = 1.0;
}

void main(){
auto my_car = new Car();
my_car.speed = 2.5;
writefln(my_car.speed);
}
</pre>
|Syntax used for method calls and variable references is different
|-
|Objective C
|output = [object methodWithOutput]
|x->field
|An example of getter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}

- (NSString*) caption;
- (NSString*) photographer;

@end
</pre>
An example of setter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}
- (NSString*) caption;
- (NSString*) photographer;

- (void) setCaption: (NSString*)input;
- (void) setPhotographer: (NSString*)input;

@end
</pre>
|Syntax used for method calls and variable references is different
|-
|Python
|x.method(parameters)
|x.field
|Pythonic way of implementing getters and setters is to using public members and turning them into properties when needed
|Syntax used for method calls and variable references is sometimes the same and different at times (when there are arguments)

|-
|Javascript
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
var lost = {
loc : "Island",
get location () {
return this.loc;
},
set location(val) {
this.loc = val;
}
};
lost.location = "Another island";
</pre>
|Syntax is different for method calls and instance-variable reference

|-
|PHP
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference

|-
|VB.NET
|
ObjectName.MethodName(Parameters);
ObjectNmae.MethodName
|ObjectName.Attribute
|<pre>
Public Property myProperty As String
Get
Return String.Empty
End Get
Private Set(ByVal value As String)
somethingElse = value
End Set
End Property
</pre>
|Syntax may be same for method calls and instance-variable reference

|-
|Ruby
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>
class Message
attr_reader :message
def message=(m)
@message = m.dup
end
end

class Message
attr_writer :message
def message
@message.encode!("UTF-8")
end
end
</pre>
|Syntax is same for method calls and instance-variable reference

|-
|Lua
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference

|-
|Perl
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference

|}

== Conclusion ==
Using the same syntax for method calls and instance variable references have some advantages and disadvantages. One could argue that having the same syntax makes it simpler for the programmer. It makes the code lighter in terms of lines of code, thus avoiding bulky code. However, including distinct ways for using methods and variables enhances readability by enabling better understanding. This is possible because the manipulation is visible whereas if the syntax were the same(i.e. compact), the one reading has no idea about what is happening "under the hood".

== References ==
<ol>
<li>[http://help.sap.com/saphelp_nw04/helpdata/en/08/d27c03b81011d194f60000e8353423/content.htm/ Declaring and Calling Methods]</li>
<li>[http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(object-oriented_programming)/ Comparison of Programming Languages]</li>
<li>[http://forums.sdn.sap.com/thread.jspa?threadID=529448&tstart=6135/ Setters and Getters in ABAP]</li>
<li>[http://www.zeuscmd.com/tutorials/cplusplus/50-GettersAndSetters.php/ Getters and Setters]</li>
<li>[http://cocoadevcentral.com/d/learn_objectivec/ Objective C]</li>
</ol>

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T04:46:38Z

Pramasw3:

Common Attribute/Member Syntax 

Different object oriented programming languages include different ways of accessing the member variables and methods. This page discusses the various usages and their advantages and disadvantages.

== Introduction ==
The purpose of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] is to make programs model things the way people think or deal with the world i.e it's modeled around data rather than logic. Objects form the basis of OOP. Let us now look at objects, their manipulation and the ways to do so.

== Objects - Attributes and Methods ==
<table>
<tr>
<td>
Similar to real world objects, software objects also consist of state and related behavior. An object stores it's state in attributes and exposes its behavior through methods. Let's look at the pseudo code for a bicycle object.
<pre>
CLASS Bicycle
ATTRIBUTES:
speed: NUMBER
gear: NUMBER
pedal_cadence: NUMBER
METHODS:
ride(speed)
changeGear(gear)
changeCadence(pedal_cadence)
</pre>
</td>
<td>[[File:concepts-object.gif]]</td>
</tr>
</table>
In the above pseudo code, the attributes define the object and the methods provide a way of achieving the desired functionality from that object. The methods use the attributes to manipulate the object and achieve the functionality. From this we can observe that this manipulation is the very essence of programming using objects. Therefore the access of attributes and way of defining method calls very important in OOP.

== Method call / Instance Variable reference Syntax ==
A running debate in O-O languages is whether method calls and instance-variable references should have the same syntax. Different programming languages implement this in different ways. Let's look at them by examples.

=== Same Syntax ===
Languages like Ruby use the same syntax for method calls and variable references. There is no distinction between these. We can see this in the example below:
<pre>
class Song
def duration=(newDuration)
@duration = newDuration
end
end
aSong = Song.new("Bicylops", "Fleck", 260)
aSong.duration » 260
aSong.duration = 257 # set attribute with updated value
aSong.duration » 257
</pre>

This makes it simpler for the programmer to code. Also, it presents uniformity in the code.

=== Differing Syntax ===
Languages like Java employ different syntax for method calls and variable references as seen in this example below:
<pre>
class Song{
int duration;
Song(){}
void setDuration(int dur){
duration = dur;
}
}

Song sng = new Song();
sng.setDuration(260);
System.out.println("Song duration = "+sng.duration);
</pre>

As seen above, a method is always called using parenthesis, within which arguments may be included if required. However, instance variable is accessed directly.

== Comparison of syntax between various Programming Languages ==
The usage syntax of methods, instance variables, getters and setters is in the table below

{|class="wikitable"
|-
!Programming Languages
!Method call
!Fields/Attributes
!Getter / Setter
!Comparison
|-
|ABAP (Advanced Business Application Programming)
|<pre>
CALL METHOD <meth> EXPORTING... <ii> =.<f i>...
IMPORTING... <ei> =.<g i>...
CHANGING ... <ci> =.<f i>...
RECEIVING r = h
EXCEPTIONS... <ei> = rc i...
</pre>
|data field type type
|Same as other methods with the only difference that they start with SET or GET
|Syntax is different for method calls and instance-variable reference
|-
|C++
|<instance-variable>.method(parameters) [Eg: x.method()]
|type field
|Same as methods. Example below:
<pre>
int getHealth() const { return health; }
void setHealth(int h) { health = h; }
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|C#
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|They are just like methods. Example below:
<pre>
public string GetName()
{
return m_name;
}

public void SetName(string name)
{
m_name = name;
}
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|Java
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|They are nothing but method calls
|Different syntax is used to call methods and instance-variable references
|-
|D
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|No need for getters and setters. It can be directly accessed.
<pre>
import std.stdio;

class Car
{
float speed = 1.0;
}

void main(){
auto my_car = new Car();
my_car.speed = 2.5;
writefln(my_car.speed);
}
</pre>
|Syntax used for method calls and variable references is different
|-
|Objective C
|output = [object methodWithOutput]
|x->field
|An example of getter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}

- (NSString*) caption;
- (NSString*) photographer;

@end
</pre>
An example of setter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}
- (NSString*) caption;
- (NSString*) photographer;

- (void) setCaption: (NSString*)input;
- (void) setPhotographer: (NSString*)input;

@end
</pre>
|Syntax used for method calls and variable references is different
|-
|Python
|x.method(parameters)
|x.field
|Pythonic way of implementing getters and setters is to using public members and turning them into properties when needed
|Syntax used for method calls and variable references is sometimes the same and different at times (when there are arguments)

|-
|Javascript
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
var lost = {
loc : "Island",
get location () {
return this.loc;
},
set location(val) {
this.loc = val;
}
};
lost.location = "Another island";
</pre>
|Syntax is different for method calls and instance-variable reference

|-
|PHP
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference

|-
|VB.NET
|
ObjectName.MethodName(Parameters);
ObjectNmae.MethodName
|ObjectName.Attribute
|<pre>
Public Property myProperty As String
Get
Return String.Empty
End Get
Private Set(ByVal value As String)
somethingElse = value
End Set
End Property
</pre>
|Syntax may be same for method calls and instance-variable reference

|-
|Ruby
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>
class Message
attr_reader :message
def message=(m)
@message = m.dup
end
end

class Message
attr_writer :message
def message
@message.encode!("UTF-8")
end
end

|Syntax is same for method calls and instance-variable reference

|-
|Lua
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference

|-
|Perl
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference

|}

== Conclusion ==
Using the same syntax for method calls and instance variable references have some advantages and disadvantages. One could argue that having the same syntax makes it simpler for the programmer. It makes the code lighter in terms of lines of code, thus avoiding bulky code. However, including distinct ways for using methods and variables enhances readability by enabling better understanding. This is possible because the manipulation is visible whereas if the syntax were the same(i.e. compact), the one reading has no idea about what is happening "under the hood".

== References ==
<ol>
<li>[http://help.sap.com/saphelp_nw04/helpdata/en/08/d27c03b81011d194f60000e8353423/content.htm/ Declaring and Calling Methods]</li>
<li>[http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(object-oriented_programming)/ Comparison of Programming Languages]</li>
<li>[http://forums.sdn.sap.com/thread.jspa?threadID=529448&tstart=6135/ Setters and Getters in ABAP]</li>
<li>[http://www.zeuscmd.com/tutorials/cplusplus/50-GettersAndSetters.php/ Getters and Setters]</li>
<li>[http://cocoadevcentral.com/d/learn_objectivec/ Objective C]</li>
</ol>

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T04:45:29Z

Pramasw3:

Common Attribute/Member Syntax 

Different object oriented programming languages include different ways of accessing the member variables and methods. This page discusses the various usages and their advantages and disadvantages.

== Introduction ==
The purpose of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] is to make programs model things the way people think or deal with the world i.e it's modeled around data rather than logic. Objects form the basis of OOP. Let us now look at objects, their manipulation and the ways to do so.

== Objects - Attributes and Methods ==
<table>
<tr>
<td>
Similar to real world objects, software objects also consist of state and related behavior. An object stores it's state in attributes and exposes its behavior through methods. Let's look at the pseudo code for a bicycle object.
<pre>
CLASS Bicycle
ATTRIBUTES:
speed: NUMBER
gear: NUMBER
pedal_cadence: NUMBER
METHODS:
ride(speed)
changeGear(gear)
changeCadence(pedal_cadence)
</pre>
</td>
<td>[[File:concepts-object.gif]]</td>
</tr>
</table>
In the above pseudo code, the attributes define the object and the methods provide a way of achieving the desired functionality from that object. The methods use the attributes to manipulate the object and achieve the functionality. From this we can observe that this manipulation is the very essence of programming using objects. Therefore the access of attributes and way of defining method calls very important in OOP.

== Method call / Instance Variable reference Syntax ==
A running debate in O-O languages is whether method calls and instance-variable references should have the same syntax. Different programming languages implement this in different ways. Let's look at them by examples.

=== Same Syntax ===
Languages like Ruby use the same syntax for method calls and variable references. There is no distinction between these. We can see this in the example below:
<pre>
class Song
def duration=(newDuration)
@duration = newDuration
end
end
aSong = Song.new("Bicylops", "Fleck", 260)
aSong.duration » 260
aSong.duration = 257 # set attribute with updated value
aSong.duration » 257
</pre>

This makes it simpler for the programmer to code. Also, it presents uniformity in the code.

=== Differing Syntax ===
Languages like Java employ different syntax for method calls and variable references as seen in this example below:
<pre>
class Song{
int duration;
Song(){}
void setDuration(int dur){
duration = dur;
}
}

Song sng = new Song();
sng.setDuration(260);
System.out.println("Song duration = "+sng.duration);
</pre>

As seen above, a method is always called using parenthesis, within which arguments may be included if required. However, instance variable is accessed directly.

== Comparison of syntax between various Programming Languages ==
The usage syntax of methods, instance variables, getters and setters is in the table below

{|class="wikitable"
|-
!Programming Languages
!Method call
!Fields/Attributes
!Getter / Setter
!Comparison
|-
|ABAP (Advanced Business Application Programming)
|<pre>
CALL METHOD <meth> EXPORTING... <ii> =.<f i>...
IMPORTING... <ei> =.<g i>...
CHANGING ... <ci> =.<f i>...
RECEIVING r = h
EXCEPTIONS... <ei> = rc i...
</pre>
|data field type type
|Same as other methods with the only difference that they start with SET or GET
|Syntax is different for method calls and instance-variable reference
|-
|C++
|<instance-variable>.method(parameters) [Eg: x.method()]
|type field
|Same as methods. Example below:
<pre>
int getHealth() const { return health; }
void setHealth(int h) { health = h; }
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|C#
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|They are just like methods. Example below:
<pre>
public string GetName()
{
return m_name;
}

public void SetName(string name)
{
m_name = name;
}
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|Java
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|They are nothing but method calls
|Different syntax is used to call methods and instance-variable references
|-
|D
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|No need for getters and setters. It can be directly accessed.
<pre>
import std.stdio;

class Car
{
float speed = 1.0;
}

void main(){
auto my_car = new Car();
my_car.speed = 2.5;
writefln(my_car.speed);
}
</pre>
|Syntax used for method calls and variable references is different
|-
|Objective C
|output = [object methodWithOutput]
|x->field
|An example of getter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}

- (NSString*) caption;
- (NSString*) photographer;

@end
</pre>
An example of setter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}
- (NSString*) caption;
- (NSString*) photographer;

- (void) setCaption: (NSString*)input;
- (void) setPhotographer: (NSString*)input;

@end
</pre>
|Syntax used for method calls and variable references is different
|-
|Python
|x.method(parameters)
|x.field
|Pythonic way of implementing getters and setters is to using public members and turning them into properties when needed
|Syntax used for method calls and variable references is sometimes the same and different at times (when there are arguments)

|-
|Javascript
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
var lost = {
loc : "Island",
get location () {
return this.loc;
},
set location(val) {
this.loc = val;
}
};
lost.location = "Another island";
</pre>
|Syntax is different for method calls and instance-variable reference

|-
|PHP
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference

|-
|VB.NET
|
ObjectName.MethodName(Parameters);
ObjectNmae.MethodName
|ObjectName.Attribute
|<pre>
Public Property myProperty As String
Get
Return String.Empty
End Get
Private Set(ByVal value As String)
somethingElse = value
End Set
End Property
</pre>
|Syntax may be same for method calls and instance-variable reference

|-
|Ruby
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is same for method calls and instance-variable reference

|-
|Lua
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference

|-
|Perl
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference

|}

== Conclusion ==
Using the same syntax for method calls and instance variable references have some advantages and disadvantages. One could argue that having the same syntax makes it simpler for the programmer. It makes the code lighter in terms of lines of code, thus avoiding bulky code. However, including distinct ways for using methods and variables enhances readability by enabling better understanding. This is possible because the manipulation is visible whereas if the syntax were the same(i.e. compact), the one reading has no idea about what is happening "under the hood".

== References ==
<ol>
<li>[http://help.sap.com/saphelp_nw04/helpdata/en/08/d27c03b81011d194f60000e8353423/content.htm/ Declaring and Calling Methods]</li>
<li>[http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(object-oriented_programming)/ Comparison of Programming Languages]</li>
<li>[http://forums.sdn.sap.com/thread.jspa?threadID=529448&tstart=6135/ Setters and Getters in ABAP]</li>
<li>[http://www.zeuscmd.com/tutorials/cplusplus/50-GettersAndSetters.php/ Getters and Setters]</li>
<li>[http://cocoadevcentral.com/d/learn_objectivec/ Objective C]</li>
</ol>

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T04:32:36Z

Pramasw3:

Common Attribute/Member Syntax 

Different object oriented programming languages include different ways of accessing the member variables and methods. This page discusses the various usages and their advantages and disadvantages.

== Introduction ==
The purpose of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] is to make programs model things the way people think or deal with the world i.e it's modeled around data rather than logic. Objects form the basis of OOP. Let us now look at objects, their manipulation and the ways to do so.

== Objects - Attributes and Methods ==
<table>
<tr>
<td>
Similar to real world objects, software objects also consist of state and related behavior. An object stores it's state in attributes and exposes its behavior through methods. Let's look at the pseudo code for a bicycle object.
<pre>
CLASS Bicycle
ATTRIBUTES:
speed: NUMBER
gear: NUMBER
pedal_cadence: NUMBER
METHODS:
ride(speed)
changeGear(gear)
changeCadence(pedal_cadence)
</pre>
</td>
<td>[[File:concepts-object.gif]]</td>
</tr>
</table>
In the above pseudo code, the attributes define the object and the methods provide a way of achieving the desired functionality from that object. The methods use the attributes to manipulate the object and achieve the functionality. From this we can observe that this manipulation is the very essence of programming using objects. Therefore the access of attributes and way of defining method calls very important in OOP.

== Method call / Instance Variable reference Syntax ==
A running debate in O-O languages is whether method calls and instance-variable references should have the same syntax. Different programming languages implement this in different ways. Let's look at them by examples.

=== Same Syntax ===
Languages like Ruby use the same syntax for method calls and variable references. There is no distinction between these. We can see this in the example below:
<pre>
class Song
def duration=(newDuration)
@duration = newDuration
end
end
aSong = Song.new("Bicylops", "Fleck", 260)
aSong.duration » 260
aSong.duration = 257 # set attribute with updated value
aSong.duration » 257
</pre>

This makes it simpler for the programmer to code. Also, it presents uniformity in the code.

=== Differing Syntax ===
Languages like Java employ different syntax for method calls and variable references as seen in this example below:
<pre>
class Song{
int duration;
Song(){}
void setDuration(int dur){
duration = dur;
}
}

Song sng = new Song();
sng.setDuration(260);
System.out.println("Song duration = "+sng.duration);
</pre>

As seen above, a method is always called using parenthesis, within which arguments may be included if required. However, instance variable is accessed directly.

== Comparison of syntax between various Programming Languages ==
The usage syntax of methods, instance variables, getters and setters is in the table below

{|class="wikitable"
|-
!Programming Languages
!Method call
!Fields/Attributes
!Getter / Setter
!Comparison
|-
|ABAP (Advanced Business Application Programming)
|<pre>
CALL METHOD <meth> EXPORTING... <ii> =.<f i>...
IMPORTING... <ei> =.<g i>...
CHANGING ... <ci> =.<f i>...
RECEIVING r = h
EXCEPTIONS... <ei> = rc i...
</pre>
|data field type type
|Same as other methods with the only difference that they start with SET or GET
|Syntax is different for method calls and instance-variable reference
|-
|C++
|<instance-variable>.method(parameters) [Eg: x.method()]
|type field
|Same as methods. Example below:
<pre>
int getHealth() const { return health; }
void setHealth(int h) { health = h; }
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|C#
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|They are just like methods. Example below:
<pre>
public string GetName()
{
return m_name;
}

public void SetName(string name)
{
m_name = name;
}
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|Java
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|They are nothing but method calls
|Different syntax is used to call methods and instance-variable references
|-
|D
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|No need for getters and setters. It can be directly accessed.
<pre>
import std.stdio;

class Car
{
float speed = 1.0;
}

void main(){
auto my_car = new Car();
my_car.speed = 2.5;
writefln(my_car.speed);
}
</pre>
|Syntax used for method calls and variable references is different
|-
|Objective C
|output = [object methodWithOutput]
|x->field
|An example of getter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}

- (NSString*) caption;
- (NSString*) photographer;

@end
</pre>
An example of setter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}
- (NSString*) caption;
- (NSString*) photographer;

- (void) setCaption: (NSString*)input;
- (void) setPhotographer: (NSString*)input;

@end
</pre>
|Syntax used for method calls and variable references is different
|-
|Python
|x.method(parameters)
|x.field
|Pythonic way of implementing getters and setters is to using public members and turning them into properties when needed
|Syntax used for method calls and variable references is sometimes the same and different at times (when there are arguments)

|-
|Javascript
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
var lost = {
loc : "Island",
get location () {
return this.loc;
},
set location(val) {
this.loc = val;
}
};
lost.location = "Another island";
</pre>
|Syntax is different for method calls and instance-variable reference

|-
|PHP
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference

|-
|VB.NET
|ObjectName.MethodName(Parameters);
ObjectNmae.MethodName
|ObjectName.Attribute
|<pre>
Public Property myProperty As String
Get
Return String.Empty
End Get
Private Set(ByVal value As String)
somethingElse = value
End Set
End Property
</pre>
|Syntax may be same for method calls and instance-variable reference

|-
|Ruby
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is same for method calls and instance-variable reference

|-
|Lua
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference

|-
|Perl
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference

|}

== Conclusion ==
Using the same syntax for method calls and instance variable references have some advantages and disadvantages. One could argue that having the same syntax makes it simpler for the programmer. It makes the code lighter in terms of lines of code, thus avoiding bulky code. However, including distinct ways for using methods and variables enhances readability by enabling better understanding. This is possible because the manipulation is visible whereas if the syntax were the same(i.e. compact), the one reading has no idea about what is happening "under the hood".

== References ==
<ol>
<li>[http://help.sap.com/saphelp_nw04/helpdata/en/08/d27c03b81011d194f60000e8353423/content.htm/ Declaring and Calling Methods]</li>
<li>[http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(object-oriented_programming)/ Comparison of Programming Languages]</li>
<li>[http://forums.sdn.sap.com/thread.jspa?threadID=529448&tstart=6135/ Setters and Getters in ABAP]</li>
<li>[http://www.zeuscmd.com/tutorials/cplusplus/50-GettersAndSetters.php/ Getters and Setters]</li>
<li>[http://cocoadevcentral.com/d/learn_objectivec/ Objective C]</li>
</ol>

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T04:20:30Z

Pramasw3:

Common Attribute/Member Syntax 

Different object oriented programming languages include different ways of accessing the member variables and methods. This page discusses the various usages and their advantages and disadvantages.

== Introduction ==
The purpose of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] is to make programs model things the way people think or deal with the world i.e it's modeled around data rather than logic. Objects form the basis of OOP. Let us now look at objects, their manipulation and the ways to do so.

== Objects - Attributes and Methods ==
<table>
<tr>
<td>
Similar to real world objects, software objects also consist of state and related behavior. An object stores it's state in attributes and exposes its behavior through methods. Let's look at the pseudo code for a bicycle object.
<pre>
CLASS Bicycle
ATTRIBUTES:
speed: NUMBER
gear: NUMBER
pedal_cadence: NUMBER
METHODS:
ride(speed)
changeGear(gear)
changeCadence(pedal_cadence)
</pre>
</td>
<td>[[File:concepts-object.gif]]</td>
</tr>
</table>
In the above pseudo code, the attributes define the object and the methods provide a way of achieving the desired functionality from that object. The methods use the attributes to manipulate the object and achieve the functionality. From this we can observe that this manipulation is the very essence of programming using objects. Therefore the access of attributes and way of defining method calls very important in OOP.

== Method call / Instance Variable reference Syntax ==
A running debate in O-O languages is whether method calls and instance-variable references should have the same syntax. Different programming languages implement this in different ways. Let's look at them by examples.

=== Same Syntax ===
Languages like Ruby use the same syntax for method calls and variable references. There is no distinction between these. We can see this in the example below:
<pre>
class Song
def duration=(newDuration)
@duration = newDuration
end
end
aSong = Song.new("Bicylops", "Fleck", 260)
aSong.duration » 260
aSong.duration = 257 # set attribute with updated value
aSong.duration » 257
</pre>

This makes it simpler for the programmer to code. Also, it presents uniformity in the code.

=== Differing Syntax ===
Languages like Java employ different syntax for method calls and variable references as seen in this example below:
<pre>
class Song{
int duration;
Song(){}
void setDuration(int dur){
duration = dur;
}
}

Song sng = new Song();
sng.setDuration(260);
System.out.println("Song duration = "+sng.duration);
</pre>

As seen above, a method is always called using parenthesis, within which arguments may be included if required. However, instance variable is accessed directly.

== Comparison of syntax between various Programming Languages ==
The usage syntax of methods, instance variables, getters and setters is in the table below

{|class="wikitable"
|-
!Programming Languages
!Method call
!Fields/Attributes
!Getter / Setter
!Comparison
|-
|ABAP (Advanced Business Application Programming)
|<pre>
CALL METHOD <meth> EXPORTING... <ii> =.<f i>...
IMPORTING... <ei> =.<g i>...
CHANGING ... <ci> =.<f i>...
RECEIVING r = h
EXCEPTIONS... <ei> = rc i...
</pre>
|data field type type
|Same as other methods with the only difference that they start with SET or GET
|Syntax is different for method calls and instance-variable reference
|-
|C++
|<instance-variable>.method(parameters) [Eg: x.method()]
|type field
|Same as methods. Example below:
<pre>
int getHealth() const { return health; }
void setHealth(int h) { health = h; }
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|C#
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|They are just like methods. Example below:
<pre>
public string GetName()
{
return m_name;
}

public void SetName(string name)
{
m_name = name;
}
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|Java
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|They are nothing but method calls
|Different syntax is used to call methods and instance-variable references
|-
|D
|<instance-variable>.method(parameters) [Eg: x.method()]
|<instance-variable>.field [Eg: x.field]
|No need for getters and setters. It can be directly accessed.
<pre>
import std.stdio;

class Car
{
float speed = 1.0;
}

void main(){
auto my_car = new Car();
my_car.speed = 2.5;
writefln(my_car.speed);
}
</pre>
|Syntax used for method calls and variable references is different
|-
|Objective C
|output = [object methodWithOutput]
|x->field
|An example of getter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}

- (NSString*) caption;
- (NSString*) photographer;

@end
</pre>
An example of setter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}
- (NSString*) caption;
- (NSString*) photographer;

- (void) setCaption: (NSString*)input;
- (void) setPhotographer: (NSString*)input;

@end
</pre>
|Syntax used for method calls and variable references is different
|-
|Python
|x.method(parameters)
|x.field
|Pythonic way of implementing getters and setters is to using public members and turning them into properties when needed
|Syntax used for method calls and variable references is sometimes the same and different at times (when there are arguments)

|-
|Javascript
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
var lost = {
loc : "Island",
get location () {
return this.loc;
},
set location(val) {
this.loc = val;
}
};
lost.location = "Another island";
</pre>
|Syntax is different for method calls and instance-variable reference

|-
|PHP
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference

|-
|VB.NET
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference

|-
|Ruby
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference

|-
|Lua
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference

|-
|Perl
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference

|}

== Conclusion ==
Using the same syntax for method calls and instance variable references have some advantages and disadvantages. One could argue that having the same syntax makes it simpler for the programmer. It makes the code lighter in terms of lines of code, thus avoiding bulky code. However, including distinct ways for using methods and variables enhances readability by enabling better understanding. This is possible because the manipulation is visible whereas if the syntax were the same(i.e. compact), the one reading has no idea about what is happening "under the hood".

== References ==
<ol>
<li>[http://help.sap.com/saphelp_nw04/helpdata/en/08/d27c03b81011d194f60000e8353423/content.htm/ Declaring and Calling Methods]</li>
<li>[http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(object-oriented_programming)/ Comparison of Programming Languages]</li>
<li>[http://forums.sdn.sap.com/thread.jspa?threadID=529448&tstart=6135/ Setters and Getters in ABAP]</li>
<li>[http://www.zeuscmd.com/tutorials/cplusplus/50-GettersAndSetters.php/ Getters and Setters]</li>
<li>[http://cocoadevcentral.com/d/learn_objectivec/ Objective C]</li>
</ol>

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T04:18:05Z

Pramasw3:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T04:17:07Z

Pramasw3:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T04:15:48Z

Pramasw3:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T04:15:13Z

Pramasw3:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T03:58:16Z

Pramasw3:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T03:54:57Z

Pramasw3:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T03:54:08Z

Pramasw3:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T03:52:35Z

Pramasw3:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T03:51:45Z

Pramasw3:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-07T22:35:18Z

Pramasw3:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-07T22:28:52Z

Pramasw3:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-07T22:27:20Z

Pramasw3: