views:

122

answers:

5

The team is familiar with ASP.NET and has been working in VB.NET for several years, but they just haven't made the transition in thinking in terms of objects. In fact, they may be a little intimidated by OOP from brief glimpses they've seen of C++ and unmanaged environments. Work has kept them busy enough that they haven't had time to properly absorb the benefits that .NET and OOP provides.

I'm looking for some lightweight resources (i.e.: blog posts, articles) that I can share with both developers and/or managers which would help to introduce the object oriented paradigm in a nicely presented fashon. The language could be in either C# or VB.NET, though VB.NET would be preferred.

Thanks!

+4  A: 
Rap
There are several other books out there that are much more technical, and possibly more accurate, but I was looking for something that places an emphasis on connecting with the reader. After reading several reviews, this book appears to be the best place to start. Thanks!
Technobabble
A: 

Design Pattens

The book is actually pretty "lightweight" from the perspective of a single pattern.

Greg Mattes
+1  A: 

For OOP with VB...

Beginning Object-Oriented Programming with VB.Net

Object-Oriented Programming with Visual Basic .Net

Depending on how experienced one is you may want to also read about Object-Oriented Analysis and Design. These will help you to wrap your head around how to do it.

Head First Object-Oriented Analysis and Design

Object-Oriented Analysis and Design with Applications

MS article on OO in VB.Net:

http://msdn.microsoft.com/en-us/library/aa289512(VS.71).aspx

A little old but gives the basics....

It has been my experience that depending on how entrenched the team is on the event driven model will greatly influence how effective the team moves/embraces OO. It's easier than I would like to admit to just use objects in .Net and not really understand OO. Coming from VB6 it was too easy to keep on trucking the classic way. The OOA & OOD books may be a great starting point if your team seems to be just "users" of the objects in .Net versus actually creating classes in their own code.

klabranche
+4  A: 

Another approach that has worked spectacularly for me is to host an open-ended series of brown bag lunches. This is when you invite your coworkers (not demand) to a conference room where you discuss some aspect of OO.

Everyone brings their own lunch. And you can buy a pizza now and then to incent them to come, but you wouldn't do this every week.

Always have it the same place and the same time every week. You'll always talk briefly, no more than 30 minutes, leaving plenty of time for questions and discussion on how we use this in our company. Start on time and finish religiously on time.

Publish the schedule, emphasizing that they'll get the most out of it if they attend all sessions, but if they miss one, they can still catch on.

Here are some example topics:

  • OO for beginners.
  • Abstraction is the main thing; how to get there.
  • Encapsulation 101
  • Why inheritance?
  • Top 5 things we should use inheritance for here
  • Interfaces are way better than inheritance.
  • What are Design Patterns?
  • ... then drill down into the patterns that you'd use in real life.

I'm telling you, if you make these things interesting, you'll be amazed at how quickly your people will come up to speed.

Then, the best followup in the world is to implement Pair Programming and Friendly Code Walkthroughs. If you don't do one or both of these, the lessons will likely not stick.

Rap
I've been considering taking this route for some time, actually. Thanks for your input.
Technobabble
+1. Obviously a team worth their salt would already have been using design patterns, interfaces, abstraction, encapsulation etc in VB6 - you'd just need to explain inheritance and then tell them to only use it with extreme caution.
MarkJ
A: 

I've worked with VB developers of varying skills before (mostly from a VB6 background). Design Patterns might already require too much abstract thinking on their part.

If they're pretty savvy with business requirements, can I suggest a 'Naked Objects' type approach? This approach let's everyone visualise objects, encapsulation, inheritance, relationships and composition, and can ease the initial pain of OOAD. And you can use concrete examples from your business, instead of contrived examples from a book.

It's a long road - best of luck!

P.S. If you're interested, I provide a tool that supports the Naked Object pattern.

Vijay Patel