I’m reading a lot about good and bad practices in OOP design. It’s nice to know your design is bad, or good. But how do you get from bad to good design? I’ve split the interface (xaml) and codebehind from the main businesslogic class. That last class is growing big. I’ve tried splitting it up into smaller classes, but I’m stuck now. Any ideas on how to split large classes? The main class has 1 list of data of different types. I’m doing calculations on the total, but also on the individual types. I’ve got methods to perform these calculations which are called from events handled in the codebehind. Any ideas where to go from here?
Additional Info:
We are already about 6 months into this project. I’ve worked with object oriented laguages for years (first c++, java and now c#), but never on a large project like this one. I believe we’ve made some wrong turns in the beginning and I think we need to correct these. I can’t specify any details on this project at the moment. I’m going to order one or two books about design. If I separate all the classes, how do I stick them back together? Maybe it’s even better to continue this way to the first release and rebuilt parts after that, for a second release?
If there are a lot of computations based on the contents of the list have you considered moving operations into a customised list class? Same goes for the operations on the specific types, perhaps they could live inside the types?
In terms of performing similar yet different operations on different types consider using the state pattern (see this as a replacement for switch statements) which enables you to treat the entities in a uniform manner.
A lot of OOP is about throwing away a ‘top down’/micromanagement approach and considering a ‘bottom up’/self-sufficient approach. It’s worth remembering that neither approach is ‘correct’ in isolation. Creating maintainable code is about finding a sensible balance which requires a lot of thought and usually develops through experience.