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.
Generally true, but if the professor in this context was not a moron, he probably mentioned at the start of the class that he would be forcing a change to requirements part way through the course. Ideally, he would’ve specified what kind of changes this would be, in order for the students to account for that in their design. I think it’s likely this happened, but the student was lacking so much experience he didn’t understand that hint or what he needed to do in the design in order to later swap parameters more easily. I’m going to withhold judgement on this professor having only heard a biased account. It could’ve been a very good assignment, now being told from the perspective of a mediocre student.
Honestly, I liked the professor. When he had time to teach something he was clearly interested in, he did a great job of connecting. He didn’t get to teach us OOP though because there was a staffing emergency. The person we did get normally taught Hardware, so he was basically just reading aloud the textbook. Poor guy.
And you’re right, the professor did let us know that there was going to be a change of requirements partway through. But it wouldn’t be a good lesson if he told us what was going to change, although he did give some examples from previous times he’d taught the course.
A lot of people got burned when the change came. For my part I thought I did pretty okay, the refactor didn’t go perfectly but it was better than if I hadn’t been prepared. But I’ve also written a bunch of really gross objects that served no purpose just because they might change later. As anything is, it’s all about finding that happy medium
That’s a fair assessment. It’s kind of like the rule for premature optimization: don’t.
With experience you might get some intuition about when it’s good to lean into inheritance. We were definitely lacking experience at that point though.
OOP is a pretty powerful paradigm, which means it’s also easy to provide enough rope to hang yourself with. See also just about any other meme here about OOP
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.
Generally true, but if the professor in this context was not a moron, he probably mentioned at the start of the class that he would be forcing a change to requirements part way through the course. Ideally, he would’ve specified what kind of changes this would be, in order for the students to account for that in their design. I think it’s likely this happened, but the student was lacking so much experience he didn’t understand that hint or what he needed to do in the design in order to later swap parameters more easily. I’m going to withhold judgement on this professor having only heard a biased account. It could’ve been a very good assignment, now being told from the perspective of a mediocre student.
I wasn’t aware my mediocrity was on display. 😅
Honestly, I liked the professor. When he had time to teach something he was clearly interested in, he did a great job of connecting. He didn’t get to teach us OOP though because there was a staffing emergency. The person we did get normally taught Hardware, so he was basically just reading aloud the textbook. Poor guy.
And you’re right, the professor did let us know that there was going to be a change of requirements partway through. But it wouldn’t be a good lesson if he told us what was going to change, although he did give some examples from previous times he’d taught the course.
A lot of people got burned when the change came. For my part I thought I did pretty okay, the refactor didn’t go perfectly but it was better than if I hadn’t been prepared. But I’ve also written a bunch of really gross objects that served no purpose just because they might change later. As anything is, it’s all about finding that happy medium
That’s a fair assessment. It’s kind of like the rule for premature optimization: don’t.
With experience you might get some intuition about when it’s good to lean into inheritance. We were definitely lacking experience at that point though.
OOP is a pretty powerful paradigm, which means it’s also easy to provide enough rope to hang yourself with. See also just about any other meme here about OOP