Продление классов без переопределения: плохая практика?

1

Я беру на себя старый проект. Теперь у меня есть некоторые классы в вкусе собственного класса util, переопределяющего класс утилиты внешней библиотеки. Например:

public final class StringUtilsXXX extends org.apache.commons.lang3.StringUtils {
}

Эти классы вообще не переопределяют любые методы расширенного класса (и никогда не будут в будущем). Я сбиваю с толку, что большинство вызовов собственной реализации просто делегируют суперкласс. Это плохая практика?

  • 0
    «большинство вызовов собственной реализации просто делегируют ...» Что делают другие вызовы?
Теги:

6 ответов

3
Лучший ответ

Да. Это плохая практика. Аргумент за то, что он тесно связан с вашими собственными классами в сторонней библиотеке. Я уверен, что причина, по которой ваш предшественник сделал это, заключается в том, что если ему когда-нибудь понадобится заменить commons-lang, ему нужно будет только изменить один фрагмент кода. Вероятно, он сделал это из-за разочарования от перехода с lang2 на lang3.

То, как он должен был это сделать, было бы создать интерфейс StringUtil и написать различные реализации этого (вы могли бы использовать StringUtil, который был реализован с использованием lang2, который использовал lang3 и даже, возможно, резервную реализацию, которая была реализована с нуля. (если вам нужна некоторая обработка строк, не предоставленная ни тем, или если вам нужно скомпилировать некоторые версии со старой версией Java или что-то еще).

Поделиться
  • 0
    +1 .. Более или менее то, что я хотел передать ..: P
0

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

Насколько я понимаю, адаптеры - правильный ответ. Но есть еще кое-что, что меня озадачивает: разве мы не должны стараться изо всех сил стараться, чтобы не разорвать контракт при обновлении нашего проекта, который мы отдаем другим? "Им" нужно было ввести новое пространство имен? Если бы они это сделали, мы должны обвинять наши колледжи в том, что они взломали код, чтобы поддерживать проект, несмотря на некоторые другие сомнительные идеи/решения?

Поделиться
  • 0
    Я не понимаю, как это отличается от простого старого наследства. Шаблон декоратора обычно подразумевает, что производный класс привязан к экземпляру базового класса, что здесь бессмысленно, поскольку StringUtils - это просто набор статических методов.
0

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

Поделиться
0

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

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

Поделиться
0

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

Поделиться
-1

Нет. Это плохая практика. Предположим, что завтра org.apache.commons.lang3.StringUtils что-то меняет (удаляет метод. Хотя это маловероятно, это может случиться с другими классами, особенно с пользовательскими классами), представьте, какое влияние это повлияет на ваш код. Фактически вы тесно связываете свои методы с org.apache.commons.lang3.StringUtils.

Поделиться
  • 2
    Это может произойти, даже если OP должен использовать StringUtils напрямую, не расширяя его в каком-либо другом классе.
  • 0
    @RJ - Я полностью согласен. Я просто считаю, что найти ошибку в StringUtils.someMethod () проще, чем найти ошибку в MyClass.someMethod ()
Показать ещё 2 комментария

Ещё вопросы

Сообщество Overcoder
Наверх
Меню