CSC/ECE 517 Fall 2011/ch1 1g rn: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
 
(5 intermediate revisions by the same user not shown)
Line 12: Line 12:




'''Note''': The intent of this article is not to provide an introduction to either scripting languages or object-oriented languages. We assume that the user has familiarity with basic [http://en.wikipedia.org/wiki/Object-oriented_programming  object-oriented] and [http://en.wikipedia.org/wiki/Scripting scripting concepts]. The case study presented requires intermediate knowledge of [http://www.perl.org/ Perl]. An excellent resource for learning Perl is [http://shop.oreilly.com/product/0636920018452.do Learning Perl].
'''Note''': The intent of this article is not to provide an introduction to either scripting languages or object-oriented languages. We assume that the user has familiarity with basic [http://en.wikipedia.org/wiki/Object-oriented_programming  object-oriented] and [http://en.wikipedia.org/wiki/Scripting scripting concepts]. The case study presented requires basic knowledge of [http://www.perl.org/ Perl]. An excellent resource for Perl is [http://shop.oreilly.com/product/0636920018452.do Learning Perl].


==Advantages that object orientation bring to a scripting language==
==Advantages that object orientation bring to a scripting language==
Line 19: Line 19:


===Separate code into abstract pieces===
===Separate code into abstract pieces===
Procedural programming is the natural choice when writing scripts. Functionality in such scripts is broken down as procedures and variables. One of the major disadvantages of this approach is that it can get out of control when the complexity reaches a certain level. Using an object-oriented approach to scripting allows the programmer to separate code into classes that can be related to real-world entities. Providing classes with attributes and methods makes the code more readable, easier to extend and convenient to maintain [http://www.ibm.com/developerworks/aix/library/au-scripting_to_oo/]. An abstract model makes implementation of complex system allows the program to follow a more natural flow.
[http://en.wikipedia.org/wiki/Procedural_programming Procedural programming] is the natural choice when writing scripts. Functionality in such scripts is broken down as procedures and variables. One of the major disadvantages of this approach is that it can get out of control when the complexity reaches a certain level. Using an object-oriented approach to scripting allows the programmer to separate code into classes that can be related to real-world entities. Providing classes with attributes and methods makes the code more readable, easier to extend and convenient to maintain [http://www.ibm.com/developerworks/aix/library/au-scripting_to_oo/]. An abstract model makes implementation of complex system allows the program to follow a more natural flow.


Line 42: Line 42:
package DiskMonitor;
package DiskMonitor;


# Constructor for DiskMonitor
# A DiskMonitor object is a hash, and holds a string with key 'usage' in it
sub new {
sub new {
my $class = shift;
my $class = shift;
Line 49: Line 51:
}
}


# $self references the object that invoked this method. This method
# sets the value for the 'usage' key inside the object
sub getdiskusage {
sub getdiskusage {
my $self = shift;
my $self = shift;
Line 66: Line 70:
use Sys::Statistics::Linux;
use Sys::Statistics::Linux;


# Class HostMonitor is a subclass of Sys::Statistics::Linux
package HostMonitor;
package HostMonitor;
our @ISA = "Sys::Statistics::Linux";
our @ISA = "Sys::Statistics::Linux";


# Constructor for HostMonitor
# A HostMonitor object is a hash, and holds a string with key 'hostname' in it
sub new {
sub new {
my $class = shift;
my $class = shift;
Line 77: Line 84:
}
}


# sets the value for the 'hostname' key inside the object
sub gethostname {
sub gethostname {
my $self = shift;
my $self = shift;
Line 97: Line 105:
package SystemMonitor;
package SystemMonitor;


# Constructor for SystemMonitor
# A SystemMonitor object is a hash, and holds reference to
# a HostMonitor object with key 'host'
# a DiskMonitor object with key 'disk'
sub new {
sub new {
my $class = shift;
my $class = shift;
Line 132: Line 144:


Things to take away from this case study:
Things to take away from this case study:
* The SystemMonitor object seamlessly glues together pre-existing components: HostMonitor and DiskMonitor, one of the fundamental reasons of using a scripting language. It provides a SystemMonitor with the appearance of an intact and complete entity, hiding away the internal details of the parts that make it.
* A SystemMonitor object contains a DiskMonitor and a HostMonitor object. It seamlessly glues together these two pre-existing components, one of the fundamental reasons of using a scripting language. It provides SystemMonitor with the appearance of an intact and complete entity, hiding away the internal details of the parts that make it.


* The SystemMonitor object encapsulates HostMonitor and DiskMonitor objects. This follows natural reasoning of having a consolidated monitor (like the dashboard of a car) with specific metric reporting components inside it (like the various dials on a dashboard).  
* The SystemMonitor object encapsulates HostMonitor and DiskMonitor objects. This follows natural reasoning of having a consolidated monitor (like the dashboard of a car) with specific metric reporting components inside it (like the various dials on a dashboard).  


* The HostMonitor extends [http://search.cpan.org/~bloonix/Sys-Statistics-Linux-0.60/lib/Sys/Statistics/Linux.pm Sys::Statistics::Linux], a pre-existing module obtained from CPAN . The Sys::Statistics::Linux provides with a lot metrics, however our system administrator needs the hostname also. Hence, HostMonitor uses all of the functionality Sys::Statistics::Linux provides, and add the missing method: gethostname(). Hence, we have reused a lot of existing code and customized the host monitoring component to our needs.
* The HostMonitor extends [http://search.cpan.org/~bloonix/Sys-Statistics-Linux-0.60/lib/Sys/Statistics/Linux.pm Sys::Statistics::Linux], a pre-existing module obtained from CPAN . The Sys::Statistics::Linux provides with a lot metrics, however our system administrator needs the hostname too. Hence, HostMonitor uses all of the functionality Sys::Statistics::Linux provides, and add the missing method: gethostname(). Hence, we have reused a lot of existing code and customized the host monitoring component to our needs.


* Extending functionality of the SystemMonitor to collect some other statistics is easy. Suppose now we want our SystemMonitor to report network usage statistics. Just create a new Perl module NetworkMonitor that can obtain the required statistics about network usage and add it as a member of the SystemMonitor package.
* Extending functionality of the SystemMonitor to collect some other statistics is easy. Suppose now we want our SystemMonitor to report network usage statistics. Just create a new Perl module NetworkMonitor that can obtain the required statistics about network usage and add it as a member of the SystemMonitor package.
Line 153: Line 165:


==Advantages of scripting languages that are not object oriented==
==Advantages of scripting languages that are not object oriented==
Scripting languages are basically known as “Glue” languages, since scripts glue together various preexisting components or programs which may or may not be in same language. Dynamically typed languages generally use run time objects with tags containing their type information [http://www.cio.com/article/446829/PHP_JavaScript_Ruby_Perl_Python_and_Tcl_Today_The_State_of_the_Scripting_Universe?page=4&taxonomyId=3038]. In dynamic typing, types are associated with values rather than variables. It allows the programmer not to explicit type annotations on expressions. In other words, it allows  a variable to refer to values of different types at different points in a single program. Hence it helps scripting language to glue different components together.
Scripting languages are basically known as “Glue” languages, since scripts glue together various preexisting components or programs which may or may not be in same language. [http://en.wikipedia.org/wiki/Dynamic_programming_language Dynamically typed languages] generally use run time objects with tags containing their type information [http://www.cio.com/article/446829/PHP_JavaScript_Ruby_Perl_Python_and_Tcl_Today_The_State_of_the_Scripting_Universe?page=4&taxonomyId=3038]. In dynamic typing, types are associated with values rather than variables. It allows the programmer not to explicit type annotations on expressions. In other words, it allows  a variable to refer to values of different types at different points in a single program. Hence it helps scripting language to glue different components together.


Most of the popular scripting languages today did not start out as object-oriented languages. Object-orientation was provided to them later on. The designers of the language envisioned use of scripting for writing easy to medium complexity code in a short time. However, these languages grew immensely popular that made object-orientation a necessity.  As such, a performance of a non-object oriented script will always be better that an object-oriented one. Object-orientation adds an extra layer of abstraction that hurts performance. Having said that, todays processors are so fast that this difference is hardly noticeable.
Most of the popular scripting languages today did not start out as object-oriented languages. Object-orientation was provided to them later on. The designers of the language envisioned use of scripting for writing easy to medium complexity code in a short time. However, these languages grew immensely popular that made object-orientation a necessity.  As such, a performance of a non-object oriented script will always be better that an object-oriented one. Object-orientation adds an extra layer of abstraction that hurts performance. Having said that, todays processors are so fast that this difference is hardly noticeable.

Latest revision as of 01:57, 26 September 2011

Object-Oriented Languages and Scripting

Introduction

Scripting Languages

Definition: A scripting language is a programming language that allows control of applications, giving it a sequence of work to do in a single batch[1] Scripting languages are usually used for gluing together pre-existing component and automation of manual work. They provide features like dynamic typing and extensibility that make them easy to learn. Scripting languages grew out of the need to shorten the traditional edit-compile-link-run process. As such, most of the scripting languages today are interpreted. However, this is not a defining feature; there are scripting languages that are compiled [2].

In this article we present an analysis of object-orientation in scripting. Specifically, we focus on what why object-orientation was introduced to the scripting arena, what advantages it brings to a scripting language and how scripting capabilities benefit object-orientation.

Object-oriented Languages

Definition: An object-oriented language is a programming language that uses the "object" paradigm, consisting of members, method and their interactions to design application and computer programs. The fundamental ideology behind object-orientation is to model real world entities, either physical or conceptual as objects, their properties as data member, behavior as methods and relationships as interactions. The basic concepts of object-oriented languages are data abstraction, encapsulation, inheritance, polymorphism and modularity.


Note: The intent of this article is not to provide an introduction to either scripting languages or object-oriented languages. We assume that the user has familiarity with basic object-oriented and scripting concepts. The case study presented requires basic knowledge of Perl. An excellent resource for Perl is Learning Perl.

Advantages that object orientation bring to a scripting language

Provides encapsulation paradigm in gluing components

An object-oriented approach allows multiple levels of encapsulation. The foremost use of scripts is to act as glue for pre-existing components [3]. Since in scripting languages, code reuse is already provided by pre-existing components, encapsulation is the biggest advantage object-orientation brings to the table. Encapsulation lets us think about an object in isolation; encapsulation fits the human reasoning. Encapsulating data and functionality of various modules, possibly in different languages into a neatly packaged brand new object is perhaps the single most important objective of glue!

Separate code into abstract pieces

Procedural programming is the natural choice when writing scripts. Functionality in such scripts is broken down as procedures and variables. One of the major disadvantages of this approach is that it can get out of control when the complexity reaches a certain level. Using an object-oriented approach to scripting allows the programmer to separate code into classes that can be related to real-world entities. Providing classes with attributes and methods makes the code more readable, easier to extend and convenient to maintain [4]. An abstract model makes implementation of complex system allows the program to follow a more natural flow.  

Reuse and customize things without changing source code

Most of the popular object-oriented scripting languages like Perl, Python provide the programmer with vast libraries. Scripts typically use one or more library modules and build upon that [5]. Object-orientation makes it easy to reuse and customize existing functionality without changes to the source code.

Complex interactions within the system can be streamlined by the use of design patterns

Design patterns are used to solve recurring problems within a given context. Patterns are created once and used many times. So, designing and creating patterns help in writing scripts as scripts are meant to use multiple times. Also many design patterns follow object oriented approach. Hence these patterns help in writing object oriented scripts.

Case study

Consider the following case which highlights the Advantages that object orientation bring to a scripting language:

One of the most common uses of scripting languages is for system administration. They are used extensively for automating system setup, configuration, and monitoring. Consider a system administrator who has the needs to run a monitor to obtain system statistics on his machines. For the sake of simplicity, we deal with hostname, system time, and disk usage as the metrics of interest. The following code shows an object-oriented Perl script that will serve his purposes:

# DiskMonitor.pm
#!/usr/bin/perl
use strict;
use warnings;

package DiskMonitor;

# Constructor for DiskMonitor
# A DiskMonitor object is a hash, and holds a string with key 'usage' in it
sub new {
	my $class = shift;
	my $self = { };
	$self->{'usage'} = undef;
	bless($self, $class);
}

# $self references the object that invoked this method. This method
# sets the value for the 'usage' key inside the object
sub getdiskusage {
	my $self = shift;
	$self->{'usage'} = `df -h`;
        chomp $self->{'usage'};
	return $self->{'usage'};
}

1;
# HostMonitor.pm
#!/usr/bin/perl
use strict;
use warnings;
use Sys::Statistics::Linux;

# Class HostMonitor is a subclass of Sys::Statistics::Linux
package HostMonitor;
our @ISA = "Sys::Statistics::Linux";

# Constructor for HostMonitor
# A HostMonitor object is a hash, and holds a string with key 'hostname' in it
sub new {
	my $class = shift;
	my %params = @_;
	my $self = Sys::Statistics::Linux->new(@_);
	$self->{'hostname'} = undef;
	bless($self, $class);
}

# sets the value for the 'hostname' key inside the object
sub gethostname {
	my $self = shift;
	$self->{'hostname'} = `hostname`;
	chomp $self->{'hostname'};
	return $self->{'hostname'};
}

1;
# Monitor.pm
#!/usr/bin/perl
use strict;
use warnings;
use HostMonitor;
use DiskMonitor;

package SystemMonitor;

# Constructor for SystemMonitor
# A SystemMonitor object is a hash, and holds reference to
# a HostMonitor object with key 'host'
# a DiskMonitor object with key 'disk'
sub new {
	my $class = shift;
	my %param = @_;
	my $self = {
		'host' => HostMonitor->new(%param),
		'disk' => DiskMonitor->new()
	};
	bless($self,$class);
}

sub displayStats {
	my $self = shift;
	my $hostname = $self->{'host'}->gethostname;
	my $time = $self->{'host'}->gettime;
	my $diskusage = $self->{'disk'}->getdiskusage;
	print "For host : $hostname\n";
	print "Time : $time\n";
	print "Disk usage : $diskusage()\n";
}

1;
# displayStats.pl
#!/usr/bin/perl
use warnings;
use strict;
use SystemMonitor;

my $myMonitor = SystemMonitor->new();
$myMonitor->displayStats(); 

Things to take away from this case study:

  • A SystemMonitor object contains a DiskMonitor and a HostMonitor object. It seamlessly glues together these two pre-existing components, one of the fundamental reasons of using a scripting language. It provides SystemMonitor with the appearance of an intact and complete entity, hiding away the internal details of the parts that make it.
  • The SystemMonitor object encapsulates HostMonitor and DiskMonitor objects. This follows natural reasoning of having a consolidated monitor (like the dashboard of a car) with specific metric reporting components inside it (like the various dials on a dashboard).
  • The HostMonitor extends Sys::Statistics::Linux, a pre-existing module obtained from CPAN . The Sys::Statistics::Linux provides with a lot metrics, however our system administrator needs the hostname too. Hence, HostMonitor uses all of the functionality Sys::Statistics::Linux provides, and add the missing method: gethostname(). Hence, we have reused a lot of existing code and customized the host monitoring component to our needs.
  • Extending functionality of the SystemMonitor to collect some other statistics is easy. Suppose now we want our SystemMonitor to report network usage statistics. Just create a new Perl module NetworkMonitor that can obtain the required statistics about network usage and add it as a member of the SystemMonitor package.
  • By defining HostMonitor and DiskMonitor as modules, they are made available to other users for reuse.

Advantages that scripting capability bring to an object-oriented language

Dynamic typing and extensibility reduce software development lifecycle

Dynamic typing doesn’t require explicit declaration of variables before their use. Variables can be used as and when needed without worrying about their declaration and initialization. More importantly, since variable need not be declared, they also need not belong to a particular type. Hence, a variable can bound to objects of different types. Dynamic typing also opens the door for other features such as autovivification, where a variable reference is automatically created on dereferencing an undefined value. This dynamic typing and extensibility reduce the development time as the programmer has the freedom to bind and extended data structures at run time. It also makes the language less syntactically enforcing, making it easier to learn and use.

Standard data representation

A central property of scripting languages is the use of strings as the only representation of data [6]. Hence, all integrated components use the same string interface for typing 6. An implication of dynamic typing is that there are no native data-types. Hence all data structures are inherently built upon the only common representation of data. As a consequence the programmer does not have to worry about type-casting and type-conversions when handling data from different components.

Focus on functionality

Allows application developers to concentrate primarily on the functionality, rather than worry about component fitting. Scripting languages have the ability to glue diverse implementations.

Advantages of scripting languages that are not object oriented

Scripting languages are basically known as “Glue” languages, since scripts glue together various preexisting components or programs which may or may not be in same language. Dynamically typed languages generally use run time objects with tags containing their type information [7]. In dynamic typing, types are associated with values rather than variables. It allows the programmer not to explicit type annotations on expressions. In other words, it allows a variable to refer to values of different types at different points in a single program. Hence it helps scripting language to glue different components together.

Most of the popular scripting languages today did not start out as object-oriented languages. Object-orientation was provided to them later on. The designers of the language envisioned use of scripting for writing easy to medium complexity code in a short time. However, these languages grew immensely popular that made object-orientation a necessity. As such, a performance of a non-object oriented script will always be better that an object-oriented one. Object-orientation adds an extra layer of abstraction that hurts performance. Having said that, todays processors are so fast that this difference is hardly noticeable.

References