CODEWITHSUNDEEP
c#
CodeTrance
CodeTrance

Reputation: 109

Large class with many properties, but what if I only need one or two?

I'm modifying an app for performance gains. The app has a class with many properties. Typically this class is populated in its entirety by a primary key that pulls a large query from a database. The application is in great part slow because this happens constantly throughout, even though much of the time only one two properties in the class are needed in a given section of code. The existing large class has only a default constructor and all of its properties are nullable or have default values. In code below ignore lack of constructors and how these objects are populated.

public class Contract
{
    public enum ContractStatus
    {
        Draft, Active, Inactive
    }

    private Int32 contractId = DALC.DefaultInt32;
    private String name = DALC.DefaultString;
    private ContractStatus status;
    private ContractType contractType = null;
    private CurrencyType currencyType = null;
    private Company company = null;
}

As you can see it has its own properties, and also references other classes (e.g. ContractType, Company).

A few approaches I've thought of in light of common design patterns:

1) re-factor this hugely and break up those smaller sub-sections into their own classes with their own properties. Then reconstruct that large class with all of the smaller ones when it is needed. This will be quite laborious, though even if it sounds ideal and consistent with SOLID OOD principles.

2) Create new classes that simply contain the large class, but only expose one or two of its properties. I'm still creating a full blown version of the original, large class, but I will only populate the data I need. This will be via simple DB query, thus the bulk of the class will sit there unused and its null default classes it's referencing won't ever be constructed.

public class ContractName
{
    Contract contract;

    public ContractName()
    {
        contract = new Contract();
    }

    public String Name
    {
        get { return contract.Name; }
        set { contract.Name = value; }
    }
}

3) Add new constructors to existing large class with a parameter indicating what chunks of code I want to actually populate. This sounds messy and kind of nasty and wrong, and would leave me in the scenario where if Contract is created by a contract ID in one section of code it has different info than if created by contract ID elsewhere.

Thanks for any ideas!

Upvotes: 0

Views: 355

Answers (1)

Benjamin Hodgson
Benjamin Hodgson

Reputation: 44634

I would recommend option 1: extract the classes you think you need to extract now. The other two options are just adding more technical debt which will take even longer to resolve in the future. Well-factored code is usually much easier to optimise than big complicated classes.

In my experience, breaking up classes is not all that laborious. In fact I usually find myself surprised by how quickly I can execute refactorings like Extract Class as long as I follow the recipe.

Upvotes: 1

Related Questions