I'm intrigued by this (and the answers so far to your question). You have a hairy bunch of state squirreled away in a collection of global variables. OK, we all agree that is a nightmare. Do we agree that it is primarily a nightmare because it is hard to know which bits of the code touch the globals and how they interact?

If so, how does using a Singleton class help at all? In order to keep the app working, all parts of your app will need access to the singleton. So that in itself will not help. The code is still tweaking a hairy collection of state, only now it is wrapped up in a singleton. I don't see any benefit yet.

You want to migrate. So you plan to move data out of the singleton/global variables into managed packages/objects. Good.

I guess that encapsulation in the singleton gives you the ability to move the data out from the singleton to a new class, as long as you change the implementation of the singleton to access the new class. But that doesn't help your code quality, since all the code which accesses the data still does so through the singleton.

Code quality benefits only accrue once you change the code which accesses the data to do so through the new interface. At which point you will presumably remove that data from the singleton.

But but but. The hard part is changing all the code which uses the data. AFAICS, you propose to do this twice - once to access the singleton and then once to access the 'new interface'.

Why not just leave the old, global-accessing code in place with a view to getting it to use the new interface when it is ready (note that you can do this piecemeal, as you finish each new interface which encompasses part of your global data)? OK, you may have namespace issues (your globals will reside in main::) but they can be hacked around fairly easily by aliasing (a hopefully-temporary 'use Crud' in each new package). The namespace pollution will probably be horrible but you have that already.

OK. I should probably go away and read up on design patterns, but this is an honest question. Can someone explain the benefits to me please?

In reply to Re: how to make a universally inherited method? by jbert
in thread how to make a universally inherited method? by exphysicist

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • 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! —
  • 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:
    & &amp;
    < &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.