CSC/ECE 517 Fall 2011/ch1 1g rn: Difference between revisions
Line 122: | Line 122: | ||
Things to take away from this case study: | Things to take away from this case study: | ||
* The Monitor object seamlessly glues together pre-existing components: HostMonitor and DiskMonitor, one of the fundamental reasons of using a scripting language. It provides a Monitor with the appearance of an intact and complete entity, hiding away the internal details of the parts that make it. | * The Monitor object seamlessly glues together pre-existing components: HostMonitor and DiskMonitor, one of the fundamental reasons of using a scripting language. It provides a Monitor with the appearance of an intact and complete entity, hiding away the internal details of the parts that make it. | ||
* The Monitor 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 Monitor 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 ex¬isting code and customized the host monitoring component to our needs. | * 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 ex¬isting code and customized the host monitoring component to our needs. | ||
* By defining HostMonitor and DiskMonitor as modules, they are made available to other users for reuse. | * By defining HostMonitor and DiskMonitor as modules, they are made available to other users for reuse. | ||
Revision as of 00:31, 9 September 2011
Object-Oriented Languages and Scripting
Scripting
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.
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, monitoring 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`; 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 Monitor; 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 Monitor; my $myMonitor = Monitor->new(); $myMonitor->displayStats();
Things to take away from this case study:
- The Monitor object seamlessly glues together pre-existing components: HostMonitor and DiskMonitor, one of the fundamental reasons of using a scripting language. It provides a Monitor with the appearance of an intact and complete entity, hiding away the internal details of the parts that make it.
- The Monitor 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 ex¬isting code and customized the host monitoring component to our needs.
- By defining HostMonitor and DiskMonitor as modules, they are made available to other users for reuse.