perltoot.1

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

\&    }
\&
\&    sub age {
\&        my $self = shift;
\&        if (@_) { $self\->{AGE} = shift }
\&        return $self\->{AGE};
\&    }
\&
\&    sub peers {
\&        my $self = shift;
\&        if (@_) { @{ $self\->{PEERS} } = @_ }
\&        return @{ $self\->{PEERS} };
\&    }
\&
\&    1;  # so the require or use succeeds
.Ve
.PP
We've created three methods to access an object's data, \fIname()\fR, \fIage()\fR,
and \fIpeers()\fR.  These are all substantially similar.  If called with an
argument, they set the appropriate field; otherwise they return the
value held by that field, meaning the value of that hash key.
.Sh "Planning for the Future: Better Constructors"
.IX Subsection "Planning for the Future: Better Constructors"
Even though at this point you may not even know what it means, someday
you're going to worry about inheritance.  (You can safely ignore this
for now and worry about it later if you'd like.)  To ensure that this
all works out smoothly, you must use the double-argument form of \fIbless()\fR.
The second argument is the class into which the referent will be blessed.
By not assuming our own class as the default second argument and instead
using the class passed into us, we make our constructor inheritable.
.PP
.Vb 9
\&    sub new {
\&        my $class = shift;
\&        my $self  = {};
\&        $self\->{NAME}   = undef;
\&        $self\->{AGE}    = undef;
\&        $self\->{PEERS}  = [];
\&        bless ($self, $class);
\&        return $self;
\&    }
.Ve
.PP
That's about all there is for constructors.  These methods bring objects
to life, returning neat little opaque bundles to the user to be used in
subsequent method calls.
.Sh "Destructors"
.IX Subsection "Destructors"
Every story has a beginning and an end.  The beginning of the object's
story is its constructor, explicitly called when the object comes into
existence.  But the ending of its story is the \fIdestructor\fR, a method
implicitly called when an object leaves this life.  Any per-object
clean-up code is placed in the destructor, which must (in Perl) be called
\&\s-1DESTROY\s0.
.PP
If constructors can have arbitrary names, then why not destructors?
Because while a constructor is explicitly called, a destructor is not.
Destruction happens automatically via Perl's garbage collection (\s-1GC\s0)
system, which is a quick but somewhat lazy reference-based \s-1GC\s0 system.
To know what to call, Perl insists that the destructor be named \s-1DESTROY\s0.
Perl's notion of the right time to call a destructor is not well-defined
currently, which is why your destructors should not rely on when they are
called.
.PP
Why is \s-1DESTROY\s0 in all caps?  Perl on occasion uses purely uppercase
function names as a convention to indicate that the function will
be automatically called by Perl in some way.  Others that are called
implicitly include \s-1BEGIN\s0, \s-1END\s0, \s-1AUTOLOAD\s0, plus all methods used by
tied objects, described in perltie.
.PP
In really good object-oriented programming languages, the user doesn't
care when the destructor is called.  It just happens when it's supposed
to.  In low-level languages without any \s-1GC\s0 at all, there's no way to
depend on this happening at the right time, so the programmer must
explicitly call the destructor to clean up memory and state, crossing
their fingers that it's the right time to do so.   Unlike \*(C+, an
object destructor is nearly never needed in Perl, and even when it is,
explicit invocation is uncalled for.  In the case of our Person class,
we don't need a destructor because Perl takes care of simple matters
like memory deallocation.
.PP
The only situation where Perl's reference-based \s-1GC\s0 won't work is
when there's a circularity in the data structure, such as:
.PP
.Vb 1
\&    $this\->{WHATEVER} = $this;
.Ve
.PP
In that case, you must delete the self-reference manually if you expect
your program not to leak memory.  While admittedly error-prone, this is
the best we can do right now.  Nonetheless, rest assured that when your
program is finished, its objects' destructors are all duly called.
So you are guaranteed that an object \fIeventually\fR gets properly
destroyed, except in the unique case of a program that never exits.
(If you're running Perl embedded in another application, this full \s-1GC\s0
pass happens a bit more frequently\*(--whenever a thread shuts down.)
.Sh "Other Object Methods"
.IX Subsection "Other Object Methods"
The methods we've talked about so far have either been constructors or
else simple \*(L"data methods\*(R", interfaces to data stored in the object.
These are a bit like an object's data members in the \*(C+ world, except
that strangers don't access them as data.  Instead, they should only
access the object's data indirectly via its methods.  This is an
important rule: in Perl, access to an object's data should \fIonly\fR
be made through methods.
.PP
Perl doesn't impose restrictions on who gets to use which methods.
The public-versus-private distinction is by convention, not syntax.
(Well, unless you use the Alias module described below in
\&\*(L"Data Members as Variables\*(R".)  Occasionally you'll see method names beginning or ending
with an underscore or two.  This marking is a convention indicating
that the methods are private to that class alone and sometimes to its
closest acquaintances, its immediate subclasses.  But this distinction
is not enforced by Perl itself.  It's up to the programmer to behave.
.PP
There's no reason to limit methods to those that simply access data.
Methods can do anything at all.  The key point is that they're invoked
against an object or a class.  Let's say we'd like object methods that
do more than fetch or set one particular field.
.PP
.Vb 5
\&    sub exclaim {
\&        my $self = shift;
\&        return sprintf "Hi, I\*(Aqm %s, age %d, working with %s",
\&            $self\->{NAME}, $self\->{AGE}, join(", ", @{$self\->{PEERS}});
\&    }
.Ve
.PP
Or maybe even one like this:
.PP
.Vb 4
\&    sub happy_birthday {
\&        my $self = shift;
\&        return ++$self\->{AGE};
\&    }
.Ve
.PP
Some might argue that one should go at these this way:
.PP
.Vb 5
\&    sub exclaim {
\&        my $self = shift;
\&        return sprintf "Hi, I\*(Aqm %s, age %d, working with %s",
\&            $self\->name, $self\->age, join(", ", $self\->peers);
\&    }
\&
\&    sub happy_birthday {
\&        my $self = shift;
\&        return $self\->age( $self\->age() + 1 );
\&    }
.Ve
.PP
But since these methods are all executing in the class itself, this
may not be critical.  There are tradeoffs to be made.  Using direct
hash access is faster (about an order of magnitude faster, in fact), and
it's more convenient when you want to interpolate in strings.  But using
methods (the external interface) internally shields not just the users of
your class but even you yourself from changes in your data representation.
.SH "Class Data"
.IX Header "Class Data"
What about \*(L"class data\*(R", data items common to each object in a class?
What would you want that for?  Well, in your Person class, you might
like to keep track of the total people alive.  How do you implement that?
.PP
You \fIcould\fR make it a global variable called \f(CW$Person::Census\fR.  But about
only reason you'd do that would be if you \fIwanted\fR people to be able to
get at your class data directly.  They could just say \f(CW$Person::Census\fR
and play around with it.  Maybe this is ok in your design scheme.
You might even conceivably want to make it an exported variable.  To be
exportable, a variable must be a (package) global.  If this were a
traditional module rather than an object-oriented one, you might do that.
.PP
While this approach is expected in most traditional modules, it's
generally considered rather poor form in most object modules.  In an
object module, you should set up a protective veil to separate interface
from implementation.  So provide a class method to access class data
just as you provide object methods to access object data.
.PP
So, you \fIcould\fR still keep \f(CW$Census\fR as a package global and rely upon
others to honor the contract of the module and therefore not play around
with its implementation.  You could even be supertricky and make \f(CW$Census\fR a
tied object as described in perltie, thereby intercepting all accesses.
.PP
But more often than not, you just want to make your class data a
file-scoped lexical.  To do so, simply put this at the top of the file:
.PP
.Vb 1
\&    my $Census = 0;
.Ve
.PP
Even though the scope of a \fImy()\fR normally expires when the block in which
it was declared is done (in this case the whole file being required or
used), Perl's deep binding of lexical variables guarantees that the
variable will not be deallocated, remaining accessible to functions
declared within that scope.  This doesn't work with global variables
given temporary values via \fIlocal()\fR, though.
.PP
Irrespective of whether you leave \f(CW$Census\fR a package global or make
it instead a file-scoped lexical, you should make these
changes to your \fIPerson::new()\fR constructor:
.PP
.Vb 10
\&    sub new {
\&        my $class = shift;
\&        my $self  = {};
\&        $Census++;
\&        $self\->{NAME}   = undef;
\&        $self\->{AGE}    = undef;
\&        $self\->{PEERS}  = [];
\&        bless ($self, $class);
\&        return $self;
\&    }
\&
\&    sub population {
\&        return $Census;
\&    }
.Ve
.PP
Now that we've done this, we certainly do need a destructor so that
when Person is destroyed, the \f(CW$Census\fR goes down.  Here's how
this could be done:
.PP
.Vb 1
\&    sub DESTROY { \-\-$Census }
.Ve
.PP
Notice how there's no memory to deallocate in the destructor?  That's
something that Perl takes care of for you all by itself.
.PP
Alternatively, you could use the Class::Data::Inheritable module from
\&\s-1CPAN\s0.
.Sh "Accessing Class Data"
.IX Subsection "Accessing Class Data"
It turns out that this is not really a good way to go about handling
class data.  A good scalable rule is that \fIyou must never reference class
data directly from an object method\fR.  Otherwise you aren't building a
scalable, inheritable class.  The object must be the rendezvous point
for all operations, especially from an object method.  The globals
(class data) would in some sense be in the \*(L"wrong\*(R" package in your
derived classes.  In Perl, methods execute in the context of the class
they were defined in, \fInot\fR that of the object that triggered them.
Therefore, namespace visibility of package globals in methods is unrelated
to inheritance.
.PP
Got that?  Maybe not.  Ok, let's say that some other class \*(L"borrowed\*(R"
(well, inherited) the \s-1DESTROY\s0 method as it was defined above.  When those
objects are destroyed, the original \f(CW$Census\fR variable will be altered,
not the one in the new class's package namespace.  Perhaps this is what
you want, but probably it isn't.
.PP
Here's how to fix this.  We'll store a reference to the data in the
value accessed by the hash key \*(L"_CENSUS\*(R".  Why the underscore?  Well,
mostly because an initial underscore already conveys strong feelings
of magicalness to a C programmer.  It's really just a mnemonic device
to remind ourselves that this field is special and not to be used as
a public data member in the same way that \s-1NAME\s0, \s-1AGE\s0, and \s-1PEERS\s0 are.
(Because we've been developing this code under the strict pragma, prior
to perl version 5.004 we'll have to quote the field name.)
.PP
.Vb 12
\&    sub new {
\&        my $class = shift;
\&        my $self  = {};
\&        $self\->{NAME}     = undef;
\&        $self\->{AGE}      = undef;
\&        $self\->{PEERS}    = [];
\&        # "private" data
\&        $self\->{"_CENSUS"} = \e$Census;
\&        bless ($self, $class);
\&        ++ ${ $self\->{"_CENSUS"} };
\&        return $self;
\&    }
\&
\&    sub population {
\&        my $self = shift;
\&        if (ref $self) {
\&            return ${ $self\->{"_CENSUS"} };
\&        } else {
\&            return $Census;
\&        }
\&    }
\&
\&    sub DESTROY {
\&        my $self = shift;
\&        \-\- ${ $self\->{"_CENSUS"} };
\&    }
.Ve
.Sh "Debugging Methods"
.IX Subsection "Debugging Methods"
It's common for a class to have a debugging mechanism.  For example,
you might want to see when objects are created or destroyed.  To do that,
add a debugging variable as a file-scoped lexical.  For this, we'll pull
in the standard Carp module to emit our warnings and fatal messages.
That way messages will come out with the caller's filename and
line number instead of our own; if we wanted them to be from our own
perspective, we'd just use \fIdie()\fR and \fIwarn()\fR directly instead of \fIcroak()\fR
and \fIcarp()\fR respectively.
.PP
.Vb 2
\&    use Carp;
\&    my $Debugging = 0;
.Ve
.PP
Now add a new class method to access the variable.
.PP
.Vb 6
\&    sub debug {
\&        my $class = shift;
\&        if (ref $class)  { confess "Class method called as object method" }
\&        unless (@_ == 1) { confess "usage: CLASSNAME\->debug(level)" }
\&        $Debugging = shift;
\&    }
.Ve
.PP
Now fix up \s-1DESTROY\s0 to murmur a bit as the moribund object expires:
.PP
.Vb 5
\&    sub DESTROY {
\&        my $self = shift;
\&        if ($Debugging) { carp "Destroying $self " . $self\->name }
\&        \-\- ${ $self\->{"_CENSUS"} };
\&    }
.Ve
.PP
One could conceivably make a per-object debug state.  That
way you could call both of these:
.PP
.Vb 2
\&    Person\->debug(1);   # entire class
\&    $him\->debug(1);     # just this object
.Ve
.PP
To do so, we need our debugging method to be a \*(L"bimodal\*(R" one, one that
works on both classes \fIand\fR objects.  Therefore, adjust the \fIdebug()\fR
and \s-1DESTROY\s0 methods as follows: