Moving "from scripting to programming" is so much broader than whether to embrace a "fully fledged, object oriented approach"!

Conway's Ten Essential Development Practices should help you appreciate that. For example:

• Design the Module's Interface First. The most important aspect of any module is not how it implements the facilities it provides, but the way in which it provides those facilities in the first place.
• Write the Test Cases Before the Code.
• Use a Revision Control System.
• Add New Test Cases Before you Start Debugging.
• Don't Optimize Code -- Benchmark It.

Modularity is a fundamental aspect of all successful large programs. In Perl therefore, modules are fundamental and you must master them. A study of top-rated CPAN modules is time well spent. For more details see: Writing Solid CPAN Modules.

High-level Design Checklist

• Know Architectural patterns. Choose wisely. Multitier archtecture is common.
• 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.
• Information hiding: Minimize the exposure of implementation details; provide stable interfaces to protect the remainder of the program from the details of the implementation (which are likely to change). Don't just provide full access to the data used in the implementation. Minimize the use of 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.

As for whether and when to use OO, there is no substitute for judgement and taste based on understanding and experience. A 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, then a module.

For some general background on programming paradigms, I quite like Stroustrup's description of different programming styles in C++, a multi-paradigm programming language:

• Procedural: Decide which procedures you want; use the best algorithms you can find.
• Modular: Decide which modules you want; partition the program so that data is hidden within modules.
• Data Abstraction: Decide which types you want; provide a full set of operations for each type.
• Object Oriented: Decide which classes you want; provide a full set of operations for each class; make commonality explicit by using inheritance.
• Generic: Decide which algorithms you want; parameterize them so that they work for a variety of suitable types and data structures.

Though Perl is also a multi-paradigm language, it has significant differences from C++ -- for example, Perl is dynamically typed while C++ is statically typed -- so a Perl design of a given system may vary significantly from a C++ one.

See also:

• On Coding Standards and Code Reviews
• On Interfaces and APIs
• Effective Automated Testing
• Two Different Languages: Two Similar Books (PBP and CCS)
• Re: Sane deprecation policy for a CPAN module? (Software Versioning and Exporter References) (discusses software versioning)

Updated 2020: Minor changes to "High-level Design Checklist" section.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.