Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-29T00:34:46Z

Sshyamr: /* Fixtures */

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d Lecture 10] '''"Testing in Rails"'''<ref>http://guides.rubyonrails.org/testing.html</ref> and it basically describes in detail the various types of tests in rails which one might encounter while developing a typical rails application. There are five components central to testing in rails: '''Fixtures''', '''Unit tests''', '''Functional tests''', '''Integration tests''' and '''Performance tests'''. These have been described below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem ''''memory_test_fix''''<ref>http://agilewebdevelopment.com/plugins/memory_test_fix</ref> which basically ([http://en.wikipedia.org/wiki/Monkey_patch monkey]) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they would, if they were to read/write all their results to files (on the disk). It eliminates file locking issues on the test database when running on Windows. This is not a requirement, but it improves the speed of testing and development which is ultimately desirable. Most importantly it is good for testing because one usually does not need the data after the test is done, but only needs it during the lifetime of the test.

Make the following change to the ''''config/database.yml'''' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the ''''database:'''' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one in memory and not in an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref> allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails [http://guides.rubyonrails.org/getting_started.html#generating-a-model generate model] is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the '''"key: value"''' format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called '''':cookie'''' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating the model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that the ones which are generated by default by the scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==
Unit tests are used to test the models. Thus any tests that deal with the validation of data in a model are to be done in Unit tests. It is always a good practice to have one test for every kind of validation present so that everything that could potentially break has goes through tests before production. Models contain most of the business logic, hence the unit tests need to test all the individual methods present in the models too.

When models are generated (either using the ''''generate'''' command or by using scaffolds), default Unit test are generated alongside. These tests by no means contain any functionality by themselves, but are merely placeholders that provide a framework upon which one can write their own tests. Such test stubs are created in the test/unit folder. Almost all tests, be it Unit tests or Integration tests require 'test_helper' which specifies the default configuration of our tests.

Consider the CookBook example in which the model ''''recipe'''' validated the presence of its attributes 'title', 'description', 'instructions' and 'category'. Such a validation ensures that none of the fields can be empty and therefore creation of an empty recipe should be invalid. A Unit test that does just this is given below:
<pre>
test 'should require all fields' do
r = recipe.new
assert_false r.valid?
end
</pre>
A blank recipe should be invalidated by the model which is what '''assert_false''' checks for. This test would pass if '''r.valid?''' is false i.e. model does not accept an empty recipe.

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if all the methods of a controller are working correctly. Since the controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, whether or not the users are getting authenticated correctly, validating the correctness of the content displayed on the page,etc. Functional tests are also used to test the Views because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionalities can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly or not.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a basic idea of what the test is all about.In this case, '''"should use layout"''' implies that this test checks the layout of the page. The gist of this test is that it gets the index page (corresponding to view of this controller),and ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is '''"Online CookBook"'''. <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example of it would be that of a shopping cart application. Even though different phases of the application may work correctly, while running integration tests, one might realize that the ''''add to cart'''' button is absent in the product-catalog, even though the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such [http://en.wikipedia.org/wiki/Behavior_Driven_Development Behavioral-Driven-Development] goes hand in hand with [http://en.wikipedia.org/wiki/Test-driven_development Test-Driven-Development] and helps in removing the ambiguities which are often associated with Customer Requirements.

The following example shows how the test framework '''CapyBara'''<ref>http://opinionated-programmer.com/2011/02/capybara-and-selenium-with-rspec-and-rails-3/</ref> is used for Integration Testing:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedites the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration test written must '''''require 'test_helper' '''''. This is basically a '''''mixin''''', so one still has the capability to access all the low-level GET/POST commands in Test-Unit in addition to all the methods offered by Capybara.

Another example of Integration Testing with Test-Framework '''RSpec Version 1.3.2'''<ref>http://rspec.info/documentation/</ref>:
<pre>
describe "Recipes" do

before(:all) do
@recipe = Recipe.new
end

it "should not accept empty recipe" do
@user.should_not_be_valid
@user.title = "Cookie"
@user.description = "Chocolate Chip Cookie"
@user.instructions = "Bake in Oven"
@user.category = 3
@user.should_be_valid
end

end
</pre>
In the above example we basically test that an empty recipe is invalid and that a recipe with fields filled out is valid. This is a very primitive example of using RSpec and it is just to showcase the difference between RSpec and Capybara, and is in no way a comprehensive example. A thing to note is the ''before(:all)'' method, which is similar to the setup() method in Java's JUnit Framework i.e. this method is called before every test in the ''describe'' block gets executed.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==
Performance tests as the name indicates are used to gauge the performance of the system and play a very important role in software development for the simple reason that as a developer, one does not want the end user to have a poor experience while using the application. Users do not want to wait long for pages to load and elements on the page to respond. They are not - and should not - be concerned with the capability of the system to handle large loads, scale to accommodate increased volumes of traffic etc. Such details are abstracted away from the user, but they ''do'' have a significant impact on user's interaction with the system.

Rails Performance test can be categorized as a special type of integration tests, which are designed for bench-marking and profiling the test code<ref>http://guides.rubyonrails.org/performance_testing.html#modes</ref>. In these tests, one can mention how many connections are to be simulated to the server etc. at the outcome of which it would be possible to identify the performance bottlenecks and hopefully pinpoint the source of speed and/or memory problems.

Detailed examples can be found [http://guides.rubyonrails.org/performance_testing.html#examples Here].

==Conclusion==
Testing is an indispensable and an inevitable part of development in rails.It must be fully exploited to avail the benefits associated with Test-Driven-Development, for the simple reason that rails provides an excellent in-built framework upon which writing tests is a highly natural and intuitive process. There are many advantages to testing and many articles<ref>http://www.learn.geekinterview.com/programming/ruby/ruby-on-rails-application-testing.html</ref> have been written that emphasize this point.

==References==
<references/>

Most of the content for this article has been obtained from the Lecture taught in class which has been the primary resource. The video of the lecture can be found [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d here].

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-29T00:32:27Z

Sshyamr: /* Setup prior to Testing */

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d Lecture 10] '''"Testing in Rails"'''<ref>http://guides.rubyonrails.org/testing.html</ref> and it basically describes in detail the various types of tests in rails which one might encounter while developing a typical rails application. There are five components central to testing in rails: '''Fixtures''', '''Unit tests''', '''Functional tests''', '''Integration tests''' and '''Performance tests'''. These have been described below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem ''''memory_test_fix''''<ref>http://agilewebdevelopment.com/plugins/memory_test_fix</ref> which basically ([http://en.wikipedia.org/wiki/Monkey_patch monkey]) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they would, if they were to read/write all their results to files (on the disk). It eliminates file locking issues on the test database when running on Windows. This is not a requirement, but it improves the speed of testing and development which is ultimately desirable. Most importantly it is good for testing because one usually does not need the data after the test is done, but only needs it during the lifetime of the test.

Make the following change to the ''''config/database.yml'''' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the ''''database:'''' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one in memory and not in an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref> allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails '''generate model''' is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the '''"key: value"''' format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called '''':cookie'''' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating the model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that the ones which are generated by default by the scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==
Unit tests are used to test the models. Thus any tests that deal with the validation of data in a model are to be done in Unit tests. It is always a good practice to have one test for every kind of validation present so that everything that could potentially break has goes through tests before production. Models contain most of the business logic, hence the unit tests need to test all the individual methods present in the models too.

When models are generated (either using the ''''generate'''' command or by using scaffolds), default Unit test are generated alongside. These tests by no means contain any functionality by themselves, but are merely placeholders that provide a framework upon which one can write their own tests. Such test stubs are created in the test/unit folder. Almost all tests, be it Unit tests or Integration tests require 'test_helper' which specifies the default configuration of our tests.

Consider the CookBook example in which the model ''''recipe'''' validated the presence of its attributes 'title', 'description', 'instructions' and 'category'. Such a validation ensures that none of the fields can be empty and therefore creation of an empty recipe should be invalid. A Unit test that does just this is given below:
<pre>
test 'should require all fields' do
r = recipe.new
assert_false r.valid?
end
</pre>
A blank recipe should be invalidated by the model which is what '''assert_false''' checks for. This test would pass if '''r.valid?''' is false i.e. model does not accept an empty recipe.

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if all the methods of a controller are working correctly. Since the controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, whether or not the users are getting authenticated correctly, validating the correctness of the content displayed on the page,etc. Functional tests are also used to test the Views because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionalities can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly or not.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a basic idea of what the test is all about.In this case, '''"should use layout"''' implies that this test checks the layout of the page. The gist of this test is that it gets the index page (corresponding to view of this controller),and ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is '''"Online CookBook"'''. <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example of it would be that of a shopping cart application. Even though different phases of the application may work correctly, while running integration tests, one might realize that the ''''add to cart'''' button is absent in the product-catalog, even though the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such [http://en.wikipedia.org/wiki/Behavior_Driven_Development Behavioral-Driven-Development] goes hand in hand with [http://en.wikipedia.org/wiki/Test-driven_development Test-Driven-Development] and helps in removing the ambiguities which are often associated with Customer Requirements.

The following example shows how the test framework '''CapyBara'''<ref>http://opinionated-programmer.com/2011/02/capybara-and-selenium-with-rspec-and-rails-3/</ref> is used for Integration Testing:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedites the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration test written must '''''require 'test_helper' '''''. This is basically a '''''mixin''''', so one still has the capability to access all the low-level GET/POST commands in Test-Unit in addition to all the methods offered by Capybara.

Another example of Integration Testing with Test-Framework '''RSpec Version 1.3.2'''<ref>http://rspec.info/documentation/</ref>:
<pre>
describe "Recipes" do

before(:all) do
@recipe = Recipe.new
end

it "should not accept empty recipe" do
@user.should_not_be_valid
@user.title = "Cookie"
@user.description = "Chocolate Chip Cookie"
@user.instructions = "Bake in Oven"
@user.category = 3
@user.should_be_valid
end

end
</pre>
In the above example we basically test that an empty recipe is invalid and that a recipe with fields filled out is valid. This is a very primitive example of using RSpec and it is just to showcase the difference between RSpec and Capybara, and is in no way a comprehensive example. A thing to note is the ''before(:all)'' method, which is similar to the setup() method in Java's JUnit Framework i.e. this method is called before every test in the ''describe'' block gets executed.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==
Performance tests as the name indicates are used to gauge the performance of the system and play a very important role in software development for the simple reason that as a developer, one does not want the end user to have a poor experience while using the application. Users do not want to wait long for pages to load and elements on the page to respond. They are not - and should not - be concerned with the capability of the system to handle large loads, scale to accommodate increased volumes of traffic etc. Such details are abstracted away from the user, but they ''do'' have a significant impact on user's interaction with the system.

Rails Performance test can be categorized as a special type of integration tests, which are designed for bench-marking and profiling the test code<ref>http://guides.rubyonrails.org/performance_testing.html#modes</ref>. In these tests, one can mention how many connections are to be simulated to the server etc. at the outcome of which it would be possible to identify the performance bottlenecks and hopefully pinpoint the source of speed and/or memory problems.

Detailed examples can be found [http://guides.rubyonrails.org/performance_testing.html#examples Here].

==Conclusion==
Testing is an indispensable and an inevitable part of development in rails.It must be fully exploited to avail the benefits associated with Test-Driven-Development, for the simple reason that rails provides an excellent in-built framework upon which writing tests is a highly natural and intuitive process. There are many advantages to testing and many articles<ref>http://www.learn.geekinterview.com/programming/ruby/ruby-on-rails-application-testing.html</ref> have been written that emphasize this point.

==References==
<references/>

Most of the content for this article has been obtained from the Lecture taught in class which has been the primary resource. The video of the lecture can be found [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d here].

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-29T00:30:37Z

Sshyamr: /* Integration Tests */

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d Lecture 10] '''"Testing in Rails"'''<ref>http://guides.rubyonrails.org/testing.html</ref> and it basically describes in detail the various types of tests in rails which one might encounter while developing a typical rails application. There are five components central to testing in rails: '''Fixtures''', '''Unit tests''', '''Functional tests''', '''Integration tests''' and '''Performance tests'''. These have been described below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem ''''memory_test_fix''''<ref>http://agilewebdevelopment.com/plugins/memory_test_fix</ref> which basically (monkey) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they would, if they were to read/write all their results to files (on the disk).It eliminates file locking issues on the test database when running on Windows. This is not a requirement, but it improves the speed of testing and development which is ultimately desirable. Most importantly it is good for testing because one usually does not need the data after the test is done, but only needs it during the lifetime of the test.

Make the following change to the ''''config/database.yml'''' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the ''''database:'''' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one in memory and not in an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref> allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails '''generate model''' is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the '''"key: value"''' format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called '''':cookie'''' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating the model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that the ones which are generated by default by the scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==
Unit tests are used to test the models. Thus any tests that deal with the validation of data in a model are to be done in Unit tests. It is always a good practice to have one test for every kind of validation present so that everything that could potentially break has goes through tests before production. Models contain most of the business logic, hence the unit tests need to test all the individual methods present in the models too.

When models are generated (either using the ''''generate'''' command or by using scaffolds), default Unit test are generated alongside. These tests by no means contain any functionality by themselves, but are merely placeholders that provide a framework upon which one can write their own tests. Such test stubs are created in the test/unit folder. Almost all tests, be it Unit tests or Integration tests require 'test_helper' which specifies the default configuration of our tests.

Consider the CookBook example in which the model ''''recipe'''' validated the presence of its attributes 'title', 'description', 'instructions' and 'category'. Such a validation ensures that none of the fields can be empty and therefore creation of an empty recipe should be invalid. A Unit test that does just this is given below:
<pre>
test 'should require all fields' do
r = recipe.new
assert_false r.valid?
end
</pre>
A blank recipe should be invalidated by the model which is what '''assert_false''' checks for. This test would pass if '''r.valid?''' is false i.e. model does not accept an empty recipe.

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if all the methods of a controller are working correctly. Since the controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, whether or not the users are getting authenticated correctly, validating the correctness of the content displayed on the page,etc. Functional tests are also used to test the Views because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionalities can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly or not.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a basic idea of what the test is all about.In this case, '''"should use layout"''' implies that this test checks the layout of the page. The gist of this test is that it gets the index page (corresponding to view of this controller),and ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is '''"Online CookBook"'''. <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example of it would be that of a shopping cart application. Even though different phases of the application may work correctly, while running integration tests, one might realize that the ''''add to cart'''' button is absent in the product-catalog, even though the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such [http://en.wikipedia.org/wiki/Behavior_Driven_Development Behavioral-Driven-Development] goes hand in hand with [http://en.wikipedia.org/wiki/Test-driven_development Test-Driven-Development] and helps in removing the ambiguities which are often associated with Customer Requirements.

The following example shows how the test framework '''CapyBara'''<ref>http://opinionated-programmer.com/2011/02/capybara-and-selenium-with-rspec-and-rails-3/</ref> is used for Integration Testing:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedites the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration test written must '''''require 'test_helper' '''''. This is basically a '''''mixin''''', so one still has the capability to access all the low-level GET/POST commands in Test-Unit in addition to all the methods offered by Capybara.

Another example of Integration Testing with Test-Framework '''RSpec Version 1.3.2'''<ref>http://rspec.info/documentation/</ref>:
<pre>
describe "Recipes" do

before(:all) do
@recipe = Recipe.new
end

it "should not accept empty recipe" do
@user.should_not_be_valid
@user.title = "Cookie"
@user.description = "Chocolate Chip Cookie"
@user.instructions = "Bake in Oven"
@user.category = 3
@user.should_be_valid
end

end
</pre>
In the above example we basically test that an empty recipe is invalid and that a recipe with fields filled out is valid. This is a very primitive example of using RSpec and it is just to showcase the difference between RSpec and Capybara, and is in no way a comprehensive example. A thing to note is the ''before(:all)'' method, which is similar to the setup() method in Java's JUnit Framework i.e. this method is called before every test in the ''describe'' block gets executed.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==
Performance tests as the name indicates are used to gauge the performance of the system and play a very important role in software development for the simple reason that as a developer, one does not want the end user to have a poor experience while using the application. Users do not want to wait long for pages to load and elements on the page to respond. They are not - and should not - be concerned with the capability of the system to handle large loads, scale to accommodate increased volumes of traffic etc. Such details are abstracted away from the user, but they ''do'' have a significant impact on user's interaction with the system.

Rails Performance test can be categorized as a special type of integration tests, which are designed for bench-marking and profiling the test code<ref>http://guides.rubyonrails.org/performance_testing.html#modes</ref>. In these tests, one can mention how many connections are to be simulated to the server etc. at the outcome of which it would be possible to identify the performance bottlenecks and hopefully pinpoint the source of speed and/or memory problems.

Detailed examples can be found [http://guides.rubyonrails.org/performance_testing.html#examples Here].

==Conclusion==
Testing is an indispensable and an inevitable part of development in rails.It must be fully exploited to avail the benefits associated with Test-Driven-Development, for the simple reason that rails provides an excellent in-built framework upon which writing tests is a highly natural and intuitive process. There are many advantages to testing and many articles<ref>http://www.learn.geekinterview.com/programming/ruby/ruby-on-rails-application-testing.html</ref> have been written that emphasize this point.

==References==
<references/>

Most of the content for this article has been obtained from the Lecture taught in class which has been the primary resource. The video of the lecture can be found [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d here].

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-29T00:28:47Z

Sshyamr: /* Integration Tests */

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d Lecture 10] '''"Testing in Rails"'''<ref>http://guides.rubyonrails.org/testing.html</ref> and it basically describes in detail the various types of tests in rails which one might encounter while developing a typical rails application. There are five components central to testing in rails: '''Fixtures''', '''Unit tests''', '''Functional tests''', '''Integration tests''' and '''Performance tests'''. These have been described below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem ''''memory_test_fix''''<ref>http://agilewebdevelopment.com/plugins/memory_test_fix</ref> which basically (monkey) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they would, if they were to read/write all their results to files (on the disk).It eliminates file locking issues on the test database when running on Windows. This is not a requirement, but it improves the speed of testing and development which is ultimately desirable. Most importantly it is good for testing because one usually does not need the data after the test is done, but only needs it during the lifetime of the test.

Make the following change to the ''''config/database.yml'''' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the ''''database:'''' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one in memory and not in an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref> allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails '''generate model''' is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the '''"key: value"''' format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called '''':cookie'''' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating the model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that the ones which are generated by default by the scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==
Unit tests are used to test the models. Thus any tests that deal with the validation of data in a model are to be done in Unit tests. It is always a good practice to have one test for every kind of validation present so that everything that could potentially break has goes through tests before production. Models contain most of the business logic, hence the unit tests need to test all the individual methods present in the models too.

When models are generated (either using the ''''generate'''' command or by using scaffolds), default Unit test are generated alongside. These tests by no means contain any functionality by themselves, but are merely placeholders that provide a framework upon which one can write their own tests. Such test stubs are created in the test/unit folder. Almost all tests, be it Unit tests or Integration tests require 'test_helper' which specifies the default configuration of our tests.

Consider the CookBook example in which the model ''''recipe'''' validated the presence of its attributes 'title', 'description', 'instructions' and 'category'. Such a validation ensures that none of the fields can be empty and therefore creation of an empty recipe should be invalid. A Unit test that does just this is given below:
<pre>
test 'should require all fields' do
r = recipe.new
assert_false r.valid?
end
</pre>
A blank recipe should be invalidated by the model which is what '''assert_false''' checks for. This test would pass if '''r.valid?''' is false i.e. model does not accept an empty recipe.

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if all the methods of a controller are working correctly. Since the controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, whether or not the users are getting authenticated correctly, validating the correctness of the content displayed on the page,etc. Functional tests are also used to test the Views because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionalities can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly or not.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a basic idea of what the test is all about.In this case, '''"should use layout"''' implies that this test checks the layout of the page. The gist of this test is that it gets the index page (corresponding to view of this controller),and ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is '''"Online CookBook"'''. <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example of it would be that of a shopping cart application. Even though different phases of the application may work correctly, while running integration tests, one might realize that the ''''add to cart'''' button is absent in the product-catalog, even though the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such '''''Behavioral-Driven-Development''''' goes hand in hand with '''''Test-Driven-Development''''' and helps in removing the ambiguities which are often associated with Customer Requirements.

The following example shows how the test framework '''CapyBara'''<ref>http://opinionated-programmer.com/2011/02/capybara-and-selenium-with-rspec-and-rails-3/</ref> is used for Integration Testing:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedites the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration test written must '''''require 'test_helper' '''''. This is basically a '''''mixin''''', so one still has the capability to access all the low-level GET/POST commands in Test-Unit in addition to all the methods offered by Capybara.

Another example of Integration Testing with Test-Framework '''RSpec Version 1.3.2'''<ref>http://rspec.info/documentation/</ref>:
<pre>
describe "Recipes" do

before(:all) do
@recipe = Recipe.new
end

it "should not accept empty recipe" do
@user.should_not_be_valid
@user.title = "Cookie"
@user.description = "Chocolate Chip Cookie"
@user.instructions = "Bake in Oven"
@user.category = 3
@user.should_be_valid
end

end
</pre>
In the above example we basically test that an empty recipe is invalid and that a recipe with fields filled out is valid. This is a very primitive example of using RSpec and it is just to showcase the difference between RSpec and Capybara, and is in no way a comprehensive example. A thing to note is the ''before(:all)'' method, which is similar to the setup() method in Java's JUnit Framework i.e. this method is called before every test in the ''describe'' block gets executed.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==
Performance tests as the name indicates are used to gauge the performance of the system and play a very important role in software development for the simple reason that as a developer, one does not want the end user to have a poor experience while using the application. Users do not want to wait long for pages to load and elements on the page to respond. They are not - and should not - be concerned with the capability of the system to handle large loads, scale to accommodate increased volumes of traffic etc. Such details are abstracted away from the user, but they ''do'' have a significant impact on user's interaction with the system.

Rails Performance test can be categorized as a special type of integration tests, which are designed for bench-marking and profiling the test code<ref>http://guides.rubyonrails.org/performance_testing.html#modes</ref>. In these tests, one can mention how many connections are to be simulated to the server etc. at the outcome of which it would be possible to identify the performance bottlenecks and hopefully pinpoint the source of speed and/or memory problems.

Detailed examples can be found [http://guides.rubyonrails.org/performance_testing.html#examples Here].

==Conclusion==
Testing is an indispensable and an inevitable part of development in rails.It must be fully exploited to avail the benefits associated with Test-Driven-Development, for the simple reason that rails provides an excellent in-built framework upon which writing tests is a highly natural and intuitive process. There are many advantages to testing and many articles<ref>http://www.learn.geekinterview.com/programming/ruby/ruby-on-rails-application-testing.html</ref> have been written that emphasize this point.

==References==
<references/>

Most of the content for this article has been obtained from the Lecture taught in class which has been the primary resource. The video of the lecture can be found [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d here].

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-29T00:27:49Z

Sshyamr: /* Integration Tests */

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d Lecture 10] '''"Testing in Rails"'''<ref>http://guides.rubyonrails.org/testing.html</ref> and it basically describes in detail the various types of tests in rails which one might encounter while developing a typical rails application. There are five components central to testing in rails: '''Fixtures''', '''Unit tests''', '''Functional tests''', '''Integration tests''' and '''Performance tests'''. These have been described below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem ''''memory_test_fix''''<ref>http://agilewebdevelopment.com/plugins/memory_test_fix</ref> which basically (monkey) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they would, if they were to read/write all their results to files (on the disk).It eliminates file locking issues on the test database when running on Windows. This is not a requirement, but it improves the speed of testing and development which is ultimately desirable. Most importantly it is good for testing because one usually does not need the data after the test is done, but only needs it during the lifetime of the test.

Make the following change to the ''''config/database.yml'''' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the ''''database:'''' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one in memory and not in an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref> allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails '''generate model''' is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the '''"key: value"''' format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called '''':cookie'''' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating the model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that the ones which are generated by default by the scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==
Unit tests are used to test the models. Thus any tests that deal with the validation of data in a model are to be done in Unit tests. It is always a good practice to have one test for every kind of validation present so that everything that could potentially break has goes through tests before production. Models contain most of the business logic, hence the unit tests need to test all the individual methods present in the models too.

When models are generated (either using the ''''generate'''' command or by using scaffolds), default Unit test are generated alongside. These tests by no means contain any functionality by themselves, but are merely placeholders that provide a framework upon which one can write their own tests. Such test stubs are created in the test/unit folder. Almost all tests, be it Unit tests or Integration tests require 'test_helper' which specifies the default configuration of our tests.

Consider the CookBook example in which the model ''''recipe'''' validated the presence of its attributes 'title', 'description', 'instructions' and 'category'. Such a validation ensures that none of the fields can be empty and therefore creation of an empty recipe should be invalid. A Unit test that does just this is given below:
<pre>
test 'should require all fields' do
r = recipe.new
assert_false r.valid?
end
</pre>
A blank recipe should be invalidated by the model which is what '''assert_false''' checks for. This test would pass if '''r.valid?''' is false i.e. model does not accept an empty recipe.

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if all the methods of a controller are working correctly. Since the controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, whether or not the users are getting authenticated correctly, validating the correctness of the content displayed on the page,etc. Functional tests are also used to test the Views because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionalities can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly or not.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a basic idea of what the test is all about.In this case, '''"should use layout"''' implies that this test checks the layout of the page. The gist of this test is that it gets the index page (corresponding to view of this controller),and ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is '''"Online CookBook"'''. <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example of it would be that of a shopping cart application. Even though different phases of the application may work correctly, while running integration tests, one might realize that the ''''add to cart'''' button is absent in the product-catalog, even though the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such '''''Behavioral-Driven-Development''''' goes hand in hand with '''''Test-Driven-Development''''' and helps in removing the ambiguities which are often associated with Customer Requirements.

The following example shows how the test framework '''CapyBara''' is used for Integration Testing:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedites the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration test written must '''''require 'test_helper' '''''. This is basically a '''''mixin''''', so one still has the capability to access all the low-level GET/POST commands in Test-Unit in addition to all the methods offered by Capybara.

Another example of Integration Testing with Test-Framework '''RSpec Version 1.3.2'''<ref>http://rspec.info/documentation/</ref>:
<pre>
describe "Recipes" do

before(:all) do
@recipe = Recipe.new
end

it "should not accept empty recipe" do
@user.should_not_be_valid
@user.title = "Cookie"
@user.description = "Chocolate Chip Cookie"
@user.instructions = "Bake in Oven"
@user.category = 3
@user.should_be_valid
end

end
</pre>
In the above example we basically test that an empty recipe is invalid and that a recipe with fields filled out is valid. This is a very primitive example of using RSpec and it is just to showcase the difference between RSpec and Capybara, and is in no way a comprehensive example. A thing to note is the ''before(:all)'' method, which is similar to the setup() method in Java's JUnit Framework i.e. this method is called before every test in the ''describe'' block gets executed.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==
Performance tests as the name indicates are used to gauge the performance of the system and play a very important role in software development for the simple reason that as a developer, one does not want the end user to have a poor experience while using the application. Users do not want to wait long for pages to load and elements on the page to respond. They are not - and should not - be concerned with the capability of the system to handle large loads, scale to accommodate increased volumes of traffic etc. Such details are abstracted away from the user, but they ''do'' have a significant impact on user's interaction with the system.

Rails Performance test can be categorized as a special type of integration tests, which are designed for bench-marking and profiling the test code<ref>http://guides.rubyonrails.org/performance_testing.html#modes</ref>. In these tests, one can mention how many connections are to be simulated to the server etc. at the outcome of which it would be possible to identify the performance bottlenecks and hopefully pinpoint the source of speed and/or memory problems.

Detailed examples can be found [http://guides.rubyonrails.org/performance_testing.html#examples Here].

==Conclusion==
Testing is an indispensable and an inevitable part of development in rails.It must be fully exploited to avail the benefits associated with Test-Driven-Development, for the simple reason that rails provides an excellent in-built framework upon which writing tests is a highly natural and intuitive process. There are many advantages to testing and many articles<ref>http://www.learn.geekinterview.com/programming/ruby/ruby-on-rails-application-testing.html</ref> have been written that emphasize this point.

==References==
<references/>

Most of the content for this article has been obtained from the Lecture taught in class which has been the primary resource. The video of the lecture can be found [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d here].

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-29T00:26:46Z

Sshyamr: /* Integration Tests */

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d Lecture 10] '''"Testing in Rails"'''<ref>http://guides.rubyonrails.org/testing.html</ref> and it basically describes in detail the various types of tests in rails which one might encounter while developing a typical rails application. There are five components central to testing in rails: '''Fixtures''', '''Unit tests''', '''Functional tests''', '''Integration tests''' and '''Performance tests'''. These have been described below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem ''''memory_test_fix''''<ref>http://agilewebdevelopment.com/plugins/memory_test_fix</ref> which basically (monkey) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they would, if they were to read/write all their results to files (on the disk).It eliminates file locking issues on the test database when running on Windows. This is not a requirement, but it improves the speed of testing and development which is ultimately desirable. Most importantly it is good for testing because one usually does not need the data after the test is done, but only needs it during the lifetime of the test.

Make the following change to the ''''config/database.yml'''' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the ''''database:'''' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one in memory and not in an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref> allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails '''generate model''' is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the '''"key: value"''' format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called '''':cookie'''' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating the model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that the ones which are generated by default by the scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==
Unit tests are used to test the models. Thus any tests that deal with the validation of data in a model are to be done in Unit tests. It is always a good practice to have one test for every kind of validation present so that everything that could potentially break has goes through tests before production. Models contain most of the business logic, hence the unit tests need to test all the individual methods present in the models too.

When models are generated (either using the ''''generate'''' command or by using scaffolds), default Unit test are generated alongside. These tests by no means contain any functionality by themselves, but are merely placeholders that provide a framework upon which one can write their own tests. Such test stubs are created in the test/unit folder. Almost all tests, be it Unit tests or Integration tests require 'test_helper' which specifies the default configuration of our tests.

Consider the CookBook example in which the model ''''recipe'''' validated the presence of its attributes 'title', 'description', 'instructions' and 'category'. Such a validation ensures that none of the fields can be empty and therefore creation of an empty recipe should be invalid. A Unit test that does just this is given below:
<pre>
test 'should require all fields' do
r = recipe.new
assert_false r.valid?
end
</pre>
A blank recipe should be invalidated by the model which is what '''assert_false''' checks for. This test would pass if '''r.valid?''' is false i.e. model does not accept an empty recipe.

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if all the methods of a controller are working correctly. Since the controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, whether or not the users are getting authenticated correctly, validating the correctness of the content displayed on the page,etc. Functional tests are also used to test the Views because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionalities can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly or not.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a basic idea of what the test is all about.In this case, '''"should use layout"''' implies that this test checks the layout of the page. The gist of this test is that it gets the index page (corresponding to view of this controller),and ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is '''"Online CookBook"'''. <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example of it would be that of a shopping cart application. Even though different phases of the application may work correctly, while running integration tests, one might realize that the ''''add to cart'''' button is absent in the product-catalog, even though the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such '''''Behavioral-Driven-Development''''' goes hand in hand with '''''Test-Driven-Development''''' and helps in removing the ambiguities which are often associated with Customer Requirements.

The following example shows how the test framework '''CapyBara''' is used for Integration Testing:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedites the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration test written must '''''require 'test_helper' '''''. This is basically a '''''mixin''''', so one still has the capability to access all the low-level GET/POST commands in Test-Unit in addition to all the methods offered by Capybara.

Another example of Integration Testing with Test-Framework '''RSpec Version 1.3.2''':
<pre>
describe "Recipes" do

before(:all) do
@recipe = Recipe.new
end

it "should not accept empty recipe" do
@user.should_not_be_valid
@user.title = "Cookie"
@user.description = "Chocolate Chip Cookie"
@user.instructions = "Bake in Oven"
@user.category = 3
@user.should_be_valid
end

end
</pre>
In the above example we basically test that an empty recipe is invalid and that a recipe with fields filled out is valid. This is a very primitive example of using RSpec and it is just to showcase the difference between RSpec and Capybara, and is in no way a comprehensive example. A thing to note is the ''before(:all)'' method, which is similar to the setup() method in Java's JUnit Framework i.e. this method is called before every test in the ''describe'' block gets executed.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==
Performance tests as the name indicates are used to gauge the performance of the system and play a very important role in software development for the simple reason that as a developer, one does not want the end user to have a poor experience while using the application. Users do not want to wait long for pages to load and elements on the page to respond. They are not - and should not - be concerned with the capability of the system to handle large loads, scale to accommodate increased volumes of traffic etc. Such details are abstracted away from the user, but they ''do'' have a significant impact on user's interaction with the system.

Rails Performance test can be categorized as a special type of integration tests, which are designed for bench-marking and profiling the test code<ref>http://guides.rubyonrails.org/performance_testing.html#modes</ref>. In these tests, one can mention how many connections are to be simulated to the server etc. at the outcome of which it would be possible to identify the performance bottlenecks and hopefully pinpoint the source of speed and/or memory problems.

Detailed examples can be found [http://guides.rubyonrails.org/performance_testing.html#examples Here].

==Conclusion==
Testing is an indispensable and an inevitable part of development in rails.It must be fully exploited to avail the benefits associated with Test-Driven-Development, for the simple reason that rails provides an excellent in-built framework upon which writing tests is a highly natural and intuitive process. There are many advantages to testing and many articles<ref>http://www.learn.geekinterview.com/programming/ruby/ruby-on-rails-application-testing.html</ref> have been written that emphasize this point.

==References==
<references/>

Most of the content for this article has been obtained from the Lecture taught in class which has been the primary resource. The video of the lecture can be found [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d here].

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-25T00:43:40Z

Sshyamr: /* Integration Tests */

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d Lecture 10] '''"Testing in Rails"'''<ref>http://guides.rubyonrails.org/testing.html</ref> and it basically describes in detail the various types of tests in rails which one might encounter while developing a typical rails application. There are five components central to testing in rails: '''Fixtures''', '''Unit tests''', '''Functional tests''', '''Integration tests''' and '''Performance tests'''. These have been described below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem ''''memory_test_fix''''<ref>http://agilewebdevelopment.com/plugins/memory_test_fix</ref> which basically (monkey) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they would, if they were to read/write all their results to files (on the disk).It eliminates file locking issues on the test database when running on Windows. This is not a requirement, but it improves the speed of testing and development which is ultimately desirable. Most importantly it is good for testing because one usually does not need the data after the test is done, but only needs it during the lifetime of the test.

Make the following change to the ''''config/database.yml'''' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the ''''database:'''' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one in memory and not in an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref> allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails '''generate model''' is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the '''"key: value"''' format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called '''':cookie'''' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating the model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that the ones which are generated by default by the scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==
Unit tests are used to test the models. Thus any tests that deal with the validation of data in a model are to be done in Unit tests. It is always a good practice to have one test for every kind of validation present so that everything that could potentially break has goes through tests before production. Models contain most of the business logic, hence the unit tests need to test all the individual methods present in the models too.

When models are generated (either using the ''''generate'''' command or by using scaffolds), default Unit test are generated alongside. These tests by no means contain any functionality by themselves, but are merely placeholders that provide a framework upon which one can write their own tests. Such test stubs are created in the test/unit folder. Almost all tests, be it Unit tests or Integration tests require 'test_helper' which specifies the default configuration of our tests.

Consider the CookBook example in which the model ''''recipe'''' validated the presence of its attributes 'title', 'description', 'instructions' and 'category'. Such a validation ensures that none of the fields can be empty and therefore creation of an empty recipe should be invalid. A Unit test that does just this is given below:
<pre>
test 'should require all fields' do
r = recipe.new
assert_false r.valid?
end
</pre>
A blank recipe should be invalidated by the model which is what '''assert_false''' checks for. This test would pass if '''r.valid?''' is false i.e. model does not accept an empty recipe.

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if all the methods of a controller are working correctly. Since the controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, whether or not the users are getting authenticated correctly, validating the correctness of the content displayed on the page,etc. Functional tests are also used to test the Views because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionalities can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly or not.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a basic idea of what the test is all about.In this case, '''"should use layout"''' implies that this test checks the layout of the page. The gist of this test is that it gets the index page (corresponding to view of this controller),and ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is '''"Online CookBook"'''. <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example of it would be that of a shopping cart application. Even though different phases of the application may work correctly, while running integration tests, one might realize that the ''''add to cart'''' button is absent in the product-catalog, even though the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such '''''Behavioral-Driven-Development''''' goes hand in hand with '''''Test-Driven-Development''''' and helps in removing the ambiguities which are often associated with Customer Requirements.

An Example:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedites the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration test written must '''''require 'test_helper' '''''. This is basically a '''''mixin''''', so one still has the capability to access all the low-level GET/POST commands in Test-Unit in addition to all the methods offered by Capybara.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==
Performance tests as the name indicates are used to gauge the performance of the system and play a very important role in software development for the simple reason that as a developer, one does not want the end user to have a poor experience while using the application. Users do not want to wait long for pages to load and elements on the page to respond. They are not - and should not - be concerned with the capability of the system to handle large loads, scale to accommodate increased volumes of traffic etc. Such details are abstracted away from the user, but they ''do'' have a significant impact on user's interaction with the system.

Rails Performance test can be categorized as a special type of integration tests, which are designed for bench-marking and profiling the test code<ref>http://guides.rubyonrails.org/performance_testing.html#modes</ref>. In these tests, one can mention how many connections are to be simulated to the server etc. at the outcome of which it would be possible to identify the performance bottlenecks and hopefully pinpoint the source of speed and/or memory problems.

Detailed examples can be found [http://guides.rubyonrails.org/performance_testing.html#examples Here].

==Conclusion==
Testing is an indispensable and an inevitable part of development in rails.It must be fully exploited to avail the benefits associated with Test-Driven-Development, for the simple reason that rails provides an excellent in-built framework upon which writing tests is a highly natural and intuitive process. There are many advantages to testing and many articles<ref>http://www.learn.geekinterview.com/programming/ruby/ruby-on-rails-application-testing.html</ref> have been written that emphasize this point.

==References==
<references/>

Most of the content for this article has been obtained from the Lecture taught in class which has been the primary resource. The video of the lecture can be found [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d here].

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-25T00:39:53Z

Sshyamr: /* Introduction */

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d Lecture 10] '''"Testing in Rails"'''<ref>http://guides.rubyonrails.org/testing.html</ref> and it basically describes in detail the various types of tests in rails which one might encounter while developing a typical rails application. There are five components central to testing in rails: '''Fixtures''', '''Unit tests''', '''Functional tests''', '''Integration tests''' and '''Performance tests'''. These have been described below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem ''''memory_test_fix''''<ref>http://agilewebdevelopment.com/plugins/memory_test_fix</ref> which basically (monkey) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they would, if they were to read/write all their results to files (on the disk).It eliminates file locking issues on the test database when running on Windows. This is not a requirement, but it improves the speed of testing and development which is ultimately desirable. Most importantly it is good for testing because one usually does not need the data after the test is done, but only needs it during the lifetime of the test.

Make the following change to the ''''config/database.yml'''' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the ''''database:'''' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one in memory and not in an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref> allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails '''generate model''' is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the '''"key: value"''' format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called '''':cookie'''' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating the model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that the ones which are generated by default by the scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==
Unit tests are used to test the models. Thus any tests that deal with the validation of data in a model are to be done in Unit tests. It is always a good practice to have one test for every kind of validation present so that everything that could potentially break has goes through tests before production. Models contain most of the business logic, hence the unit tests need to test all the individual methods present in the models too.

When models are generated (either using the ''''generate'''' command or by using scaffolds), default Unit test are generated alongside. These tests by no means contain any functionality by themselves, but are merely placeholders that provide a framework upon which one can write their own tests. Such test stubs are created in the test/unit folder. Almost all tests, be it Unit tests or Integration tests require 'test_helper' which specifies the default configuration of our tests.

Consider the CookBook example in which the model ''''recipe'''' validated the presence of its attributes 'title', 'description', 'instructions' and 'category'. Such a validation ensures that none of the fields can be empty and therefore creation of an empty recipe should be invalid. A Unit test that does just this is given below:
<pre>
test 'should require all fields' do
r = recipe.new
assert_false r.valid?
end
</pre>
A blank recipe should be invalidated by the model which is what '''assert_false''' checks for. This test would pass if '''r.valid?''' is false i.e. model does not accept an empty recipe.

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if all the methods of a controller are working correctly. Since the controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, whether or not the users are getting authenticated correctly, validating the correctness of the content displayed on the page,etc. Functional tests are also used to test the Views because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionalities can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly or not.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a basic idea of what the test is all about.In this case, '''"should use layout"''' implies that this test checks the layout of the page. The gist of this test is that it gets the index page (corresponding to view of this controller),and ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is '''"Online CookBook"'''. <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example of it would be that of a shopping cart application. Even though different phases of the application may work correctly, integration testing one might realize that the ''''add to cart'''' button is absent in the product-catalog, even though the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such '''''Behavioral-Driven-Development''''' goes hand in hand with '''''Test-Driven-Development''''' and helps in removing the ambiguities which are often associated with Customer Requirements.

An Example:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedites the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration test written must '''''require 'test_helper' '''''. This is basically a '''''mixin''''', so one still has the capability to access all the low-level GET/POST commands in Test-Unit in addition to all the methods offered by Capybara.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==
Performance tests as the name indicates are used to gauge the performance of the system and play a very important role in software development for the simple reason that as a developer, one does not want the end user to have a poor experience while using the application. Users do not want to wait long for pages to load and elements on the page to respond. They are not - and should not - be concerned with the capability of the system to handle large loads, scale to accommodate increased volumes of traffic etc. Such details are abstracted away from the user, but they ''do'' have a significant impact on user's interaction with the system.

Rails Performance test can be categorized as a special type of integration tests, which are designed for bench-marking and profiling the test code<ref>http://guides.rubyonrails.org/performance_testing.html#modes</ref>. In these tests, one can mention how many connections are to be simulated to the server etc. at the outcome of which it would be possible to identify the performance bottlenecks and hopefully pinpoint the source of speed and/or memory problems.

Detailed examples can be found [http://guides.rubyonrails.org/performance_testing.html#examples Here].

==Conclusion==
Testing is an indispensable and an inevitable part of development in rails.It must be fully exploited to avail the benefits associated with Test-Driven-Development, for the simple reason that rails provides an excellent in-built framework upon which writing tests is a highly natural and intuitive process. There are many advantages to testing and many articles<ref>http://www.learn.geekinterview.com/programming/ruby/ruby-on-rails-application-testing.html</ref> have been written that emphasize this point.

==References==
<references/>

Most of the content for this article has been obtained from the Lecture taught in class which has been the primary resource. The video of the lecture can be found [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d here].

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-22T20:14:12Z

Sshyamr: /* Conclusion */

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d Lecture 10] '''"Testing in Rails"'''<ref>http://guides.rubyonrails.org/testing.html</ref> and it basically describes in detail the various types of tests in rails which one might encounter while developing a typical rails application. There are five components central to testing in railsz: '''Fixtures''', '''Unit tests''', '''Functional tests''', '''Integration tests''' and '''Performance tests'''. These have been described below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem ''''memory_test_fix''''<ref>http://agilewebdevelopment.com/plugins/memory_test_fix</ref> which basically (monkey) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they would, if they were to read/write all their results to files (on the disk).It eliminates file locking issues on the test database when running on Windows. This is not a requirement, but it improves the speed of testing and development which is ultimately desirable. Most importantly it is good for testing because one usually does not need the data after the test is done, but only needs it during the lifetime of the test.

Make the following change to the ''''config/database.yml'''' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the ''''database:'''' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one in memory and not in an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref> allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails '''generate model''' is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the '''"key: value"''' format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called '''':cookie'''' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating the model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that the ones which are generated by default by the scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==
Unit tests are used to test the models. Thus any tests that deal with the validation of data in a model are to be done in Unit tests. It is always a good practice to have one test for every kind of validation present so that everything that could potentially break has goes through tests before production. Models contain most of the business logic, hence the unit tests need to test all the individual methods present in the models too.

When models are generated (either using the ''''generate'''' command or by using scaffolds), default Unit test are generated alongside. These tests by no means contain any functionality by themselves, but are merely placeholders that provide a framework upon which one can write their own tests. Such test stubs are created in the test/unit folder. Almost all tests, be it Unit tests or Integration tests require 'test_helper' which specifies the default configuration of our tests.

Consider the CookBook example in which the model ''''recipe'''' validated the presence of its attributes 'title', 'description', 'instructions' and 'category'. Such a validation ensures that none of the fields can be empty and therefore creation of an empty recipe should be invalid. A Unit test that does just this is given below:
<pre>
test 'should require all fields' do
r = recipe.new
assert_false r.valid?
end
</pre>
A blank recipe should be invalidated by the model which is what '''assert_false''' checks for. This test would pass if '''r.valid?''' is false i.e. model does not accept an empty recipe.

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if all the methods of a controller are working correctly. Since the controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, whether or not the users are getting authenticated correctly, validating the correctness of the content displayed on the page,etc. Functional tests are also used to test the Views because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionalities can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly or not.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a basic idea of what the test is all about.In this case, '''"should use layout"''' implies that this test checks the layout of the page. The gist of this test is that it gets the index page (corresponding to view of this controller),and ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is '''"Online CookBook"'''. <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example of it would be that of a shopping cart application. Even though different phases of the application may work correctly, integration testing one might realize that the ''''add to cart'''' button is absent in the product-catalog, even though the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such '''''Behavioral-Driven-Development''''' goes hand in hand with '''''Test-Driven-Development''''' and helps in removing the ambiguities which are often associated with Customer Requirements.

An Example:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedites the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration test written must '''''require 'test_helper' '''''. This is basically a '''''mixin''''', so one still has the capability to access all the low-level GET/POST commands in Test-Unit in addition to all the methods offered by Capybara.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==
Performance tests as the name indicates are used to gauge the performance of the system and play a very important role in software development for the simple reason that as a developer, one does not want the end user to have a poor experience while using the application. Users do not want to wait long for pages to load and elements on the page to respond. They are not - and should not - be concerned with the capability of the system to handle large loads, scale to accommodate increased volumes of traffic etc. Such details are abstracted away from the user, but they ''do'' have a significant impact on user's interaction with the system.

Rails Performance test can be categorized as a special type of integration tests, which are designed for bench-marking and profiling the test code<ref>http://guides.rubyonrails.org/performance_testing.html#modes</ref>. In these tests, one can mention how many connections are to be simulated to the server etc. at the outcome of which it would be possible to identify the performance bottlenecks and hopefully pinpoint the source of speed and/or memory problems.

Detailed examples can be found [http://guides.rubyonrails.org/performance_testing.html#examples Here].

==Conclusion==
Testing is an indispensable and an inevitable part of development in rails.It must be fully exploited to avail the benefits associated with Test-Driven-Development, for the simple reason that rails provides an excellent in-built framework upon which writing tests is a highly natural and intuitive process. There are many advantages to testing and many articles<ref>http://www.learn.geekinterview.com/programming/ruby/ruby-on-rails-application-testing.html</ref> have been written that emphasize this point.

==References==
<references/>

Most of the content for this article has been obtained from the Lecture taught in class which has been the primary resource. The video of the lecture can be found [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d here].

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-22T20:13:41Z

Sshyamr: /* References */

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d Lecture 10] '''"Testing in Rails"'''<ref>http://guides.rubyonrails.org/testing.html</ref> and it basically describes in detail the various types of tests in rails which one might encounter while developing a typical rails application. There are five components central to testing in railsz: '''Fixtures''', '''Unit tests''', '''Functional tests''', '''Integration tests''' and '''Performance tests'''. These have been described below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem ''''memory_test_fix''''<ref>http://agilewebdevelopment.com/plugins/memory_test_fix</ref> which basically (monkey) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they would, if they were to read/write all their results to files (on the disk).It eliminates file locking issues on the test database when running on Windows. This is not a requirement, but it improves the speed of testing and development which is ultimately desirable. Most importantly it is good for testing because one usually does not need the data after the test is done, but only needs it during the lifetime of the test.

Make the following change to the ''''config/database.yml'''' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the ''''database:'''' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one in memory and not in an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref> allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails '''generate model''' is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the '''"key: value"''' format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called '''':cookie'''' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating the model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that the ones which are generated by default by the scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==
Unit tests are used to test the models. Thus any tests that deal with the validation of data in a model are to be done in Unit tests. It is always a good practice to have one test for every kind of validation present so that everything that could potentially break has goes through tests before production. Models contain most of the business logic, hence the unit tests need to test all the individual methods present in the models too.

When models are generated (either using the ''''generate'''' command or by using scaffolds), default Unit test are generated alongside. These tests by no means contain any functionality by themselves, but are merely placeholders that provide a framework upon which one can write their own tests. Such test stubs are created in the test/unit folder. Almost all tests, be it Unit tests or Integration tests require 'test_helper' which specifies the default configuration of our tests.

Consider the CookBook example in which the model ''''recipe'''' validated the presence of its attributes 'title', 'description', 'instructions' and 'category'. Such a validation ensures that none of the fields can be empty and therefore creation of an empty recipe should be invalid. A Unit test that does just this is given below:
<pre>
test 'should require all fields' do
r = recipe.new
assert_false r.valid?
end
</pre>
A blank recipe should be invalidated by the model which is what '''assert_false''' checks for. This test would pass if '''r.valid?''' is false i.e. model does not accept an empty recipe.

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if all the methods of a controller are working correctly. Since the controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, whether or not the users are getting authenticated correctly, validating the correctness of the content displayed on the page,etc. Functional tests are also used to test the Views because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionalities can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly or not.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a basic idea of what the test is all about.In this case, '''"should use layout"''' implies that this test checks the layout of the page. The gist of this test is that it gets the index page (corresponding to view of this controller),and ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is '''"Online CookBook"'''. <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example of it would be that of a shopping cart application. Even though different phases of the application may work correctly, integration testing one might realize that the ''''add to cart'''' button is absent in the product-catalog, even though the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such '''''Behavioral-Driven-Development''''' goes hand in hand with '''''Test-Driven-Development''''' and helps in removing the ambiguities which are often associated with Customer Requirements.

An Example:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedites the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration test written must '''''require 'test_helper' '''''. This is basically a '''''mixin''''', so one still has the capability to access all the low-level GET/POST commands in Test-Unit in addition to all the methods offered by Capybara.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==
Performance tests as the name indicates are used to gauge the performance of the system and play a very important role in software development for the simple reason that as a developer, one does not want the end user to have a poor experience while using the application. Users do not want to wait long for pages to load and elements on the page to respond. They are not - and should not - be concerned with the capability of the system to handle large loads, scale to accommodate increased volumes of traffic etc. Such details are abstracted away from the user, but they ''do'' have a significant impact on user's interaction with the system.

Rails Performance test can be categorized as a special type of integration tests, which are designed for bench-marking and profiling the test code<ref>http://guides.rubyonrails.org/performance_testing.html#modes</ref>. In these tests, one can mention how many connections are to be simulated to the server etc. at the outcome of which it would be possible to identify the performance bottlenecks and hopefully pinpoint the source of speed and/or memory problems.

Detailed examples can be found [http://guides.rubyonrails.org/performance_testing.html#examples Here].

==Conclusion==
Testing is an indispensable and an inevitable part of development in rails.It must be fully exploited to avail the benefits associated with Test-Driven-Development, for the simple reason that rails provides an excellent in-built framework upon which writing tests is a highly natural and intuitive process. There are many advantages to testing and many articles[http://www.learn.geekinterview.com/programming/ruby/ruby-on-rails-application-testing.html] have been written that emphasize this point.

==References==
<references/>

Most of the content for this article has been obtained from the Lecture taught in class which has been the primary resource. The video of the lecture can be found [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d here].

CSC/ECE 517 Fall 2011

2011-10-21T01:24:25Z

Sshyamr:

[[Link title]]
*[[CSC/ECE 517 Fall 2011/ch1 1a ms]]

*[[CSC/ECE 517 Fall 2011/ch1 1a cs]]

*[[CSC/ECE 517 Fall 2011/ch1 1a ri]]

*[[CSC/ECE 517 Fall 2011/ch1 1a lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1b sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1b ds]]

*[[CSC/ECE 517 Fall 2011/ch1 1b tj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c cm]]

*[[CSC/ECE 517 Fall 2011/ch1 1c sj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c ka]]

*[[CSC/ECE 517 Fall 2011/ch1 1d sr]]

*[[CSC/ECE 517 Fall 2011/ch1 1e vs]]

*[[CSC/ECE 517 Fall 2011/ch1 1e aa]]

*[[CSC/ECE 517 Fall 2011/ch1 1a sc]]

*[[CSC/ECE 517 Fall 2011/ch1 1e dm]]

*[[CSC/ECE 517 Fall 2011/ch1 1e an]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1e lm]]

*[[CSC/ECE 517 Fall 2011/ch1 1g vn]]

*[[CSC/ECE 517 Fall 2011/ch1 1f rs]]

*[[CSC/ECE 517 Fall 2011/ch1 1f sv]]

*[[CSC/ECE 517 Fall 2011/ch1 1g jn]]

*[[CSC/ECE 517 Fall 2011/ch1 1h ps]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sm]]

*[[CSC/ECE 517 Fall 2011/ch1 1i zf]]

*[[CSC/ECE 517 Fall 2011/ch1 1g rn]]

*[[CSC/ECE 517 Fall 2011/ch1 1i cl]]

*[[CSC/ECE 517 Fall 2011/ch1 1d ss]]

*[[CSC/ECE 517 Fall 2011/ch1 1i lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1h hs]]

*[[CSC/ECE 517 Fall 2011/ch1 1d gs]]

*[[CSC/ECE 517 Fall 2011/ch1 2b ns]]

*[[CSC/ECE 517 Fall 2011/ch1 2b jp]]

*[[CSC/ECE 517 Fall 2011/ch1 2a av]]

*[[CSC/ECE 517 Fall 2011/ch2 2f jm]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ad]]

*[[CSC/ECE 517 Fall 2011/ch2 2e kt]]

*[[CSC/ECE 517 Fall 2011/ch2 2e gp]]

*[[CSC/ECE 517 Fall 2011/ch1 2b qu]]

*[[CSC/ECE 517 Fall 2011/ch2 2c bs]]

*[[CSC/ECE 517 Fall 2011/ch1 2c rs]]

*[[CSC/ECE 517 Fall 2011/ch1 2a ca]]

*[[CSC/ECE 517 Fall 2011/ch1 2b rv]]

*[[CSC/ECE 517 Fall 2011/ch2 2c ds]]

*[[CSC/ECE 517 Fall 2011/ch2 2b sa]]

*[[CSC/ECE 517 Fall 2011/ch2 2f vh]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ps]]

*[[CSC/ECE 517 Fall 2011/ch3 3a oe]]

*[[CSC/ECE 517 Fall 2011/ch3 3h rr]]

*[[CSC/ECE 517 Fall 2011/ch3 3h ss]]

*[[CSC/ECE 517 Fall 2011/ch3 4b js]]

*[[CSC/ECE 517 Fall 2011/ch3 4b ms]]

*[[CSC/ECE 517 Fall 2011/ch4 4b ds]]

*[[CSC/ECE 517 Fall 2011/ch4 4i aa]]

*[[CSC/ECE 517 Fall 2011/ch4 4i sd]]

*[[CSC/ECE 517 Fall 2011/ch4 4d mt]]

*[[CSC/ECE 517 Fall 2011/ch4 4d ls]]

*[[CSC/ECE 517 Fall 2011/ch4 4d ch]]

*[[CSC/ECE 517 Fall 2011/ch4 4c ap]]

*[[CSC/ECE 517 Fall 2011/ch4 4h sv]]

*[[CSC/ECE 517 Fall 2011/ch4 4e cl]]

*[[CSC/ECE 517 Fall 2011/ch4 4e gs]]

*[[CSC/ECE 517 Fall 2011/ch4 4a ga]]

*[[CSC/ECE 517 Fall 2011/ch4 4f sl]]

*[[CSC/ECE 517 Fall 2011/ch4 4i js]]

*[[CSC/ECE 517 Fall 2011/ch4 4f ss]]

*[[CSC/ECE 517 Fall 2011/ch4 4c dm]]

*[[CSC/ECE 517 Fall 2011/ch4 4g as]]

*[[CSC/ECE 517 Fall 2011/ch4 4g nv]]

*[[CSC/ECE 517 Fall 2011/ch4 4g ms]]

*[[CSC/ECE 517 Fall 2011/ch4 4h kp]]

*[[CSC/ECE 517 Fall 2011/ch4 4h lp]]

*[[CSC/ECE 517 Fall 2011/ch4 4j fw]]

*[[CSC/ECE 517 Fall 2011/ch4 4f rs]]

*[[CSC/ECE 517 Fall 2011/ch4 4i lc]]

*[[trial]]

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-21T01:22:46Z

Sshyamr: /* References */

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d Lecture 10] '''"Testing in Rails"'''<ref>http://guides.rubyonrails.org/testing.html</ref> and it basically describes in detail the various types of tests in rails which one might encounter while developing a typical rails application. There are five components central to testing in railsz: '''Fixtures''', '''Unit tests''', '''Functional tests''', '''Integration tests''' and '''Performance tests'''. These have been described below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem ''''memory_test_fix''''<ref>http://agilewebdevelopment.com/plugins/memory_test_fix</ref> which basically (monkey) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they would, if they were to read/write all their results to files (on the disk).It eliminates file locking issues on the test database when running on Windows. This is not a requirement, but it improves the speed of testing and development which is ultimately desirable. Most importantly it is good for testing because one usually does not need the data after the test is done, but only needs it during the lifetime of the test.

Make the following change to the ''''config/database.yml'''' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the ''''database:'''' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one in memory and not in an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref> allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails '''generate model''' is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the '''"key: value"''' format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called '''':cookie'''' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating the model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that the ones which are generated by default by the scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==
Unit tests are used to test the models. Thus any tests that deal with the validation of data in a model are to be done in Unit tests. It is always a good practice to have one test for every kind of validation present so that everything that could potentially break has goes through tests before production. Models contain most of the business logic, hence the unit tests need to test all the individual methods present in the models too.

When models are generated (either using the ''''generate'''' command or by using scaffolds), default Unit test are generated alongside. These tests by no means contain any functionality by themselves, but are merely placeholders that provide a framework upon which one can write their own tests. Such test stubs are created in the test/unit folder. Almost all tests, be it Unit tests or Integration tests require 'test_helper' which specifies the default configuration of our tests.

Consider the CookBook example in which the model ''''recipe'''' validated the presence of its attributes 'title', 'description', 'instructions' and 'category'. Such a validation ensures that none of the fields can be empty and therefore creation of an empty recipe should be invalid. A Unit test that does just this is given below:
<pre>
test 'should require all fields' do
r = recipe.new
assert_false r.valid?
end
</pre>
A blank recipe should be invalidated by the model which is what '''assert_false''' checks for. This test would pass if '''r.valid?''' is false i.e. model does not accept an empty recipe.

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if all the methods of a controller are working correctly. Since the controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, whether or not the users are getting authenticated correctly, validating the correctness of the content displayed on the page,etc. Functional tests are also used to test the Views because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionalities can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly or not.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a basic idea of what the test is all about.In this case, '''"should use layout"''' implies that this test checks the layout of the page. The gist of this test is that it gets the index page (corresponding to view of this controller),and ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is '''"Online CookBook"'''. <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example of it would be that of a shopping cart application. Even though different phases of the application may work correctly, integration testing one might realize that the ''''add to cart'''' button is absent in the product-catalog, even though the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such '''''Behavioral-Driven-Development''''' goes hand in hand with '''''Test-Driven-Development''''' and helps in removing the ambiguities which are often associated with Customer Requirements.

An Example:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedites the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration test written must '''''require 'test_helper' '''''. This is basically a '''''mixin''''', so one still has the capability to access all the low-level GET/POST commands in Test-Unit in addition to all the methods offered by Capybara.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==
Performance tests as the name indicates are used to gauge the performance of the system and play a very important role in software development for the simple reason that as a developer, one does not want the end user to have a poor experience while using the application. Users do not want to wait long for pages to load and elements on the page to respond. They are not - and should not - be concerned with the capability of the system to handle large loads, scale to accommodate increased volumes of traffic etc. Such details are abstracted away from the user, but they ''do'' have a significant impact on user's interaction with the system.

Rails Performance test can be categorized as a special type of integration tests, which are designed for bench-marking and profiling the test code<ref>http://guides.rubyonrails.org/performance_testing.html#modes</ref>. In these tests, one can mention how many connections are to be simulated to the server etc. at the outcome of which it would be possible to identify the performance bottlenecks and hopefully pinpoint the source of speed and/or memory problems.

Detailed examples can be found [http://guides.rubyonrails.org/performance_testing.html#examples Here].

==Conclusion==
Testing is an indispensable and an inevitable part of development in rails.It must be fully exploited to avail the benefits associated with Test-Driven-Development, for the simple reason that rails provides an excellent in-built framework upon which writing tests is a highly natural and intuitive process. There are many advantages to testing and many articles[http://www.learn.geekinterview.com/programming/ruby/ruby-on-rails-application-testing.html] have been written that emphasize this point.

==References==
<references/>

Most of the content for this article has been obtained from the Lecture taught in class which has been the primary primary resource. The video of the lecture can be found [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d here].

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-21T01:19:20Z

Sshyamr:

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d Lecture 10] '''"Testing in Rails"'''<ref>http://guides.rubyonrails.org/testing.html</ref> and it basically describes in detail the various types of tests in rails which one might encounter while developing a typical rails application. There are five components central to testing in railsz: '''Fixtures''', '''Unit tests''', '''Functional tests''', '''Integration tests''' and '''Performance tests'''. These have been described below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem ''''memory_test_fix''''<ref>http://agilewebdevelopment.com/plugins/memory_test_fix</ref> which basically (monkey) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they would, if they were to read/write all their results to files (on the disk).It eliminates file locking issues on the test database when running on Windows. This is not a requirement, but it improves the speed of testing and development which is ultimately desirable. Most importantly it is good for testing because one usually does not need the data after the test is done, but only needs it during the lifetime of the test.

Make the following change to the ''''config/database.yml'''' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the ''''database:'''' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one in memory and not in an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref> allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails '''generate model''' is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the '''"key: value"''' format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called '''':cookie'''' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating the model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that the ones which are generated by default by the scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==
Unit tests are used to test the models. Thus any tests that deal with the validation of data in a model are to be done in Unit tests. It is always a good practice to have one test for every kind of validation present so that everything that could potentially break has goes through tests before production. Models contain most of the business logic, hence the unit tests need to test all the individual methods present in the models too.

When models are generated (either using the ''''generate'''' command or by using scaffolds), default Unit test are generated alongside. These tests by no means contain any functionality by themselves, but are merely placeholders that provide a framework upon which one can write their own tests. Such test stubs are created in the test/unit folder. Almost all tests, be it Unit tests or Integration tests require 'test_helper' which specifies the default configuration of our tests.

Consider the CookBook example in which the model ''''recipe'''' validated the presence of its attributes 'title', 'description', 'instructions' and 'category'. Such a validation ensures that none of the fields can be empty and therefore creation of an empty recipe should be invalid. A Unit test that does just this is given below:
<pre>
test 'should require all fields' do
r = recipe.new
assert_false r.valid?
end
</pre>
A blank recipe should be invalidated by the model which is what '''assert_false''' checks for. This test would pass if '''r.valid?''' is false i.e. model does not accept an empty recipe.

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if all the methods of a controller are working correctly. Since the controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, whether or not the users are getting authenticated correctly, validating the correctness of the content displayed on the page,etc. Functional tests are also used to test the Views because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionalities can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly or not.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a basic idea of what the test is all about.In this case, '''"should use layout"''' implies that this test checks the layout of the page. The gist of this test is that it gets the index page (corresponding to view of this controller),and ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is '''"Online CookBook"'''. <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example of it would be that of a shopping cart application. Even though different phases of the application may work correctly, integration testing one might realize that the ''''add to cart'''' button is absent in the product-catalog, even though the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such '''''Behavioral-Driven-Development''''' goes hand in hand with '''''Test-Driven-Development''''' and helps in removing the ambiguities which are often associated with Customer Requirements.

An Example:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedites the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration test written must '''''require 'test_helper' '''''. This is basically a '''''mixin''''', so one still has the capability to access all the low-level GET/POST commands in Test-Unit in addition to all the methods offered by Capybara.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==
Performance tests as the name indicates are used to gauge the performance of the system and play a very important role in software development for the simple reason that as a developer, one does not want the end user to have a poor experience while using the application. Users do not want to wait long for pages to load and elements on the page to respond. They are not - and should not - be concerned with the capability of the system to handle large loads, scale to accommodate increased volumes of traffic etc. Such details are abstracted away from the user, but they ''do'' have a significant impact on user's interaction with the system.

Rails Performance test can be categorized as a special type of integration tests, which are designed for bench-marking and profiling the test code<ref>http://guides.rubyonrails.org/performance_testing.html#modes</ref>. In these tests, one can mention how many connections are to be simulated to the server etc. at the outcome of which it would be possible to identify the performance bottlenecks and hopefully pinpoint the source of speed and/or memory problems.

Detailed examples can be found [http://guides.rubyonrails.org/performance_testing.html#examples Here].

==Conclusion==
Testing is an indispensable and an inevitable part of development in rails.It must be fully exploited to avail the benefits associated with Test-Driven-Development, for the simple reason that rails provides an excellent in-built framework upon which writing tests is a highly natural and intuitive process. There are many advantages to testing and many articles[http://www.learn.geekinterview.com/programming/ruby/ruby-on-rails-application-testing.html] have been written that emphasize this point.

==References==
<references/>

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-20T07:47:12Z

Sshyamr:

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of Lecture 10 "Testing in Rails" and it basically describes in detail the various types of tests in rails one might encounter while developing a typical rails application. There are four components central to testing in rails: Fixtures, Unit tests, Functional tests, Integration tests and Performance tests. These have been described below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem 'memory_test_fix' which basically (monkey) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they otherwise would if they were to read/write all their results to files (on the disk) and also because it will eliminate file locking issues on the test database when running on Windows. This is in no way a requirement, but it improves the speed of testing and development which is ultimately desirable. This is especially good for testing because one usually does not need the data after the test is done, but only during the lifetime of the test.

Make the following change to the 'config/database.yml' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the 'database:' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one on memory and not an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails generate model is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the "key: value" format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called ':cookie' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that ones default-generated by scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==
Unit tests are used to test the models. Thus any tests that deal with the validation of data in a model are to be done in Unit tests. It is good practice to have one test for every kind of validation present so the everything that could potentially break has been tested. Models contain most of the business logic, hence the unit tests need to test all the individual methods present in the models too.

When models are generated (either using the 'generate' command or by using scaffolds), default Unit test are generated alongside. These tests by no means contain any functionality in and of themselves, but are merely placeholders that provide a framework upon which one can write their own tests. Such test stubs are created in the test/unit folder. Almost all tests, be it Unit tests or Integration tests require 'test_helper' which specifies the default configuration of our tests.

Consider the CookBook example in which the model 'recipe' validated the presence of its attributes 'title', 'description', 'instructions' and 'category'. Since this validation ensures that none of the fields can be empty, creation of an empty recipe should be invalid. A Unit test that does just this is given below:
<pre>
test 'should require all fields' do
r = recipe.new
assert_false r.valid?
end
</pre>
A blank recipe should be invalidated by the model which is what assert_false checks for. This test would pass if r.valid? is false i.e. model does not accept an empty recipe.

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if methods of a controller are working correctly. Since controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, that users are getting authenticated correctly, that the content displayed on the page is correct etc. Functional tests are also used to test the View because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionality can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a absic idea of what the test does. In this case, "should use layout" implies that this test checks the layout of the page. The gist of this test is that it GET's the index page (corresponding to view of this controller), ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is "Online CookBook". <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example would be that of a shopping cart application. Even though different phases of the application may work correctly while integration testing one might realize that the 'add to cart' button is absent in the product-catalog although the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such ''Behavioral-Driven-Development'' goes hand in hand with ''Test-Driven-Development'' and helps in removing the ambiguities often associated with Customer Requirements.

An Example:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedite the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration test written must ''require 'test_helper' ''. This is basically a ''mixin'', so one still has the capability to access all the low-level GET/POST commands in Test-Unit in addition to all the methods offered by Capybara.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==
Performance tests as the name indicates are used to gauge the performance of the system and play a very important role in software development for the simple reason that as a developer, one does not want the end user to have a poor experience while using the application. Users do not want to wait long for pages to load and elements on the page to respond. They are not - and should not - be concerned with the capability of the system to handle large loads, scale to accommodate increased volumes of traffic etc. Such details are abstracted away from the user, but they ''do'' have a significant impact on user's interaction with the system.

Rails Performance test can be categorized as a special type of integration tests, which are designed for bench-marking and profiling the test code. In these tests, one can mention how many connections are to be simulated to the server etc. at the outcome of which it would be possible to identify the performance bottlenecks and hopefully pinpoint the source of speed and/or memory problems.

Detailed examples can be found [http://guides.rubyonrails.org/performance_testing.html#examples Here].

==Conclusion==
Testing is an indispensable an inevitable part of development in rails and must be fully exploited to avail the benefits associated with Test-Driven-Development, if for the simple reason that rails provides an excellent in-built framework upon which writing tests is a highly natural and intuitive process. There are many advantages to testing and [http://www.learn.geekinterview.com/programming/ruby/ruby-on-rails-application-testing.html entire articles] have been written that emphasize this point.

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-20T07:46:02Z

Sshyamr: /* Integration Tests */

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-20T07:45:20Z

Sshyamr: /* Integration Tests */

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of Lecture 10 "Testing in Rails" and it basically describes in detail the various types of tests in rails one might encounter while developing a typical rails application. There are four components central to testing in rails: Fixtures, Unit tests, Functional tests, Integration tests and Performance tests. These have been described below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem 'memory_test_fix' which basically (monkey) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they otherwise would if they were to read/write all their results to files (on the disk) and also because it will eliminate file locking issues on the test database when running on Windows. This is in no way a requirement, but it improves the speed of testing and development which is ultimately desirable. This is especially good for testing because one usually does not need the data after the test is done, but only during the lifetime of the test.

Make the following change to the 'config/database.yml' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the 'database:' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one on memory and not an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails generate model is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the "key: value" format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called ':cookie' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that ones default-generated by scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==
Unit tests are used to test the models. Thus any tests that deal with the validation of data in a model are to be done in Unit tests. It is good practice to have one test for every kind of validation present so the everything that could potentially break has been tested. Models contain most of the business logic, hence the unit tests need to test all the individual methods present in the models too.

When models are generated (either using the 'generate' command or by using scaffolds), default Unit test are generated alongside. These tests by no means contain any functionality in and of themselves, but are merely placeholders that provide a framework upon which one can write their own tests. Such test stubs are created in the test/unit folder. Almost all tests, be it Unit tests or Integration tests require 'test_helper' which specifies the default configuration of our tests.

Consider the CookBook example in which the model 'recipe' validated the presence of its attributes 'title', 'description', 'instructions' and 'category'. Since this validation ensures that none of the fields can be empty, creation of an empty recipe should be invalid. A Unit test that does just this is given below:
<pre>
test 'should require all fields' do
r = recipe.new
assert_false r.valid?
end
</pre>
A blank recipe should be invalidated by the model which is what assert_false checks for. This test would pass if r.valid? is false i.e. model does not accept an empty recipe.

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if methods of a controller are working correctly. Since controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, that users are getting authenticated correctly, that the content displayed on the page is correct etc. Functional tests are also used to test the View because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionality can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a absic idea of what the test does. In this case, "should use layout" implies that this test checks the layout of the page. The gist of this test is that it GET's the index page (corresponding to view of this controller), ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is "Online CookBook". <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example would be that of a shopping cart application. Even though different phases of the application may work correctly while integration testing one might realize that the 'add to cart' button is absent in the product-catalog although the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such ''Behavioral-Driven-Development'' goes hand in hand with ''Test-Driven-Development'' and helps in removing the ambiguities often associated with Customer Requirements.

An Example:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedite the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration test written must ''require 'test_helper' ''. This is basically a ''mixin'', so one still has the capability to access all the low-level GET/POST commands in Test-Unit.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==
Performance tests as the name indicates are used to gauge the performance of the system and play a very important role in software development for the simple reason that as a developer, one does not want the end user to have a poor experience while using the application. Users do not want to wait long for pages to load and elements on the page to respond. They are not - and should not - be concerned with the capability of the system to handle large loads, scale to accommodate increased volumes of traffic etc. Such details are abstracted away from the user, but they ''do'' have a significant impact on user's interaction with the system.

Rails Performance test can be categorized as a special type of integration tests, which are designed for bench-marking and profiling the test code. In these tests, one can mention how many connections are to be simulated to the server etc. at the outcome of which it would be possible to identify the performance bottlenecks and hopefully pinpoint the source of speed and/or memory problems.

Detailed examples can be found [http://guides.rubyonrails.org/performance_testing.html#examples Here].

==Conclusion==
Testing is an indispensable an inevitable part of development in rails and must be fully exploited to avail the benefits associated with Test-Driven-Development, if for the simple reason that rails provides an excellent in-built framework upon which writing tests is a highly natural and intuitive process. There are many advantages to testing and [http://www.learn.geekinterview.com/programming/ruby/ruby-on-rails-application-testing.html entire articles] have been written that emphasize this point.

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-20T07:40:20Z

Sshyamr: /* Introduction */

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of Lecture 10 "Testing in Rails" and it basically describes in detail the various types of tests in rails one might encounter while developing a typical rails application. There are four components central to testing in rails: Fixtures, Unit tests, Functional tests, Integration tests and Performance tests. These have been described below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem 'memory_test_fix' which basically (monkey) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they otherwise would if they were to read/write all their results to files (on the disk) and also because it will eliminate file locking issues on the test database when running on Windows. This is in no way a requirement, but it improves the speed of testing and development which is ultimately desirable. This is especially good for testing because one usually does not need the data after the test is done, but only during the lifetime of the test.

Make the following change to the 'config/database.yml' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the 'database:' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one on memory and not an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails generate model is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the "key: value" format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called ':cookie' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that ones default-generated by scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==
Unit tests are used to test the models. Thus any tests that deal with the validation of data in a model are to be done in Unit tests. It is good practice to have one test for every kind of validation present so the everything that could potentially break has been tested. Models contain most of the business logic, hence the unit tests need to test all the individual methods present in the models too.

When models are generated (either using the 'generate' command or by using scaffolds), default Unit test are generated alongside. These tests by no means contain any functionality in and of themselves, but are merely placeholders that provide a framework upon which one can write their own tests. Such test stubs are created in the test/unit folder. Almost all tests, be it Unit tests or Integration tests require 'test_helper' which specifies the default configuration of our tests.

Consider the CookBook example in which the model 'recipe' validated the presence of its attributes 'title', 'description', 'instructions' and 'category'. Since this validation ensures that none of the fields can be empty, creation of an empty recipe should be invalid. A Unit test that does just this is given below:
<pre>
test 'should require all fields' do
r = recipe.new
assert_false r.valid?
end
</pre>
A blank recipe should be invalidated by the model which is what assert_false checks for. This test would pass if r.valid? is false i.e. model does not accept an empty recipe.

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if methods of a controller are working correctly. Since controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, that users are getting authenticated correctly, that the content displayed on the page is correct etc. Functional tests are also used to test the View because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionality can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a absic idea of what the test does. In this case, "should use layout" implies that this test checks the layout of the page. The gist of this test is that it GET's the index page (corresponding to view of this controller), ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is "Online CookBook". <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example would be that of a shopping cart application. Even though different phases of the application may work correctly while integration testing one might realize that the 'add to cart' button is absent in the product-catalog although the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such ''Behavioral-Driven-Development'' goes hand in hand with ''Test-Driven-Development'' and helps in removing the ambiguities often associated with Customer Requirements.

An Example:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedite the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration written must ''require 'test_helper' ''. This is basically a ''mixin'', so one still has the capability to access all the low-level GET/POST commands in Test-Unit.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==
Performance tests as the name indicates are used to gauge the performance of the system and play a very important role in software development for the simple reason that as a developer, one does not want the end user to have a poor experience while using the application. Users do not want to wait long for pages to load and elements on the page to respond. They are not - and should not - be concerned with the capability of the system to handle large loads, scale to accommodate increased volumes of traffic etc. Such details are abstracted away from the user, but they ''do'' have a significant impact on user's interaction with the system.

Rails Performance test can be categorized as a special type of integration tests, which are designed for bench-marking and profiling the test code. In these tests, one can mention how many connections are to be simulated to the server etc. at the outcome of which it would be possible to identify the performance bottlenecks and hopefully pinpoint the source of speed and/or memory problems.

Detailed examples can be found [http://guides.rubyonrails.org/performance_testing.html#examples Here].

==Conclusion==
Testing is an indispensable an inevitable part of development in rails and must be fully exploited to avail the benefits associated with Test-Driven-Development, if for the simple reason that rails provides an excellent in-built framework upon which writing tests is a highly natural and intuitive process. There are many advantages to testing and [http://www.learn.geekinterview.com/programming/ruby/ruby-on-rails-application-testing.html entire articles] have been written that emphasize this point.

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-20T07:38:55Z

Sshyamr: /* Conclusion */

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of Lecture 10 "Testing in Rails" and it basically describes in detail the various types of tests in rails one might encounter while developing a typical rails application. There are four components central to testing in rails: Fixtures, Unit tests, Functional Tests, Integration Tests and Performance tests. These have been describes below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem 'memory_test_fix' which basically (monkey) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they otherwise would if they were to read/write all their results to files (on the disk) and also because it will eliminate file locking issues on the test database when running on Windows. This is in no way a requirement, but it improves the speed of testing and development which is ultimately desirable. This is especially good for testing because one usually does not need the data after the test is done, but only during the lifetime of the test.

Make the following change to the 'config/database.yml' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the 'database:' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one on memory and not an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails generate model is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the "key: value" format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called ':cookie' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that ones default-generated by scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==
Unit tests are used to test the models. Thus any tests that deal with the validation of data in a model are to be done in Unit tests. It is good practice to have one test for every kind of validation present so the everything that could potentially break has been tested. Models contain most of the business logic, hence the unit tests need to test all the individual methods present in the models too.

When models are generated (either using the 'generate' command or by using scaffolds), default Unit test are generated alongside. These tests by no means contain any functionality in and of themselves, but are merely placeholders that provide a framework upon which one can write their own tests. Such test stubs are created in the test/unit folder. Almost all tests, be it Unit tests or Integration tests require 'test_helper' which specifies the default configuration of our tests.

Consider the CookBook example in which the model 'recipe' validated the presence of its attributes 'title', 'description', 'instructions' and 'category'. Since this validation ensures that none of the fields can be empty, creation of an empty recipe should be invalid. A Unit test that does just this is given below:
<pre>
test 'should require all fields' do
r = recipe.new
assert_false r.valid?
end
</pre>
A blank recipe should be invalidated by the model which is what assert_false checks for. This test would pass if r.valid? is false i.e. model does not accept an empty recipe.

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if methods of a controller are working correctly. Since controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, that users are getting authenticated correctly, that the content displayed on the page is correct etc. Functional tests are also used to test the View because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionality can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a absic idea of what the test does. In this case, "should use layout" implies that this test checks the layout of the page. The gist of this test is that it GET's the index page (corresponding to view of this controller), ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is "Online CookBook". <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example would be that of a shopping cart application. Even though different phases of the application may work correctly while integration testing one might realize that the 'add to cart' button is absent in the product-catalog although the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such ''Behavioral-Driven-Development'' goes hand in hand with ''Test-Driven-Development'' and helps in removing the ambiguities often associated with Customer Requirements.

An Example:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedite the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration written must ''require 'test_helper' ''. This is basically a ''mixin'', so one still has the capability to access all the low-level GET/POST commands in Test-Unit.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==
Performance tests as the name indicates are used to gauge the performance of the system and play a very important role in software development for the simple reason that as a developer, one does not want the end user to have a poor experience while using the application. Users do not want to wait long for pages to load and elements on the page to respond. They are not - and should not - be concerned with the capability of the system to handle large loads, scale to accommodate increased volumes of traffic etc. Such details are abstracted away from the user, but they ''do'' have a significant impact on user's interaction with the system.

Rails Performance test can be categorized as a special type of integration tests, which are designed for bench-marking and profiling the test code. In these tests, one can mention how many connections are to be simulated to the server etc. at the outcome of which it would be possible to identify the performance bottlenecks and hopefully pinpoint the source of speed and/or memory problems.

Detailed examples can be found [http://guides.rubyonrails.org/performance_testing.html#examples Here].

==Conclusion==
Testing is an indispensable an inevitable part of development in rails and must be fully exploited to avail the benefits associated with Test-Driven-Development, if for the simple reason that rails provides an excellent in-built framework upon which writing tests is a highly natural and intuitive process. There are many advantages to testing and [http://www.learn.geekinterview.com/programming/ruby/ruby-on-rails-application-testing.html entire articles] have been written that emphasize this point.

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-20T07:30:40Z

Sshyamr: /* Performance Tests */

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of Lecture 10 "Testing in Rails" and it basically describes in detail the various types of tests in rails one might encounter while developing a typical rails application. There are four components central to testing in rails: Fixtures, Unit tests, Functional Tests, Integration Tests and Performance tests. These have been describes below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem 'memory_test_fix' which basically (monkey) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they otherwise would if they were to read/write all their results to files (on the disk) and also because it will eliminate file locking issues on the test database when running on Windows. This is in no way a requirement, but it improves the speed of testing and development which is ultimately desirable. This is especially good for testing because one usually does not need the data after the test is done, but only during the lifetime of the test.

Make the following change to the 'config/database.yml' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the 'database:' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one on memory and not an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails generate model is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the "key: value" format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called ':cookie' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that ones default-generated by scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==
Unit tests are used to test the models. Thus any tests that deal with the validation of data in a model are to be done in Unit tests. It is good practice to have one test for every kind of validation present so the everything that could potentially break has been tested. Models contain most of the business logic, hence the unit tests need to test all the individual methods present in the models too.

When models are generated (either using the 'generate' command or by using scaffolds), default Unit test are generated alongside. These tests by no means contain any functionality in and of themselves, but are merely placeholders that provide a framework upon which one can write their own tests. Such test stubs are created in the test/unit folder. Almost all tests, be it Unit tests or Integration tests require 'test_helper' which specifies the default configuration of our tests.

Consider the CookBook example in which the model 'recipe' validated the presence of its attributes 'title', 'description', 'instructions' and 'category'. Since this validation ensures that none of the fields can be empty, creation of an empty recipe should be invalid. A Unit test that does just this is given below:
<pre>
test 'should require all fields' do
r = recipe.new
assert_false r.valid?
end
</pre>
A blank recipe should be invalidated by the model which is what assert_false checks for. This test would pass if r.valid? is false i.e. model does not accept an empty recipe.

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if methods of a controller are working correctly. Since controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, that users are getting authenticated correctly, that the content displayed on the page is correct etc. Functional tests are also used to test the View because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionality can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a absic idea of what the test does. In this case, "should use layout" implies that this test checks the layout of the page. The gist of this test is that it GET's the index page (corresponding to view of this controller), ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is "Online CookBook". <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example would be that of a shopping cart application. Even though different phases of the application may work correctly while integration testing one might realize that the 'add to cart' button is absent in the product-catalog although the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such ''Behavioral-Driven-Development'' goes hand in hand with ''Test-Driven-Development'' and helps in removing the ambiguities often associated with Customer Requirements.

An Example:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedite the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration written must ''require 'test_helper' ''. This is basically a ''mixin'', so one still has the capability to access all the low-level GET/POST commands in Test-Unit.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==
Performance tests as the name indicates are used to gauge the performance of the system and play a very important role in software development for the simple reason that as a developer, one does not want the end user to have a poor experience while using the application. Users do not want to wait long for pages to load and elements on the page to respond. They are not - and should not - be concerned with the capability of the system to handle large loads, scale to accommodate increased volumes of traffic etc. Such details are abstracted away from the user, but they ''do'' have a significant impact on user's interaction with the system.

Rails Performance test can be categorized as a special type of integration tests, which are designed for bench-marking and profiling the test code. In these tests, one can mention how many connections are to be simulated to the server etc. at the outcome of which it would be possible to identify the performance bottlenecks and hopefully pinpoint the source of speed and/or memory problems.

Detailed examples can be found [http://guides.rubyonrails.org/performance_testing.html#examples Here].

==Conclusion==

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-20T07:09:41Z

Sshyamr: /* Introduction */

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of Lecture 10 "Testing in Rails" and it basically describes in detail the various types of tests in rails one might encounter while developing a typical rails application. There are four components central to testing in rails: Fixtures, Unit tests, Functional Tests, Integration Tests and Performance tests. These have been describes below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem 'memory_test_fix' which basically (monkey) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they otherwise would if they were to read/write all their results to files (on the disk) and also because it will eliminate file locking issues on the test database when running on Windows. This is in no way a requirement, but it improves the speed of testing and development which is ultimately desirable. This is especially good for testing because one usually does not need the data after the test is done, but only during the lifetime of the test.

Make the following change to the 'config/database.yml' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the 'database:' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one on memory and not an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails generate model is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the "key: value" format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called ':cookie' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that ones default-generated by scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==
Unit tests are used to test the models. Thus any tests that deal with the validation of data in a model are to be done in Unit tests. It is good practice to have one test for every kind of validation present so the everything that could potentially break has been tested. Models contain most of the business logic, hence the unit tests need to test all the individual methods present in the models too.

When models are generated (either using the 'generate' command or by using scaffolds), default Unit test are generated alongside. These tests by no means contain any functionality in and of themselves, but are merely placeholders that provide a framework upon which one can write their own tests. Such test stubs are created in the test/unit folder. Almost all tests, be it Unit tests or Integration tests require 'test_helper' which specifies the default configuration of our tests.

Consider the CookBook example in which the model 'recipe' validated the presence of its attributes 'title', 'description', 'instructions' and 'category'. Since this validation ensures that none of the fields can be empty, creation of an empty recipe should be invalid. A Unit test that does just this is given below:
<pre>
test 'should require all fields' do
r = recipe.new
assert_false r.valid?
end
</pre>
A blank recipe should be invalidated by the model which is what assert_false checks for. This test would pass if r.valid? is false i.e. model does not accept an empty recipe.

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if methods of a controller are working correctly. Since controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, that users are getting authenticated correctly, that the content displayed on the page is correct etc. Functional tests are also used to test the View because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionality can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a absic idea of what the test does. In this case, "should use layout" implies that this test checks the layout of the page. The gist of this test is that it GET's the index page (corresponding to view of this controller), ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is "Online CookBook". <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example would be that of a shopping cart application. Even though different phases of the application may work correctly while integration testing one might realize that the 'add to cart' button is absent in the product-catalog although the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such ''Behavioral-Driven-Development'' goes hand in hand with ''Test-Driven-Development'' and helps in removing the ambiguities often associated with Customer Requirements.

An Example:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedite the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration written must ''require 'test_helper' ''. This is basically a ''mixin'', so one still has the capability to access all the low-level GET/POST commands in Test-Unit.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==

==Conclusion==

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-20T07:08:53Z

Sshyamr: /* Integration Tests */

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of Lecture 10 "Testing in Rails" and it basically describes in detail the various types of tests in rails one encounters while developing a typical rails app. There are four components central to testing in rails: Fixtures, Unit tests, Functional Tests, Integration Tests and Performance tests. These have been describes below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem 'memory_test_fix' which basically (monkey) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they otherwise would if they were to read/write all their results to files (on the disk) and also because it will eliminate file locking issues on the test database when running on Windows. This is in no way a requirement, but it improves the speed of testing and development which is ultimately desirable. This is especially good for testing because one usually does not need the data after the test is done, but only during the lifetime of the test.

Make the following change to the 'config/database.yml' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the 'database:' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one on memory and not an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails generate model is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the "key: value" format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called ':cookie' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that ones default-generated by scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==
Unit tests are used to test the models. Thus any tests that deal with the validation of data in a model are to be done in Unit tests. It is good practice to have one test for every kind of validation present so the everything that could potentially break has been tested. Models contain most of the business logic, hence the unit tests need to test all the individual methods present in the models too.

When models are generated (either using the 'generate' command or by using scaffolds), default Unit test are generated alongside. These tests by no means contain any functionality in and of themselves, but are merely placeholders that provide a framework upon which one can write their own tests. Such test stubs are created in the test/unit folder. Almost all tests, be it Unit tests or Integration tests require 'test_helper' which specifies the default configuration of our tests.

Consider the CookBook example in which the model 'recipe' validated the presence of its attributes 'title', 'description', 'instructions' and 'category'. Since this validation ensures that none of the fields can be empty, creation of an empty recipe should be invalid. A Unit test that does just this is given below:
<pre>
test 'should require all fields' do
r = recipe.new
assert_false r.valid?
end
</pre>
A blank recipe should be invalidated by the model which is what assert_false checks for. This test would pass if r.valid? is false i.e. model does not accept an empty recipe.

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if methods of a controller are working correctly. Since controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, that users are getting authenticated correctly, that the content displayed on the page is correct etc. Functional tests are also used to test the View because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionality can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a absic idea of what the test does. In this case, "should use layout" implies that this test checks the layout of the page. The gist of this test is that it GET's the index page (corresponding to view of this controller), ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is "Online CookBook". <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example would be that of a shopping cart application. Even though different phases of the application may work correctly while integration testing one might realize that the 'add to cart' button is absent in the product-catalog although the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such ''Behavioral-Driven-Development'' goes hand in hand with ''Test-Driven-Development'' and helps in removing the ambiguities often associated with Customer Requirements.

An Example:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedite the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration written must ''require 'test_helper' ''. This is basically a ''mixin'', so one still has the capability to access all the low-level GET/POST commands in Test-Unit.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==

==Conclusion==

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-20T07:08:25Z

Sshyamr: /* Functional Tests */

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of Lecture 10 "Testing in Rails" and it basically describes in detail the various types of tests in rails one encounters while developing a typical rails app. There are four components central to testing in rails: Fixtures, Unit tests, Functional Tests, Integration Tests and Performance tests. These have been describes below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem 'memory_test_fix' which basically (monkey) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they otherwise would if they were to read/write all their results to files (on the disk) and also because it will eliminate file locking issues on the test database when running on Windows. This is in no way a requirement, but it improves the speed of testing and development which is ultimately desirable. This is especially good for testing because one usually does not need the data after the test is done, but only during the lifetime of the test.

Make the following change to the 'config/database.yml' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the 'database:' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one on memory and not an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails generate model is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the "key: value" format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called ':cookie' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that ones default-generated by scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==
Unit tests are used to test the models. Thus any tests that deal with the validation of data in a model are to be done in Unit tests. It is good practice to have one test for every kind of validation present so the everything that could potentially break has been tested. Models contain most of the business logic, hence the unit tests need to test all the individual methods present in the models too.

When models are generated (either using the 'generate' command or by using scaffolds), default Unit test are generated alongside. These tests by no means contain any functionality in and of themselves, but are merely placeholders that provide a framework upon which one can write their own tests. Such test stubs are created in the test/unit folder. Almost all tests, be it Unit tests or Integration tests require 'test_helper' which specifies the default configuration of our tests.

Consider the CookBook example in which the model 'recipe' validated the presence of its attributes 'title', 'description', 'instructions' and 'category'. Since this validation ensures that none of the fields can be empty, creation of an empty recipe should be invalid. A Unit test that does just this is given below:
<pre>
test 'should require all fields' do
r = recipe.new
assert_false r.valid?
end
</pre>
A blank recipe should be invalidated by the model which is what assert_false checks for. This test would pass if r.valid? is false i.e. model does not accept an empty recipe.

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if methods of a controller are working correctly. Since controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, that users are getting authenticated correctly, that the content displayed on the page is correct etc. Functional tests are also used to test the View because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionality can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a absic idea of what the test does. In this case, "should use layout" implies that this test checks the layout of the page. The gist of this test is that it GET's the index page (corresponding to view of this controller), ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is "Online CookBook". <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example would be that of a shopping cart application. Even though different phases of the application may work correctly while integration testing one might realize that the 'add to cart' button is absent in the product-catalog although the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such ''Behavioral-Driven-Development'' goes hand in hand with ''Test-Driven-Development'' and helps in removing the ambiguities often associated with Customer Requirements.

An Example:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedite the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration written must ''require 'test_helper' ''. This is basically a ''mixin'', so one still has the capability to access all the low-level GET/POST commands in Test-Unit.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==

==Conclusion==

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-20T07:07:55Z

Sshyamr: /* Fixtures */

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of Lecture 10 "Testing in Rails" and it basically describes in detail the various types of tests in rails one encounters while developing a typical rails app. There are four components central to testing in rails: Fixtures, Unit tests, Functional Tests, Integration Tests and Performance tests. These have been describes below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem 'memory_test_fix' which basically (monkey) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they otherwise would if they were to read/write all their results to files (on the disk) and also because it will eliminate file locking issues on the test database when running on Windows. This is in no way a requirement, but it improves the speed of testing and development which is ultimately desirable. This is especially good for testing because one usually does not need the data after the test is done, but only during the lifetime of the test.

Make the following change to the 'config/database.yml' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the 'database:' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one on memory and not an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails generate model is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the "key: value" format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called ':cookie' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that ones default-generated by scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==
Unit tests are used to test the models. Thus any tests that deal with the validation of data in a model are to be done in Unit tests. It is good practice to have one test for every kind of validation present so the everything that could potentially break has been tested. Models contain most of the business logic, hence the unit tests need to test all the individual methods present in the models too.

When models are generated (either using the 'generate' command or by using scaffolds), default Unit test are generated alongside. These tests by no means contain any functionality in and of themselves, but are merely placeholders that provide a framework upon which one can write their own tests. Such test stubs are created in the test/unit folder. Almost all tests, be it Unit tests or Integration tests require 'test_helper' which specifies the default configuration of our tests.

Consider the CookBook example in which the model 'recipe' validated the presence of its attributes 'title', 'description', 'instructions' and 'category'. Since this validation ensures that none of the fields can be empty, creation of an empty recipe should be invalid. A Unit test that does just this is given below:
<pre>
test 'should require all fields' do
r = recipe.new
assert_false r.valid?
end
</pre>
A blank recipe should be invalidated by the model which is what assert_false checks for. This test would pass if r.valid? is false i.e. model does not accept an empty recipe.

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if methods of a controller are working correctly. Since controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, that users are getting authenticated correctly, that the content displayed on the page is correct etc. Functional tests are also used to test the View because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionality can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a absic idea of what the test does. In this case, "should use layout" implies that this test checks the layout of the page. The gist of this test is that it GET's the index page (corresponding to view of this controller), ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is "Online CookBook". <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example would be that of a shopping cart application. Even though different phases of the application may work correctly while integration testing one might realize that the 'add to cart' button is absent in the product-catalog although the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such ''Behavioral-Driven-Development'' goes hand in hand with ''Test-Driven-Development'' and helps in removing the ambiguities often associated with Customer Requirements.

An Example:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedite the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration written must ''require 'test_helper' ''. This is basically a ''mixin'', so one still has the capability to access all the low-level GET/POST commands in Test-Unit.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==

==Conclusion==

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-20T07:07:01Z

Sshyamr: /* Unit Tests */

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of Lecture 10 "Testing in Rails" and it basically describes in detail the various types of tests in rails one encounters while developing a typical rails app. There are four components central to testing in rails: Fixtures, Unit tests, Functional Tests, Integration Tests and Performance tests. These have been describes below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem 'memory_test_fix' which basically (monkey) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they otherwise would if they were to read/write all their results to files (on the disk) and also because it will eliminate file locking issues on the test database when running on Windows. This is in no way a requirement, but it improves the speed of testing and development which is ultimately desirable. This is especially good for testing because one usually does not need the data after the test is done, but only during the lifetime of the test.

Make the following change to the 'config/database.yml' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the 'database:' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one on memory and not an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails generate model is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the "key: value" format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called ':cookie' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<%end%>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that ones default-generated by scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==
Unit tests are used to test the models. Thus any tests that deal with the validation of data in a model are to be done in Unit tests. It is good practice to have one test for every kind of validation present so the everything that could potentially break has been tested. Models contain most of the business logic, hence the unit tests need to test all the individual methods present in the models too.

When models are generated (either using the 'generate' command or by using scaffolds), default Unit test are generated alongside. These tests by no means contain any functionality in and of themselves, but are merely placeholders that provide a framework upon which one can write their own tests. Such test stubs are created in the test/unit folder. Almost all tests, be it Unit tests or Integration tests require 'test_helper' which specifies the default configuration of our tests.

Consider the CookBook example in which the model 'recipe' validated the presence of its attributes 'title', 'description', 'instructions' and 'category'. Since this validation ensures that none of the fields can be empty, creation of an empty recipe should be invalid. A Unit test that does just this is given below:
<pre>
test 'should require all fields' do
r = recipe.new
assert_false r.valid?
end
</pre>
A blank recipe should be invalidated by the model which is what assert_false checks for. This test would pass if r.valid? is false i.e. model does not accept an empty recipe.

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if methods of a controller are working correctly. Since controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, that users are getting authenticated correctly, that the content displayed on the page is correct etc. Functional tests are also used to test the View because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionality can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a absic idea of what the test does. In this case, "should use layout" implies that this test checks the layout of the page. The gist of this test is that it GET's the index page (corresponding to view of this controller), ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is "Online CookBook". <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example would be that of a shopping cart application. Even though different phases of the application may work correctly while integration testing one might realize that the 'add to cart' button is absent in the product-catalog although the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such ''Behavioral-Driven-Development'' goes hand in hand with ''Test-Driven-Development'' and helps in removing the ambiguities often associated with Customer Requirements.

An Example:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedite the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration written must ''require 'test_helper' ''. This is basically a ''mixin'', so one still has the capability to access all the low-level GET/POST commands in Test-Unit.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==

==Conclusion==

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-20T07:06:30Z

Sshyamr:

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of Lecture 10 "Testing in Rails" and it basically describes in detail the various types of tests in rails one encounters while developing a typical rails app. There are four components central to testing in rails: Fixtures, Unit tests, Functional Tests, Integration Tests and Performance tests. These have been describes below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem 'memory_test_fix' which basically (monkey) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they otherwise would if they were to read/write all their results to files (on the disk) and also because it will eliminate file locking issues on the test database when running on Windows. This is in no way a requirement, but it improves the speed of testing and development which is ultimately desirable. This is especially good for testing because one usually does not need the data after the test is done, but only during the lifetime of the test.

Make the following change to the 'config/database.yml' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the 'database:' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one on memory and not an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails generate model is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the "key: value" format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called ':cookie' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<%end%>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that ones default-generated by scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==
Unit tests are used to test the models. Thus any tests that deal with the validation of data in a model are to be done in Unit tests. It is good practice to have one test for every kind of validation present so the everything that could potentially break has been tested. Models contain most of the business logic, hence the unit tests need to test all the individual methods present in the models too.

When models are generated (either using the 'generate' command or by using scaffolds), default Unit test are generated alongside. These tests by no means contain any functionality in and of themselves, but are merely placeholders that provide a framework upon which one can write their own tests. Such test stubs are created in the test/unit folder.

Almost all tests, be it Unit tests or Integration tests require 'test_helper' which specifies the default configuration of our tests.

Consider the CookBook example in which the model 'recipe' validated the presence of its attributes 'title', 'description', 'instructions' and 'category'. Since this validation ensures that none of the fields can be empty, creation of an empty recipe should be invalid. A Unit test that does just this is given below:
<pre>
test 'should require all fields' do
r = recipe.new
assert_false r.valid?
end
</pre>
A blank recipe should be invalidated by the model which is what assert_false checks for. This test would pass if r.valid? is false i.e. model does not accept an empty recipe.

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if methods of a controller are working correctly. Since controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, that users are getting authenticated correctly, that the content displayed on the page is correct etc. Functional tests are also used to test the View because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionality can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a absic idea of what the test does. In this case, "should use layout" implies that this test checks the layout of the page. The gist of this test is that it GET's the index page (corresponding to view of this controller), ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is "Online CookBook". <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example would be that of a shopping cart application. Even though different phases of the application may work correctly while integration testing one might realize that the 'add to cart' button is absent in the product-catalog although the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such ''Behavioral-Driven-Development'' goes hand in hand with ''Test-Driven-Development'' and helps in removing the ambiguities often associated with Customer Requirements.

An Example:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedite the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration written must ''require 'test_helper' ''. This is basically a ''mixin'', so one still has the capability to access all the low-level GET/POST commands in Test-Unit.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==

==Conclusion==

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-20T06:22:47Z

Sshyamr:

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of Lecture 10 "Testing in Rails" and it basically describes in detail the various types of tests in rails one encounters while developing a typical rails app. There are four components central to testing in rails: Fixtures, Unit tests, Functional Tests, Integration Tests and Performance tests. These have been describes below.

==Setup prior to Testing==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem 'memory_test_fix' which basically (monkey) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they otherwise would if they were to read/write all their results to files (on the disk) and also because it will eliminate file locking issues on the test database when running on Windows. This is in no way a requirement, but it improves the speed of testing and development which is ultimately desirable. This is especially good for testing because one usually does not need the data after the test is done, but only during the lifetime of the test.

Make the following change to the 'config/database.yml' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the 'database:' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>

This now ensures that for all the tests, the database used will be the one on memory and not an actual Sqlite database.

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails generate model is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the "key: value" format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called ':cookie' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<%end%>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that ones default-generated by scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Tests==

==Functional Tests==
Fundamentally, these tests are used for testing the 'functionality' of the various components of a controller. So typically, one has as many functional tests as there are controllers. The basic purpose of writing functional tests is to check if methods of a controller are working correctly. Since controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, that users are getting authenticated correctly, that the content displayed on the page is correct etc. Functional tests are also used to test the View because controllers and views are tightly coupled in rails. This tight coupling is evident by the fact that instance variables in the controller are available to the view. Hence, view related functionality can also be tested in functional tests e.g. the most common kind of view test would be checking that the title of a web page is displayed correctly.

An example of a functional test:
<pre>
test “should use layout” do
get :index
assert_response :success
assert_select ‘title’, ‘Online Cookbook’
end
</pre>
In rails the title of the test gives you a absic idea of what the test does. In this case, "should use layout" implies that this test checks the layout of the page. The gist of this test is that it GET's the index page (corresponding to view of this controller), ensures that the page is rendered correctly with the mothod: <pre> assert_response </pre>Finally it checks that the title of the page is "Online CookBook". <pre> assert_select </pre> This method allows you to select the value of a particular tag from html - in this case the title tag.

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example would be that of a shopping cart application. Even though different phases of the application may work correctly while integration testing one might realize that the 'add to cart' button is absent in the product-catalog although the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such ''Behavioral-Driven-Development'' goes hand in hand with ''Test-Driven-Development'' and helps in removing the ambiguities often associated with Customer Requirements.

An Example:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedite the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration written must ''require 'test_helper' ''. This is basically a ''mixin'', so one still has the capability to access all the low-level GET/POST commands in Test-Unit.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==

==Conclusion==

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-20T05:44:36Z

Sshyamr:

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-18T19:41:48Z

Sshyamr:

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
== Introduction ==
This article covers testing in rails which is the content of Lecture 10.
There are four components central to testing in rails: Fixtures, Unit tests, Functional Tests, Integration Tests and Performance tests.

==Fixtures==

CSC/ECE 517 Fall 2011

2011-10-18T19:19:16Z

Sshyamr:

[[Link title]]
*[[CSC/ECE 517 Fall 2011/ch1 1a ms]]

*[[CSC/ECE 517 Fall 2011/ch1 1a cs]]

*[[CSC/ECE 517 Fall 2011/ch1 1a ri]]

*[[CSC/ECE 517 Fall 2011/ch1 1a lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1b sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1b ds]]

*[[CSC/ECE 517 Fall 2011/ch1 1b tj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c cm]]

*[[CSC/ECE 517 Fall 2011/ch1 1c sj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c ka]]

*[[CSC/ECE 517 Fall 2011/ch1 1d sr]]

*[[CSC/ECE 517 Fall 2011/ch1 1e vs]]

*[[CSC/ECE 517 Fall 2011/ch1 1e aa]]

*[[CSC/ECE 517 Fall 2011/ch1 1a sc]]

*[[CSC/ECE 517 Fall 2011/ch1 1e dm]]

*[[CSC/ECE 517 Fall 2011/ch1 1e an]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1e lm]]

*[[CSC/ECE 517 Fall 2011/ch1 1g vn]]

*[[CSC/ECE 517 Fall 2011/ch1 1f rs]]

*[[CSC/ECE 517 Fall 2011/ch1 1f sv]]

*[[CSC/ECE 517 Fall 2011/ch1 1g jn]]

*[[CSC/ECE 517 Fall 2011/ch1 1h ps]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sm]]

*[[CSC/ECE 517 Fall 2011/ch1 1i zf]]

*[[CSC/ECE 517 Fall 2011/ch1 1g rn]]

*[[CSC/ECE 517 Fall 2011/ch1 1i cl]]

*[[CSC/ECE 517 Fall 2011/ch1 1d ss]]

*[[CSC/ECE 517 Fall 2011/ch1 1i lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1h hs]]

*[[CSC/ECE 517 Fall 2011/ch1 1d gs]]

*[[CSC/ECE 517 Fall 2011/ch1 2b ns]]

*[[CSC/ECE 517 Fall 2011/ch1 2b jp]]

*[[CSC/ECE 517 Fall 2011/ch1 2a av]]

*[[CSC/ECE 517 Fall 2011/ch2 2f jm]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ad]]

*[[CSC/ECE 517 Fall 2011/ch2 2e kt]]

*[[CSC/ECE 517 Fall 2011/ch2 2e gp]]

*[[CSC/ECE 517 Fall 2011/ch1 2b qu]]

*[[CSC/ECE 517 Fall 2011/ch2 2c bs]]

*[[CSC/ECE 517 Fall 2011/ch1 2c rs]]

*[[CSC/ECE 517 Fall 2011/ch1 2a ca]]

*[[CSC/ECE 517 Fall 2011/ch1 2b rv]]

*[[CSC/ECE 517 Fall 2011/ch2 2c ds]]

*[[CSC/ECE 517 Fall 2011/ch2 2b sa]]

*[[CSC/ECE 517 Fall 2011/ch2 2f vh]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ps]]

*[[CSC/ECE 517 Fall 2011/ch3 3a oe]]

*[[CSC/ECE 517 Fall 2011/ch3 3h rr]]

*[[CSC/ECE 517 Fall 2011/ch3 3h ss]]

*[[CSC/ECE 517 Fall 2011/ch3 4b js]]

*[[CSC/ECE 517 Fall 2011/ch3 4b ms]]

*[[CSC/ECE 517 Fall 2011/ch4 4i aa]]

*[[CSC/ECE 517 Fall 2011/ch4 4i sd]]

*[[CSC/ECE 517 Fall 2011/ch4 4d mt]]

*[[CSC/ECE 517 Fall 2011/ch4 4d ls]]

*[[CSC/ECE 517 Fall 2011/ch4 4d ch]]

*[[CSC/ECE 517 Fall 2011/ch4 4c ap]]

*[[CSC/ECE 517 Fall 2011/ch4 4h sv]]

*[[CSC/ECE 517 Fall 2011/ch4 4e cl]]

*[[CSC/ECE 517 Fall 2011/ch4 4a ga]]

*[[CSC/ECE 517 Fall 2011/ch4 4f sl]]

*[[CSC/ECE 517 Fall 2011/ch4 4i js]]

*[[CSC/ECE 517 Fall 2011/ch4 4f ss]]

*[[trial]]

CSC/ECE 517 Fall 2011

2011-10-18T19:18:31Z

Sshyamr:

[[Link title]]
*[[CSC/ECE 517 Fall 2011/ch1 1a ms]]

*[[CSC/ECE 517 Fall 2011/ch1 1a cs]]

*[[CSC/ECE 517 Fall 2011/ch1 1a ri]]

*[[CSC/ECE 517 Fall 2011/ch1 1a lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1b sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1b ds]]

*[[CSC/ECE 517 Fall 2011/ch1 1b tj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c cm]]

*[[CSC/ECE 517 Fall 2011/ch1 1c sj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c ka]]

*[[CSC/ECE 517 Fall 2011/ch1 1d sr]]

*[[CSC/ECE 517 Fall 2011/ch1 1e vs]]

*[[CSC/ECE 517 Fall 2011/ch1 1e aa]]

*[[CSC/ECE 517 Fall 2011/ch1 1a sc]]

*[[CSC/ECE 517 Fall 2011/ch1 1e dm]]

*[[CSC/ECE 517 Fall 2011/ch1 1e an]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1e lm]]

*[[CSC/ECE 517 Fall 2011/ch1 1g vn]]

*[[CSC/ECE 517 Fall 2011/ch1 1f rs]]

*[[CSC/ECE 517 Fall 2011/ch1 1f sv]]

*[[CSC/ECE 517 Fall 2011/ch1 1g jn]]

*[[CSC/ECE 517 Fall 2011/ch1 1h ps]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sm]]

*[[CSC/ECE 517 Fall 2011/ch1 1i zf]]

*[[CSC/ECE 517 Fall 2011/ch1 1g rn]]

*[[CSC/ECE 517 Fall 2011/ch1 1i cl]]

*[[CSC/ECE 517 Fall 2011/ch1 1d ss]]

*[[CSC/ECE 517 Fall 2011/ch1 1i lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1h hs]]

*[[CSC/ECE 517 Fall 2011/ch1 1d gs]]

*[[CSC/ECE 517 Fall 2011/ch1 2b ns]]

*[[CSC/ECE 517 Fall 2011/ch1 2b jp]]

*[[CSC/ECE 517 Fall 2011/ch1 2a av]]

*[[CSC/ECE 517 Fall 2011/ch2 2f jm]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ad]]

*[[CSC/ECE 517 Fall 2011/ch2 2e kt]]

*[[CSC/ECE 517 Fall 2011/ch2 2e gp]]

*[[CSC/ECE 517 Fall 2011/ch1 2b qu]]

*[[CSC/ECE 517 Fall 2011/ch2 2c bs]]

*[[CSC/ECE 517 Fall 2011/ch1 2c rs]]

*[[CSC/ECE 517 Fall 2011/ch1 2a ca]]

*[[CSC/ECE 517 Fall 2011/ch1 2b rv]]

*[[CSC/ECE 517 Fall 2011/ch2 2c ds]]

*[[CSC/ECE 517 Fall 2011/ch2 2b sa]]

*[[CSC/ECE 517 Fall 2011/ch2 2f vh]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ps]]

*[[CSC/ECE 517 Fall 2011/ch3 3a oe]]

*[[CSC/ECE 517 Fall 2011/ch3 3h rr]]

*[[CSC/ECE 517 Fall 2011/ch3 3h ss]]

*[[CSC/ECE 517 Fall 2011/ch3 4b js]]

*[[CSC/ECE 517 Fall 2011/ch3 4b ms]]

*[[CSC/ECE 517 Fall 2011/ch4 4i aa]]

*[[CSC/ECE 517 Fall 2011/ch4 4i sd]]

*[[CSC/ECE 517 Fall 2011/ch4 4d mt]]

*[[CSC/ECE 517 Fall 2011/ch4 4d ls]]

*[[CSC/ECE 517 Fall 2011/ch4 4d ch]]

*[[CSC/ECE 517 Fall 2011/ch4 4c ap]]

*[[CSC/ECE 517 Fall 2011/ch4 4h sv]]

*[[CSC/ECE 517 Fall 2011/ch4 4e cl]]

*[[CSC/ECE 517 Fall 2011/ch4 4e gs]]

*[[CSC/ECE 517 Fall 2011/ch4 4a ga]]

*[[CSC/ECE 517 Fall 2011/ch4 4f sl]]

*[[CSC/ECE 517 Fall 2011/ch4 4i js]]

*[[CSC/ECE 517 Fall 2011/ch4 4f ss]]

*[[trial]]

CSC/ECE 517 Fall 2011/ch4 4e gs

2011-10-18T19:17:15Z

Sshyamr: Created page with "PlaceHolder"

PlaceHolder

CSC/ECE 517 Fall 2011/ch1 2b ns

2011-09-30T23:11:44Z

Sshyamr: /* Ruby : The send method */

<h2>Access Control in Object-Oriented Languages</h2>

== Introduction ==
A fundamental precept of O-O systems is that an object should not expose any of its implementation details. In other words, access to an object’s functionality must be tightly regulated. The access control policies of any object-oriented language specify the rules and capabilities for enforcing this regulation. Thus, the concept of Access control ties in deeply with the underlying principles of [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming].

__TOC__
==Purpose of Access Control==
Object-oriented programming fundamentally revolves around the principle of Data Hiding and Encapsulation. In a nutshell, [http://en.wikipedia.org/wiki/Information_hiding Data Hiding] is the practice of securing data by constraining access to it, and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] ensures that the secure data (and the respective member functions) are bundled together as an individual module. All object oriented languages thus need to control the level of access to their critical data (and functions) which is achieved using ''Access Modifiers'' or ''Access Specifiers'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

The need to strictly control ''who'' can access ''what'' is very crucial in Software development. For example, if you make an instance variable 'public', then you can't change the field as the class evolves over time since you might break any external code that uses the field. This is because outside code having complete access to this field, has tied itself indelibly to the inside implementation of the (former) class and is now closely dependent on it. Changing the said field thus entails changing all the other code that have a dependency on it, which is cumbersome, unwieldy and contrary to the principles of an Object Oriented approach which strives for [http://en.wikipedia.org/wiki/Coupling_(computer_programming) Low Coupling].

Thus, the ‘Implementation hiding principle’ leads to a good acid test of an O-O system's quality: Can you make massive changes to a class definition—even throw out the whole thing and replace it with a completely different implementation—without impacting any of the code that uses that class's objects? This sort of modularization is the central premise of object orientation and makes maintenance much easier. Without implementation hiding, there's little point in using other O-O features. Regulation of access - Access Control - is at the heart of Object oriented programming<ref>http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html</ref>.

==Evolution of Access Control and proliferation of Accessor methods==
Access control has been a part of the OOP movement ever since its inception. [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] is arguably one of first and purest of the many O-O languages and was developed by Xerox PARC in the Learning Research Group in the 1970s <ref>http://www.zdnet.com/blog/murphy/the-tattered-history-of-oop/1157</ref>. Rather than having explicit access specifiers, smalltalk objects operated more in the sense of 'states' i.e. it would hold the 'state' of object(s) which is always private to that object. Any changes required to be made to this state, had to be sent as a request message to that object. This is the most primitive form of access control - having private data members and public member functions - the only difference being that the access levels are not being explicitly specified.

Access control has evolved over time to become highly complicated <ref>http://www.exforsys.com/tutorials/oops/the-use-of-access-specifiers-in-object-oriented-programming.html</ref> because the requirements of computing and software development have ballooned considerably in last decade and a half. Complex software requirements mandates complexity in languages, and this has indeed affected the access control policies, which have evolved into something comprehensive, yet - at times - convoluted. Unfortunately today's developers often lose sight of the fundamental motivation behind the existence of extensive access control and lose out on much of the benefits of having a highly cohesive, low coupled system <ref>http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref>.

To elaborate, it has become somewhat of an involuntary practice for present programmers to make ''all'' data members of a class private and provide accessor methods (getters/setters) to all of them (data members). Developers have come to accept this to be a contemporary programmatic-paradigm and by supplying setters and getters for ''everything'', defeat the very purpose of making class-fields private. A long time ago programmers discovered that reducing the scope (visibility) of data as much as possible leads to more reliable and maintainable code<ref>http://typicalprogrammer.com/?p=23</ref>.

Every getter and setter in one’s code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters is a sign of a poorly-designed set of classes. Java <ref>http://www.eclipse-blog.org/eclipse-ide/auto-generating-getters-and-setters.html</ref> and C# <ref>http://forums.asp.net/t/941864.aspx/1</ref> developers have IDEs that generate getters and setters automatically, implying that accessors are a good idea and thus contribute to that popular belief. That is not to say that one must completely abstain from accessors, but rather re-analyze and - if required - redesign the class structure to involve as little exposure of its data members as can be achieved.

==Access Control: A typical example==
Empirically, the data members of a class are held private, and the member functions (public) act as the end points of this class. Via these public methods, one can access the ‘state’ of an object. The following example illustrates this point and shows how access to the data members of a class are specified and controlled by the access modifiers.

[http://en.wikipedia.org/wiki/UML_Diagram#Diagrams_overview UML Diagram] of a BankAccount Class.

[[Image:BankAccount_UML.png|650px|thumb|center|Typical UML diagram of BankAccount.]]

The “(-)/(+)” preceding the members of this class represent the associated access levels. (-) indicates private and (+) indicates public.
The data members ‘accountNumber’, ‘routingNumber’ and ‘balance’ are maintained as private. Thus, an instance of a ‘Customer’ Object (say) cannot directly access or modify this data. Customer has to interact with the public behavior bundled in this module which allows him to view his account information and/or withdraw/deposit money i.e. his visibility of the class is only restricted to that which is made public by the Class.

Using such access specifiers, we can control the level of security and visibility associated with the members of a class. Thus, an Access Specifier can be roughly defined as ''‘A keyword applied to a variable, method, etc. that indicates which other parts of the code are permitted to access it’'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

==Common Access Specifiers in O-O languages==

Although all access specifiers essentially provide the same functionality, their semantics differ among different O-O languages. Here is how access control is implemented in some of the more common O-O languages.

===C++===
*'''private''':All members of the Class that are declared as private can only be accessed by the class's member functions and [http://en.wikipedia.org/wiki/Friend_class friends] of the class.
*'''protected''':All members of the Class that are declared as protected can be accessed by that class's member functions and friends (classes or functions) of the class. Moreover, classes derived from the class also have access to these elements.
*'''public''':Any class or method can have access to these type of elements.

===Java===
Java offers four access specifiers, listed below in order of decreasing accessibility:
*'''public''': All public classes, methods, and fields are the least secure. The Public access specifier must be used if you explicitly want to offer access to these entities and if this access cannot do any conceivable harm.
*'''protected''': Protected methods and fields can only be accessed within the same class to which the methods and fields belong, within its subclasses, and within classes present in the same [http://download.oracle.com/javase/tutorial/java/concepts/package.html Package]. Use of protected access specifier thus only allows its fields to be accessed by those classes which have some semblance of correlation to it - be it in the form of subclasses (correlation through inheritance) or classes within the same package (logical and/or functional correlation i.e. classes in the same package have ''something'' logical/functional common to them <ref>http://download.oracle.com/javase/tutorial/java/concepts/package.html</ref>).
*'''default '''(no specifier): Default access specifier is Java’s fail-safe way to handle security. Via the default access specifier, a class, method, or field will be accessible from inside the same package to which the class, method, or field belongs, but not from outside this package. Default access is thus suited when the source code is compartmentalized and organized into packages.
*'''private''': Private access specifier is a way to secure vital members of a class. Private methods and fields can only be accessed within the same class to which the methods and fields belong. Private methods and fields are not visible within subclasses and are not inherited by subclasses.

===Ruby===
Ruby gives you three levels of protection, listed below in order of decreasing accessibility:
*'''public''':Public methods can be called by everyone - no access control is enforced. A class's instance methods are public by default.
*'''protected''':Protected methods can be invoked only by objects of the defining class and its subclasses. Access is kept within the family.
*'''private''':Private methods cannot be called with an explicit receiver - the receiver is always self. Thus private methods can be called only in the context of the current object and cannot be invoked by another object's private methods.

Access control in Ruby is determined [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically], as the program runs, not statically. You will get an access violation only when the code attempts to execute the restricted method<ref>http://rubylearning.com/satishtalim/ruby_access_control.html</ref>.

===C#===
The following access modifiers specify the accessibility levels in C#
*'''public''':Any public method or member can be accessed by any other code in the same or different package.
*'''private''':The method or member can only be accessed from within the same class.
*'''protected''':The method or member can be accessed only from within the same Class or from within any of the subclasses.
*'''internal''':The type or member can be accessed by any code in the same assembly, but not from another assembly. An assembly in C# is the rough equivalent of a package in java.
*'''protected internal''':The type or member can be accessed by any code in the [http://msdn.microsoft.com/en-us/library/ms173099.aspx Assembly] (also see [http://msdn.microsoft.com/en-us/library/ms173099(v=vs.80).aspx this]) in which it is declared, or from within a derived class in another assembly. Access from another assembly must take place within a class declaration that derives from the class in which the protected internal element is declared, and it must take place through an instance of the derived class type.

===Summary of Access Specfiers in C++, Java, Ruby and C#:===
{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Access Level
! C++
! Java
! Ruby
! C#
|-
! Public
| Anything can access
| Anything can access
| Anything can access
| Anything can access
|-
! Protected
| Class, Subclasses and friends
| Class, Subclasses and classes of same package
| Class and Subclasses
| Class and Subclasses
|-
! Private
| Within Class
| Within Class
| Within Class
| Within Class
|-
! Internal
| --
| --
| --
| Any Class from same Assembly
|-
! Protected internal
| --
| --
| --
| Any Class from same Assembly and Subclass from any Assembly.
|}

==Examples of Access Specifiers==
The following examples exhibit the use of the access specifiers and getter methods for the aforementioned Bank Account example.

===C++===
<pre>
class BankAccount {
private:
char routingNumber;
char accountNumber;

protected:
int balance;

public:
BankAccount(char *, char *);
void changeAccountNumber(char *);
void changeRoutingNumber(char *);
void depositMoney(int);
void withdrawMoney(int);
friend void displayAccountInfo();
}

BankAccount::BankAccount(char *rNo, char *accNo) {
Strcpy(routingNumber, rNo);
Strcpy(accountNumber, accNo);
balance = 0;
}

BankAccount::void changeAccountNumber(char *accNo){
Strcpy(accountNumber, accNo);
}

BankAccount::void changeRoutingNumber(char *rNo){
Strcpy(routingNumber, rNo);
}

BankAccount::void depositMoney(int amount) {
balance += amount;
}

BankAccount::void withdrawMoney(int amount) {
balance -= amount;
}

// Friend function can access both the private and protected members
// of BankAccount.
void displayAccountInfo(BankAccount ba) {
cout << “Account Number: ” << ba.accountNumber << endl;
cout << “Routing Number: ” << ba.routingNumber << endl;
cout << “Account Balance: ” << ba.balance << endl << endl;
}

// CheckingAccount inherits from BankAccount. Hence it can access only the
// public and protected members of BankAccount. It cannot access the private
// members of BankAccount.
class CheckingAccount: public BankAccount {
private:
char accountType[20];

public:
CheckingAccount(char *, char *);
void resetBalance();
}

CheckingAccount::CheckingAccount(char *rNo, char *accNo) {
Strcpy(accountType, "Checking");
changeRoutingNumber(rNo);
changeAccountNumber (accNo);
balance = 0;
}

// Since balance is a protected field, it can be accessed by CheckingAccount
CheckingAccount::void resetBalance() {
balance = 0;
}

int main() {
CheckingAccount ca("888", "999");
ca.depositMoney(100);
displayAccountInfo(ca);
ca.withdrawMoney(50);
displayAccountInfo(ca);
ca.resetBalance();
displayAccountInfo(ca);
}

</pre>

<pre>
OUTPUT:

Account Number: 888
Routing Number: 999
Account Balance: 100

Account Number: 888
Routing Number: 999
Account Balance: 50

Account Number: 888
Routing Number: 999
Account Balance: 0
</pre>

The data members routingNumber, accountNumber are made private and balance is protected. This makes it impossible to directly access or change routingNumber, accountNumber from outside code. Access to these attributes are strictly through the public methods changeRoutingNumber() and changeAccountNumber(). However, private and protected members are accessible through friend functions, so displayAccountInfo() function is able to access all the mentioned fields. Since balance is protected, it can be accessed from a subclass (CheckingAccount) directly as shown above. But the private members have to be accessed through the functions changeRoutingNumber() and changeAccountNumber() instead of being accessed directly.

Thus, it purely at the discretion of the programmer to allow access to these data members through such accessor functions. In the absence of such accessors, there would be no way for any code outside the class to view/modify the private attributes.

===Java===

<pre>
public class BankAccount {
String accountNumber;
private String routingNumber;
private Integer balance;

//setter methods for accountNumber allows public acccess to it.
public void setAccountNumber(String acNo){
this.accountNumber=acNo;
}

//setter methods for routingNumber allows public acccess to it.
public void setRoutingNumber(String rtNo){
this.routingNumber=rtNo;
}

//setter methods for balance allows only 'protected' access to it (see definition).
protected void setBalance(Integer bal){
this.balance=bal;
}

// Getter method allows accountNumber to be read publicly
public String getAccountNumber(){
return this.accountNumber;
}

// Getter method allows routingNumber to be read publicly
public String getRoutingNumber(){
return this.routingNumber;
}

// Getter method allows balance to be read only in in a 'protected' fashion (see definition).
protected Integer getBalance(){
return this.balance;
}

public void showAccountNumber(){
System.out.println(this.accountNumber);
}

public void showRoutingNumber(){
System.out.println(this.routingNumber);
}

public void showBalance(){
System.out.println(this.balance);
}

public void withdraw(Integer amount){
this.balance-=amount;
}

public void deposit(Integer amount){
this.balance+=amount;
}

public static void main(String args[]){
BankAccount Steve = new BankAccount();

//public access to setRoutingNumber/getRoutingNumber
Steve.setRoutingNumber("1234");
String steveRtNo=Steve.getRoutingNumber();
System.out.println(steveRtNo);

//protected access to the method setBalance/getBalance
Steve.setBalance(5000);
System.out.println(Steve.getBalance());
}

}
</pre>

Class BankAccount in the above Java code has public getter/setter methods to access the private data member ‘routingNumber’. Thus, we can invoke these methods using an instance of the BankAccount object: Steve.
The methods setBalance()/ getBalance() are protected. As can be seen, they behave like public methods if invoked in the same package. Protected methods act like private methods if invoked by any instance of a class outside the package.
However, if there is a class ‘InternationalBankAccount’ in a different package such that:
<pre>
public class InternationalBankAccount extends BankAccount {
public String internationalBankAccNo;
}
</pre>

<pre>
InternationalBankAccount Anna = new InternationalBankAccount();
Anna.setBalance(10000);
</pre>

The above is a valid syntax and Anna can access protected member functions of the parent class.
Data member ‘accountNumber’ has default access specifier. Default access specifier is used in Java to support package driven development. Thus ‘accountNumber’ can be accessed from anywhere within the package. However no classes from other packages can access ‘accountNumber’.
Data member balance is a private data member and if it is invoked explicitly as follows,
<pre>
Steve.balance=1000;
</pre>
then the output would be an unresolved compilation error of the form:
<pre>
Unresolved compilation problem: The field bankAccount.balance is not visible
</pre>

===Ruby===
The following code illustrates the use of access specifiers in Ruby.
<pre>
class BankAccount

#Instance Variables
def balance
@balance
end

def routingNumber
@routingNumber
end

def accountNumber
@accountNumber
end

#Initialize the instance variables
def initialize(acNo, rtNo, bal)
@accountNumber = acNo
@routingNumber = rtNo
@balance = bal
end

#method to compare protected data member, balance of 2 objects
def compare_balance(other)
if other.balance > balance
"The other object has more bank balance."
else
"This object has more bank balance."
end
end

#access_specifier:class_member_name to define the access control
protected:balance
public:routingNumber
private:accountNumber

end
</pre>

<pre>
#Creating objects and initializing variables
Steve = BankAccount.new(713, 123, 1000)
Anna = BankAccount.new(923, 125, 2000)

#Accessing public data member
puts Steve.routingNumber()

#Comparing protected field: balance of Steve and Anna
puts Steve.compare_balance (Anna)

#Unsuccessful access of private data member raises “NoMethodError”
puts Steve.accountNumber()
</pre>

<pre>
Output:
123
The other object has more bank balance.
NoMethodError: private method `accountNumber' called for #<BankAccount:0x2b75320>
</pre>

‘routingNumber’ is a public function. Thus, when we access object Steve’s public method ‘routing number’, we successfully get ‘123’ as the output.
Furthermore, this snippet provides a mechanism for the comparison of one account holder’s balance with another. This comparison involves a call to the method ‘balance’. The object performing the comparison has to ask the other object to execute its balance method. So, balance cannot be private. With ‘balance’ changed to protected instead of private, Steve can ask Anna to execute ‘balance’, because both are instances of the same class. But if we try to call the ‘balance’ method of a bankAccount object when ‘self’ is anything other than a bankAccount object, the method will fail. A protected method is thus just like a private method, but with the exemption for those cases where the class of ‘self’ and the class of the respective object (having the method called on it) are the same.

The ‘accountNumber’ method is private. Thus user gets a ‘NoMethodError’ on invoking object Steve’s ‘accountNumber’ method. Initialize method in a class is private by default. Whenever the new method is invoked, initialize method is called and instances are created. If we try to invoke the ‘initialize’ method explicitly, we get the same error as in the case when we tried to invoke object Steve’s private ‘accountNumber’ method.

====Ruby : The send method====
The [http://ruby-doc.org/core/classes/Object.html#M000999 send method] of Ruby has always been a potential security leak and has thus been continually revised and changed across the different versions of Ruby. The Ruby send method has been de-mystified to an extent below.

In Ruby calling methods is similar to passing messages to an object. Consider the simple code below:
<pre>
class TestSend
def hello
puts “hello world”
end
public:hello
end
</pre>

Now the hello method of TestSend can be invoked in 2 ways as follows:
<pre>
t = TestSend.new

#Conventional invocation of public methods
t.hello

#Invoking a method using send
t.send :hello
</pre>

Both these ways of calling the hello method prints out "hello world" as expected. Parameters can also be passed while invoking a method using the send method. However in Ruby, using send we can also access the private methods of a class. Consider the following snippet for an illustration. Here we have slightly modified the TestSend class we had defined above.

<pre>
class TestSend
def hello
puts “hello world”
end
private:hello
end
</pre>

The hello method has been changed to private. Lets again consider 2 ways of invoking this private method hello:

<pre>
t=TestSend.new

#Conventional invocation of public methods
t.hello

#Invoking a method using send
t.send :hello
</pre>

As expected 't.hello' results in an 'NoMethodError' whereas 't.send :hello' successfully prints "hello world". Thus, the send method provides a workaround to accessing private member functions of a class. This is a distinction that Ruby possesses in comparison to other O-O languages. The state of send has changed several times as and when versions of Ruby have been released. For a while, Ruby 1.9 changed the implementation of send to only allow public methods to be called, introducing a new 'send!' method which continued to allow private methods to be called. However, this has now been removed from Ruby 1.9 in favour of keeping the functionality of send as is. Instead, a new public_send method has been introduced which will only call public methods <ref>http://deaddeadgood.com/2008/11/17/rubys-send-method/</ref>. Another [http://www.joshstaiger.org/archives/2006/12/the_ruby_send_h.html example].

===C#===
<pre>
class BankAccount
{
public BankAccount(string accountNumber, string routingNumber, int balance)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
this.balance = balance;
}

private string accountNumber;
protected string routingNumber;
private int balance;

// accountNumber is private, so it can only be modified from within this
// class. Also, since the following method is private, it can only be called
// from within this class. So this field is truly private.
private void setAccountNumber(string acNo)
{
this.accountNumber=acNo;
}

// routingNumber is protected, so it can be directly modified by objects of
// a subclass. But the contents of this field are made accessible as public
// so anyone can 'read' the value of this field.
public string getRoutingNumber()
{
return this.routingNumber;
}

// Provides access to modify the private member balance, but this function
// can only be called by subclasses (and from within this class).
protected initBalance()
{
this.balance = 0;
}

// Provides access to 'read' the contents of the private field to everyone.
public void getBalance(int balance)
{
return this.balance;
}
}

class Customer : BankAccount
{
Customer(string accountNumber, string routingNumber)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
initBalance();
}
}

class Startup
{
public static void main()
{
Customer cust = new Customer(“999”, “888”, 100);
System.console.WriteLine(cust.getBalance);
}
}

</pre>

The Customer class inherits from the BankAccount class. All protected data members and methods of BankAccount class are accessible directly by an object of the Customer class. The private fields such as accountNumber and routingNumber are not directly accessible. Thus it is possible to call only the initBalance and getBalance methods from Customer. The initBalance method cannot be called by anyone outside the BankAccount class. Also see [http://www.informit.com/articles/article.aspx?p=101373&seqNum=3 this] for another example.

==Conclusion==
Access control is an integral component of object oriented languages and it underlines and emphasizes some of the principal ideals central to the object-oriented approach. It is possible to maximize the benefits of any O-O language by adhering to, and fully exploiting the capabilities of its access specifiers. Access control is in no way a peripheral add-on or redundant feature of O-O languages, and programmers would only stand to gain by fully appreciating, respecting and understanding their presence.

==References==
<references/>

CSC/ECE 517 Fall 2011/ch1 2b ns

2011-09-30T23:10:59Z

Sshyamr: /* Ruby : The send method */

<h2>Access Control in Object-Oriented Languages</h2>

== Introduction ==
A fundamental precept of O-O systems is that an object should not expose any of its implementation details. In other words, access to an object’s functionality must be tightly regulated. The access control policies of any object-oriented language specify the rules and capabilities for enforcing this regulation. Thus, the concept of Access control ties in deeply with the underlying principles of [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming].

__TOC__
==Purpose of Access Control==
Object-oriented programming fundamentally revolves around the principle of Data Hiding and Encapsulation. In a nutshell, [http://en.wikipedia.org/wiki/Information_hiding Data Hiding] is the practice of securing data by constraining access to it, and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] ensures that the secure data (and the respective member functions) are bundled together as an individual module. All object oriented languages thus need to control the level of access to their critical data (and functions) which is achieved using ''Access Modifiers'' or ''Access Specifiers'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

The need to strictly control ''who'' can access ''what'' is very crucial in Software development. For example, if you make an instance variable 'public', then you can't change the field as the class evolves over time since you might break any external code that uses the field. This is because outside code having complete access to this field, has tied itself indelibly to the inside implementation of the (former) class and is now closely dependent on it. Changing the said field thus entails changing all the other code that have a dependency on it, which is cumbersome, unwieldy and contrary to the principles of an Object Oriented approach which strives for [http://en.wikipedia.org/wiki/Coupling_(computer_programming) Low Coupling].

Thus, the ‘Implementation hiding principle’ leads to a good acid test of an O-O system's quality: Can you make massive changes to a class definition—even throw out the whole thing and replace it with a completely different implementation—without impacting any of the code that uses that class's objects? This sort of modularization is the central premise of object orientation and makes maintenance much easier. Without implementation hiding, there's little point in using other O-O features. Regulation of access - Access Control - is at the heart of Object oriented programming<ref>http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html</ref>.

==Evolution of Access Control and proliferation of Accessor methods==
Access control has been a part of the OOP movement ever since its inception. [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] is arguably one of first and purest of the many O-O languages and was developed by Xerox PARC in the Learning Research Group in the 1970s <ref>http://www.zdnet.com/blog/murphy/the-tattered-history-of-oop/1157</ref>. Rather than having explicit access specifiers, smalltalk objects operated more in the sense of 'states' i.e. it would hold the 'state' of object(s) which is always private to that object. Any changes required to be made to this state, had to be sent as a request message to that object. This is the most primitive form of access control - having private data members and public member functions - the only difference being that the access levels are not being explicitly specified.

Access control has evolved over time to become highly complicated <ref>http://www.exforsys.com/tutorials/oops/the-use-of-access-specifiers-in-object-oriented-programming.html</ref> because the requirements of computing and software development have ballooned considerably in last decade and a half. Complex software requirements mandates complexity in languages, and this has indeed affected the access control policies, which have evolved into something comprehensive, yet - at times - convoluted. Unfortunately today's developers often lose sight of the fundamental motivation behind the existence of extensive access control and lose out on much of the benefits of having a highly cohesive, low coupled system <ref>http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref>.

To elaborate, it has become somewhat of an involuntary practice for present programmers to make ''all'' data members of a class private and provide accessor methods (getters/setters) to all of them (data members). Developers have come to accept this to be a contemporary programmatic-paradigm and by supplying setters and getters for ''everything'', defeat the very purpose of making class-fields private. A long time ago programmers discovered that reducing the scope (visibility) of data as much as possible leads to more reliable and maintainable code<ref>http://typicalprogrammer.com/?p=23</ref>.

Every getter and setter in one’s code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters is a sign of a poorly-designed set of classes. Java <ref>http://www.eclipse-blog.org/eclipse-ide/auto-generating-getters-and-setters.html</ref> and C# <ref>http://forums.asp.net/t/941864.aspx/1</ref> developers have IDEs that generate getters and setters automatically, implying that accessors are a good idea and thus contribute to that popular belief. That is not to say that one must completely abstain from accessors, but rather re-analyze and - if required - redesign the class structure to involve as little exposure of its data members as can be achieved.

==Access Control: A typical example==
Empirically, the data members of a class are held private, and the member functions (public) act as the end points of this class. Via these public methods, one can access the ‘state’ of an object. The following example illustrates this point and shows how access to the data members of a class are specified and controlled by the access modifiers.

[http://en.wikipedia.org/wiki/UML_Diagram#Diagrams_overview UML Diagram] of a BankAccount Class.

[[Image:BankAccount_UML.png|650px|thumb|center|Typical UML diagram of BankAccount.]]

The “(-)/(+)” preceding the members of this class represent the associated access levels. (-) indicates private and (+) indicates public.
The data members ‘accountNumber’, ‘routingNumber’ and ‘balance’ are maintained as private. Thus, an instance of a ‘Customer’ Object (say) cannot directly access or modify this data. Customer has to interact with the public behavior bundled in this module which allows him to view his account information and/or withdraw/deposit money i.e. his visibility of the class is only restricted to that which is made public by the Class.

Using such access specifiers, we can control the level of security and visibility associated with the members of a class. Thus, an Access Specifier can be roughly defined as ''‘A keyword applied to a variable, method, etc. that indicates which other parts of the code are permitted to access it’'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

==Common Access Specifiers in O-O languages==

Although all access specifiers essentially provide the same functionality, their semantics differ among different O-O languages. Here is how access control is implemented in some of the more common O-O languages.

===C++===
*'''private''':All members of the Class that are declared as private can only be accessed by the class's member functions and [http://en.wikipedia.org/wiki/Friend_class friends] of the class.
*'''protected''':All members of the Class that are declared as protected can be accessed by that class's member functions and friends (classes or functions) of the class. Moreover, classes derived from the class also have access to these elements.
*'''public''':Any class or method can have access to these type of elements.

===Java===
Java offers four access specifiers, listed below in order of decreasing accessibility:
*'''public''': All public classes, methods, and fields are the least secure. The Public access specifier must be used if you explicitly want to offer access to these entities and if this access cannot do any conceivable harm.
*'''protected''': Protected methods and fields can only be accessed within the same class to which the methods and fields belong, within its subclasses, and within classes present in the same [http://download.oracle.com/javase/tutorial/java/concepts/package.html Package]. Use of protected access specifier thus only allows its fields to be accessed by those classes which have some semblance of correlation to it - be it in the form of subclasses (correlation through inheritance) or classes within the same package (logical and/or functional correlation i.e. classes in the same package have ''something'' logical/functional common to them <ref>http://download.oracle.com/javase/tutorial/java/concepts/package.html</ref>).
*'''default '''(no specifier): Default access specifier is Java’s fail-safe way to handle security. Via the default access specifier, a class, method, or field will be accessible from inside the same package to which the class, method, or field belongs, but not from outside this package. Default access is thus suited when the source code is compartmentalized and organized into packages.
*'''private''': Private access specifier is a way to secure vital members of a class. Private methods and fields can only be accessed within the same class to which the methods and fields belong. Private methods and fields are not visible within subclasses and are not inherited by subclasses.

===Ruby===
Ruby gives you three levels of protection, listed below in order of decreasing accessibility:
*'''public''':Public methods can be called by everyone - no access control is enforced. A class's instance methods are public by default.
*'''protected''':Protected methods can be invoked only by objects of the defining class and its subclasses. Access is kept within the family.
*'''private''':Private methods cannot be called with an explicit receiver - the receiver is always self. Thus private methods can be called only in the context of the current object and cannot be invoked by another object's private methods.

Access control in Ruby is determined [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically], as the program runs, not statically. You will get an access violation only when the code attempts to execute the restricted method<ref>http://rubylearning.com/satishtalim/ruby_access_control.html</ref>.

===C#===
The following access modifiers specify the accessibility levels in C#
*'''public''':Any public method or member can be accessed by any other code in the same or different package.
*'''private''':The method or member can only be accessed from within the same class.
*'''protected''':The method or member can be accessed only from within the same Class or from within any of the subclasses.
*'''internal''':The type or member can be accessed by any code in the same assembly, but not from another assembly. An assembly in C# is the rough equivalent of a package in java.
*'''protected internal''':The type or member can be accessed by any code in the [http://msdn.microsoft.com/en-us/library/ms173099.aspx Assembly] (also see [http://msdn.microsoft.com/en-us/library/ms173099(v=vs.80).aspx this]) in which it is declared, or from within a derived class in another assembly. Access from another assembly must take place within a class declaration that derives from the class in which the protected internal element is declared, and it must take place through an instance of the derived class type.

===Summary of Access Specfiers in C++, Java, Ruby and C#:===
{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Access Level
! C++
! Java
! Ruby
! C#
|-
! Public
| Anything can access
| Anything can access
| Anything can access
| Anything can access
|-
! Protected
| Class, Subclasses and friends
| Class, Subclasses and classes of same package
| Class and Subclasses
| Class and Subclasses
|-
! Private
| Within Class
| Within Class
| Within Class
| Within Class
|-
! Internal
| --
| --
| --
| Any Class from same Assembly
|-
! Protected internal
| --
| --
| --
| Any Class from same Assembly and Subclass from any Assembly.
|}

==Examples of Access Specifiers==
The following examples exhibit the use of the access specifiers and getter methods for the aforementioned Bank Account example.

===C++===
<pre>
class BankAccount {
private:
char routingNumber;
char accountNumber;

protected:
int balance;

public:
BankAccount(char *, char *);
void changeAccountNumber(char *);
void changeRoutingNumber(char *);
void depositMoney(int);
void withdrawMoney(int);
friend void displayAccountInfo();
}

BankAccount::BankAccount(char *rNo, char *accNo) {
Strcpy(routingNumber, rNo);
Strcpy(accountNumber, accNo);
balance = 0;
}

BankAccount::void changeAccountNumber(char *accNo){
Strcpy(accountNumber, accNo);
}

BankAccount::void changeRoutingNumber(char *rNo){
Strcpy(routingNumber, rNo);
}

BankAccount::void depositMoney(int amount) {
balance += amount;
}

BankAccount::void withdrawMoney(int amount) {
balance -= amount;
}

// Friend function can access both the private and protected members
// of BankAccount.
void displayAccountInfo(BankAccount ba) {
cout << “Account Number: ” << ba.accountNumber << endl;
cout << “Routing Number: ” << ba.routingNumber << endl;
cout << “Account Balance: ” << ba.balance << endl << endl;
}

// CheckingAccount inherits from BankAccount. Hence it can access only the
// public and protected members of BankAccount. It cannot access the private
// members of BankAccount.
class CheckingAccount: public BankAccount {
private:
char accountType[20];

public:
CheckingAccount(char *, char *);
void resetBalance();
}

CheckingAccount::CheckingAccount(char *rNo, char *accNo) {
Strcpy(accountType, "Checking");
changeRoutingNumber(rNo);
changeAccountNumber (accNo);
balance = 0;
}

// Since balance is a protected field, it can be accessed by CheckingAccount
CheckingAccount::void resetBalance() {
balance = 0;
}

int main() {
CheckingAccount ca("888", "999");
ca.depositMoney(100);
displayAccountInfo(ca);
ca.withdrawMoney(50);
displayAccountInfo(ca);
ca.resetBalance();
displayAccountInfo(ca);
}

</pre>

<pre>
OUTPUT:

Account Number: 888
Routing Number: 999
Account Balance: 100

Account Number: 888
Routing Number: 999
Account Balance: 50

Account Number: 888
Routing Number: 999
Account Balance: 0
</pre>

The data members routingNumber, accountNumber are made private and balance is protected. This makes it impossible to directly access or change routingNumber, accountNumber from outside code. Access to these attributes are strictly through the public methods changeRoutingNumber() and changeAccountNumber(). However, private and protected members are accessible through friend functions, so displayAccountInfo() function is able to access all the mentioned fields. Since balance is protected, it can be accessed from a subclass (CheckingAccount) directly as shown above. But the private members have to be accessed through the functions changeRoutingNumber() and changeAccountNumber() instead of being accessed directly.

Thus, it purely at the discretion of the programmer to allow access to these data members through such accessor functions. In the absence of such accessors, there would be no way for any code outside the class to view/modify the private attributes.

===Java===

<pre>
public class BankAccount {
String accountNumber;
private String routingNumber;
private Integer balance;

//setter methods for accountNumber allows public acccess to it.
public void setAccountNumber(String acNo){
this.accountNumber=acNo;
}

//setter methods for routingNumber allows public acccess to it.
public void setRoutingNumber(String rtNo){
this.routingNumber=rtNo;
}

//setter methods for balance allows only 'protected' access to it (see definition).
protected void setBalance(Integer bal){
this.balance=bal;
}

// Getter method allows accountNumber to be read publicly
public String getAccountNumber(){
return this.accountNumber;
}

// Getter method allows routingNumber to be read publicly
public String getRoutingNumber(){
return this.routingNumber;
}

// Getter method allows balance to be read only in in a 'protected' fashion (see definition).
protected Integer getBalance(){
return this.balance;
}

public void showAccountNumber(){
System.out.println(this.accountNumber);
}

public void showRoutingNumber(){
System.out.println(this.routingNumber);
}

public void showBalance(){
System.out.println(this.balance);
}

public void withdraw(Integer amount){
this.balance-=amount;
}

public void deposit(Integer amount){
this.balance+=amount;
}

public static void main(String args[]){
BankAccount Steve = new BankAccount();

//public access to setRoutingNumber/getRoutingNumber
Steve.setRoutingNumber("1234");
String steveRtNo=Steve.getRoutingNumber();
System.out.println(steveRtNo);

//protected access to the method setBalance/getBalance
Steve.setBalance(5000);
System.out.println(Steve.getBalance());
}

}
</pre>

Class BankAccount in the above Java code has public getter/setter methods to access the private data member ‘routingNumber’. Thus, we can invoke these methods using an instance of the BankAccount object: Steve.
The methods setBalance()/ getBalance() are protected. As can be seen, they behave like public methods if invoked in the same package. Protected methods act like private methods if invoked by any instance of a class outside the package.
However, if there is a class ‘InternationalBankAccount’ in a different package such that:
<pre>
public class InternationalBankAccount extends BankAccount {
public String internationalBankAccNo;
}
</pre>

<pre>
InternationalBankAccount Anna = new InternationalBankAccount();
Anna.setBalance(10000);
</pre>

The above is a valid syntax and Anna can access protected member functions of the parent class.
Data member ‘accountNumber’ has default access specifier. Default access specifier is used in Java to support package driven development. Thus ‘accountNumber’ can be accessed from anywhere within the package. However no classes from other packages can access ‘accountNumber’.
Data member balance is a private data member and if it is invoked explicitly as follows,
<pre>
Steve.balance=1000;
</pre>
then the output would be an unresolved compilation error of the form:
<pre>
Unresolved compilation problem: The field bankAccount.balance is not visible
</pre>

===Ruby===
The following code illustrates the use of access specifiers in Ruby.
<pre>
class BankAccount

#Instance Variables
def balance
@balance
end

def routingNumber
@routingNumber
end

def accountNumber
@accountNumber
end

#Initialize the instance variables
def initialize(acNo, rtNo, bal)
@accountNumber = acNo
@routingNumber = rtNo
@balance = bal
end

#method to compare protected data member, balance of 2 objects
def compare_balance(other)
if other.balance > balance
"The other object has more bank balance."
else
"This object has more bank balance."
end
end

#access_specifier:class_member_name to define the access control
protected:balance
public:routingNumber
private:accountNumber

end
</pre>

<pre>
#Creating objects and initializing variables
Steve = BankAccount.new(713, 123, 1000)
Anna = BankAccount.new(923, 125, 2000)

#Accessing public data member
puts Steve.routingNumber()

#Comparing protected field: balance of Steve and Anna
puts Steve.compare_balance (Anna)

#Unsuccessful access of private data member raises “NoMethodError”
puts Steve.accountNumber()
</pre>

<pre>
Output:
123
The other object has more bank balance.
NoMethodError: private method `accountNumber' called for #<BankAccount:0x2b75320>
</pre>

‘routingNumber’ is a public function. Thus, when we access object Steve’s public method ‘routing number’, we successfully get ‘123’ as the output.
Furthermore, this snippet provides a mechanism for the comparison of one account holder’s balance with another. This comparison involves a call to the method ‘balance’. The object performing the comparison has to ask the other object to execute its balance method. So, balance cannot be private. With ‘balance’ changed to protected instead of private, Steve can ask Anna to execute ‘balance’, because both are instances of the same class. But if we try to call the ‘balance’ method of a bankAccount object when ‘self’ is anything other than a bankAccount object, the method will fail. A protected method is thus just like a private method, but with the exemption for those cases where the class of ‘self’ and the class of the respective object (having the method called on it) are the same.

The ‘accountNumber’ method is private. Thus user gets a ‘NoMethodError’ on invoking object Steve’s ‘accountNumber’ method. Initialize method in a class is private by default. Whenever the new method is invoked, initialize method is called and instances are created. If we try to invoke the ‘initialize’ method explicitly, we get the same error as in the case when we tried to invoke object Steve’s private ‘accountNumber’ method.

====Ruby : The send method====
The [http://ruby-doc.org/core/classes/Object.html#M000999 send method] of Ruby has always posed a potential security leak and has thus been continually revised and changed across the different versions of Ruby. The Ruby send method has been de-mystified to an extent below.

In Ruby calling methods is similar to passing messages to an object. Consider the simple code below:
<pre>
class TestSend
def hello
puts “hello world”
end
public:hello
end
</pre>

Now the hello method of TestSend can be invoked in 2 ways as follows:
<pre>
t = TestSend.new

#Conventional invocation of public methods
t.hello

#Invoking a method using send
t.send :hello
</pre>

Both these ways of calling the hello method prints out "hello world" as expected. Parameters can also be passed while invoking a method using the send method. However in Ruby, using send we can also access the private methods of a class. Consider the following snippet for an illustration. Here we have slightly modified the TestSend class we had defined above.

<pre>
class TestSend
def hello
puts “hello world”
end
private:hello
end
</pre>

The hello method has been changed to private. Lets again consider 2 ways of invoking this private method hello:

<pre>
t=TestSend.new

#Conventional invocation of public methods
t.hello

#Invoking a method using send
t.send :hello
</pre>

As expected 't.hello' results in an 'NoMethodError' whereas 't.send :hello' successfully prints "hello world". Thus, the send method provides a workaround to accessing private member functions of a class. This is a distinction that Ruby possesses in comparison to other O-O languages. The state of send has changed several times as and when versions of Ruby have been released. For a while, Ruby 1.9 changed the implementation of send to only allow public methods to be called, introducing a new 'send!' method which continued to allow private methods to be called. However, this has now been removed from Ruby 1.9 in favour of keeping the functionality of send as is. Instead, a new public_send method has been introduced which will only call public methods <ref>http://deaddeadgood.com/2008/11/17/rubys-send-method/</ref>. Another [http://www.joshstaiger.org/archives/2006/12/the_ruby_send_h.html example].

===C#===
<pre>
class BankAccount
{
public BankAccount(string accountNumber, string routingNumber, int balance)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
this.balance = balance;
}

private string accountNumber;
protected string routingNumber;
private int balance;

// accountNumber is private, so it can only be modified from within this
// class. Also, since the following method is private, it can only be called
// from within this class. So this field is truly private.
private void setAccountNumber(string acNo)
{
this.accountNumber=acNo;
}

// routingNumber is protected, so it can be directly modified by objects of
// a subclass. But the contents of this field are made accessible as public
// so anyone can 'read' the value of this field.
public string getRoutingNumber()
{
return this.routingNumber;
}

// Provides access to modify the private member balance, but this function
// can only be called by subclasses (and from within this class).
protected initBalance()
{
this.balance = 0;
}

// Provides access to 'read' the contents of the private field to everyone.
public void getBalance(int balance)
{
return this.balance;
}
}

class Customer : BankAccount
{
Customer(string accountNumber, string routingNumber)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
initBalance();
}
}

class Startup
{
public static void main()
{
Customer cust = new Customer(“999”, “888”, 100);
System.console.WriteLine(cust.getBalance);
}
}

</pre>

The Customer class inherits from the BankAccount class. All protected data members and methods of BankAccount class are accessible directly by an object of the Customer class. The private fields such as accountNumber and routingNumber are not directly accessible. Thus it is possible to call only the initBalance and getBalance methods from Customer. The initBalance method cannot be called by anyone outside the BankAccount class. Also see [http://www.informit.com/articles/article.aspx?p=101373&seqNum=3 this] for another example.

==Conclusion==
Access control is an integral component of object oriented languages and it underlines and emphasizes some of the principal ideals central to the object-oriented approach. It is possible to maximize the benefits of any O-O language by adhering to, and fully exploiting the capabilities of its access specifiers. Access control is in no way a peripheral add-on or redundant feature of O-O languages, and programmers would only stand to gain by fully appreciating, respecting and understanding their presence.

==References==
<references/>

CSC/ECE 517 Fall 2011/ch1 2b ns

2011-09-30T23:07:28Z

Sshyamr: /* Ruby */

<h2>Access Control in Object-Oriented Languages</h2>

== Introduction ==
A fundamental precept of O-O systems is that an object should not expose any of its implementation details. In other words, access to an object’s functionality must be tightly regulated. The access control policies of any object-oriented language specify the rules and capabilities for enforcing this regulation. Thus, the concept of Access control ties in deeply with the underlying principles of [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming].

__TOC__
==Purpose of Access Control==
Object-oriented programming fundamentally revolves around the principle of Data Hiding and Encapsulation. In a nutshell, [http://en.wikipedia.org/wiki/Information_hiding Data Hiding] is the practice of securing data by constraining access to it, and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] ensures that the secure data (and the respective member functions) are bundled together as an individual module. All object oriented languages thus need to control the level of access to their critical data (and functions) which is achieved using ''Access Modifiers'' or ''Access Specifiers'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

The need to strictly control ''who'' can access ''what'' is very crucial in Software development. For example, if you make an instance variable 'public', then you can't change the field as the class evolves over time since you might break any external code that uses the field. This is because outside code having complete access to this field, has tied itself indelibly to the inside implementation of the (former) class and is now closely dependent on it. Changing the said field thus entails changing all the other code that have a dependency on it, which is cumbersome, unwieldy and contrary to the principles of an Object Oriented approach which strives for [http://en.wikipedia.org/wiki/Coupling_(computer_programming) Low Coupling].

Thus, the ‘Implementation hiding principle’ leads to a good acid test of an O-O system's quality: Can you make massive changes to a class definition—even throw out the whole thing and replace it with a completely different implementation—without impacting any of the code that uses that class's objects? This sort of modularization is the central premise of object orientation and makes maintenance much easier. Without implementation hiding, there's little point in using other O-O features. Regulation of access - Access Control - is at the heart of Object oriented programming<ref>http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html</ref>.

==Evolution of Access Control and proliferation of Accessor methods==
Access control has been a part of the OOP movement ever since its inception. [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] is arguably one of first and purest of the many O-O languages and was developed by Xerox PARC in the Learning Research Group in the 1970s <ref>http://www.zdnet.com/blog/murphy/the-tattered-history-of-oop/1157</ref>. Rather than having explicit access specifiers, smalltalk objects operated more in the sense of 'states' i.e. it would hold the 'state' of object(s) which is always private to that object. Any changes required to be made to this state, had to be sent as a request message to that object. This is the most primitive form of access control - having private data members and public member functions - the only difference being that the access levels are not being explicitly specified.

Access control has evolved over time to become highly complicated <ref>http://www.exforsys.com/tutorials/oops/the-use-of-access-specifiers-in-object-oriented-programming.html</ref> because the requirements of computing and software development have ballooned considerably in last decade and a half. Complex software requirements mandates complexity in languages, and this has indeed affected the access control policies, which have evolved into something comprehensive, yet - at times - convoluted. Unfortunately today's developers often lose sight of the fundamental motivation behind the existence of extensive access control and lose out on much of the benefits of having a highly cohesive, low coupled system <ref>http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref>.

To elaborate, it has become somewhat of an involuntary practice for present programmers to make ''all'' data members of a class private and provide accessor methods (getters/setters) to all of them (data members). Developers have come to accept this to be a contemporary programmatic-paradigm and by supplying setters and getters for ''everything'', defeat the very purpose of making class-fields private. A long time ago programmers discovered that reducing the scope (visibility) of data as much as possible leads to more reliable and maintainable code<ref>http://typicalprogrammer.com/?p=23</ref>.

Every getter and setter in one’s code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters is a sign of a poorly-designed set of classes. Java <ref>http://www.eclipse-blog.org/eclipse-ide/auto-generating-getters-and-setters.html</ref> and C# <ref>http://forums.asp.net/t/941864.aspx/1</ref> developers have IDEs that generate getters and setters automatically, implying that accessors are a good idea and thus contribute to that popular belief. That is not to say that one must completely abstain from accessors, but rather re-analyze and - if required - redesign the class structure to involve as little exposure of its data members as can be achieved.

==Access Control: A typical example==
Empirically, the data members of a class are held private, and the member functions (public) act as the end points of this class. Via these public methods, one can access the ‘state’ of an object. The following example illustrates this point and shows how access to the data members of a class are specified and controlled by the access modifiers.

[http://en.wikipedia.org/wiki/UML_Diagram#Diagrams_overview UML Diagram] of a BankAccount Class.

[[Image:BankAccount_UML.png|650px|thumb|center|Typical UML diagram of BankAccount.]]

The “(-)/(+)” preceding the members of this class represent the associated access levels. (-) indicates private and (+) indicates public.
The data members ‘accountNumber’, ‘routingNumber’ and ‘balance’ are maintained as private. Thus, an instance of a ‘Customer’ Object (say) cannot directly access or modify this data. Customer has to interact with the public behavior bundled in this module which allows him to view his account information and/or withdraw/deposit money i.e. his visibility of the class is only restricted to that which is made public by the Class.

Using such access specifiers, we can control the level of security and visibility associated with the members of a class. Thus, an Access Specifier can be roughly defined as ''‘A keyword applied to a variable, method, etc. that indicates which other parts of the code are permitted to access it’'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

==Common Access Specifiers in O-O languages==

Although all access specifiers essentially provide the same functionality, their semantics differ among different O-O languages. Here is how access control is implemented in some of the more common O-O languages.

===C++===
*'''private''':All members of the Class that are declared as private can only be accessed by the class's member functions and [http://en.wikipedia.org/wiki/Friend_class friends] of the class.
*'''protected''':All members of the Class that are declared as protected can be accessed by that class's member functions and friends (classes or functions) of the class. Moreover, classes derived from the class also have access to these elements.
*'''public''':Any class or method can have access to these type of elements.

===Java===
Java offers four access specifiers, listed below in order of decreasing accessibility:
*'''public''': All public classes, methods, and fields are the least secure. The Public access specifier must be used if you explicitly want to offer access to these entities and if this access cannot do any conceivable harm.
*'''protected''': Protected methods and fields can only be accessed within the same class to which the methods and fields belong, within its subclasses, and within classes present in the same [http://download.oracle.com/javase/tutorial/java/concepts/package.html Package]. Use of protected access specifier thus only allows its fields to be accessed by those classes which have some semblance of correlation to it - be it in the form of subclasses (correlation through inheritance) or classes within the same package (logical and/or functional correlation i.e. classes in the same package have ''something'' logical/functional common to them <ref>http://download.oracle.com/javase/tutorial/java/concepts/package.html</ref>).
*'''default '''(no specifier): Default access specifier is Java’s fail-safe way to handle security. Via the default access specifier, a class, method, or field will be accessible from inside the same package to which the class, method, or field belongs, but not from outside this package. Default access is thus suited when the source code is compartmentalized and organized into packages.
*'''private''': Private access specifier is a way to secure vital members of a class. Private methods and fields can only be accessed within the same class to which the methods and fields belong. Private methods and fields are not visible within subclasses and are not inherited by subclasses.

===Ruby===
Ruby gives you three levels of protection, listed below in order of decreasing accessibility:
*'''public''':Public methods can be called by everyone - no access control is enforced. A class's instance methods are public by default.
*'''protected''':Protected methods can be invoked only by objects of the defining class and its subclasses. Access is kept within the family.
*'''private''':Private methods cannot be called with an explicit receiver - the receiver is always self. Thus private methods can be called only in the context of the current object and cannot be invoked by another object's private methods.

Access control in Ruby is determined [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically], as the program runs, not statically. You will get an access violation only when the code attempts to execute the restricted method<ref>http://rubylearning.com/satishtalim/ruby_access_control.html</ref>.

===C#===
The following access modifiers specify the accessibility levels in C#
*'''public''':Any public method or member can be accessed by any other code in the same or different package.
*'''private''':The method or member can only be accessed from within the same class.
*'''protected''':The method or member can be accessed only from within the same Class or from within any of the subclasses.
*'''internal''':The type or member can be accessed by any code in the same assembly, but not from another assembly. An assembly in C# is the rough equivalent of a package in java.
*'''protected internal''':The type or member can be accessed by any code in the [http://msdn.microsoft.com/en-us/library/ms173099.aspx Assembly] (also see [http://msdn.microsoft.com/en-us/library/ms173099(v=vs.80).aspx this]) in which it is declared, or from within a derived class in another assembly. Access from another assembly must take place within a class declaration that derives from the class in which the protected internal element is declared, and it must take place through an instance of the derived class type.

===Summary of Access Specfiers in C++, Java, Ruby and C#:===
{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Access Level
! C++
! Java
! Ruby
! C#
|-
! Public
| Anything can access
| Anything can access
| Anything can access
| Anything can access
|-
! Protected
| Class, Subclasses and friends
| Class, Subclasses and classes of same package
| Class and Subclasses
| Class and Subclasses
|-
! Private
| Within Class
| Within Class
| Within Class
| Within Class
|-
! Internal
| --
| --
| --
| Any Class from same Assembly
|-
! Protected internal
| --
| --
| --
| Any Class from same Assembly and Subclass from any Assembly.
|}

==Examples of Access Specifiers==
The following examples exhibit the use of the access specifiers and getter methods for the aforementioned Bank Account example.

===C++===
<pre>
class BankAccount {
private:
char routingNumber;
char accountNumber;

protected:
int balance;

public:
BankAccount(char *, char *);
void changeAccountNumber(char *);
void changeRoutingNumber(char *);
void depositMoney(int);
void withdrawMoney(int);
friend void displayAccountInfo();
}

BankAccount::BankAccount(char *rNo, char *accNo) {
Strcpy(routingNumber, rNo);
Strcpy(accountNumber, accNo);
balance = 0;
}

BankAccount::void changeAccountNumber(char *accNo){
Strcpy(accountNumber, accNo);
}

BankAccount::void changeRoutingNumber(char *rNo){
Strcpy(routingNumber, rNo);
}

BankAccount::void depositMoney(int amount) {
balance += amount;
}

BankAccount::void withdrawMoney(int amount) {
balance -= amount;
}

// Friend function can access both the private and protected members
// of BankAccount.
void displayAccountInfo(BankAccount ba) {
cout << “Account Number: ” << ba.accountNumber << endl;
cout << “Routing Number: ” << ba.routingNumber << endl;
cout << “Account Balance: ” << ba.balance << endl << endl;
}

// CheckingAccount inherits from BankAccount. Hence it can access only the
// public and protected members of BankAccount. It cannot access the private
// members of BankAccount.
class CheckingAccount: public BankAccount {
private:
char accountType[20];

public:
CheckingAccount(char *, char *);
void resetBalance();
}

CheckingAccount::CheckingAccount(char *rNo, char *accNo) {
Strcpy(accountType, "Checking");
changeRoutingNumber(rNo);
changeAccountNumber (accNo);
balance = 0;
}

// Since balance is a protected field, it can be accessed by CheckingAccount
CheckingAccount::void resetBalance() {
balance = 0;
}

int main() {
CheckingAccount ca("888", "999");
ca.depositMoney(100);
displayAccountInfo(ca);
ca.withdrawMoney(50);
displayAccountInfo(ca);
ca.resetBalance();
displayAccountInfo(ca);
}

</pre>

<pre>
OUTPUT:

Account Number: 888
Routing Number: 999
Account Balance: 100

Account Number: 888
Routing Number: 999
Account Balance: 50

Account Number: 888
Routing Number: 999
Account Balance: 0
</pre>

The data members routingNumber, accountNumber are made private and balance is protected. This makes it impossible to directly access or change routingNumber, accountNumber from outside code. Access to these attributes are strictly through the public methods changeRoutingNumber() and changeAccountNumber(). However, private and protected members are accessible through friend functions, so displayAccountInfo() function is able to access all the mentioned fields. Since balance is protected, it can be accessed from a subclass (CheckingAccount) directly as shown above. But the private members have to be accessed through the functions changeRoutingNumber() and changeAccountNumber() instead of being accessed directly.

Thus, it purely at the discretion of the programmer to allow access to these data members through such accessor functions. In the absence of such accessors, there would be no way for any code outside the class to view/modify the private attributes.

===Java===

<pre>
public class BankAccount {
String accountNumber;
private String routingNumber;
private Integer balance;

//setter methods for accountNumber allows public acccess to it.
public void setAccountNumber(String acNo){
this.accountNumber=acNo;
}

//setter methods for routingNumber allows public acccess to it.
public void setRoutingNumber(String rtNo){
this.routingNumber=rtNo;
}

//setter methods for balance allows only 'protected' access to it (see definition).
protected void setBalance(Integer bal){
this.balance=bal;
}

// Getter method allows accountNumber to be read publicly
public String getAccountNumber(){
return this.accountNumber;
}

// Getter method allows routingNumber to be read publicly
public String getRoutingNumber(){
return this.routingNumber;
}

// Getter method allows balance to be read only in in a 'protected' fashion (see definition).
protected Integer getBalance(){
return this.balance;
}

public void showAccountNumber(){
System.out.println(this.accountNumber);
}

public void showRoutingNumber(){
System.out.println(this.routingNumber);
}

public void showBalance(){
System.out.println(this.balance);
}

public void withdraw(Integer amount){
this.balance-=amount;
}

public void deposit(Integer amount){
this.balance+=amount;
}

public static void main(String args[]){
BankAccount Steve = new BankAccount();

//public access to setRoutingNumber/getRoutingNumber
Steve.setRoutingNumber("1234");
String steveRtNo=Steve.getRoutingNumber();
System.out.println(steveRtNo);

//protected access to the method setBalance/getBalance
Steve.setBalance(5000);
System.out.println(Steve.getBalance());
}

}
</pre>

Class BankAccount in the above Java code has public getter/setter methods to access the private data member ‘routingNumber’. Thus, we can invoke these methods using an instance of the BankAccount object: Steve.
The methods setBalance()/ getBalance() are protected. As can be seen, they behave like public methods if invoked in the same package. Protected methods act like private methods if invoked by any instance of a class outside the package.
However, if there is a class ‘InternationalBankAccount’ in a different package such that:
<pre>
public class InternationalBankAccount extends BankAccount {
public String internationalBankAccNo;
}
</pre>

<pre>
InternationalBankAccount Anna = new InternationalBankAccount();
Anna.setBalance(10000);
</pre>

The above is a valid syntax and Anna can access protected member functions of the parent class.
Data member ‘accountNumber’ has default access specifier. Default access specifier is used in Java to support package driven development. Thus ‘accountNumber’ can be accessed from anywhere within the package. However no classes from other packages can access ‘accountNumber’.
Data member balance is a private data member and if it is invoked explicitly as follows,
<pre>
Steve.balance=1000;
</pre>
then the output would be an unresolved compilation error of the form:
<pre>
Unresolved compilation problem: The field bankAccount.balance is not visible
</pre>

===Ruby===
The following code illustrates the use of access specifiers in Ruby.
<pre>
class BankAccount

#Instance Variables
def balance
@balance
end

def routingNumber
@routingNumber
end

def accountNumber
@accountNumber
end

#Initialize the instance variables
def initialize(acNo, rtNo, bal)
@accountNumber = acNo
@routingNumber = rtNo
@balance = bal
end

#method to compare protected data member, balance of 2 objects
def compare_balance(other)
if other.balance > balance
"The other object has more bank balance."
else
"This object has more bank balance."
end
end

#access_specifier:class_member_name to define the access control
protected:balance
public:routingNumber
private:accountNumber

end
</pre>

<pre>
#Creating objects and initializing variables
Steve = BankAccount.new(713, 123, 1000)
Anna = BankAccount.new(923, 125, 2000)

#Accessing public data member
puts Steve.routingNumber()

#Comparing protected field: balance of Steve and Anna
puts Steve.compare_balance (Anna)

#Unsuccessful access of private data member raises “NoMethodError”
puts Steve.accountNumber()
</pre>

<pre>
Output:
123
The other object has more bank balance.
NoMethodError: private method `accountNumber' called for #<BankAccount:0x2b75320>
</pre>

‘routingNumber’ is a public function. Thus, when we access object Steve’s public method ‘routing number’, we successfully get ‘123’ as the output.
Furthermore, this snippet provides a mechanism for the comparison of one account holder’s balance with another. This comparison involves a call to the method ‘balance’. The object performing the comparison has to ask the other object to execute its balance method. So, balance cannot be private. With ‘balance’ changed to protected instead of private, Steve can ask Anna to execute ‘balance’, because both are instances of the same class. But if we try to call the ‘balance’ method of a bankAccount object when ‘self’ is anything other than a bankAccount object, the method will fail. A protected method is thus just like a private method, but with the exemption for those cases where the class of ‘self’ and the class of the respective object (having the method called on it) are the same.

The ‘accountNumber’ method is private. Thus user gets a ‘NoMethodError’ on invoking object Steve’s ‘accountNumber’ method. Initialize method in a class is private by default. Whenever the new method is invoked, initialize method is called and instances are created. If we try to invoke the ‘initialize’ method explicitly, we get the same error as in the case when we tried to invoke object Steve’s private ‘accountNumber’ method.

====Ruby : The send method====
The send method of Ruby has always posed a potential security leak and has thus been continually revised and changed across the different versions of Ruby. The Ruby send method has been de-mystified to an extent below.

In Ruby calling methods is similar to passing messages to an object. Consider the simple code below:
<pre>
class TestSend
def hello
puts “hello world”
end
public:hello
end
</pre>

Now the hello method of TestSend can be invoked in 2 ways as follows:
<pre>
t = TestSend.new

#Conventional invocation of public methods
t.hello

#Invoking a method using send
t.send :hello
</pre>

Both these ways of calling the hello method prints out "hello world" as expected. Parameters can also be passed while invoking a method using the send method. However in Ruby, using send we can also access the private methods of a class. Consider the following snippet for an illustration. Here we have slightly modified the TestSend class we had defined above.

<pre>
class TestSend
def hello
puts “hello world”
end
private:hello
end
</pre>

The hello method has been changed to private. Lets again consider 2 ways of invoking this private method hello:

<pre>
t=TestSend.new

#Conventional invocation of public methods
t.hello

#Invoking a method using send
t.send :hello
</pre>

As expected 't.hello' results in an 'NoMethodError' whereas 't.send :hello' successfully prints "hello world". Thus, the send method provides a workaround to accessing private member functions of a class. This is a distinction that Ruby possesses in comparison to other O-O languages. The state of send has changed several times as and when versions of Ruby have been released. For a while, Ruby 1.9 changed the implementation of send to only allow public methods to be called, introducing a new 'send!' method which continued to allow private methods to be called. However, this has now been removed from Ruby 1.9 in favour of keeping the functionality of send as is. Instead, a new public_send method has been introduced which will only call public methods <ref>http://deaddeadgood.com/2008/11/17/rubys-send-method/</ref>.

===C#===
<pre>
class BankAccount
{
public BankAccount(string accountNumber, string routingNumber, int balance)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
this.balance = balance;
}

private string accountNumber;
protected string routingNumber;
private int balance;

// accountNumber is private, so it can only be modified from within this
// class. Also, since the following method is private, it can only be called
// from within this class. So this field is truly private.
private void setAccountNumber(string acNo)
{
this.accountNumber=acNo;
}

// routingNumber is protected, so it can be directly modified by objects of
// a subclass. But the contents of this field are made accessible as public
// so anyone can 'read' the value of this field.
public string getRoutingNumber()
{
return this.routingNumber;
}

// Provides access to modify the private member balance, but this function
// can only be called by subclasses (and from within this class).
protected initBalance()
{
this.balance = 0;
}

// Provides access to 'read' the contents of the private field to everyone.
public void getBalance(int balance)
{
return this.balance;
}
}

class Customer : BankAccount
{
Customer(string accountNumber, string routingNumber)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
initBalance();
}
}

class Startup
{
public static void main()
{
Customer cust = new Customer(“999”, “888”, 100);
System.console.WriteLine(cust.getBalance);
}
}

</pre>

The Customer class inherits from the BankAccount class. All protected data members and methods of BankAccount class are accessible directly by an object of the Customer class. The private fields such as accountNumber and routingNumber are not directly accessible. Thus it is possible to call only the initBalance and getBalance methods from Customer. The initBalance method cannot be called by anyone outside the BankAccount class. Also see [http://www.informit.com/articles/article.aspx?p=101373&seqNum=3 this] for another example.

==Conclusion==
Access control is an integral component of object oriented languages and it underlines and emphasizes some of the principal ideals central to the object-oriented approach. It is possible to maximize the benefits of any O-O language by adhering to, and fully exploiting the capabilities of its access specifiers. Access control is in no way a peripheral add-on or redundant feature of O-O languages, and programmers would only stand to gain by fully appreciating, respecting and understanding their presence.

==References==
<references/>

CSC/ECE 517 Fall 2011/ch1 2b ns

2011-09-30T22:55:00Z

Sshyamr: /* Ruby */

<h2>Access Control in Object-Oriented Languages</h2>

== Introduction ==
A fundamental precept of O-O systems is that an object should not expose any of its implementation details. In other words, access to an object’s functionality must be tightly regulated. The access control policies of any object-oriented language specify the rules and capabilities for enforcing this regulation. Thus, the concept of Access control ties in deeply with the underlying principles of [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming].

__TOC__
==Purpose of Access Control==
Object-oriented programming fundamentally revolves around the principle of Data Hiding and Encapsulation. In a nutshell, [http://en.wikipedia.org/wiki/Information_hiding Data Hiding] is the practice of securing data by constraining access to it, and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] ensures that the secure data (and the respective member functions) are bundled together as an individual module. All object oriented languages thus need to control the level of access to their critical data (and functions) which is achieved using ''Access Modifiers'' or ''Access Specifiers'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

The need to strictly control ''who'' can access ''what'' is very crucial in Software development. For example, if you make an instance variable 'public', then you can't change the field as the class evolves over time since you might break any external code that uses the field. This is because outside code having complete access to this field, has tied itself indelibly to the inside implementation of the (former) class and is now closely dependent on it. Changing the said field thus entails changing all the other code that have a dependency on it, which is cumbersome, unwieldy and contrary to the principles of an Object Oriented approach which strives for [http://en.wikipedia.org/wiki/Coupling_(computer_programming) Low Coupling].

Thus, the ‘Implementation hiding principle’ leads to a good acid test of an O-O system's quality: Can you make massive changes to a class definition—even throw out the whole thing and replace it with a completely different implementation—without impacting any of the code that uses that class's objects? This sort of modularization is the central premise of object orientation and makes maintenance much easier. Without implementation hiding, there's little point in using other O-O features. Regulation of access - Access Control - is at the heart of Object oriented programming<ref>http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html</ref>.

==Evolution of Access Control and proliferation of Accessor methods==
Access control has been a part of the OOP movement ever since its inception. [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] is arguably one of first and purest of the many O-O languages and was developed by Xerox PARC in the Learning Research Group in the 1970s <ref>http://www.zdnet.com/blog/murphy/the-tattered-history-of-oop/1157</ref>. Rather than having explicit access specifiers, smalltalk objects operated more in the sense of 'states' i.e. it would hold the 'state' of object(s) which is always private to that object. Any changes required to be made to this state, had to be sent as a request message to that object. This is the most primitive form of access control - having private data members and public member functions - the only difference being that the access levels are not being explicitly specified.

Access control has evolved over time to become highly complicated <ref>http://www.exforsys.com/tutorials/oops/the-use-of-access-specifiers-in-object-oriented-programming.html</ref> because the requirements of computing and software development have ballooned considerably in last decade and a half. Complex software requirements mandates complexity in languages, and this has indeed affected the access control policies, which have evolved into something comprehensive, yet - at times - convoluted. Unfortunately today's developers often lose sight of the fundamental motivation behind the existence of extensive access control and lose out on much of the benefits of having a highly cohesive, low coupled system <ref>http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref>.

To elaborate, it has become somewhat of an involuntary practice for present programmers to make ''all'' data members of a class private and provide accessor methods (getters/setters) to all of them (data members). Developers have come to accept this to be a contemporary programmatic-paradigm and by supplying setters and getters for ''everything'', defeat the very purpose of making class-fields private. A long time ago programmers discovered that reducing the scope (visibility) of data as much as possible leads to more reliable and maintainable code<ref>http://typicalprogrammer.com/?p=23</ref>.

Every getter and setter in one’s code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters is a sign of a poorly-designed set of classes. Java <ref>http://www.eclipse-blog.org/eclipse-ide/auto-generating-getters-and-setters.html</ref> and C# <ref>http://forums.asp.net/t/941864.aspx/1</ref> developers have IDEs that generate getters and setters automatically, implying that accessors are a good idea and thus contribute to that popular belief. That is not to say that one must completely abstain from accessors, but rather re-analyze and - if required - redesign the class structure to involve as little exposure of its data members as can be achieved.

==Access Control: A typical example==
Empirically, the data members of a class are held private, and the member functions (public) act as the end points of this class. Via these public methods, one can access the ‘state’ of an object. The following example illustrates this point and shows how access to the data members of a class are specified and controlled by the access modifiers.

[http://en.wikipedia.org/wiki/UML_Diagram#Diagrams_overview UML Diagram] of a BankAccount Class.

[[Image:BankAccount_UML.png|650px|thumb|center|Typical UML diagram of BankAccount.]]

The “(-)/(+)” preceding the members of this class represent the associated access levels. (-) indicates private and (+) indicates public.
The data members ‘accountNumber’, ‘routingNumber’ and ‘balance’ are maintained as private. Thus, an instance of a ‘Customer’ Object (say) cannot directly access or modify this data. Customer has to interact with the public behavior bundled in this module which allows him to view his account information and/or withdraw/deposit money i.e. his visibility of the class is only restricted to that which is made public by the Class.

Using such access specifiers, we can control the level of security and visibility associated with the members of a class. Thus, an Access Specifier can be roughly defined as ''‘A keyword applied to a variable, method, etc. that indicates which other parts of the code are permitted to access it’'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

==Common Access Specifiers in O-O languages==

Although all access specifiers essentially provide the same functionality, their semantics differ among different O-O languages. Here is how access control is implemented in some of the more common O-O languages.

===C++===
*'''private''':All members of the Class that are declared as private can only be accessed by the class's member functions and [http://en.wikipedia.org/wiki/Friend_class friends] of the class.
*'''protected''':All members of the Class that are declared as protected can be accessed by that class's member functions and friends (classes or functions) of the class. Moreover, classes derived from the class also have access to these elements.
*'''public''':Any class or method can have access to these type of elements.

===Java===
Java offers four access specifiers, listed below in order of decreasing accessibility:
*'''public''': All public classes, methods, and fields are the least secure. The Public access specifier must be used if you explicitly want to offer access to these entities and if this access cannot do any conceivable harm.
*'''protected''': Protected methods and fields can only be accessed within the same class to which the methods and fields belong, within its subclasses, and within classes present in the same [http://download.oracle.com/javase/tutorial/java/concepts/package.html Package]. Use of protected access specifier thus only allows its fields to be accessed by those classes which have some semblance of correlation to it - be it in the form of subclasses (correlation through inheritance) or classes within the same package (logical and/or functional correlation i.e. classes in the same package have ''something'' logical/functional common to them <ref>http://download.oracle.com/javase/tutorial/java/concepts/package.html</ref>).
*'''default '''(no specifier): Default access specifier is Java’s fail-safe way to handle security. Via the default access specifier, a class, method, or field will be accessible from inside the same package to which the class, method, or field belongs, but not from outside this package. Default access is thus suited when the source code is compartmentalized and organized into packages.
*'''private''': Private access specifier is a way to secure vital members of a class. Private methods and fields can only be accessed within the same class to which the methods and fields belong. Private methods and fields are not visible within subclasses and are not inherited by subclasses.

===Ruby===
Ruby gives you three levels of protection, listed below in order of decreasing accessibility:
*'''public''':Public methods can be called by everyone - no access control is enforced. A class's instance methods are public by default.
*'''protected''':Protected methods can be invoked only by objects of the defining class and its subclasses. Access is kept within the family.
*'''private''':Private methods cannot be called with an explicit receiver - the receiver is always self. Thus private methods can be called only in the context of the current object and cannot be invoked by another object's private methods.

Access control in Ruby is determined [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically], as the program runs, not statically. You will get an access violation only when the code attempts to execute the restricted method<ref>http://rubylearning.com/satishtalim/ruby_access_control.html</ref>.

===C#===
The following access modifiers specify the accessibility levels in C#
*'''public''':Any public method or member can be accessed by any other code in the same or different package.
*'''private''':The method or member can only be accessed from within the same class.
*'''protected''':The method or member can be accessed only from within the same Class or from within any of the subclasses.
*'''internal''':The type or member can be accessed by any code in the same assembly, but not from another assembly. An assembly in C# is the rough equivalent of a package in java.
*'''protected internal''':The type or member can be accessed by any code in the [http://msdn.microsoft.com/en-us/library/ms173099.aspx Assembly] (also see [http://msdn.microsoft.com/en-us/library/ms173099(v=vs.80).aspx this]) in which it is declared, or from within a derived class in another assembly. Access from another assembly must take place within a class declaration that derives from the class in which the protected internal element is declared, and it must take place through an instance of the derived class type.

===Summary of Access Specfiers in C++, Java, Ruby and C#:===
{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Access Level
! C++
! Java
! Ruby
! C#
|-
! Public
| Anything can access
| Anything can access
| Anything can access
| Anything can access
|-
! Protected
| Class, Subclasses and friends
| Class, Subclasses and classes of same package
| Class and Subclasses
| Class and Subclasses
|-
! Private
| Within Class
| Within Class
| Within Class
| Within Class
|-
! Internal
| --
| --
| --
| Any Class from same Assembly
|-
! Protected internal
| --
| --
| --
| Any Class from same Assembly and Subclass from any Assembly.
|}

==Examples of Access Specifiers==
The following examples exhibit the use of the access specifiers and getter methods for the aforementioned Bank Account example.

===C++===
<pre>
class BankAccount {
private:
char routingNumber;
char accountNumber;

protected:
int balance;

public:
BankAccount(char *, char *);
void changeAccountNumber(char *);
void changeRoutingNumber(char *);
void depositMoney(int);
void withdrawMoney(int);
friend void displayAccountInfo();
}

BankAccount::BankAccount(char *rNo, char *accNo) {
Strcpy(routingNumber, rNo);
Strcpy(accountNumber, accNo);
balance = 0;
}

BankAccount::void changeAccountNumber(char *accNo){
Strcpy(accountNumber, accNo);
}

BankAccount::void changeRoutingNumber(char *rNo){
Strcpy(routingNumber, rNo);
}

BankAccount::void depositMoney(int amount) {
balance += amount;
}

BankAccount::void withdrawMoney(int amount) {
balance -= amount;
}

// Friend function can access both the private and protected members
// of BankAccount.
void displayAccountInfo(BankAccount ba) {
cout << “Account Number: ” << ba.accountNumber << endl;
cout << “Routing Number: ” << ba.routingNumber << endl;
cout << “Account Balance: ” << ba.balance << endl << endl;
}

// CheckingAccount inherits from BankAccount. Hence it can access only the
// public and protected members of BankAccount. It cannot access the private
// members of BankAccount.
class CheckingAccount: public BankAccount {
private:
char accountType[20];

public:
CheckingAccount(char *, char *);
void resetBalance();
}

CheckingAccount::CheckingAccount(char *rNo, char *accNo) {
Strcpy(accountType, "Checking");
changeRoutingNumber(rNo);
changeAccountNumber (accNo);
balance = 0;
}

// Since balance is a protected field, it can be accessed by CheckingAccount
CheckingAccount::void resetBalance() {
balance = 0;
}

int main() {
CheckingAccount ca("888", "999");
ca.depositMoney(100);
displayAccountInfo(ca);
ca.withdrawMoney(50);
displayAccountInfo(ca);
ca.resetBalance();
displayAccountInfo(ca);
}

</pre>

<pre>
OUTPUT:

Account Number: 888
Routing Number: 999
Account Balance: 100

Account Number: 888
Routing Number: 999
Account Balance: 50

Account Number: 888
Routing Number: 999
Account Balance: 0
</pre>

The data members routingNumber, accountNumber are made private and balance is protected. This makes it impossible to directly access or change routingNumber, accountNumber from outside code. Access to these attributes are strictly through the public methods changeRoutingNumber() and changeAccountNumber(). However, private and protected members are accessible through friend functions, so displayAccountInfo() function is able to access all the mentioned fields. Since balance is protected, it can be accessed from a subclass (CheckingAccount) directly as shown above. But the private members have to be accessed through the functions changeRoutingNumber() and changeAccountNumber() instead of being accessed directly.

Thus, it purely at the discretion of the programmer to allow access to these data members through such accessor functions. In the absence of such accessors, there would be no way for any code outside the class to view/modify the private attributes.

===Java===

<pre>
public class BankAccount {
String accountNumber;
private String routingNumber;
private Integer balance;

//setter methods for accountNumber allows public acccess to it.
public void setAccountNumber(String acNo){
this.accountNumber=acNo;
}

//setter methods for routingNumber allows public acccess to it.
public void setRoutingNumber(String rtNo){
this.routingNumber=rtNo;
}

//setter methods for balance allows only 'protected' access to it (see definition).
protected void setBalance(Integer bal){
this.balance=bal;
}

// Getter method allows accountNumber to be read publicly
public String getAccountNumber(){
return this.accountNumber;
}

// Getter method allows routingNumber to be read publicly
public String getRoutingNumber(){
return this.routingNumber;
}

// Getter method allows balance to be read only in in a 'protected' fashion (see definition).
protected Integer getBalance(){
return this.balance;
}

public void showAccountNumber(){
System.out.println(this.accountNumber);
}

public void showRoutingNumber(){
System.out.println(this.routingNumber);
}

public void showBalance(){
System.out.println(this.balance);
}

public void withdraw(Integer amount){
this.balance-=amount;
}

public void deposit(Integer amount){
this.balance+=amount;
}

public static void main(String args[]){
BankAccount Steve = new BankAccount();

//public access to setRoutingNumber/getRoutingNumber
Steve.setRoutingNumber("1234");
String steveRtNo=Steve.getRoutingNumber();
System.out.println(steveRtNo);

//protected access to the method setBalance/getBalance
Steve.setBalance(5000);
System.out.println(Steve.getBalance());
}

}
</pre>

Class BankAccount in the above Java code has public getter/setter methods to access the private data member ‘routingNumber’. Thus, we can invoke these methods using an instance of the BankAccount object: Steve.
The methods setBalance()/ getBalance() are protected. As can be seen, they behave like public methods if invoked in the same package. Protected methods act like private methods if invoked by any instance of a class outside the package.
However, if there is a class ‘InternationalBankAccount’ in a different package such that:
<pre>
public class InternationalBankAccount extends BankAccount {
public String internationalBankAccNo;
}
</pre>

<pre>
InternationalBankAccount Anna = new InternationalBankAccount();
Anna.setBalance(10000);
</pre>

The above is a valid syntax and Anna can access protected member functions of the parent class.
Data member ‘accountNumber’ has default access specifier. Default access specifier is used in Java to support package driven development. Thus ‘accountNumber’ can be accessed from anywhere within the package. However no classes from other packages can access ‘accountNumber’.
Data member balance is a private data member and if it is invoked explicitly as follows,
<pre>
Steve.balance=1000;
</pre>
then the output would be an unresolved compilation error of the form:
<pre>
Unresolved compilation problem: The field bankAccount.balance is not visible
</pre>

===Ruby===
The following code illustrates the use of access specifiers in Ruby.
<pre>
class BankAccount

#Instance Variables
def balance
@balance
end

def routingNumber
@routingNumber
end

def accountNumber
@accountNumber
end

#Initialize the instance variables
def initialize(acNo, rtNo, bal)
@accountNumber = acNo
@routingNumber = rtNo
@balance = bal
end

#method to compare protected data member, balance of 2 objects
def compare_balance(other)
if other.balance > balance
"The other object has more bank balance."
else
"This object has more bank balance."
end
end

#access_specifier:class_member_name to define the access control
protected:balance
public:routingNumber
private:accountNumber

end
</pre>

<pre>
#Creating objects and initializing variables
Steve = BankAccount.new(713, 123, 1000)
Anna = BankAccount.new(923, 125, 2000)

#Accessing public data member
puts Steve.routingNumber()

#Comparing protected field: balance of Steve and Anna
puts Steve.compare_balance (Anna)

#Unsuccessful access of private data member raises “NoMethodError”
puts Steve.accountNumber()
</pre>

<pre>
Output:
123
The other object has more bank balance.
NoMethodError: private method `accountNumber' called for #<BankAccount:0x2b75320>
</pre>

‘routingNumber’ is a public function. Thus, when we access object Steve’s public method ‘routing number’, we successfully get ‘123’ as the output.
Furthermore, this snippet provides a mechanism for the comparison of one account holder’s balance with another. This comparison involves a call to the method ‘balance’. The object performing the comparison has to ask the other object to execute its balance method. So, balance cannot be private. With ‘balance’ changed to protected instead of private, Steve can ask Anna to execute ‘balance’, because both are instances of the same class. But if we try to call the ‘balance’ method of a bankAccount object when ‘self’ is anything other than a bankAccount object, the method will fail. A protected method is thus just like a private method, but with the exemption for those cases where the class of ‘self’ and the class of the respective object (having the method called on it) are the same.
‘accountNumber’ method is private. Thus user gets a ‘NoMethodError’ on invoking object Steve’s ‘accountNumber’ method. Initialize method in a class is private by default. Whenever the new method is invoked, initialize method is called and instances are created. If we try to invoke the ‘initialize’ method explicitly, we get the same error as in the case when we tried to invoke object Steve’s private ‘accountNumber’ method.

===C#===
<pre>
class BankAccount
{
public BankAccount(string accountNumber, string routingNumber, int balance)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
this.balance = balance;
}

private string accountNumber;
protected string routingNumber;
private int balance;

// accountNumber is private, so it can only be modified from within this
// class. Also, since the following method is private, it can only be called
// from within this class. So this field is truly private.
private void setAccountNumber(string acNo)
{
this.accountNumber=acNo;
}

// routingNumber is protected, so it can be directly modified by objects of
// a subclass. But the contents of this field are made accessible as public
// so anyone can 'read' the value of this field.
public string getRoutingNumber()
{
return this.routingNumber;
}

// Provides access to modify the private member balance, but this function
// can only be called by subclasses (and from within this class).
protected initBalance()
{
this.balance = 0;
}

// Provides access to 'read' the contents of the private field to everyone.
public void getBalance(int balance)
{
return this.balance;
}
}

class Customer : BankAccount
{
Customer(string accountNumber, string routingNumber)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
initBalance();
}
}

class Startup
{
public static void main()
{
Customer cust = new Customer(“999”, “888”, 100);
System.console.WriteLine(cust.getBalance);
}
}

</pre>

The Customer class inherits from the BankAccount class. All protected data members and methods of BankAccount class are accessible directly by an object of the Customer class. The private fields such as accountNumber and routingNumber are not directly accessible. Thus it is possible to call only the initBalance and getBalance methods from Customer. The initBalance method cannot be called by anyone outside the BankAccount class. Also see [http://www.informit.com/articles/article.aspx?p=101373&seqNum=3 this] for another example.

==Conclusion==
Access control is an integral component of object oriented languages and it underlines and emphasizes some of the principal ideals central to the object-oriented approach. It is possible to maximize the benefits of any O-O language by adhering to, and fully exploiting the capabilities of its access specifiers. Access control is in no way a peripheral add-on or redundant feature of O-O languages, and programmers would only stand to gain by fully appreciating, respecting and understanding their presence.

==References==
<references/>

CSC/ECE 517 Fall 2011/ch1 2b ns

2011-09-30T22:51:49Z

Sshyamr: /* Java */

<h2>Access Control in Object-Oriented Languages</h2>

== Introduction ==
A fundamental precept of O-O systems is that an object should not expose any of its implementation details. In other words, access to an object’s functionality must be tightly regulated. The access control policies of any object-oriented language specify the rules and capabilities for enforcing this regulation. Thus, the concept of Access control ties in deeply with the underlying principles of [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming].

__TOC__
==Purpose of Access Control==
Object-oriented programming fundamentally revolves around the principle of Data Hiding and Encapsulation. In a nutshell, [http://en.wikipedia.org/wiki/Information_hiding Data Hiding] is the practice of securing data by constraining access to it, and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] ensures that the secure data (and the respective member functions) are bundled together as an individual module. All object oriented languages thus need to control the level of access to their critical data (and functions) which is achieved using ''Access Modifiers'' or ''Access Specifiers'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

The need to strictly control ''who'' can access ''what'' is very crucial in Software development. For example, if you make an instance variable 'public', then you can't change the field as the class evolves over time since you might break any external code that uses the field. This is because outside code having complete access to this field, has tied itself indelibly to the inside implementation of the (former) class and is now closely dependent on it. Changing the said field thus entails changing all the other code that have a dependency on it, which is cumbersome, unwieldy and contrary to the principles of an Object Oriented approach which strives for [http://en.wikipedia.org/wiki/Coupling_(computer_programming) Low Coupling].

Thus, the ‘Implementation hiding principle’ leads to a good acid test of an O-O system's quality: Can you make massive changes to a class definition—even throw out the whole thing and replace it with a completely different implementation—without impacting any of the code that uses that class's objects? This sort of modularization is the central premise of object orientation and makes maintenance much easier. Without implementation hiding, there's little point in using other O-O features. Regulation of access - Access Control - is at the heart of Object oriented programming<ref>http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html</ref>.

==Evolution of Access Control and proliferation of Accessor methods==
Access control has been a part of the OOP movement ever since its inception. [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] is arguably one of first and purest of the many O-O languages and was developed by Xerox PARC in the Learning Research Group in the 1970s <ref>http://www.zdnet.com/blog/murphy/the-tattered-history-of-oop/1157</ref>. Rather than having explicit access specifiers, smalltalk objects operated more in the sense of 'states' i.e. it would hold the 'state' of object(s) which is always private to that object. Any changes required to be made to this state, had to be sent as a request message to that object. This is the most primitive form of access control - having private data members and public member functions - the only difference being that the access levels are not being explicitly specified.

Access control has evolved over time to become highly complicated <ref>http://www.exforsys.com/tutorials/oops/the-use-of-access-specifiers-in-object-oriented-programming.html</ref> because the requirements of computing and software development have ballooned considerably in last decade and a half. Complex software requirements mandates complexity in languages, and this has indeed affected the access control policies, which have evolved into something comprehensive, yet - at times - convoluted. Unfortunately today's developers often lose sight of the fundamental motivation behind the existence of extensive access control and lose out on much of the benefits of having a highly cohesive, low coupled system <ref>http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref>.

To elaborate, it has become somewhat of an involuntary practice for present programmers to make ''all'' data members of a class private and provide accessor methods (getters/setters) to all of them (data members). Developers have come to accept this to be a contemporary programmatic-paradigm and by supplying setters and getters for ''everything'', defeat the very purpose of making class-fields private. A long time ago programmers discovered that reducing the scope (visibility) of data as much as possible leads to more reliable and maintainable code<ref>http://typicalprogrammer.com/?p=23</ref>.

Every getter and setter in one’s code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters is a sign of a poorly-designed set of classes. Java <ref>http://www.eclipse-blog.org/eclipse-ide/auto-generating-getters-and-setters.html</ref> and C# <ref>http://forums.asp.net/t/941864.aspx/1</ref> developers have IDEs that generate getters and setters automatically, implying that accessors are a good idea and thus contribute to that popular belief. That is not to say that one must completely abstain from accessors, but rather re-analyze and - if required - redesign the class structure to involve as little exposure of its data members as can be achieved.

==Access Control: A typical example==
Empirically, the data members of a class are held private, and the member functions (public) act as the end points of this class. Via these public methods, one can access the ‘state’ of an object. The following example illustrates this point and shows how access to the data members of a class are specified and controlled by the access modifiers.

[http://en.wikipedia.org/wiki/UML_Diagram#Diagrams_overview UML Diagram] of a BankAccount Class.

[[Image:BankAccount_UML.png|650px|thumb|center|Typical UML diagram of BankAccount.]]

The “(-)/(+)” preceding the members of this class represent the associated access levels. (-) indicates private and (+) indicates public.
The data members ‘accountNumber’, ‘routingNumber’ and ‘balance’ are maintained as private. Thus, an instance of a ‘Customer’ Object (say) cannot directly access or modify this data. Customer has to interact with the public behavior bundled in this module which allows him to view his account information and/or withdraw/deposit money i.e. his visibility of the class is only restricted to that which is made public by the Class.

Using such access specifiers, we can control the level of security and visibility associated with the members of a class. Thus, an Access Specifier can be roughly defined as ''‘A keyword applied to a variable, method, etc. that indicates which other parts of the code are permitted to access it’'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

==Common Access Specifiers in O-O languages==

Although all access specifiers essentially provide the same functionality, their semantics differ among different O-O languages. Here is how access control is implemented in some of the more common O-O languages.

===C++===
*'''private''':All members of the Class that are declared as private can only be accessed by the class's member functions and [http://en.wikipedia.org/wiki/Friend_class friends] of the class.
*'''protected''':All members of the Class that are declared as protected can be accessed by that class's member functions and friends (classes or functions) of the class. Moreover, classes derived from the class also have access to these elements.
*'''public''':Any class or method can have access to these type of elements.

===Java===
Java offers four access specifiers, listed below in order of decreasing accessibility:
*'''public''': All public classes, methods, and fields are the least secure. The Public access specifier must be used if you explicitly want to offer access to these entities and if this access cannot do any conceivable harm.
*'''protected''': Protected methods and fields can only be accessed within the same class to which the methods and fields belong, within its subclasses, and within classes present in the same [http://download.oracle.com/javase/tutorial/java/concepts/package.html Package]. Use of protected access specifier thus only allows its fields to be accessed by those classes which have some semblance of correlation to it - be it in the form of subclasses (correlation through inheritance) or classes within the same package (logical and/or functional correlation i.e. classes in the same package have ''something'' logical/functional common to them <ref>http://download.oracle.com/javase/tutorial/java/concepts/package.html</ref>).
*'''default '''(no specifier): Default access specifier is Java’s fail-safe way to handle security. Via the default access specifier, a class, method, or field will be accessible from inside the same package to which the class, method, or field belongs, but not from outside this package. Default access is thus suited when the source code is compartmentalized and organized into packages.
*'''private''': Private access specifier is a way to secure vital members of a class. Private methods and fields can only be accessed within the same class to which the methods and fields belong. Private methods and fields are not visible within subclasses and are not inherited by subclasses.

===Ruby===
Ruby gives you three levels of protection, listed below in order of decreasing accessibility:
*'''public''':Public methods can be called by everyone - no access control is enforced. A class's instance methods are public by default.
*'''protected''':Protected methods can be invoked only by objects of the defining class and its subclasses. Access is kept within the family.
*'''private''':Private methods cannot be called with an explicit receiver - the receiver is always self. Thus private methods can be called only in the context of the current object and cannot be invoked by another object's private methods.

Access control in Ruby is determined [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically], as the program runs, not statically. You will get an access violation only when the code attempts to execute the restricted method<ref>http://rubylearning.com/satishtalim/ruby_access_control.html</ref>.

===C#===
The following access modifiers specify the accessibility levels in C#
*'''public''':Any public method or member can be accessed by any other code in the same or different package.
*'''private''':The method or member can only be accessed from within the same class.
*'''protected''':The method or member can be accessed only from within the same Class or from within any of the subclasses.
*'''internal''':The type or member can be accessed by any code in the same assembly, but not from another assembly. An assembly in C# is the rough equivalent of a package in java.
*'''protected internal''':The type or member can be accessed by any code in the [http://msdn.microsoft.com/en-us/library/ms173099.aspx Assembly] (also see [http://msdn.microsoft.com/en-us/library/ms173099(v=vs.80).aspx this]) in which it is declared, or from within a derived class in another assembly. Access from another assembly must take place within a class declaration that derives from the class in which the protected internal element is declared, and it must take place through an instance of the derived class type.

===Summary of Access Specfiers in C++, Java, Ruby and C#:===
{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Access Level
! C++
! Java
! Ruby
! C#
|-
! Public
| Anything can access
| Anything can access
| Anything can access
| Anything can access
|-
! Protected
| Class, Subclasses and friends
| Class, Subclasses and classes of same package
| Class and Subclasses
| Class and Subclasses
|-
! Private
| Within Class
| Within Class
| Within Class
| Within Class
|-
! Internal
| --
| --
| --
| Any Class from same Assembly
|-
! Protected internal
| --
| --
| --
| Any Class from same Assembly and Subclass from any Assembly.
|}

==Examples of Access Specifiers==
The following examples exhibit the use of the access specifiers and getter methods for the aforementioned Bank Account example.

===C++===
<pre>
class BankAccount {
private:
char routingNumber;
char accountNumber;

protected:
int balance;

public:
BankAccount(char *, char *);
void changeAccountNumber(char *);
void changeRoutingNumber(char *);
void depositMoney(int);
void withdrawMoney(int);
friend void displayAccountInfo();
}

BankAccount::BankAccount(char *rNo, char *accNo) {
Strcpy(routingNumber, rNo);
Strcpy(accountNumber, accNo);
balance = 0;
}

BankAccount::void changeAccountNumber(char *accNo){
Strcpy(accountNumber, accNo);
}

BankAccount::void changeRoutingNumber(char *rNo){
Strcpy(routingNumber, rNo);
}

BankAccount::void depositMoney(int amount) {
balance += amount;
}

BankAccount::void withdrawMoney(int amount) {
balance -= amount;
}

// Friend function can access both the private and protected members
// of BankAccount.
void displayAccountInfo(BankAccount ba) {
cout << “Account Number: ” << ba.accountNumber << endl;
cout << “Routing Number: ” << ba.routingNumber << endl;
cout << “Account Balance: ” << ba.balance << endl << endl;
}

// CheckingAccount inherits from BankAccount. Hence it can access only the
// public and protected members of BankAccount. It cannot access the private
// members of BankAccount.
class CheckingAccount: public BankAccount {
private:
char accountType[20];

public:
CheckingAccount(char *, char *);
void resetBalance();
}

CheckingAccount::CheckingAccount(char *rNo, char *accNo) {
Strcpy(accountType, "Checking");
changeRoutingNumber(rNo);
changeAccountNumber (accNo);
balance = 0;
}

// Since balance is a protected field, it can be accessed by CheckingAccount
CheckingAccount::void resetBalance() {
balance = 0;
}

int main() {
CheckingAccount ca("888", "999");
ca.depositMoney(100);
displayAccountInfo(ca);
ca.withdrawMoney(50);
displayAccountInfo(ca);
ca.resetBalance();
displayAccountInfo(ca);
}

</pre>

<pre>
OUTPUT:

Account Number: 888
Routing Number: 999
Account Balance: 100

Account Number: 888
Routing Number: 999
Account Balance: 50

Account Number: 888
Routing Number: 999
Account Balance: 0
</pre>

The data members routingNumber, accountNumber are made private and balance is protected. This makes it impossible to directly access or change routingNumber, accountNumber from outside code. Access to these attributes are strictly through the public methods changeRoutingNumber() and changeAccountNumber(). However, private and protected members are accessible through friend functions, so displayAccountInfo() function is able to access all the mentioned fields. Since balance is protected, it can be accessed from a subclass (CheckingAccount) directly as shown above. But the private members have to be accessed through the functions changeRoutingNumber() and changeAccountNumber() instead of being accessed directly.

Thus, it purely at the discretion of the programmer to allow access to these data members through such accessor functions. In the absence of such accessors, there would be no way for any code outside the class to view/modify the private attributes.

===Java===

<pre>
public class BankAccount {
String accountNumber;
private String routingNumber;
private Integer balance;

//setter methods for accountNumber allows public acccess to it.
public void setAccountNumber(String acNo){
this.accountNumber=acNo;
}

//setter methods for routingNumber allows public acccess to it.
public void setRoutingNumber(String rtNo){
this.routingNumber=rtNo;
}

//setter methods for balance allows only 'protected' access to it (see definition).
protected void setBalance(Integer bal){
this.balance=bal;
}

// Getter method allows accountNumber to be read publicly
public String getAccountNumber(){
return this.accountNumber;
}

// Getter method allows routingNumber to be read publicly
public String getRoutingNumber(){
return this.routingNumber;
}

// Getter method allows balance to be read only in in a 'protected' fashion (see definition).
protected Integer getBalance(){
return this.balance;
}

public void showAccountNumber(){
System.out.println(this.accountNumber);
}

public void showRoutingNumber(){
System.out.println(this.routingNumber);
}

public void showBalance(){
System.out.println(this.balance);
}

public void withdraw(Integer amount){
this.balance-=amount;
}

public void deposit(Integer amount){
this.balance+=amount;
}

public static void main(String args[]){
BankAccount Steve = new BankAccount();

//public access to setRoutingNumber/getRoutingNumber
Steve.setRoutingNumber("1234");
String steveRtNo=Steve.getRoutingNumber();
System.out.println(steveRtNo);

//protected access to the method setBalance/getBalance
Steve.setBalance(5000);
System.out.println(Steve.getBalance());
}

}
</pre>

Class BankAccount in the above Java code has public getter/setter methods to access the private data member ‘routingNumber’. Thus, we can invoke these methods using an instance of the BankAccount object: Steve.
The methods setBalance()/ getBalance() are protected. As can be seen, they behave like public methods if invoked in the same package. Protected methods act like private methods if invoked by any instance of a class outside the package.
However, if there is a class ‘InternationalBankAccount’ in a different package such that:
<pre>
public class InternationalBankAccount extends BankAccount {
public String internationalBankAccNo;
}
</pre>

<pre>
InternationalBankAccount Anna = new InternationalBankAccount();
Anna.setBalance(10000);
</pre>

The above is a valid syntax and Anna can access protected member functions of the parent class.
Data member ‘accountNumber’ has default access specifier. Default access specifier is used in Java to support package driven development. Thus ‘accountNumber’ can be accessed from anywhere within the package. However no classes from other packages can access ‘accountNumber’.
Data member balance is a private data member and if it is invoked explicitly as follows,
<pre>
Steve.balance=1000;
</pre>
then the output would be an unresolved compilation error of the form:
<pre>
Unresolved compilation problem: The field bankAccount.balance is not visible
</pre>

===Ruby===
The following code illustrates the use of access specifiers in Ruby.
<pre>
class BankAccount

def initialize(acNo, rtNo, bal)
@accountNumber = acNo
@routingNumber = rtNo
@balance = bal
end

def balance
@balance
end

def routingNumber
@routingNumber
end

def accountNumber
@accountNumber
end

def compare_balance(other)
if other.balance > balance
"The other object has more bank balance."
else
"This object has more bank balance."
end
end

protected:balance
public:routingNumber
private:accountNumber

end
</pre>

<pre>
Steve = BankAccount.new(713, 123, 1000)
Anna = BankAccount.new(923, 125, 2000)
puts Steve.routingNumber()
puts Steve.compare_balance (Anna)
puts Steve.accountNumber()
</pre>

<pre>
Output:
123
The other object has more bank balance.
NoMethodError: private method `accountNumber' called for #<BankAccount:0x2b75320>
</pre>

‘routingNumber’ is a public function. Thus, when we access object Steve’s public method ‘routing number’, we successfully get ‘123’ as the output.
Furthermore, this snippet provides a mechanism for the comparison of one account holder’s balance with another. This comparison involves a call to the method ‘balance’. The object performing the comparison has to ask the other object to execute its balance method. So, balance cannot be private. With ‘balance’ changed to protected instead of private, Steve can ask Anna to execute ‘balance’, because both are instances of the same class. But if we try to call the ‘balance’ method of a bankAccount object when ‘self’ is anything other than a bankAccount object, the method will fail. A protected method is thus just like a private method, but with the exemption for those cases where the class of ‘self’ and the class of the respective object (having the method called on it) are the same.
‘accountNumber’ method is private. Thus user gets a ‘NoMethodError’ on invoking object Steve’s ‘accountNumber’ method. Initialize method in a class is private by default. Whenever the new method is invoked, initialize method is called and instances are created. If we try to invoke the ‘initialize’ method explicitly, we get the same error as in the case when we tried to invoke object Steve’s private ‘accountNumber’ method.

===C#===
<pre>
class BankAccount
{
public BankAccount(string accountNumber, string routingNumber, int balance)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
this.balance = balance;
}

private string accountNumber;
protected string routingNumber;
private int balance;

// accountNumber is private, so it can only be modified from within this
// class. Also, since the following method is private, it can only be called
// from within this class. So this field is truly private.
private void setAccountNumber(string acNo)
{
this.accountNumber=acNo;
}

// routingNumber is protected, so it can be directly modified by objects of
// a subclass. But the contents of this field are made accessible as public
// so anyone can 'read' the value of this field.
public string getRoutingNumber()
{
return this.routingNumber;
}

// Provides access to modify the private member balance, but this function
// can only be called by subclasses (and from within this class).
protected initBalance()
{
this.balance = 0;
}

// Provides access to 'read' the contents of the private field to everyone.
public void getBalance(int balance)
{
return this.balance;
}
}

class Customer : BankAccount
{
Customer(string accountNumber, string routingNumber)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
initBalance();
}
}

class Startup
{
public static void main()
{
Customer cust = new Customer(“999”, “888”, 100);
System.console.WriteLine(cust.getBalance);
}
}

</pre>

The Customer class inherits from the BankAccount class. All protected data members and methods of BankAccount class are accessible directly by an object of the Customer class. The private fields such as accountNumber and routingNumber are not directly accessible. Thus it is possible to call only the initBalance and getBalance methods from Customer. The initBalance method cannot be called by anyone outside the BankAccount class. Also see [http://www.informit.com/articles/article.aspx?p=101373&seqNum=3 this] for another example.

==Conclusion==
Access control is an integral component of object oriented languages and it underlines and emphasizes some of the principal ideals central to the object-oriented approach. It is possible to maximize the benefits of any O-O language by adhering to, and fully exploiting the capabilities of its access specifiers. Access control is in no way a peripheral add-on or redundant feature of O-O languages, and programmers would only stand to gain by fully appreciating, respecting and understanding their presence.

==References==
<references/>

CSC/ECE 517 Fall 2011/ch1 2b ns

2011-09-30T22:45:46Z

Sshyamr: /* Conclusion */

<h2>Access Control in Object-Oriented Languages</h2>

== Introduction ==
A fundamental precept of O-O systems is that an object should not expose any of its implementation details. In other words, access to an object’s functionality must be tightly regulated. The access control policies of any object-oriented language specify the rules and capabilities for enforcing this regulation. Thus, the concept of Access control ties in deeply with the underlying principles of [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming].

__TOC__
==Purpose of Access Control==
Object-oriented programming fundamentally revolves around the principle of Data Hiding and Encapsulation. In a nutshell, [http://en.wikipedia.org/wiki/Information_hiding Data Hiding] is the practice of securing data by constraining access to it, and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] ensures that the secure data (and the respective member functions) are bundled together as an individual module. All object oriented languages thus need to control the level of access to their critical data (and functions) which is achieved using ''Access Modifiers'' or ''Access Specifiers'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

The need to strictly control ''who'' can access ''what'' is very crucial in Software development. For example, if you make an instance variable 'public', then you can't change the field as the class evolves over time since you might break any external code that uses the field. This is because outside code having complete access to this field, has tied itself indelibly to the inside implementation of the (former) class and is now closely dependent on it. Changing the said field thus entails changing all the other code that have a dependency on it, which is cumbersome, unwieldy and contrary to the principles of an Object Oriented approach which strives for [http://en.wikipedia.org/wiki/Coupling_(computer_programming) Low Coupling].

Thus, the ‘Implementation hiding principle’ leads to a good acid test of an O-O system's quality: Can you make massive changes to a class definition—even throw out the whole thing and replace it with a completely different implementation—without impacting any of the code that uses that class's objects? This sort of modularization is the central premise of object orientation and makes maintenance much easier. Without implementation hiding, there's little point in using other O-O features. Regulation of access - Access Control - is at the heart of Object oriented programming<ref>http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html</ref>.

==Evolution of Access Control and proliferation of Accessor methods==
Access control has been a part of the OOP movement ever since its inception. [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] is arguably one of first and purest of the many O-O languages and was developed by Xerox PARC in the Learning Research Group in the 1970s <ref>http://www.zdnet.com/blog/murphy/the-tattered-history-of-oop/1157</ref>. Rather than having explicit access specifiers, smalltalk objects operated more in the sense of 'states' i.e. it would hold the 'state' of object(s) which is always private to that object. Any changes required to be made to this state, had to be sent as a request message to that object. This is the most primitive form of access control - having private data members and public member functions - the only difference being that the access levels are not being explicitly specified.

Access control has evolved over time to become highly complicated <ref>http://www.exforsys.com/tutorials/oops/the-use-of-access-specifiers-in-object-oriented-programming.html</ref> because the requirements of computing and software development have ballooned considerably in last decade and a half. Complex software requirements mandates complexity in languages, and this has indeed affected the access control policies, which have evolved into something comprehensive, yet - at times - convoluted. Unfortunately today's developers often lose sight of the fundamental motivation behind the existence of extensive access control and lose out on much of the benefits of having a highly cohesive, low coupled system <ref>http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref>.

To elaborate, it has become somewhat of an involuntary practice for present programmers to make ''all'' data members of a class private and provide accessor methods (getters/setters) to all of them (data members). Developers have come to accept this to be a contemporary programmatic-paradigm and by supplying setters and getters for ''everything'', defeat the very purpose of making class-fields private. A long time ago programmers discovered that reducing the scope (visibility) of data as much as possible leads to more reliable and maintainable code<ref>http://typicalprogrammer.com/?p=23</ref>.

Every getter and setter in one’s code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters is a sign of a poorly-designed set of classes. Java <ref>http://www.eclipse-blog.org/eclipse-ide/auto-generating-getters-and-setters.html</ref> and C# <ref>http://forums.asp.net/t/941864.aspx/1</ref> developers have IDEs that generate getters and setters automatically, implying that accessors are a good idea and thus contribute to that popular belief. That is not to say that one must completely abstain from accessors, but rather re-analyze and - if required - redesign the class structure to involve as little exposure of its data members as can be achieved.

==Access Control: A typical example==
Empirically, the data members of a class are held private, and the member functions (public) act as the end points of this class. Via these public methods, one can access the ‘state’ of an object. The following example illustrates this point and shows how access to the data members of a class are specified and controlled by the access modifiers.

[http://en.wikipedia.org/wiki/UML_Diagram#Diagrams_overview UML Diagram] of a BankAccount Class.

[[Image:BankAccount_UML.png|650px|thumb|center|Typical UML diagram of BankAccount.]]

The “(-)/(+)” preceding the members of this class represent the associated access levels. (-) indicates private and (+) indicates public.
The data members ‘accountNumber’, ‘routingNumber’ and ‘balance’ are maintained as private. Thus, an instance of a ‘Customer’ Object (say) cannot directly access or modify this data. Customer has to interact with the public behavior bundled in this module which allows him to view his account information and/or withdraw/deposit money i.e. his visibility of the class is only restricted to that which is made public by the Class.

Using such access specifiers, we can control the level of security and visibility associated with the members of a class. Thus, an Access Specifier can be roughly defined as ''‘A keyword applied to a variable, method, etc. that indicates which other parts of the code are permitted to access it’'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

==Common Access Specifiers in O-O languages==

Although all access specifiers essentially provide the same functionality, their semantics differ among different O-O languages. Here is how access control is implemented in some of the more common O-O languages.

===C++===
*'''private''':All members of the Class that are declared as private can only be accessed by the class's member functions and [http://en.wikipedia.org/wiki/Friend_class friends] of the class.
*'''protected''':All members of the Class that are declared as protected can be accessed by that class's member functions and friends (classes or functions) of the class. Moreover, classes derived from the class also have access to these elements.
*'''public''':Any class or method can have access to these type of elements.

===Java===
Java offers four access specifiers, listed below in order of decreasing accessibility:
*'''public''': All public classes, methods, and fields are the least secure. The Public access specifier must be used if you explicitly want to offer access to these entities and if this access cannot do any conceivable harm.
*'''protected''': Protected methods and fields can only be accessed within the same class to which the methods and fields belong, within its subclasses, and within classes present in the same [http://download.oracle.com/javase/tutorial/java/concepts/package.html Package]. Use of protected access specifier thus only allows its fields to be accessed by those classes which have some semblance of correlation to it - be it in the form of subclasses (correlation through inheritance) or classes within the same package (logical and/or functional correlation i.e. classes in the same package have ''something'' logical/functional common to them <ref>http://download.oracle.com/javase/tutorial/java/concepts/package.html</ref>).
*'''default '''(no specifier): Default access specifier is Java’s fail-safe way to handle security. Via the default access specifier, a class, method, or field will be accessible from inside the same package to which the class, method, or field belongs, but not from outside this package. Default access is thus suited when the source code is compartmentalized and organized into packages.
*'''private''': Private access specifier is a way to secure vital members of a class. Private methods and fields can only be accessed within the same class to which the methods and fields belong. Private methods and fields are not visible within subclasses and are not inherited by subclasses.

===Ruby===
Ruby gives you three levels of protection, listed below in order of decreasing accessibility:
*'''public''':Public methods can be called by everyone - no access control is enforced. A class's instance methods are public by default.
*'''protected''':Protected methods can be invoked only by objects of the defining class and its subclasses. Access is kept within the family.
*'''private''':Private methods cannot be called with an explicit receiver - the receiver is always self. Thus private methods can be called only in the context of the current object and cannot be invoked by another object's private methods.

Access control in Ruby is determined [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically], as the program runs, not statically. You will get an access violation only when the code attempts to execute the restricted method<ref>http://rubylearning.com/satishtalim/ruby_access_control.html</ref>.

===C#===
The following access modifiers specify the accessibility levels in C#
*'''public''':Any public method or member can be accessed by any other code in the same or different package.
*'''private''':The method or member can only be accessed from within the same class.
*'''protected''':The method or member can be accessed only from within the same Class or from within any of the subclasses.
*'''internal''':The type or member can be accessed by any code in the same assembly, but not from another assembly. An assembly in C# is the rough equivalent of a package in java.
*'''protected internal''':The type or member can be accessed by any code in the [http://msdn.microsoft.com/en-us/library/ms173099.aspx Assembly] (also see [http://msdn.microsoft.com/en-us/library/ms173099(v=vs.80).aspx this]) in which it is declared, or from within a derived class in another assembly. Access from another assembly must take place within a class declaration that derives from the class in which the protected internal element is declared, and it must take place through an instance of the derived class type.

===Summary of Access Specfiers in C++, Java, Ruby and C#:===
{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Access Level
! C++
! Java
! Ruby
! C#
|-
! Public
| Anything can access
| Anything can access
| Anything can access
| Anything can access
|-
! Protected
| Class, Subclasses and friends
| Class, Subclasses and classes of same package
| Class and Subclasses
| Class and Subclasses
|-
! Private
| Within Class
| Within Class
| Within Class
| Within Class
|-
! Internal
| --
| --
| --
| Any Class from same Assembly
|-
! Protected internal
| --
| --
| --
| Any Class from same Assembly and Subclass from any Assembly.
|}

==Examples of Access Specifiers==
The following examples exhibit the use of the access specifiers and getter methods for the aforementioned Bank Account example.

===C++===
<pre>
class BankAccount {
private:
char routingNumber;
char accountNumber;

protected:
int balance;

public:
BankAccount(char *, char *);
void changeAccountNumber(char *);
void changeRoutingNumber(char *);
void depositMoney(int);
void withdrawMoney(int);
friend void displayAccountInfo();
}

BankAccount::BankAccount(char *rNo, char *accNo) {
Strcpy(routingNumber, rNo);
Strcpy(accountNumber, accNo);
balance = 0;
}

BankAccount::void changeAccountNumber(char *accNo){
Strcpy(accountNumber, accNo);
}

BankAccount::void changeRoutingNumber(char *rNo){
Strcpy(routingNumber, rNo);
}

BankAccount::void depositMoney(int amount) {
balance += amount;
}

BankAccount::void withdrawMoney(int amount) {
balance -= amount;
}

// Friend function can access both the private and protected members
// of BankAccount.
void displayAccountInfo(BankAccount ba) {
cout << “Account Number: ” << ba.accountNumber << endl;
cout << “Routing Number: ” << ba.routingNumber << endl;
cout << “Account Balance: ” << ba.balance << endl << endl;
}

// CheckingAccount inherits from BankAccount. Hence it can access only the
// public and protected members of BankAccount. It cannot access the private
// members of BankAccount.
class CheckingAccount: public BankAccount {
private:
char accountType[20];

public:
CheckingAccount(char *, char *);
void resetBalance();
}

CheckingAccount::CheckingAccount(char *rNo, char *accNo) {
Strcpy(accountType, "Checking");
changeRoutingNumber(rNo);
changeAccountNumber (accNo);
balance = 0;
}

// Since balance is a protected field, it can be accessed by CheckingAccount
CheckingAccount::void resetBalance() {
balance = 0;
}

int main() {
CheckingAccount ca("888", "999");
ca.depositMoney(100);
displayAccountInfo(ca);
ca.withdrawMoney(50);
displayAccountInfo(ca);
ca.resetBalance();
displayAccountInfo(ca);
}

</pre>

<pre>
OUTPUT:

Account Number: 888
Routing Number: 999
Account Balance: 100

Account Number: 888
Routing Number: 999
Account Balance: 50

Account Number: 888
Routing Number: 999
Account Balance: 0
</pre>

The data members routingNumber, accountNumber are made private and balance is protected. This makes it impossible to directly access or change routingNumber, accountNumber from outside code. Access to these attributes are strictly through the public methods changeRoutingNumber() and changeAccountNumber(). However, private and protected members are accessible through friend functions, so displayAccountInfo() function is able to access all the mentioned fields. Since balance is protected, it can be accessed from a subclass (CheckingAccount) directly as shown above. But the private members have to be accessed through the functions changeRoutingNumber() and changeAccountNumber() instead of being accessed directly.

Thus, it purely at the discretion of the programmer to allow access to these data members through such accessor functions. In the absence of such accessors, there would be no way for any code outside the class to view/modify the private attributes.

===Java===

<pre>
public class BankAccount {
String accountNumber;
private String routingNumber;
private Integer balance;

public void setAccountNumber(String acNo){
this.accountNumber=acNo;
}

public void setRoutingNumber(String rtNo){
this.routingNumber=rtNo;
}

protected void setBalance(Integer bal){
this.balance=bal;
}

public String getAccountNumber(){
return this.accountNumber;
}

public String getRoutingNumber(){
return this.routingNumber;
}

protected Integer getBalance(){
return this.balance;
}

public void showAccountNumber(){
System.out.println(this.accountNumber);
}

public void showRoutingNumber(){
System.out.println(this.routingNumber);
}

public void showBalance(){
System.out.println(this.balance);
}

public void withdraw(Integer amount){
this.balance-=amount;
}

public void deposit(Integer amount){
this.balance+=amount;
}

public static void main(String args[]){
BankAccount Steve = new BankAccount();

//public access to setRoutingNumber/getRoutingNumber
Steve.setRoutingNumber("1234");
String steveRtNo=Steve.getRoutingNumber();
System.out.println(steveRtNo);

//protected access to the method setBalance/getBalance
Steve.setBalance(5000);
System.out.println(Steve.getBalance());
}

}
</pre>

Class BankAccount in the above Java code has public getter/setter methods to access the private data member ‘routingNumber’. Thus, we can invoke these methods using an instance of the BankAccount object: Steve.
The methods setBalance()/ getBalance() are protected. As can be seen, they behave like public methods if invoked in the same package. Protected methods act like private methods if invoked by any instance of a class outside the package.
However, if there is a class ‘InternationalBankAccount’ in a different package such that:
<pre>
public class InternationalBankAccount extends BankAccount {
public String internationalBankAccNo;
}
</pre>

<pre>
InternationalBankAccount Anna = new InternationalBankAccount();
Anna.setBalance(10000);
</pre>

The above is a valid syntax and Anna can access protected member functions of the parent class.
Data member ‘accountNumber’ has default access specifier. Default access specifier is used in Java to support package driven development. Thus ‘accountNumber’ can be accessed from anywhere within the package. However no classes from other packages can access ‘accountNumber’.
Data member balance is a private data member and if it is invoked explicitly as follows,
<pre>
Steve.balance=1000;
</pre>
then the output would be an unresolved compilation error of the form:
<pre>
Unresolved compilation problem: The field bankAccount.balance is not visible
</pre>

===Ruby===
The following code illustrates the use of access specifiers in Ruby.
<pre>
class BankAccount

def initialize(acNo, rtNo, bal)
@accountNumber = acNo
@routingNumber = rtNo
@balance = bal
end

def balance
@balance
end

def routingNumber
@routingNumber
end

def accountNumber
@accountNumber
end

def compare_balance(other)
if other.balance > balance
"The other object has more bank balance."
else
"This object has more bank balance."
end
end

protected:balance
public:routingNumber
private:accountNumber

end
</pre>

<pre>
Steve = BankAccount.new(713, 123, 1000)
Anna = BankAccount.new(923, 125, 2000)
puts Steve.routingNumber()
puts Steve.compare_balance (Anna)
puts Steve.accountNumber()
</pre>

<pre>
Output:
123
The other object has more bank balance.
NoMethodError: private method `accountNumber' called for #<BankAccount:0x2b75320>
</pre>

‘routingNumber’ is a public function. Thus, when we access object Steve’s public method ‘routing number’, we successfully get ‘123’ as the output.
Furthermore, this snippet provides a mechanism for the comparison of one account holder’s balance with another. This comparison involves a call to the method ‘balance’. The object performing the comparison has to ask the other object to execute its balance method. So, balance cannot be private. With ‘balance’ changed to protected instead of private, Steve can ask Anna to execute ‘balance’, because both are instances of the same class. But if we try to call the ‘balance’ method of a bankAccount object when ‘self’ is anything other than a bankAccount object, the method will fail. A protected method is thus just like a private method, but with the exemption for those cases where the class of ‘self’ and the class of the respective object (having the method called on it) are the same.
‘accountNumber’ method is private. Thus user gets a ‘NoMethodError’ on invoking object Steve’s ‘accountNumber’ method. Initialize method in a class is private by default. Whenever the new method is invoked, initialize method is called and instances are created. If we try to invoke the ‘initialize’ method explicitly, we get the same error as in the case when we tried to invoke object Steve’s private ‘accountNumber’ method.

===C#===
<pre>
class BankAccount
{
public BankAccount(string accountNumber, string routingNumber, int balance)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
this.balance = balance;
}

private string accountNumber;
protected string routingNumber;
private int balance;

// accountNumber is private, so it can only be modified from within this
// class. Also, since the following method is private, it can only be called
// from within this class. So this field is truly private.
private void setAccountNumber(string acNo)
{
this.accountNumber=acNo;
}

// routingNumber is protected, so it can be directly modified by objects of
// a subclass. But the contents of this field are made accessible as public
// so anyone can 'read' the value of this field.
public string getRoutingNumber()
{
return this.routingNumber;
}

// Provides access to modify the private member balance, but this function
// can only be called by subclasses (and from within this class).
protected initBalance()
{
this.balance = 0;
}

// Provides access to 'read' the contents of the private field to everyone.
public void getBalance(int balance)
{
return this.balance;
}
}

class Customer : BankAccount
{
Customer(string accountNumber, string routingNumber)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
initBalance();
}
}

class Startup
{
public static void main()
{
Customer cust = new Customer(“999”, “888”, 100);
System.console.WriteLine(cust.getBalance);
}
}

</pre>

The Customer class inherits from the BankAccount class. All protected data members and methods of BankAccount class are accessible directly by an object of the Customer class. The private fields such as accountNumber and routingNumber are not directly accessible. Thus it is possible to call only the initBalance and getBalance methods from Customer. The initBalance method cannot be called by anyone outside the BankAccount class. Also see [http://www.informit.com/articles/article.aspx?p=101373&seqNum=3 this] for another example.

==Conclusion==
Access control is an integral component of object oriented languages and it underlines and emphasizes some of the principal ideals central to the object-oriented approach. It is possible to maximize the benefits of any O-O language by adhering to, and fully exploiting the capabilities of its access specifiers. Access control is in no way a peripheral add-on or redundant feature of O-O languages, and programmers would only stand to gain by fully appreciating, respecting and understanding their presence.

==References==
<references/>

CSC/ECE 517 Fall 2011/ch1 2b ns

2011-09-30T22:45:05Z

Sshyamr: /* Examples of Access Specifiers */

<h2>Access Control in Object-Oriented Languages</h2>

== Introduction ==
A fundamental precept of O-O systems is that an object should not expose any of its implementation details. In other words, access to an object’s functionality must be tightly regulated. The access control policies of any object-oriented language specify the rules and capabilities for enforcing this regulation. Thus, the concept of Access control ties in deeply with the underlying principles of [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming].

__TOC__
==Purpose of Access Control==
Object-oriented programming fundamentally revolves around the principle of Data Hiding and Encapsulation. In a nutshell, [http://en.wikipedia.org/wiki/Information_hiding Data Hiding] is the practice of securing data by constraining access to it, and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] ensures that the secure data (and the respective member functions) are bundled together as an individual module. All object oriented languages thus need to control the level of access to their critical data (and functions) which is achieved using ''Access Modifiers'' or ''Access Specifiers'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

The need to strictly control ''who'' can access ''what'' is very crucial in Software development. For example, if you make an instance variable 'public', then you can't change the field as the class evolves over time since you might break any external code that uses the field. This is because outside code having complete access to this field, has tied itself indelibly to the inside implementation of the (former) class and is now closely dependent on it. Changing the said field thus entails changing all the other code that have a dependency on it, which is cumbersome, unwieldy and contrary to the principles of an Object Oriented approach which strives for [http://en.wikipedia.org/wiki/Coupling_(computer_programming) Low Coupling].

Thus, the ‘Implementation hiding principle’ leads to a good acid test of an O-O system's quality: Can you make massive changes to a class definition—even throw out the whole thing and replace it with a completely different implementation—without impacting any of the code that uses that class's objects? This sort of modularization is the central premise of object orientation and makes maintenance much easier. Without implementation hiding, there's little point in using other O-O features. Regulation of access - Access Control - is at the heart of Object oriented programming<ref>http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html</ref>.

==Evolution of Access Control and proliferation of Accessor methods==
Access control has been a part of the OOP movement ever since its inception. [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] is arguably one of first and purest of the many O-O languages and was developed by Xerox PARC in the Learning Research Group in the 1970s <ref>http://www.zdnet.com/blog/murphy/the-tattered-history-of-oop/1157</ref>. Rather than having explicit access specifiers, smalltalk objects operated more in the sense of 'states' i.e. it would hold the 'state' of object(s) which is always private to that object. Any changes required to be made to this state, had to be sent as a request message to that object. This is the most primitive form of access control - having private data members and public member functions - the only difference being that the access levels are not being explicitly specified.

Access control has evolved over time to become highly complicated <ref>http://www.exforsys.com/tutorials/oops/the-use-of-access-specifiers-in-object-oriented-programming.html</ref> because the requirements of computing and software development have ballooned considerably in last decade and a half. Complex software requirements mandates complexity in languages, and this has indeed affected the access control policies, which have evolved into something comprehensive, yet - at times - convoluted. Unfortunately today's developers often lose sight of the fundamental motivation behind the existence of extensive access control and lose out on much of the benefits of having a highly cohesive, low coupled system <ref>http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref>.

To elaborate, it has become somewhat of an involuntary practice for present programmers to make ''all'' data members of a class private and provide accessor methods (getters/setters) to all of them (data members). Developers have come to accept this to be a contemporary programmatic-paradigm and by supplying setters and getters for ''everything'', defeat the very purpose of making class-fields private. A long time ago programmers discovered that reducing the scope (visibility) of data as much as possible leads to more reliable and maintainable code<ref>http://typicalprogrammer.com/?p=23</ref>.

Every getter and setter in one’s code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters is a sign of a poorly-designed set of classes. Java <ref>http://www.eclipse-blog.org/eclipse-ide/auto-generating-getters-and-setters.html</ref> and C# <ref>http://forums.asp.net/t/941864.aspx/1</ref> developers have IDEs that generate getters and setters automatically, implying that accessors are a good idea and thus contribute to that popular belief. That is not to say that one must completely abstain from accessors, but rather re-analyze and - if required - redesign the class structure to involve as little exposure of its data members as can be achieved.

==Access Control: A typical example==
Empirically, the data members of a class are held private, and the member functions (public) act as the end points of this class. Via these public methods, one can access the ‘state’ of an object. The following example illustrates this point and shows how access to the data members of a class are specified and controlled by the access modifiers.

[http://en.wikipedia.org/wiki/UML_Diagram#Diagrams_overview UML Diagram] of a BankAccount Class.

[[Image:BankAccount_UML.png|650px|thumb|center|Typical UML diagram of BankAccount.]]

The “(-)/(+)” preceding the members of this class represent the associated access levels. (-) indicates private and (+) indicates public.
The data members ‘accountNumber’, ‘routingNumber’ and ‘balance’ are maintained as private. Thus, an instance of a ‘Customer’ Object (say) cannot directly access or modify this data. Customer has to interact with the public behavior bundled in this module which allows him to view his account information and/or withdraw/deposit money i.e. his visibility of the class is only restricted to that which is made public by the Class.

Using such access specifiers, we can control the level of security and visibility associated with the members of a class. Thus, an Access Specifier can be roughly defined as ''‘A keyword applied to a variable, method, etc. that indicates which other parts of the code are permitted to access it’'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

==Common Access Specifiers in O-O languages==

Although all access specifiers essentially provide the same functionality, their semantics differ among different O-O languages. Here is how access control is implemented in some of the more common O-O languages.

===C++===
*'''private''':All members of the Class that are declared as private can only be accessed by the class's member functions and [http://en.wikipedia.org/wiki/Friend_class friends] of the class.
*'''protected''':All members of the Class that are declared as protected can be accessed by that class's member functions and friends (classes or functions) of the class. Moreover, classes derived from the class also have access to these elements.
*'''public''':Any class or method can have access to these type of elements.

===Java===
Java offers four access specifiers, listed below in order of decreasing accessibility:
*'''public''': All public classes, methods, and fields are the least secure. The Public access specifier must be used if you explicitly want to offer access to these entities and if this access cannot do any conceivable harm.
*'''protected''': Protected methods and fields can only be accessed within the same class to which the methods and fields belong, within its subclasses, and within classes present in the same [http://download.oracle.com/javase/tutorial/java/concepts/package.html Package]. Use of protected access specifier thus only allows its fields to be accessed by those classes which have some semblance of correlation to it - be it in the form of subclasses (correlation through inheritance) or classes within the same package (logical and/or functional correlation i.e. classes in the same package have ''something'' logical/functional common to them <ref>http://download.oracle.com/javase/tutorial/java/concepts/package.html</ref>).
*'''default '''(no specifier): Default access specifier is Java’s fail-safe way to handle security. Via the default access specifier, a class, method, or field will be accessible from inside the same package to which the class, method, or field belongs, but not from outside this package. Default access is thus suited when the source code is compartmentalized and organized into packages.
*'''private''': Private access specifier is a way to secure vital members of a class. Private methods and fields can only be accessed within the same class to which the methods and fields belong. Private methods and fields are not visible within subclasses and are not inherited by subclasses.

===Ruby===
Ruby gives you three levels of protection, listed below in order of decreasing accessibility:
*'''public''':Public methods can be called by everyone - no access control is enforced. A class's instance methods are public by default.
*'''protected''':Protected methods can be invoked only by objects of the defining class and its subclasses. Access is kept within the family.
*'''private''':Private methods cannot be called with an explicit receiver - the receiver is always self. Thus private methods can be called only in the context of the current object and cannot be invoked by another object's private methods.

Access control in Ruby is determined [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically], as the program runs, not statically. You will get an access violation only when the code attempts to execute the restricted method<ref>http://rubylearning.com/satishtalim/ruby_access_control.html</ref>.

===C#===
The following access modifiers specify the accessibility levels in C#
*'''public''':Any public method or member can be accessed by any other code in the same or different package.
*'''private''':The method or member can only be accessed from within the same class.
*'''protected''':The method or member can be accessed only from within the same Class or from within any of the subclasses.
*'''internal''':The type or member can be accessed by any code in the same assembly, but not from another assembly. An assembly in C# is the rough equivalent of a package in java.
*'''protected internal''':The type or member can be accessed by any code in the [http://msdn.microsoft.com/en-us/library/ms173099.aspx Assembly] (also see [http://msdn.microsoft.com/en-us/library/ms173099(v=vs.80).aspx this]) in which it is declared, or from within a derived class in another assembly. Access from another assembly must take place within a class declaration that derives from the class in which the protected internal element is declared, and it must take place through an instance of the derived class type.

===Summary of Access Specfiers in C++, Java, Ruby and C#:===
{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Access Level
! C++
! Java
! Ruby
! C#
|-
! Public
| Anything can access
| Anything can access
| Anything can access
| Anything can access
|-
! Protected
| Class, Subclasses and friends
| Class, Subclasses and classes of same package
| Class and Subclasses
| Class and Subclasses
|-
! Private
| Within Class
| Within Class
| Within Class
| Within Class
|-
! Internal
| --
| --
| --
| Any Class from same Assembly
|-
! Protected internal
| --
| --
| --
| Any Class from same Assembly and Subclass from any Assembly.
|}

==Examples of Access Specifiers==
The following examples exhibit the use of the access specifiers and getter methods for the aforementioned Bank Account example.

===C++===
<pre>
class BankAccount {
private:
char routingNumber;
char accountNumber;

protected:
int balance;

public:
BankAccount(char *, char *);
void changeAccountNumber(char *);
void changeRoutingNumber(char *);
void depositMoney(int);
void withdrawMoney(int);
friend void displayAccountInfo();
}

BankAccount::BankAccount(char *rNo, char *accNo) {
Strcpy(routingNumber, rNo);
Strcpy(accountNumber, accNo);
balance = 0;
}

BankAccount::void changeAccountNumber(char *accNo){
Strcpy(accountNumber, accNo);
}

BankAccount::void changeRoutingNumber(char *rNo){
Strcpy(routingNumber, rNo);
}

BankAccount::void depositMoney(int amount) {
balance += amount;
}

BankAccount::void withdrawMoney(int amount) {
balance -= amount;
}

// Friend function can access both the private and protected members
// of BankAccount.
void displayAccountInfo(BankAccount ba) {
cout << “Account Number: ” << ba.accountNumber << endl;
cout << “Routing Number: ” << ba.routingNumber << endl;
cout << “Account Balance: ” << ba.balance << endl << endl;
}

// CheckingAccount inherits from BankAccount. Hence it can access only the
// public and protected members of BankAccount. It cannot access the private
// members of BankAccount.
class CheckingAccount: public BankAccount {
private:
char accountType[20];

public:
CheckingAccount(char *, char *);
void resetBalance();
}

CheckingAccount::CheckingAccount(char *rNo, char *accNo) {
Strcpy(accountType, "Checking");
changeRoutingNumber(rNo);
changeAccountNumber (accNo);
balance = 0;
}

// Since balance is a protected field, it can be accessed by CheckingAccount
CheckingAccount::void resetBalance() {
balance = 0;
}

int main() {
CheckingAccount ca("888", "999");
ca.depositMoney(100);
displayAccountInfo(ca);
ca.withdrawMoney(50);
displayAccountInfo(ca);
ca.resetBalance();
displayAccountInfo(ca);
}

</pre>

<pre>
OUTPUT:

Account Number: 888
Routing Number: 999
Account Balance: 100

Account Number: 888
Routing Number: 999
Account Balance: 50

Account Number: 888
Routing Number: 999
Account Balance: 0
</pre>

The data members routingNumber, accountNumber are made private and balance is protected. This makes it impossible to directly access or change routingNumber, accountNumber from outside code. Access to these attributes are strictly through the public methods changeRoutingNumber() and changeAccountNumber(). However, private and protected members are accessible through friend functions, so displayAccountInfo() function is able to access all the mentioned fields. Since balance is protected, it can be accessed from a subclass (CheckingAccount) directly as shown above. But the private members have to be accessed through the functions changeRoutingNumber() and changeAccountNumber() instead of being accessed directly.

Thus, it purely at the discretion of the programmer to allow access to these data members through such accessor functions. In the absence of such accessors, there would be no way for any code outside the class to view/modify the private attributes.

===Java===

<pre>
public class BankAccount {
String accountNumber;
private String routingNumber;
private Integer balance;

public void setAccountNumber(String acNo){
this.accountNumber=acNo;
}

public void setRoutingNumber(String rtNo){
this.routingNumber=rtNo;
}

protected void setBalance(Integer bal){
this.balance=bal;
}

public String getAccountNumber(){
return this.accountNumber;
}

public String getRoutingNumber(){
return this.routingNumber;
}

protected Integer getBalance(){
return this.balance;
}

public void showAccountNumber(){
System.out.println(this.accountNumber);
}

public void showRoutingNumber(){
System.out.println(this.routingNumber);
}

public void showBalance(){
System.out.println(this.balance);
}

public void withdraw(Integer amount){
this.balance-=amount;
}

public void deposit(Integer amount){
this.balance+=amount;
}

public static void main(String args[]){
BankAccount Steve = new BankAccount();

//public access to setRoutingNumber/getRoutingNumber
Steve.setRoutingNumber("1234");
String steveRtNo=Steve.getRoutingNumber();
System.out.println(steveRtNo);

//protected access to the method setBalance/getBalance
Steve.setBalance(5000);
System.out.println(Steve.getBalance());
}

}
</pre>

Class BankAccount in the above Java code has public getter/setter methods to access the private data member ‘routingNumber’. Thus, we can invoke these methods using an instance of the BankAccount object: Steve.
The methods setBalance()/ getBalance() are protected. As can be seen, they behave like public methods if invoked in the same package. Protected methods act like private methods if invoked by any instance of a class outside the package.
However, if there is a class ‘InternationalBankAccount’ in a different package such that:
<pre>
public class InternationalBankAccount extends BankAccount {
public String internationalBankAccNo;
}
</pre>

<pre>
InternationalBankAccount Anna = new InternationalBankAccount();
Anna.setBalance(10000);
</pre>

The above is a valid syntax and Anna can access protected member functions of the parent class.
Data member ‘accountNumber’ has default access specifier. Default access specifier is used in Java to support package driven development. Thus ‘accountNumber’ can be accessed from anywhere within the package. However no classes from other packages can access ‘accountNumber’.
Data member balance is a private data member and if it is invoked explicitly as follows,
<pre>
Steve.balance=1000;
</pre>
then the output would be an unresolved compilation error of the form:
<pre>
Unresolved compilation problem: The field bankAccount.balance is not visible
</pre>

===Ruby===
The following code illustrates the use of access specifiers in Ruby.
<pre>
class BankAccount

def initialize(acNo, rtNo, bal)
@accountNumber = acNo
@routingNumber = rtNo
@balance = bal
end

def balance
@balance
end

def routingNumber
@routingNumber
end

def accountNumber
@accountNumber
end

def compare_balance(other)
if other.balance > balance
"The other object has more bank balance."
else
"This object has more bank balance."
end
end

protected:balance
public:routingNumber
private:accountNumber

end
</pre>

<pre>
Steve = BankAccount.new(713, 123, 1000)
Anna = BankAccount.new(923, 125, 2000)
puts Steve.routingNumber()
puts Steve.compare_balance (Anna)
puts Steve.accountNumber()
</pre>

<pre>
Output:
123
The other object has more bank balance.
NoMethodError: private method `accountNumber' called for #<BankAccount:0x2b75320>
</pre>

‘routingNumber’ is a public function. Thus, when we access object Steve’s public method ‘routing number’, we successfully get ‘123’ as the output.
Furthermore, this snippet provides a mechanism for the comparison of one account holder’s balance with another. This comparison involves a call to the method ‘balance’. The object performing the comparison has to ask the other object to execute its balance method. So, balance cannot be private. With ‘balance’ changed to protected instead of private, Steve can ask Anna to execute ‘balance’, because both are instances of the same class. But if we try to call the ‘balance’ method of a bankAccount object when ‘self’ is anything other than a bankAccount object, the method will fail. A protected method is thus just like a private method, but with the exemption for those cases where the class of ‘self’ and the class of the respective object (having the method called on it) are the same.
‘accountNumber’ method is private. Thus user gets a ‘NoMethodError’ on invoking object Steve’s ‘accountNumber’ method. Initialize method in a class is private by default. Whenever the new method is invoked, initialize method is called and instances are created. If we try to invoke the ‘initialize’ method explicitly, we get the same error as in the case when we tried to invoke object Steve’s private ‘accountNumber’ method.

===C#===
<pre>
class BankAccount
{
public BankAccount(string accountNumber, string routingNumber, int balance)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
this.balance = balance;
}

private string accountNumber;
protected string routingNumber;
private int balance;

// accountNumber is private, so it can only be modified from within this
// class. Also, since the following method is private, it can only be called
// from within this class. So this field is truly private.
private void setAccountNumber(string acNo)
{
this.accountNumber=acNo;
}

// routingNumber is protected, so it can be directly modified by objects of
// a subclass. But the contents of this field are made accessible as public
// so anyone can 'read' the value of this field.
public string getRoutingNumber()
{
return this.routingNumber;
}

// Provides access to modify the private member balance, but this function
// can only be called by subclasses (and from within this class).
protected initBalance()
{
this.balance = 0;
}

// Provides access to 'read' the contents of the private field to everyone.
public void getBalance(int balance)
{
return this.balance;
}
}

class Customer : BankAccount
{
Customer(string accountNumber, string routingNumber)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
initBalance();
}
}

class Startup
{
public static void main()
{
Customer cust = new Customer(“999”, “888”, 100);
System.console.WriteLine(cust.getBalance);
}
}

</pre>

The Customer class inherits from the BankAccount class. All protected data members and methods of BankAccount class are accessible directly by an object of the Customer class. The private fields such as accountNumber and routingNumber are not directly accessible. Thus it is possible to call only the initBalance and getBalance methods from Customer. The initBalance method cannot be called by anyone outside the BankAccount class. Also see [http://www.informit.com/articles/article.aspx?p=101373&seqNum=3 this] for another example.

==Conclusion==
Access control is an integral component of object oriented languages and it underlines and emphasizes some of the pricipal ideals central to the object-oriented approach. It is possible to maximize the benefits of any O-O language by adhering to, and fully exploiting the capabilities of its access specifiers. Access control is in no way a peripheral add-on or redundant feature of O-O languages, and programmers would only stand to gain by fully appreciating, respecting and understanding their presence.

==References==
<references/>

CSC/ECE 517 Fall 2011/ch1 2b ns

2011-09-30T22:43:19Z

Sshyamr: /* Evolution of Access Control and proliferation of Accessor methods */

<h2>Access Control in Object-Oriented Languages</h2>

== Introduction ==
A fundamental precept of O-O systems is that an object should not expose any of its implementation details. In other words, access to an object’s functionality must be tightly regulated. The access control policies of any object-oriented language specify the rules and capabilities for enforcing this regulation. Thus, the concept of Access control ties in deeply with the underlying principles of [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming].

__TOC__
==Purpose of Access Control==
Object-oriented programming fundamentally revolves around the principle of Data Hiding and Encapsulation. In a nutshell, [http://en.wikipedia.org/wiki/Information_hiding Data Hiding] is the practice of securing data by constraining access to it, and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] ensures that the secure data (and the respective member functions) are bundled together as an individual module. All object oriented languages thus need to control the level of access to their critical data (and functions) which is achieved using ''Access Modifiers'' or ''Access Specifiers'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

The need to strictly control ''who'' can access ''what'' is very crucial in Software development. For example, if you make an instance variable 'public', then you can't change the field as the class evolves over time since you might break any external code that uses the field. This is because outside code having complete access to this field, has tied itself indelibly to the inside implementation of the (former) class and is now closely dependent on it. Changing the said field thus entails changing all the other code that have a dependency on it, which is cumbersome, unwieldy and contrary to the principles of an Object Oriented approach which strives for [http://en.wikipedia.org/wiki/Coupling_(computer_programming) Low Coupling].

Thus, the ‘Implementation hiding principle’ leads to a good acid test of an O-O system's quality: Can you make massive changes to a class definition—even throw out the whole thing and replace it with a completely different implementation—without impacting any of the code that uses that class's objects? This sort of modularization is the central premise of object orientation and makes maintenance much easier. Without implementation hiding, there's little point in using other O-O features. Regulation of access - Access Control - is at the heart of Object oriented programming<ref>http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html</ref>.

==Evolution of Access Control and proliferation of Accessor methods==
Access control has been a part of the OOP movement ever since its inception. [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] is arguably one of first and purest of the many O-O languages and was developed by Xerox PARC in the Learning Research Group in the 1970s <ref>http://www.zdnet.com/blog/murphy/the-tattered-history-of-oop/1157</ref>. Rather than having explicit access specifiers, smalltalk objects operated more in the sense of 'states' i.e. it would hold the 'state' of object(s) which is always private to that object. Any changes required to be made to this state, had to be sent as a request message to that object. This is the most primitive form of access control - having private data members and public member functions - the only difference being that the access levels are not being explicitly specified.

Access control has evolved over time to become highly complicated <ref>http://www.exforsys.com/tutorials/oops/the-use-of-access-specifiers-in-object-oriented-programming.html</ref> because the requirements of computing and software development have ballooned considerably in last decade and a half. Complex software requirements mandates complexity in languages, and this has indeed affected the access control policies, which have evolved into something comprehensive, yet - at times - convoluted. Unfortunately today's developers often lose sight of the fundamental motivation behind the existence of extensive access control and lose out on much of the benefits of having a highly cohesive, low coupled system <ref>http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref>.

To elaborate, it has become somewhat of an involuntary practice for present programmers to make ''all'' data members of a class private and provide accessor methods (getters/setters) to all of them (data members). Developers have come to accept this to be a contemporary programmatic-paradigm and by supplying setters and getters for ''everything'', defeat the very purpose of making class-fields private. A long time ago programmers discovered that reducing the scope (visibility) of data as much as possible leads to more reliable and maintainable code<ref>http://typicalprogrammer.com/?p=23</ref>.

Every getter and setter in one’s code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters is a sign of a poorly-designed set of classes. Java <ref>http://www.eclipse-blog.org/eclipse-ide/auto-generating-getters-and-setters.html</ref> and C# <ref>http://forums.asp.net/t/941864.aspx/1</ref> developers have IDEs that generate getters and setters automatically, implying that accessors are a good idea and thus contribute to that popular belief. That is not to say that one must completely abstain from accessors, but rather re-analyze and - if required - redesign the class structure to involve as little exposure of its data members as can be achieved.

==Access Control: A typical example==
Empirically, the data members of a class are held private, and the member functions (public) act as the end points of this class. Via these public methods, one can access the ‘state’ of an object. The following example illustrates this point and shows how access to the data members of a class are specified and controlled by the access modifiers.

[http://en.wikipedia.org/wiki/UML_Diagram#Diagrams_overview UML Diagram] of a BankAccount Class.

[[Image:BankAccount_UML.png|650px|thumb|center|Typical UML diagram of BankAccount.]]

The “(-)/(+)” preceding the members of this class represent the associated access levels. (-) indicates private and (+) indicates public.
The data members ‘accountNumber’, ‘routingNumber’ and ‘balance’ are maintained as private. Thus, an instance of a ‘Customer’ Object (say) cannot directly access or modify this data. Customer has to interact with the public behavior bundled in this module which allows him to view his account information and/or withdraw/deposit money i.e. his visibility of the class is only restricted to that which is made public by the Class.

Using such access specifiers, we can control the level of security and visibility associated with the members of a class. Thus, an Access Specifier can be roughly defined as ''‘A keyword applied to a variable, method, etc. that indicates which other parts of the code are permitted to access it’'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

==Common Access Specifiers in O-O languages==

Although all access specifiers essentially provide the same functionality, their semantics differ among different O-O languages. Here is how access control is implemented in some of the more common O-O languages.

===C++===
*'''private''':All members of the Class that are declared as private can only be accessed by the class's member functions and [http://en.wikipedia.org/wiki/Friend_class friends] of the class.
*'''protected''':All members of the Class that are declared as protected can be accessed by that class's member functions and friends (classes or functions) of the class. Moreover, classes derived from the class also have access to these elements.
*'''public''':Any class or method can have access to these type of elements.

===Java===
Java offers four access specifiers, listed below in order of decreasing accessibility:
*'''public''': All public classes, methods, and fields are the least secure. The Public access specifier must be used if you explicitly want to offer access to these entities and if this access cannot do any conceivable harm.
*'''protected''': Protected methods and fields can only be accessed within the same class to which the methods and fields belong, within its subclasses, and within classes present in the same [http://download.oracle.com/javase/tutorial/java/concepts/package.html Package]. Use of protected access specifier thus only allows its fields to be accessed by those classes which have some semblance of correlation to it - be it in the form of subclasses (correlation through inheritance) or classes within the same package (logical and/or functional correlation i.e. classes in the same package have ''something'' logical/functional common to them <ref>http://download.oracle.com/javase/tutorial/java/concepts/package.html</ref>).
*'''default '''(no specifier): Default access specifier is Java’s fail-safe way to handle security. Via the default access specifier, a class, method, or field will be accessible from inside the same package to which the class, method, or field belongs, but not from outside this package. Default access is thus suited when the source code is compartmentalized and organized into packages.
*'''private''': Private access specifier is a way to secure vital members of a class. Private methods and fields can only be accessed within the same class to which the methods and fields belong. Private methods and fields are not visible within subclasses and are not inherited by subclasses.

===Ruby===
Ruby gives you three levels of protection, listed below in order of decreasing accessibility:
*'''public''':Public methods can be called by everyone - no access control is enforced. A class's instance methods are public by default.
*'''protected''':Protected methods can be invoked only by objects of the defining class and its subclasses. Access is kept within the family.
*'''private''':Private methods cannot be called with an explicit receiver - the receiver is always self. Thus private methods can be called only in the context of the current object and cannot be invoked by another object's private methods.

Access control in Ruby is determined [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically], as the program runs, not statically. You will get an access violation only when the code attempts to execute the restricted method<ref>http://rubylearning.com/satishtalim/ruby_access_control.html</ref>.

===C#===
The following access modifiers specify the accessibility levels in C#
*'''public''':Any public method or member can be accessed by any other code in the same or different package.
*'''private''':The method or member can only be accessed from within the same class.
*'''protected''':The method or member can be accessed only from within the same Class or from within any of the subclasses.
*'''internal''':The type or member can be accessed by any code in the same assembly, but not from another assembly. An assembly in C# is the rough equivalent of a package in java.
*'''protected internal''':The type or member can be accessed by any code in the [http://msdn.microsoft.com/en-us/library/ms173099.aspx Assembly] (also see [http://msdn.microsoft.com/en-us/library/ms173099(v=vs.80).aspx this]) in which it is declared, or from within a derived class in another assembly. Access from another assembly must take place within a class declaration that derives from the class in which the protected internal element is declared, and it must take place through an instance of the derived class type.

===Summary of Access Specfiers in C++, Java, Ruby and C#:===
{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Access Level
! C++
! Java
! Ruby
! C#
|-
! Public
| Anything can access
| Anything can access
| Anything can access
| Anything can access
|-
! Protected
| Class, Subclasses and friends
| Class, Subclasses and classes of same package
| Class and Subclasses
| Class and Subclasses
|-
! Private
| Within Class
| Within Class
| Within Class
| Within Class
|-
! Internal
| --
| --
| --
| Any Class from same Assembly
|-
! Protected internal
| --
| --
| --
| Any Class from same Assembly and Subclass from any Assembly.
|}

==Examples of Access Specifiers==
The following examples exhibit the use of the access specifiers and getter methofs for the aforementioned Bank Account example.

===C++===
<pre>
class BankAccount {
private:
char routingNumber;
char accountNumber;

protected:
int balance;

public:
BankAccount(char *, char *);
void changeAccountNumber(char *);
void changeRoutingNumber(char *);
void depositMoney(int);
void withdrawMoney(int);
friend void displayAccountInfo();
}

BankAccount::BankAccount(char *rNo, char *accNo) {
Strcpy(routingNumber, rNo);
Strcpy(accountNumber, accNo);
balance = 0;
}

BankAccount::void changeAccountNumber(char *accNo){
Strcpy(accountNumber, accNo);
}

BankAccount::void changeRoutingNumber(char *rNo){
Strcpy(routingNumber, rNo);
}

BankAccount::void depositMoney(int amount) {
balance += amount;
}

BankAccount::void withdrawMoney(int amount) {
balance -= amount;
}

// Friend function can access both the private and protected members
// of BankAccount.
void displayAccountInfo(BankAccount ba) {
cout << “Account Number: ” << ba.accountNumber << endl;
cout << “Routing Number: ” << ba.routingNumber << endl;
cout << “Account Balance: ” << ba.balance << endl << endl;
}

// CheckingAccount inherits from BankAccount. Hence it can access only the
// public and protected members of BankAccount. It cannot access the private
// members of BankAccount.
class CheckingAccount: public BankAccount {
private:
char accountType[20];

public:
CheckingAccount(char *, char *);
void resetBalance();
}

CheckingAccount::CheckingAccount(char *rNo, char *accNo) {
Strcpy(accountType, "Checking");
changeRoutingNumber(rNo);
changeAccountNumber (accNo);
balance = 0;
}

// Since balance is a protected field, it can be accessed by CheckingAccount
CheckingAccount::void resetBalance() {
balance = 0;
}

int main() {
CheckingAccount ca("888", "999");
ca.depositMoney(100);
displayAccountInfo(ca);
ca.withdrawMoney(50);
displayAccountInfo(ca);
ca.resetBalance();
displayAccountInfo(ca);
}

</pre>

<pre>
OUTPUT:

Account Number: 888
Routing Number: 999
Account Balance: 100

Account Number: 888
Routing Number: 999
Account Balance: 50

Account Number: 888
Routing Number: 999
Account Balance: 0
</pre>

The data members routingNumber, accountNumber are made private and balance is protected. This makes it impossible to directly access or change routingNumber, accountNumber from outside code. Access to these attributes are strictly through the public methods changeRoutingNumber() and changeAccountNumber(). However, private and protected members are accessible through friend functions, so displayAccountInfo() function is able to access all the mentioned fields. Since balance is protected, it can be accessed from a subclass (CheckingAccount) directly as shown above. But the private members have to be accessed through the functions changeRoutingNumber() and changeAccountNumber() instead of being accessed directly.

Thus, it purely at the discretion of the programmer to allow access to these data members through such accessor functions. In the absence of such accessors, there would be no way for any code outside the class to view/modify the private attributes.

===Java===

<pre>
public class BankAccount {
String accountNumber;
private String routingNumber;
private Integer balance;

public void setAccountNumber(String acNo){
this.accountNumber=acNo;
}

public void setRoutingNumber(String rtNo){
this.routingNumber=rtNo;
}

protected void setBalance(Integer bal){
this.balance=bal;
}

public String getAccountNumber(){
return this.accountNumber;
}

public String getRoutingNumber(){
return this.routingNumber;
}

protected Integer getBalance(){
return this.balance;
}

public void showAccountNumber(){
System.out.println(this.accountNumber);
}

public void showRoutingNumber(){
System.out.println(this.routingNumber);
}

public void showBalance(){
System.out.println(this.balance);
}

public void withdraw(Integer amount){
this.balance-=amount;
}

public void deposit(Integer amount){
this.balance+=amount;
}

public static void main(String args[]){
BankAccount Steve = new BankAccount();

//public access to setRoutingNumber/getRoutingNumber
Steve.setRoutingNumber("1234");
String steveRtNo=Steve.getRoutingNumber();
System.out.println(steveRtNo);

//protected access to the method setBalance/getBalance
Steve.setBalance(5000);
System.out.println(Steve.getBalance());
}

}
</pre>

Class BankAccount in the above Java code has public getter/setter methods to access the private data member ‘routingNumber’. Thus, we can invoke these methods using an instance of the BankAccount object: Steve.
The methods setBalance()/ getBalance() are protected. As can be seen, they behave like public methods if invoked in the same package. Protected methods act like private methods if invoked by any instance of a class outside the package.
However, if there is a class ‘InternationalBankAccount’ in a different package such that:
<pre>
public class InternationalBankAccount extends BankAccount {
public String internationalBankAccNo;
}
</pre>

<pre>
InternationalBankAccount Anna = new InternationalBankAccount();
Anna.setBalance(10000);
</pre>

The above is a valid syntax and Anna can access protected member functions of the parent class.
Data member ‘accountNumber’ has default access specifier. Default access specifier is used in Java to support package driven development. Thus ‘accountNumber’ can be accessed from anywhere within the package. However no classes from other packages can access ‘accountNumber’.
Data member balance is a private data member and if it is invoked explicitly as follows,
<pre>
Steve.balance=1000;
</pre>
then the output would be an unresolved compilation error of the form:
<pre>
Unresolved compilation problem: The field bankAccount.balance is not visible
</pre>

===Ruby===
The following code illustrates the use of access specifiers in Ruby.
<pre>
class BankAccount

def initialize(acNo, rtNo, bal)
@accountNumber = acNo
@routingNumber = rtNo
@balance = bal
end

def balance
@balance
end

def routingNumber
@routingNumber
end

def accountNumber
@accountNumber
end

def compare_balance(other)
if other.balance > balance
"The other object has more bank balance."
else
"This object has more bank balance."
end
end

protected:balance
public:routingNumber
private:accountNumber

end
</pre>

<pre>
Steve = BankAccount.new(713, 123, 1000)
Anna = BankAccount.new(923, 125, 2000)
puts Steve.routingNumber()
puts Steve.compare_balance (Anna)
puts Steve.accountNumber()
</pre>

<pre>
Output:
123
The other object has more bank balance.
NoMethodError: private method `accountNumber' called for #<BankAccount:0x2b75320>
</pre>

‘routingNumber’ is a public function. Thus, when we access object Steve’s public method ‘routing number’, we successfully get ‘123’ as the output.
Furthermore, this snippet provides a mechanism for the comparison of one account holder’s balance with another. This comparison involves a call to the method ‘balance’. The object performing the comparison has to ask the other object to execute its balance method. So, balance cannot be private. With ‘balance’ changed to protected instead of private, Steve can ask Anna to execute ‘balance’, because both are instances of the same class. But if we try to call the ‘balance’ method of a bankAccount object when ‘self’ is anything other than a bankAccount object, the method will fail. A protected method is thus just like a private method, but with the exemption for those cases where the class of ‘self’ and the class of the respective object (having the method called on it) are the same.
‘accountNumber’ method is private. Thus user gets a ‘NoMethodError’ on invoking object Steve’s ‘accountNumber’ method. Initialize method in a class is private by default. Whenever the new method is invoked, initialize method is called and instances are created. If we try to invoke the ‘initialize’ method explicitly, we get the same error as in the case when we tried to invoke object Steve’s private ‘accountNumber’ method.

===C#===
<pre>
class BankAccount
{
public BankAccount(string accountNumber, string routingNumber, int balance)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
this.balance = balance;
}

private string accountNumber;
protected string routingNumber;
private int balance;

// accountNumber is private, so it can only be modified from within this
// class. Also, since the following method is private, it can only be called
// from within this class. So this field is truly private.
private void setAccountNumber(string acNo)
{
this.accountNumber=acNo;
}

// routingNumber is protected, so it can be directly modified by objects of
// a subclass. But the contents of this field are made accessible as public
// so anyone can 'read' the value of this field.
public string getRoutingNumber()
{
return this.routingNumber;
}

// Provides access to modify the private member balance, but this function
// can only be called by subclasses (and from within this class).
protected initBalance()
{
this.balance = 0;
}

// Provides access to 'read' the contents of the private field to everyone.
public void getBalance(int balance)
{
return this.balance;
}
}

class Customer : BankAccount
{
Customer(string accountNumber, string routingNumber)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
initBalance();
}
}

class Startup
{
public static void main()
{
Customer cust = new Customer(“999”, “888”, 100);
System.console.WriteLine(cust.getBalance);
}
}

</pre>

The Customer class inherits from the BankAccount class. All protected data members and methods of BankAccount class are accessible directly by an object of the Customer class. The private fields such as accountNumber and routingNumber are not directly accessible. Thus it is possible to call only the initBalance and getBalance methods from Customer. The initBalance method cannot be called by anyone outside the BankAccount class. Also see [http://www.informit.com/articles/article.aspx?p=101373&seqNum=3 this] for another example.

==Conclusion==
Access control is an integral component of object oriented languages and it underlines and emphasizes some of the pricipal ideals central to the object-oriented approach. It is possible to maximize the benefits of any O-O language by adhering to, and fully exploiting the capabilities of its access specifiers. Access control is in no way a peripheral add-on or redundant feature of O-O languages, and programmers would only stand to gain by fully appreciating, respecting and understanding their presence.

==References==
<references/>

CSC/ECE 517 Fall 2011/ch1 2b ns

2011-09-30T17:00:36Z

Sshyamr: /* Evolution of Access Control and proliferation of Accessor methods */

<h2>Access Control in Object-Oriented Languages</h2>

== Introduction ==
A fundamental precept of O-O systems is that an object should not expose any of its implementation details. In other words, access to an object’s functionality must be tightly regulated. The access control policies of any object-oriented language specify the rules and capabilities for enforcing this regulation. Thus, the concept of Access control ties in deeply with the underlying principles of [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming].

__TOC__
==Purpose of Access Control==
Object-oriented programming fundamentally revolves around the principle of Data Hiding and Encapsulation. In a nutshell, [http://en.wikipedia.org/wiki/Information_hiding Data Hiding] is the practice of securing data by constraining access to it, and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] ensures that the secure data (and the respective member functions) are bundled together as an individual module. All object oriented languages thus need to control the level of access to their critical data (and functions) which is achieved using ''Access Modifiers'' or ''Access Specifiers'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

The need to strictly control ''who'' can access ''what'' is very crucial in Software development. For example, if you make an instance variable 'public', then you can't change the field as the class evolves over time since you might break any external code that uses the field. This is because outside code having complete access to this field, has tied itself indelibly to the inside implementation of the (former) class and is now closely dependent on it. Changing the said field thus entails changing all the other code that have a dependency on it, which is cumbersome, unwieldy and contrary to the principles of an Object Oriented approach which strives for [http://en.wikipedia.org/wiki/Coupling_(computer_programming) Low Coupling].

Thus, the ‘Implementation hiding principle’ leads to a good acid test of an O-O system's quality: Can you make massive changes to a class definition—even throw out the whole thing and replace it with a completely different implementation—without impacting any of the code that uses that class's objects? This sort of modularization is the central premise of object orientation and makes maintenance much easier. Without implementation hiding, there's little point in using other O-O features. Regulation of access - Access Control - is at the heart of Object oriented programming<ref>http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html</ref>.

==Evolution of Access Control and proliferation of Accessor methods==
Access control has been a part of the OOP movement ever since its inception. [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] is arguably one of first and purest of the many O-O languages and was developed by Xerox PARC in the Learning Research Group in the 1970s <ref>http://www.zdnet.com/blog/murphy/the-tattered-history-of-oop/1157</ref>. Rather than having explicit access specifiers, smalltalk objects operated more in the sense of 'states' i.e. it would hold the 'state' of object(s) which is always private to that object. Any changes required to be made to this state, had to be sent as a request message to that object. This is the most primitive form of access control - having private data members and public member functions - the only difference being that the access levels are not being explicitly specified.

Access control has evolved over time to become highly complicated <ref>http://www.exforsys.com/tutorials/oops/the-use-of-access-specifiers-in-object-oriented-programming.html</ref> because, the requirements of computing and software development have ballooned considerably in last decade and a half. Complex software requirements mandates complexity in languages, and this has indeed affected the access control policies, which have evolved into something comprehensive, yet - at times - convoluted. Unfortunately today's developers often lose sight of the fundamental motivation behind the existence of extensive access control and lose out on much of the benefits of having a highly cohesive, low coupled system<ref>http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref>.

To elaborate, it has become somewhat of an involuntary practice for present programmers to make ''all'' data members of a class private and provide accessor methods (getters/setters) to all of them (data members). Developers have come to accept this to be a contemporary programmatic-paradigm and by supplying setters and getters for ''everything'', defeat the very purpose of making class-fields private. A long time ago programmers discovered that reducing the scope (visibility) of data as much as possible leads to more reliable and maintainable code<ref>http://typicalprogrammer.com/?p=23</ref>.

Every getter and setter in one’s code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters is a sign of a poorly-designed set of classes. Java<ref>http://www.eclipse-blog.org/eclipse-ide/auto-generating-getters-and-setters.html</ref> and C#<ref>http://forums.asp.net/t/941864.aspx/1</ref> developers have IDEs that generate getters and setters automatically, implying that accessors are a good idea and thus contribute to that popular belief. That is not to say that one must completely abstain from accessors, but rather re-analyze and - if required - redesign the class structure to involve as little exposure of its data members as can be achieved.

==Access Control: A typical example==
Empirically, the data members of a class are held private, and the member functions (public) act as the end points of this class. Via these public methods, one can access the ‘state’ of an object. The following example illustrates this point and shows how access to the data members of a class are specified and controlled by the access modifiers.

[http://en.wikipedia.org/wiki/UML_Diagram#Diagrams_overview UML Diagram] of a BankAccount Class.

[[Image:BankAccount_UML.png|650px|thumb|center|Typical UML diagram of BankAccount.]]

The “(-)/(+)” preceding the members of this class represent the associated access levels. (-) indicates private and (+) indicates public.
The data members ‘accountNumber’, ‘routingNumber’ and ‘balance’ are maintained as private. Thus, an instance of a ‘Customer’ Object (say) cannot directly access or modify this data. Customer has to interact with the public behavior bundled in this module which allows him to view his account information and/or withdraw/deposit money i.e. his visibility of the class is only restricted to that which is made public by the Class.

Using such access specifiers, we can control the level of security and visibility associated with the members of a class. Thus, an Access Specifier can be roughly defined as ''‘A keyword applied to a variable, method, etc. that indicates which other parts of the code are permitted to access it’'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

==Common Access Specifiers in O-O languages==

Although all access specifiers essentially provide the same functionality, their semantics differ among different O-O languages. Here is how access control is implemented in some of the more common O-O languages.

===C++===
*'''private''':All members of the Class that are declared as private can only be accessed by the class's member functions and [http://en.wikipedia.org/wiki/Friend_class friends] of the class.
*'''protected''':All members of the Class that are declared as protected can be accessed by that class's member functions and friends (classes or functions) of the class. Moreover, classes derived from the class also have access to these elements.
*'''public''':Any class or method can have access to these type of elements.

===Java===
Java offers four access specifiers, listed below in order of decreasing accessibility:
*'''public''': All public classes, methods, and fields are the least secure. The Public access specifier must be used if you explicitly want to offer access to these entities and if this access cannot do any conceivable harm.
*'''protected''': Protected methods and fields can only be accessed within the same class to which the methods and fields belong, within its subclasses, and within classes present in the same [http://download.oracle.com/javase/tutorial/java/concepts/package.html Package]. Use of protected access specifier thus only allows its fields to be accessed by those classes which have some semblance of correlation to it - be it in the form of subclasses (correlation through inheritance) or classes within the same package (logical and/or functional correlation i.e. classes in the same package have ''something'' logical/functional common to them <ref>http://download.oracle.com/javase/tutorial/java/concepts/package.html</ref>).
*'''default '''(no specifier): Default access specifier is Java’s fail-safe way to handle security. Via the default access specifier, a class, method, or field will be accessible from inside the same package to which the class, method, or field belongs, but not from outside this package. Default access is thus suited when the source code is compartmentalized and organized into packages.
*'''private''': Private access specifier is a way to secure vital members of a class. Private methods and fields can only be accessed within the same class to which the methods and fields belong. Private methods and fields are not visible within subclasses and are not inherited by subclasses.

===Ruby===
Ruby gives you three levels of protection, listed below in order of decreasing accessibility:
*'''public''':Public methods can be called by everyone - no access control is enforced. A class's instance methods are public by default.
*'''protected''':Protected methods can be invoked only by objects of the defining class and its subclasses. Access is kept within the family.
*'''private''':Private methods cannot be called with an explicit receiver - the receiver is always self. Thus private methods can be called only in the context of the current object and cannot be invoked by another object's private methods.

Access control in Ruby is determined [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically], as the program runs, not statically. You will get an access violation only when the code attempts to execute the restricted method<ref>http://rubylearning.com/satishtalim/ruby_access_control.html</ref>.

===C#===
The following access modifiers specify the accessibility levels in C#
*'''public''':Any public method or member can be accessed by any other code in the same or different package.
*'''private''':The method or member can only be accessed from within the same class.
*'''protected''':The method or member can be accessed only from within the same Class or from within any of the subclasses.
*'''internal''':The type or member can be accessed by any code in the same assembly, but not from another assembly. An assembly in C# is the rough equivalent of a package in java.
*'''protected internal''':The type or member can be accessed by any code in the [http://msdn.microsoft.com/en-us/library/ms173099.aspx Assembly] (also see [http://msdn.microsoft.com/en-us/library/ms173099(v=vs.80).aspx this]) in which it is declared, or from within a derived class in another assembly. Access from another assembly must take place within a class declaration that derives from the class in which the protected internal element is declared, and it must take place through an instance of the derived class type.

===Summary of Access Specfiers in C++, Java, Ruby and C#:===
{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Access Level
! C++
! Java
! Ruby
! C#
|-
! Public
| Anything can access
| Anything can access
| Anything can access
| Anything can access
|-
! Protected
| Class, Subclasses and friends
| Class, Subclasses and classes of same package
| Class and Subclasses
| Class and Subclasses
|-
! Private
| Within Class
| Within Class
| Within Class
| Within Class
|-
! Internal
| --
| --
| --
| Any Class from same Assembly
|-
! Protected internal
| --
| --
| --
| Any Class from same Assembly and Subclass from any Assembly.
|}

==Examples of Access Specifiers==
The following examples exhibit the use of the access specifiers and getter methofs for the aforementioned Bank Account example.

===C++===
<pre>
class BankAccount {
private:
char routingNumber;
char accountNumber;

protected:
int balance;

public:
BankAccount(char *, char *);
void changeAccountNumber(char *);
void changeRoutingNumber(char *);
void depositMoney(int);
void withdrawMoney(int);
friend void displayAccountInfo();
}

BankAccount::BankAccount(char *rNo, char *accNo) {
Strcpy(routingNumber, rNo);
Strcpy(accountNumber, accNo);
balance = 0;
}

BankAccount::void changeAccountNumber(char *accNo){
Strcpy(accountNumber, accNo);
}

BankAccount::void changeRoutingNumber(char *rNo){
Strcpy(routingNumber, rNo);
}

BankAccount::void depositMoney(int amount) {
balance += amount;
}

BankAccount::void withdrawMoney(int amount) {
balance -= amount;
}

// Friend function can access both the private and protected members
// of BankAccount.
void displayAccountInfo(BankAccount ba) {
cout << “Account Number: ” << ba.accountNumber << endl;
cout << “Routing Number: ” << ba.routingNumber << endl;
cout << “Account Balance: ” << ba.balance << endl << endl;
}

// CheckingAccount inherits from BankAccount. Hence it can access only the
// public and protected members of BankAccount. It cannot access the private
// members of BankAccount.
class CheckingAccount: public BankAccount {
private:
char accountType[20];

public:
CheckingAccount(char *, char *);
void resetBalance();
}

CheckingAccount::CheckingAccount(char *rNo, char *accNo) {
Strcpy(accountType, "Checking");
changeRoutingNumber(rNo);
changeAccountNumber (accNo);
balance = 0;
}

// Since balance is a protected field, it can be accessed by CheckingAccount
CheckingAccount::void resetBalance() {
balance = 0;
}

int main() {
CheckingAccount ca("888", "999");
ca.depositMoney(100);
displayAccountInfo(ca);
ca.withdrawMoney(50);
displayAccountInfo(ca);
ca.resetBalance();
displayAccountInfo(ca);
}

</pre>

<pre>
OUTPUT:

Account Number: 888
Routing Number: 999
Account Balance: 100

Account Number: 888
Routing Number: 999
Account Balance: 50

Account Number: 888
Routing Number: 999
Account Balance: 0
</pre>

The data members routingNumber, accountNumber are made private and balance is protected. This makes it impossible to directly access or change routingNumber, accountNumber from outside code. Access to these attributes are strictly through the public methods changeRoutingNumber() and changeAccountNumber(). However, private and protected members are accessible through friend functions, so displayAccountInfo() function is able to access all the mentioned fields. Since balance is protected, it can be accessed from a subclass (CheckingAccount) directly as shown above. But the private members have to be accessed through the functions changeRoutingNumber() and changeAccountNumber() instead of being accessed directly.

Thus, it purely at the discretion of the programmer to allow access to these data members through such accessor functions. In the absence of such accessors, there would be no way for any code outside the class to view/modify the private attributes.

===Java===

<pre>
public class BankAccount {
String accountNumber;
private String routingNumber;
private Integer balance;

public void setAccountNumber(String acNo){
this.accountNumber=acNo;
}

public void setRoutingNumber(String rtNo){
this.routingNumber=rtNo;
}

protected void setBalance(Integer bal){
this.balance=bal;
}

public String getAccountNumber(){
return this.accountNumber;
}

public String getRoutingNumber(){
return this.routingNumber;
}

protected Integer getBalance(){
return this.balance;
}

public void showAccountNumber(){
System.out.println(this.accountNumber);
}

public void showRoutingNumber(){
System.out.println(this.routingNumber);
}

public void showBalance(){
System.out.println(this.balance);
}

public void withdraw(Integer amount){
this.balance-=amount;
}

public void deposit(Integer amount){
this.balance+=amount;
}

public static void main(String args[]){
BankAccount Steve = new BankAccount();

//public access to setRoutingNumber/getRoutingNumber
Steve.setRoutingNumber("1234");
String steveRtNo=Steve.getRoutingNumber();
System.out.println(steveRtNo);

//protected access to the method setBalance/getBalance
Steve.setBalance(5000);
System.out.println(Steve.getBalance());
}

}
</pre>

Class BankAccount in the above Java code has public getter/setter methods to access the private data member ‘routingNumber’. Thus, we can invoke these methods using an instance of the BankAccount object: Steve.
The methods setBalance()/ getBalance() are protected. As can be seen, they behave like public methods if invoked in the same package. Protected methods act like private methods if invoked by any instance of a class outside the package.
However, if there is a class ‘InternationalBankAccount’ in a different package such that:
<pre>
public class InternationalBankAccount extends BankAccount {
public String internationalBankAccNo;
}
</pre>

<pre>
InternationalBankAccount Anna = new InternationalBankAccount();
Anna.setBalance(10000);
</pre>

The above is a valid syntax and Anna can access protected member functions of the parent class.
Data member ‘accountNumber’ has default access specifier. Default access specifier is used in Java to support package driven development. Thus ‘accountNumber’ can be accessed from anywhere within the package. However no classes from other packages can access ‘accountNumber’.
Data member balance is a private data member and if it is invoked explicitly as follows,
<pre>
Steve.balance=1000;
</pre>
then the output would be an unresolved compilation error of the form:
<pre>
Unresolved compilation problem: The field bankAccount.balance is not visible
</pre>

===Ruby===
The following code illustrates the use of access specifiers in Ruby.
<pre>
class BankAccount

def initialize(acNo, rtNo, bal)
@accountNumber = acNo
@routingNumber = rtNo
@balance = bal
end

def balance
@balance
end

def routingNumber
@routingNumber
end

def accountNumber
@accountNumber
end

def compare_balance(other)
if other.balance > balance
"The other object has more bank balance."
else
"This object has more bank balance."
end
end

protected:balance
public:routingNumber
private:accountNumber

end
</pre>

<pre>
Steve = BankAccount.new(713, 123, 1000)
Anna = BankAccount.new(923, 125, 2000)
puts Steve.routingNumber()
puts Steve.compare_balance (Anna)
puts Steve.accountNumber()
</pre>

<pre>
Output:
123
The other object has more bank balance.
NoMethodError: private method `accountNumber' called for #<BankAccount:0x2b75320>
</pre>

‘routingNumber’ is a public function. Thus, when we access object Steve’s public method ‘routing number’, we successfully get ‘123’ as the output.
Furthermore, this snippet provides a mechanism for the comparison of one account holder’s balance with another. This comparison involves a call to the method ‘balance’. The object performing the comparison has to ask the other object to execute its balance method. So, balance cannot be private. With ‘balance’ changed to protected instead of private, Steve can ask Anna to execute ‘balance’, because both are instances of the same class. But if we try to call the ‘balance’ method of a bankAccount object when ‘self’ is anything other than a bankAccount object, the method will fail. A protected method is thus just like a private method, but with the exemption for those cases where the class of ‘self’ and the class of the respective object (having the method called on it) are the same.
‘accountNumber’ method is private. Thus user gets a ‘NoMethodError’ on invoking object Steve’s ‘accountNumber’ method. Initialize method in a class is private by default. Whenever the new method is invoked, initialize method is called and instances are created. If we try to invoke the ‘initialize’ method explicitly, we get the same error as in the case when we tried to invoke object Steve’s private ‘accountNumber’ method.

===C#===
<pre>
class BankAccount
{
public BankAccount(string accountNumber, string routingNumber, int balance)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
this.balance = balance;
}

private string accountNumber;
protected string routingNumber;
private int balance;

// accountNumber is private, so it can only be modified from within this
// class. Also, since the following method is private, it can only be called
// from within this class. So this field is truly private.
private void setAccountNumber(string acNo)
{
this.accountNumber=acNo;
}

// routingNumber is protected, so it can be directly modified by objects of
// a subclass. But the contents of this field are made accessible as public
// so anyone can 'read' the value of this field.
public string getRoutingNumber()
{
return this.routingNumber;
}

// Provides access to modify the private member balance, but this function
// can only be called by subclasses (and from within this class).
protected initBalance()
{
this.balance = 0;
}

// Provides access to 'read' the contents of the private field to everyone.
public void getBalance(int balance)
{
return this.balance;
}
}

class Customer : BankAccount
{
Customer(string accountNumber, string routingNumber)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
initBalance();
}
}

class Startup
{
public static void main()
{
Customer cust = new Customer(“999”, “888”, 100);
System.console.WriteLine(cust.getBalance);
}
}

</pre>

The Customer class inherits from the BankAccount class. All protected data members and methods of BankAccount class are accessible directly by an object of the Customer class. The private fields such as accountNumber and routingNumber are not directly accessible. Thus it is possible to call only the initBalance and getBalance methods from Customer. The initBalance method cannot be called by anyone outside the BankAccount class. Also see [http://www.informit.com/articles/article.aspx?p=101373&seqNum=3 this] for another example.

==Conclusion==
Access control is an integral component of object oriented languages and it underlines and emphasizes some of the pricipal ideals central to the object-oriented approach. It is possible to maximize the benefits of any O-O language by adhering to, and fully exploiting the capabilities of its access specifiers. Access control is in no way a peripheral add-on or redundant feature of O-O languages, and programmers would only stand to gain by fully appreciating, respecting and understanding their presence.

==References==
<references/>

CSC/ECE 517 Fall 2011/ch1 2b ns

2011-09-30T16:59:49Z

Sshyamr: /* Evolution of Access Control and proliferation of Accessor methods */

<h2>Access Control in Object-Oriented Languages</h2>

== Introduction ==
A fundamental precept of O-O systems is that an object should not expose any of its implementation details. In other words, access to an object’s functionality must be tightly regulated. The access control policies of any object-oriented language specify the rules and capabilities for enforcing this regulation. Thus, the concept of Access control ties in deeply with the underlying principles of [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming].

__TOC__
==Purpose of Access Control==
Object-oriented programming fundamentally revolves around the principle of Data Hiding and Encapsulation. In a nutshell, [http://en.wikipedia.org/wiki/Information_hiding Data Hiding] is the practice of securing data by constraining access to it, and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] ensures that the secure data (and the respective member functions) are bundled together as an individual module. All object oriented languages thus need to control the level of access to their critical data (and functions) which is achieved using ''Access Modifiers'' or ''Access Specifiers'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

The need to strictly control ''who'' can access ''what'' is very crucial in Software development. For example, if you make an instance variable 'public', then you can't change the field as the class evolves over time since you might break any external code that uses the field. This is because outside code having complete access to this field, has tied itself indelibly to the inside implementation of the (former) class and is now closely dependent on it. Changing the said field thus entails changing all the other code that have a dependency on it, which is cumbersome, unwieldy and contrary to the principles of an Object Oriented approach which strives for [http://en.wikipedia.org/wiki/Coupling_(computer_programming) Low Coupling].

Thus, the ‘Implementation hiding principle’ leads to a good acid test of an O-O system's quality: Can you make massive changes to a class definition—even throw out the whole thing and replace it with a completely different implementation—without impacting any of the code that uses that class's objects? This sort of modularization is the central premise of object orientation and makes maintenance much easier. Without implementation hiding, there's little point in using other O-O features. Regulation of access - Access Control - is at the heart of Object oriented programming<ref>http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html</ref>.

==Evolution of Access Control and proliferation of Accessor methods==
Access control has been a part of the OOP movement ever since its inception. [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] is arguably one of first and purest of the many O-O languages and was developed by Xerox PARC in the Learning Research Group in the 1970s <ref>http://www.zdnet.com/blog/murphy/the-tattered-history-of-oop/1157</ref>. Rather than having explicit access specifiers, smalltalk objects operated more in the sense of 'states' i.e. it would hold the 'state' of object(s) which is always private to that object. Any changes required to be made to this state had to be sent as request message to that object. This is the most primitive form of access control - having private data members and public member functions - the only difference being that the access levels are not explicitly specified.

Access control has evolved over time to become highly complicated <ref>http://www.exforsys.com/tutorials/oops/the-use-of-access-specifiers-in-object-oriented-programming.html</ref> because, the requirements of computing and software development have ballooned considerably in last decade and a half. Complex software requirements mandates complexity in languages, and this has indeed affected the access control policies, which have evolved into something comprehensive, yet - at times - convoluted. Unfortunately today's developers often lose sight of the fundamental motivation behind the existence of extensive access control and lose out on much of the benefits of having a highly cohesive, low coupled system<ref>http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref>.

To elaborate, it has become somewhat of an involuntary practice for present programmers to make ''all'' data members of a class private and provide accessor methods (getters/setters) to all of them (data members). Developers have come to accept this to be a contemporary programmatic-paradigm and by supplying setters and getters for ''everything'', defeat the very purpose of making class-fields private. A long time ago programmers discovered that reducing the scope (visibility) of data as much as possible leads to more reliable and maintainable code<ref>http://typicalprogrammer.com/?p=23</ref>.

Every getter and setter in one’s code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters is a sign of a poorly-designed set of classes. Java<ref>http://www.eclipse-blog.org/eclipse-ide/auto-generating-getters-and-setters.html</ref> and C#<ref>http://forums.asp.net/t/941864.aspx/1</ref> developers have IDEs that generate getters and setters automatically, implying that accessors are a good idea and thus contribute to that popular belief. That is not to say that one must completely abstain from accessors, but rather re-analyze and - if required - redesign the class structure to involve as little exposure of its data members as can be achieved.

==Access Control: A typical example==
Empirically, the data members of a class are held private, and the member functions (public) act as the end points of this class. Via these public methods, one can access the ‘state’ of an object. The following example illustrates this point and shows how access to the data members of a class are specified and controlled by the access modifiers.

[http://en.wikipedia.org/wiki/UML_Diagram#Diagrams_overview UML Diagram] of a BankAccount Class.

[[Image:BankAccount_UML.png|650px|thumb|center|Typical UML diagram of BankAccount.]]

The “(-)/(+)” preceding the members of this class represent the associated access levels. (-) indicates private and (+) indicates public.
The data members ‘accountNumber’, ‘routingNumber’ and ‘balance’ are maintained as private. Thus, an instance of a ‘Customer’ Object (say) cannot directly access or modify this data. Customer has to interact with the public behavior bundled in this module which allows him to view his account information and/or withdraw/deposit money i.e. his visibility of the class is only restricted to that which is made public by the Class.

Using such access specifiers, we can control the level of security and visibility associated with the members of a class. Thus, an Access Specifier can be roughly defined as ''‘A keyword applied to a variable, method, etc. that indicates which other parts of the code are permitted to access it’'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

==Common Access Specifiers in O-O languages==

Although all access specifiers essentially provide the same functionality, their semantics differ among different O-O languages. Here is how access control is implemented in some of the more common O-O languages.

===C++===
*'''private''':All members of the Class that are declared as private can only be accessed by the class's member functions and [http://en.wikipedia.org/wiki/Friend_class friends] of the class.
*'''protected''':All members of the Class that are declared as protected can be accessed by that class's member functions and friends (classes or functions) of the class. Moreover, classes derived from the class also have access to these elements.
*'''public''':Any class or method can have access to these type of elements.

===Java===
Java offers four access specifiers, listed below in order of decreasing accessibility:
*'''public''': All public classes, methods, and fields are the least secure. The Public access specifier must be used if you explicitly want to offer access to these entities and if this access cannot do any conceivable harm.
*'''protected''': Protected methods and fields can only be accessed within the same class to which the methods and fields belong, within its subclasses, and within classes present in the same [http://download.oracle.com/javase/tutorial/java/concepts/package.html Package]. Use of protected access specifier thus only allows its fields to be accessed by those classes which have some semblance of correlation to it - be it in the form of subclasses (correlation through inheritance) or classes within the same package (logical and/or functional correlation i.e. classes in the same package have ''something'' logical/functional common to them <ref>http://download.oracle.com/javase/tutorial/java/concepts/package.html</ref>).
*'''default '''(no specifier): Default access specifier is Java’s fail-safe way to handle security. Via the default access specifier, a class, method, or field will be accessible from inside the same package to which the class, method, or field belongs, but not from outside this package. Default access is thus suited when the source code is compartmentalized and organized into packages.
*'''private''': Private access specifier is a way to secure vital members of a class. Private methods and fields can only be accessed within the same class to which the methods and fields belong. Private methods and fields are not visible within subclasses and are not inherited by subclasses.

===Ruby===
Ruby gives you three levels of protection, listed below in order of decreasing accessibility:
*'''public''':Public methods can be called by everyone - no access control is enforced. A class's instance methods are public by default.
*'''protected''':Protected methods can be invoked only by objects of the defining class and its subclasses. Access is kept within the family.
*'''private''':Private methods cannot be called with an explicit receiver - the receiver is always self. Thus private methods can be called only in the context of the current object and cannot be invoked by another object's private methods.

Access control in Ruby is determined [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically], as the program runs, not statically. You will get an access violation only when the code attempts to execute the restricted method<ref>http://rubylearning.com/satishtalim/ruby_access_control.html</ref>.

===C#===
The following access modifiers specify the accessibility levels in C#
*'''public''':Any public method or member can be accessed by any other code in the same or different package.
*'''private''':The method or member can only be accessed from within the same class.
*'''protected''':The method or member can be accessed only from within the same Class or from within any of the subclasses.
*'''internal''':The type or member can be accessed by any code in the same assembly, but not from another assembly. An assembly in C# is the rough equivalent of a package in java.
*'''protected internal''':The type or member can be accessed by any code in the [http://msdn.microsoft.com/en-us/library/ms173099.aspx Assembly] (also see [http://msdn.microsoft.com/en-us/library/ms173099(v=vs.80).aspx this]) in which it is declared, or from within a derived class in another assembly. Access from another assembly must take place within a class declaration that derives from the class in which the protected internal element is declared, and it must take place through an instance of the derived class type.

===Summary of Access Specfiers in C++, Java, Ruby and C#:===
{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Access Level
! C++
! Java
! Ruby
! C#
|-
! Public
| Anything can access
| Anything can access
| Anything can access
| Anything can access
|-
! Protected
| Class, Subclasses and friends
| Class, Subclasses and classes of same package
| Class and Subclasses
| Class and Subclasses
|-
! Private
| Within Class
| Within Class
| Within Class
| Within Class
|-
! Internal
| --
| --
| --
| Any Class from same Assembly
|-
! Protected internal
| --
| --
| --
| Any Class from same Assembly and Subclass from any Assembly.
|}

==Examples of Access Specifiers==
The following examples exhibit the use of the access specifiers and getter methofs for the aforementioned Bank Account example.

===C++===
<pre>
class BankAccount {
private:
char routingNumber;
char accountNumber;

protected:
int balance;

public:
BankAccount(char *, char *);
void changeAccountNumber(char *);
void changeRoutingNumber(char *);
void depositMoney(int);
void withdrawMoney(int);
friend void displayAccountInfo();
}

BankAccount::BankAccount(char *rNo, char *accNo) {
Strcpy(routingNumber, rNo);
Strcpy(accountNumber, accNo);
balance = 0;
}

BankAccount::void changeAccountNumber(char *accNo){
Strcpy(accountNumber, accNo);
}

BankAccount::void changeRoutingNumber(char *rNo){
Strcpy(routingNumber, rNo);
}

BankAccount::void depositMoney(int amount) {
balance += amount;
}

BankAccount::void withdrawMoney(int amount) {
balance -= amount;
}

// Friend function can access both the private and protected members
// of BankAccount.
void displayAccountInfo(BankAccount ba) {
cout << “Account Number: ” << ba.accountNumber << endl;
cout << “Routing Number: ” << ba.routingNumber << endl;
cout << “Account Balance: ” << ba.balance << endl << endl;
}

// CheckingAccount inherits from BankAccount. Hence it can access only the
// public and protected members of BankAccount. It cannot access the private
// members of BankAccount.
class CheckingAccount: public BankAccount {
private:
char accountType[20];

public:
CheckingAccount(char *, char *);
void resetBalance();
}

CheckingAccount::CheckingAccount(char *rNo, char *accNo) {
Strcpy(accountType, "Checking");
changeRoutingNumber(rNo);
changeAccountNumber (accNo);
balance = 0;
}

// Since balance is a protected field, it can be accessed by CheckingAccount
CheckingAccount::void resetBalance() {
balance = 0;
}

int main() {
CheckingAccount ca("888", "999");
ca.depositMoney(100);
displayAccountInfo(ca);
ca.withdrawMoney(50);
displayAccountInfo(ca);
ca.resetBalance();
displayAccountInfo(ca);
}

</pre>

<pre>
OUTPUT:

Account Number: 888
Routing Number: 999
Account Balance: 100

Account Number: 888
Routing Number: 999
Account Balance: 50

Account Number: 888
Routing Number: 999
Account Balance: 0
</pre>

The data members routingNumber, accountNumber are made private and balance is protected. This makes it impossible to directly access or change routingNumber, accountNumber from outside code. Access to these attributes are strictly through the public methods changeRoutingNumber() and changeAccountNumber(). However, private and protected members are accessible through friend functions, so displayAccountInfo() function is able to access all the mentioned fields. Since balance is protected, it can be accessed from a subclass (CheckingAccount) directly as shown above. But the private members have to be accessed through the functions changeRoutingNumber() and changeAccountNumber() instead of being accessed directly.

Thus, it purely at the discretion of the programmer to allow access to these data members through such accessor functions. In the absence of such accessors, there would be no way for any code outside the class to view/modify the private attributes.

===Java===

<pre>
public class BankAccount {
String accountNumber;
private String routingNumber;
private Integer balance;

public void setAccountNumber(String acNo){
this.accountNumber=acNo;
}

public void setRoutingNumber(String rtNo){
this.routingNumber=rtNo;
}

protected void setBalance(Integer bal){
this.balance=bal;
}

public String getAccountNumber(){
return this.accountNumber;
}

public String getRoutingNumber(){
return this.routingNumber;
}

protected Integer getBalance(){
return this.balance;
}

public void showAccountNumber(){
System.out.println(this.accountNumber);
}

public void showRoutingNumber(){
System.out.println(this.routingNumber);
}

public void showBalance(){
System.out.println(this.balance);
}

public void withdraw(Integer amount){
this.balance-=amount;
}

public void deposit(Integer amount){
this.balance+=amount;
}

public static void main(String args[]){
BankAccount Steve = new BankAccount();

//public access to setRoutingNumber/getRoutingNumber
Steve.setRoutingNumber("1234");
String steveRtNo=Steve.getRoutingNumber();
System.out.println(steveRtNo);

//protected access to the method setBalance/getBalance
Steve.setBalance(5000);
System.out.println(Steve.getBalance());
}

}
</pre>

Class BankAccount in the above Java code has public getter/setter methods to access the private data member ‘routingNumber’. Thus, we can invoke these methods using an instance of the BankAccount object: Steve.
The methods setBalance()/ getBalance() are protected. As can be seen, they behave like public methods if invoked in the same package. Protected methods act like private methods if invoked by any instance of a class outside the package.
However, if there is a class ‘InternationalBankAccount’ in a different package such that:
<pre>
public class InternationalBankAccount extends BankAccount {
public String internationalBankAccNo;
}
</pre>

<pre>
InternationalBankAccount Anna = new InternationalBankAccount();
Anna.setBalance(10000);
</pre>

The above is a valid syntax and Anna can access protected member functions of the parent class.
Data member ‘accountNumber’ has default access specifier. Default access specifier is used in Java to support package driven development. Thus ‘accountNumber’ can be accessed from anywhere within the package. However no classes from other packages can access ‘accountNumber’.
Data member balance is a private data member and if it is invoked explicitly as follows,
<pre>
Steve.balance=1000;
</pre>
then the output would be an unresolved compilation error of the form:
<pre>
Unresolved compilation problem: The field bankAccount.balance is not visible
</pre>

===Ruby===
The following code illustrates the use of access specifiers in Ruby.
<pre>
class BankAccount

def initialize(acNo, rtNo, bal)
@accountNumber = acNo
@routingNumber = rtNo
@balance = bal
end

def balance
@balance
end

def routingNumber
@routingNumber
end

def accountNumber
@accountNumber
end

def compare_balance(other)
if other.balance > balance
"The other object has more bank balance."
else
"This object has more bank balance."
end
end

protected:balance
public:routingNumber
private:accountNumber

end
</pre>

<pre>
Steve = BankAccount.new(713, 123, 1000)
Anna = BankAccount.new(923, 125, 2000)
puts Steve.routingNumber()
puts Steve.compare_balance (Anna)
puts Steve.accountNumber()
</pre>

<pre>
Output:
123
The other object has more bank balance.
NoMethodError: private method `accountNumber' called for #<BankAccount:0x2b75320>
</pre>

‘routingNumber’ is a public function. Thus, when we access object Steve’s public method ‘routing number’, we successfully get ‘123’ as the output.
Furthermore, this snippet provides a mechanism for the comparison of one account holder’s balance with another. This comparison involves a call to the method ‘balance’. The object performing the comparison has to ask the other object to execute its balance method. So, balance cannot be private. With ‘balance’ changed to protected instead of private, Steve can ask Anna to execute ‘balance’, because both are instances of the same class. But if we try to call the ‘balance’ method of a bankAccount object when ‘self’ is anything other than a bankAccount object, the method will fail. A protected method is thus just like a private method, but with the exemption for those cases where the class of ‘self’ and the class of the respective object (having the method called on it) are the same.
‘accountNumber’ method is private. Thus user gets a ‘NoMethodError’ on invoking object Steve’s ‘accountNumber’ method. Initialize method in a class is private by default. Whenever the new method is invoked, initialize method is called and instances are created. If we try to invoke the ‘initialize’ method explicitly, we get the same error as in the case when we tried to invoke object Steve’s private ‘accountNumber’ method.

===C#===
<pre>
class BankAccount
{
public BankAccount(string accountNumber, string routingNumber, int balance)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
this.balance = balance;
}

private string accountNumber;
protected string routingNumber;
private int balance;

// accountNumber is private, so it can only be modified from within this
// class. Also, since the following method is private, it can only be called
// from within this class. So this field is truly private.
private void setAccountNumber(string acNo)
{
this.accountNumber=acNo;
}

// routingNumber is protected, so it can be directly modified by objects of
// a subclass. But the contents of this field are made accessible as public
// so anyone can 'read' the value of this field.
public string getRoutingNumber()
{
return this.routingNumber;
}

// Provides access to modify the private member balance, but this function
// can only be called by subclasses (and from within this class).
protected initBalance()
{
this.balance = 0;
}

// Provides access to 'read' the contents of the private field to everyone.
public void getBalance(int balance)
{
return this.balance;
}
}

class Customer : BankAccount
{
Customer(string accountNumber, string routingNumber)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
initBalance();
}
}

class Startup
{
public static void main()
{
Customer cust = new Customer(“999”, “888”, 100);
System.console.WriteLine(cust.getBalance);
}
}

</pre>

The Customer class inherits from the BankAccount class. All protected data members and methods of BankAccount class are accessible directly by an object of the Customer class. The private fields such as accountNumber and routingNumber are not directly accessible. Thus it is possible to call only the initBalance and getBalance methods from Customer. The initBalance method cannot be called by anyone outside the BankAccount class. Also see [http://www.informit.com/articles/article.aspx?p=101373&seqNum=3 this] for another example.

==Conclusion==
Access control is an integral component of object oriented languages and it underlines and emphasizes some of the pricipal ideals central to the object-oriented approach. It is possible to maximize the benefits of any O-O language by adhering to, and fully exploiting the capabilities of its access specifiers. Access control is in no way a peripheral add-on or redundant feature of O-O languages, and programmers would only stand to gain by fully appreciating, respecting and understanding their presence.

==References==
<references/>

CSC/ECE 517 Fall 2011/ch1 2b ns

2011-09-30T16:59:00Z

Sshyamr: /* Conclusion */

<h2>Access Control in Object-Oriented Languages</h2>

== Introduction ==
A fundamental precept of O-O systems is that an object should not expose any of its implementation details. In other words, access to an object’s functionality must be tightly regulated. The access control policies of any object-oriented language specify the rules and capabilities for enforcing this regulation. Thus, the concept of Access control ties in deeply with the underlying principles of [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming].

__TOC__
==Purpose of Access Control==
Object-oriented programming fundamentally revolves around the principle of Data Hiding and Encapsulation. In a nutshell, [http://en.wikipedia.org/wiki/Information_hiding Data Hiding] is the practice of securing data by constraining access to it, and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] ensures that the secure data (and the respective member functions) are bundled together as an individual module. All object oriented languages thus need to control the level of access to their critical data (and functions) which is achieved using ''Access Modifiers'' or ''Access Specifiers'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

The need to strictly control ''who'' can access ''what'' is very crucial in Software development. For example, if you make an instance variable 'public', then you can't change the field as the class evolves over time since you might break any external code that uses the field. This is because outside code having complete access to this field, has tied itself indelibly to the inside implementation of the (former) class and is now closely dependent on it. Changing the said field thus entails changing all the other code that have a dependency on it, which is cumbersome, unwieldy and contrary to the principles of an Object Oriented approach which strives for [http://en.wikipedia.org/wiki/Coupling_(computer_programming) Low Coupling].

Thus, the ‘Implementation hiding principle’ leads to a good acid test of an O-O system's quality: Can you make massive changes to a class definition—even throw out the whole thing and replace it with a completely different implementation—without impacting any of the code that uses that class's objects? This sort of modularization is the central premise of object orientation and makes maintenance much easier. Without implementation hiding, there's little point in using other O-O features. Regulation of access - Access Control - is at the heart of Object oriented programming<ref>http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html</ref>.

==Evolution of Access Control and proliferation of Accessor methods==
Access control has been a part of the OOP movement ever since its inception. [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] is arguably one of first and purest of the many OO languages and was developed by Xerox PARC in the Learning Research Group in the 1970s <ref>http://www.zdnet.com/blog/murphy/the-tattered-history-of-oop/1157</ref>. Rather than having explicit access specifiers, smalltalk objects operated more in the sense of 'states' i.e. it would hold the 'state' of object(s) which is always private to that object. Any changes required to be made to this state had to be sent as request message to that object. This is the most primitive form of access control - having private data members and public member functions - the only difference being that the access levels are not explicitly specified.

Access control has evolved over time to become highly complicated <ref>http://www.exforsys.com/tutorials/oops/the-use-of-access-specifiers-in-object-oriented-programming.html</ref> because, the requirements of computing and software development have ballooned considerably in last decade and a half. Complex software requirements mandates complexity in languages, and this has indeed affected the access control policies, which have evolved into something comprehensive, yet - at times - convoluted. Unfortunately today's developers often lose sight of the fundamental motivation behind the existence of extensive access control and lose out on much of the benefits of having a highly cohesive, low coupled system<ref>http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref>.

To elaborate, it has become somewhat of an involuntary practice for present programmers to make ''all'' data members of a class private and provide accessor methods (getters/setters) to all of them (data members). Developers have come to accept this to be a contemporary programmatic-paradigm and by supplying setters and getters for ''everything'', defeat the very purpose of making class-fields private. A long time ago programmers discovered that reducing the scope (visibility) of data as much as possible leads to more reliable and maintainable code<ref>http://typicalprogrammer.com/?p=23</ref>.

Every getter and setter in one’s code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters is a sign of a poorly-designed set of classes. Java<ref>http://www.eclipse-blog.org/eclipse-ide/auto-generating-getters-and-setters.html</ref> and C#<ref>http://forums.asp.net/t/941864.aspx/1</ref> developers have IDEs that generate getters and setters automatically, implying that accessors are a good idea and thus contribute to that popular belief. That is not to say that one must completely abstain from accessors, but rather re-analyze and - if required - redesign the class structure to involve as little exposure of its data members as can be achieved.

==Access Control: A typical example==
Empirically, the data members of a class are held private, and the member functions (public) act as the end points of this class. Via these public methods, one can access the ‘state’ of an object. The following example illustrates this point and shows how access to the data members of a class are specified and controlled by the access modifiers.

[http://en.wikipedia.org/wiki/UML_Diagram#Diagrams_overview UML Diagram] of a BankAccount Class.

[[Image:BankAccount_UML.png|650px|thumb|center|Typical UML diagram of BankAccount.]]

The “(-)/(+)” preceding the members of this class represent the associated access levels. (-) indicates private and (+) indicates public.
The data members ‘accountNumber’, ‘routingNumber’ and ‘balance’ are maintained as private. Thus, an instance of a ‘Customer’ Object (say) cannot directly access or modify this data. Customer has to interact with the public behavior bundled in this module which allows him to view his account information and/or withdraw/deposit money i.e. his visibility of the class is only restricted to that which is made public by the Class.

Using such access specifiers, we can control the level of security and visibility associated with the members of a class. Thus, an Access Specifier can be roughly defined as ''‘A keyword applied to a variable, method, etc. that indicates which other parts of the code are permitted to access it’'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

==Common Access Specifiers in O-O languages==

Although all access specifiers essentially provide the same functionality, their semantics differ among different O-O languages. Here is how access control is implemented in some of the more common O-O languages.

===C++===
*'''private''':All members of the Class that are declared as private can only be accessed by the class's member functions and [http://en.wikipedia.org/wiki/Friend_class friends] of the class.
*'''protected''':All members of the Class that are declared as protected can be accessed by that class's member functions and friends (classes or functions) of the class. Moreover, classes derived from the class also have access to these elements.
*'''public''':Any class or method can have access to these type of elements.

===Java===
Java offers four access specifiers, listed below in order of decreasing accessibility:
*'''public''': All public classes, methods, and fields are the least secure. The Public access specifier must be used if you explicitly want to offer access to these entities and if this access cannot do any conceivable harm.
*'''protected''': Protected methods and fields can only be accessed within the same class to which the methods and fields belong, within its subclasses, and within classes present in the same [http://download.oracle.com/javase/tutorial/java/concepts/package.html Package]. Use of protected access specifier thus only allows its fields to be accessed by those classes which have some semblance of correlation to it - be it in the form of subclasses (correlation through inheritance) or classes within the same package (logical and/or functional correlation i.e. classes in the same package have ''something'' logical/functional common to them <ref>http://download.oracle.com/javase/tutorial/java/concepts/package.html</ref>).
*'''default '''(no specifier): Default access specifier is Java’s fail-safe way to handle security. Via the default access specifier, a class, method, or field will be accessible from inside the same package to which the class, method, or field belongs, but not from outside this package. Default access is thus suited when the source code is compartmentalized and organized into packages.
*'''private''': Private access specifier is a way to secure vital members of a class. Private methods and fields can only be accessed within the same class to which the methods and fields belong. Private methods and fields are not visible within subclasses and are not inherited by subclasses.

===Ruby===
Ruby gives you three levels of protection, listed below in order of decreasing accessibility:
*'''public''':Public methods can be called by everyone - no access control is enforced. A class's instance methods are public by default.
*'''protected''':Protected methods can be invoked only by objects of the defining class and its subclasses. Access is kept within the family.
*'''private''':Private methods cannot be called with an explicit receiver - the receiver is always self. Thus private methods can be called only in the context of the current object and cannot be invoked by another object's private methods.

Access control in Ruby is determined [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically], as the program runs, not statically. You will get an access violation only when the code attempts to execute the restricted method<ref>http://rubylearning.com/satishtalim/ruby_access_control.html</ref>.

===C#===
The following access modifiers specify the accessibility levels in C#
*'''public''':Any public method or member can be accessed by any other code in the same or different package.
*'''private''':The method or member can only be accessed from within the same class.
*'''protected''':The method or member can be accessed only from within the same Class or from within any of the subclasses.
*'''internal''':The type or member can be accessed by any code in the same assembly, but not from another assembly. An assembly in C# is the rough equivalent of a package in java.
*'''protected internal''':The type or member can be accessed by any code in the [http://msdn.microsoft.com/en-us/library/ms173099.aspx Assembly] (also see [http://msdn.microsoft.com/en-us/library/ms173099(v=vs.80).aspx this]) in which it is declared, or from within a derived class in another assembly. Access from another assembly must take place within a class declaration that derives from the class in which the protected internal element is declared, and it must take place through an instance of the derived class type.

===Summary of Access Specfiers in C++, Java, Ruby and C#:===
{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Access Level
! C++
! Java
! Ruby
! C#
|-
! Public
| Anything can access
| Anything can access
| Anything can access
| Anything can access
|-
! Protected
| Class, Subclasses and friends
| Class, Subclasses and classes of same package
| Class and Subclasses
| Class and Subclasses
|-
! Private
| Within Class
| Within Class
| Within Class
| Within Class
|-
! Internal
| --
| --
| --
| Any Class from same Assembly
|-
! Protected internal
| --
| --
| --
| Any Class from same Assembly and Subclass from any Assembly.
|}

==Examples of Access Specifiers==
The following examples exhibit the use of the access specifiers and getter methofs for the aforementioned Bank Account example.

===C++===
<pre>
class BankAccount {
private:
char routingNumber;
char accountNumber;

protected:
int balance;

public:
BankAccount(char *, char *);
void changeAccountNumber(char *);
void changeRoutingNumber(char *);
void depositMoney(int);
void withdrawMoney(int);
friend void displayAccountInfo();
}

BankAccount::BankAccount(char *rNo, char *accNo) {
Strcpy(routingNumber, rNo);
Strcpy(accountNumber, accNo);
balance = 0;
}

BankAccount::void changeAccountNumber(char *accNo){
Strcpy(accountNumber, accNo);
}

BankAccount::void changeRoutingNumber(char *rNo){
Strcpy(routingNumber, rNo);
}

BankAccount::void depositMoney(int amount) {
balance += amount;
}

BankAccount::void withdrawMoney(int amount) {
balance -= amount;
}

// Friend function can access both the private and protected members
// of BankAccount.
void displayAccountInfo(BankAccount ba) {
cout << “Account Number: ” << ba.accountNumber << endl;
cout << “Routing Number: ” << ba.routingNumber << endl;
cout << “Account Balance: ” << ba.balance << endl << endl;
}

// CheckingAccount inherits from BankAccount. Hence it can access only the
// public and protected members of BankAccount. It cannot access the private
// members of BankAccount.
class CheckingAccount: public BankAccount {
private:
char accountType[20];

public:
CheckingAccount(char *, char *);
void resetBalance();
}

CheckingAccount::CheckingAccount(char *rNo, char *accNo) {
Strcpy(accountType, "Checking");
changeRoutingNumber(rNo);
changeAccountNumber (accNo);
balance = 0;
}

// Since balance is a protected field, it can be accessed by CheckingAccount
CheckingAccount::void resetBalance() {
balance = 0;
}

int main() {
CheckingAccount ca("888", "999");
ca.depositMoney(100);
displayAccountInfo(ca);
ca.withdrawMoney(50);
displayAccountInfo(ca);
ca.resetBalance();
displayAccountInfo(ca);
}

</pre>

<pre>
OUTPUT:

Account Number: 888
Routing Number: 999
Account Balance: 100

Account Number: 888
Routing Number: 999
Account Balance: 50

Account Number: 888
Routing Number: 999
Account Balance: 0
</pre>

The data members routingNumber, accountNumber are made private and balance is protected. This makes it impossible to directly access or change routingNumber, accountNumber from outside code. Access to these attributes are strictly through the public methods changeRoutingNumber() and changeAccountNumber(). However, private and protected members are accessible through friend functions, so displayAccountInfo() function is able to access all the mentioned fields. Since balance is protected, it can be accessed from a subclass (CheckingAccount) directly as shown above. But the private members have to be accessed through the functions changeRoutingNumber() and changeAccountNumber() instead of being accessed directly.

Thus, it purely at the discretion of the programmer to allow access to these data members through such accessor functions. In the absence of such accessors, there would be no way for any code outside the class to view/modify the private attributes.

===Java===

<pre>
public class BankAccount {
String accountNumber;
private String routingNumber;
private Integer balance;

public void setAccountNumber(String acNo){
this.accountNumber=acNo;
}

public void setRoutingNumber(String rtNo){
this.routingNumber=rtNo;
}

protected void setBalance(Integer bal){
this.balance=bal;
}

public String getAccountNumber(){
return this.accountNumber;
}

public String getRoutingNumber(){
return this.routingNumber;
}

protected Integer getBalance(){
return this.balance;
}

public void showAccountNumber(){
System.out.println(this.accountNumber);
}

public void showRoutingNumber(){
System.out.println(this.routingNumber);
}

public void showBalance(){
System.out.println(this.balance);
}

public void withdraw(Integer amount){
this.balance-=amount;
}

public void deposit(Integer amount){
this.balance+=amount;
}

public static void main(String args[]){
BankAccount Steve = new BankAccount();

//public access to setRoutingNumber/getRoutingNumber
Steve.setRoutingNumber("1234");
String steveRtNo=Steve.getRoutingNumber();
System.out.println(steveRtNo);

//protected access to the method setBalance/getBalance
Steve.setBalance(5000);
System.out.println(Steve.getBalance());
}

}
</pre>

Class BankAccount in the above Java code has public getter/setter methods to access the private data member ‘routingNumber’. Thus, we can invoke these methods using an instance of the BankAccount object: Steve.
The methods setBalance()/ getBalance() are protected. As can be seen, they behave like public methods if invoked in the same package. Protected methods act like private methods if invoked by any instance of a class outside the package.
However, if there is a class ‘InternationalBankAccount’ in a different package such that:
<pre>
public class InternationalBankAccount extends BankAccount {
public String internationalBankAccNo;
}
</pre>

<pre>
InternationalBankAccount Anna = new InternationalBankAccount();
Anna.setBalance(10000);
</pre>

The above is a valid syntax and Anna can access protected member functions of the parent class.
Data member ‘accountNumber’ has default access specifier. Default access specifier is used in Java to support package driven development. Thus ‘accountNumber’ can be accessed from anywhere within the package. However no classes from other packages can access ‘accountNumber’.
Data member balance is a private data member and if it is invoked explicitly as follows,
<pre>
Steve.balance=1000;
</pre>
then the output would be an unresolved compilation error of the form:
<pre>
Unresolved compilation problem: The field bankAccount.balance is not visible
</pre>

===Ruby===
The following code illustrates the use of access specifiers in Ruby.
<pre>
class BankAccount

def initialize(acNo, rtNo, bal)
@accountNumber = acNo
@routingNumber = rtNo
@balance = bal
end

def balance
@balance
end

def routingNumber
@routingNumber
end

def accountNumber
@accountNumber
end

def compare_balance(other)
if other.balance > balance
"The other object has more bank balance."
else
"This object has more bank balance."
end
end

protected:balance
public:routingNumber
private:accountNumber

end
</pre>

<pre>
Steve = BankAccount.new(713, 123, 1000)
Anna = BankAccount.new(923, 125, 2000)
puts Steve.routingNumber()
puts Steve.compare_balance (Anna)
puts Steve.accountNumber()
</pre>

<pre>
Output:
123
The other object has more bank balance.
NoMethodError: private method `accountNumber' called for #<BankAccount:0x2b75320>
</pre>

‘routingNumber’ is a public function. Thus, when we access object Steve’s public method ‘routing number’, we successfully get ‘123’ as the output.
Furthermore, this snippet provides a mechanism for the comparison of one account holder’s balance with another. This comparison involves a call to the method ‘balance’. The object performing the comparison has to ask the other object to execute its balance method. So, balance cannot be private. With ‘balance’ changed to protected instead of private, Steve can ask Anna to execute ‘balance’, because both are instances of the same class. But if we try to call the ‘balance’ method of a bankAccount object when ‘self’ is anything other than a bankAccount object, the method will fail. A protected method is thus just like a private method, but with the exemption for those cases where the class of ‘self’ and the class of the respective object (having the method called on it) are the same.
‘accountNumber’ method is private. Thus user gets a ‘NoMethodError’ on invoking object Steve’s ‘accountNumber’ method. Initialize method in a class is private by default. Whenever the new method is invoked, initialize method is called and instances are created. If we try to invoke the ‘initialize’ method explicitly, we get the same error as in the case when we tried to invoke object Steve’s private ‘accountNumber’ method.

===C#===
<pre>
class BankAccount
{
public BankAccount(string accountNumber, string routingNumber, int balance)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
this.balance = balance;
}

private string accountNumber;
protected string routingNumber;
private int balance;

// accountNumber is private, so it can only be modified from within this
// class. Also, since the following method is private, it can only be called
// from within this class. So this field is truly private.
private void setAccountNumber(string acNo)
{
this.accountNumber=acNo;
}

// routingNumber is protected, so it can be directly modified by objects of
// a subclass. But the contents of this field are made accessible as public
// so anyone can 'read' the value of this field.
public string getRoutingNumber()
{
return this.routingNumber;
}

// Provides access to modify the private member balance, but this function
// can only be called by subclasses (and from within this class).
protected initBalance()
{
this.balance = 0;
}

// Provides access to 'read' the contents of the private field to everyone.
public void getBalance(int balance)
{
return this.balance;
}
}

class Customer : BankAccount
{
Customer(string accountNumber, string routingNumber)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
initBalance();
}
}

class Startup
{
public static void main()
{
Customer cust = new Customer(“999”, “888”, 100);
System.console.WriteLine(cust.getBalance);
}
}

</pre>

The Customer class inherits from the BankAccount class. All protected data members and methods of BankAccount class are accessible directly by an object of the Customer class. The private fields such as accountNumber and routingNumber are not directly accessible. Thus it is possible to call only the initBalance and getBalance methods from Customer. The initBalance method cannot be called by anyone outside the BankAccount class. Also see [http://www.informit.com/articles/article.aspx?p=101373&seqNum=3 this] for another example.

==Conclusion==
Access control is an integral component of object oriented languages and it underlines and emphasizes some of the pricipal ideals central to the object-oriented approach. It is possible to maximize the benefits of any O-O language by adhering to, and fully exploiting the capabilities of its access specifiers. Access control is in no way a peripheral add-on or redundant feature of O-O languages, and programmers would only stand to gain by fully appreciating, respecting and understanding their presence.

==References==
<references/>

CSC/ECE 517 Fall 2011/ch1 2b ns

2011-09-30T16:58:18Z

Sshyamr: /* C# */

<h2>Access Control in Object-Oriented Languages</h2>

== Introduction ==
A fundamental precept of O-O systems is that an object should not expose any of its implementation details. In other words, access to an object’s functionality must be tightly regulated. The access control policies of any object-oriented language specify the rules and capabilities for enforcing this regulation. Thus, the concept of Access control ties in deeply with the underlying principles of [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming].

__TOC__
==Purpose of Access Control==
Object-oriented programming fundamentally revolves around the principle of Data Hiding and Encapsulation. In a nutshell, [http://en.wikipedia.org/wiki/Information_hiding Data Hiding] is the practice of securing data by constraining access to it, and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] ensures that the secure data (and the respective member functions) are bundled together as an individual module. All object oriented languages thus need to control the level of access to their critical data (and functions) which is achieved using ''Access Modifiers'' or ''Access Specifiers'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

The need to strictly control ''who'' can access ''what'' is very crucial in Software development. For example, if you make an instance variable 'public', then you can't change the field as the class evolves over time since you might break any external code that uses the field. This is because outside code having complete access to this field, has tied itself indelibly to the inside implementation of the (former) class and is now closely dependent on it. Changing the said field thus entails changing all the other code that have a dependency on it, which is cumbersome, unwieldy and contrary to the principles of an Object Oriented approach which strives for [http://en.wikipedia.org/wiki/Coupling_(computer_programming) Low Coupling].

Thus, the ‘Implementation hiding principle’ leads to a good acid test of an O-O system's quality: Can you make massive changes to a class definition—even throw out the whole thing and replace it with a completely different implementation—without impacting any of the code that uses that class's objects? This sort of modularization is the central premise of object orientation and makes maintenance much easier. Without implementation hiding, there's little point in using other O-O features. Regulation of access - Access Control - is at the heart of Object oriented programming<ref>http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html</ref>.

==Evolution of Access Control and proliferation of Accessor methods==
Access control has been a part of the OOP movement ever since its inception. [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] is arguably one of first and purest of the many OO languages and was developed by Xerox PARC in the Learning Research Group in the 1970s <ref>http://www.zdnet.com/blog/murphy/the-tattered-history-of-oop/1157</ref>. Rather than having explicit access specifiers, smalltalk objects operated more in the sense of 'states' i.e. it would hold the 'state' of object(s) which is always private to that object. Any changes required to be made to this state had to be sent as request message to that object. This is the most primitive form of access control - having private data members and public member functions - the only difference being that the access levels are not explicitly specified.

Access control has evolved over time to become highly complicated <ref>http://www.exforsys.com/tutorials/oops/the-use-of-access-specifiers-in-object-oriented-programming.html</ref> because, the requirements of computing and software development have ballooned considerably in last decade and a half. Complex software requirements mandates complexity in languages, and this has indeed affected the access control policies, which have evolved into something comprehensive, yet - at times - convoluted. Unfortunately today's developers often lose sight of the fundamental motivation behind the existence of extensive access control and lose out on much of the benefits of having a highly cohesive, low coupled system<ref>http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref>.

To elaborate, it has become somewhat of an involuntary practice for present programmers to make ''all'' data members of a class private and provide accessor methods (getters/setters) to all of them (data members). Developers have come to accept this to be a contemporary programmatic-paradigm and by supplying setters and getters for ''everything'', defeat the very purpose of making class-fields private. A long time ago programmers discovered that reducing the scope (visibility) of data as much as possible leads to more reliable and maintainable code<ref>http://typicalprogrammer.com/?p=23</ref>.

Every getter and setter in one’s code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters is a sign of a poorly-designed set of classes. Java<ref>http://www.eclipse-blog.org/eclipse-ide/auto-generating-getters-and-setters.html</ref> and C#<ref>http://forums.asp.net/t/941864.aspx/1</ref> developers have IDEs that generate getters and setters automatically, implying that accessors are a good idea and thus contribute to that popular belief. That is not to say that one must completely abstain from accessors, but rather re-analyze and - if required - redesign the class structure to involve as little exposure of its data members as can be achieved.

==Access Control: A typical example==
Empirically, the data members of a class are held private, and the member functions (public) act as the end points of this class. Via these public methods, one can access the ‘state’ of an object. The following example illustrates this point and shows how access to the data members of a class are specified and controlled by the access modifiers.

[http://en.wikipedia.org/wiki/UML_Diagram#Diagrams_overview UML Diagram] of a BankAccount Class.

[[Image:BankAccount_UML.png|650px|thumb|center|Typical UML diagram of BankAccount.]]

The “(-)/(+)” preceding the members of this class represent the associated access levels. (-) indicates private and (+) indicates public.
The data members ‘accountNumber’, ‘routingNumber’ and ‘balance’ are maintained as private. Thus, an instance of a ‘Customer’ Object (say) cannot directly access or modify this data. Customer has to interact with the public behavior bundled in this module which allows him to view his account information and/or withdraw/deposit money i.e. his visibility of the class is only restricted to that which is made public by the Class.

Using such access specifiers, we can control the level of security and visibility associated with the members of a class. Thus, an Access Specifier can be roughly defined as ''‘A keyword applied to a variable, method, etc. that indicates which other parts of the code are permitted to access it’'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

==Common Access Specifiers in O-O languages==

Although all access specifiers essentially provide the same functionality, their semantics differ among different O-O languages. Here is how access control is implemented in some of the more common O-O languages.

===C++===
*'''private''':All members of the Class that are declared as private can only be accessed by the class's member functions and [http://en.wikipedia.org/wiki/Friend_class friends] of the class.
*'''protected''':All members of the Class that are declared as protected can be accessed by that class's member functions and friends (classes or functions) of the class. Moreover, classes derived from the class also have access to these elements.
*'''public''':Any class or method can have access to these type of elements.

===Java===
Java offers four access specifiers, listed below in order of decreasing accessibility:
*'''public''': All public classes, methods, and fields are the least secure. The Public access specifier must be used if you explicitly want to offer access to these entities and if this access cannot do any conceivable harm.
*'''protected''': Protected methods and fields can only be accessed within the same class to which the methods and fields belong, within its subclasses, and within classes present in the same [http://download.oracle.com/javase/tutorial/java/concepts/package.html Package]. Use of protected access specifier thus only allows its fields to be accessed by those classes which have some semblance of correlation to it - be it in the form of subclasses (correlation through inheritance) or classes within the same package (logical and/or functional correlation i.e. classes in the same package have ''something'' logical/functional common to them <ref>http://download.oracle.com/javase/tutorial/java/concepts/package.html</ref>).
*'''default '''(no specifier): Default access specifier is Java’s fail-safe way to handle security. Via the default access specifier, a class, method, or field will be accessible from inside the same package to which the class, method, or field belongs, but not from outside this package. Default access is thus suited when the source code is compartmentalized and organized into packages.
*'''private''': Private access specifier is a way to secure vital members of a class. Private methods and fields can only be accessed within the same class to which the methods and fields belong. Private methods and fields are not visible within subclasses and are not inherited by subclasses.

===Ruby===
Ruby gives you three levels of protection, listed below in order of decreasing accessibility:
*'''public''':Public methods can be called by everyone - no access control is enforced. A class's instance methods are public by default.
*'''protected''':Protected methods can be invoked only by objects of the defining class and its subclasses. Access is kept within the family.
*'''private''':Private methods cannot be called with an explicit receiver - the receiver is always self. Thus private methods can be called only in the context of the current object and cannot be invoked by another object's private methods.

Access control in Ruby is determined [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically], as the program runs, not statically. You will get an access violation only when the code attempts to execute the restricted method<ref>http://rubylearning.com/satishtalim/ruby_access_control.html</ref>.

===C#===
The following access modifiers specify the accessibility levels in C#
*'''public''':Any public method or member can be accessed by any other code in the same or different package.
*'''private''':The method or member can only be accessed from within the same class.
*'''protected''':The method or member can be accessed only from within the same Class or from within any of the subclasses.
*'''internal''':The type or member can be accessed by any code in the same assembly, but not from another assembly. An assembly in C# is the rough equivalent of a package in java.
*'''protected internal''':The type or member can be accessed by any code in the [http://msdn.microsoft.com/en-us/library/ms173099.aspx Assembly] (also see [http://msdn.microsoft.com/en-us/library/ms173099(v=vs.80).aspx this]) in which it is declared, or from within a derived class in another assembly. Access from another assembly must take place within a class declaration that derives from the class in which the protected internal element is declared, and it must take place through an instance of the derived class type.

===Summary of Access Specfiers in C++, Java, Ruby and C#:===
{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Access Level
! C++
! Java
! Ruby
! C#
|-
! Public
| Anything can access
| Anything can access
| Anything can access
| Anything can access
|-
! Protected
| Class, Subclasses and friends
| Class, Subclasses and classes of same package
| Class and Subclasses
| Class and Subclasses
|-
! Private
| Within Class
| Within Class
| Within Class
| Within Class
|-
! Internal
| --
| --
| --
| Any Class from same Assembly
|-
! Protected internal
| --
| --
| --
| Any Class from same Assembly and Subclass from any Assembly.
|}

==Examples of Access Specifiers==
The following examples exhibit the use of the access specifiers and getter methofs for the aforementioned Bank Account example.

===C++===
<pre>
class BankAccount {
private:
char routingNumber;
char accountNumber;

protected:
int balance;

public:
BankAccount(char *, char *);
void changeAccountNumber(char *);
void changeRoutingNumber(char *);
void depositMoney(int);
void withdrawMoney(int);
friend void displayAccountInfo();
}

BankAccount::BankAccount(char *rNo, char *accNo) {
Strcpy(routingNumber, rNo);
Strcpy(accountNumber, accNo);
balance = 0;
}

BankAccount::void changeAccountNumber(char *accNo){
Strcpy(accountNumber, accNo);
}

BankAccount::void changeRoutingNumber(char *rNo){
Strcpy(routingNumber, rNo);
}

BankAccount::void depositMoney(int amount) {
balance += amount;
}

BankAccount::void withdrawMoney(int amount) {
balance -= amount;
}

// Friend function can access both the private and protected members
// of BankAccount.
void displayAccountInfo(BankAccount ba) {
cout << “Account Number: ” << ba.accountNumber << endl;
cout << “Routing Number: ” << ba.routingNumber << endl;
cout << “Account Balance: ” << ba.balance << endl << endl;
}

// CheckingAccount inherits from BankAccount. Hence it can access only the
// public and protected members of BankAccount. It cannot access the private
// members of BankAccount.
class CheckingAccount: public BankAccount {
private:
char accountType[20];

public:
CheckingAccount(char *, char *);
void resetBalance();
}

CheckingAccount::CheckingAccount(char *rNo, char *accNo) {
Strcpy(accountType, "Checking");
changeRoutingNumber(rNo);
changeAccountNumber (accNo);
balance = 0;
}

// Since balance is a protected field, it can be accessed by CheckingAccount
CheckingAccount::void resetBalance() {
balance = 0;
}

int main() {
CheckingAccount ca("888", "999");
ca.depositMoney(100);
displayAccountInfo(ca);
ca.withdrawMoney(50);
displayAccountInfo(ca);
ca.resetBalance();
displayAccountInfo(ca);
}

</pre>

<pre>
OUTPUT:

Account Number: 888
Routing Number: 999
Account Balance: 100

Account Number: 888
Routing Number: 999
Account Balance: 50

Account Number: 888
Routing Number: 999
Account Balance: 0
</pre>

The data members routingNumber, accountNumber are made private and balance is protected. This makes it impossible to directly access or change routingNumber, accountNumber from outside code. Access to these attributes are strictly through the public methods changeRoutingNumber() and changeAccountNumber(). However, private and protected members are accessible through friend functions, so displayAccountInfo() function is able to access all the mentioned fields. Since balance is protected, it can be accessed from a subclass (CheckingAccount) directly as shown above. But the private members have to be accessed through the functions changeRoutingNumber() and changeAccountNumber() instead of being accessed directly.

Thus, it purely at the discretion of the programmer to allow access to these data members through such accessor functions. In the absence of such accessors, there would be no way for any code outside the class to view/modify the private attributes.

===Java===

<pre>
public class BankAccount {
String accountNumber;
private String routingNumber;
private Integer balance;

public void setAccountNumber(String acNo){
this.accountNumber=acNo;
}

public void setRoutingNumber(String rtNo){
this.routingNumber=rtNo;
}

protected void setBalance(Integer bal){
this.balance=bal;
}

public String getAccountNumber(){
return this.accountNumber;
}

public String getRoutingNumber(){
return this.routingNumber;
}

protected Integer getBalance(){
return this.balance;
}

public void showAccountNumber(){
System.out.println(this.accountNumber);
}

public void showRoutingNumber(){
System.out.println(this.routingNumber);
}

public void showBalance(){
System.out.println(this.balance);
}

public void withdraw(Integer amount){
this.balance-=amount;
}

public void deposit(Integer amount){
this.balance+=amount;
}

public static void main(String args[]){
BankAccount Steve = new BankAccount();

//public access to setRoutingNumber/getRoutingNumber
Steve.setRoutingNumber("1234");
String steveRtNo=Steve.getRoutingNumber();
System.out.println(steveRtNo);

//protected access to the method setBalance/getBalance
Steve.setBalance(5000);
System.out.println(Steve.getBalance());
}

}
</pre>

Class BankAccount in the above Java code has public getter/setter methods to access the private data member ‘routingNumber’. Thus, we can invoke these methods using an instance of the BankAccount object: Steve.
The methods setBalance()/ getBalance() are protected. As can be seen, they behave like public methods if invoked in the same package. Protected methods act like private methods if invoked by any instance of a class outside the package.
However, if there is a class ‘InternationalBankAccount’ in a different package such that:
<pre>
public class InternationalBankAccount extends BankAccount {
public String internationalBankAccNo;
}
</pre>

<pre>
InternationalBankAccount Anna = new InternationalBankAccount();
Anna.setBalance(10000);
</pre>

The above is a valid syntax and Anna can access protected member functions of the parent class.
Data member ‘accountNumber’ has default access specifier. Default access specifier is used in Java to support package driven development. Thus ‘accountNumber’ can be accessed from anywhere within the package. However no classes from other packages can access ‘accountNumber’.
Data member balance is a private data member and if it is invoked explicitly as follows,
<pre>
Steve.balance=1000;
</pre>
then the output would be an unresolved compilation error of the form:
<pre>
Unresolved compilation problem: The field bankAccount.balance is not visible
</pre>

===Ruby===
The following code illustrates the use of access specifiers in Ruby.
<pre>
class BankAccount

def initialize(acNo, rtNo, bal)
@accountNumber = acNo
@routingNumber = rtNo
@balance = bal
end

def balance
@balance
end

def routingNumber
@routingNumber
end

def accountNumber
@accountNumber
end

def compare_balance(other)
if other.balance > balance
"The other object has more bank balance."
else
"This object has more bank balance."
end
end

protected:balance
public:routingNumber
private:accountNumber

end
</pre>

<pre>
Steve = BankAccount.new(713, 123, 1000)
Anna = BankAccount.new(923, 125, 2000)
puts Steve.routingNumber()
puts Steve.compare_balance (Anna)
puts Steve.accountNumber()
</pre>

<pre>
Output:
123
The other object has more bank balance.
NoMethodError: private method `accountNumber' called for #<BankAccount:0x2b75320>
</pre>

‘routingNumber’ is a public function. Thus, when we access object Steve’s public method ‘routing number’, we successfully get ‘123’ as the output.
Furthermore, this snippet provides a mechanism for the comparison of one account holder’s balance with another. This comparison involves a call to the method ‘balance’. The object performing the comparison has to ask the other object to execute its balance method. So, balance cannot be private. With ‘balance’ changed to protected instead of private, Steve can ask Anna to execute ‘balance’, because both are instances of the same class. But if we try to call the ‘balance’ method of a bankAccount object when ‘self’ is anything other than a bankAccount object, the method will fail. A protected method is thus just like a private method, but with the exemption for those cases where the class of ‘self’ and the class of the respective object (having the method called on it) are the same.
‘accountNumber’ method is private. Thus user gets a ‘NoMethodError’ on invoking object Steve’s ‘accountNumber’ method. Initialize method in a class is private by default. Whenever the new method is invoked, initialize method is called and instances are created. If we try to invoke the ‘initialize’ method explicitly, we get the same error as in the case when we tried to invoke object Steve’s private ‘accountNumber’ method.

===C#===
<pre>
class BankAccount
{
public BankAccount(string accountNumber, string routingNumber, int balance)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
this.balance = balance;
}

private string accountNumber;
protected string routingNumber;
private int balance;

// accountNumber is private, so it can only be modified from within this
// class. Also, since the following method is private, it can only be called
// from within this class. So this field is truly private.
private void setAccountNumber(string acNo)
{
this.accountNumber=acNo;
}

// routingNumber is protected, so it can be directly modified by objects of
// a subclass. But the contents of this field are made accessible as public
// so anyone can 'read' the value of this field.
public string getRoutingNumber()
{
return this.routingNumber;
}

// Provides access to modify the private member balance, but this function
// can only be called by subclasses (and from within this class).
protected initBalance()
{
this.balance = 0;
}

// Provides access to 'read' the contents of the private field to everyone.
public void getBalance(int balance)
{
return this.balance;
}
}

class Customer : BankAccount
{
Customer(string accountNumber, string routingNumber)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
initBalance();
}
}

class Startup
{
public static void main()
{
Customer cust = new Customer(“999”, “888”, 100);
System.console.WriteLine(cust.getBalance);
}
}

</pre>

The Customer class inherits from the BankAccount class. All protected data members and methods of BankAccount class are accessible directly by an object of the Customer class. The private fields such as accountNumber and routingNumber are not directly accessible. Thus it is possible to call only the initBalance and getBalance methods from Customer. The initBalance method cannot be called by anyone outside the BankAccount class. Also see [http://www.informit.com/articles/article.aspx?p=101373&seqNum=3 this] for another example.

==Conclusion==
Access control is an integral component of object oriented languages and it underlines and emphasizes some the pricipal ideals central to the object-oriented approach. It is possible to maximize the benefits of any O-O language by adhering to, and fully exploiting the capabilities of its access specifiers. Access control is in no way a peripheral add-on or redundant feature of O-O languages, and programmers would only stand to gain by fully appreciating, respecting and understanding their presence.

==References==
<references/>

CSC/ECE 517 Fall 2011/ch1 2b ns

2011-09-30T16:53:31Z

Sshyamr: /* C# */

<h2>Access Control in Object-Oriented Languages</h2>

== Introduction ==
A fundamental precept of O-O systems is that an object should not expose any of its implementation details. In other words, access to an object’s functionality must be tightly regulated. The access control policies of any object-oriented language specify the rules and capabilities for enforcing this regulation. Thus, the concept of Access control ties in deeply with the underlying principles of [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming].

__TOC__
==Purpose of Access Control==
Object-oriented programming fundamentally revolves around the principle of Data Hiding and Encapsulation. In a nutshell, [http://en.wikipedia.org/wiki/Information_hiding Data Hiding] is the practice of securing data by constraining access to it, and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] ensures that the secure data (and the respective member functions) are bundled together as an individual module. All object oriented languages thus need to control the level of access to their critical data (and functions) which is achieved using ''Access Modifiers'' or ''Access Specifiers'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

The need to strictly control ''who'' can access ''what'' is very crucial in Software development. For example, if you make an instance variable 'public', then you can't change the field as the class evolves over time since you might break any external code that uses the field. This is because outside code having complete access to this field, has tied itself indelibly to the inside implementation of the (former) class and is now closely dependent on it. Changing the said field thus entails changing all the other code that have a dependency on it, which is cumbersome, unwieldy and contrary to the principles of an Object Oriented approach which strives for [http://en.wikipedia.org/wiki/Coupling_(computer_programming) Low Coupling].

Thus, the ‘Implementation hiding principle’ leads to a good acid test of an O-O system's quality: Can you make massive changes to a class definition—even throw out the whole thing and replace it with a completely different implementation—without impacting any of the code that uses that class's objects? This sort of modularization is the central premise of object orientation and makes maintenance much easier. Without implementation hiding, there's little point in using other O-O features. Regulation of access - Access Control - is at the heart of Object oriented programming<ref>http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html</ref>.

==Evolution of Access Control and proliferation of Accessor methods==
Access control has been a part of the OOP movement ever since its inception. [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] is arguably one of first and purest of the many OO languages and was developed by Xerox PARC in the Learning Research Group in the 1970s <ref>http://www.zdnet.com/blog/murphy/the-tattered-history-of-oop/1157</ref>. Rather than having explicit access specifiers, smalltalk objects operated more in the sense of 'states' i.e. it would hold the 'state' of object(s) which is always private to that object. Any changes required to be made to this state had to be sent as request message to that object. This is the most primitive form of access control - having private data members and public member functions - the only difference being that the access levels are not explicitly specified.

Access control has evolved over time to become highly complicated <ref>http://www.exforsys.com/tutorials/oops/the-use-of-access-specifiers-in-object-oriented-programming.html</ref> because, the requirements of computing and software development have ballooned considerably in last decade and a half. Complex software requirements mandates complexity in languages, and this has indeed affected the access control policies, which have evolved into something comprehensive, yet - at times - convoluted. Unfortunately today's developers often lose sight of the fundamental motivation behind the existence of extensive access control and lose out on much of the benefits of having a highly cohesive, low coupled system<ref>http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref>.

To elaborate, it has become somewhat of an involuntary practice for present programmers to make ''all'' data members of a class private and provide accessor methods (getters/setters) to all of them (data members). Developers have come to accept this to be a contemporary programmatic-paradigm and by supplying setters and getters for ''everything'', defeat the very purpose of making class-fields private. A long time ago programmers discovered that reducing the scope (visibility) of data as much as possible leads to more reliable and maintainable code<ref>http://typicalprogrammer.com/?p=23</ref>.

Every getter and setter in one’s code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters is a sign of a poorly-designed set of classes. Java<ref>http://www.eclipse-blog.org/eclipse-ide/auto-generating-getters-and-setters.html</ref> and C#<ref>http://forums.asp.net/t/941864.aspx/1</ref> developers have IDEs that generate getters and setters automatically, implying that accessors are a good idea and thus contribute to that popular belief. That is not to say that one must completely abstain from accessors, but rather re-analyze and - if required - redesign the class structure to involve as little exposure of its data members as can be achieved.

==Access Control: A typical example==
Empirically, the data members of a class are held private, and the member functions (public) act as the end points of this class. Via these public methods, one can access the ‘state’ of an object. The following example illustrates this point and shows how access to the data members of a class are specified and controlled by the access modifiers.

[http://en.wikipedia.org/wiki/UML_Diagram#Diagrams_overview UML Diagram] of a BankAccount Class.

[[Image:BankAccount_UML.png|650px|thumb|center|Typical UML diagram of BankAccount.]]

The “(-)/(+)” preceding the members of this class represent the associated access levels. (-) indicates private and (+) indicates public.
The data members ‘accountNumber’, ‘routingNumber’ and ‘balance’ are maintained as private. Thus, an instance of a ‘Customer’ Object (say) cannot directly access or modify this data. Customer has to interact with the public behavior bundled in this module which allows him to view his account information and/or withdraw/deposit money i.e. his visibility of the class is only restricted to that which is made public by the Class.

Using such access specifiers, we can control the level of security and visibility associated with the members of a class. Thus, an Access Specifier can be roughly defined as ''‘A keyword applied to a variable, method, etc. that indicates which other parts of the code are permitted to access it’'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

==Common Access Specifiers in O-O languages==

Although all access specifiers essentially provide the same functionality, their semantics differ among different O-O languages. Here is how access control is implemented in some of the more common O-O languages.

===C++===
*'''private''':All members of the Class that are declared as private can only be accessed by the class's member functions and [http://en.wikipedia.org/wiki/Friend_class friends] of the class.
*'''protected''':All members of the Class that are declared as protected can be accessed by that class's member functions and friends (classes or functions) of the class. Moreover, classes derived from the class also have access to these elements.
*'''public''':Any class or method can have access to these type of elements.

===Java===
Java offers four access specifiers, listed below in order of decreasing accessibility:
*'''public''': All public classes, methods, and fields are the least secure. The Public access specifier must be used if you explicitly want to offer access to these entities and if this access cannot do any conceivable harm.
*'''protected''': Protected methods and fields can only be accessed within the same class to which the methods and fields belong, within its subclasses, and within classes present in the same [http://download.oracle.com/javase/tutorial/java/concepts/package.html Package]. Use of protected access specifier thus only allows its fields to be accessed by those classes which have some semblance of correlation to it - be it in the form of subclasses (correlation through inheritance) or classes within the same package (logical and/or functional correlation i.e. classes in the same package have ''something'' logical/functional common to them <ref>http://download.oracle.com/javase/tutorial/java/concepts/package.html</ref>).
*'''default '''(no specifier): Default access specifier is Java’s fail-safe way to handle security. Via the default access specifier, a class, method, or field will be accessible from inside the same package to which the class, method, or field belongs, but not from outside this package. Default access is thus suited when the source code is compartmentalized and organized into packages.
*'''private''': Private access specifier is a way to secure vital members of a class. Private methods and fields can only be accessed within the same class to which the methods and fields belong. Private methods and fields are not visible within subclasses and are not inherited by subclasses.

===Ruby===
Ruby gives you three levels of protection, listed below in order of decreasing accessibility:
*'''public''':Public methods can be called by everyone - no access control is enforced. A class's instance methods are public by default.
*'''protected''':Protected methods can be invoked only by objects of the defining class and its subclasses. Access is kept within the family.
*'''private''':Private methods cannot be called with an explicit receiver - the receiver is always self. Thus private methods can be called only in the context of the current object and cannot be invoked by another object's private methods.

Access control in Ruby is determined [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically], as the program runs, not statically. You will get an access violation only when the code attempts to execute the restricted method<ref>http://rubylearning.com/satishtalim/ruby_access_control.html</ref>.

===C#===
The following access modifiers specify the accessibility levels in C#
*'''public''':Any public method or member can be accessed by any other code in the same or different package.
*'''private''':The method or member can only be accessed from within the same class.
*'''protected''':The method or member can be accessed only from within the same Class or from within any of the subclasses.
*'''internal''':The type or member can be accessed by any code in the same assembly, but not from another assembly. An assembly in C# is the rough equivalent of a package in java.
*'''protected internal''':The type or member can be accessed by any code in the [http://msdn.microsoft.com/en-us/library/ms173099.aspx Assembly] (also see [http://msdn.microsoft.com/en-us/library/ms173099(v=vs.80).aspx this]) in which it is declared, or from within a derived class in another assembly. Access from another assembly must take place within a class declaration that derives from the class in which the protected internal element is declared, and it must take place through an instance of the derived class type.

===Summary of Access Specfiers in C++, Java, Ruby and C#:===
{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Access Level
! C++
! Java
! Ruby
! C#
|-
! Public
| Anything can access
| Anything can access
| Anything can access
| Anything can access
|-
! Protected
| Class, Subclasses and friends
| Class, Subclasses and classes of same package
| Class and Subclasses
| Class and Subclasses
|-
! Private
| Within Class
| Within Class
| Within Class
| Within Class
|-
! Internal
| --
| --
| --
| Any Class from same Assembly
|-
! Protected internal
| --
| --
| --
| Any Class from same Assembly and Subclass from any Assembly.
|}

==Examples of Access Specifiers==
The following examples exhibit the use of the access specifiers and getter methofs for the aforementioned Bank Account example.

===C++===
<pre>
class BankAccount {
private:
char routingNumber;
char accountNumber;

protected:
int balance;

public:
BankAccount(char *, char *);
void changeAccountNumber(char *);
void changeRoutingNumber(char *);
void depositMoney(int);
void withdrawMoney(int);
friend void displayAccountInfo();
}

BankAccount::BankAccount(char *rNo, char *accNo) {
Strcpy(routingNumber, rNo);
Strcpy(accountNumber, accNo);
balance = 0;
}

BankAccount::void changeAccountNumber(char *accNo){
Strcpy(accountNumber, accNo);
}

BankAccount::void changeRoutingNumber(char *rNo){
Strcpy(routingNumber, rNo);
}

BankAccount::void depositMoney(int amount) {
balance += amount;
}

BankAccount::void withdrawMoney(int amount) {
balance -= amount;
}

// Friend function can access both the private and protected members
// of BankAccount.
void displayAccountInfo(BankAccount ba) {
cout << “Account Number: ” << ba.accountNumber << endl;
cout << “Routing Number: ” << ba.routingNumber << endl;
cout << “Account Balance: ” << ba.balance << endl << endl;
}

// CheckingAccount inherits from BankAccount. Hence it can access only the
// public and protected members of BankAccount. It cannot access the private
// members of BankAccount.
class CheckingAccount: public BankAccount {
private:
char accountType[20];

public:
CheckingAccount(char *, char *);
void resetBalance();
}

CheckingAccount::CheckingAccount(char *rNo, char *accNo) {
Strcpy(accountType, "Checking");
changeRoutingNumber(rNo);
changeAccountNumber (accNo);
balance = 0;
}

// Since balance is a protected field, it can be accessed by CheckingAccount
CheckingAccount::void resetBalance() {
balance = 0;
}

int main() {
CheckingAccount ca("888", "999");
ca.depositMoney(100);
displayAccountInfo(ca);
ca.withdrawMoney(50);
displayAccountInfo(ca);
ca.resetBalance();
displayAccountInfo(ca);
}

</pre>

<pre>
OUTPUT:

Account Number: 888
Routing Number: 999
Account Balance: 100

Account Number: 888
Routing Number: 999
Account Balance: 50

Account Number: 888
Routing Number: 999
Account Balance: 0
</pre>

The data members routingNumber, accountNumber are made private and balance is protected. This makes it impossible to directly access or change routingNumber, accountNumber from outside code. Access to these attributes are strictly through the public methods changeRoutingNumber() and changeAccountNumber(). However, private and protected members are accessible through friend functions, so displayAccountInfo() function is able to access all the mentioned fields. Since balance is protected, it can be accessed from a subclass (CheckingAccount) directly as shown above. But the private members have to be accessed through the functions changeRoutingNumber() and changeAccountNumber() instead of being accessed directly.

Thus, it purely at the discretion of the programmer to allow access to these data members through such accessor functions. In the absence of such accessors, there would be no way for any code outside the class to view/modify the private attributes.

===Java===

<pre>
public class BankAccount {
String accountNumber;
private String routingNumber;
private Integer balance;

public void setAccountNumber(String acNo){
this.accountNumber=acNo;
}

public void setRoutingNumber(String rtNo){
this.routingNumber=rtNo;
}

protected void setBalance(Integer bal){
this.balance=bal;
}

public String getAccountNumber(){
return this.accountNumber;
}

public String getRoutingNumber(){
return this.routingNumber;
}

protected Integer getBalance(){
return this.balance;
}

public void showAccountNumber(){
System.out.println(this.accountNumber);
}

public void showRoutingNumber(){
System.out.println(this.routingNumber);
}

public void showBalance(){
System.out.println(this.balance);
}

public void withdraw(Integer amount){
this.balance-=amount;
}

public void deposit(Integer amount){
this.balance+=amount;
}

public static void main(String args[]){
BankAccount Steve = new BankAccount();

//public access to setRoutingNumber/getRoutingNumber
Steve.setRoutingNumber("1234");
String steveRtNo=Steve.getRoutingNumber();
System.out.println(steveRtNo);

//protected access to the method setBalance/getBalance
Steve.setBalance(5000);
System.out.println(Steve.getBalance());
}

}
</pre>

Class BankAccount in the above Java code has public getter/setter methods to access the private data member ‘routingNumber’. Thus, we can invoke these methods using an instance of the BankAccount object: Steve.
The methods setBalance()/ getBalance() are protected. As can be seen, they behave like public methods if invoked in the same package. Protected methods act like private methods if invoked by any instance of a class outside the package.
However, if there is a class ‘InternationalBankAccount’ in a different package such that:
<pre>
public class InternationalBankAccount extends BankAccount {
public String internationalBankAccNo;
}
</pre>

<pre>
InternationalBankAccount Anna = new InternationalBankAccount();
Anna.setBalance(10000);
</pre>

The above is a valid syntax and Anna can access protected member functions of the parent class.
Data member ‘accountNumber’ has default access specifier. Default access specifier is used in Java to support package driven development. Thus ‘accountNumber’ can be accessed from anywhere within the package. However no classes from other packages can access ‘accountNumber’.
Data member balance is a private data member and if it is invoked explicitly as follows,
<pre>
Steve.balance=1000;
</pre>
then the output would be an unresolved compilation error of the form:
<pre>
Unresolved compilation problem: The field bankAccount.balance is not visible
</pre>

===Ruby===
The following code illustrates the use of access specifiers in Ruby.
<pre>
class BankAccount

def initialize(acNo, rtNo, bal)
@accountNumber = acNo
@routingNumber = rtNo
@balance = bal
end

def balance
@balance
end

def routingNumber
@routingNumber
end

def accountNumber
@accountNumber
end

def compare_balance(other)
if other.balance > balance
"The other object has more bank balance."
else
"This object has more bank balance."
end
end

protected:balance
public:routingNumber
private:accountNumber

end
</pre>

<pre>
Steve = BankAccount.new(713, 123, 1000)
Anna = BankAccount.new(923, 125, 2000)
puts Steve.routingNumber()
puts Steve.compare_balance (Anna)
puts Steve.accountNumber()
</pre>

<pre>
Output:
123
The other object has more bank balance.
NoMethodError: private method `accountNumber' called for #<BankAccount:0x2b75320>
</pre>

‘routingNumber’ is a public function. Thus, when we access object Steve’s public method ‘routing number’, we successfully get ‘123’ as the output.
Furthermore, this snippet provides a mechanism for the comparison of one account holder’s balance with another. This comparison involves a call to the method ‘balance’. The object performing the comparison has to ask the other object to execute its balance method. So, balance cannot be private. With ‘balance’ changed to protected instead of private, Steve can ask Anna to execute ‘balance’, because both are instances of the same class. But if we try to call the ‘balance’ method of a bankAccount object when ‘self’ is anything other than a bankAccount object, the method will fail. A protected method is thus just like a private method, but with the exemption for those cases where the class of ‘self’ and the class of the respective object (having the method called on it) are the same.
‘accountNumber’ method is private. Thus user gets a ‘NoMethodError’ on invoking object Steve’s ‘accountNumber’ method. Initialize method in a class is private by default. Whenever the new method is invoked, initialize method is called and instances are created. If we try to invoke the ‘initialize’ method explicitly, we get the same error as in the case when we tried to invoke object Steve’s private ‘accountNumber’ method.

===C#===
<pre>
class BankAccount
{
public BankAccount(string accountNumber, string routingNumber, int balance)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
this.balance = balance;
}

private string accountNumber;
protected string routingNumber;
private int balance;

// accountNumber is private, so it can only be modified from within this
// class. Also, since the following method is private, it can only be called
// from within this class. So this field is truly private.
private void setAccountNumber(string acNo)
{
this.accountNumber=acNo;
}

// routingNumber is protected, so it can be directly modified by objects of
// a subclass. But the contents of this field are made accessible as public
// so anyone can 'read' the value of this field.
public string getRoutingNumber()
{
return this.routingNumber;
}

// Provides access to modify the private member balance, but this function
// can only be called by subclasses (and from within this class).
protected initBalance()
{
this.balance = 0;
}

// Provides access to 'read' the contents of the private field to everyone.
public void getBalance(int balance)
{
return this.balance;
}
}

class Customer : BankAccount
{
Customer(string accountNumber, string routingNumber)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
initBalance();
}
}

class Startup
{
public static void main()
{
Customer cust = new Customer(“999”, “888”, 100);
System.console.WriteLine(cust.getBalance);
}
}

</pre>

The Customer class inherits from the BankAccount class. All protected data members and methods of BankAccount class are accessible directly by an object of the Customer class. The private fields such as accountNumber and routingNumber are not directly accessible. Thus it is possible to call only the initBalance and getBalance methods from Customer. The initBalance method cannot be called by anyone outside the BankAccount class.

==Conclusion==
Access control is an integral component of object oriented languages and it underlines and emphasizes some the pricipal ideals central to the object-oriented approach. It is possible to maximize the benefits of any O-O language by adhering to, and fully exploiting the capabilities of its access specifiers. Access control is in no way a peripheral add-on or redundant feature of O-O languages, and programmers would only stand to gain by fully appreciating, respecting and understanding their presence.

==References==
<references/>

CSC/ECE 517 Fall 2011/ch1 2b ns

2011-09-30T16:42:10Z

Sshyamr: /* C++ */

<h2>Access Control in Object-Oriented Languages</h2>

== Introduction ==
A fundamental precept of O-O systems is that an object should not expose any of its implementation details. In other words, access to an object’s functionality must be tightly regulated. The access control policies of any object-oriented language specify the rules and capabilities for enforcing this regulation. Thus, the concept of Access control ties in deeply with the underlying principles of [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming].

__TOC__
==Purpose of Access Control==
Object-oriented programming fundamentally revolves around the principle of Data Hiding and Encapsulation. In a nutshell, [http://en.wikipedia.org/wiki/Information_hiding Data Hiding] is the practice of securing data by constraining access to it, and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] ensures that the secure data (and the respective member functions) are bundled together as an individual module. All object oriented languages thus need to control the level of access to their critical data (and functions) which is achieved using ''Access Modifiers'' or ''Access Specifiers'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

The need to strictly control ''who'' can access ''what'' is very crucial in Software development. For example, if you make an instance variable 'public', then you can't change the field as the class evolves over time since you might break any external code that uses the field. This is because outside code having complete access to this field, has tied itself indelibly to the inside implementation of the (former) class and is now closely dependent on it. Changing the said field thus entails changing all the other code that have a dependency on it, which is cumbersome, unwieldy and contrary to the principles of an Object Oriented approach which strives for [http://en.wikipedia.org/wiki/Coupling_(computer_programming) Low Coupling].

Thus, the ‘Implementation hiding principle’ leads to a good acid test of an O-O system's quality: Can you make massive changes to a class definition—even throw out the whole thing and replace it with a completely different implementation—without impacting any of the code that uses that class's objects? This sort of modularization is the central premise of object orientation and makes maintenance much easier. Without implementation hiding, there's little point in using other O-O features. Regulation of access - Access Control - is at the heart of Object oriented programming<ref>http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html</ref>.

==Evolution of Access Control and proliferation of Accessor methods==
Access control has been a part of the OOP movement ever since its inception. [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] is arguably one of first and purest of the many OO languages and was developed by Xerox PARC in the Learning Research Group in the 1970s <ref>http://www.zdnet.com/blog/murphy/the-tattered-history-of-oop/1157</ref>. Rather than having explicit access specifiers, smalltalk objects operated more in the sense of 'states' i.e. it would hold the 'state' of object(s) which is always private to that object. Any changes required to be made to this state had to be sent as request message to that object. This is the most primitive form of access control - having private data members and public member functions - the only difference being that the access levels are not explicitly specified.

Access control has evolved over time to become highly complicated <ref>http://www.exforsys.com/tutorials/oops/the-use-of-access-specifiers-in-object-oriented-programming.html</ref> because, the requirements of computing and software development have ballooned considerably in last decade and a half. Complex software requirements mandates complexity in languages, and this has indeed affected the access control policies, which have evolved into something comprehensive, yet - at times - convoluted. Unfortunately today's developers often lose sight of the fundamental motivation behind the existence of extensive access control and lose out on much of the benefits of having a highly cohesive, low coupled system<ref>http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref>.

To elaborate, it has become somewhat of an involuntary practice for present programmers to make ''all'' data members of a class private and provide accessor methods (getters/setters) to all of them (data members). Developers have come to accept this to be a contemporary programmatic-paradigm and by supplying setters and getters for ''everything'', defeat the very purpose of making class-fields private. A long time ago programmers discovered that reducing the scope (visibility) of data as much as possible leads to more reliable and maintainable code<ref>http://typicalprogrammer.com/?p=23</ref>.

Every getter and setter in one’s code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters is a sign of a poorly-designed set of classes. Java<ref>http://www.eclipse-blog.org/eclipse-ide/auto-generating-getters-and-setters.html</ref> and C#<ref>http://forums.asp.net/t/941864.aspx/1</ref> developers have IDEs that generate getters and setters automatically, implying that accessors are a good idea and thus contribute to that popular belief. That is not to say that one must completely abstain from accessors, but rather re-analyze and - if required - redesign the class structure to involve as little exposure of its data members as can be achieved.

==Access Control: A typical example==
Empirically, the data members of a class are held private, and the member functions (public) act as the end points of this class. Via these public methods, one can access the ‘state’ of an object. The following example illustrates this point and shows how access to the data members of a class are specified and controlled by the access modifiers.

[http://en.wikipedia.org/wiki/UML_Diagram#Diagrams_overview UML Diagram] of a BankAccount Class.

[[Image:BankAccount_UML.png|650px|thumb|center|Typical UML diagram of BankAccount.]]

The “(-)/(+)” preceding the members of this class represent the associated access levels. (-) indicates private and (+) indicates public.
The data members ‘accountNumber’, ‘routingNumber’ and ‘balance’ are maintained as private. Thus, an instance of a ‘Customer’ Object (say) cannot directly access or modify this data. Customer has to interact with the public behavior bundled in this module which allows him to view his account information and/or withdraw/deposit money i.e. his visibility of the class is only restricted to that which is made public by the Class.

Using such access specifiers, we can control the level of security and visibility associated with the members of a class. Thus, an Access Specifier can be roughly defined as ''‘A keyword applied to a variable, method, etc. that indicates which other parts of the code are permitted to access it’'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

==Common Access Specifiers in O-O languages==

Although all access specifiers essentially provide the same functionality, their semantics differ among different O-O languages. Here is how access control is implemented in some of the more common O-O languages.

===C++===
*'''private''':All members of the Class that are declared as private can only be accessed by the class's member functions and [http://en.wikipedia.org/wiki/Friend_class friends] of the class.
*'''protected''':All members of the Class that are declared as protected can be accessed by that class's member functions and friends (classes or functions) of the class. Moreover, classes derived from the class also have access to these elements.
*'''public''':Any class or method can have access to these type of elements.

===Java===
Java offers four access specifiers, listed below in order of decreasing accessibility:
*'''public''': All public classes, methods, and fields are the least secure. The Public access specifier must be used if you explicitly want to offer access to these entities and if this access cannot do any conceivable harm.
*'''protected''': Protected methods and fields can only be accessed within the same class to which the methods and fields belong, within its subclasses, and within classes present in the same [http://download.oracle.com/javase/tutorial/java/concepts/package.html Package]. Use of protected access specifier thus only allows its fields to be accessed by those classes which have some semblance of correlation to it - be it in the form of subclasses (correlation through inheritance) or classes within the same package (logical and/or functional correlation i.e. classes in the same package have ''something'' logical/functional common to them <ref>http://download.oracle.com/javase/tutorial/java/concepts/package.html</ref>).
*'''default '''(no specifier): Default access specifier is Java’s fail-safe way to handle security. Via the default access specifier, a class, method, or field will be accessible from inside the same package to which the class, method, or field belongs, but not from outside this package. Default access is thus suited when the source code is compartmentalized and organized into packages.
*'''private''': Private access specifier is a way to secure vital members of a class. Private methods and fields can only be accessed within the same class to which the methods and fields belong. Private methods and fields are not visible within subclasses and are not inherited by subclasses.

===Ruby===
Ruby gives you three levels of protection, listed below in order of decreasing accessibility:
*'''public''':Public methods can be called by everyone - no access control is enforced. A class's instance methods are public by default.
*'''protected''':Protected methods can be invoked only by objects of the defining class and its subclasses. Access is kept within the family.
*'''private''':Private methods cannot be called with an explicit receiver - the receiver is always self. Thus private methods can be called only in the context of the current object and cannot be invoked by another object's private methods.

Access control in Ruby is determined [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically], as the program runs, not statically. You will get an access violation only when the code attempts to execute the restricted method<ref>http://rubylearning.com/satishtalim/ruby_access_control.html</ref>.

===C#===
The following access modifiers specify the accessibility levels in C#
*'''public''':Any public method or member can be accessed by any other code in the same or different package.
*'''private''':The method or member can only be accessed from within the same class.
*'''protected''':The method or member can be accessed only from within the same Class or from within any of the subclasses.
*'''internal''':The type or member can be accessed by any code in the same assembly, but not from another assembly. An assembly in C# is the rough equivalent of a package in java.
*'''protected internal''':The type or member can be accessed by any code in the [http://msdn.microsoft.com/en-us/library/ms173099.aspx Assembly] (also see [http://msdn.microsoft.com/en-us/library/ms173099(v=vs.80).aspx this]) in which it is declared, or from within a derived class in another assembly. Access from another assembly must take place within a class declaration that derives from the class in which the protected internal element is declared, and it must take place through an instance of the derived class type.

===Summary of Access Specfiers in C++, Java, Ruby and C#:===
{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Access Level
! C++
! Java
! Ruby
! C#
|-
! Public
| Anything can access
| Anything can access
| Anything can access
| Anything can access
|-
! Protected
| Class, Subclasses and friends
| Class, Subclasses and classes of same package
| Class and Subclasses
| Class and Subclasses
|-
! Private
| Within Class
| Within Class
| Within Class
| Within Class
|-
! Internal
| --
| --
| --
| Any Class from same Assembly
|-
! Protected internal
| --
| --
| --
| Any Class from same Assembly and Subclass from any Assembly.
|}

==Examples of Access Specifiers==
The following examples exhibit the use of the access specifiers and getter methofs for the aforementioned Bank Account example.

===C++===
<pre>
class BankAccount {
private:
char routingNumber;
char accountNumber;

protected:
int balance;

public:
BankAccount(char *, char *);
void changeAccountNumber(char *);
void changeRoutingNumber(char *);
void depositMoney(int);
void withdrawMoney(int);
friend void displayAccountInfo();
}

BankAccount::BankAccount(char *rNo, char *accNo) {
Strcpy(routingNumber, rNo);
Strcpy(accountNumber, accNo);
balance = 0;
}

BankAccount::void changeAccountNumber(char *accNo){
Strcpy(accountNumber, accNo);
}

BankAccount::void changeRoutingNumber(char *rNo){
Strcpy(routingNumber, rNo);
}

BankAccount::void depositMoney(int amount) {
balance += amount;
}

BankAccount::void withdrawMoney(int amount) {
balance -= amount;
}

// Friend function can access both the private and protected members
// of BankAccount.
void displayAccountInfo(BankAccount ba) {
cout << “Account Number: ” << ba.accountNumber << endl;
cout << “Routing Number: ” << ba.routingNumber << endl;
cout << “Account Balance: ” << ba.balance << endl << endl;
}

// CheckingAccount inherits from BankAccount. Hence it can access only the
// public and protected members of BankAccount. It cannot access the private
// members of BankAccount.
class CheckingAccount: public BankAccount {
private:
char accountType[20];

public:
CheckingAccount(char *, char *);
void resetBalance();
}

CheckingAccount::CheckingAccount(char *rNo, char *accNo) {
Strcpy(accountType, "Checking");
changeRoutingNumber(rNo);
changeAccountNumber (accNo);
balance = 0;
}

// Since balance is a protected field, it can be accessed by CheckingAccount
CheckingAccount::void resetBalance() {
balance = 0;
}

int main() {
CheckingAccount ca("888", "999");
ca.depositMoney(100);
displayAccountInfo(ca);
ca.withdrawMoney(50);
displayAccountInfo(ca);
ca.resetBalance();
displayAccountInfo(ca);
}

</pre>

<pre>
OUTPUT:

Account Number: 888
Routing Number: 999
Account Balance: 100

Account Number: 888
Routing Number: 999
Account Balance: 50

Account Number: 888
Routing Number: 999
Account Balance: 0
</pre>

The data members routingNumber, accountNumber are made private and balance is protected. This makes it impossible to directly access or change routingNumber, accountNumber from outside code. Access to these attributes are strictly through the public methods changeRoutingNumber() and changeAccountNumber(). However, private and protected members are accessible through friend functions, so displayAccountInfo() function is able to access all the mentioned fields. Since balance is protected, it can be accessed from a subclass (CheckingAccount) directly as shown above. But the private members have to be accessed through the functions changeRoutingNumber() and changeAccountNumber() instead of being accessed directly.

Thus, it purely at the discretion of the programmer to allow access to these data members through such accessor functions. In the absence of such accessors, there would be no way for any code outside the class to view/modify the private attributes.

===Java===

<pre>
public class BankAccount {
String accountNumber;
private String routingNumber;
private Integer balance;

public void setAccountNumber(String acNo){
this.accountNumber=acNo;
}

public void setRoutingNumber(String rtNo){
this.routingNumber=rtNo;
}

protected void setBalance(Integer bal){
this.balance=bal;
}

public String getAccountNumber(){
return this.accountNumber;
}

public String getRoutingNumber(){
return this.routingNumber;
}

protected Integer getBalance(){
return this.balance;
}

public void showAccountNumber(){
System.out.println(this.accountNumber);
}

public void showRoutingNumber(){
System.out.println(this.routingNumber);
}

public void showBalance(){
System.out.println(this.balance);
}

public void withdraw(Integer amount){
this.balance-=amount;
}

public void deposit(Integer amount){
this.balance+=amount;
}

public static void main(String args[]){
BankAccount Steve = new BankAccount();

//public access to setRoutingNumber/getRoutingNumber
Steve.setRoutingNumber("1234");
String steveRtNo=Steve.getRoutingNumber();
System.out.println(steveRtNo);

//protected access to the method setBalance/getBalance
Steve.setBalance(5000);
System.out.println(Steve.getBalance());
}

}
</pre>

Class BankAccount in the above Java code has public getter/setter methods to access the private data member ‘routingNumber’. Thus, we can invoke these methods using an instance of the BankAccount object: Steve.
The methods setBalance()/ getBalance() are protected. As can be seen, they behave like public methods if invoked in the same package. Protected methods act like private methods if invoked by any instance of a class outside the package.
However, if there is a class ‘InternationalBankAccount’ in a different package such that:
<pre>
public class InternationalBankAccount extends BankAccount {
public String internationalBankAccNo;
}
</pre>

<pre>
InternationalBankAccount Anna = new InternationalBankAccount();
Anna.setBalance(10000);
</pre>

The above is a valid syntax and Anna can access protected member functions of the parent class.
Data member ‘accountNumber’ has default access specifier. Default access specifier is used in Java to support package driven development. Thus ‘accountNumber’ can be accessed from anywhere within the package. However no classes from other packages can access ‘accountNumber’.
Data member balance is a private data member and if it is invoked explicitly as follows,
<pre>
Steve.balance=1000;
</pre>
then the output would be an unresolved compilation error of the form:
<pre>
Unresolved compilation problem: The field bankAccount.balance is not visible
</pre>

===Ruby===
The following code illustrates the use of access specifiers in Ruby.
<pre>
class BankAccount

def initialize(acNo, rtNo, bal)
@accountNumber = acNo
@routingNumber = rtNo
@balance = bal
end

def balance
@balance
end

def routingNumber
@routingNumber
end

def accountNumber
@accountNumber
end

def compare_balance(other)
if other.balance > balance
"The other object has more bank balance."
else
"This object has more bank balance."
end
end

protected:balance
public:routingNumber
private:accountNumber

end
</pre>

<pre>
Steve = BankAccount.new(713, 123, 1000)
Anna = BankAccount.new(923, 125, 2000)
puts Steve.routingNumber()
puts Steve.compare_balance (Anna)
puts Steve.accountNumber()
</pre>

<pre>
Output:
123
The other object has more bank balance.
NoMethodError: private method `accountNumber' called for #<BankAccount:0x2b75320>
</pre>

‘routingNumber’ is a public function. Thus, when we access object Steve’s public method ‘routing number’, we successfully get ‘123’ as the output.
Furthermore, this snippet provides a mechanism for the comparison of one account holder’s balance with another. This comparison involves a call to the method ‘balance’. The object performing the comparison has to ask the other object to execute its balance method. So, balance cannot be private. With ‘balance’ changed to protected instead of private, Steve can ask Anna to execute ‘balance’, because both are instances of the same class. But if we try to call the ‘balance’ method of a bankAccount object when ‘self’ is anything other than a bankAccount object, the method will fail. A protected method is thus just like a private method, but with the exemption for those cases where the class of ‘self’ and the class of the respective object (having the method called on it) are the same.
‘accountNumber’ method is private. Thus user gets a ‘NoMethodError’ on invoking object Steve’s ‘accountNumber’ method. Initialize method in a class is private by default. Whenever the new method is invoked, initialize method is called and instances are created. If we try to invoke the ‘initialize’ method explicitly, we get the same error as in the case when we tried to invoke object Steve’s private ‘accountNumber’ method.

===C#===
<pre>
class BankAccount
{
public BankAccount(string accountNumber, string routingNumber, int balance)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
this.balance = balance;
}

protected string accountNumber;
protected string routingNumber;
private int balance;

private void setAccountNumber(string acNo)
{
this.accountNumber=acNo;
}

private void setRoutingNumber(string rtNo)
{
this.routingNumber=rtNo;
}

protected initBalance()
{
this.balance = 0;
}

public void getBalance(int balance)
{
return this.balance;
}
}

class Customer : BankAccount
{
Customer(string accountNumber, string routingNumber)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
initBalance();
}
}

class Startup
{
public static void main()
{
Customer cust = new Customer(“999”, “888”, 100);
System.console.WriteLine(cust.getBalance);
}
}

</pre>

The Customer class inherits from the BankAccount class. All protected data members and methods of BankAccount class are accessible directly by an object of the Customer class. The private fields such as accountNumber and routingNumber are not directly accessible. Thus it is possible to call only the initBalance and getBalance methods from Customer. The initBalance method cannot be called by anyone outside the BankAccount class.

==Conclusion==
Access control is an integral component of object oriented languages and it underlines and emphasizes some the pricipal ideals central to the object-oriented approach. It is possible to maximize the benefits of any O-O language by adhering to, and fully exploiting the capabilities of its access specifiers. Access control is in no way a peripheral add-on or redundant feature of O-O languages, and programmers would only stand to gain by fully appreciating, respecting and understanding their presence.

==References==
<references/>

CSC/ECE 517 Fall 2011/ch1 2b ns

2011-09-30T16:36:12Z

Sshyamr: /* C++ */

<h2>Access Control in Object-Oriented Languages</h2>

== Introduction ==
A fundamental precept of O-O systems is that an object should not expose any of its implementation details. In other words, access to an object’s functionality must be tightly regulated. The access control policies of any object-oriented language specify the rules and capabilities for enforcing this regulation. Thus, the concept of Access control ties in deeply with the underlying principles of [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming].

__TOC__
==Purpose of Access Control==
Object-oriented programming fundamentally revolves around the principle of Data Hiding and Encapsulation. In a nutshell, [http://en.wikipedia.org/wiki/Information_hiding Data Hiding] is the practice of securing data by constraining access to it, and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] ensures that the secure data (and the respective member functions) are bundled together as an individual module. All object oriented languages thus need to control the level of access to their critical data (and functions) which is achieved using ''Access Modifiers'' or ''Access Specifiers'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

The need to strictly control ''who'' can access ''what'' is very crucial in Software development. For example, if you make an instance variable 'public', then you can't change the field as the class evolves over time since you might break any external code that uses the field. This is because outside code having complete access to this field, has tied itself indelibly to the inside implementation of the (former) class and is now closely dependent on it. Changing the said field thus entails changing all the other code that have a dependency on it, which is cumbersome, unwieldy and contrary to the principles of an Object Oriented approach which strives for [http://en.wikipedia.org/wiki/Coupling_(computer_programming) Low Coupling].

Thus, the ‘Implementation hiding principle’ leads to a good acid test of an O-O system's quality: Can you make massive changes to a class definition—even throw out the whole thing and replace it with a completely different implementation—without impacting any of the code that uses that class's objects? This sort of modularization is the central premise of object orientation and makes maintenance much easier. Without implementation hiding, there's little point in using other O-O features. Regulation of access - Access Control - is at the heart of Object oriented programming<ref>http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html</ref>.

==Evolution of Access Control and proliferation of Accessor methods==
Access control has been a part of the OOP movement ever since its inception. [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] is arguably one of first and purest of the many OO languages and was developed by Xerox PARC in the Learning Research Group in the 1970s <ref>http://www.zdnet.com/blog/murphy/the-tattered-history-of-oop/1157</ref>. Rather than having explicit access specifiers, smalltalk objects operated more in the sense of 'states' i.e. it would hold the 'state' of object(s) which is always private to that object. Any changes required to be made to this state had to be sent as request message to that object. This is the most primitive form of access control - having private data members and public member functions - the only difference being that the access levels are not explicitly specified.

Access control has evolved over time to become highly complicated <ref>http://www.exforsys.com/tutorials/oops/the-use-of-access-specifiers-in-object-oriented-programming.html</ref> because, the requirements of computing and software development have ballooned considerably in last decade and a half. Complex software requirements mandates complexity in languages, and this has indeed affected the access control policies, which have evolved into something comprehensive, yet - at times - convoluted. Unfortunately today's developers often lose sight of the fundamental motivation behind the existence of extensive access control and lose out on much of the benefits of having a highly cohesive, low coupled system<ref>http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref>.

To elaborate, it has become somewhat of an involuntary practice for present programmers to make ''all'' data members of a class private and provide accessor methods (getters/setters) to all of them (data members). Developers have come to accept this to be a contemporary programmatic-paradigm and by supplying setters and getters for ''everything'', defeat the very purpose of making class-fields private. A long time ago programmers discovered that reducing the scope (visibility) of data as much as possible leads to more reliable and maintainable code<ref>http://typicalprogrammer.com/?p=23</ref>.

Every getter and setter in one’s code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters is a sign of a poorly-designed set of classes. Java<ref>http://www.eclipse-blog.org/eclipse-ide/auto-generating-getters-and-setters.html</ref> and C#<ref>http://forums.asp.net/t/941864.aspx/1</ref> developers have IDEs that generate getters and setters automatically, implying that accessors are a good idea and thus contribute to that popular belief. That is not to say that one must completely abstain from accessors, but rather re-analyze and - if required - redesign the class structure to involve as little exposure of its data members as can be achieved.

==Access Control: A typical example==
Empirically, the data members of a class are held private, and the member functions (public) act as the end points of this class. Via these public methods, one can access the ‘state’ of an object. The following example illustrates this point and shows how access to the data members of a class are specified and controlled by the access modifiers.

[http://en.wikipedia.org/wiki/UML_Diagram#Diagrams_overview UML Diagram] of a BankAccount Class.

[[Image:BankAccount_UML.png|650px|thumb|center|Typical UML diagram of BankAccount.]]

The “(-)/(+)” preceding the members of this class represent the associated access levels. (-) indicates private and (+) indicates public.
The data members ‘accountNumber’, ‘routingNumber’ and ‘balance’ are maintained as private. Thus, an instance of a ‘Customer’ Object (say) cannot directly access or modify this data. Customer has to interact with the public behavior bundled in this module which allows him to view his account information and/or withdraw/deposit money i.e. his visibility of the class is only restricted to that which is made public by the Class.

Using such access specifiers, we can control the level of security and visibility associated with the members of a class. Thus, an Access Specifier can be roughly defined as ''‘A keyword applied to a variable, method, etc. that indicates which other parts of the code are permitted to access it’'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

==Common Access Specifiers in O-O languages==

Although all access specifiers essentially provide the same functionality, their semantics differ among different O-O languages. Here is how access control is implemented in some of the more common O-O languages.

===C++===
*'''private''':All members of the Class that are declared as private can only be accessed by the class's member functions and [http://en.wikipedia.org/wiki/Friend_class friends] of the class.
*'''protected''':All members of the Class that are declared as protected can be accessed by that class's member functions and friends (classes or functions) of the class. Moreover, classes derived from the class also have access to these elements.
*'''public''':Any class or method can have access to these type of elements.

===Java===
Java offers four access specifiers, listed below in order of decreasing accessibility:
*'''public''': All public classes, methods, and fields are the least secure. The Public access specifier must be used if you explicitly want to offer access to these entities and if this access cannot do any conceivable harm.
*'''protected''': Protected methods and fields can only be accessed within the same class to which the methods and fields belong, within its subclasses, and within classes present in the same [http://download.oracle.com/javase/tutorial/java/concepts/package.html Package]. Use of protected access specifier thus only allows its fields to be accessed by those classes which have some semblance of correlation to it - be it in the form of subclasses (correlation through inheritance) or classes within the same package (logical and/or functional correlation i.e. classes in the same package have ''something'' logical/functional common to them <ref>http://download.oracle.com/javase/tutorial/java/concepts/package.html</ref>).
*'''default '''(no specifier): Default access specifier is Java’s fail-safe way to handle security. Via the default access specifier, a class, method, or field will be accessible from inside the same package to which the class, method, or field belongs, but not from outside this package. Default access is thus suited when the source code is compartmentalized and organized into packages.
*'''private''': Private access specifier is a way to secure vital members of a class. Private methods and fields can only be accessed within the same class to which the methods and fields belong. Private methods and fields are not visible within subclasses and are not inherited by subclasses.

===Ruby===
Ruby gives you three levels of protection, listed below in order of decreasing accessibility:
*'''public''':Public methods can be called by everyone - no access control is enforced. A class's instance methods are public by default.
*'''protected''':Protected methods can be invoked only by objects of the defining class and its subclasses. Access is kept within the family.
*'''private''':Private methods cannot be called with an explicit receiver - the receiver is always self. Thus private methods can be called only in the context of the current object and cannot be invoked by another object's private methods.

Access control in Ruby is determined [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically], as the program runs, not statically. You will get an access violation only when the code attempts to execute the restricted method<ref>http://rubylearning.com/satishtalim/ruby_access_control.html</ref>.

===C#===
The following access modifiers specify the accessibility levels in C#
*'''public''':Any public method or member can be accessed by any other code in the same or different package.
*'''private''':The method or member can only be accessed from within the same class.
*'''protected''':The method or member can be accessed only from within the same Class or from within any of the subclasses.
*'''internal''':The type or member can be accessed by any code in the same assembly, but not from another assembly. An assembly in C# is the rough equivalent of a package in java.
*'''protected internal''':The type or member can be accessed by any code in the [http://msdn.microsoft.com/en-us/library/ms173099.aspx Assembly] (also see [http://msdn.microsoft.com/en-us/library/ms173099(v=vs.80).aspx this]) in which it is declared, or from within a derived class in another assembly. Access from another assembly must take place within a class declaration that derives from the class in which the protected internal element is declared, and it must take place through an instance of the derived class type.

===Summary of Access Specfiers in C++, Java, Ruby and C#:===
{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Access Level
! C++
! Java
! Ruby
! C#
|-
! Public
| Anything can access
| Anything can access
| Anything can access
| Anything can access
|-
! Protected
| Class, Subclasses and friends
| Class, Subclasses and classes of same package
| Class and Subclasses
| Class and Subclasses
|-
! Private
| Within Class
| Within Class
| Within Class
| Within Class
|-
! Internal
| --
| --
| --
| Any Class from same Assembly
|-
! Protected internal
| --
| --
| --
| Any Class from same Assembly and Subclass from any Assembly.
|}

==Examples of Access Specifiers==
The following examples exhibit the use of the access specifiers and getter methofs for the aforementioned Bank Account example.

===C++===
<pre>
class BankAccount {
private:
char routingNumber;
char accountNumber;

protected:
int balance;

public:
BankAccount(char *, char *);
void changeAccountNumber(char *);
void changeRoutingtNumber(char *);
void depositMoney(int);
void withdrawMoney(int);
friend void displayAccountInfo();
}

BankAccount::BankAccount(char *rNo, char *accNo) {
Strcpy(routingNumber, rNo);
Strcpy(accountNumber, accNo);
balance = 0;
}

BankAccount::void changeAccountNumber(char *accNo){
Strcpy(accountNumber, accNo);
}

BankAccount::void changeRoutingtNumber(char *rNo){
Strcpy(routingNumber, rNo);
}

BankAccount::void depositMoney(int amount) {
balance += amount;
}

BankAccount::void withdrawMoney(int amount) {
balance -= amount;
}

// Friend function can access both the private and protected members
// of BankAccount.
void displayAccountInfo(BankAccount ba) {
cout << “Account Number: ” << ba.accountNumber << endl;
cout << “Routing Number: ” << ba.routingNumber << endl;
cout << “Account Balance: ” << ba.balance << endl << endl;
}

// CheckingAccount inherits from BankAccount. Hence it can access only the
// public and protected members of BankAccount. It cannot access the private
// members of BankAccount.
class CheckingAccount: public BankAccount {
private:
char accountType[20];

public:
CheckingAccount(char *, char *);
void resetBalance();
}

CheckingAccount::CheckingAccount(char *rNo, char *accNo) {
Strcpy(accountType, "Checking");
changeRoutingtNumber(rNo);
changeAccountNumber (accNo);
balance = 0;
}

// Since balance is a protected field, it can be accessed by CheckingAccount
CheckingAccount::void resetBalance() {
balance = 0;
}

int main() {
CheckingAccount ca("888", "999");
ca.depositMoney(100);
displayAccountInfo(ca);
ca.withdrawMoney(50);
displayAccountInfo(ca);
ca.resetBalance();
displayAccountInfo(ca);
}

</pre>

<pre>
OUTPUT:

Account Number: 888
Routing Number: 999
Account Balance: 100

Account Number: 888
Routing Number: 999
Account Balance: 50

Account Number: 888
Routing Number: 999
Account Balance: 0
</pre>

All the datamambers routingNumber, accountNumber and balance are made private. This makes it impossible to directly access or change these data members from outside code. Access to these attributes are strictly through the public methods changeRoutingNumber() and changeAccountNumber(). Thus, it purely at the discretion of the programmer to allow access to these data members through such accessor functions. In the absence of such accessors, there would be no way for any code outside the class to view/modify the private attributes.

===Java===

<pre>
public class BankAccount {
String accountNumber;
private String routingNumber;
private Integer balance;

public void setAccountNumber(String acNo){
this.accountNumber=acNo;
}

public void setRoutingNumber(String rtNo){
this.routingNumber=rtNo;
}

protected void setBalance(Integer bal){
this.balance=bal;
}

public String getAccountNumber(){
return this.accountNumber;
}

public String getRoutingNumber(){
return this.routingNumber;
}

protected Integer getBalance(){
return this.balance;
}

public void showAccountNumber(){
System.out.println(this.accountNumber);
}

public void showRoutingNumber(){
System.out.println(this.routingNumber);
}

public void showBalance(){
System.out.println(this.balance);
}

public void withdraw(Integer amount){
this.balance-=amount;
}

public void deposit(Integer amount){
this.balance+=amount;
}

public static void main(String args[]){
BankAccount Steve = new BankAccount();

//public access to setRoutingNumber/getRoutingNumber
Steve.setRoutingNumber("1234");
String steveRtNo=Steve.getRoutingNumber();
System.out.println(steveRtNo);

//protected access to the method setBalance/getBalance
Steve.setBalance(5000);
System.out.println(Steve.getBalance());
}

}
</pre>

Class BankAccount in the above Java code has public getter/setter methods to access the private data member ‘routingNumber’. Thus, we can invoke these methods using an instance of the BankAccount object: Steve.
The methods setBalance()/ getBalance() are protected. As can be seen, they behave like public methods if invoked in the same package. Protected methods act like private methods if invoked by any instance of a class outside the package.
However, if there is a class ‘InternationalBankAccount’ in a different package such that:
<pre>
public class InternationalBankAccount extends BankAccount {
public String internationalBankAccNo;
}
</pre>

<pre>
InternationalBankAccount Anna = new InternationalBankAccount();
Anna.setBalance(10000);
</pre>

The above is a valid syntax and Anna can access protected member functions of the parent class.
Data member ‘accountNumber’ has default access specifier. Default access specifier is used in Java to support package driven development. Thus ‘accountNumber’ can be accessed from anywhere within the package. However no classes from other packages can access ‘accountNumber’.
Data member balance is a private data member and if it is invoked explicitly as follows,
<pre>
Steve.balance=1000;
</pre>
then the output would be an unresolved compilation error of the form:
<pre>
Unresolved compilation problem: The field bankAccount.balance is not visible
</pre>

===Ruby===
The following code illustrates the use of access specifiers in Ruby.
<pre>
class BankAccount

def initialize(acNo, rtNo, bal)
@accountNumber = acNo
@routingNumber = rtNo
@balance = bal
end

def balance
@balance
end

def routingNumber
@routingNumber
end

def accountNumber
@accountNumber
end

def compare_balance(other)
if other.balance > balance
"The other object has more bank balance."
else
"This object has more bank balance."
end
end

protected:balance
public:routingNumber
private:accountNumber

end
</pre>

<pre>
Steve = BankAccount.new(713, 123, 1000)
Anna = BankAccount.new(923, 125, 2000)
puts Steve.routingNumber()
puts Steve.compare_balance (Anna)
puts Steve.accountNumber()
</pre>

<pre>
Output:
123
The other object has more bank balance.
NoMethodError: private method `accountNumber' called for #<BankAccount:0x2b75320>
</pre>

‘routingNumber’ is a public function. Thus, when we access object Steve’s public method ‘routing number’, we successfully get ‘123’ as the output.
Furthermore, this snippet provides a mechanism for the comparison of one account holder’s balance with another. This comparison involves a call to the method ‘balance’. The object performing the comparison has to ask the other object to execute its balance method. So, balance cannot be private. With ‘balance’ changed to protected instead of private, Steve can ask Anna to execute ‘balance’, because both are instances of the same class. But if we try to call the ‘balance’ method of a bankAccount object when ‘self’ is anything other than a bankAccount object, the method will fail. A protected method is thus just like a private method, but with the exemption for those cases where the class of ‘self’ and the class of the respective object (having the method called on it) are the same.
‘accountNumber’ method is private. Thus user gets a ‘NoMethodError’ on invoking object Steve’s ‘accountNumber’ method. Initialize method in a class is private by default. Whenever the new method is invoked, initialize method is called and instances are created. If we try to invoke the ‘initialize’ method explicitly, we get the same error as in the case when we tried to invoke object Steve’s private ‘accountNumber’ method.

===C#===
<pre>
class BankAccount
{
public BankAccount(string accountNumber, string routingNumber, int balance)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
this.balance = balance;
}

protected string accountNumber;
protected string routingNumber;
private int balance;

private void setAccountNumber(string acNo)
{
this.accountNumber=acNo;
}

private void setRoutingNumber(string rtNo)
{
this.routingNumber=rtNo;
}

protected initBalance()
{
this.balance = 0;
}

public void getBalance(int balance)
{
return this.balance;
}
}

class Customer : BankAccount
{
Customer(string accountNumber, string routingNumber)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
initBalance();
}
}

class Startup
{
public static void main()
{
Customer cust = new Customer(“999”, “888”, 100);
System.console.WriteLine(cust.getBalance);
}
}

</pre>

The Customer class inherits from the BankAccount class. All protected data members and methods of BankAccount class are accessible directly by an object of the Customer class. The private fields such as accountNumber and routingNumber are not directly accessible. Thus it is possible to call only the initBalance and getBalance methods from Customer. The initBalance method cannot be called by anyone outside the BankAccount class.

==Conclusion==
Access control is an integral component of object oriented languages and it underlines and emphasizes some the pricipal ideals central to the object-oriented approach. It is possible to maximize the benefits of any O-O language by adhering to, and fully exploiting the capabilities of its access specifiers. Access control is in no way a peripheral add-on or redundant feature of O-O languages, and programmers would only stand to gain by fully appreciating, respecting and understanding their presence.

==References==
<references/>

CSC/ECE 517 Fall 2011/ch1 2b ns

2011-09-30T16:08:33Z

Sshyamr: /* Ruby */

<h2>Access Control in Object-Oriented Languages</h2>

== Introduction ==
A fundamental precept of O-O systems is that an object should not expose any of its implementation details. In other words, access to an object’s functionality must be tightly regulated. The access control policies of any object-oriented language specify the rules and capabilities for enforcing this regulation. Thus, the concept of Access control ties in deeply with the underlying principles of [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming].

__TOC__
==Purpose of Access Control==
Object-oriented programming fundamentally revolves around the principle of Data Hiding and Encapsulation. In a nutshell, [http://en.wikipedia.org/wiki/Information_hiding Data Hiding] is the practice of securing data by constraining access to it, and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] ensures that the secure data (and the respective member functions) are bundled together as an individual module. All object oriented languages thus need to control the level of access to their critical data (and functions) which is achieved using ''Access Modifiers'' or ''Access Specifiers'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

The need to strictly control ''who'' can access ''what'' is very crucial in Software development. For example, if you make an instance variable 'public', then you can't change the field as the class evolves over time since you might break any external code that uses the field. This is because outside code having complete access to this field, has tied itself indelibly to the inside implementation of the (former) class and is now closely dependent on it. Changing the said field thus entails changing all the other code that have a dependency on it, which is cumbersome, unwieldy and contrary to the principles of an Object Oriented approach which strives for [http://en.wikipedia.org/wiki/Coupling_(computer_programming) Low Coupling].

Thus, the ‘Implementation hiding principle’ leads to a good acid test of an O-O system's quality: Can you make massive changes to a class definition—even throw out the whole thing and replace it with a completely different implementation—without impacting any of the code that uses that class's objects? This sort of modularization is the central premise of object orientation and makes maintenance much easier. Without implementation hiding, there's little point in using other O-O features. Regulation of access - Access Control - is at the heart of Object oriented programming<ref>http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html</ref>.

==Evolution of Access Control and proliferation of Accessor methods==
Access control has been a part of the OOP movement ever since its inception. [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] is arguably one of first and purest of the many OO languages and was developed by Xerox PARC in the Learning Research Group in the 1970s <ref>http://www.zdnet.com/blog/murphy/the-tattered-history-of-oop/1157</ref>. Rather than having explicit access specifiers, smalltalk objects operated more in the sense of 'states' i.e. it would hold the 'state' of object(s) which is always private to that object. Any changes required to be made to this state had to be sent as request message to that object. This is the most primitive form of access control - having private data members and public member functions - the only difference being that the access levels are not explicitly specified.

Access control has evolved over time to become highly complicated <ref>http://www.exforsys.com/tutorials/oops/the-use-of-access-specifiers-in-object-oriented-programming.html</ref> because, the requirements of computing and software development have ballooned considerably in last decade and a half. Complex software requirements mandates complexity in languages, and this has indeed affected the access control policies, which have evolved into something comprehensive, yet - at times - convoluted. Unfortunately today's developers often lose sight of the fundamental motivation behind the existence of extensive access control and lose out on much of the benefits of having a highly cohesive, low coupled system<ref>http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref>.

To elaborate, it has become somewhat of an involuntary practice for present programmers to make ''all'' data members of a class private and provide accessor methods (getters/setters) to all of them (data members). Developers have come to accept this to be a contemporary programmatic-paradigm and by supplying setters and getters for ''everything'', defeat the very purpose of making class-fields private. A long time ago programmers discovered that reducing the scope (visibility) of data as much as possible leads to more reliable and maintainable code<ref>http://typicalprogrammer.com/?p=23</ref>.

Every getter and setter in one’s code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters is a sign of a poorly-designed set of classes. Java<ref>http://www.eclipse-blog.org/eclipse-ide/auto-generating-getters-and-setters.html</ref> and C#<ref>http://forums.asp.net/t/941864.aspx/1</ref> developers have IDEs that generate getters and setters automatically, implying that accessors are a good idea and thus contribute to that popular belief. That is not to say that one must completely abstain from accessors, but rather re-analyze and - if required - redesign the class structure to involve as little exposure of its data members as can be achieved.

==Access Control: A typical example==
Empirically, the data members of a class are held private, and the member functions (public) act as the end points of this class. Via these public methods, one can access the ‘state’ of an object. The following example illustrates this point and shows how access to the data members of a class are specified and controlled by the access modifiers.

[http://en.wikipedia.org/wiki/UML_Diagram#Diagrams_overview UML Diagram] of a BankAccount Class.

[[Image:BankAccount_UML.png|650px|thumb|center|Typical UML diagram of BankAccount.]]

The “(-)/(+)” preceding the members of this class represent the associated access levels. (-) indicates private and (+) indicates public.
The data members ‘accountNumber’, ‘routingNumber’ and ‘balance’ are maintained as private. Thus, an instance of a ‘Customer’ Object (say) cannot directly access or modify this data. Customer has to interact with the public behavior bundled in this module which allows him to view his account information and/or withdraw/deposit money i.e. his visibility of the class is only restricted to that which is made public by the Class.

Using such access specifiers, we can control the level of security and visibility associated with the members of a class. Thus, an Access Specifier can be roughly defined as ''‘A keyword applied to a variable, method, etc. that indicates which other parts of the code are permitted to access it’'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

==Common Access Specifiers in O-O languages==

Although all access specifiers essentially provide the same functionality, their semantics differ among different O-O languages. Here is how access control is implemented in some of the more common O-O languages.

===C++===
*'''private''':All members of the Class that are declared as private can only be accessed by the class's member functions and [http://en.wikipedia.org/wiki/Friend_class friends] of the class.
*'''protected''':All members of the Class that are declared as protected can be accessed by that class's member functions and friends (classes or functions) of the class. Moreover, classes derived from the class also have access to these elements.
*'''public''':Any class or method can have access to these type of elements.

===Java===
Java offers four access specifiers, listed below in order of decreasing accessibility:
*'''public''': All public classes, methods, and fields are the least secure. The Public access specifier must be used if you explicitly want to offer access to these entities and if this access cannot do any conceivable harm.
*'''protected''': Protected methods and fields can only be accessed within the same class to which the methods and fields belong, within its subclasses, and within classes present in the same [http://download.oracle.com/javase/tutorial/java/concepts/package.html Package]. Use of protected access specifier thus only allows its fields to be accessed by those classes which have some semblance of correlation to it - be it in the form of subclasses (correlation through inheritance) or classes within the same package (logical and/or functional correlation i.e. classes in the same package have ''something'' logical/functional common to them <ref>http://download.oracle.com/javase/tutorial/java/concepts/package.html</ref>).
*'''default '''(no specifier): Default access specifier is Java’s fail-safe way to handle security. Via the default access specifier, a class, method, or field will be accessible from inside the same package to which the class, method, or field belongs, but not from outside this package. Default access is thus suited when the source code is compartmentalized and organized into packages.
*'''private''': Private access specifier is a way to secure vital members of a class. Private methods and fields can only be accessed within the same class to which the methods and fields belong. Private methods and fields are not visible within subclasses and are not inherited by subclasses.

===Ruby===
Ruby gives you three levels of protection, listed below in order of decreasing accessibility:
*'''public''':Public methods can be called by everyone - no access control is enforced. A class's instance methods are public by default.
*'''protected''':Protected methods can be invoked only by objects of the defining class and its subclasses. Access is kept within the family.
*'''private''':Private methods cannot be called with an explicit receiver - the receiver is always self. Thus private methods can be called only in the context of the current object and cannot be invoked by another object's private methods.

Access control in Ruby is determined [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically], as the program runs, not statically. You will get an access violation only when the code attempts to execute the restricted method<ref>http://rubylearning.com/satishtalim/ruby_access_control.html</ref>.

===C#===
The following access modifiers specify the accessibility levels in C#
*'''public''':Any public method or member can be accessed by any other code in the same or different package.
*'''private''':The method or member can only be accessed from within the same class.
*'''protected''':The method or member can be accessed only from within the same Class or from within any of the subclasses.
*'''internal''':The type or member can be accessed by any code in the same assembly, but not from another assembly. An assembly in C# is the rough equivalent of a package in java.
*'''protected internal''':The type or member can be accessed by any code in the [http://msdn.microsoft.com/en-us/library/ms173099.aspx Assembly] (also see [http://msdn.microsoft.com/en-us/library/ms173099(v=vs.80).aspx this]) in which it is declared, or from within a derived class in another assembly. Access from another assembly must take place within a class declaration that derives from the class in which the protected internal element is declared, and it must take place through an instance of the derived class type.

===Summary of Access Specfiers in C++, Java, Ruby and C#:===
{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Access Level
! C++
! Java
! Ruby
! C#
|-
! Public
| Anything can access
| Anything can access
| Anything can access
| Anything can access
|-
! Protected
| Class, Subclasses and friends
| Class, Subclasses and classes of same package
| Class and Subclasses
| Class and Subclasses
|-
! Private
| Within Class
| Within Class
| Within Class
| Within Class
|-
! Internal
| --
| --
| --
| Any Class from same Assembly
|-
! Protected internal
| --
| --
| --
| Any Class from same Assembly and Subclass from any Assembly.
|}

==Examples of Access Specifiers==
The following examples exhibit the use of the access specifiers and getter methofs for the aforementioned Bank Account example.

===C++===
<pre>
class BankAccount {
private:
char routingNumber;
char accountNumber;
int balance;

public:
BankAccount(char *, char *);
void changeAccountNumber(char *);
void changeRoutingtNumber(char *);
void depositMoney(int);
void withdrawMoney(int);
void displayAccountInfo();
}

BankAccount::BankAccount(char *rNo, char *accNo) {
Strcpy(routingNumber, rNo);
Strcpy(accountNumber, accNo);
balance = 0;
}

BankAccount::void changeAccountNumber(char *acNo){
Strcpy(accountNumber, accNo);
}

BankAccount::void changeRoutingtNumber(char *rNo){
Strcpy(routingNumber, arNo);
}

BankAccount::void depositMoney(int amount) {
balance += amount;
}

BankAccount::void withdrawMoney(int amount) {
balance -= amount;
}

BankAccount::displayAccountInfo() {
cout << “Account Number:” << accountNumber << endl;
cout << “Routing Number:” << routingNumber << endl;
cout << “Account Balance:” << balance << endl;
}
</pre>

All the datamambers routingNumber, accountNumber and balance are made private. This makes it impossible to directly access or change these data members from outside code. Access to these attributes are strictly through the public methods changeRoutingNumber() and changeAccountNumber(). Thus, it purely at the discretion of the programmer to allow access to these data members through such accessor functions. In the absence of such accessors, there would be no way for any code outside the class to view/modify the private attributes.

===Java===

<pre>
public class BankAccount {
String accountNumber;
private String routingNumber;
private Integer balance;

public void setAccountNumber(String acNo){
this.accountNumber=acNo;
}

public void setRoutingNumber(String rtNo){
this.routingNumber=rtNo;
}

protected void setBalance(Integer bal){
this.balance=bal;
}

public String getAccountNumber(){
return this.accountNumber;
}

public String getRoutingNumber(){
return this.routingNumber;
}

protected Integer getBalance(){
return this.balance;
}

public void showAccountNumber(){
System.out.println(this.accountNumber);
}

public void showRoutingNumber(){
System.out.println(this.routingNumber);
}

public void showBalance(){
System.out.println(this.balance);
}

public void withdraw(Integer amount){
this.balance-=amount;
}

public void deposit(Integer amount){
this.balance+=amount;
}

public static void main(String args[]){
BankAccount Steve = new BankAccount();

//public access to setRoutingNumber/getRoutingNumber
Steve.setRoutingNumber("1234");
String steveRtNo=Steve.getRoutingNumber();
System.out.println(steveRtNo);

//protected access to the method setBalance/getBalance
Steve.setBalance(5000);
System.out.println(Steve.getBalance());
}

}
</pre>

Class BankAccount in the above Java code has public getter/setter methods to access the private data member ‘routingNumber’. Thus, we can invoke these methods using an instance of the BankAccount object: Steve.
The methods setBalance()/ getBalance() are protected. As can be seen, they behave like public methods if invoked in the same package. Protected methods act like private methods if invoked by any instance of a class outside the package.
However, if there is a class ‘InternationalBankAccount’ in a different package such that:
<pre>
public class InternationalBankAccount extends BankAccount {
public String internationalBankAccNo;
}
</pre>

<pre>
InternationalBankAccount Anna = new InternationalBankAccount();
Anna.setBalance(10000);
</pre>

The above is a valid syntax and Anna can access protected member functions of the parent class.
Data member ‘accountNumber’ has default access specifier. Default access specifier is used in Java to support package driven development. Thus ‘accountNumber’ can be accessed from anywhere within the package. However no classes from other packages can access ‘accountNumber’.
Data member balance is a private data member and if it is invoked explicitly as follows,
<pre>
Steve.balance=1000;
</pre>
then the output would be an unresolved compilation error of the form:
<pre>
Unresolved compilation problem: The field bankAccount.balance is not visible
</pre>

===Ruby===
The following code illustrates the use of access specifiers in Ruby.
<pre>
class BankAccount

def initialize(acNo, rtNo, bal)
@accountNumber = acNo
@routingNumber = rtNo
@balance = bal
end

def balance
@balance
end

def routingNumber
@routingNumber
end

def accountNumber
@accountNumber
end

def compare_balance(other)
if other.balance > balance
"The other object has more bank balance."
else
"This object has more bank balance."
end
end

protected:balance
public:routingNumber
private:accountNumber

end
</pre>

<pre>
Steve = BankAccount.new(713, 123, 1000)
Anna = BankAccount.new(923, 125, 2000)
puts Steve.routingNumber()
puts Steve.compare_balance (Anna)
puts Steve.accountNumber()
</pre>

<pre>
Output:
123
The other object has more bank balance.
NoMethodError: private method `accountNumber' called for #<BankAccount:0x2b75320>
</pre>

‘routingNumber’ is a public function. Thus, when we access object Steve’s public method ‘routing number’, we successfully get ‘123’ as the output.
Furthermore, this snippet provides a mechanism for the comparison of one account holder’s balance with another. This comparison involves a call to the method ‘balance’. The object performing the comparison has to ask the other object to execute its balance method. So, balance cannot be private. With ‘balance’ changed to protected instead of private, Steve can ask Anna to execute ‘balance’, because both are instances of the same class. But if we try to call the ‘balance’ method of a bankAccount object when ‘self’ is anything other than a bankAccount object, the method will fail. A protected method is thus just like a private method, but with the exemption for those cases where the class of ‘self’ and the class of the respective object (having the method called on it) are the same.
‘accountNumber’ method is private. Thus user gets a ‘NoMethodError’ on invoking object Steve’s ‘accountNumber’ method. Initialize method in a class is private by default. Whenever the new method is invoked, initialize method is called and instances are created. If we try to invoke the ‘initialize’ method explicitly, we get the same error as in the case when we tried to invoke object Steve’s private ‘accountNumber’ method.

===C#===
<pre>
class BankAccount
{
public BankAccount(string accountNumber, string routingNumber, int balance)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
this.balance = balance;
}

protected string accountNumber;
protected string routingNumber;
private int balance;

private void setAccountNumber(string acNo)
{
this.accountNumber=acNo;
}

private void setRoutingNumber(string rtNo)
{
this.routingNumber=rtNo;
}

protected initBalance()
{
this.balance = 0;
}

public void getBalance(int balance)
{
return this.balance;
}
}

class Customer : BankAccount
{
Customer(string accountNumber, string routingNumber)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
initBalance();
}
}

class Startup
{
public static void main()
{
Customer cust = new Customer(“999”, “888”, 100);
System.console.WriteLine(cust.getBalance);
}
}

</pre>

The Customer class inherits from the BankAccount class. All protected data members and methods of BankAccount class are accessible directly by an object of the Customer class. The private fields such as accountNumber and routingNumber are not directly accessible. Thus it is possible to call only the initBalance and getBalance methods from Customer. The initBalance method cannot be called by anyone outside the BankAccount class.

==Conclusion==
Access control is an integral component of object oriented languages and it underlines and emphasizes some the pricipal ideals central to the object-oriented approach. It is possible to maximize the benefits of any O-O language by adhering to, and fully exploiting the capabilities of its access specifiers. Access control is in no way a peripheral add-on or redundant feature of O-O languages, and programmers would only stand to gain by fully appreciating, respecting and understanding their presence.

==References==
<references/>

CSC/ECE 517 Fall 2011/ch1 2b ns

2011-09-30T16:06:17Z

Sshyamr: /* Java */

<h2>Access Control in Object-Oriented Languages</h2>

== Introduction ==
A fundamental precept of O-O systems is that an object should not expose any of its implementation details. In other words, access to an object’s functionality must be tightly regulated. The access control policies of any object-oriented language specify the rules and capabilities for enforcing this regulation. Thus, the concept of Access control ties in deeply with the underlying principles of [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming].

__TOC__
==Purpose of Access Control==
Object-oriented programming fundamentally revolves around the principle of Data Hiding and Encapsulation. In a nutshell, [http://en.wikipedia.org/wiki/Information_hiding Data Hiding] is the practice of securing data by constraining access to it, and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] ensures that the secure data (and the respective member functions) are bundled together as an individual module. All object oriented languages thus need to control the level of access to their critical data (and functions) which is achieved using ''Access Modifiers'' or ''Access Specifiers'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

The need to strictly control ''who'' can access ''what'' is very crucial in Software development. For example, if you make an instance variable 'public', then you can't change the field as the class evolves over time since you might break any external code that uses the field. This is because outside code having complete access to this field, has tied itself indelibly to the inside implementation of the (former) class and is now closely dependent on it. Changing the said field thus entails changing all the other code that have a dependency on it, which is cumbersome, unwieldy and contrary to the principles of an Object Oriented approach which strives for [http://en.wikipedia.org/wiki/Coupling_(computer_programming) Low Coupling].

Thus, the ‘Implementation hiding principle’ leads to a good acid test of an O-O system's quality: Can you make massive changes to a class definition—even throw out the whole thing and replace it with a completely different implementation—without impacting any of the code that uses that class's objects? This sort of modularization is the central premise of object orientation and makes maintenance much easier. Without implementation hiding, there's little point in using other O-O features. Regulation of access - Access Control - is at the heart of Object oriented programming<ref>http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html</ref>.

==Evolution of Access Control and proliferation of Accessor methods==
Access control has been a part of the OOP movement ever since its inception. [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] is arguably one of first and purest of the many OO languages and was developed by Xerox PARC in the Learning Research Group in the 1970s <ref>http://www.zdnet.com/blog/murphy/the-tattered-history-of-oop/1157</ref>. Rather than having explicit access specifiers, smalltalk objects operated more in the sense of 'states' i.e. it would hold the 'state' of object(s) which is always private to that object. Any changes required to be made to this state had to be sent as request message to that object. This is the most primitive form of access control - having private data members and public member functions - the only difference being that the access levels are not explicitly specified.

Access control has evolved over time to become highly complicated <ref>http://www.exforsys.com/tutorials/oops/the-use-of-access-specifiers-in-object-oriented-programming.html</ref> because, the requirements of computing and software development have ballooned considerably in last decade and a half. Complex software requirements mandates complexity in languages, and this has indeed affected the access control policies, which have evolved into something comprehensive, yet - at times - convoluted. Unfortunately today's developers often lose sight of the fundamental motivation behind the existence of extensive access control and lose out on much of the benefits of having a highly cohesive, low coupled system<ref>http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref>.

To elaborate, it has become somewhat of an involuntary practice for present programmers to make ''all'' data members of a class private and provide accessor methods (getters/setters) to all of them (data members). Developers have come to accept this to be a contemporary programmatic-paradigm and by supplying setters and getters for ''everything'', defeat the very purpose of making class-fields private. A long time ago programmers discovered that reducing the scope (visibility) of data as much as possible leads to more reliable and maintainable code<ref>http://typicalprogrammer.com/?p=23</ref>.

Every getter and setter in one’s code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters is a sign of a poorly-designed set of classes. Java<ref>http://www.eclipse-blog.org/eclipse-ide/auto-generating-getters-and-setters.html</ref> and C#<ref>http://forums.asp.net/t/941864.aspx/1</ref> developers have IDEs that generate getters and setters automatically, implying that accessors are a good idea and thus contribute to that popular belief. That is not to say that one must completely abstain from accessors, but rather re-analyze and - if required - redesign the class structure to involve as little exposure of its data members as can be achieved.

==Access Control: A typical example==
Empirically, the data members of a class are held private, and the member functions (public) act as the end points of this class. Via these public methods, one can access the ‘state’ of an object. The following example illustrates this point and shows how access to the data members of a class are specified and controlled by the access modifiers.

[http://en.wikipedia.org/wiki/UML_Diagram#Diagrams_overview UML Diagram] of a BankAccount Class.

[[Image:BankAccount_UML.png|650px|thumb|center|Typical UML diagram of BankAccount.]]

The “(-)/(+)” preceding the members of this class represent the associated access levels. (-) indicates private and (+) indicates public.
The data members ‘accountNumber’, ‘routingNumber’ and ‘balance’ are maintained as private. Thus, an instance of a ‘Customer’ Object (say) cannot directly access or modify this data. Customer has to interact with the public behavior bundled in this module which allows him to view his account information and/or withdraw/deposit money i.e. his visibility of the class is only restricted to that which is made public by the Class.

Using such access specifiers, we can control the level of security and visibility associated with the members of a class. Thus, an Access Specifier can be roughly defined as ''‘A keyword applied to a variable, method, etc. that indicates which other parts of the code are permitted to access it’'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

==Common Access Specifiers in O-O languages==

Although all access specifiers essentially provide the same functionality, their semantics differ among different O-O languages. Here is how access control is implemented in some of the more common O-O languages.

===C++===
*'''private''':All members of the Class that are declared as private can only be accessed by the class's member functions and [http://en.wikipedia.org/wiki/Friend_class friends] of the class.
*'''protected''':All members of the Class that are declared as protected can be accessed by that class's member functions and friends (classes or functions) of the class. Moreover, classes derived from the class also have access to these elements.
*'''public''':Any class or method can have access to these type of elements.

===Java===
Java offers four access specifiers, listed below in order of decreasing accessibility:
*'''public''': All public classes, methods, and fields are the least secure. The Public access specifier must be used if you explicitly want to offer access to these entities and if this access cannot do any conceivable harm.
*'''protected''': Protected methods and fields can only be accessed within the same class to which the methods and fields belong, within its subclasses, and within classes present in the same [http://download.oracle.com/javase/tutorial/java/concepts/package.html Package]. Use of protected access specifier thus only allows its fields to be accessed by those classes which have some semblance of correlation to it - be it in the form of subclasses (correlation through inheritance) or classes within the same package (logical and/or functional correlation i.e. classes in the same package have ''something'' logical/functional common to them <ref>http://download.oracle.com/javase/tutorial/java/concepts/package.html</ref>).
*'''default '''(no specifier): Default access specifier is Java’s fail-safe way to handle security. Via the default access specifier, a class, method, or field will be accessible from inside the same package to which the class, method, or field belongs, but not from outside this package. Default access is thus suited when the source code is compartmentalized and organized into packages.
*'''private''': Private access specifier is a way to secure vital members of a class. Private methods and fields can only be accessed within the same class to which the methods and fields belong. Private methods and fields are not visible within subclasses and are not inherited by subclasses.

===Ruby===
Ruby gives you three levels of protection, listed below in order of decreasing accessibility:
*'''public''':Public methods can be called by everyone - no access control is enforced. A class's instance methods are public by default.
*'''protected''':Protected methods can be invoked only by objects of the defining class and its subclasses. Access is kept within the family.
*'''private''':Private methods cannot be called with an explicit receiver - the receiver is always self. Thus private methods can be called only in the context of the current object and cannot be invoked by another object's private methods.

Access control in Ruby is determined dynamically, as the program runs, not statically. You will get an access violation only when the code attempts to execute the restricted method<ref>http://rubylearning.com/satishtalim/ruby_access_control.html</ref>.

===C#===
The following access modifiers specify the accessibility levels in C#
*'''public''':Any public method or member can be accessed by any other code in the same or different package.
*'''private''':The method or member can only be accessed from within the same class.
*'''protected''':The method or member can be accessed only from within the same Class or from within any of the subclasses.
*'''internal''':The type or member can be accessed by any code in the same assembly, but not from another assembly. An assembly in C# is the rough equivalent of a package in java.
*'''protected internal''':The type or member can be accessed by any code in the [http://msdn.microsoft.com/en-us/library/ms173099.aspx Assembly] (also see [http://msdn.microsoft.com/en-us/library/ms173099(v=vs.80).aspx this]) in which it is declared, or from within a derived class in another assembly. Access from another assembly must take place within a class declaration that derives from the class in which the protected internal element is declared, and it must take place through an instance of the derived class type.

===Summary of Access Specfiers in C++, Java, Ruby and C#:===
{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Access Level
! C++
! Java
! Ruby
! C#
|-
! Public
| Anything can access
| Anything can access
| Anything can access
| Anything can access
|-
! Protected
| Class, Subclasses and friends
| Class, Subclasses and classes of same package
| Class and Subclasses
| Class and Subclasses
|-
! Private
| Within Class
| Within Class
| Within Class
| Within Class
|-
! Internal
| --
| --
| --
| Any Class from same Assembly
|-
! Protected internal
| --
| --
| --
| Any Class from same Assembly and Subclass from any Assembly.
|}

==Examples of Access Specifiers==
The following examples exhibit the use of the access specifiers and getter methofs for the aforementioned Bank Account example.

===C++===
<pre>
class BankAccount {
private:
char routingNumber;
char accountNumber;
int balance;

public:
BankAccount(char *, char *);
void changeAccountNumber(char *);
void changeRoutingtNumber(char *);
void depositMoney(int);
void withdrawMoney(int);
void displayAccountInfo();
}

BankAccount::BankAccount(char *rNo, char *accNo) {
Strcpy(routingNumber, rNo);
Strcpy(accountNumber, accNo);
balance = 0;
}

BankAccount::void changeAccountNumber(char *acNo){
Strcpy(accountNumber, accNo);
}

BankAccount::void changeRoutingtNumber(char *rNo){
Strcpy(routingNumber, arNo);
}

BankAccount::void depositMoney(int amount) {
balance += amount;
}

BankAccount::void withdrawMoney(int amount) {
balance -= amount;
}

BankAccount::displayAccountInfo() {
cout << “Account Number:” << accountNumber << endl;
cout << “Routing Number:” << routingNumber << endl;
cout << “Account Balance:” << balance << endl;
}
</pre>

All the datamambers routingNumber, accountNumber and balance are made private. This makes it impossible to directly access or change these data members from outside code. Access to these attributes are strictly through the public methods changeRoutingNumber() and changeAccountNumber(). Thus, it purely at the discretion of the programmer to allow access to these data members through such accessor functions. In the absence of such accessors, there would be no way for any code outside the class to view/modify the private attributes.

===Java===

<pre>
public class BankAccount {
String accountNumber;
private String routingNumber;
private Integer balance;

public void setAccountNumber(String acNo){
this.accountNumber=acNo;
}

public void setRoutingNumber(String rtNo){
this.routingNumber=rtNo;
}

protected void setBalance(Integer bal){
this.balance=bal;
}

public String getAccountNumber(){
return this.accountNumber;
}

public String getRoutingNumber(){
return this.routingNumber;
}

protected Integer getBalance(){
return this.balance;
}

public void showAccountNumber(){
System.out.println(this.accountNumber);
}

public void showRoutingNumber(){
System.out.println(this.routingNumber);
}

public void showBalance(){
System.out.println(this.balance);
}

public void withdraw(Integer amount){
this.balance-=amount;
}

public void deposit(Integer amount){
this.balance+=amount;
}

public static void main(String args[]){
BankAccount Steve = new BankAccount();

//public access to setRoutingNumber/getRoutingNumber
Steve.setRoutingNumber("1234");
String steveRtNo=Steve.getRoutingNumber();
System.out.println(steveRtNo);

//protected access to the method setBalance/getBalance
Steve.setBalance(5000);
System.out.println(Steve.getBalance());
}

}
</pre>

Class BankAccount in the above Java code has public getter/setter methods to access the private data member ‘routingNumber’. Thus, we can invoke these methods using an instance of the BankAccount object: Steve.
The methods setBalance()/ getBalance() are protected. As can be seen, they behave like public methods if invoked in the same package. Protected methods act like private methods if invoked by any instance of a class outside the package.
However, if there is a class ‘InternationalBankAccount’ in a different package such that:
<pre>
public class InternationalBankAccount extends BankAccount {
public String internationalBankAccNo;
}
</pre>

<pre>
InternationalBankAccount Anna = new InternationalBankAccount();
Anna.setBalance(10000);
</pre>

The above is a valid syntax and Anna can access protected member functions of the parent class.
Data member ‘accountNumber’ has default access specifier. Default access specifier is used in Java to support package driven development. Thus ‘accountNumber’ can be accessed from anywhere within the package. However no classes from other packages can access ‘accountNumber’.
Data member balance is a private data member and if it is invoked explicitly as follows,
<pre>
Steve.balance=1000;
</pre>
then the output would be an unresolved compilation error of the form:
<pre>
Unresolved compilation problem: The field bankAccount.balance is not visible
</pre>

===Ruby===
The following code illustrates the use of access specifiers in Ruby.
<pre>
class BankAccount

def initialize(acNo, rtNo, bal)
@accountNumber = acNo
@routingNumber = rtNo
@balance = bal
end

def balance
@balance
end

def routingNumber
@routingNumber
end

def accountNumber
@accountNumber
end

def compare_balance(other)
if other.balance > balance
"The other object has more bank balance."
else
"This object has more bank balance."
end
end

protected:balance
public:routingNumber
private:accountNumber

end
</pre>

<pre>
Steve = BankAccount.new(713, 123, 1000)
Anna = BankAccount.new(923, 125, 2000)
puts Steve.routingNumber()
puts Steve.compare_balance (Anna)
puts Steve.accountNumber()
</pre>

<pre>
Output:
123
The other object has more bank balance.
NoMethodError: private method `accountNumber' called for #<BankAccount:0x2b75320>
</pre>

‘routingNumber’ is a public function. Thus, when we access object Steve’s public method ‘routing number’, we successfully get ‘123’ as the output.
Furthermore, this snippet provides a mechanism for the comparison of one account holder’s balance with another. This comparison involves a call to the method ‘balance’. The object performing the comparison has to ask the other object to execute its balance method. So, balance cannot be private. With ‘balance’ changed to protected instead of private, Steve can ask Anna to execute ‘balance’, because both are instances of the same class. But if we try to call the ‘balance’ method of a bankAccount object when ‘self’ is anything other than a bankAccount object, the method will fail. A protected method is thus just like a private method, but with the exemption for those cases where the class of ‘self’ and the class of the respective object (having the method called on it) are the same.
‘accountNumber’ method is private. Thus user gets a ‘NoMethodError’ on invoking object Steve’s ‘accountNumber’ method. Initialize method in a class is private by default. Whenever the new method is invoked, initialize method is called and instances are created. If we try to invoke the ‘initialize’ method explicitly, we get the same error as in the case when we tried to invoke object Steve’s private ‘accountNumber’ method.

===C#===
<pre>
class BankAccount
{
public BankAccount(string accountNumber, string routingNumber, int balance)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
this.balance = balance;
}

protected string accountNumber;
protected string routingNumber;
private int balance;

private void setAccountNumber(string acNo)
{
this.accountNumber=acNo;
}

private void setRoutingNumber(string rtNo)
{
this.routingNumber=rtNo;
}

protected initBalance()
{
this.balance = 0;
}

public void getBalance(int balance)
{
return this.balance;
}
}

class Customer : BankAccount
{
Customer(string accountNumber, string routingNumber)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
initBalance();
}
}

class Startup
{
public static void main()
{
Customer cust = new Customer(“999”, “888”, 100);
System.console.WriteLine(cust.getBalance);
}
}

</pre>

The Customer class inherits from the BankAccount class. All protected data members and methods of BankAccount class are accessible directly by an object of the Customer class. The private fields such as accountNumber and routingNumber are not directly accessible. Thus it is possible to call only the initBalance and getBalance methods from Customer. The initBalance method cannot be called by anyone outside the BankAccount class.

==Conclusion==
Access control is an integral component of object oriented languages and it underlines and emphasizes some the pricipal ideals central to the object-oriented approach. It is possible to maximize the benefits of any O-O language by adhering to, and fully exploiting the capabilities of its access specifiers. Access control is in no way a peripheral add-on or redundant feature of O-O languages, and programmers would only stand to gain by fully appreciating, respecting and understanding their presence.

==References==
<references/>

CSC/ECE 517 Fall 2011/ch1 2b ns

2011-09-30T16:02:24Z

Sshyamr: /* C# */

<h2>Access Control in Object-Oriented Languages</h2>

== Introduction ==
A fundamental precept of O-O systems is that an object should not expose any of its implementation details. In other words, access to an object’s functionality must be tightly regulated. The access control policies of any object-oriented language specify the rules and capabilities for enforcing this regulation. Thus, the concept of Access control ties in deeply with the underlying principles of [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming].

__TOC__
==Purpose of Access Control==
Object-oriented programming fundamentally revolves around the principle of Data Hiding and Encapsulation. In a nutshell, [http://en.wikipedia.org/wiki/Information_hiding Data Hiding] is the practice of securing data by constraining access to it, and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] ensures that the secure data (and the respective member functions) are bundled together as an individual module. All object oriented languages thus need to control the level of access to their critical data (and functions) which is achieved using ''Access Modifiers'' or ''Access Specifiers'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

The need to strictly control ''who'' can access ''what'' is very crucial in Software development. For example, if you make an instance variable 'public', then you can't change the field as the class evolves over time since you might break any external code that uses the field. This is because outside code having complete access to this field, has tied itself indelibly to the inside implementation of the (former) class and is now closely dependent on it. Changing the said field thus entails changing all the other code that have a dependency on it, which is cumbersome, unwieldy and contrary to the principles of an Object Oriented approach which strives for [http://en.wikipedia.org/wiki/Coupling_(computer_programming) Low Coupling].

Thus, the ‘Implementation hiding principle’ leads to a good acid test of an O-O system's quality: Can you make massive changes to a class definition—even throw out the whole thing and replace it with a completely different implementation—without impacting any of the code that uses that class's objects? This sort of modularization is the central premise of object orientation and makes maintenance much easier. Without implementation hiding, there's little point in using other O-O features. Regulation of access - Access Control - is at the heart of Object oriented programming<ref>http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html</ref>.

==Evolution of Access Control and proliferation of Accessor methods==
Access control has been a part of the OOP movement ever since its inception. [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] is arguably one of first and purest of the many OO languages and was developed by Xerox PARC in the Learning Research Group in the 1970s <ref>http://www.zdnet.com/blog/murphy/the-tattered-history-of-oop/1157</ref>. Rather than having explicit access specifiers, smalltalk objects operated more in the sense of 'states' i.e. it would hold the 'state' of object(s) which is always private to that object. Any changes required to be made to this state had to be sent as request message to that object. This is the most primitive form of access control - having private data members and public member functions - the only difference being that the access levels are not explicitly specified.

Access control has evolved over time to become highly complicated <ref>http://www.exforsys.com/tutorials/oops/the-use-of-access-specifiers-in-object-oriented-programming.html</ref> because, the requirements of computing and software development have ballooned considerably in last decade and a half. Complex software requirements mandates complexity in languages, and this has indeed affected the access control policies, which have evolved into something comprehensive, yet - at times - convoluted. Unfortunately today's developers often lose sight of the fundamental motivation behind the existence of extensive access control and lose out on much of the benefits of having a highly cohesive, low coupled system<ref>http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref>.

To elaborate, it has become somewhat of an involuntary practice for present programmers to make ''all'' data members of a class private and provide accessor methods (getters/setters) to all of them (data members). Developers have come to accept this to be a contemporary programmatic-paradigm and by supplying setters and getters for ''everything'', defeat the very purpose of making class-fields private. A long time ago programmers discovered that reducing the scope (visibility) of data as much as possible leads to more reliable and maintainable code<ref>http://typicalprogrammer.com/?p=23</ref>.

Every getter and setter in one’s code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters is a sign of a poorly-designed set of classes. Java<ref>http://www.eclipse-blog.org/eclipse-ide/auto-generating-getters-and-setters.html</ref> and C#<ref>http://forums.asp.net/t/941864.aspx/1</ref> developers have IDEs that generate getters and setters automatically, implying that accessors are a good idea and thus contribute to that popular belief. That is not to say that one must completely abstain from accessors, but rather re-analyze and - if required - redesign the class structure to involve as little exposure of its data members as can be achieved.

==Access Control: A typical example==
Empirically, the data members of a class are held private, and the member functions (public) act as the end points of this class. Via these public methods, one can access the ‘state’ of an object. The following example illustrates this point and shows how access to the data members of a class are specified and controlled by the access modifiers.

[http://en.wikipedia.org/wiki/UML_Diagram#Diagrams_overview UML Diagram] of a BankAccount Class.

[[Image:BankAccount_UML.png|650px|thumb|center|Typical UML diagram of BankAccount.]]

The “(-)/(+)” preceding the members of this class represent the associated access levels. (-) indicates private and (+) indicates public.
The data members ‘accountNumber’, ‘routingNumber’ and ‘balance’ are maintained as private. Thus, an instance of a ‘Customer’ Object (say) cannot directly access or modify this data. Customer has to interact with the public behavior bundled in this module which allows him to view his account information and/or withdraw/deposit money i.e. his visibility of the class is only restricted to that which is made public by the Class.

Using such access specifiers, we can control the level of security and visibility associated with the members of a class. Thus, an Access Specifier can be roughly defined as ''‘A keyword applied to a variable, method, etc. that indicates which other parts of the code are permitted to access it’'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

==Common Access Specifiers in O-O languages==

Although all access specifiers essentially provide the same functionality, their semantics differ among different O-O languages. Here is how access control is implemented in some of the more common O-O languages.

===C++===
*'''private''':All members of the Class that are declared as private can only be accessed by the class's member functions and [http://en.wikipedia.org/wiki/Friend_class friends] of the class.
*'''protected''':All members of the Class that are declared as protected can be accessed by that class's member functions and friends (classes or functions) of the class. Moreover, classes derived from the class also have access to these elements.
*'''public''':Any class or method can have access to these type of elements.

===Java===
Java offers four access specifiers, listed below in order of decreasing accessibility:
*'''public''': All public classes, methods, and fields are the least secure. The Public access specifier must be used if you explicitly want to offer access to these entities and if this access cannot do any conceivable harm.
*'''protected''': Protected methods and fields can only be accessed within the same class to which the methods and fields belong, within its subclasses, and within classes present in the same package. Use of protected access specifier thus only allows its fields to be accessed by those classes which have some semblance of correlation to it - be it in the form of subclasses (correlation through inheritance) or classes within the same package (logical and/or functional correlation i.e. classes in the same package have ''something'' logical/functional common to them).
*'''default '''(no specifier): Default access specifier is Java’s fail-safe way to handle security. Via the default access specifier, a class, method, or field will be accessible from inside the same package to which the class, method, or field belongs, but not from outside this package. Default access is thus suited when the source code is compartmentalized and organized into packages.
*'''private''': Private access specifier is a way to secure vital members of a class. Private methods and fields can only be accessed within the same class to which the methods and fields belong. Private methods and fields are not visible within subclasses and are not inherited by subclasses.

===Ruby===
Ruby gives you three levels of protection, listed below in order of decreasing accessibility:
*'''public''':Public methods can be called by everyone - no access control is enforced. A class's instance methods are public by default.
*'''protected''':Protected methods can be invoked only by objects of the defining class and its subclasses. Access is kept within the family.
*'''private''':Private methods cannot be called with an explicit receiver - the receiver is always self. Thus private methods can be called only in the context of the current object and cannot be invoked by another object's private methods.

Access control in Ruby is determined dynamically, as the program runs, not statically. You will get an access violation only when the code attempts to execute the restricted method<ref>http://rubylearning.com/satishtalim/ruby_access_control.html</ref>.

===C#===
The following access modifiers specify the accessibility levels in C#
*'''public''':Any public method or member can be accessed by any other code in the same or different package.
*'''private''':The method or member can only be accessed from within the same class.
*'''protected''':The method or member can be accessed only from within the same Class or from within any of the subclasses.
*'''internal''':The type or member can be accessed by any code in the same assembly, but not from another assembly. An assembly in C# is the rough equivalent of a package in java.
*'''protected internal''':The type or member can be accessed by any code in the [http://msdn.microsoft.com/en-us/library/ms173099.aspx Assembly] (also see [http://msdn.microsoft.com/en-us/library/ms173099(v=vs.80).aspx this]) in which it is declared, or from within a derived class in another assembly. Access from another assembly must take place within a class declaration that derives from the class in which the protected internal element is declared, and it must take place through an instance of the derived class type.

===Summary of Access Specfiers in C++, Java, Ruby and C#:===
{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Access Level
! C++
! Java
! Ruby
! C#
|-
! Public
| Anything can access
| Anything can access
| Anything can access
| Anything can access
|-
! Protected
| Class, Subclasses and friends
| Class, Subclasses and classes of same package
| Class and Subclasses
| Class and Subclasses
|-
! Private
| Within Class
| Within Class
| Within Class
| Within Class
|-
! Internal
| --
| --
| --
| Any Class from same Assembly
|-
! Protected internal
| --
| --
| --
| Any Class from same Assembly and Subclass from any Assembly.
|}

==Examples of Access Specifiers==
The following examples exhibit the use of the access specifiers and getter methofs for the aforementioned Bank Account example.

===C++===
<pre>
class BankAccount {
private:
char routingNumber;
char accountNumber;
int balance;

public:
BankAccount(char *, char *);
void changeAccountNumber(char *);
void changeRoutingtNumber(char *);
void depositMoney(int);
void withdrawMoney(int);
void displayAccountInfo();
}

BankAccount::BankAccount(char *rNo, char *accNo) {
Strcpy(routingNumber, rNo);
Strcpy(accountNumber, accNo);
balance = 0;
}

BankAccount::void changeAccountNumber(char *acNo){
Strcpy(accountNumber, accNo);
}

BankAccount::void changeRoutingtNumber(char *rNo){
Strcpy(routingNumber, arNo);
}

BankAccount::void depositMoney(int amount) {
balance += amount;
}

BankAccount::void withdrawMoney(int amount) {
balance -= amount;
}

BankAccount::displayAccountInfo() {
cout << “Account Number:” << accountNumber << endl;
cout << “Routing Number:” << routingNumber << endl;
cout << “Account Balance:” << balance << endl;
}
</pre>

All the datamambers routingNumber, accountNumber and balance are made private. This makes it impossible to directly access or change these data members from outside code. Access to these attributes are strictly through the public methods changeRoutingNumber() and changeAccountNumber(). Thus, it purely at the discretion of the programmer to allow access to these data members through such accessor functions. In the absence of such accessors, there would be no way for any code outside the class to view/modify the private attributes.

===Java===

<pre>
public class BankAccount {
String accountNumber;
private String routingNumber;
private Integer balance;

public void setAccountNumber(String acNo){
this.accountNumber=acNo;
}

public void setRoutingNumber(String rtNo){
this.routingNumber=rtNo;
}

protected void setBalance(Integer bal){
this.balance=bal;
}

public String getAccountNumber(){
return this.accountNumber;
}

public String getRoutingNumber(){
return this.routingNumber;
}

protected Integer getBalance(){
return this.balance;
}

public void showAccountNumber(){
System.out.println(this.accountNumber);
}

public void showRoutingNumber(){
System.out.println(this.routingNumber);
}

public void showBalance(){
System.out.println(this.balance);
}

public void withdraw(Integer amount){
this.balance-=amount;
}

public void deposit(Integer amount){
this.balance+=amount;
}

public static void main(String args[]){
BankAccount Steve = new BankAccount();

//public access to setRoutingNumber/getRoutingNumber
Steve.setRoutingNumber("1234");
String steveRtNo=Steve.getRoutingNumber();
System.out.println(steveRtNo);

//protected access to the method setBalance/getBalance
Steve.setBalance(5000);
System.out.println(Steve.getBalance());
}

}
</pre>

Class BankAccount in the above Java code has public getter/setter methods to access the private data member ‘routingNumber’. Thus, we can invoke these methods using an instance of the BankAccount object: Steve.
The methods setBalance()/ getBalance() are protected. As can be seen, they behave like public methods if invoked in the same package. Protected methods act like private methods if invoked by any instance of a class outside the package.
However, if there is a class ‘InternationalBankAccount’ in a different package such that:
<pre>
public class InternationalBankAccount extends BankAccount {
public String internationalBankAccNo;
}
</pre>

<pre>
InternationalBankAccount Anna = new InternationalBankAccount();
Anna.setBalance(10000);
</pre>

The above is a valid syntax and Anna can access protected member functions of the parent class.
Data member ‘accountNumber’ has default access specifier. Default access specifier is used in Java to support package driven development. Thus ‘accountNumber’ can be accessed from anywhere within the package. However no classes from other packages can access ‘accountNumber’.
Data member balance is a private data member and if it is invoked explicitly as follows,
<pre>
Steve.balance=1000;
</pre>
then the output would be an unresolved compilation error of the form:
<pre>
Unresolved compilation problem: The field bankAccount.balance is not visible
</pre>

===Ruby===
The following code illustrates the use of access specifiers in Ruby.
<pre>
class BankAccount

def initialize(acNo, rtNo, bal)
@accountNumber = acNo
@routingNumber = rtNo
@balance = bal
end

def balance
@balance
end

def routingNumber
@routingNumber
end

def accountNumber
@accountNumber
end

def compare_balance(other)
if other.balance > balance
"The other object has more bank balance."
else
"This object has more bank balance."
end
end

protected:balance
public:routingNumber
private:accountNumber

end
</pre>

<pre>
Steve = BankAccount.new(713, 123, 1000)
Anna = BankAccount.new(923, 125, 2000)
puts Steve.routingNumber()
puts Steve.compare_balance (Anna)
puts Steve.accountNumber()
</pre>

<pre>
Output:
123
The other object has more bank balance.
NoMethodError: private method `accountNumber' called for #<BankAccount:0x2b75320>
</pre>

‘routingNumber’ is a public function. Thus, when we access object Steve’s public method ‘routing number’, we successfully get ‘123’ as the output.
Furthermore, this snippet provides a mechanism for the comparison of one account holder’s balance with another. This comparison involves a call to the method ‘balance’. The object performing the comparison has to ask the other object to execute its balance method. So, balance cannot be private. With ‘balance’ changed to protected instead of private, Steve can ask Anna to execute ‘balance’, because both are instances of the same class. But if we try to call the ‘balance’ method of a bankAccount object when ‘self’ is anything other than a bankAccount object, the method will fail. A protected method is thus just like a private method, but with the exemption for those cases where the class of ‘self’ and the class of the respective object (having the method called on it) are the same.
‘accountNumber’ method is private. Thus user gets a ‘NoMethodError’ on invoking object Steve’s ‘accountNumber’ method. Initialize method in a class is private by default. Whenever the new method is invoked, initialize method is called and instances are created. If we try to invoke the ‘initialize’ method explicitly, we get the same error as in the case when we tried to invoke object Steve’s private ‘accountNumber’ method.

===C#===
<pre>
class BankAccount
{
public BankAccount(string accountNumber, string routingNumber, int balance)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
this.balance = balance;
}

protected string accountNumber;
protected string routingNumber;
private int balance;

private void setAccountNumber(string acNo)
{
this.accountNumber=acNo;
}

private void setRoutingNumber(string rtNo)
{
this.routingNumber=rtNo;
}

protected initBalance()
{
this.balance = 0;
}

public void getBalance(int balance)
{
return this.balance;
}
}

class Customer : BankAccount
{
Customer(string accountNumber, string routingNumber)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
initBalance();
}
}

class Startup
{
public static void main()
{
Customer cust = new Customer(“999”, “888”, 100);
System.console.WriteLine(cust.getBalance);
}
}

</pre>

The Customer class inherits from the BankAccount class. All protected data members and methods of BankAccount class are accessible directly by an object of the Customer class. The private fields such as accountNumber and routingNumber are not directly accessible. Thus it is possible to call only the initBalance and getBalance methods from Customer. The initBalance method cannot be called by anyone outside the BankAccount class.

==Conclusion==
Access control is an integral component of object oriented languages and it underlines and emphasizes some the pricipal ideals central to the object-oriented approach. It is possible to maximize the benefits of any O-O language by adhering to, and fully exploiting the capabilities of its access specifiers. Access control is in no way a peripheral add-on or redundant feature of O-O languages, and programmers would only stand to gain by fully appreciating, respecting and understanding their presence.

==References==
<references/>

CSC/ECE 517 Fall 2011/ch1 2b ns

2011-09-30T15:58:59Z

Sshyamr: /* Ruby */

<h2>Access Control in Object-Oriented Languages</h2>

== Introduction ==
A fundamental precept of O-O systems is that an object should not expose any of its implementation details. In other words, access to an object’s functionality must be tightly regulated. The access control policies of any object-oriented language specify the rules and capabilities for enforcing this regulation. Thus, the concept of Access control ties in deeply with the underlying principles of [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming].

__TOC__
==Purpose of Access Control==
Object-oriented programming fundamentally revolves around the principle of Data Hiding and Encapsulation. In a nutshell, [http://en.wikipedia.org/wiki/Information_hiding Data Hiding] is the practice of securing data by constraining access to it, and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] ensures that the secure data (and the respective member functions) are bundled together as an individual module. All object oriented languages thus need to control the level of access to their critical data (and functions) which is achieved using ''Access Modifiers'' or ''Access Specifiers'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

The need to strictly control ''who'' can access ''what'' is very crucial in Software development. For example, if you make an instance variable 'public', then you can't change the field as the class evolves over time since you might break any external code that uses the field. This is because outside code having complete access to this field, has tied itself indelibly to the inside implementation of the (former) class and is now closely dependent on it. Changing the said field thus entails changing all the other code that have a dependency on it, which is cumbersome, unwieldy and contrary to the principles of an Object Oriented approach which strives for [http://en.wikipedia.org/wiki/Coupling_(computer_programming) Low Coupling].

Thus, the ‘Implementation hiding principle’ leads to a good acid test of an O-O system's quality: Can you make massive changes to a class definition—even throw out the whole thing and replace it with a completely different implementation—without impacting any of the code that uses that class's objects? This sort of modularization is the central premise of object orientation and makes maintenance much easier. Without implementation hiding, there's little point in using other O-O features. Regulation of access - Access Control - is at the heart of Object oriented programming<ref>http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html</ref>.

==Evolution of Access Control and proliferation of Accessor methods==
Access control has been a part of the OOP movement ever since its inception. [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] is arguably one of first and purest of the many OO languages and was developed by Xerox PARC in the Learning Research Group in the 1970s <ref>http://www.zdnet.com/blog/murphy/the-tattered-history-of-oop/1157</ref>. Rather than having explicit access specifiers, smalltalk objects operated more in the sense of 'states' i.e. it would hold the 'state' of object(s) which is always private to that object. Any changes required to be made to this state had to be sent as request message to that object. This is the most primitive form of access control - having private data members and public member functions - the only difference being that the access levels are not explicitly specified.

Access control has evolved over time to become highly complicated <ref>http://www.exforsys.com/tutorials/oops/the-use-of-access-specifiers-in-object-oriented-programming.html</ref> because, the requirements of computing and software development have ballooned considerably in last decade and a half. Complex software requirements mandates complexity in languages, and this has indeed affected the access control policies, which have evolved into something comprehensive, yet - at times - convoluted. Unfortunately today's developers often lose sight of the fundamental motivation behind the existence of extensive access control and lose out on much of the benefits of having a highly cohesive, low coupled system<ref>http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref>.

To elaborate, it has become somewhat of an involuntary practice for present programmers to make ''all'' data members of a class private and provide accessor methods (getters/setters) to all of them (data members). Developers have come to accept this to be a contemporary programmatic-paradigm and by supplying setters and getters for ''everything'', defeat the very purpose of making class-fields private. A long time ago programmers discovered that reducing the scope (visibility) of data as much as possible leads to more reliable and maintainable code<ref>http://typicalprogrammer.com/?p=23</ref>.

Every getter and setter in one’s code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters is a sign of a poorly-designed set of classes. Java<ref>http://www.eclipse-blog.org/eclipse-ide/auto-generating-getters-and-setters.html</ref> and C#<ref>http://forums.asp.net/t/941864.aspx/1</ref> developers have IDEs that generate getters and setters automatically, implying that accessors are a good idea and thus contribute to that popular belief. That is not to say that one must completely abstain from accessors, but rather re-analyze and - if required - redesign the class structure to involve as little exposure of its data members as can be achieved.

==Access Control: A typical example==
Empirically, the data members of a class are held private, and the member functions (public) act as the end points of this class. Via these public methods, one can access the ‘state’ of an object. The following example illustrates this point and shows how access to the data members of a class are specified and controlled by the access modifiers.

[http://en.wikipedia.org/wiki/UML_Diagram#Diagrams_overview UML Diagram] of a BankAccount Class.

[[Image:BankAccount_UML.png|650px|thumb|center|Typical UML diagram of BankAccount.]]

The “(-)/(+)” preceding the members of this class represent the associated access levels. (-) indicates private and (+) indicates public.
The data members ‘accountNumber’, ‘routingNumber’ and ‘balance’ are maintained as private. Thus, an instance of a ‘Customer’ Object (say) cannot directly access or modify this data. Customer has to interact with the public behavior bundled in this module which allows him to view his account information and/or withdraw/deposit money i.e. his visibility of the class is only restricted to that which is made public by the Class.

Using such access specifiers, we can control the level of security and visibility associated with the members of a class. Thus, an Access Specifier can be roughly defined as ''‘A keyword applied to a variable, method, etc. that indicates which other parts of the code are permitted to access it’'' <ref>http://en.wiktionary.org/wiki/access_specifier</ref>.

==Common Access Specifiers in O-O languages==

Although all access specifiers essentially provide the same functionality, their semantics differ among different O-O languages. Here is how access control is implemented in some of the more common O-O languages.

===C++===
*'''private''':All members of the Class that are declared as private can only be accessed by the class's member functions and [http://en.wikipedia.org/wiki/Friend_class friends] of the class.
*'''protected''':All members of the Class that are declared as protected can be accessed by that class's member functions and friends (classes or functions) of the class. Moreover, classes derived from the class also have access to these elements.
*'''public''':Any class or method can have access to these type of elements.

===Java===
Java offers four access specifiers, listed below in order of decreasing accessibility:
*'''public''': All public classes, methods, and fields are the least secure. The Public access specifier must be used if you explicitly want to offer access to these entities and if this access cannot do any conceivable harm.
*'''protected''': Protected methods and fields can only be accessed within the same class to which the methods and fields belong, within its subclasses, and within classes present in the same package. Use of protected access specifier thus only allows its fields to be accessed by those classes which have some semblance of correlation to it - be it in the form of subclasses (correlation through inheritance) or classes within the same package (logical and/or functional correlation i.e. classes in the same package have ''something'' logical/functional common to them).
*'''default '''(no specifier): Default access specifier is Java’s fail-safe way to handle security. Via the default access specifier, a class, method, or field will be accessible from inside the same package to which the class, method, or field belongs, but not from outside this package. Default access is thus suited when the source code is compartmentalized and organized into packages.
*'''private''': Private access specifier is a way to secure vital members of a class. Private methods and fields can only be accessed within the same class to which the methods and fields belong. Private methods and fields are not visible within subclasses and are not inherited by subclasses.

===Ruby===
Ruby gives you three levels of protection, listed below in order of decreasing accessibility:
*'''public''':Public methods can be called by everyone - no access control is enforced. A class's instance methods are public by default.
*'''protected''':Protected methods can be invoked only by objects of the defining class and its subclasses. Access is kept within the family.
*'''private''':Private methods cannot be called with an explicit receiver - the receiver is always self. Thus private methods can be called only in the context of the current object and cannot be invoked by another object's private methods.

Access control in Ruby is determined dynamically, as the program runs, not statically. You will get an access violation only when the code attempts to execute the restricted method<ref>http://rubylearning.com/satishtalim/ruby_access_control.html</ref>.

===C#===
The following access modifiers specify the accessibility levels in C#
*'''public''':Any public method or member can be accessed by any other code in the same or different package.
*'''private''':The method or member can only be accessed from within the same class.
*'''protected''':The method or member can be accessed only from within the same Class or from within any of the subclasses.
*'''internal''':The type or member can be accessed by any code in the same assembly, but not from another assembly. An assembly in C# is the rough equivalent of a package in java.
*'''protected internal''':The type or member can be accessed by any code in the assembly in which it is declared, or from within a derived class in another assembly. Access from another assembly must take place within a class declaration that derives from the class in which the protected internal element is declared, and it must take place through an instance of the derived class type.

===Summary of Access Specfiers in C++, Java, Ruby and C#:===
{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Access Level
! C++
! Java
! Ruby
! C#
|-
! Public
| Anything can access
| Anything can access
| Anything can access
| Anything can access
|-
! Protected
| Class, Subclasses and friends
| Class, Subclasses and classes of same package
| Class and Subclasses
| Class and Subclasses
|-
! Private
| Within Class
| Within Class
| Within Class
| Within Class
|-
! Internal
| --
| --
| --
| Any Class from same Assembly
|-
! Protected internal
| --
| --
| --
| Any Class from same Assembly and Subclass from any Assembly.
|}

==Examples of Access Specifiers==
The following examples exhibit the use of the access specifiers and getter methofs for the aforementioned Bank Account example.

===C++===
<pre>
class BankAccount {
private:
char routingNumber;
char accountNumber;
int balance;

public:
BankAccount(char *, char *);
void changeAccountNumber(char *);
void changeRoutingtNumber(char *);
void depositMoney(int);
void withdrawMoney(int);
void displayAccountInfo();
}

BankAccount::BankAccount(char *rNo, char *accNo) {
Strcpy(routingNumber, rNo);
Strcpy(accountNumber, accNo);
balance = 0;
}

BankAccount::void changeAccountNumber(char *acNo){
Strcpy(accountNumber, accNo);
}

BankAccount::void changeRoutingtNumber(char *rNo){
Strcpy(routingNumber, arNo);
}

BankAccount::void depositMoney(int amount) {
balance += amount;
}

BankAccount::void withdrawMoney(int amount) {
balance -= amount;
}

BankAccount::displayAccountInfo() {
cout << “Account Number:” << accountNumber << endl;
cout << “Routing Number:” << routingNumber << endl;
cout << “Account Balance:” << balance << endl;
}
</pre>

All the datamambers routingNumber, accountNumber and balance are made private. This makes it impossible to directly access or change these data members from outside code. Access to these attributes are strictly through the public methods changeRoutingNumber() and changeAccountNumber(). Thus, it purely at the discretion of the programmer to allow access to these data members through such accessor functions. In the absence of such accessors, there would be no way for any code outside the class to view/modify the private attributes.

===Java===

<pre>
public class BankAccount {
String accountNumber;
private String routingNumber;
private Integer balance;

public void setAccountNumber(String acNo){
this.accountNumber=acNo;
}

public void setRoutingNumber(String rtNo){
this.routingNumber=rtNo;
}

protected void setBalance(Integer bal){
this.balance=bal;
}

public String getAccountNumber(){
return this.accountNumber;
}

public String getRoutingNumber(){
return this.routingNumber;
}

protected Integer getBalance(){
return this.balance;
}

public void showAccountNumber(){
System.out.println(this.accountNumber);
}

public void showRoutingNumber(){
System.out.println(this.routingNumber);
}

public void showBalance(){
System.out.println(this.balance);
}

public void withdraw(Integer amount){
this.balance-=amount;
}

public void deposit(Integer amount){
this.balance+=amount;
}

public static void main(String args[]){
BankAccount Steve = new BankAccount();

//public access to setRoutingNumber/getRoutingNumber
Steve.setRoutingNumber("1234");
String steveRtNo=Steve.getRoutingNumber();
System.out.println(steveRtNo);

//protected access to the method setBalance/getBalance
Steve.setBalance(5000);
System.out.println(Steve.getBalance());
}

}
</pre>

Class BankAccount in the above Java code has public getter/setter methods to access the private data member ‘routingNumber’. Thus, we can invoke these methods using an instance of the BankAccount object: Steve.
The methods setBalance()/ getBalance() are protected. As can be seen, they behave like public methods if invoked in the same package. Protected methods act like private methods if invoked by any instance of a class outside the package.
However, if there is a class ‘InternationalBankAccount’ in a different package such that:
<pre>
public class InternationalBankAccount extends BankAccount {
public String internationalBankAccNo;
}
</pre>

<pre>
InternationalBankAccount Anna = new InternationalBankAccount();
Anna.setBalance(10000);
</pre>

The above is a valid syntax and Anna can access protected member functions of the parent class.
Data member ‘accountNumber’ has default access specifier. Default access specifier is used in Java to support package driven development. Thus ‘accountNumber’ can be accessed from anywhere within the package. However no classes from other packages can access ‘accountNumber’.
Data member balance is a private data member and if it is invoked explicitly as follows,
<pre>
Steve.balance=1000;
</pre>
then the output would be an unresolved compilation error of the form:
<pre>
Unresolved compilation problem: The field bankAccount.balance is not visible
</pre>

===Ruby===
The following code illustrates the use of access specifiers in Ruby.
<pre>
class BankAccount

def initialize(acNo, rtNo, bal)
@accountNumber = acNo
@routingNumber = rtNo
@balance = bal
end

def balance
@balance
end

def routingNumber
@routingNumber
end

def accountNumber
@accountNumber
end

def compare_balance(other)
if other.balance > balance
"The other object has more bank balance."
else
"This object has more bank balance."
end
end

protected:balance
public:routingNumber
private:accountNumber

end
</pre>

<pre>
Steve = BankAccount.new(713, 123, 1000)
Anna = BankAccount.new(923, 125, 2000)
puts Steve.routingNumber()
puts Steve.compare_balance (Anna)
puts Steve.accountNumber()
</pre>

<pre>
Output:
123
The other object has more bank balance.
NoMethodError: private method `accountNumber' called for #<BankAccount:0x2b75320>
</pre>

‘routingNumber’ is a public function. Thus, when we access object Steve’s public method ‘routing number’, we successfully get ‘123’ as the output.
Furthermore, this snippet provides a mechanism for the comparison of one account holder’s balance with another. This comparison involves a call to the method ‘balance’. The object performing the comparison has to ask the other object to execute its balance method. So, balance cannot be private. With ‘balance’ changed to protected instead of private, Steve can ask Anna to execute ‘balance’, because both are instances of the same class. But if we try to call the ‘balance’ method of a bankAccount object when ‘self’ is anything other than a bankAccount object, the method will fail. A protected method is thus just like a private method, but with the exemption for those cases where the class of ‘self’ and the class of the respective object (having the method called on it) are the same.
‘accountNumber’ method is private. Thus user gets a ‘NoMethodError’ on invoking object Steve’s ‘accountNumber’ method. Initialize method in a class is private by default. Whenever the new method is invoked, initialize method is called and instances are created. If we try to invoke the ‘initialize’ method explicitly, we get the same error as in the case when we tried to invoke object Steve’s private ‘accountNumber’ method.

===C#===
<pre>
class BankAccount
{
public BankAccount(string accountNumber, string routingNumber, int balance)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
this.balance = balance;
}

protected string accountNumber;
protected string routingNumber;
private int balance;

private void setAccountNumber(string acNo)
{
this.accountNumber=acNo;
}

private void setRoutingNumber(string rtNo)
{
this.routingNumber=rtNo;
}

protected initBalance()
{
this.balance = 0;
}

public void getBalance(int balance)
{
return this.balance;
}
}

class Customer : BankAccount
{
Customer(string accountNumber, string routingNumber)
{
this.accountNumber = accountNumber;
this.routingNumber = routingNumber;
initBalance();
}
}

class Startup
{
public static void main()
{
Customer cust = new Customer(“999”, “888”, 100);
System.console.WriteLine(cust.getBalance);
}
}

</pre>

The Customer class inherits from the BankAccount class. All protected data members and methods of BankAccount class are accessible directly by an object of the Customer class. The private fields such as accountNumber and routingNumber are not directly accessible. Thus it is possible to call only the initBalance and getBalance methods from Customer. The initBalance method cannot be called by anyone outside the BankAccount class.

==Conclusion==
Access control is an integral component of object oriented languages and it underlines and emphasizes some the pricipal ideals central to the object-oriented approach. It is possible to maximize the benefits of any O-O language by adhering to, and fully exploiting the capabilities of its access specifiers. Access control is in no way a peripheral add-on or redundant feature of O-O languages, and programmers would only stand to gain by fully appreciating, respecting and understanding their presence.

==References==
<references/>