Think in java note (1)

Think in java note (1)
I don't know what to do after work. Everything we should do is almost done. Let's take a look at spring's things. After all, these things are mostly used. But I want to take a look at javaee. There are many design patterns in it. After thinking for a while, I think these are nothing more than tools, and java is the foundation. I suddenly remembered think in java, which was recommended by my teacher in college. I read it once before, but I am confused. Now let's take a look at it again, combining my work and study experience, you may be able to get something different. (1) The access permissions for classes and members are written to the java class and members, including public, private, protected, and friendly. Not long ago, when writing a tool class in my work, when a model is used, an error will be reported regardless of the situation, prompting that this class does not exist. We recommend that you create a new class. When I thought that the editor had not encountered any problems, I checked the model class and found that the class was defined as this: class mymodel {....} this is the default friendly class, and my tool class is not in the same package, so the class cannot be accessed, thus an error is returned. (2) If we have to create another type to implement roughly the same functions After inheriting a data type, it will be very frustrating. However, if the existing data type can be used to "clone" it, and then add and modify it as needed, the situation would be much more satisfactory. "Inheritance" is designed for this purpose. But inheritance is not exactly equivalent to cloning. There are two ways to separate the new category class from the original base class. The first method is very simple: Add a new function for the functions class ). Although the extends keyword implies that we want to "scale" new features for the interface, this is not true. To differentiate our new classes, the second method is to change the behavior of an existing function in the base class. We call it the "improve" function. (3) upward Transformation () this thing has been confusing for a long time, mainly because it is used too little. In combination with the code in the book, I also wrote a section about Shape and Circle ). Copy the code package com. thinkinjava. unit1; public class Shape {public void move (Shape shape) {System. out. println (shape. getClass (). getName () + ", move... ");} public void draw (Shape shape) {System. out. println (shape. getClass (). getName () + ", draw .... ");} public void doStuff (Shape shape) {shape. move (shape); shape. draw (shape) ;}} copies the code, which specifies the general shape method. Write a Circle to inherit the Shape we just wrote: package com. thinkinjava. unit1; public class Circle extends Shape {}. Nothing is done, that is, a basic class (Shape) is derived ). Then write a main method: copy the code package com. thinkinjava. unit1; public class Main {public static void main (String [] args) {Circle circle = new Circle (); circle. doStuff (circle) ;}} copies the code to implement the upward transformation, which is what the book says: "The upward Styling ". Here, Circle = new circle () can be written as Shape Circle = new circle. However, the latter is easy to confuse. Running result: com. thinkinjava. unit1.Circle, move ...com. thinkinjava. unit1.Circle, draw .... this structure is very clear, that is, to pass the basic class type in the method, the input parameter type must be inherited from the basic class. To be honest, the application scenarios of this technology have never been used. As mentioned in the book, passing this basic class as the parameter type is to prevent passing in a specific subclass and re-write more subclass code. I hope you can understand the specific and more vivid application scenarios. Unless reposted, other articles are original articles and can be freely reproduced. However, please indicate the address of this article, please respect the author's Labor achievements.