Design pattern for class with upwards of 100 properties

Viewed 4564

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.

16 Answers
Related