in reply to Re: OO 2 death?
in thread OO 2 death?

For one, undeniably, your teacher made silly restrictions and demands.

You assume that the point of the instructor's exercise was to build a web application in the most efficient way possible. What if the instructor was hoping to use this exercise as a means to teach some good OO design? Suddenly his requirement doesn't seem so silly after all... We don't know what languages the other students were working in, or whether or not all of them got to pick their language of choice. It's very possible the language of choice here just happens to be an OO language. If that's one of the goals of the course, I would expect to have to have that reflected in the languages the instructor would permit me to use.

Replies are listed 'Best First'.
Re: Re: Re: OO 2 death?
by Rhose (Priest) on Dec 07, 2001 at 18:55 UTC
    Thank you Fastolfe.

    I just found this thread and started reading the replies. I find it hard to believe that most people just assume there is no other motive behind this assignment. While it is very possible that the constraints placed on the project are just plain silly, there is also a reasonable chance that there are other lessons being taught.

    I have a close, talented friend who flunked out of Carnegie Mellon because he felt he could improve his projects and that his CS profs were "silly" with some of their assignments.

[reply]
      However... It's been quite a while since I've been in school, but one of the things that teachers should be teaching is at least the process of determining what the best solution is to a problem.

      It's entirely possible that the assignment was given to force the students to work with OO. But in that case, pick a problem that matches to an OO implementation and don't force busy work on a student just because that's what the lesson plan says.

      Now, I'm not saying that there aren't equally silly constraints out in The Real World™. However, those tend to be a different set of silly constraints from school. For example, it's entirely possible (in TRW) to be told that you have to use a particular language or environment because that's what the entire organization is using (or whatever). But "Do it in OO" is rarely one of the real-world constraints. "Make it reusable" may be, but OO-ness, in and of itself, rarely is.

      I'd be curious to hear back from the teacher in this instance as to why they put that set of contraints on the student / developer. That may be more instructive than anything else.

[reply]
        I have certainly seen "use OO" be a real-world constraint. That part was not what I thought was stupid. I can accept that an example to teach people how to use the OO mechanics had better be a problem they can understand easily with or without it. Particularly since a bit of blind flailing with OO can turn the simplest of problems into a mess.

        No, that wasn't what put me off. What put me off was restrictions like the ones described at Re: Re: OO 2 death?. A series of restrictions that struck me as seriously counter-productive. Is advice like, "Modules no more than 1.5 pages" or advice like, "Days of the week need to be separated for maintainability" any good? Not as far as I can see...

        That said, were I this highschool student, dealing with those restrictions, I would have chosen to program in Ruby. Why? Because Ruby's OO has fewer "moving parts" than Perl's does, making it somewhat more compact. Also the syntax looks cleaner to the uninitiated, which probably will go over better with a teacher who doesn't know the language...

[reply]
Re^3: OO 2 death?
by Aristotle (Chancellor) on Dec 08, 2001 at 05:29 UTC
    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.
[reply]

      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]

In Section Meditations