Tips on proper classes

Question

Hello,

I'm using C#. I have a products class with fields like sku, name, description.... and methods like setSku, setDescription, setImages(products have an image attached). I was keeping these methods inside the Product class but because of the large amount of settings available to the client on how to set the sku and descriptions and images, the class was getting really, really large. There was a lot of code inside the class. So I was going to break up the large Product class into pieces like a ProductSku class, ProductDescription class...etc. The problem here is that there are some of the same fields that need to be accessed by all the classes. I starting calling the methods on those individual classes and passing in the same objects over and over again, but this didn't seem to be right. So now I decided to make one global(using Singleton pattern) CurrentProduct class that has the fields I need for all the other Product classes I created. My questions are does this sound right and what would you do?

The program I am working on just, on a basic level, takes products from one table from database1 and saves the products to a table on database2. However, the users have a lot of settings available to them for how they want the fields coming from database1 to look when they enter database2.

To Clarify: The set and get methods referenced above are not getter and setter methods. I use properties however I called them set because there is a lot of code that goes into formatting some of the fields prior to update. I understand the confusion and I apologize for not clarifying.

Answer 1

Maybe you should think about merging it back to one class, but in order to make it readable use partial modifier?

Another answer would be to create abstract class Product and inherit specialized classes from it.

Answer 2

The singleton for current product does sound bad. You're just calling a global variable by a different name.

I don't know what a Sku is, but as for the rest (Description and Images), if they're attributes of a product (which I think they are) they belong in the Product class.

If you're passing your "class pieces" around together a lot that is a strong sign that they belong together.

If you wish, separate the code (not the class) into several files by using the partial keyword. Like this:

// This file is Product.CodeAboutThingA.cs

public partial class Product
{
    // Some stuff related to A here...
}

And in another file:

// This file is Product.CodeAboutThingB.cs

public partial class Product
{
    // Some stuff related to B here...
}

Answer 3

To give my .5 cents, a class that can only be managed by splitting it into partials has quite some code smell. Separating the whole thing into several classes sounds good, especially when you already identified stuff like SKU etc. to be its own class.

Things you should ask yourself are...

• Is it OK if I can only access an SKU through a valid Product instance? Even if it is just an identifier, such an identifier may be quite complex in itself.
• In what way must the SKU use stuff from the Product class? If the product is the only one instantiating an SKU, it may be OK to pass the product into the SKU. The two classes are now coupled fairly tight, but still better than a single Product mess with no semantics.
• Can you identify what are the common parts that need to be shared throughout? Maybe you are missing an entity or a value object that is that "common part"?
• Maybe you would be happier with a Product Builder, instead of letting the Client rummage around the innards of a Product instance?

From my perspective, when you have a class with 1k+ lines of code, there is still a lot of understanding missing what your "Product" really is and how it behaves in the scope of your application...