hyrax: Module architecture used incorrectly
This is symptomatic of all the Hydra ruby stack, but we need to stop abusing the module pattern. That means more classes and more OO, less chains of include.
A module is designed to be a set of methods that get mixed-in to a consuming class without knowing anything about that class.
Ways to recognize a badly formed module:
- Is only
included once anywhere. Premature optimization: useconcerningor similar for structure. - Makes assumptions about consumers: contains calls to things not guaranteed to exist in an otherwise empty class.
- Directly defines Class-level variables: That is the domain of the class.
- Directly defines Instance-level variables: Again, the domain of the class.
- Untraceable logic due to dozens of modules-including-modules.
I realize rails is all-in on module magic, adding capabilities directly to Module to do things like define class-and-instance level accessors. These are also terrible for our purposes.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 16 (16 by maintainers)
Commits related to this issue
- Remove controller behavior modules This pattern was established in order to allow local applications to override the upstream gem classes. In ruby 2 we can do this using Module#prepend instead. I b... — committed to samvera/hyrax by jcoyne 7 years ago
- Remove controller behavior modules This pattern was established in order to allow local applications to override the upstream gem classes. In ruby 2 we can do this using Module#prepend instead. I b... — committed to samvera/hyrax by jcoyne 7 years ago
- Remove controller behavior modules This pattern was established in order to allow local applications to override the upstream gem classes. In ruby 2 we can do this using Module#prepend instead. I b... — committed to samvera/hyrax by jcoyne 7 years ago
- Remove controller behavior modules This pattern was established in order to allow local applications to override the upstream gem classes. In ruby 2 we can do this using Module#prepend instead. I b... — committed to samvera/hyrax by jcoyne 7 years ago
- Remove controller behavior modules This pattern was established in order to allow local applications to override the upstream gem classes. In ruby 2 we can do this using Module#prepend instead. I b... — committed to samvera/hyrax by jcoyne 7 years ago
- Remove controller behavior modules This pattern was established in order to allow local applications to override the upstream gem classes. In ruby 2 we can do this using Module#prepend instead. I b... — committed to samvera/hyrax by jcoyne 7 years ago
- Remove controller behavior modules This pattern was established in order to allow local applications to override the upstream gem classes. In ruby 2 we can do this using Module#prepend instead. I b... — committed to samvera/hyrax by jcoyne 7 years ago
- Remove controller behavior modules This pattern was established in order to allow local applications to override the upstream gem classes. In ruby 2 we can do this using Module#prepend instead. I b... — committed to samvera/hyrax by jcoyne 7 years ago
- Remove controller behavior modules This pattern was established in order to allow local applications to override the upstream gem classes. In ruby 2 we can do this using Module#prepend instead. I b... — committed to samvera/hyrax by jcoyne 7 years ago
I’m largely voting for top-down. I have questions about the architectural future of AF, and Hyrax has plenty of examples where we could just be okay with large classes (and refactor with delegation).