, в котором не следует использовать абстрактный класс и интерфейс сценария?

Question

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

Я не смог четко ответить на его вопрос конкретными примерами того, когда вы не хотели бы этого делать в то время. У меня есть поисковая партия для конкретного ответа с примером, но не в состоянии найти.

Я знаю, когда использовать какой из них. Также я понимаю, что
абстракция - это механизм и практика сокращения и разложения деталей, чтобы можно было сосредоточиться на нескольких концепциях за раз.

Так что я могу ответить, что, когда я не нашел никакого отношения, я не должен его использовать.

Можете ли вы, чтобы гениальные парни провели минуту и ​​ответили мне, чтобы увеличить мои знания?

Заранее спасибо.

Answer 1

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

Answer 2

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

Answer 3

2 случая я думаю

1: если вы должны создавать объекты вашего класса (eg: MyClass object=new MyClass())

2: в случае наследования той же реализации в качестве родительского класса, например:

class Parent { 
    int x; 

    public void setX(int x) { 
     this.x = 2 * x; 
    } 
} 

class Child extends Parent { 
    int y = 1; 

    public void setX_AND_Y(int x, int y) { 
     setX(x); // same implmentaion 
     this.y = y; 
    } 
} 

Answer 4

У меня возникли проблемы с весенним бобом, которым пришлось реализовать интерфейс и расширить базовый класс в прошлом.

Это была довольно сложная проблема, связанная с АОП и весной, поэтому я не могу быть на 100% уверен, что это то, о чем спросил ваш интервьюер, но это совершенно то, что вы можете наткнуться на дикую природу и не ограничиваться только весной ,

Часто вы хотите добавить AOP в свое приложение Spring (например, чтобы использовать аннотации @Transactional). Проблема в том, что существует несколько способов реализации АОП: от патча байт-кода во время компиляции или времени загрузки до генерации чего-то похожего на обертки во время выполнения.

Последний подход является самым дешевым, построенным по конструкции, и используется чаще, чем другие, но имеет свои недостатки.

Один из них заключается в том, что существует множество способов сделать это, и подход отличается от того, какой конкретный компонент (экземпляр класса) вы хотите переплетать (обернуть). Вещь вроде «ли класс реализует интерфейс», «ли класс расширяет класс» и сочетается здесь.

Я не буду углубляться в подробности здесь, просто потому, что я боролся с этим довольно давно, но вы можете понять, с чем вам придется иметь дело от spring docs, кратко обсуждая этот вопрос.

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

ОБНОВЛЕНИЕ: Ответ на ваш вопрос в одном предложении: вы, вероятно, не хотите расширять абстрактный класс и реализовывать интерфейс в то же время в коде, который имеет дело с динамическим проксированием классов/созданием кода AOP /.

Answer 5

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

С помощью Java 1.5 и более поздних версий статический импорт теперь можно использовать, чтобы избежать необходимости определять константу с именем класса. Хотя лично я на самом деле не имею в виду квалификационные константы с именем класса, особенно если имена классов констант имеют значимое «группирующее» имя.