Re^3: OO 2 death?

The "silly restrictions" referred to things like module length and using different classes for each day. Try as I might, I cannot see any valuable lesson being taught there. I am very well aware of the fact that a lesson to be taught may not be what would under other circumstances have been the optimal solution.

Pay attention: I am not critizing the teacher's choice of restrictions with respect to the problem at hand; I am questioning their worth as such. (Maybe I should have been clearer?)

I am in fact biased towards OO; I would tend to use it in projects that could be done without OO simply because solutions tend to stick around and grow, regardless of how short term they were planned, and I'd rather be working with organic growth in an OO approach than a procedural one.

Comment on Re^3: OO 2 death?

Replies are listed 'Best First'.
Re: Re: Re: Re: OO 2 death? by Fastolfe (Vicar) on Dec 08, 2001 at 05:53 UTC
I am not critizing the teacher's choice of restrictions with respect to the problem at hand; I am questioning their worth as such. Without knowing what the instructor's goals were with this assignment, I don't know how you can do that. What's a simple way of teaching someone inheritance? Or juggling a half-dozen different object types in an application? Or maybe methods for working with (identifying?) object types when said objects might be used interchangeably? This assignment could fit any of those. The original poster gave us his requirements, but never stated the goal of the exercise. And if I were teaching an entry-level object-oriented programming course, I would not want to wade through 50 pages of someone's crappy code. I've had CS instructors say, "This probably shouldn't take more than X lines of code to do," but rarely was a size limit strictly imposed, I will agree with that. But I can also see how some instructors might want to do that. That's just a personal decision. This length requirement really doesn't surprise me. But, alas, this is kind of getting off-topic. Yes, in the real world there are practical and design reasons you may or may not want to go with an OO design. But this isn't a real world: it's an exercise with an unknown goal. "Silly restrictions" should hardly be surprising.	[reply]

Replies are listed 'Best First'.

Re: Re: Re: Re: OO 2 death?
by Fastolfe (Vicar) on Dec 08, 2001 at 05:53 UTC

I am not critizing the teacher's choice of restrictions with respect to the problem at hand; I am questioning their worth as such.

Without knowing what the instructor's goals were with this assignment, I don't know how you can do that. What's a simple way of teaching someone inheritance? Or juggling a half-dozen different object types in an application? Or maybe methods for working with (identifying?) object types when said objects might be used interchangeably? This assignment could fit any of those. The original poster gave us his requirements, but never stated the goal of the exercise.

And if I were teaching an entry-level object-oriented programming course, I would not want to wade through 50 pages of someone's crappy code. I've had CS instructors say, "This probably shouldn't take more than X lines of code to do," but rarely was a size limit strictly imposed, I will agree with that. But I can also see how some instructors might want to do that. That's just a personal decision. This length requirement really doesn't surprise me.

But, alas, this is kind of getting off-topic. Yes, in the real world there are practical and design reasons you may or may not want to go with an OO design. But this isn't a real world: it's an exercise with an unknown goal. "Silly restrictions" should hardly be surprising.

[reply]