9th Chapter Interface
"Confirm that the interface is an ideal choice, so you should always select an interface rather than a specific class." "This is actually a lure. Of course, for creating a class, almost at any moment, it can be replaced by creating an interface and a factory.
Many people fall into the trap of temptation to create interfaces and factories whenever possible. This logic looks as if you need to use a different specific implementation, so you should always add this abstraction. This has actually turned out to be a sloppy design optimization.
Any abstraction should be the result of a genuine need. When necessary, you should refactor the interface instead of adding additional levels of indirection everywhere, resulting in additional complexity. This extra complexity is significant if you let someone deal with this complexity simply because you realize that by just being in case you've added a new interface, and there's no other compelling reason for it, well, if I run into this kind of thing, then I'm going to question all the designs that this person has done.
The appropriate principle should be to select a class rather than an interface. Start with the class, and refactor if the necessary interface becomes very clear. Interfaces are an important tool, but they are easy to misuse. 10th Chapter Inner Class
An inner class automatically has access to all members of its perimeter class.
An object of an inner class can only be created if the object of its outer class is associated (the inner class is non-static).
When an inner class is transformed upward into its base class, especially when transformed into an interface, the inner class-----the implementation of an interface-----can be completely invisible and unavailable. All you get is a reference to the base class or interface, so it's convenient to hide the implementation details. 10.7 Nested Classes
If you do not need a connection between the inner class object and its perimeter class, you can declare the inner class as static. This is often referred to as a nested class. The ordinary inner class object implicitly holds a reference to the outer class object that created it. However, when the inner class is static, it means:
1 to create an object of a nested class, you do not need an object of its outer class.
2 Cannot access the Outer class object of a non-static class from within the object of the nested class.
There is another difference between a nested class and an ordinary inner class. The fields and methods of the normal inner class can only be placed on the outer level of the class, so ordinary inner classes cannot have static data and static fields, nor can they contain nested classes. But nested classes can contain all of these things.
Normally, you cannot place any code inside an interface, but a nested class can be part of an interface. Any class you put into the interface is automatically public and static. Because the class is static, it simply places the nested class within the interface's namespace, which does not violate the rules of the interface. 10.8 Why internal classes are needed
The most compelling reason to use an inner class is that each inner class can inherit independently from an implementation of an (interface), so no matter whether the outer class has inherited an implementation of an (interface), it has no effect on the inner class.
The interface solves some of the problems, while the inner class effectively implements multiple inheritance. That is, an inner class allows you to inherit multiple non-interface types (classes or abstract classes).
If you don't need to solve the problem of multiple inheritance, then naturally you can encode it in a different way without using an inner class. However, if you use an inner class, you can also get some other features:
1 The inner class can have multiple instances, each with its own state information, and the information of its peripheral class objects is independent of each other.
2 in a single perimeter class, you can have multiple inner classes implement the same interface in different ways, or inherit the same class.
3 The time to create an internal class object does not depend on the creation of the outer class object.
4 The inner class does not have a confusing "is-a" relationship; it is an independent entity.