Абстракт: война между решением проблемы и общим решением [закрыто]

Как программист, я попадаю в дилемму, где я хочу сделать свою программу максимально абстрактной и максимально общей.

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

Тогда этот голос в моей голове говорит, просто решите проблему, пустышка, это так просто! Зачем тратить больше времени, чем нужно?

Мы все действительно столкнулись с этим вопросом, когда абстракция находится на вашем правом плече, а Solve-it-глупый - на левом.

Что слушать и как часто? Какова ваша стратегия для этого? Стоит ли абстрагироваться от всего?

Что слушать и как часто?

Никогда не абстрагируйтесь, пока не должны.

Например, в Java вы должны использовать интерфейсы. Они абстракция.

В Python у вас нет интерфейсов, у вас есть Duck Typing, и вам не нужны высокие уровни абстракции. Так что вы просто не делаете.

Какова ваша стратегия для этого?

Не абстрагируйтесь, пока не напишите три раза.

Один раз - хорошо - один раз. Просто решите это и двигайтесь дальше.

Дважды указывает на то, что здесь может быть образец. Или не может. Это может быть просто совпадение.

Трижды это начало паттерна. Теперь это выходит за рамки совпадения. Теперь вы можете успешно абстрагироваться.

Стоит ли абстрагироваться от всего?

Нет.

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

Обычно это позволяет мне повторно использовать мой код

Это предположение, которое часто ложно. Абстракция не может помочь вообще. Это может быть сделано плохо. Поэтому не делайте этого, пока не должны.

Ах, ЯГНИ. Наиболее злоупотребленная концепция программирования.

Есть разница между созданием общего кода и дополнительной работой. Стоит ли тратить дополнительное время на то, чтобы сделать свой код свободно связанным и легко адаптированным для других целей? Абсолютно. Стоит ли тратить время на реализацию ненужных функций? Нет. Должны ли вы тратить время на то, чтобы ваш код работал с другим кодом, который еще не был добавлен? Нет.

Как говорится "Делай самое простое, что могло бы сработать". Дело в том, что люди всегда путают простое с легким . Простота требует работы. Но это стоит усилий.

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

Подумайте об этом так: велика вероятность, что ваш код каким-то образом снова будет использоваться. Но вы не собираетесь правильно прогнозировать этот путь. Так что сделайте ваш код чистым, абстрактным и слабо связанным. Но не пытайтесь заставить ваш код работать с какими-то конкретными функциональными частями, которые еще не существуют. Даже если вы знаете, что это будет существовать в будущем.

Силлогизм:

1. Общность дорогая.

2. Вы тратите деньги других людей.

3. Поэтому расходы на общность должны быть обоснованы для заинтересованных сторон.

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

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

И, наконец, не существует такого понятия, как «как можно более общее». Предположим, вы пишете программное обеспечение на C # только для аргументации. Собираетесь ли вы заставить каждый класс реализовывать интерфейс? Каждый класс абстрактный базовый класс с каждым методом абстрактный метод? Это довольно общее, но это далеко не «как можно более общее». Это позволяет людям изменять реализацию любого метода с помощью подклассов. Что если они захотят изменить реализацию метода без создания подклассов? Вы можете сделать каждый метод на самом деле свойством типа делегата с установщиком, чтобы люди могли изменить каждый метод на что-то другое. Но что, если кто-то захочет добавить больше методов? Теперь каждый объект должен быть расширяемым.

На данный момент вы должны отказаться от C # и принять JavaScript. Но вы все еще не получили достаточно общего; Что делать, если кто-то хочет изменить, как поиск членов работает для этого конкретного объекта? Может быть, вы должны написать все на Python вместо этого.

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

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

Например, рассмотрим функцию, которая копирует память.

Функция является абстракцией, которая скрывает, как копируются 4 байта.

int copy4Bytes (char * pSrc, char * pDest)

Обобщением было бы сделать эту функцию копировать любое количество байтов.

int copyBytes (char * pSrc, char * pDest, int numBytesToCopy)

Абстракция пригодна для повторного использования, в то время как обобщение делает абстракцию полезной в большинстве случаев.

Более конкретно, связанный с вашим вопросом, абстракция полезна не только с точки зрения повторного использования кода. Часто, если все сделано правильно, это сделает ваш код более читабельным и понятным. Используя приведенный выше пример, что легче читать и понимать, если вы просматриваете код copyBytes () или цикл for, перебирающий массив, перемещающий данные по одному индексу за раз? Абстракция может обеспечить своего рода документацию, которая, по моему мнению, облегчает работу с кодом.

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

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

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

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

Первое: преждевременная общность стоит дорого.

Второе: представьте в своей модели только те вещи, которые всегда находятся в предметной области и чьи классовые отношения неизменны.

Третье: держите ваши политики подальше от ваших механизмов.

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

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

Я большой поклонник принципа KISS.

Я сосредоточен на предоставлении того, что меня просят сделать, а не на том, что является лучшим решением. Я должен был отпустить перфекционизм (и ОКР), потому что он сделал меня несчастным.

где абстракция находится на вашем правом плече, а Solve-it-глупый - на левом.

Я не согласен с «решить это глупо» , я думаю, что это может быть более «решить это умно» .

Что умнее:

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

Выбор по умолчанию должен быть вторым. Если вы не можете продемонстрировать потребность в поколениях.

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

Обычно я считаю, что обобщенные решения лучше всего использовать в качестве «основного кода библиотеки»