Аноним против названных внутренних классов? - лучшие практики?

Question

У меня есть класс, назовем его LineGraph, который отображает линейный график. Мне нужно создать его подкласс, но производный класс используется только в одном месте и связан с классом, который его использует. Поэтому я использую внутренний класс.

Я вижу два способа сделать это:

Анонимный внутренний класс

public class Gui {
    LineGraph graph = new LineGraph() {
        // extra functionality here.
    };
}

Именованный внутренний класс

public class Gui {
    MyLineGraph graph = new MyLineGraph();

    private class MyLineGraph extends LineGraph {
        // extra functionality here.
    }
}

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

Answer 1

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

Я видел код, в котором последний массив из 1 элемента используется для передачи данных от вызова к анонимному внутреннему классу. Внутри метода класса anon устанавливается один элемент, затем этот «результат» извлекается после завершения метода. Действительный, но уродливый код.

Answer 2

С помощью анонимных внутренних классов мы не можем изменить состояние включаемых членов класса. Они должны быть объявлены как окончательные.

Answer 3

Только что провел эту дискуссию сегодня с моим коллегой и копался в поисках популярного мнения.

Я согласен с TofuBeer. Если ваш код содержит более 2 строк, он, вероятно, не является одноразовым и может быть когда-нибудь использован повторно. Если вы создаете форму с использованием шаблона MVC, у вас может быть 20 контролируемых элементов на странице, вместо того, чтобы загромождать представление тоннами классов анонимных (черт возьми, ваше представление, вероятно, было создано с использованием GUI-компоновщика, а код был автоматически создан редактирование источника даже не вариант) вы, скорее всего, будете передавать каждый элемент контроллеру. Вы можете вложить внутренние классы в контроллер для обработки каждого интерфейса обработчика / прослушивателя, который требуется вашему представлению. Это очень хорошо организует код, особенно если у вас есть соглашение, что ваш класс обработчика должен быть назван с использованием имени элемента GUI (например, backButtonHandler для backButtonElement). Это очень хорошо сработало для нас, и мы написали инструмент автоматической регистрации (когда вы регистрируете контроллер в представлении, представление ищет внутренние классы, используя имя элемента, и использует их для обработчика каждого именованного элемента). Это было бы невозможно с анонимными классами и делает контроллер более пригодным для повторного использования.

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

Answer 4

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

Answer 5

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