Good resources for Best OOP Practices?

[Mike_Le]

As my coworkers and I dip our toes into OOP, we're looking for best practices/guidelines to follow.

We already took the basic OOP course from NI and watched a few intro presentations.

What are some other guides, documents, or books people can recommend for solid OOP design practices? LabVIEW-specific guides are especially appreciated, as none of us have a strong CS background. But anything will help.

Thanks.

[johnsold]

Mike Le,

Although it has nothing to do with LabVIEW, Matt Weisfeld's The Object Oriented Thought Process is widely recommended.  The code examples are in text-based languages and some of the concepts are strange enough that it may take more than one reading to absorb. It is quite readable though.

Lynn

[crossrulz]

This might be a good place to start: Applying Common Object-Oriented (OO) Design Patterns to LabVIEW

[Mike_Le]

I'm becoming more familiar with different OO design patterns. In the last few months I've deployed the Actor Framework on a handful of small apps. But more than patterns, I'm looking for general guidelines about how OOP should be written and why.

As I go through a lot of the introductory LabVIEW OO material, I sometimes run into suggestions such as "Avoid excessive levels of inheritance" or "Write file data using objects, so casting is preserved even with version changes." These are the sort of things I'm looking to find compiled in one place. I'd like to have these written down in a list so that my coworkers and I can review them, and code with such guide posts in mind as we move forward.

[Mark_Yedinak]

Unfortunately there is a simple check list you can employ. OO programming is somewhat an art and there are many ways to solve the same problem. Some are obviously better than others but you can find multiple ways of doing the same thing. A few things to consider is that when using inheritance your child classes should always be more specific than it's predecessor. Avoid adding methods or class data to a parent which is only used by some of the children. Generally everything in the parent should apply equally to all children. Don't be scared off of using inheritance. It is quite powerful when used correctly. Prior to coding use something like UML to define your classes. It is generally easy to see if you are heading in the wrong direction when the classes are placed on paper and you see the relationships between objects and how they are used.If you find yourself repeating some functionality inside multiple classes you may want to consider creating a new class and create a HAS-A relationship between the classes. It is perfectly acceptable to have classes contain other classes. Speaking of HAS-A think about the relationship between classes. Identify the distinction between a HAS-A relationship and an IS-A relationship. IS-A will drvie your inheritance. HAS-A will build your library of reuseable code.

[Mike_Le]

Thanks, Mark. The kind of tips you listed are exactly the sort of things I'm looking for. Not necessarily a checklist or inflexible "rules/laws", but solid guidelines that we should keep in mind as we program.

[AKA_TG]

I found this book to be a excellent read.

Alan Shalloway is a good writer and explain OO in such a way that I could (finally) get it.

Design Patterns Explained: A New Perspective on Object-Oriented Design (2nd Edition)

http://www.amazon.com/Design-Patterns-Explained-Perspective-Object-Oriented/dp/0201715945