design rules

This article will be continuously improved.

1. Dependencies.  Dependencies are very important for both implementing and understanding of code.  A class needs help from other classes, and it is surely be needed by some other classes.  A natural but bad idea is to let these classes call each other.  If you program in this way, then your design is rotting.  Even you yourself cannot touch the code after some period and nobody wants to maintain your code or fix your bugs.  The way to avoid it is to use abstracts.  You need some help? OK, imagine what the help should be and write an abstract class.  If you always use this technology then your code will be easier to read and modify.

2. Classes.  Class is a bunch of code that servers as an employee that holding some properties and can do some minor jobs based on the properties.  If you want it to do something, you have to first give it the property.  Think of a truck driver.  Without a truck, the driver cannot send tons of products to places far away.  With the truck, the driver can do the job but even then the driver actually relies on the truck to do the job, the driver himself just takes care of the truck.  So this is a very different view according to structure programming.  When thinking in structure, you think about the hard problems that how to do the job.  When thinking OO, you think about if I have a property, what I would do.  It's a lot easier.  Defining classes is art.  It's usually helpful to have a mental model before defining classes.  If you are modelling a real system, then define major classes by separating the players.  After that you may want to define some process to be class, too.  And then you can modify the classes to meet OO principles.  It may take you several hours to write the code that can be finished in 10 minutes.  But when you are familiar with that, it will be easier.