Почему так много библиотек foss делают свои классы публичными, а не окончательными? - PullRequest
4 голосов
/ 21 января 2011

Прежде чем перейти ко мне с очевидным ответом, позвольте мне уточнить вопрос и сказать, что не все классы подклассифицированы.

  • Подклассы должны быть тщательно продуманными, а не стандартным свойством всех классов.
  • Можно утверждать, что классы должны быть окончательными по умолчанию и не окончательными, если кто-то действительно этого хочет.

Я могу придумать много преимуществ для частных классов.

  • если класс на самом деле не для моего просмотра, а просто помощник, который я должен рассмотреть подробно о реализации, то, сделав его закрытым, это означает, что он не появится, когда я буду искать классы по имени или реализации интерфейса в моем ide.
  • это также означает, что если все, кроме экспортируемых интерфейсов, публично проверяет API, просматривая файлы JAR библиотеки, становится намного проще, так как меньше шума. Я больше не вижу внутреннюю реализацию.
  • Нет необходимости беспокоиться о подклассах вне вашего пакета.
  • для пользователей практическая выгода означает, что необходимые им методы, вероятно, также будут сгруппированы в одном интерфейсе / классе, а не разбросаны по другим общедоступным классам, что означает меньшую смекалку и меньше мест для просмотра и меньше ручек тоже умудрился.

Так почему же люди не пользуются этими возможностями?

Ответы [ 6 ]

3 голосов
/ 21 января 2011

Есть языки, например, python, в которых все публично и ничто не является окончательным.Это не значит, что они живут в аду, а модули невозможно использовать и поддерживать.Совсем наоборот.

Программная инженерия сложна.Много раз мы являемся бойцами в наших умах.Это может быть весело, мы преследуем идеал независимо от практической выгоды - если у нас есть время.Если вы один человек, который отвечает за сотни занятий, то, будучи перфекционистом, вы сведете вас с ума.

1 голос
/ 11 февраля 2011

Ну, это просто потому, что для размышления о том, что НЕ ДОЛЖНО расширяться, требуются большие мозговые усилия.

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

На моей практике только Java Spring действительно беспокоил меня такого рода превентивным закрытием (что приводит к намного более ясному API после нескольких микро релизов)Я думаю).

У меня была цитата Р. Мартина по этому вопросу здесь:

http://java.akraievoy.org/2009/03/openclosed-principle-strategic-closure.html

1 голос
/ 21 января 2011
  1. Ваши предполагаемые преимущества библиотек, не поддерживающих подклассы, не подкреплены моим опытом.

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

Все меняется. С программным обеспечением, которое может измениться, легче работать. Иногда это требует радикальных улучшений, таких как стандартные методы Java 8. Они аккуратно исправляют методы добавления интерфейсов после широкого использования интерфейсов.

1 голос
/ 21 января 2011

С точки зрения того, должны ли классы быть окончательными или нет по умолчанию, это спорный вопрос, для которого на самом деле нет «правильного» ответа.Java решила сделать это одним способом, C # - другим, разные люди думают, что разные языки понимают это правильно и неправильно.

Лично мне нравится, как классы расширяются по умолчанию, если люди хотят сделать их окончательными, то они могутЭто всего лишь ключевое слово.Но разрешение подклассификации просто добавляет мне больше гибкости, и я уверен, что мне не нужно расширять каждый неконечный объект под солнцем, но если я хочу добавить некоторую степень специфического поведения, тогда у меня есть возможность сделать это.Да, можно использовать композицию (и в некоторых случаях ее следует использовать), но это не исключает и не должно исключать подклассификацию в качестве опции.Во многих случаях подклассифицированный объект выполняет отношения is-a с родителем, и в этом случае это правильный путь.Следует признать, что в прошлом этим злоупотребляли, даже в Java API (например, свойства не являются хеш-таблицей). Но если вы пытаетесь изменить язык, чтобы люди перестали быть глупыми - они всегда найдутОбходной путь!

Что касается того, чтобы сделать пакет классов закрытым, для меня эта опция была бы гораздо более полезной, если бы пакеты были иерархическими, а не плоскими.Да, они иерархичны по описанию, но что-то, объявленное пакетом private в org.me, недоступно из org.me.subpackage, что я часто чувствую необходимость сделать.К счастью, с добавлением суперпакетов мы могли бы лучше использовать эту опцию!

1 голос
/ 21 января 2011

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

Большинство конструкций API учитывают расширяемость.

0 голосов
/ 13 февраля 2011
  • модификаторы public и final принадлежат к разным категориям , помещать их в одно предложение не очень хорошее начало, когда вы хотите прояснить ситуацию
  • как для final - требования изменяются , и через некоторое время вам может понадобиться создать подкласс для некоторого финального класса, плюс не все библиотеки / фреймворки могут создавать прокси для конечных классов
  • что касается доступа к пакету - может сделать рефакторинг более сложным , но да, если вы создаете некоторую библиотеку, не публиковать внутренние классы - это хороший "шаблон"
...