C #2.0 learning 4-advanced object-oriented concepts

C #2.0 learning 4-advanced object-oriented concepts

I. Interface

1. Concepts and functions of interfaces

An example: the main board and optical drive on a computer, in fact, for the main board, as long as the optical drive is in line with its specifications, the specific type of optical drive is not important, it is compatible. If I change an optical drive, there is no need to change the motherboard.

When we need a new object, we first consider whether we can define an object that is consistent with the original object function (compatible), instead of modifying the original object, or creating a new object.

For another example, how should we design a siud operation on data in a database system? Suppose our system cannot determine the specific database, or when the user requests to change to a new database, so should we redesign the entire data access layer and its related calls?

We define an interface:

Interface idataaccess

{

Public bool insert (item)

Public bool Delete (string ID)

Public bool Update (item)

Public list getdata ();

Public item getdatabyid (string ID );

}

If we use sqlserver

We define a class to implement the above interface.

Class sqldataacess: idataacess

{

// Specific SQL server operations

}

In the upper-Layer Program Calling, we can simply use the following method to call

Item = new item ();

Idataacess da = new sqldataaccess (); // if the application reflection is used, the object can be directly initialized from the configuration file without such hard encoding.

// Idataacess da = dataaccessfactory. createinstance (configration. getdatatype );

Da. insert (item );

 

Now, if you want to change to Oracle, what should you do?

Class oracledataacess: idataacess

{

// Specific oracleserver operations

}

Change the datatype in the configuration file to Oracle, and the entire system does not need to change other code.

For example:

 

2. interface features

In order to meet the changeable needs, we should program the interface, not the specific class programming.

Provide consistent program interfaces for programs with the same functions to facilitate plug-and-play.

Code implementation is in a specific class, rather than an interface, the interface only declares the functions of the program, not implemented

Ii. abstract classes

Similar to interfaces, but it can contain attributes or implement methods

 

Iii. Object-oriented Design Principles

1. Single Responsibility Principle (SRP ):

A class should have only one reason for its change.

2. Open and closed principle (OCP ):

Class modules should be extensible, but cannot be modified (open to extensions and closed to changes)

3. liskov replacement principle (LSP ):

Subclass must be able to replace their base classes

4. Dependency inversion principle (DIP ):

High-level modules should not depend on low-level modules, both of which should depend on abstraction.

Abstraction should not depend on implementation details, but on abstraction.

5. Interface isolation principle (ISP ):

Customer programs should not be forced to rely on methods they do not need.

Iv. Design Patterns and multi-State Applications

Polymorphism is widely used in many modes. For example, factory methods, policies, and template Modes

The so-called design pattern refers to a programming experience of the former.

The example of the above database system is applied to the factory method mode.

One product interface: idataaccess for consistent data operations

Two specific implementation classes: sqldataaccess and oracledataaccess are the implementation of specific database access.

One factory class: dataaccessfactory is used to generate different dataaccess policies for different configurations.

Demo (actor Program)

Mode used: factory Method

Application with Polymorphism