http://www.perlmonks.org?node_id=1225549


in reply to Splitting program into modules

Well ... some general thoughts on splitting up unknown code

Incremental strategy

Prerequisites

Study and understand

==== Perl essentials

==== Tools and techniques

==== your application

Analyze
Documentation

Modularisation / Namespaces ?

Object Oriented Programming

Improvement

See Also

Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

update

Expanded the OOP part

) that's an intermediate step exporting and importing is much cleaner

) As a rule of thumb from easier to better

Replies are listed 'Best First'.
Re^2: Splitting program into modules
by eyepopslikeamosquito (Chancellor) on Nov 12, 2018 at 06:05 UTC

    Object Oriented Programming: logical modules are sometimes better OO classes ...

    As for whether and when to use OO, my simple rule of thumb is to ask "do I need more than one?": if the answer is yes, an object is indicated; if the answer is no, a module.

    A (non Perl-specific) design checklist (derived from On Coding Standards and Code Reviews):

    • Coupling and Cohesion. Systems should be designed as a set of cohesive modules as loosely coupled as is reasonably feasible.
    • Testability. Systems should be designed so that components can be easily tested in isolation.
    • Data hiding. Minimize the exposure of implementation details. Minimize global data.
    • Interfaces matter. Once an interface becomes widely used, changing it becomes practically impossible (just about anything else can be fixed in a later release).
    • Design the module's interface first.
    • Design interfaces that are: consistent; easy to use correctly; hard to use incorrectly; easy to read, maintain and extend; clearly documented; appropriate to your audience. Be sufficient, not complete; it is easier to add a new feature than to remove a mis-feature.
    • Use descriptive, explanatory, consistent and regular names.
    • Correctness, simplicity and clarity come first. Avoid unnecessary cleverness. If you must rely on cleverness, encapsulate and comment it.
    • DRY (Don't repeat yourself).
    • Establish a rational error handling policy and follow it strictly.

      I once had to maintain code which had many subs accessing a bunch of global states which where switched by calling an "init()" routine or passed flags.

      After long analysis (Freudian yes) I realized that these routines where effectively methods, the states where instance vars and the so called init() routine switched the instances.

      Well actually that was only a simplified description of what happened, I don't wanna give you nightmares. :)

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

      </div