vb.net expert advice


(kinda long text, but please bare with me)

I'm kinda getting annoyed here.
So as a living, I work... like most of you guys I presume. Now in the mean time I also go to evening school where I try to learn vb.net. Problem was (what I noticed at the end) is that the first year was theoretical and procedural (our "teacher" was an analyst not a programmer for a living). During that time we almost never did exercises but just watched the screen instead.

Now suddenly after 1 year of procedural programming we take off with Object Oriented. I myself have a huge problem with a sudden chance, so am still stuck with how to write decent OO code.

I mean I know explanations on what overriding is, or what a inherit is, or even interfaces... but I dont know when to use em or sometimes why...

Also the thing about patterns... where can I find decent information? not only what they are, but also when to use em... or maybe the positive and negative sides.
What about the already existed Interfaces?
Should I maybe start from scratch? Is there maybe a decent vb.net OO book?

I mean, I can keep going on these questions... But I'm so angry at the school that after 2 years I still have problems getting a decent knowledge.

Who is Participating?
Mike TomlinsonConnect With a Mentor Middle School Assistant TeacherCommented:
"But I'm so angry at the school that after 2 years I still have problems getting a decent knowledge."

Let's get real...those coming out of college with a computer science degree really don't know squat about programming unless they had prior programming experience.  Yes...they actually learn some new concepts and write a few programs, but nothing that resembles "real world" projects.  Computer Science programs only teach you the basics of software development as it applies to the programming world in general.  Typically students will be "exposed" to 3 or 4 languages...tops.  You're not going to become proficient in any of these languages...think of it as an appetizer tray in a restaurant (just enough to sample but not fill you up).

To get any "real world" experience out of a college program would require that they pick a specific framework and a specific operating system/environment to target.  You would then need to build a sizable project over several semesters to get any experience out of it.  This is almost always frowned upon since then they would be catering to a specific scenario (language paired with an operating system) and students get bogged down in the details of making something work for just that scenario.  The "lessons" then get lost in the specifics and it's too complex for the average person to see the "big picture".

People coming out of college with a computer science degree basically have the foundations for programming...nothing more.  They have proven that they have the ability to "learn" by sticking with a degree program and finishing it.  It is up to the business that hires them to ensure they are given small enough projects, or just pieces of projects, that can be handled by someone still new to programming.  If you're lucky, you'll be paired up with a senior developer who's job is to "mentor" you and guide you along the way.

Real world programming skills are learned...in the real world.   =\
*Either in a job or on your own*
Jeff CertainCommented:
A couple comments. First off, the half-life of software knowledge runs about 4 years. So half of what you learn in an undergrad program is goign to be outdated by the time you get out. This is assuming that you're being taught the most recent material -- which isn't likely.

On the other hand... get used to it. In this field, you're going to be learning continually. Blunt, perhaps, but that's the reality.

Now, having said that, design patterns were formalized by the Gang of Four in a book called "Design Patterns." There's a series called "Head First" that includes both an OOP/OOA booka nd a design patterns book. The latter is very good; I haven't read the former yet.

As far as a .NET OO book, "Object Thinking" is a classic on how to wrap your head around objects. It's not a .NET book specifically. Deb Kurata's book "Doing Objects in Visual Basic .NET 2005" is a bit older, but solid. (I don't know if Deb wrote a 2008 version or not.)

Hopefully, this helps.
MutsopAuthor Commented:
K I do get the point that programming keeps evolving, but the problem is (after this experience over 2 years) they should have thought us OO from the beginning, not procedural programming.... and especially not theory without exercises.

As I said, it's the basic where I still have problems.

For example as of now we have a project to make, a "rent equipment" program... As of now we only need to create the business layer (nothing has been said about data nor UI). Now after a brief talk with my mentor, he told me to use the DAOFactory design.

He helped me with the basic setup and I was able to improve the layer and interaction between the classes. But without his help I wouldn't be able to come up with that idea, nor would I be able to actually make some facade part.

I mean I know how to use the design with examples, but am not sure how to create the base of it :(

Would it help with some online resources?

(as you might have noticed, we learned procedural programming in 1 year, OO in half a year and suddenly this project? :D Don't forget I have a fulltime job and this is evening school - So we don't have daily classes)
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Jeff CertainConnect With a Mentor Commented:

Universities and colleges really don't get it when it comes to teaching software development. You're likely to have taken a course that focused almost exclusively on syntax, and the problems they gave you were almost certainly trivial and contrived. Worse yet, they probably taught you how to use while loops, as an example, in a completely inappropriate way. It speaks highly of you that you recognize this.

As for writing "good OO code," the books I recommended would help. If you'd prefer something online, Robert C. Martin's "SOLID" acronym (see http://en.wikipedia.org/wiki/Solid_(object-oriented_design)) is a pretty good start for the things that you want to keep in your head.

Also, starting to do test-driven development (TDD) forces you down the correct path in some cases. At the very least, it keeps your methods cohesive and independent -- which makes it much easier to refactor when needed, if your objects weren't quite as tight as you need them.

As far as business layer, UI and data layer... that's really n-tier design (or architecture).
MutsopAuthor Commented:
Will check into these links! Thanks

@Chaosian Right to the point! :)
Will check into the SOLID design "patterns" later tonight. As for the TDD, that seems quite intuitive :)
So you start of with tests and build upon them till they pass.
Jeff CertainCommented:

Exactly. Red, green, refactor becomes your mantra. Make it break, make it pass, clean up the code. Although it's not the goal, this helps avoid some bad practices (global/class level variables being used to store object state inappropriately, for example).
MutsopAuthor Commented:
Forgot to ask,
what do you mean by: "As far as business layer, UI and data layer... that's really n-tier design (or architecture)."?
TSSTJeffConnect With a Mentor Commented:
I truly feel for you and have been in your position many years ago.  My solution became just part of life.  I write code everyday, and every week I pick something out of the fast list of objects that you can access from visual studio and teach myself how to use it.  With that said I am a veratious reader and text is almost as slow as cirriculum but it is still very possible to teach yourself how to program, patterns are a good start, but its like doing an oil change if you have never done it then you dont know and when you do you know that particular vechical.

In short do it your self think of a project you want to build or find something that is out on the web and try to build it.  In the beginnning it will be frusterating but eventualy with patients it will get easier.  Then at some point youll notice that you actually know something well.  For me my first big realization came with a mastery of Regular Expressions.  But, that was a project for work. Never the less, it was a success and I am askd to write them all the time now.

The pitfalls will be that there is so much wrong information on the web, examples that dont work, or an example in C# that wont convert to VB, and my favorite is an example that is so complex that you cant figure out what the programmer did.(Thanks Microsoft for console program examples).  But just have some faith and have a stab at it knowing what you know,  you are already in a good place for help.  And while on the path start with security it will save you so much time later.

Good Luck.
Jeff CertainCommented:
The separation of different concerns into different layers (often reflected as different projects) is referred to as an N-tier architecture. It isn't strictly OO per se, although it does end up helping to enforce separation of concerns.

The biggest benefit from N-tier architecture comes when you need to accomodate changing business needs. For example, your application may be a Windows Forms application... and then your boss' boss' boss decides you need to migrate it to the web. If you UI and business logic are separate, this becomes an exercise in writing only the web UI. (Leaving aside a few things like page lifecycles and state management that AJAX really helps with.) If your UI logic and your business logic aren't separate, this becomes and exercise in rewriting everything.

This is partly why the Model - View - View Model (MVVM) pattern has become so popular. It helps enforce these separations.
I agree totally with Chaosian N tier is a must to allow for adaptation for changing business needs.
MutsopAuthor Commented:
Sorry for the late response.

But how would you know then what kind of data model you should use?
For example: NHibernate, ADO.net, ... and if I'm correct there was something new last month but can't remember the name (something expression 4?)
Jeff CertainCommented:
Entity Framework 4 might be what you were thinking of.

That's pretty much the reason for N-tier architectures. The rest of the application should be independent of your data access, letting you use whatever data access technology you prefer.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.