PHP interface Learning

I recently encountered difficulties in learning the Php5 interface. It is a method to implement multiple inheritance, but I still don't know how to implement it. I found very little information about the PHP interface on the internet, and I checked the java interface. In fact, it is almost the same. After reading the article "clarifying Java (interfaces and inheritance)", I suddenly realized that it was wrong at the beginning.

I recently encountered difficulties in learning the Php5 interface. It is a method to implement multiple inheritance, but I still don't know how to implement it. I found very little information about the PHP interface on the internet, and I checked the java interface. In fact, it is almost the same. After reading the article "clarifying Java (interfaces and inheritance)", I suddenly realized that it was wrong at the beginning.

I recently encountered difficulties in learning the Php5 interface. It is a method to implement multiple inheritance, but I still don't know how to implement it. I found very little information about the PHP interface on the internet, and I checked the java interface. In fact, it is almost the same. After reading the article "clarifying Java (interfaces and inheritance)", I suddenly realized that I had an incorrect understanding at the beginning. The so-called multi-Inheritance refers to the interface inheritance class, not the class inheritance interface.
The article mentions the OO abstraction, just as the sentence in the article -- "abstraction is the part of the image", which is very image. It is always hard to understand and abstract in the past, haha, now it's easy to understand. This is exactly what interfaces and abstract classes need to do.
I also benefited from many points in the article, as listed below:
The essence of OO, I think, is the abstraction of objects.
The function of an interface, in a word, is the type of class ). You can better manage different types of classes by assigning them to different interfaces.
The significance of inheritance also lies in abstraction, rather than code reuse.
After reading this article, I have basically understood how to apply interfaces, abstract classes, and inheritance.

The original article is as follows:
Clarify that the brother of Java (interface and inheritance) Emy of computer science discussed Java with me. When I met, I asked a few questions about interfaces. What is the use of interfaces? Why use interfaces? When should I use the interface? Fortunately, they didn't ask me how Java connects to SQL Server, or how to develop J2EE applications. This type of problem is lethal. This year, I graduated from the Computer Science Institute with a design subject of j2-based. At the end of May, the students who chose this subject were still studying java. util. *. This package ...... Alas.

Most people think that the meaning of an interface is to replace multiple inheritance. As we all know, Java does not have the multi-Inheritance Mechanism like c ++, but it can implement multiple interfaces. In fact, this is very far-fetched. interfaces and inheritance are completely different. Interfaces do not have the ability to replace multiple inheritance, and they do not have this obligation. The function of an interface, in a word, is the type of class ). You can better manage different types of classes by assigning them to different interfaces. The essence of OO, I think, is the abstraction of objects, the interface that best reflects this point is. Why do we discuss that the design patterns are only for languages with abstract capabilities (such as c ++, java, and c #) because the design patterns are studied, it is actually how to reasonably abstract. (Cowboy's famous saying is that "abstraction is the part of image extraction". It seems ridiculous, but it is actually the most reasonable ).

The most basic design pattern is the Factory pattern. In a very simple application recently, I want to try to port my program among multiple databases. Of course, this involves many problems. It is a headache to be compatible with the SQL statements of different DBMS. We may want to simplify the problem and only consider how to connect to different databases.

Suppose I have many classes, namely Mysql. java, SQLServer. java, Oracle. java and DB2.java connect to different databases, and return a Connection object in a unified manner. They all have a close method to close the Connection. You only need to select different classes for your DBMS. But what database does my user use? I don't know. I want to modify the code as little as possible to meet his needs. I can abstract the following interfaces:
Package org. bromon. test;
Public interface DB. 310-083
{
Java. SQL. Connection openDB (String url, String user, String password );
Void close ();
}

This interface only defines two methods without any actual code. The specific code is provided by the class implementing this interface, such as Mysql. java:

Package org. bromon. test;
Import java. SQL .*;
Public class Mysql implements DB
{
Private String url = "jdbc: mysql: localhost: 3306/test ";
Private String user = "root ";
Private String password = "";
Private Connection conn;
Public Connection openDB (url, user, password)
{
// Database connection code
}

Public void close ()
{
// Close the database
}
}

Similar to Oracle. java, and so on, the interface DB gives these classes a class. In the application, we define the object as follows:

Org. bromon. test. DB myDB;

When using myDB to operate databases, you don't have to worry about which class I actually use. This is the so-called "Open-Close" principle. However, the problem is that the interface cannot be instantiated. myDB = new DB (). Such code is absolutely incorrect. We can only use myDB = new Mysql () or myDB = new Oracle (). The problem is that I still need to specify the class to be instantiated, and the interface is useless. So we need a factory:

Package org. bromon. test;
Public class DBFactory
{
Public static DB Connection getConn ()
{
Return (new Mysql ());
}
}

So the instantiated code becomes: myDB = DBFactory. getConn ();
This is the most basic Factory in the 23 modes. The Factory class is responsible for instantiating which class, and other program logic is to operate on the DB interface, this is "programming for interfaces ". Responsibility has been shirked to the Factory class. Of course, you can continue to define the Factory interface and continue to throw the responsibility, which will evolve into Abstract Factory ).

The interface is not responsible for any specific operation throughout the process, other programs to connect to the database, you only need to construct a DB object is OK, MB3-530 regardless of how the factory class changes. This is the meaning of the interface ---- abstraction.

It is easy to understand the concept of inheritance. Why inherit? Because you want to reuse the code? This is definitely not a reason. The significance of inheritance also lies in abstraction, rather than code reuse. If object A has A run () method, object B also wants this method, HP0-729 PW0-300 so someone has Class B extends. This is a brainless approach. If we instantiate A in B and call the Run () method of A, can we achieve the same purpose? As follows:
Class B
{
A a = new ();
A. run ();
}

This refers to the reuse of Code by means of class aggregation, the prototype of the delegation mode, and the practice consistently advocated by GoF.

So what is the significance of inheritance? In fact, this is caused by historical reasons. In the beginning, the OO language only had inheritance and no interfaces, so it was only allowed to implement abstraction by inheritance. Please note that the inheritance was originally intended to be abstract, rather than code reuse (although inheritance also plays this role), this is one of the most serious errors of many bad Java books. The shadows they have caused have not been completely removed yet, bad books are harmful, especially entry-level books. The traffic is too high. When should I use inheritance? It is used only in abstract classes, and should not be used in other cases. Abstract classes cannot be instantiated. They only provide a template, which can be used to illustrate the problem.

The source of all evil in software development is repeated code rather than code reuse. Second, bad inheritance, especially for c ++ programmers. It is wise to ban multi-inheritance in Java to stop the use of inheritance, but many people do not understand it. Java can better reflect the design, which is one of the reasons why I am fascinated.

Source: http://www.phpweblog.net/wgxjava/archive/2008/06/11/5026.html