Sora, for some specific stuations, that would work, and you could do that, especially if it's just something quick and dirty (aka, you can't be bothered to do it properly), you only have a few cases, and all the cases are known. But *even then*, I would still do it such that the functionality is grouped with the object (just as variables are) instead of spreading the logic around in the code.
I had a long piece of text written in response to this (which I started and deleted multiple times), and we can discuss further if you want and I could get into it, but before we get into "why modularization is good for your code", I thought I'd root out your interest.
(Remember that this is all a bit abstract - with writing code, as with many things in life, just because you can do something doesn't mean it's aesthetically pleasing or "correct" in the grander scheme of things... so it comes down to how much you care, really, in the end).
Basically, it's a choice between grouping your code up based on objects vs grouping your code based on operation.
Let's say you have four doors (A-D) and two operations, open and close. You need to write code to handle the product of that (open A, close A, open B, close B, etc). You can either group it by "open" and "close", where you have a single function that handles all the "open" cases for all objects, etc - or you can group by object, where you put all the code for each object with that object. It ends up being the same code; it's just a question of how it's organized.
Programming design (and, let me tell you, my own experience) says that it makes more sense, makes better code, and makes a happier programmer if you have each object manage its own affairs rather than grouping things by operation. In other words, it's better to have each object decide how to open and close itself rather than have monolithic "opener" and "closer" functions that need to know about all relevant objects. For one thing, it makes adding and removing objects much easier (consider touching one place - the object - rather than all the scattered places where the individual pieces are). And if you want a library that works with arbitrary objects (e.g. something like Quest), then you simply can't do it with a switch, as it means that rather than just adding new objects and having the code talk to them, the new pieces of logic would need to go into your library, adding your object handling into all these various places, and the idea of a library is that you shouldn't have to do that.
The rule of thumb I have arrived at after (*cough* too many) years programming is this: if you want to operate uniformly across a range of objects, then if you have to know what type an object is when you're using it, something is wrong. It's one of those big red flags. The idea is: you shouldn't have to know what type an object is - you just need to know how to talk to it. The object should manage its own affairs. The object sets the policy. The object holds the implementation. If you want to know how an object's function is implemented, you look in the object, not in some function grouping all these various implementations into one place.
Another thought: since you're basically organizing little snippets of code (open A, close A, open B, etc), by having functions with switches, you're actually writing more code, since rather than just invoking the function on the object, you actually have to have all this logic (the switch) to route the request to the right code. It's like, instead of handing a message to your co-worker sitting next to you for him to handle, you take and hand it to someone else (e.g. the "open function with switch) who reads it *on behalf of your co-worker*. And if you had a different message or request, you'd hand it to someone else again (e.g. the "close function with switch) who would, again, handle it for your co-worker. That's not exactly parallel, but somehow feels relevant.
That's probably a bunch of babble, and I apologize. I hope some of it makes sense.
