programming:object_oriented_rules_of_thumb
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
programming:object_oriented_rules_of_thumb [2011/07/25 19:26] mjallison |
programming:object_oriented_rules_of_thumb [2012/10/10 16:47] (current) |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| Designing an implementing successful object oriented code is tough because of the variety of situations with which a programmer will find themselves. Often when a coder is trying to code a solution to a problem the question is asked, "what pattern should I use, or what object scheme should I use?" The answer invariably is "it depends". There are so many variables in any problem, there is generally not a single fit answer. This page is an attempt to capture more of the interesting ways of looking at problems. | Designing an implementing successful object oriented code is tough because of the variety of situations with which a programmer will find themselves. Often when a coder is trying to code a solution to a problem the question is asked, "what pattern should I use, or what object scheme should I use?" The answer invariably is "it depends". There are so many variables in any problem, there is generally not a single fit answer. This page is an attempt to capture more of the interesting ways of looking at problems. | ||
| + | |||
| + | ====== Goals ====== | ||
| ====== Red Flags ====== | ====== Red Flags ====== | ||
| Line 18: | Line 20: | ||
| * **Circular References** In order for objects to be useful and flexible, they need to be used in a wide variety of circumstances. Much like exposing implementation, or making a class knowlegable about it's callers implementation, circular dependencies between classes reduces this flexibility. When you have classes which are dependent upon one another, you can't use just a single class without using the other dependent classes. In general, keep your dependencies flowing in a single direction. Technically this would be called a Directed Acyclic Graph (DAG), in the class "type space". Note that this applies not only to two classes referring to each other, but to a series of classes which also form a cycle. In fact this becomes worse with more classes. | * **Circular References** In order for objects to be useful and flexible, they need to be used in a wide variety of circumstances. Much like exposing implementation, or making a class knowlegable about it's callers implementation, circular dependencies between classes reduces this flexibility. When you have classes which are dependent upon one another, you can't use just a single class without using the other dependent classes. In general, keep your dependencies flowing in a single direction. Technically this would be called a Directed Acyclic Graph (DAG), in the class "type space". Note that this applies not only to two classes referring to each other, but to a series of classes which also form a cycle. In fact this becomes worse with more classes. | ||
| + | |||
| + | * **Lying with code** We used to call them "side effects", methods that don't quite do what they advertise. You may have seen them, a method named "add" which does a subtraction, etc. Generally this is a bad thing with respect to all coding, not just OO. Here is an interesting example called "bait and switch" pattern (for the record, I don't quite recommend this...) [[http://thedailywtf.com/Articles/Representative-Property-MaxRetry.aspx]] or try this one [[http://thedailywtf.com/Articles/An-Enum-or-_2.aspx]] | ||
programming/object_oriented_rules_of_thumb.1311622019.txt.gz ยท Last modified: 2012/10/10 16:47 (external edit)
Page Tools
