The principle of object-oriented design: open and closed

definition: Software entities (classes, modules, functions, etc.) should be extensible, but not modifiable. For extensions that are open, the changes are closed. The key is abstraction, which separates the common part of a feature from the Implementation Details section.

This requires us to write code with an abstract concept. What is abstraction. Refers to the thought process of extracting the concept from the entity. is to draw away from a multitude of objects a characteristic of common nature. In the process of writing code, need abstract class place, only need to grasp the essential function of this class, don't always think of it in this project specific function.
We continue to look at the open closure principle, which requires that the shared part of a function be clearly separated from the implementation part. Because you can't predict all the changes that are going to happen when you first set up the architecture, the class is not the same, and as you implement it in each module, you find that the abstract class works for this function, but not for another feature. So, do you want to go back and modify the abstract class? The price is huge, it needs to be thought over and adjusted to the specifics. If the program has not released some good, once the program released, then return to modify the abstract class, the impact will be greater. So in the beginning of the abstraction to prevent such a phenomenon occurs, to follow the open closure principle. Abstract class, interface is a standard, once defined in the program, it can not be easily modified, the demand has changed, how to do it. You can extend this interface, rewrite the methods, or add new methods after inheritance, but do not modify them.
Here are two examples to illustrate the open closure principle.
1, the connection database for example.
For example, different types of database connections used in programs, Access, and Oracle. The direct connection is as follows:

    Class connectaccess
    {public
        string connectstring ()
        {
            string datapath = "Database path";
            return string. Format ("Provider=Microsoft.Jet.OLEDB.4.0;Data source={0}; Persist Security info=true; Jet oledb:database Password={1} ", DataPath," password ");
        }
    Class Connectoracle
    {public
        string connectstring ()
        {return
            @ "server=localhost;database= namespace; uid= user name; pwd= password ";
        }
    }

Call

       static void Main (string[] args)
        {
            //Connect access
           connectaccess connaccess = new connectaccess ();

           OleDbConnection accessconnection = new OleDbConnection (Connaccess.connectstring ());

            Connect Oracle
           connectoracle connoracle = new Connectoracle ();

           OracleConnection oracleconnection = new OracleConnection (connoracle.connectstring ());
        }

So every time to consider the OleDbConnection parameters to use which. Here's a little bit of change. Abstract an interface.

    Interface Connectdatabase
    {
        string connectstring ();
    }

    Class Connectaccess:connectdatabase
    {
        #region connectdatabase member public

        string connectstring ()
        {
            string datapath = "Database path";

            return string. Format ("Provider=Microsoft.Jet.OLEDB.4.0;Data source={0}; Persist Security info=true; Jet oledb:database Password={1} ", DataPath," password ");
        }

        #endregion
    }

    class Connectoracle:connectdatabase
    {
        #region connectdatabase member

        public String ConnectString ()
        {return
            @ "server=localhost;database= namespace; uid= user name; pwd= password";
        }

        #endregion
    }

Call

        static void Main (string[] args)
        {
            Connectdatabase conn = null;

            Connect access
            conn = new connectaccess ();

            OleDbConnection accessconnection = new OleDbConnection (Conn. ConnectString ());

            Connect Oracle
            conn = new connectoracle ();

            OracleConnection oracleconnection = new OracleConnection (conn. ConnectString ());
        }

After the reform, just care about the conn with which class instantiation, it is OK. However, as you may see, because Oracle connections must be oracleconnection, the advantages may not be easily seen. You can refer to the example of a strategy model (http://blog.csdn.net/yysyangyangyangshan/article/details/6955065).
2, the basic type as an example of method parameters.
This is why general design principles emphasize method parameters as much as possible to avoid basic types. The following two method definitions are compared:

        Define 1  
        bool Connect (string userName, string password, string wifiaddress, int port)
        {return
            false;
        }

        Define 2  
        bool Connect
        {return
            false;
        }

    public class account
    {public
        string UserName
        {get
            ;
            Set;
        }
        public string Password
        {get
            ;
            Set;
        }
        public string wifiaddress
        {get
            ;
            Set;
        }
        public int Port
        {get
            ;
            Set;
        }
    }

By comparison, definition 2 has more than one definition of the account class, and the Connect () method is significantly more stable. If the Connect () method changes wifiaddress, definition 1 must modify the interface of the method, and all objects calling the Connect () method will be affected, while the definition 2 only needs to modify the account class, because the interface of the Connect () method remains unchanged , while the caller of the Connect () method does not need to be wifiaddress, such modifications do not affect the caller at all, thus reducing the impact of changes in requirements.
In short, the open closure principle is the most critical of the abstract, but it is not said that once the abstract interface, class determination must not be modified. Just, we in the abstract time to think comprehensively, strive to do without modification, once the demand has changed, just in the implementation of the time there are changes. Of course, demand is ever-changing, and once you need to change the parts of abstraction, the impact will be much smaller as long as the rules are followed strictly. Of course, if you do, you have to do unit testing, where you need to test the correct.