of interfaces available. There are pros and cons of each technique, which
should be considered when you design your API.
-According to Damian Conway, you should consider using OO:
+In I<Perl Best Practices> (copyright 2004, Published by O'Reilly Media, Inc.),
+Damian Conway provides a list of criteria to use when deciding if OO is the
+right fit for your problem:
=over 4
-=item *
+=item *
-When the system is large or likely to become so
+The system being designed is large, or is likely to become large.
-=item *
+=item *
-When the data is aggregated in obvious structures that will become objects
+The data can be aggregated into obvious structures, especially if
+there's a large amount of data in each aggregate.
-=item *
+=item *
-When the types of data form a natural hierarchy that can make use of inheritance
+The various types of data aggregate form a natural hierarchy that
+facilitates the use of inheritance and polymorphism.
=item *
-When operations on data vary according to data type (making
-polymorphic invocation of methods feasible)
+You have a piece of data on which many different operations are
+applied.
=item *
-When it is likely that new data types may be later introduced
-into the system, and will need to be handled by existing code
+You need to perform the same general operations on related types of
+data, but with slight variations depending on the specific type of data
+the operations are applied to.
=item *
-When interactions between data are best represented by
-overloaded operators
+It's likely you'll have to add new data types later.
=item *
-When the implementation of system components is likely to
-change over time (and hence should be encapsulated)
+The typical interactions between pieces of data are best represented by
+operators.
=item *
-When the system design is itself object-oriented
+The implementation of individual components of the system is likely to
+change over time.
=item *
-When large amounts of client code will use the software (and
-should be insulated from changes in its implementation)
+The system design is already object-oriented.
=item *
-When many separate operations will need to be applied to the
-same set of data
+Large numbers of other programmers will be using your code modules.
=back
unintuitive. Also, if many elements may be undefined you may see the
following unattractive method calls:
- $obj->do_something(undef, undef, undef, undef, undef, undef, 1024);
+ $obj->do_something(undef, undef, undef, undef, undef, 1024);
Provide sensible defaults for parameters which have them. Don't make
your users specify parameters which will almost always be the same.
software describing user-visible changes to your module, in terms
relevant to the user.
+Unless you have good reasons for using some other format
+(for example, a format used within your company),
+the convention is to name your changelog file C<Changes>,
+and to follow the simple format described in L<CPAN::Changes::Spec>.
+
=head1 RELEASE CONSIDERATIONS
=head2 Version numbering
For Module::Build you would use the C<make test> equivalent C<perl Build test>.
The importance of these tests is proportional to the alleged stability of a
-module -- a module which purports to be stable or which hopes to achieve wide
+module. A module which purports to be stable or which hopes to achieve wide
use should adhere to as strict a testing regime as possible.
Useful modules to help you write tests (with minimum impact on your
If you don't know what license to use, dual licensing under the GPL
and Artistic licenses (the same as Perl itself) is a good idea.
+See L<perlgpl> and L<perlartistic>.
=head1 COMMON PITFALLS
https://perl5.git.perl.org / perl5.git / blobdiff