CSC/ECE 517 Fall 2011/ch1 1g rn

From Expertiza_Wiki
Jump to navigation Jump to search

Object-Oriented Languages and Scripting

Introduction

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.

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.

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 intermediate knowledge of Perl. An excellent resource for learning 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. 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. 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. 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

foo bar

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;

sub new {
	my $class = shift;
	my $self = { };
	$self->{'usage'} = undef;
	bless($self, $class);
}

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;

package HostMonitor;
our @ISA = "Sys::Statistics::Linux";

sub new {
	my $class = shift;
	my %params = @_;
	my $self = Sys::Statistics::Linux->new(@_);
	$self->{'hostname'} = undef;
	bless($self, $class);
}

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;

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:

  • 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.
  • 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 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.
  • 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 [1]. 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.

Are there any advantages to a scripting language that is not object oriented?

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.

Is scripting essentially synonymous with dynamic typing?

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. In dynamic typing, types are associated with run time values rather than normal expressions written. It determines the type safety of operations at run time. It allows programmer not to write explicit type annotations on expressions. In other words, it allows a single variable to refer to values of different types at different points in the single program. Hence it helps scripting language to glue different components together. Some of the dynamic scripting languages are python, ruby, Perl while using user data types. Scripting languages are interpreted, as most of the dynamic typing languages are, it does not mean all languages are dynamically typed such as objective C or Lisp. Also not all dynamically typed languages offer scripting functionality. Like Perl allows dynamic typing for user defined data types only, but it is used for scripting.

References

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch1_1g_rn&oldid=48378"