Use decorators and interface segregation to solve overgrowing models problem
Summary:
Using decorators to segregate interfaces and improve testability may be a good solution for overgrowing models - https://gitlab.com/gitlab-org/gitlab-ce/issues/13484#note_3972945
Original issue:
According to this discussion, we can try moving build implementation to separate concerns, which can have some benefits.
Reasoning behind this:
- We have less implementation in a single file - it is easier to browse it
- We have semantically coherent implementation in separate files - it is easier to find elements related to each other, for a given feature (like implementation that supports build erase only)
- We can exercise concerns inside separate tests - it is easier to maintain main model spec suites
- We can easily remove a feature if we decide so
- In some case we prevent merge conflicts between CE -> EE, as EE only features can go to concerns and it is only one common line between CE and EE in a model, also specs become separate files
- If we decide that this implementation belongs somewhere else it is then easier to move it to different place
- We improve maintainability of our models
- We make contribution barrier lower, model with 1000+ is difficult to understand, and as long as we keep our concerns separated and coherent, it is easier to understand what is going on (however I think that using composition instead of mixins/inheritance would be better here, see commit comments above, mixins are more idiomatic)
- We are able to introduce a starting point for structure/architecture.
@ayufan, @DouweM, @rspeicher what do you think about it?