Сколько абстракции это слишком много?

Как мало - это слишком мало?

Когда вы продолжаете работать с элементами «низкого уровня» на регулярной основе и постоянно чувствуете, что не делаете этого » ; не хочу этим заниматься. Абстрагируйте их.

Так когда это становится слишком много?

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

Где золотая середина?

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

Каждая абстракция, которая фактически не используется, - это слишком много. Чем проще система, тем легче ее изменить. Слои абстракции почти всегда усложняют систему.

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

Проще говоря, слишком много абстракции, если код труден для понимания.

Это не означает, что вы должны жестко кодировать все, потому что это самый простой код для написания и чтения.

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

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

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

См. Пункт (6a) из RFC 1925 и знайте, что это действительно так. Единственные проблемы, которые вы не можете исправить, добавляя уровни абстракции, - это проблемы, вызванные слишком большим количеством уровней абстракции. (В частности, каждая часть абстракции затрудняет понимание всего этого.)

Теоретически это должно быть вопросом простой математики с использованием только трех (довольно простых) переменных:

• S = экономия от использования
• C = стоимость дополнительных абстракций
• P = вероятность использования

Если S * P> C, то код хорош. Если S * P

Причина этого чисто теоретическая, однако, заключается в том, что вы, как правило, не можете угадать вероятность использования или экономию, которую вы получите от его использования. Хуже того, вы не можете угадать или даже измерить стоимость его присутствия.

По крайней мере, некоторые люди сделали из этого вывод. В TDD стандартная мантра - «вам это не понадобится» (ЯГНИ). Проще говоря, все, что напрямую не способствует тому, чтобы код соответствовал его текущим требованиям, считается плохим. По сути, они пришли к выводу, что вероятность использования настолько мала, что включение такого дополнительного кода никогда не оправдано.

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

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