Object-Oriented Programming with Visual Basic .NET

3.9. Design Considerations

Many books that cover object-oriented design do not focus on any particular language. Some don't even contain one line of code, which shows that knowledge of object design can transcend whatever language you work with.

This chapter mentions several good and not-so-good programming practices, but this discussion is only an introduction to the topic. You should remember a few general rules that will get you started on the right track:

• Design a class from the user's perspective, not yours. Keep it as simple as possible.

• Limit scope as much as possible when dealing with classes, methods, and member data. Classes should expose as little as possible through their public interface. Public interfaces should have as few parameters as they can. Member data should always be Private. If it is not, think long and hard about why it isn't. Remember, changes to a class are easier to accommodate if information is hidden.

• Classes are nouns; methods are verbs. If you find yourself writing a class named Wash, you really might be writing a method that should be in Car.

• Methods imply behavior; properties imply state. Don't confuse the two concepts.

• Minimize interactions among classes to reduce complexity in the system.

• The first abstraction you come up with is probably not the best. If you get an abstraction wrong, you might end up coding yourself into a corner later on and be forced to punch holes in your once-beautiful object hierarchy.

• Whatever you do, be consistent. ...