2013-06-18 3 views
4

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

Есть ли практический пример абстрактного класса со всеми методами , объявленными как Abstract?

В большинстве случаев, как и в учебнике по Java, класс со всеми абстрактными методами - это интерфейс.

Но так как абстрактный класс и интерфейс являются два разных понятия, я ищу пример убедительным, чтобы иметь «полный абстрактный класс»

+2

Разница заключается в «ограничении видимости». –

ответ

5

Единственный практический подход я считаю, что Abstract class может держать состояние. Таким образом, вы можете иметь внутренние свойства с уровнем доступа protected, и вы можете сделать protected abstract methods, что в интерфейсе вы не можете вызвать все public.

Практический пример может быть, например, таким образом, защищенный метод в java имеет «доступ наследования» и «доступ к пакету».

public interface Operation{ 
void operate(); 
} 

public abstract class AbstractClase implements Operation{ 
protected Operation delegate; 

public AbstractClase(Operation delegate){ 
    this.delegate=delegate; 
} 

//delegate implementation responsability to children 
protected abstract doSomething(); 

} 

Недостатком использования абстрактного класса является то, что вы теряете возможность расширять что-то еще.

4

Как и для состояния держателя, стоит помнить, что все члены интерфейса неявно public. Таким образом, ограничение видимости абстрактных методов само по себе может быть достаточно убедительным основанием для использования абстрактного класса вместо интерфейса.

3
  1. Добавление к двум ответам, приведенных выше, интерфейсы могут иметь только константы (переменные, которые являются открытыми, статическими и конечным), пока не существует никаких ограничений для абстрактных классов.

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

Ниже приведен пример для использования абстрактного класса

abstract class Animal{ 
    public int noOfLegs; 
    public boolean isAlive; 
    Animal(){ 
     isAlive = true; 
    } 
    public abstract void walk(); 
} 
class Cow extends Animal{ 
    Cow(){ 
     noOfLegs = 4; 
    } 
    public void walk(){ 
     if(isAlive){ 
      //Code for walking 
     } 
    } 
} 
+1

# 1 кажется самым очевидным и важным отличием для меня ... – jahroy

0

Еще одна общая цель абстрактного класса является, чтобы предотвратить экземпляр класса., Например

abstract class Mammal{ 
    int i=0; 
} 
public class Man extends Mammal{ 
    public setMeValue(int i){ 
     this.i=i; 

    } 
public static void main(String args[]){ 
    Mammal m= new Man(); 
    man.setMeValue(10); 
} 
} 

В приведенном выше коде я фактически убедился, что никогда не будет объекта экземпляра Mammal.

+0

Это прекрасно, он не отвечает, почему класс со всеми абстрактными методами. –

+0

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

0

Интерфейс может применяться к совершенно разным классам. Классы, не имеющие отношения друг к другу, являются Serializable или Cloneable. Однако подклассы абстрактного класса связаны между собой. Это может ничего не значить при реализации интерфейса или расширении абстрактного класса, но это означает что-то семантически.

Существует стиль программирования, где все методы базового класса являются либо public final, protected abstract, protected и пустой, или private. Но даже это не то, что интересовало OP.

0

Самый простой практический пример, я думаю, это класс, который имеет защищенную переменную:

public abstract class RoadVehicle { 
    protected int numberOfTires; 
    protected String vinNumber; 
    protected VehicleRegistration registration; 
    public abstract void drive(); 
    public abstract double calculateToll(); 
    public abstract void changeTires(); 
    // so on and so forth... 
} 

Вы не можете сделать это с помощью интерфейса.

+0

Не имеет смысла numberOftires isccesible – nachokk

+0

@nachokk - Ой ... Защищено то, что я имел в виду. Глупая ошибка: -0 ​​ – jahroy

0

Добавление больше нижеприведенных ответов:

интерфейс предоставит вам контракт реализации, где абстрактный класс может предоставить вам с шаблоном, а также. Для простого сценария вы можете использовать интерфейс или абстрактный класс, не задумываясь. Но наличие абстрактного класса только для поддержания состояния может дать вам массу проблем в сложной реализации. В таких случаях вы должны тщательно рассмотреть то, что вы действительно хотите достичь в своем коде и принять решение. Если вы рассматриваете случай сохранения состояния в своем коде, вы всегда можете использовать State pattern в своей реализации, чтобы вы могли использовать интерфейс в своем коде. Вы должны всегда учитывать возможность расширения и поддерживаемость вашего кода, прежде чем принимать решение об использовании абстрактного класса над интерфейсом.

0
public abstract class animal{ 
    public abstract void speak(){ 
     System.out.println("animal voice"); 
    } 
} 

public class dog extends animal{ 
    public void speak(){ 
     System.out.println("dog voice"); 
    } 
} 
+2

Не знаете, насколько уместен этот пример для вопроса –

0

Самый большой мотив, имеющий чисто абстрактных классов, чтобы позволить в будущем расширение. Предположим, что у вас есть абстрактный класс (со всеми абстрактными членами), тогда вы наследуете этот абстрактный класс в 20 производных классах. Когда-нибудь в будущем вы хотите добавить публичный метод к 5 своим производным классам, что вы делаете?


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

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