[JAVA] Continuation: The parable of OOP (omitted)

It's hot

I wrote this article before, but after a long time, the trend is in OOP material. ~~ It's burning ~~ Isn't it burning hot? So, think a little more from that As a result of organizing, the abstract classes and interfaces that I think of Like this! I would like to express the idea. My thoughts are It is a statement that this is the case. Thinking is Java-like.

What is an interface?

Java's Runnable interface is easy to understand, but represents the functionality you want to implement When it comes to the steering wheel (the image of a car steering wheel, basket handle, or doorknob) thinking. In terms of the Runnable interface

--An interface that expresses the method you want to implement as a thread --Thread implementation is different for each request, so you can implement it as you like.

It provides a very convenient function. The implemented class is Interface functionality is expected to be guaranteed without anyone knowing So the implementer is free to implement the interface and the user is the method It can be used by focusing only on the function of.

It is impossible to implement such a function in reality, but as a means of expressing meaning Then consider the interface of a car steering wheel.

CarHandle.java


public interface CarHandle
{
    int turnRight(int angle); //Returns the angle after execution
    int turnLeft(int angle);
    void hold();
    void release(); //Let go of the handle and let it move naturally
}

The CarHandle interface represents the function of a car steering wheel. Therefore, it doesn't matter what kind of vehicle the Concrete object is mounted on. According to the characteristics of objects such as light cars, sedans, and one-boxes The implementer may implement the behavior of the interface.

Also, the implementation destination Concrete object has a CarHandle interface. It is also good to take the form of receiving the implemented handle object. You don't have to know what the characteristics of the handle are, but the interface expresses The function to do is implemented.

Manufacturer genuine handle object with CarHandle interface Or, I'll customize itMomoste Object! Fun things like Will be created.

So what is an abstract class?

In a word, I think this is a semi-finished kit part. For example. The same age as me (Speaking of people who get stuck) Some people may be enthusiastic about homebrew PCs. Case, power supply, mother, by yourself I bought a CPU, HDD, memory module, and GPU in parts, and I like it. Assembling and operating a performance and cost performance PC is just that It was an exciting play.

And time goes by, and BTO makers are crowded. Buyer's order details on the web It will deliver a PC customized to your liking in the form of a finished product. But in the shop Therefore, the contents that can be customized vary, and the specifications are not ideal. Sometimes I didn't choose that shop.

Well (although it was a long introduction) there is a BTO shop that sells PCs as semi-finished products It finally appeared (assuming it doesn't really exist). From the purchaser Parts that are less important to look at (cases, mothers, HDDs, etc.) are decent Specs can be selected and important core parts (CPU, GPU, memory module) Is a shop that sells PCs with dummies. Of course, of the kit parts Does not work in the state (cannot be instantiated).

Therefore, the purchaser (implementer) bought the core parts (kit parts class). CPU is Core i9, GPU is GeForce RTX, memory is 8GB DDR4 You can make a PC like this with 4 cards and 32GB.

AbstractPC.java


public abstract class AbstractPC
{
    public int case()  //Since the case is selected by BTO, it is already implemented
    {
        //I don't think it's case processing
    }
    public int powerUnit() //Since the power supply is selected by BTO, it is already mounted
    {
        //I don't think it's power processing
    }
    public int motherBoard() //Mother is already implemented because it is selected by BTO
    {
        //I don't think it's a mother's process
    }
    abstract int cpu(int model_no); //I buy the CPU myself
    abstract int gpu(int model_no); //Buy your own GPU
    abstract int memory(int model_no, int nums); //Buy RAM yourself
}

Inherit this guy and buy (implement) CPU, GPU, memory module By doing so, you can make it on both a super cospa PC and a high-end PC. Strictly high performance When making a PC, there are details such as power supply capacity and heat exhaust efficiency of the case, but I will not think about it for the time being.

In terms of the advantages and convenience of the Abstract class, it has already been fixed. Implement only the framework part that is not easily affected by specification changes even if implemented However, the processing that you want to respond to changes is customized according to the adaptation area. I think that it can meet the demands such as wanting to implement it.

To be honest, abstract classes are more useful than the convenience of the interface. I have the impression that it is difficult and infrequently used. Still partially implemented The convenience of being able to optimally implement only the core part is valuable.

by the way···

I searched a lot while I was there, but in a typical theory of evolution I can't help despair because I'm crazy about people who are addicted to it. No, I understand the feeling that I want to explain in evolution. But like a dog or a cat, Whether you implement or inherit an object that doesn't provide any service I don't know what is convenient. I can't feel the meaning of making it.

To be clear, it is ** "not transmitted" **. It ’s an interface, it ’s an abstract class. You get yourself programming to explain a little intricate concept I can't tell what the profit is. I don't think so.

Therefore, if you explain with the intention of giving a lecture to a third party, from the standpoint of the other party ** If you don't create the impression that "Yes, you can do such a convenient thing" ** This is the second lecture in Japan. Impression is deeply engraved in memory.

Recommended Posts

Continuation: The parable of OOP (omitted)
The world of clara-rules (2)
Judgment of the calendar
The world of clara-rules (4)
The world of clara-rules (1)
The world of clara-rules (3)
The world of clara-rules (5)
The idea of quicksort
The idea of jQuery
About the handling of Null
Docker monitoring-explaining the basics of basics-
About the description of Docker-compose.yml
Understand the basics of docker
The play of instantiating java.lang.Void
Explanation of the FizzBuzz problem
The basics of Swift's TableView
Median of the three values
The illusion of object orientation
Switch the version of bundler