Recently, I encountered difficulties in the process of learning the PHP5 interface. The book said it is a way to implement multiple inheritance, but I still don't know how to implement it. There is very little information on the PHP interface on the Internet, so I checked on Java. In fact, they are basically the same. After reading the article "Clarifying Java (Interfaces and Inheritance)", I suddenly realized that I had misunderstood it from the beginning. The so-called multiple inheritance refers to interfaces inheriting classes, not classes inheriting interfaces.
The article mentioned the abstraction of OO. Just like the sentence in the article - "Abstraction is to remove the image part", it is very vivid. When I thought about abstraction, I always thought it was difficult to understand. But abstraction, haha, it is easy to understand now. Yes, this is exactly what interfaces and abstract classes do.
There are many other points of view in the article that have benefited me a lot, as listed below:
The essence of OO, I think, is the abstraction of objects.
The function of the interface, in a nutshell, is to mark the type of class. Attributing different types of classes to different interfaces can better manage them.
The point of inheritance is also abstraction, not code reuse.
After reading this article, I now basically understand how to apply interfaces, abstract classes, and inheritance.
The original text is as follows:
Clarifying Java (Interfaces and Inheritance) My brother, a second-year graduate student in the School of Computer Science, discussed Java with me. When we met, several questions were all about interfaces. What is the use of interfaces? Why use interfaces? When should you use interfaces? I'm glad they didn't ask me how to connect to SQL Server using Java, or how to develop J2EE applications. Such questions are lethal and should be avoided. This year, the School of Computer Science has a graduation project project on J2ME. The students who chose this topic were still studying the java.util.* package with a grimace at the end of May, this and this... sigh.
Most people believe that the purpose of interfaces is to replace multiple inheritance. As we all know, Java does not have a multiple inheritance mechanism like C++, but it can implement multiple interfaces. In fact, this is far-fetched. Interfaces and inheritance are completely different things. Interfaces have no ability to replace multiple inheritance, and they have no such obligation. The function of the interface, in a nutshell, is to mark the type of class. Attributing different types of classes to different interfaces can better manage them. I think the essence of OO is the abstraction of objects, and the interface best embodies this. Why we discuss design patterns only for languages with abstract capabilities (such as c++, java, c#, etc.) is because what design patterns study is actually how to abstract reasonably. (Cowboy's famous saying is "Abstraction is to remove the image part", which seems to be a joke, but is actually true).
The most basic of the design patterns is the Factory pattern. In a very simple application I recently made, I wanted to try my best to make my program portable between multiple databases. Of course, this involves many issues, including how to Compatibility of SQL from different DBMS is a headache. We might as well simplify the problem first and only consider how to connect different databases.
Suppose I have many classes, namely Mysql.java, SQLServer.java, Oracle.java, and DB2.java. They connect to different databases respectively, return a Connection object uniformly, and all have a close method for closing the connection. You just need to select different classes for your DBMS, and you can use it. But what database will my user use? I don't know, what I hope is to modify the code as little as possible to meet his needs. I can abstract the following interface:
package org.bromon.test;
public interface DB
{
java.sql.Connection openDB(String url,String user,String password);
void close();
}
This interface only defines two methods without any meaningful code. The specific code is given by the class that implements 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)
{
//Code to connect to database}
public void close()
{
//Close database}
}
Similar ones are of course Oracle.java, etc. The interface DB classifies these classes. In the application, we define the object like this:
org.bromon.test.DB myDB;
use myDB to operate the database, and you don’t have to worry about it. Which class I'm actually using is what's called the "open-closed" principle. But the problem is that the interface cannot be instantiated, myDB=new DB(), such code is absolutely wrong, we can only myDB=new Mysql() or myDB=new Oracle(). Sorry, I still need to specify which class is to be instantiated. Using an 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 instantiation code becomes: myDB=DBFactory.getConn();
This is the most basic ordinary factory (Factory) among the 23 modes. The factory class is responsible for specifically instantiating which class, and other program logic operates on the DB interface. This is "programming for the interface". The responsibilities have been passed on to the factory class. Of course, you can also continue to define the factory interface and continue to throw the responsibilities up, which evolves into an abstract factory.
The interface is not responsible for any specific operations during the entire process. If other programs want to connect to the database, they only need to construct a DB object, regardless of how the factory class changes. This is what interfaces are about - abstraction.
Needless to say, the concept of inheritance is easy to understand. Why inherit? Because you want to reuse code? This is definitely not a reason. The point of inheritance is abstraction, not code reuse. If object A has a run() method, object B also wants to have this method, so someone uses Class B extends A. This is a mindless approach. If you instantiate A in B and call A's Run() method, can the same purpose be achieved? as follows:
Class B
{
A a=new A();
a.run();
}
This is to use the aggregation of classes to reuse code. It is the prototype of the delegation model and a practice that GoF has always advocated.
So what is the point of inheritance? In fact, this is caused by historical reasons. The original OO language only had inheritance and no interfaces, so abstraction could only be achieved through inheritance. Please note that the original intention of inheritance is abstraction, not code reuse (although inheritance also has this effect). This is one of the most serious mistakes of many bad Java books. I have not completely gotten rid of the shadow they have caused. Bad books are harmful to people, especially introductory books. They are too poisonous. When should you use inheritance? Only use it in abstract classes, try not to use it in other situations. Abstract classes cannot be instantiated. They only provide a template, which illustrates the problem.
The root of all evils in software development, especially among C++ programmers, are duplication of code instead of reuse of code, and misuse of inheritance. The purpose of banning multiple inheritance in Java is to stop the bad use of inheritance. It is a very wise approach, but many people do not understand it. Java can better reflect design, which is one of the reasons why I am fascinated.