2009-08-19 2 views

ответ

1

Да, эти методы не могут быть переопределены в подклассах. Пример этого является шаблоном шаблонного метода ...

+0

Вы должны дать больше объяснений. Метод шаблонов не подразумевает окончательного, хотя это, безусловно, упрощает жизнь. – kdgregory

+0

Ok let say final настоятельно рекомендуется :) Я рассматриваю его как ошибку, чтобы не использовать final для метода шаблона ... – pgras

1

Конечно, это означает, что вы можете унаследовать его, но вы не можете переопределить этот конкретный метод.

0

Да. Модификатор abstract позволяет опустить часть реализации класса (т. Е. Иметь некоторые методы abstract), но не налагает на вас каких-либо ограничений.

5

Да.

Подсказка: просто запустите свою любимую IDE (затмение, netbeans и т. Д.) И попробуйте. Он будет жаловаться, если он не работает.

+7

-1. Точка SO не означает, что люди «сами пробовали». Это пустая трата времени и усилий, если каждый, кто выполняет поиск в Интернете по этому вопросу, должен запустить среду IDE и попробовать ее для себя, когда кто-то может дать полный и исчерпывающий ответ на вопрос: http://stackoverflow.com/questions/1299398/1299434 # 1299434 –

+1

Да, ваше право, и я принимаю downvote, но это третий тривиальный вопрос Keyur об абстрактных классах в строке, поэтому я сделал исключение. –

+0

@Andreas_D: Я пропустил этот ключ, задал многочисленные вопросы по одному и тому же вопросу, и я видел достаточно, «почему бы вам не попробовать сами» ответы и комментарии сегодня утром, что я слишком быстро отреагировал с нисходящим потоком. Я удалил его (это означает, что вы возвращаете свой репер?), Так как ваш ответ на самом деле неверен. –

34

Несомненно. Взгляните на пример Template method pattern.

abstract class Game 
{ 
    protected int playersCount; 

    abstract void initializeGame(); 

    abstract void makePlay(int player); 

    abstract boolean endOfGame(); 

    abstract void printWinner(); 

    /* A template method : */ 
    final void playOneGame(int playersCount) { 
     this.playersCount = playersCount; 
     initializeGame(); 
     int j = 0; 
     while (!endOfGame()) { 
      makePlay(j); 
      j = (j + 1) % playersCount; 
     } 
     printWinner(); 
    } 
} 

Классы, расширяющие Game все еще необходимо реализовать все абстрактные методы, но они не в состоянии продлить playOneGame, поскольку он объявлен окончательным.

В абстрактном классе также могут быть методы, которые не являются ни абстрактными, ни окончательными, а просто обычными методами. Эти методы должны быть реализованы в абстрактном классе, но разработчик должен решить, должны ли расширения классов переопределять их или нет.

+0

прекрасный! Upvote для воссоздания шаблона шаблона метода –

+0

Но wats его использование – Sawyer

+0

@Bill the Lizard: отличный ответ! но у меня есть один вопрос: что, если метод playOneGame() был нормальным (не окончательным). это было то же самое? какое преимущество использовать здесь final вместо того, чтобы не использовать какое-либо ключевое слово? Спасибо –

4

Да, это возможно. Но последний метод не может быть абстрактным (другие не конечные методы в одном классе могут быть).

2

Да.

+1

Его хорошо стать ленивым и дать ответ в да и не только, когда пользователь сам тоже слишком ленив. Я думаю, что ваш ответ заслуживает того, как на моей стороне. – devsda

+0

Хех. :) – Bombe

0

В абстрактном классе методы могут быть определены или нет. Если мы расширим абстрактный класс, тогда только он имеет смысл, поэтому любые методы, которые мы объявляем или определяем в Abstract, требуют, чтобы он переместился в подкласс. Таким образом, мы можем объявить метод как final в абстрактном классе, и он будет преодолен в подклассе.

+3

Я вижу, что вы пытаетесь сказать здесь, но, пожалуйста, отредактируйте свой ответ, так как сейчас ОЧЕНЬ неясно. – szegedi

2

Да, в «абстрактном» классе могут быть «окончательные» методы. Но любой «абстрактный» метод в классе не может быть объявлен окончательным. Он даст "незаконная комбинация модификаторов: абстрактная и окончательная" ошибка.

public abstract final void show(); 
    illegal combination of modifiers: abstract and final 

Вот рабочий пример реализации.

abstract class Sian     //ABSTRACT CLASS 
{ 
    public final void show()  // FINAL METHOD 
    { 
     System.out.println("Yes"); 
    } 
    public void display() 
    { 
     System.out.println("Overriding"); 
    } 
    public abstract void success(); 
} 
class Ideone extends Sian    //INHERTING ABSTRACT CLASS 
{ 
    public void display() 
    { 
     System.out.println("Overridden"); 
    } 
    public void success()    //OVERRIDING THE ABSTRACT METHOD 
    { 
     System.out.println("Success overriding"); 
    } 
    public static void main (String[] args) throws java.lang.Exception 
    { 
     Ideone id = new Ideone();  //OBJECT OF SUBCLASS 
     id.show();      //CALLING FINAL METHOD 
     id.display();     //OVERRIDDEN METHODS 
     id.success(); 
    } 
} 

ВЫВОД: -

Yes 
Overridden 
Success overriding 

Вот ссылка ideone: - http://ideone.com/G1UBR5

0

Предположим, я хочу, чтобы разработанный класс, который имеет некоторую реализацию, но я не хочу, чтобы другие (суб классы) в реализуют его, но другие методы, тогда в этом случае нам нужен окончательный реализованный метод и очевидный выбор абстрактного класса.

Смежные вопросы