• Forum
  • Lounge
  • Is there some universal law that forbids

 
Is there some universal law that forbids educators from teaching decent OO practices?

Pages: 1234
I can forgive deriving Circles and Squares from a Shape class because at least at first it sounds sensible, and it some contexts it even is. But when you then proceed to derive a Ring class for the towers of Hanoi from that same geometric (!) Circle class (and the towers themselves from a Stack) you have crossed the line. Twice.

I know that it's sometimes hard to come up with good and simple examples that aren't too abstract for a beginner, but that's no excuse for shoehorning 'extends' (we're primarily using Java at my university) anywhere you can (or can't) and then calling the resulting abomination "object oriented".
What's the problem?
I once saw a Towers of Hanoi puzzle that used square plates and poles instead of circular. :P

I fully agree with you that what happened there was a bit iffy because the base class has too radically different a purpose from the derived class. Thinking about programming objects for the purpose of modeling real-world objects is only a good idea to a degree.

However, deriving the poles for the towers from a LIFO container doesn't seem all that unreasonable to me. Why do you think it is?

-Albatross
Last edited on
Because a Tower is not a Stack. It can be implemented using a Stack, but the behavior is different (e.g. a Stack doesn't care what kind of value is pushed onto it, a Hanoi Tower does). But I agree that the Stack thing isn't as gruesome.

What's the problem?


A ring for a 'Towers of Hanoi' game isn't a Circle (in the geometric sense). There is no reason for it to be either.
Last edited on
Quality of education is poor across the board, when it comes to programming (C++ is particularly terrible, but perhaps it's just my familiarity bias).

I think it's worse than education in other technical fields for at least two reasons: the field is too recent: teaching it like math or chemistry, with 50-100 year lag, just doesn't work; and the industry doesn't expect junior hires to know anything.
Well, I personally don't really believe in the teachability (is that a word?) of programming anyways, but it still kinda bugs me.
I personally don't really believe in the teachability (is that a word?) of programming

Is your problem with programming classes, programming books, both, or something else entirely? I'll absolutely agree that the best way to improve at programming is just to program, but how do you think people can learn to program without some starting point? Sure the Towers of Hanoi example is not a very good use of OOP, but it just shows that whoever was teaching the course is a bad programmer.

I don't mean to come off as rude or insulting, but I'd like to hear some ideas of your own on how you think OO principles should be explained.
I never said that you couldn't explain programming. What I meant was that there is no course you could visit or book you could read after which you'd be a programmer. I found the courses I visited so far pretty worthless for learning programming (admittedly, they weren't actually programming courses. The sentiment that programming can't be learned by listening to lectures is apparently shared by our profs).

Obviously, at the beginning you need some instructions where to start on later on you will still always need documentations, but the only thing that actually teaches you programming is experience. It's a bit like with math - you can visit courses to pick up some general techniques or 'recipes' for specific problems, but what makes you a mathematician in the end is the ability to 'think the right way'.
I'm not sure I agree with that. Clearly math can be taught and you can apply it in innovative ways and not be a mathematician.

Programming is much simpler than tertiary level math and is a technology, applicable to a very specific domain.

In my experience, many teachers are less knowledgeable than professionals in their respective subject areas, but that's not restricted to programming. Teaching itself is a specialized skill that that experts on Programing or Chemistry ... don't necessarily have.
Last edited on
Well problem is that most beginner OO things show base class Shape, derived class Square, Circle, etc. It may not be so much bad OO, but rather poor explanation after the fact. If all you have as a basis of OO is Shape and Circle/Square/etc. Then it goes even further, some force OO just to show it in whatever situation they can.
The more experience I have gained has led me to appreciate OOP in a slightly different sense than just modelling objects using "is a" relationships. Particularly within the context of C++, I prefer to think of classes as black-boxes. If runtime polymorphism isn't required I would also tend to avoid inheritance. They have specific inputs and should have deterministic outputs. This also happens to make unit testing much more simple.

The fact that inheritance is introducing tight coupling is much more disturbing than the logical "this isn't a that".
@Cubbi
I think it's worse than education in other technical fields for at least two reasons: the field is too recent: teaching it like math or chemistry, with 50-100 year lag, just doesn't work; and the industry doesn't expect junior hires to know anything.


I think the main difference here is that Math & Chemistry doesn't go out of date, and the parts that are taught in 99,9% of classes were already known 50~100 years ago.

C++, and programming in general, changes more rapidly and stuff from 20years back is not just out of date, but often detrimental.

That being said, a "Towers of Hanoi" game that uses a geometric circle class is still as redundant as it was 100 years ago (how old is OOP anyway?).

@moorecm
I prefer to think of classes as black-boxes.

That's exactly how I feel about it! I've struggled with "OOP-ing" my code for a long time, because "it just didn't make sense to make a class out of this". Until I realized that a class doesn't have to simulate a real-world object. I've been much happier ever since.


@OP:
A friend of mine recently came to me saying "I need help with my C++ class". I was a bit scared at first, but upon seeing his first piece of code, I was very relieved: no system calls, no C-style strings and I even spotted a typedef or two. I'm eager to see if the rest of their course is any decent.
Sadly, I am not confident in my programming and OOP is my weak point. I understand inheritance and composition in classes, but I truly suck at figuring out what things I should have in a class and such. I'll eventually get it figured out, but til then I just avoid them or try to keep them simple when possible.
OOP isn't the only reason to use a class.

The Class should be used with anything that requires initialisation and release. These tend to be called Abstract Data Types, and is not necessarily OOP.
Same thing for me, to be honest. I "got the hang of it" because nearly all my projects have the same basic structure, thus converging to a certain design was more a matter of time than understanding.

Still, I feel like I've had that first "breakthrough" in the way I write code, and things will go slightly easier in the future.
The Class should be used with anything that requires initialisation and release. These tend to be called Abstract Data Types, and is not necessarily OOP.

I'm aware of the ADT in regards to class. Though, if the class isn't necessarily OOP, then why is it that most C++ books and tutorials only introduce class in the OOP sections? Not meaning to be a smart ass, but that popped into my head when I read that.

@Gaminic: I've still not had that "breakthrough" for the advanced things, mainly in part that I can never think of anything to code that would push me to learn more things. I find I keep doing projects that just keep using what I already know. Last few projects I've picked were so advanced I was totally lost. I still consider myself a beginner in C++ because of this fact.
I want to express a radical view on Object oriented programming.
Let me cite Wikipedia's first paragraph on Object oriented programming:



Object-oriented programming (OOP) is a programming paradigm using "objects" – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs. Programming techniques may include features such as data abstraction, encapsulation, messaging, modularity, polymorphism, and inheritance. Many modern programming languages now support OOP, at least as an option.


Let me dissect this paragraph:

Programming techniques may include features such as data abstraction, encapsulation, messaging, modularity, polymorphism, and inheritance.


Very well, this is what every programmer should have in mind as valid techniques. These techniques can and should be used, if appropriate, in any programming language, including assembly.

Many modern programming languages now support OOP, at least as an option.
Which programming language *does not* support OOP? Assembly surely allows for clean and beautiful implementation of "data abstraction, encapsulation, messaging, modularity, polymorphism, and inheritance".

***
Here is my radical opinion on OOP: oop is a term made to advertise certain teaching practices, and promote certain, more or less arbitrarily chosen, programming languages and programming features. The main purpose of OOP is to serve, directly or indirectly, the benefit of the teachers.

Those techniques might actually be good as a side effect, but their *primary* goal is to sell the book/programming language of the particular preacher that teaches it.
Last edited on
Sorry to weigh-in so late, but I have an issue with the OP (original post/premise):

The towers are stacks.
BTW, if you want to see what OOP looks like in C, check out the OpenMotif source.
Which programming language *does not* support OOP? Assembly surely allows for clean and beautiful implementation of "data abstraction, encapsulation, messaging, modularity, polymorphism, and inheritance".


"Allows for" and "supports" are not synonymous. I hope you're not seriously asserting that assembly has direct language support for any of the features you listed.
Pages: 1234