Почему в классах из стандартных java-библиотек так много кода?

Рейтинг: 1Ответов: 1Опубликовано: 07.03.2023

Есть хорошее правило, которое называется "правило 10 - 50 - 500". Оно означает, что в идеале:

  1. В пакете должно быть не более десяти классов;
  2. В методе не более 50 строк;
  3. В классе не более 500 строк;

Если не сильно нарушить это правило, то, конечно ничего страшного в этом нет.

В jdk есть такая вещь, как архив src.zip. В нём есть .java-файлы, в которых можно посмотреть реализацию классов из java-библиотек. Именно оттуда среда разработки показывает код, когда я нажимаю на название какого-либо java-класса в своём коде в среде разработки.

Меня поразило то, что в классах огромное количество кода, а в одном пакете - гигантское количество классов. В некоторых классах количество строк достигает почти 4000, а количество классов в одном пакете может быть такое, что и половина на экран не влезет!

Вот, например, java.io.ObjectInputStream и пакет java.io:

что это?

Почему так? И как раньше это объясняла это sun, а теперь oracle? Ведь поддерживать такой проект тяжело, такой код противоречит принципам написания чистого кода. Я стараюсь создавать классы по принципу 10 - 50 - 500, но... после такого я уже засомневался в существовании этого принципа. Неужели в реальных проектах такого принципа нет и это всё выдумки для новичков?

P.S: я очень надеюсь, что на этот счёт есть цитаты и факты, а не только мнения.

java чистый-код openjdk
Источник: Stack Overflow на русском

Ответы

▲ 6Принят

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

Если вы пишете бизнес приложение, то прибыль от приложения и скорость его реакции на изменение условия в бизнесе являются приоритетом. В конкретном приложении не стыдно просто выкинуть часть кода или переписать, или вообще всё выкинуть и переписать с нуля. Бизнес приложения, в среднем, пишутся под задачу, меняется задача - меняется код. Также такие приложения пишутся программистами очень разного уровня, потому читаемость кода здесь тоже играет важную роль. То есть еще раз, для бизнес приложения важно: читаемость кода, возможность быстрого изменения приложения, при этом обычно в среднем качество приложения далеко от идеального - просадки производительности или баги - это норма жизни.

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

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

Потому, если вы пишете код бизнес приложений, то внимайте книгам дяди Боба. Но если вы пишете библиотеки, то ваш повседневные инструменты - это справочники по ООП и алгоритмам. Если вы ещё более глубоко копнете в исходники всяких фреймворков, то чего только не увидите, и самописные хешмапы и самописные другие алгоритмы, которые раздувают классы только так, и всё в угоду производительности. Ну и, естественно, если бизнес приложения пишет разношерстная команда по принципу "за меньшие деньги сделайте мне более менее работающее ПО", то библиотеки априори требуют какого то минимального (при этом довольно высокого) уровня квалификации, так как ошибки в проектировании библиотек будут жить гораздо дольше и их гораздо сложнее исправить.