Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re: How to morph a plain module to OO

by sauoq (Abbot)
on Sep 07, 2002 at 19:10 UTC ( #195894=note: print w/ replies, xml ) Need Help??


in reply to How to morph a plain module to OO

My first suggestion is not to do this. If you have a working module and it is already heavily used, just write a new module for the OO stuff and have it use the old module under the covers. It is far too easy to break the original code in subtle ways.

As an illustration, you already broke the functionality of your original module because your new isFile() doesn't take a verbose argument when it isn't used as a method.

-sauoq
"My two cents aren't worth a dime.";


Comment on Re: How to morph a plain module to OO
Re^2: How to morph a plain module to OO
by adrianh (Chancellor) on Sep 07, 2002 at 21:37 UTC
    My first suggestion is not to do this. If you have a working module and it is already heavily used, just write a new module for the OO stuff and have it use the old module under the covers.

    I second that suggestion :-)

    My process for this sort of thing is as follows:

    1. Create your new OO module that calls the original module where it needs functionality. Do not touch the implementation of the original module. If you do have to touch the implementation, skip immediately step 3. (You will, of course, be creating a nice comprehensive test suite while you implement the new module ;-)
    2. Stop - unless the new module is inelegant, or you want to retire the original module.
    3. If it doesn't have one already, write a comprehensive test suite for the original module - so you can be sure that you don't break anything during the move.
    4. Do not skip the last step. I really mean it!
    5. Repeat the following until the original module is implemented in terms of the OO module:
      1. Move a chunk of the implementation from the original module to the OO module.
      2. Re-implement the functionality you've just moved in the original module in terms of the OO module.
      3. Run the test suites for both modules. Fix bugs. Repeat until no bugs.
    6. Add some "deprecated" warnings (see perllexwarn) to the original module.
    7. Remove original module if you have to (after an appropriate time of mourning).

    Basically, do it gradually and incrementally. Don't try and have a single module be OO and non-OO at the same time. It's complicated and will cause you more hassle than it will save.

    (and I really mean it about those tests :-)


    This nodes spelling mistakes were...

    s/morning/mourning/ - thanks Arien

    s/depreciated/deprecated/ - thanks to sauoq

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://195894]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (8)
As of 2014-09-16 16:57 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (36 votes), past polls