General design guidelines/principles

[Nick K]

I know I will probably get beat up about this, but coming from a procedural background, my OOP just sucks :). My coding is reasonably effective, but I am missing the code reuse part of OOP, and the way to facilitate that. Are there any good axioms, or tutorials on how to build applications properly with multiple classes (when they should be static, when not), when to create another class and when to stuff everything in one class, or when to inherit? The Gang of Four book is a little over my head, and perhaps a bit abstract (yuk,yuk) for me. I just glazed over after about an hour of trying to understand what was going on. I have recently been working on a windows application, and have gotten in a little deep, and since I am not being paid a king's ransom and not under the gun to finish it right away and I would just like to write something on which I could build later.

[Guffa]

You will find several beginner level tutorials if you just search like this: search for "oop basics"[^] search for "oop tutorial"[^]

Despite everything, the person most likely to be fooling you next is yourself.

[Robert C Cartaino]

If you're at the point of understanding all the syntax of object-oriented programming but not how to put it all together, I would recommend this book: "Object Design: Roles, Responsibilities, and Collaborations" by Rebecca Wirfs-Brock & Alan McKean Amazon Link: http://www.amazon.com/exec/obidos/ASIN/0201379430[^] One of the reviewers says specifically, "This is definitely a book for beginning OO programmers, the ones who aren't sure how to assign functions to objects and who aren't ready for design patterns yet." I have to agree with that. If you're not sure about spending the $50 for a book, you can read parts of it in Google Books: http://books.google.com/books?id=vUF72vN5MY8C&printsec=frontcover&lr=&sig=NtmIoKGsusy7tur-JkjKXETeJaA#PPP1,M1[^] Enjoy, Robert C. Cartaino

[Mike Dimmick]

In my opinion, and a lot of others, code reuse is a real myth. You virtually never pick up a collection of objects wholesale and put them in a different project or product with no modifications because each project's requirements are different. I tend to stick to modularization with information-hiding for most objects. I only bother with inheritance when I have a real need for virtual functions, for example the GoF 'Strategy' pattern. Instead of defining one structure with a type-discrimination enumeration in, I'll write a base class (typically abstract) and one derived class per different implementation. If for some reason the classes already exist for information sharing/hiding reasons or just because that's what the Framework requires (e.g. a Form), I'll use an interface instead of a base class, but here you can't have a common base implementation, you have to actually implement the interface. If you're writing an application that has a lot of forms and you want them all to look similar - have certain controls in common that will always perform the same function (called visual inheritance) - you can make your own class that derives from Form and derive your forms from that (you have to edit the code to do this in Visual Studio, but once you do the designer can cope as long as the base form compiles correctly). I'm currently working on a project where the inheritance hierarchy goes:

System.Windows.Forms.Form
Company.ScreenManager.FormBase
Application.AppForm
Application.AppLogoForm
actual forms

FormBase adds a few virtual functions called by our 'screen manager', AppForm adds some base behaviours specific to this application, and AppLogoForm adds a logo to the form (some forms don't have the logo, but most are branded). This is a full-screen Compact Framework application; if it were necessary to have different contents on the desktop I'd have one Form containing a different UserControl for the different modes, with the control being swapped over when you switch modes.

DoEvents: Generating unexpected recursion since 1991

[Nick K]

Robert, Thanks for the advice (and describing my situation almost perfectly) :). I will certainly heed your advice, and I found a good piece of work by a fellow named Nirosh that I would recommend to others in the same situation. http://www.codeproject.com/KB/architecture/OOP\_Concepts\_and\_manymore.aspx?msg=2566566#xx2566566xx Thanks again, Nick K