I guess you didn't really want any feedback ....
You guess incorrectly. Frankie wants USEFUL feedback. The problem with your
feedback is that you are advocating "jumping into code" as an initial part
of the process of introducing experienced programmers, with procedural
programming experience, but little or no object-oriented programming
experience, and little or no knowledge of the HTTP web application
environment, to object-oriented and web application-oriented programming.
First, these people already know how to write code. They don't need code
examples to learn. What they lack is an understanding of the principles
involved in OOP and web application programming.
In the case of OOP, they need to re-adjust their thinking along OOP lines,
and that is quite a paradigm shift. It takes the concept of abstraction to a
whole new level. These people are used to thinking of an application as a
sequence of instructions. If they have used VB6, they may have had a small
taste of OOP concepts, such as classes and objects. If they have worked on
MainFrames, they have not. OOP is powerful, but only if you understand it
and can leverage its power. Why would one need a code example to illustrate
the concept of inheritance? I could illustrate it using any real-world
object, and the illustration would be both simpler and more appropriate, as
OOP teaches us to think in abstract, rather then concrete terms. An object
is not a set of instructions; it is a "thing." It is a "tool" which can be
"plugged into" an application, like plugging a speaker into a stereo system.
A swiss army knife inherits knife, in that it has a handle and a blade. But
it also has additional tools added to it, which extend its functionality.
Again, no code would make the concept clearer, only more complex to
understand. And OOP is all about hiding complexity. Which brings us to
encapsulation. Again, I could use a real-world example to illustrate the
concept much better than using code. Think about a car. It has an engine
which makes the car move. The engine is a complex device, full of complex
inner workings. But to use a car, you don't even need to know it HAS an
engine. All you need to know is the interface which the car presents to the
driver, i.e. the gas and brake pedals, and the ignition switch. As
abstraction is the final element in the concept, abstraction is best
illustrated WITH abstraction, such as talking about cars rather than code.
Again, with regards to web applications, the HTTP/HTML environment in which
an ASP.Net app runs, needs to be understood by these people. How would you
illustrate the Request/Response model, or the stateless nature of HTTP to a
group of people by having them write code, which they already know how to
do? I have often illustrated the stateless nature of HTTP as a pair of old
men with Alzheimers sitting on either side of a wall. Neither can remember
that last thing he said to the other, nor the last thing the other said to
him. They are passing notes back and forth to each other. The man on one
side (the "client" side) is requesting something from the man on the other
side (the "server" side). The man on the "server" side fetches it, and
passes it back to the man on the "client" side. Now the man on the client
side knows what he has, but decides he want to embellish it with something.
As the man on the "server" side doesn't remember what the man on the
"client" side requested last, the man on the "client" side must re-iterate
his request to the man on the "server" side, and add the embellishment to
his request. And so on.
In fact, I have often found that the "coding in the beginning" method is
actually more confusing. In the beginning, it is best to talk about
concepts, make sure the audience understands the concepts, and then begin
illustrating with code. Code is more about technique than about concept.
Code is the cart. Concept is the horse. The horse should always come before
the cart.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
I'd rather be a hammer than a nail.
