Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restructure existing logical components #32

Open
gerelef opened this issue Dec 20, 2023 · 0 comments
Open

Restructure existing logical components #32

gerelef opened this issue Dec 20, 2023 · 0 comments

Comments

@gerelef
Copy link
Contributor

gerelef commented Dec 20, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant