Existence in dao is interface
What exists in dao.impl is the specific implementation (class) of the interface
As for the benefits, check the definition of the interface.
Updated. . . .
Give me an example
There is
in dao
public interface UserDAO {
public List getUser();
}
dao.imple in
public class JdbcUserDao implements UserDAO{
@Override
public List getUser() {
//do sth.
return null;
}
}
One day in the future, when you need to use hibernate to operate the database.
Just write a HibernateUserDao to implement UserDAO.
Interfaces define specifications. Doesn't care about the specific implementation. I have a summary of various Java keywords on my github. The description of the design of the interface is:
Interface serves as a window for the system to interact with the outside world, and interface embodiment is a specification. For the implementer of the interface, the interface stipulates what services the implementer must provide to the outside world (provided in the form of methods); for the interface caller
In general, the interface specifies which services the caller can call and how to call these services (that is, how to call methods). When an interface is used in a program, the interface is a coupling standard between multiple modules; when multiple
When used between applications, the interface is a communication standard between multiple programs.
To a certain extent, the interface type is the "general outline" of the entire system. It sets the standards that each module between systems should follow. Therefore, the interfaces in a system should not change frequently. Once the interface is changed, the entire system
Even the impact on other systems will be radiating, causing most classes in the system to need to be rewritten.
@zaz @reeco @finallygo is talking about the advantages of interface-oriented programming. There is no need to doubt these contents.
But based on personal experience, I feel that this is a design solution that can be compromised as appropriate. The author has been working on some small projects, and sometimes I have used some design patterns. However, the design mentioned by the question seems to do more harm than good for small projects. There are too many layers of code, and there are many more. Useful interface code, and the interface does not play its due role in programming. For example, as @zaz said, a UserDao interface can have several different implementations. However, when the project is small, in this case, use is still relatively small. Moreover, since the questioner can ask this kind of question, I think there should be very few places where the dao layer interface is used in the subject's project.
Interface-oriented programming is a design idea. Personally, I feel that all design ideas should be alive and should not be copied and used directly. Developers should first understand this idea, and then check whether the program needs to use this design. If it is not necessary, even an excellent design will not make much sense to the program.
List<Integer> list = new ArrayList<Integer>();
List<Integer> list = new LinkedList<Integer>();
........
There are a lot of such designs in Java API. As for why, I suggest that the author take a look at interface-oriented programming in design patterns. The benefits sound hollow and can only be realized after you have started 1 or 2 projects. Some experiences and insights must be experienced before they can be gained.
One is abstract and the other is concrete
Normally, the interface should be designed from the beginning and cannot be modified at will. If you modify it frequently, you first need to consider whether the dao layer has been considered sufficiently
The reason why there is an interface layer is for better isolation. The simplest example is if you need to unit test the service layer, but do not want you to perform actual operations on the dao layer (maybe the conditions do not allow it) , at this time you may need to mock a dao for testing, and the advantages of the interface will be reflected
Separating the dao and service layers is required for program decoupling. This can reduce the degree of program coupling and allow the minimal modification of the program code when replacing different dao and different services. In addition, the relationship between dao and impl is the relationship between specification and implementation. If the specification changes, the implementation must change, but not necessarily vice versa. For the sake of program decoupling, this is still acceptable. Otherwise, frameworks like spring would be so popular.
In fact, it is decoupling. For example, if you have a dao, dao.impl is a MYSQL implementation. Later, there is a demand to change it to Oracle implementation. You only need to modify dao.impl to implement Oracle. No need Modify dao and use dao
What I said above is very good. From my own experience, in small projects, it really does more harm than good. If the project is complex, multiple people are working together, and the requirements are highly variable, it is still very useful. The main reason is the isolation of the interface, which can decouple the association between modules.
dao and daoiml embody two ideas.
One is layering. Why do we need to layer? What problems does layering solve for us? What are the advantages and disadvantages of layering? See my blog for details: http://www.inter12.org/archives/396
The second is dependency inversion and abstract isolation in OO design principles. To be more specific, there are two points:
1. High-level modules should not depend on low-level modules, both should depend on abstractions
2. Abstraction should not depend on details, details should depend on abstraction
The advantage is high cohesion and low coupling, these two poorly used words! !
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Existence in dao is interface
What exists in dao.impl is the specific implementation (class) of the interface
As for the benefits, check the definition of the interface.
Updated. . . .
Give me an example
There is
in daodao.imple in
One day in the future, when you need to use hibernate to operate the database.
Just write a HibernateUserDao to implement UserDAO.
Interfaces define specifications. Doesn't care about the specific implementation.
I have a summary of various Java keywords on my github. The description of the design of the interface is:
@zaz @reeco @finallygo is talking about the advantages of interface-oriented programming. There is no need to doubt these contents.
But based on personal experience, I feel that this is a design solution that can be compromised as appropriate. The author has been working on some small projects, and sometimes I have used some design patterns. However, the design mentioned by the question seems to do more harm than good for small projects. There are too many layers of code, and there are many more. Useful interface code, and the interface does not play its due role in programming. For example, as @zaz said, a UserDao interface can have several different implementations. However, when the project is small, in this case, use is still relatively small. Moreover, since the questioner can ask this kind of question, I think there should be very few places where the dao layer interface is used in the subject's project.
Interface-oriented programming is a design idea. Personally, I feel that all design ideas should be alive and should not be copied and used directly. Developers should first understand this idea, and then check whether the program needs to use this design. If it is not necessary, even an excellent design will not make much sense to the program.
There are a lot of such designs in Java API. As for why, I suggest that the author take a look at interface-oriented programming in design patterns. The benefits sound hollow and can only be realized after you have started 1 or 2 projects. Some experiences and insights must be experienced before they can be gained.
One is abstract and the other is concrete
Normally, the interface should be designed from the beginning and cannot be modified at will. If you modify it frequently, you first need to consider whether the dao layer has been considered sufficiently
The reason why there is an interface layer is for better isolation. The simplest example is if you need to unit test the service layer, but do not want you to perform actual operations on the dao layer (maybe the conditions do not allow it) , at this time you may need to mock a dao for testing, and the advantages of the interface will be reflected
Separating the dao and service layers is required for program decoupling. This can reduce the degree of program coupling and allow the minimal modification of the program code when replacing different dao and different services. In addition, the relationship between dao and impl is the relationship between specification and implementation. If the specification changes, the implementation must change, but not necessarily vice versa. For the sake of program decoupling, this is still acceptable. Otherwise, frameworks like spring would be so popular.
In fact, it is decoupling. For example, if you have a dao, dao.impl is a MYSQL implementation. Later, there is a demand to change it to Oracle implementation. You only need to modify dao.impl to implement Oracle. No need Modify dao and use dao
To put it simply, for convenience, use Strategy mode to replace the implementation
What I said above is very good. From my own experience, in small projects, it really does more harm than good. If the project is complex, multiple people are working together, and the requirements are highly variable, it is still very useful. The main reason is the isolation of the interface, which can decouple the association between modules.
dao and daoiml embody two ideas.
One is layering. Why do we need to layer? What problems does layering solve for us? What are the advantages and disadvantages of layering? See my blog for details: http://www.inter12.org/archives/396
The second is dependency inversion and abstract isolation in OO design principles. To be more specific, there are two points:
1. High-level modules should not depend on low-level modules, both should depend on abstractions
2. Abstraction should not depend on details, details should depend on abstraction
The advantage is high cohesion and low coupling, these two poorly used words! !
If there is no need to replace the database, it is actually okay to remove it