Advice for transitioning to object orient programming from VB 6 'style'

Question

I'm a vb.net developer in small IT department and I'm having trouble making the leap to programming exclusively with objects.

I understand the principles of OOP, design patterns, unit testing, etc, but when it comes to developing my applications, either my object design is poor, or I skip building with objects altogether. I know how to create unit tests, but don't have confidence in the ones I create.

I build almost exclusively data-driven data entry/reporting kind of apps. In most cases, much of the business logic is in the database in stored procedures and UDFs. I developer ASP.NET and Winforms applications to internal and external customers.

I've asked about small projects here on the Stack that I can look at to get an idea of good design and testing, but came up mostly short. I've read a bunch of books on design.

What are some good first steps toward breaking away from my old 'VB 6' ways?

Thanks!

Answer 1

A co-worker got me hooked on the book Domain Driven Design by Eric Evans. It really started to get me to move away from data driven development when nessasary.

Also getting involved in a .NET user group in your area will go along way in helping you find people who are more than willing to help you out.

Answer 2

1. Try to read code from projects that has been developed under OOP aproach.

2. Imagine how your code would looks like if you coding as the example that you are reading.

3. Be tough with your own code, try until you are satisfied and then when you read it after 3 months you'll find many other new things to improve it.

4. Remember the KISS rule, all the parts will fit as you still coding following the OOP principles.

5. Be disciplinated. It's easy to succumb to the old way but don't give up.

Remember Dijstra words: ...when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself "Dijkstra would not have liked this", well, that would be enough immortality for me.

He lives inside each of us =). And you have done the most important thing, you really want to learn how. That's the main obstacle with VB6 developers when they change to VB.NET.

• In VB6 it easier.
• In VB6 always works faster.
• It's the same thing...just looks better.
• VB6 has a lot more functions.

Looks familiar?

Answer 3

There are two things I'd recommend:

1. Look into UML class diagrams and play around with the class diagram tool in Visual Studio. The purpose of OOP is to make things more "conceptual" by thinking in terms of objects and, at least for me, class diagrams help to do that.
2. Read through some good design patterns, like the Decorator or Factory method pattern. Since most design patterns take full use of object-oriented design and also are usually well described, they can really help get the concepts down.

Answer 4

I was in your shoes a few years back. I remember reading an article that estimated you would spend anywhere from 6 months to a year just reading about object-oriented development before you would start to "get it".

I started by just trying to introduce objects in my day-to-day procedural programming. Then I tried getting as much processing out of the UI as I could. Then I tried creating "layers" for my business logic and data access. I understand a lot of your business logic may already be in the database but it wouldn't hurt to have a BL layer in place in case that changed. Right now it can pretty much function as a pass through.

I have Eric Evan's Domain-Driven Design still to read but a couple of books that have helped me are "The Object-Oriented Thought Process" and the one that I'm currently reading, "Microsoft .NET: Architecting Applications for the Enterprise". This book, while maybe more than you really need right now, is the first that has helped me really understand the layers and how to implement them.

Anyway, good luck with your journey. Just remember, it's going to be a process, not a destination!

Answer 5

In addition to the advice given in the other answers, you should ditch the VB.NET and learn C#.

It won't do everything for you, but it will help you get out of your old ways of thinking.

Answer 6

I hear ya, man. I too, live in your world. A world where business people demand reports. Complex reports. Reports which are easily built with complex stored procedures. In this world it is easy to think that the database is king and it drives the application. That line of thought leads to complex database TSQL code, views, functions, and stored procedures.

Certainly if it is truly a report you need then a complex sql statement may be the answer. However, you want to know how to break out of that data-driven world and enter an object oriented world.

I think typical OO design tutorials won't do you justice. Who cares if a dog is a type of an animal and a German Shepherd is a type of dog. That doesn't explain how you do business at your job. Furthermore that is only an example of OO inheritance. Other OO patterns such as composition and dependency injection are much more useful most of the time.

The way I think you should approach your next project or task is to forget about the database temporarily. Pretend that you live in a magical world where getting data from the database doesn't have to happen and writing data back to the database also doesn't have to occur. You live in a world where your objects are always populated with the right data. Model your objects first in that abstract world. After doing so, then (and only then) concern yourself with the messy implementation details of getting and writing to the database. The database is only there to persist your data. Your data is alive because you've already modeled it to fit within the rules of your domain.

Understanding UML will help tremendously for this type of modeling. Use UML designs first to model your domain. Then code to those designs. Then work them to fit within the constrains of your database.

Eric Evans "Domain Driven Design" is a great book which hammers this and many other related points home. He makes the point that domain modeling is THE crucial element to successfully modeling an application. He goes on to point out that object oriented design lends itself better to domain modeling than any other type of programming paradigm.

Good luck. Once you embrace the fully modeled, fully typed world of objects, you'll never want to parse another dataset again.