Можно ли заменить абстрактный класс без свойств, но с абстрактными методами, на интерфейс?

# Замена абстрактного класса на интерфейс

Короткий ответ: ДА, можно

Абстрактный класс без свойств, только с абстрактными методами, может быть заменён на интерфейс в современной Java (Java 8+).

Пример: Абстрактный класс

public abstract class PaymentProcessor {
    public abstract void processPayment(double amount);
    public abstract void refund(double amount);
    public abstract String getTransactionId();
}

public class CreditCardProcessor extends PaymentProcessor {
    @Override
    public void processPayment(double amount) {
        System.out.println("Processing credit card payment: " + amount);
    }
    
    @Override
    public void refund(double amount) {
        System.out.println("Refunding credit card: " + amount);
    }
    
    @Override
    public String getTransactionId() {
        return "CC-12345";
    }
}

Замена на интерфейс

public interface PaymentProcessor {
    void processPayment(double amount);
    void refund(double amount);
    String getTransactionId();
}

public class CreditCardProcessor implements PaymentProcessor {
    @Override
    public void processPayment(double amount) {
        System.out.println("Processing credit card payment: " + amount);
    }
    
    @Override
    public void refund(double amount) {
        System.out.println("Refunding credit card: " + amount);
    }
    
    @Override
    public String getTransactionId() {
        return "CC-12345";
    }
}

Когда можно заменить

✅ Можно заменить на интерфейс, если:

• Нет полей (state)
• Нет конкретных методов (implementations)
• Нет конструкторов с логикой
• Нет protected методов
• Только абстрактные методы

// ✅ Хорошо
public abstract class Logger {
    public abstract void log(String message);
    public abstract void error(String message);
}
// Может быть интерфейсом

Когда нельзя заменить

❌ Нужен класс, если:

• Есть конкретная логика в методах
• Есть состояние (поля)
• Нужны private/protected члены
• Нужны неизменяемые поля

// ❌ Нельзя заменить
public abstract class DatabaseConnection {
    protected String connectionString;  // ПОЛЕ!
    
    public abstract void connect();
    
    public String getConnectionString() {
        return connectionString;  // ЛОГИКА!
    }
}
// Это уже не интерфейс

Пример: default методы в интерфейсах (Java 8+)

public interface PaymentProcessor {
    void processPayment(double amount);
    
    // Default метод с реализацией
    default void validateAmount(double amount) {
        if (amount <= 0) {
            throw new IllegalArgumentException("Amount must be positive");
        }
    }
    
    // Private метод для инкапсуляции (Java 9+)
    private void logTransaction(double amount) {
        System.out.println("Transaction: " + amount);
    }
}

public class StripeProcessor implements PaymentProcessor {
    @Override
    public void processPayment(double amount) {
        validateAmount(amount);  // Используем default метод
        System.out.println("Stripe payment: " + amount);
    }
}

Сравнение: Абстрактный класс vs Интерфейс

Практический пример преобразования

До: Абстрактный класс без логики

public abstract class EventListener {
    public abstract void onEvent(Event event);
    public abstract void onError(Exception ex);
}

После: Интерфейс

public interface EventListener {
    void onEvent(Event event);
    void onError(Exception ex);
    
    // Дополнительно: default методы для удобства
    default void onSuccess() {
        System.out.println("Event processed successfully");
    }
}

Рекомендации

1. Предпочитай интерфейсы для определения контрактов
2. Используй классы когда нужно состояние и логика
3. Комбинируй оба для сложной иерархии
4. Читаемость кода — главный критерий

Когда выбрать?

А) Только методы? → Интерфейс
Б) Есть поля? → Класс
В) Логика + методы? → Класс
Г) Контракт для разных иерархий? → Интерфейс

Вывод: Да, абстрактный класс с только абстрактными методами (без полей и логики) может быть заменён на интерфейс, и это даже рекомендуется, так как интерфейс лучше отражает цель — определение контракта.