Thread가 추상 클래스가 아니고 start ()가 final이 아닌 이유는 무엇입니까?

Thread가 추상 클래스가 아니고 start ()가 final이 아닌 이유는 무엇입니까?

---

클래스가 메서드가 추상 인 추상 클래스가 Thread아닌 일반 클래스로 구현 된 이유는 무엇입니까?run()

문제가 생길 수 있습니까? 아니면 이런 식으로 사용됩니까?

또한이 Thread.start()메서드는 다른 클래스에서 기능을 구현할 수없는 매우 구체적인 메서드 여야합니다 (내가 틀리지 않은 경우). 따라서 final키워드가 다른 방법보다 더 적합 할 것이라고 생각합니다 .

하지만이 방법을 재정의하고 원하는대로 사용할 수 있습니다.

public class Test extends Thread {
    public static void main (String... args) {
        Thread test = new Test();
        test.start();
    }

    @Override
    public void run() {
        System.out.println("New thread started...");
    }

    @Override
    public void start() {
        System.out.println("Did anyone tell you I will spawn a new thread??");
    }
}

분명히 인쇄 만했는데

누군가 내가 새 스레드를 생성 할 것이라고 말했습니까 ??

당신을 대체하는 엔지니어를 혼란스럽게하는 것 외에 재정의에 어떤 용도가 있습니까?

그렇지 않다면 왜 메소드가 Thread 클래스에서 final로 선언되지 않았습니까?

---

Thread 클래스가 run () 메서드가 추상 인 추상 클래스가 아닌 일반 클래스로 구현 된 이유는 무엇입니까?

이 질문은 실제로 상속보다 구성을 선호해야한다는 사실로 귀결됩니다.

경우 Thread클래스가 선언 된 abstract언어는 프로그래머가를 만드는 데 사용할 수있는 그것에서 확장 된 다른 클래스를 제공 할 것입니다 Thread. 이 클래스의 것을 왜 귀하의 질문은 다음에 대한 것 extends부터가 Thread아니다 abstract. 언어가 extends에서 온 다른 클래스를 제공하지 않으면 Thread프로그래머는 메서드 extend에서 시작 Thread하고 재정의하는 자체 클래스를 만들어야합니다 run().

그렇지 않다면 왜 메소드가 Thread 클래스에서 final로 선언되지 않았습니까 ??

내가 줄 수있는 유일한 설명은 언어 개발자가 start클래스가 JDK에 도입되었을 때 재정의하는 몇 가지 사용 사례를 보았다 는 것입니다. 내가 사용한 Java의 첫 번째 버전은 1.5였으며 개인적으로 .NET Core를 재정의해야하는 사용 사례를 발견하지 못했습니다 start. JB Nizet이 그의 답변에서 말했듯이

자바가 오늘 처음부터 다시 디자인 되었다면 디자인이 다를 가능성이 높습니다.

---

물론 자신의 발에 총을 쏠 수는 있지만 그렇다고해서 반드시해야하는 것은 아닙니다.

Thread 클래스가 run () 메서드가 추상 인 추상 클래스가 아닌 일반 클래스로 구현 된 이유는 무엇입니까?

시작 스레드를 만드는 데 권장되는 방법은 Thread를 하위 클래스로 만드는 것이 아니기 때문입니다. 권장되는 방법은를 정의 Runnable하고 Thread 생성자에 인수로 전달하는 것입니다.

Runnable r = new Runnable() {
    @Override
    public void run() {
        ...
    }
};
Thread t = new Thread(r);
t.start();

따라서 최종 키워드가 다른 방법보다 더 적합 할 것이라고 생각합니다.

예, 아니오. 자신의 구현으로 start () 구현을 바꿀 수는 없지만 원하는 경우 start ()에서 추가 작업을 수행 할 수 있습니다 .

@Override
public void start() {
    System.out.println("Did anyone tell you I will spawn a new thread??");
    super.start();
}

즉, Java가 오늘 처음부터 다시 디자인 되었다면 디자인이 다를 가능성이 높습니다. 이 클래스는 Java 1.0에서 시작되었으며 여전히 이전 버전과 호환됩니다.

---

왜 Thread.start()그렇지 final않습니까?

당신이 있습니까 장해야 당신이 그것을 무시하고 싶지는 않을 것이다?

Class MyThreadFactory implements ThreadFactory {
    @Override
    public Thread newThread(Runnable r) {
        return new Thread(r) {
            @Override
            public void start() {
                LOGGER.info("Starting thread " + this);
                super.start();
            }
        };
    }
}

---

답변에 대한 몇 가지 calirifcations가 게시되어야한다고 생각합니다.

"당신은 그것을 무시하고 싶지 않을 것이 확실합니까?"

No ! I would not. Thats like saying, "Are you sure , you want to declare this variable private?" Because if I could declare any variable I use as public without fearing that other developers may mess my design logic, coding would be a breeze. One of the most important purpose of OOPS concepts of Scope, abstraction, polymorphism, Error handling etc is to communicate to other developers the design and intentions behind your code.As pointed out in the question, when you override start method, nobody is forcing you to use super.start(). @Codebender wrote a start method for a thread without using super.start() and compiler never complained. So he is free to break the whole mechanism of Threading and compiler is suppose to just let it pass? Thread's start method ensures that run method is called and execute at the right time ! It is critical to the very concept of Threading. I would be more than happy to be corrected, if I missed something here. 2.

Because the recommended way to create a start a thread is not to subclass Thread.

OK, if codebender is allowed by design, to sublass Thread and mess up the start method, By that logic, it is the design shooting itself in the foot. By another statement made,(which I agree with completely) , Runnable is the recommended way. Then why do we allow Thread class at all to instantiate the thread at all with no restrictions? This is followed by :

You can't replace the implementation of start() by your own implementation,

That actually supports codebender's claim that start method should be final when you say that.. ^

The one point, that's valid, is mentioned already as a side note, but is the actual answer to this question

"Backward compatibility".

In fact, improvements were even going on as late as JDK 5.0 , when they incorporated many major additions and clarifications to the Java concurrency model. We want backward compatibility to be supported all the way and thats why Thread class is still exactly as it was before, even though Runnable interface is the recommended way nowadays.

Again, I would be more than happy to be corrected, if I missed something.

참고URL : https://stackoverflow.com/questions/31202946/why-is-thread-not-an-abstract-class-and-start-not-final