How to teach object oriented programming to procedural programmers? [closed]

Question

I have been asked to begin teaching C# and OO concepts to a group of procedural programmers. I've searched for ideas on where to begin, but am looking for general consensus on topics to lead with in addition to topics to initially avoid.

Edit

I intend to present information in 30 minute installments weekly until it no longer makes sense to meet. These presentations are targeted at coworkers at a variety of skill levels from novice to expert.

Answer 1

The best thing you can do is: Have a ton of Q&A.

Wikipedia's procedural programming (PP) article really hits where you should start:

Whereas procedural programming uses procedures to operate on data structures, object-oriented programming bundles the two together so an "object" operates on its "own" data structure.

Once this is understood, I think a lot will fall into place.

In general

OOP is one of those things that can take time to "get," and each person takes their own path to get there. When writing in C#, it's not like the code screams, "I am using OO principles!" in every line. It's more of a subtle thing, like a foreach loop, or string concatenation.

Design center

Always use something (repeatedly) before making it.

First, use an object, and demonstrate the basic differences from PP. Like:

static void Main(string[] args) {     List<int> myList = new List<int>();      myList.Add(1);     myList.Add(7);     myList.Add(5);      myList.Sort();      for (int i = 0; i < myList.Count; i++)     {         Console.WriteLine(myList[i]);     } } 

Using objects (and other OO things) first -- before being forced to create their own -- leads people down the path of, "Ok, I'm making something like what I just used," rather than "WTF am I typing?"

Inheritance (it's a trap!)

I would NOT spend a lot of time on inheritance. I think it is a common pitfall for lessons to make a big deal about this (usually making a cliché animal hierarchy, as others pointed out). I think it's critical to know about inheritance, to understand how to use the .NET Framework, but its nuances aren't that big of a deal.

When I'm using .NET, I'm more likely to "run into inheritance" when I'm using the .NET Framework (i.e. "Does this control have a Content property?" or "I'll just call its ToString() method.") rather than when I'm creating my own class. Very (very (very)) rarely do I feel the need to make something mimicking the taxonomy structure of the animal kingdom.

Interfaces

Coding to an interface is a key mid-level concept. It's used everywhere, and OOP makes it easier. Examples of this are limitless. Building off the example I have above, one could demonstrate the IComparer<int> interface:

public int Compare(int x, int y) {     return y.CompareTo(x);  } 

Then, use it to change the sort order of the list, via myList.Sort(this). (After talking about this, of course.)

Best practices

Since there are some experienced developers in the group, one strategy in the mid-level classes would be to show how various best practices work in C#. Like, information hiding, the observer pattern, etc.

Have a ton of Q&A

Again, everyone learns slightly differently. I think the best thing you can do is have a ton of Q&A and encourage others in the group to have a discussion. People generally learn more when they're involved, and you have a good situation where that should be easier.