perltoot.1

视频监控网络部分的协议ddns,的模块的实现代码,请大家大胆指正.

.PP
.Vb 10
\&    sub debug {
\&        my $self = shift;
\&        confess "usage: thing\->debug(level)"    unless @_ == 1;
\&        my $level = shift;
\&        if (ref($self))  {
\&            $self\->{"_DEBUG"} = $level;         # just myself
\&        } else {
\&            $Debugging        = $level;         # whole class
\&        }
\&    }
\&
\&    sub DESTROY {
\&        my $self = shift;
\&        if ($Debugging || $self\->{"_DEBUG"}) {
\&            carp "Destroying $self " . $self\->name;
\&        }
\&        \-\- ${ $self\->{"_CENSUS"} };
\&    }
.Ve
.PP
What happens if a derived class (which we'll call Employee) inherits
methods from this Person base class?  Then \f(CW\*(C`Employee\->debug()\*(C'\fR, when called
as a class method, manipulates \f(CW$Person::Debugging\fR not \f(CW$Employee::Debugging\fR.
.Sh "Class Destructors"
.IX Subsection "Class Destructors"
The object destructor handles the death of each distinct object.  But sometimes
you want a bit of cleanup when the entire class is shut down, which
currently only happens when the program exits.  To make such a
\&\fIclass destructor\fR, create a function in that class's package named
\&\s-1END\s0.  This works just like the \s-1END\s0 function in traditional modules,
meaning that it gets called whenever your program exits unless it execs
or dies of an uncaught signal.  For example,
.PP
.Vb 5
\&    sub END {
\&        if ($Debugging) {
\&            print "All persons are going away now.\en";
\&        }
\&    }
.Ve
.PP
When the program exits, all the class destructors (\s-1END\s0 functions) are
be called in the opposite order that they were loaded in (\s-1LIFO\s0 order).
.Sh "Documenting the Interface"
.IX Subsection "Documenting the Interface"
And there you have it: we've just shown you the \fIimplementation\fR of this
Person class.  Its \fIinterface\fR would be its documentation.  Usually this
means putting it in pod (\*(L"plain old documentation\*(R") format right there
in the same file.  In our Person example, we would place the following
docs anywhere in the Person.pm file.  Even though it looks mostly like
code, it's not.  It's embedded documentation such as would be used by
the pod2man, pod2html, or pod2text programs.  The Perl compiler ignores
pods entirely, just as the translators ignore code.  Here's an example of
some pods describing the informal interface:
.PP
.Vb 1
\&    =head1 NAME
\&
\&    Person \- class to implement people
\&
\&    =head1 SYNOPSIS
\&
\&     use Person;
\&
\&     #################
\&     # class methods #
\&     #################
\&     $ob    = Person\->new;
\&     $count = Person\->population;
\&
\&     #######################
\&     # object data methods #
\&     #######################
\&
\&     ### get versions ###
\&         $who   = $ob\->name;
\&         $years = $ob\->age;
\&         @pals  = $ob\->peers;
\&
\&     ### set versions ###
\&         $ob\->name("Jason");
\&         $ob\->age(23);
\&         $ob\->peers( "Norbert", "Rhys", "Phineas" );
\&
\&     ########################
\&     # other object methods #
\&     ########################
\&
\&     $phrase = $ob\->exclaim;
\&     $ob\->happy_birthday;
\&
\&    =head1 DESCRIPTION
\&
\&    The Person class implements dah dee dah dee dah....
.Ve
.PP
That's all there is to the matter of interface versus implementation.
A programmer who opens up the module and plays around with all the private
little shiny bits that were safely locked up behind the interface contract
has voided the warranty, and you shouldn't worry about their fate.
.SH "Aggregation"
.IX Header "Aggregation"
Suppose you later want to change the class to implement better names.
Perhaps you'd like to support both given names (called Christian names,
irrespective of one's religion) and family names (called surnames), plus
nicknames and titles.  If users of your Person class have been properly
accessing it through its documented interface, then you can easily change
the underlying implementation.  If they haven't, then they lose and
it's their fault for breaking the contract and voiding their warranty.
.PP
To do this, we'll make another class, this one called Fullname.  What's
the Fullname class look like?  To answer that question, you have to
first figure out how you want to use it.  How about we use it this way:
.PP
.Vb 7
\&    $him = Person\->new();
\&    $him\->fullname\->title("St");
\&    $him\->fullname\->christian("Thomas");
\&    $him\->fullname\->surname("Aquinas");
\&    $him\->fullname\->nickname("Tommy");
\&    printf "His normal name is %s\en", $him\->name;
\&    printf "But his real name is %s\en", $him\->fullname\->as_string;
.Ve
.PP
Ok.  To do this, we'll change \fIPerson::new()\fR so that it supports
a full name field this way:
.PP
.Vb 11
\&    sub new {
\&        my $class = shift;
\&        my $self  = {};
\&        $self\->{FULLNAME} = Fullname\->new();
\&        $self\->{AGE}      = undef;
\&        $self\->{PEERS}    = [];
\&        $self\->{"_CENSUS"} = \e$Census;
\&        bless ($self, $class);
\&        ++ ${ $self\->{"_CENSUS"} };
\&        return $self;
\&    }
\&
\&    sub fullname {
\&        my $self = shift;
\&        return $self\->{FULLNAME};
\&    }
.Ve
.PP
Then to support old code, define \fIPerson::name()\fR this way:
.PP
.Vb 5
\&    sub name {
\&        my $self = shift;
\&        return $self\->{FULLNAME}\->nickname(@_)
\&          ||   $self\->{FULLNAME}\->christian(@_);
\&    }
.Ve
.PP
Here's the Fullname class.  We'll use the same technique
of using a hash reference to hold data fields, and methods
by the appropriate name to access them:
.PP
.Vb 2
\&    package Fullname;
\&    use strict;
\&
\&    sub new {
\&        my $class = shift;
\&        my $self  = {
\&            TITLE       => undef,
\&            CHRISTIAN   => undef,
\&            SURNAME     => undef,
\&            NICK        => undef,
\&        };
\&        bless ($self, $class);
\&        return $self;
\&    }
\&
\&    sub christian {
\&        my $self = shift;
\&        if (@_) { $self\->{CHRISTIAN} = shift }
\&        return $self\->{CHRISTIAN};
\&    }
\&
\&    sub surname {
\&        my $self = shift;
\&        if (@_) { $self\->{SURNAME} = shift }
\&        return $self\->{SURNAME};
\&    }
\&
\&    sub nickname {
\&        my $self = shift;
\&        if (@_) { $self\->{NICK} = shift }
\&        return $self\->{NICK};
\&    }
\&
\&    sub title {
\&        my $self = shift;
\&        if (@_) { $self\->{TITLE} = shift }
\&        return $self\->{TITLE};
\&    }
\&
\&    sub as_string {
\&        my $self = shift;
\&        my $name = join(" ", @$self{\*(AqCHRISTIAN\*(Aq, \*(AqSURNAME\*(Aq});
\&        if ($self\->{TITLE}) {
\&            $name = $self\->{TITLE} . " " . $name;
\&        }
\&        return $name;
\&    }
\&
\&    1;
.Ve
.PP
Finally, here's the test program:
.PP
.Vb 4
\&    #!/usr/bin/perl \-w
\&    use strict;
\&    use Person;
\&    sub END { show_census() }
\&
\&    sub show_census ()  {
\&        printf "Current population: %d\en", Person\->population;
\&    }
\&
\&    Person\->debug(1);
\&
\&    show_census();
\&
\&    my $him = Person\->new();
\&
\&    $him\->fullname\->christian("Thomas");
\&    $him\->fullname\->surname("Aquinas");
\&    $him\->fullname\->nickname("Tommy");
\&    $him\->fullname\->title("St");
\&    $him\->age(1);
\&
\&    printf "%s is really %s.\en", $him\->name, $him\->fullname\->as_string;
\&    printf "%s\*(Aqs age: %d.\en", $him\->name, $him\->age;
\&    $him\->happy_birthday;
\&    printf "%s\*(Aqs age: %d.\en", $him\->name, $him\->age;
\&
\&    show_census();
.Ve
.SH "Inheritance"
.IX Header "Inheritance"
Object-oriented programming systems all support some notion of
inheritance.  Inheritance means allowing one class to piggy-back on
top of another one so you don't have to write the same code again and
again.  It's about software reuse, and therefore related to Laziness,
the principal virtue of a programmer.  (The import/export mechanisms in
traditional modules are also a form of code reuse, but a simpler one than
the true inheritance that you find in object modules.)
.PP
Sometimes the syntax of inheritance is built into the core of the
language, and sometimes it's not.  Perl has no special syntax for
specifying the class (or classes) to inherit from.  Instead, it's all
strictly in the semantics.  Each package can have a variable called \f(CW@ISA\fR,
which governs (method) inheritance.  If you try to call a method on an
object or class, and that method is not found in that object's package,
Perl then looks to \f(CW@ISA\fR for other packages to go looking through in
search of the missing method.
.PP
Like the special per-package variables recognized by Exporter (such as
\&\f(CW@EXPORT\fR, \f(CW@EXPORT_OK\fR, \f(CW@EXPORT_FAIL\fR, \f(CW%EXPORT_TAGS\fR, and \f(CW$VERSION\fR), the \f(CW@ISA\fR
array \fImust\fR be a package-scoped global and not a file-scoped lexical
created via \fImy()\fR.  Most classes have just one item in their \f(CW@ISA\fR array.
In this case, we have what's called \*(L"single inheritance\*(R", or \s-1SI\s0 for short.
.PP
Consider this class:
.PP
.Vb 4
\&    package Employee;
\&    use Person;
\&    @ISA = ("Person");
\&    1;
.Ve
.PP
Not a lot to it, eh?  All it's doing so far is loading in another
class and stating that this one will inherit methods from that
other class if need be.  We have given it none of its own methods.
We rely upon an Employee to behave just like a Person.
.PP
Setting up an empty class like this is called the \*(L"empty subclass test\*(R";
that is, making a derived class that does nothing but inherit from a
base class.  If the original base class has been designed properly,
then the new derived class can be used as a drop-in replacement for the
old one.  This means you should be able to write a program like this:
.PP
.Vb 5
\&    use Employee;
\&    my $empl = Employee\->new();
\&    $empl\->name("Jason");
\&    $empl\->age(23);
\&    printf "%s is age %d.\en", $empl\->name, $empl\->age;
.Ve
.PP
By proper design, we mean always using the two-argument form of \fIbless()\fR,
avoiding direct access of global data, and not exporting anything.  If you
look back at the \fIPerson::new()\fR function we defined above, we were careful
to do that.  There's a bit of package data used in the constructor,
but the reference to this is stored on the object itself and all other
methods access package data via that reference, so we should be ok.
.PP
What do we mean by the \fIPerson::new()\fR function \*(-- isn't that actually
a method?  Well, in principle, yes.  A method is just a function that
expects as its first argument a class name (package) or object
(blessed reference).   \fIPerson::new()\fR is the function that both the
\&\f(CW\*(C`Person\->new()\*(C'\fR method and the \f(CW\*(C`Employee\->new()\*(C'\fR method end
up calling.  Understand that while a method call looks a lot like a
function call, they aren't really quite the same, and if you treat them
as the same, you'll very soon be left with nothing but broken programs.
First, the actual underlying calling conventions are different: method
calls get an extra argument.  Second, function calls don't do inheritance,
but methods do.
.PP
.Vb 4
\&        Method Call             Resulting Function Call
\&        \-\-\-\-\-\-\-\-\-\-\-             \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
\&        Person\->new()           Person::new("Person")
\&        Employee\->new()         Person::new("Employee")
.Ve
.PP
So don't use function calls when you mean to call a method.
.PP
If an employee is just a Person, that's not all too very interesting.
So let's add some other methods.  We'll give our employee
data fields to access their salary, their employee \s-1ID\s0, and their
start date.
.PP
If you're getting a little tired of creating all these nearly identical
methods just to get at the object's data, do not despair.  Later,
we'll describe several different convenience mechanisms for shortening
this up.  Meanwhile, here's the straight-forward way: