I believe a class should be led much as a conductor leads an orchestra, rather than treated as an audience and performed for.
When designing a system, there is a natural tension between adding many features, so the user has a powerful tool set, and maintaining a clean, minimal design, so the user can learn to find and use the available features. In designing a course, this same pressure is evident: which content is important for students, and which needs to be trimmed? It is my observation that this balance is very difficult to get right: in trying to present only relevant information, many courses give students a very rigid look at the subject they teach. For example, in a standard Networks course, a student is introduced to the OSI stack, and told about the data link, network, and transport layers (and a little about the physical and application layers); this approach does not give the student any way to make sense of non-layer concepts such as MPLS or ATM in a more advanced class.
In teaching, my goal is to get the students comfortable with "playing" with the material, seeing it as a work in progress, and perhaps eventually contributing to research to shape it themselves. To achieve this, in addition to the actual information that the student needs to master, I try to bring in context: how and why a certain architecture developed, what the designers were trying to do, and so on. In teaching Networks, for example, in addition to the textbook (Kurose & Ross), I also introduce the principles behind their development (from Patterns in Network Architecture, by John Day) and war stories about their actual history (from Interconnections, by Radia Perlman). In Distributed Systems, I use a textbook (Verissimo & Rodriguez) which presents the process of system design by an architect, and add supplementary material to deal with the styles and principles tried in middleware (Krakowiak) and programming (Varela & Agha). I have not yet delivered the course on Operating Systems, but in helping design the course, I introduced a new textbook (by Anderson & Dahlin), suggested hands-on material (from Operating Systems: Three Easy Pieces, by Arpaci-Dusseau & Arpaci-Dusseau) and helped start a supplementary course on Systems Programming (based on Bryant & O'Hallaron).
My teaching style is simple: I co-opt the students in "performing" the class, so in fact my lectures are all discussion sections. For example, in classes such as Introduction to Programming, I pass out several wireless keyboard-touchpads (by Rapoo), which are all connected to the computer driving the display; these circulate around the class. Having set a problem, I then walk around helping as the students talk to each other and edit the code on the screen, trying to complete the whole working program (we use the online IDE, ideone.com). In more lecture-oriented classes, such as Distributed Systems, I have a team of students (a different team each day) prepare the lecture with me, and deliver it with me as well. Besides strong student approval, such a participative class keeps interest high â€“ the students "own" the class, so they feel free to play with the material and try out ideas; this has led to a dramatic improvement in the quality of class projects.