Fog Creek Software
Discussion Board

difficulty learning object orientated techniques


I am coding a web site in ASP.NET and VB.NET and I can already see the VB code becoming a bit spaghetti.

I am also trying to get a firm grasp of object orientated programming but I only have time to learn during the evenings. (no training available at work).

I am also the only programmer at my company so I do not have anyone else to learn from or bounce ideas off.

Perhaps I am being to hard on myself.

I know what object orientation is but I still having problems thinking in an object orientated way.

I have been a procedural programmer for the last 15 years and it is very hard to shake of the procedural approach having used basic, Foxpro, xbase++ and clipper.

How do others balance the learning side with having to code during the day and also how to force myself to start thinking objects?

Mike Grace
Thursday, March 28, 2002

this will be vague or brief, i gotta catch the train,,,,thought id throw in my 2 cents,,something better than nothing...More when I can give better examples and clearer thougts...

If you find yourself copying code anywhere, then you're doing something wrong.  Also, review the basic principals,  and see if they apply to your code.....

polymorphism, -  Does anything take as parameters 2 different objects, yet call similar methods on them?  if so, slap an interface on them as pass in the type interface, as opposed to 2 methods that take the specific object types.

interfaces , again a way to have different objects have the same method, so they can be referenced by the interface name, not their specific class name,

overloading, a method that takes various combinations of parameters...usuually, these will call each other, with various defaults added into the methods that have fewer params....constructors are a good example of this..

inheritance...shared behavior in different objects,,,or when an objects does something similar to another object,,,maybe different, or maybe more....a way to reuse functionality b/w objects,,,also, falls under the polymorphic idea, since you can reefer to the child class as the parent class,

Thursday, March 28, 2002

> How do others balance the learning side with having to code during the day and also how to force myself to start thinking objects?

Not about OO, but in answer to your question:

* Manage my manager, so that I have time in which to think while I'm at work

* Facination with the subject and an undemanding home-life, so that I have time to think about it while not at work

* A discussion group, a newsgroup, being part of an online community ... I'd ask questions, get answers, really think about the answers until I either had another question, or 'got it'

* It also helped that I was allowed at work to manage my own coding; it was at work that I made the transition from coding in C to coding in C++ ... you have to practice.

Christopher Wells
Thursday, March 28, 2002

Try "Doing Objects in VB" . There will probably be a .NET edition soon. It helped me separate the ideas from the machanics.
Also one that was very helpful is "Applying UML and patterns" for the same reasons.
Don't expect your first project to be magically OOP all at once. My first was mixed, but workable. The next was better. Keep working with the ideas.

Doug Withau
Thursday, March 28, 2002

Thank you all for your comments.

I agree, start slowly and build up.

Mike Grace
Thursday, March 28, 2002

As you have fox experience look at Visual Fox if you can rather than VB.  VF has a very clean class structure, in VB its an afterthought.

Simon Lucy
Thursday, March 28, 2002

I'd also like to recommend the book "Refactoring" by Martin Fowler. It has some valuable insight as to what to do when your code works, but doesn't feel right. The website has parts of the refactoring catalog online, but the book has examples which can help immensely.

It makes a good pair with "Design Patterns". Don't worry if some of this stuff goes over your head at first. It will start to click with your other learning, and "Refactoring" is a pretty easy read (I wouldn't recommend reading "Design Patterns" until you actually understand "Refactoring").

Good luck!

Brad Wilson
Thursday, March 28, 2002

Fight the man! Stick to procedural coding! (I guess I'm soon to be the last ansi C coder on the planet :)

Thursday, March 28, 2002

it took me a day to abstractly understand OOP-but about two months for it come naturally without having to juggle when abstract classes, interfaces and what not were appropriate.  now-i have think in OO terms even for short scripts before reminding myself that it's not appropriate for quick & dirty.

Razib Khan
Thursday, March 28, 2002

It might help to think in terms of modules rather than objects, or perhaps data structures with an API to manipulate the data contained therein.

I still do coding in ANSI C yet I approach it with an almost OOP style.  I have a module that manipulates URLs.  The interface looks something like:

typedef implementationdetails URL;
int UrlNew(URL *,char *);
int UrlType(URL);
int UrlCompare(URL,URL);
int UrlMakeString(URL,char *,size_t);
int UrlDup(URL *,URL);
int UrlOpen(URL,Buffer *,int);
int UrlFree(URL *);

And if I find I need to peek inside the URL (say, to get a host name), then I'd probably add a function for that.  The main problem with procedural languages is that they lack the syntactic surgar to make it easier to program with objects (or modules).  You'll notice it with the function names up there---they're all preceeded with “Url” and that's because of a lack in C (I also have other modules, like one that talks HTTP, and one that handles hash tables, and one to handle binary trees, but they all follow a similar structure to the URL example above).

Sean Conner
Thursday, March 28, 2002

One thing I dislike about C++ is that the private implemenation details of your classes MUST be exposed in your header files. There is no real information hiding. One change to your private data and other files that included your header must be recompiled, even though they don't/can't use your private data..

Banana Fred
Thursday, March 28, 2002

> typedef implementationdetails URL

You're absolutely right IMO, that ordinary C++ may be analogous to well-written C code, with a class corresponding to a module: C++ supports your programming with that type of structure. One of the extra C++ feature is its supporting abstract interfaces ... for example, you may like OracleURL and FoxBaseURL and HttpURL specializations of your basic URL, which all behave like basic URL objects, and which you can code without in any way rewriting your basic URL implementation.

> One thing I dislike about C++ is that the private implemenation details of your classes MUST be exposed in your header files.

Not QUITE necessarily ... for example, my public header file can contain nothing except pure virtual functions (so it defines only an abstract interface) ... or, it may contain no data except an opaque pointer to the class' private implementation data structure, where the implementation data structure is defined in the *.cpp file not in the *.h file (this is sometimes called the "Cheshire Cat" idiom). The book _Large Scale C++ Software Design_ by Lakos goes into private-implementation-hiding techniques in near-exhaustive detail.

> Fight the man! Stick to procedural coding! (I guess I'm soon to be the last ansi C coder on the planet :)

There's a lot of C code still out there.

Much of my programming is procedural (the other part is designing interfaces), for two reasons. First, every method is a procedure. Second, once you have your library of classes such as Screen and Database, you end up writing "transactions". A transaction typically touches (invokes methods of) many different classes, and therefore can be coded as a global routine, or a method of the Application class ... it's not a method of any other class. The thing about OO objects is that they enable this procedural programming, make it easier. For example:

void MyApplication::on_user_invoked_the_SAVE_command()
  try {
  WaitCursor wait_cursor( m_window );
  SerializedData data = m_document.get_serialized_data();
  File file( m_document.get_filename() );
  file.save_data( data );
  } catch ( exception& e ) {
  m_window.error_message_box( e.explanation() );

Christopher Wells
Friday, March 29, 2002

I agree with Doug Withau above, Kurata's book was my VB starting point and it worked for me.

Saturday, March 30, 2002

My turn to be contrary and NOT recommend Deborah Kurata's OO book for the original poster - who is working in VB.NET and ASP.NET. That particular book is VB6-centric, and although it will give you an intro to OO, the syntax it presents is NOT what you want to be learning for VB.NET.

Unfortunately, most of the first crop of .NET books are, to put it bluntly, lousy (this always happens when a new product releases; publishers push so hard on schedules that authors have no time to think, and must work from betas instead of release software). Dana Wyatt & Robert Oberg's INTRODUCTION TO VISUAL BASIC USING .NET (Prentice Hall PTR) has some good parts on OO in VB.NET, though if you're an experienced VB developer you may not get $45 of value from the rest of the book. The Cornell & Morrison PROGRAMMING VB.NET: A GUIDE FOR EXPERIENCED PROGRAMMERS (Apress) is good on syntax but light on any sort of conceptual framework; it was also out very early and so perhaps more inaccurate than some others.

DESIGN PATTERNS and REFACTORING (both mentioned earlier on this thread) may get you thinking in the right direction, but you may find it hard to implement their ideas in VB.NET without experience.

Finally, you might want to take a look at , an entire book about Design Patterns in C#. Not quite VB.NET, but at least .NET-oriented.

Mike Gunderloy
Saturday, March 30, 2002

Good point Mike , I did'nt think of that.

Saturday, March 30, 2002

Oh, and its object oriented, not orientated.

Monday, April 1, 2002

I think normal procedural coding allows one to just sit down and code.  But with OOP, I think the best recommendation is to sit down and design first, without touching the computer.

It's good to have the procedural background, no matter how painful it may seem to change.  You don't throw that all away; it's orthogonal to OOP.  Many beginners haven't learned the rules of writing functions, and are terrible coders.  The APIs are nice (since APIs are probably the main part of OOP), but it's just junk inside.

Jason Trelis
Tuesday, April 2, 2002

Thank you all for your postings. I have made bookmarks of the links and look forward to reading it all.

I am also thinking on jumping off and onto C#. I used to program in C a few years back and do actually prefer the syntax.

Regarding foxpro, its not part of .net though is it?

Mike Grace
Tuesday, April 2, 2002

I recommend Design Patterns Explained: A New Perspective on Object-Oriented Design.

It's a lot gentler than Design Patterns and may be a better stepping stone (if you're going to take things slowly).

The "new perspective on object-oriented design" features are really useful as they point out a lot of traps people fall into when they come across OO (eg. too much inheritance, thinking about implementation too soon).

Walter Rumsby
Wednesday, April 3, 2002

*  Recent Topics

*  Fog Creek Home