C++, or The Crucible In Which Good Developers Are Forged

I code in C++ a lot at my job. Well, more like MFC, which is technically a set of C++ wrappers around Win32, but is about as far from plain-vanilla standard C++ as you can get. And I find myself raising my fists like little balls of rage to the heavens every few days when I see something like this:

class SomeBigClass
{
    private:
       HelperClass *m_pHelper;
       ImportantPointer *m_pImportant;
    public:
       ImportantPointer *GetImportantPointer()
       {
           return m_pImportant;
       }

       SomeBigClass() 
       {
       	   m_pHelper = new HelperClass(this);
	   m_pImportant = new ImportantPointer();
       }
       
       void DoSomethingInteresting()
       {
           m_pHelper->DoSomethingHelpful();
           m_pImportant->DoImportantOperation();
       }
}

and then, lo and behold after many access violations, wailing, and gnashing of teeth, the following is discovered in the source for HelperClass:

HelperClass::DoSomethingHelpful()
{
    // blah blah blah
    // ...
    delete m_pSomeBigClass->GetImportantPointer();
}

Now, the argument could and should be made that a helper class should never be deleting pointers that it doesn't own--this is just bad design. But what does one do when encountering such a problem? Refactor? Work around it in the consuming code?

I don't think there's a good answer, at least not without having more information about the context. But now that I have a few years of experience under my belt as a software-talking-guy, I understand that half the battle is simply recognizing these anti-patterns and just dealing with them.

This problem's an easy one. Refactor it. Work around it. Rewrite the method. But I've learned that if you want to be something more than a junior developer toiling away in the junior developer salt mines, you have to take the initiative and fix stuff that's broke when you see it.