C# – Design pattern for class with upwards of 100 properties

cclass-designdesign-patternsoop

What advice/suggestions/guidance would you provide for designing a class that has upwards of 100 properties?

Background

  • The class describes an invoice. An invoice can have upwards of 100 attributes describing it, i.e. date, amount, code, etc…
  • The system we are submitting the invoice to uses each of the 100 attributes and is submitted as a single entity (as opposed to various parts being submitted at different times).
  • The attributes describing the invoice are required as part of the business process. The business process can not be changed.

Suggestions?

  • What have others done when faced with designing a class that has 100 attributes? i.e., create the class with each of the 100 properties?
  • Somehow break it up (if so, how)?
  • Or is this a fairly normal occurrence in your experience?

EDIT
After reading through some great responses and thinking about this further, I don't think there really is any single answer for this question. However, since we ended up modeling our design along the lines of LBrushkin's Answer I have given him credit. Albeit not the most popular answer, LBrushkin's answer helped push us into defining several interfaces which we aggregate and reuse throughout the application as well as a nudged us into investigating some patterns that may be helpful down the road.

Best Answer

I would imagine that some of these properties are probably related to each other. I would imagine that there are probably groups of properties that define independent facets of an Invoice that make sense as a group.

You may want to consider creating individual interfaces that model the different facets of an invoice. This may help define the methods and properties that operate on these facets in a more coherent, and easy to understand manner.

You can also choose to combine properties that having a particular meaning (addresses, locations, ranges, etc) into objects that you aggregate, rather than as individual properties of a single large class.

Keep in mind, that the abstraction you choose to model a problem and the abstraction you need in order to communicate with some other system (or business process) don't have to be the same. In fact, it's often productive to apply the bridge pattern to allow the separate abstractions to evolve independently.

Related Topic