C# – Refactor class (extract methods) in a main / helper classes

crefactoring

Simply spoken, one of my c# classes got too big and I'm currently splitting this class in several subclasses by clustering semantically related methods (actually actions, which do side effects).

So, to give you an example:

class ViewModel
{
  // a lot of properties bound to view (MVVM pattern)
  public Property 1 //bound to view
  public Property 2 //bound to view

  // a lot of actions, containing the controller logic of the view
  //Function 1 changes Property 1 -> shall be moved to class MyViewModelHelper
  Function1() {}

That is, when I create a helper class for the viewModel, it needs to to receive the instance reference of the main view model in its constructor, so that it has access to the public properties.

I do not want that the view has to have the knowledge about the helper classes, that is the main view model shall provide all the properties… but the functions shall delegate the work to the helper classes to keep the viewModel class maintainable.

Best Answer

Sounds like a case for using extension methods. Simply move Function1() to MyViewModelHelper, make it static, and change the first/only paramater to be like this:

public static class MyViewModelHelper
{
    public static void Function1(this ViewModel vm)
    {
        // whatever
    }
}

As a benefit: afterward, the semantics of the callers often don't need to change.

Related Solutions

Python Refactoring – How to Refactor a ‘God Class’

Having written and then refactored a python "God object", I sympathize. What I did is break the original object down into sub sections based upon methods. For instance, the original looked like this pseudo code:

method A():
    self.bla += 1

method B():
    self.bla += 1

do stuff():
    self.bla = 1
    method A()
    method B()
    print self.bla

The stuff method is a self contained "unit" of work. I migrated it out to a new class which the original instantiates. This pulled out the necessary properties as well. Some were used only by the sub class and could move straight across. Others were shared, and got moved into a shared class.

The "God object" creates a new copy of the shared class at start up, and each of the new sub classes accepts a pointer as part of their init method. For example, here's a stripped version of the mailer:

#!/usr/bin/env python
# -*- coding: ascii -*-
'''Functions for emailing with dirMon.'''

from email.MIMEMultipart import MIMEMultipart
from email.MIMEBase import MIMEBase
from email.MIMEText import MIMEText
from email.Utils import COMMASPACE, formatdate
from email import Encoders
import os
import smtplib
import datetime
import logging

class mailer:
    def __init__(self,SERVER="mail.server.com",FROM="support@server.com"):
        self.server = SERVER
        self.send_from = FROM
        self.logger = logging.getLogger('dirMon.mailer')

    def send_mail(self, send_to, subject, text, files=[]):
        assert type(send_to)==list
        assert type(files)==list
        if self.logger.isEnabledFor(logging.DEBUG):
            self.logger.debug(' '.join(("Sending email to:",' '.join(send_to))))
            self.logger.debug(' '.join(("Subject:",subject)))
            self.logger.debug(' '.join(("Text:",text)))
            self.logger.debug(' '.join(("Files:",' '.join(files))))
        msg = MIMEMultipart()
        msg['From'] = self.send_from
        msg['To'] = COMMASPACE.join(send_to)
        msg['Date'] = formatdate(localtime=True)
        msg['Subject'] = subject
        msg.attach( MIMEText(text) )
        for f in files:
            part = MIMEBase('application', "octet-stream")
            part.set_payload( open(f,"rb").read() )
            Encoders.encode_base64(part)
            part.add_header('Content-Disposition', 'attachment; filename="%s"' % os.path.basename(f))
            msg.attach(part)
        smtp = smtplib.SMTP(self.server)
        mydict = smtp.sendmail(self.send_from, send_to, msg.as_string())
        if self.logger.isEnabledFor(logging.DEBUG):
            self.logger.debug("Email Successfully Sent!")
        smtp.close()
        return mydict

It is created once and shared between the different classes that need mailing capabilities.

So for you, create a class larry with the properties and methods you need. Everywhere the client says larry = blah replace it with larryObj.larry = blah. This migrates things to sub projects without breaking the current interface.

The only other thing to do is look for "units of work". If you were going to turn part of the "God Object" into it's own method, do so. But, put the method outside it. This forces you to create an interface between the components.

Laying that groundwork allows everything else to follow it. For example, a piece of the helper object demonstrating how it interfaces with the mailer:

#!/usr/bin/env python
'''This module holds a class to spawn various subprocesses'''
import logging, os, subprocess, time, dateAdditionLib, datetime, re

class spawner:
    def __init__(self, mailer):
        self.logger = logging.getLogger('dirMon.spawner')
        self.myMailer = mailer

Concentrate on the smallest individual unit of work possible, and move it out. This is easier to do, and lets you play with the setup quickly. Don't look at properties for moving stuff, they are ancillary to the tasks being done with them in most cases. Whatever is left over after you have dealt with the methods should probably stay in the original object, since it is part of the shared state.

But, the new objects should now accept the properties they need as init variables, not touching the caller objects property. They then return any necessary values, which the caller can use to update the shared properties as necessary. This helps to decouple the objects and makes for a more robust system.

C# – What’s the best way to expose a Model object in a ViewModel

As a general rule, it is not a good idea to expose a Model object in a ViewModel object. The form of the ViewModel class should be determined by the needs of the View that will use it. The form of the Model class should be determined by the concerns of your data model.

In my experience with Entity Framework and the MVVM pattern, I have found it best to transform the EF data as I populate my ViewModel object. The ViewModel object will then contain the data from the data model but in a different form. If you need to allow the user to change data, then you often want to have methods that transform the modified ViewModel data back into Model data so that you can persist it to your data store.

Best Answer

Related Solutions

Python Refactoring – How to Refactor a ‘God Class’

C# – What’s the best way to expose a Model object in a ViewModel

Related Topic