Most of my college coursework was around OOP. That said, they actually did a pretty lousy job of explaining it in a practical sense, so since we were left to figure it out ourselves a lot of our assignments ended up looking like this.
At the end of the program, our capstone project was to build a full stack app. They did a pretty good job simulating a real professional experience: we all worked together on requirements gathering and database design, then were expected to build our own app.
To really drive home the real world experience, the professor would change the requirements partway through the project. Which is a total dick move, but actually a good lesson on its own.
Anyway, this app was mostly about rendering a bunch of different views, and something subtly would change that ended up affecting all views. After the fact, the professor would say something to the effect of “If you used good objects, you’ll only have to make the change in one place.”
This of course is only helpful if you really appreciated the power of OOP and planned it from the start. Most of us were flying by the seat of our pants, so it was usually a ton of work to get those changes in
If you used good objects, you’ll only have to make the change in one place
IMO that’s generally a retroactive statement because in practice have to be lucky for that to be true. An abstraction along one dimension – even a good one, will limit flexibility in some other dimension.
Occasionally, everything comes into alignment and an opportunity appears to reliably-ish predict the correct abstraction the future will need.
Most every other time, you’re better off avoiding the possibility of the really costly bad abstraction by resisting the urge to abstract preemptively.
Most of my college coursework was around OOP. That said, they actually did a pretty lousy job of explaining it in a practical sense, so since we were left to figure it out ourselves a lot of our assignments ended up looking like this.
At the end of the program, our capstone project was to build a full stack app. They did a pretty good job simulating a real professional experience: we all worked together on requirements gathering and database design, then were expected to build our own app.
To really drive home the real world experience, the professor would change the requirements partway through the project. Which is a total dick move, but actually a good lesson on its own.
Anyway, this app was mostly about rendering a bunch of different views, and something subtly would change that ended up affecting all views. After the fact, the professor would say something to the effect of “If you used good objects, you’ll only have to make the change in one place.”
This of course is only helpful if you really appreciated the power of OOP and planned it from the start. Most of us were flying by the seat of our pants, so it was usually a ton of work to get those changes in
IMO that’s generally a retroactive statement because in practice have to be lucky for that to be true. An abstraction along one dimension – even a good one, will limit flexibility in some other dimension.
Occasionally, everything comes into alignment and an opportunity appears to reliably-ish predict the correct abstraction the future will need.
Most every other time, you’re better off avoiding the possibility of the really costly bad abstraction by resisting the urge to abstract preemptively.