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

Pages: 1234
You can't pass a tower to a method expecting a Stack and expect it to work. Stacks and Towers aren't interchangeable, hence a Tower is not a Stack. Even if they were, there really isn't any benefit to inheriting from Stack as opposed to using a Stack in this case.

That's my opinion anyways, although I'd agree that there is at least logic behind that one.


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.


You can program using OO principles in almost any language (although I imagine it would be a bit hard to do with Turing programs - then again, what isn't), but there is a difference between languages actually supporting it and those that don't.
hanst wrote:
You can't pass a tower to a method expecting a Stack and expect it to work. Stacks and Towers aren't interchangeable, hence a Tower is not a Stack


+1 @ this.

For the "is a" relationship to really apply, anything you can do with the parent must also be able to be done with the child.

You cannot do everything with a tower that you can with a stack. Therefore it's (IMO) a poor use of inheritance.
Last edited on
My C++ book by D.S Malik has this for the Tower:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
#include <iostream>
using namespace std;

void moveDisks(int count, int needle1, int needle3, int needle2);

int main()
{
	int numDisks, need1, need2, need3;
	cout << "Enter the number of disks: "; 
	cin >> numDisks;
	cout << endl;
	
	moveDisks(numDisks, 1, 3, 2);
	
	return 0;
}

void moveDisks(int count, int needle1, int needle3, int needle2)
{
	if (count > 0)
	{
		moveDisks(count - 1, needle1, needle2, needle3);
		
		cout << "Move disk " << count << " from " << needle1
			<< " to " << needle3 << "." << endl;
		
		moveDisks(count - 1, needle2, needle3, needle1);
	}
}
Isn't that cheating?
How is it cheating?

Just because you can do an OO version of something doesn't mean you have to. Seems like doing an OO version of ToH would be overkill when you look at that code.
It doesn't actually solve ToH though, it just produces output that makes it look that way in a very clever fashion.

(Ok, that distinction may seem arbitrary, but that's what I'm thinking when I look at that code).
It does solve it though. If you has a ToH with 300 discs, the output of the above code would tell you how to solve the ToH unless the ToH I'm thinking of is not the one everyone else is talking about.
hanst99 wrote:
You can't pass a tower to a method expecting a Stack and expect it to work.
Disch wrote:
You cannot do everything with a tower that you can with a stack. Therefore it's (IMO) a poor use of inheritance.

I suppose I am missing something in your definition of a tower, then. The Towers of Hanoi problem is specifically stated over stacks of disks.

Also, the 'can do to parent' implies 'can do to child' is opinion, and not a logical truth, nor is it a syllogism.
But it implies that polymorphism can't be used, defeating the purpose of inheriting.

They are, loosely speaking, stacks of disks - but you can't put a larger disk on a smaller one, whereas a Stack normally doesn't consider what's the current top when something is pushed on it.
Oh I get it--you are encoding constraints into the tower that are properly part of the algorithm. I disagree with your methodology. You are mixing your functional constraints into your data. When your algorithm seeks to figure out which towers to target next, it shouldn't have to ask the data if it is OK with it. The Towers of Hanoi algorithm, in particular, is simple enough to make tracking that a waste.
It's not >>my<< methodology - it's how our prof set it up. I can't do anything about that. The towers are supposed to check rings that passed to them, and throw an exception if a user tries to put a larger on a smaller one. That's why I'm saying it's a silly solution.
The towers are supposed to check rings that passed to them, and throw an exception if a user tries to put a larger on a smaller one. That's why I'm saying it's a silly solution.


It throws an exception? That's hilarious. I think at this point you should just discard most of the BS that your professor seems to throw at you and get whatever you can out of your textbook if you have one. This does not, however, mean that you should give up on the "teachability," of programming. Whether or not your professor isn't a very good programmer, it's not worth saying "it is forbidden to teach good OO practices."

People have been complaining that CS degrees/programs are a waste of time for years, anyhow.
closed account (3hM2Nwbp)
50% joking, but CS professors seem to be the ones who couldn't cut it in real world development.

--

50% serious because it's true of every professor that I've known

50% joking because I've only known 12 or so professors.
Last edited on
I was teaching CS in college until I made it in the real world development.
I am the 50%.
I don't know about you guys, but I'm sick of the 50% screwing over the 50%. It's time we made a stand!

Down with the 50%!
We are the 50%!


It throws an exception? That's hilarious. I think at this point you should just discard most of the BS that your professor seems to throw at you and get whatever you can out of your textbook if you have one. This does not, however, mean that you should give up on the "teachability," of programming. Whether or not your professor isn't a very good programmer, it's not worth saying "it is forbidden to teach good OO practices."

People have been complaining that CS degrees/programs are a waste of time for years, anyhow.


I didn't go to uni to learn programming or good programming practices. I had several years of programming practice before I entered, so I don't think I'm going to learn much outside of real software projects anymore. What I did go there for was a getting a solid foundation on theoretical informatics.
That's why I'm going (hopefully) - I lack the mathematical and theoretical understanding. I'd probably get it eventually by myself but I may as well get a piece of paper (and hopefully, therefore, more chance of getting a job) out of it.
Introductory classes are invariably simplistic, focusing more on form than meaning. I wouldn't worry about it. You'll get some better instruction later.

You know a lot already. You could challenge some courses. (You still have to pay for them, but you don't have to waste time actually taking them -- you only need to pass the exams.)
Actually, no I can't. There are no courses I could challenge. I don't have to pay for them either, the only thing I'm paying for is ~100€ per semester for a local public transport ticket and money that goes to the student council (and a few other student organizations).
Pages: 1234