The current implementation is leaking all over the place; everything but the kitchen sink is checking any Block's instance members, for numerous reasons. This is a significant code smell, and a clear violation, of encapsulation. The consequence is that the coupling between the Block class and the entire project is very, very tight, meaning we cannot make any sane changes without the entire project going kaput.
To add to the significant issue mentioned above, there's another problem that consistently appears throughout the project, which is that there are a ton of duplicate checks (if an imported material is in the materials list, for example) scattered throughout the project. This makes the situation even harder, since we have to keep checks that might be either redundant or integral to the regular operation of the program.
The first step to refactoring, not only the Block class, but all other components, should start at it's root:
Centralize & employ all checks that are integral to the program in our input fn/method/class/whatever.
everything else!
This issue is a generic one at that; it's here to reference when documenting logical structural changes i.e. the refactoring of the Block class.
The current implementation is leaking all over the place; everything but the kitchen sink is checking any Block's instance members, for numerous reasons. This is a significant code smell, and a clear violation, of encapsulation. The consequence is that the coupling between the Block class and the entire project is very, very tight, meaning we cannot make any sane changes without the entire project going kaput. To add to the significant issue mentioned above, there's another problem that consistently appears throughout the project, which is that there are a ton of duplicate checks (if an imported material is in the materials list, for example) scattered throughout the project. This makes the situation even harder, since we have to keep checks that might be either redundant or integral to the regular operation of the program. The first step to refactoring, not only the Block class, but all other components, should start at it's root:
This issue is a generic one at that; it's here to reference when documenting logical structural changes i.e. the refactoring of the Block class.