6. — Graham Lee
When you get overly attached to MVC, then
you look at every class you create and ask the
question “is this a model, a view, or a
controller?”. Because this question makes no
sense, the answer doesn’t either: anything that
isn’t evidently data or evidently graphics gets
put into the amorphous “controller” collection,
which eventually sucks your entire codebase
into its innards like a black hole collapsing
under its own weight.
7. — Graham Lee
When you get overly attached to MVC, then
you look at every class you create and ask the
question “is this a model, a view, or a
controller?”. Because this question makes no
sense, the answer doesn’t either: anything that
isn’t evidently data or evidently graphics gets
put into the amorphous “controller” collection,
which eventually sucks your entire codebase
into its innards like a black hole collapsing
under its own weight.
8. — Graham Lee
When you get overly attached to MVC, then
you look at every class you create and ask the
question “is this a model, a view, or a
controller?”. Because this question makes no
sense, the answer doesn’t either: anything that
isn’t evidently data or evidently graphics gets
put into the amorphous “controller” collection,
which eventually sucks your entire codebase
into its innards like a black hole collapsing
under its own weight.
54. 1. View controllers are isolated
2. View controllers are reusable
3. Every task is encapsulated
55. 1. View controllers are isolated
2. View controllers are reusable
3. Every task is encapsulated
4. Display-binding is separate from side effects
56. 1. View controllers are isolated
2. View controllers are reusable
3. Every task is encapsulated
4. Display-binding is separate from side effects
5. Coordinators are fully in your control