И на такое изящество просто невозможно наткнуться.
Около 10 лет назад один из моих коллег однажды сказал, что Javascript собирается обогнать индустрию разработки программного обеспечения. Серверы, приложения, 3D-игры - все будет написано на Javascript. Тогда я посмеялся над этой идеей, ослепленный гордостью, которой меня учили в начале своей карьеры, что веб-разработчики - это не то же самое, что компьютерные программисты. Оказывается, он не ошибался, но я уверена. Javascript занял свое маловероятное место (учитывая его корни), в результате чего в нашей отрасли, несомненно, произошел серьезный сдвиг - к лучшему ли это зависит от вас, но я думаю, что это для всех нас, кто прямо или косвенно извлекают из этого выгоду.
Параллельно с этим успехом функциональное программирование, хотя и намного старше, в последние несколько лет стало популярным. Некоторые из его сторонников могут рассматривать объектно-ориентированное программирование как нечто, что либо провалилось как парадигма, либо создало больше проблем в разработке программного обеспечения, чем решило - и многие отдельные аргументы, подтверждающие это мнение, вполне обоснованы. Нетрудно признать, что достоинства функционального программирования по-прежнему актуальны после стольких лет, особенно там, где ООП не дает результатов.
Сочетание этих двух вышеуказанных движений заново ставит под сомнение наше представление о языках программирования и парадигмах, которые они либо поддерживают, либо полностью вокруг них построены. Обратите внимание, что я использовал слово движения, а не тенденции, потому что, хотя в настоящее время есть тенденции, изменения, происходящие прямо сейчас, являются каноническими.
Я в большинстве своем являюсь ОО-программистом, но я не собираюсь принимать чью-либо сторону, потому что это не должно быть спором мы против них; у всех инструментов есть свое применение, и вы используете тот, который лучше всего подходит для вас в текущем контексте, если только вы не относитесь к типу «у меня есть молоток, а все - гвоздь». Независимо от того, на какой стороне забора вы находитесь, ООП будет оставаться актуальным в течение многих лет и может быть инструментом высокой производительности - если вы можете делать это правильно, - но большинство из нас не может.
... при построении инфраструктуры автоматизации для вашего продукта иногда совсем не хочется думать об ООП и объектах ...
Около 20 лет назад мой преподаватель в колледже по моим курсам C ++ сказал, что если вы можете изучать C ++ на уровне, который он преподает, вы можете программировать на любом языке, потому что нет более сложного языка. Я не знаю, был ли он прав в этом, но еще десятью языками позже я не доказал, что он ошибался.
В глазах многих людей C ++ был воплощением языков объектно-ориентированного программирования. Конечно, все еще могут быть некоторые сторонники Objective-C, которые сказали бы, что Objective-C был лучшим объектно-ориентированным подходом, поскольку он добавил только 6 ключевых слов к языку ANSI C с ~ 30 ключевыми словами, одновременно извлекая уроки из Smalltalk. Спросите подходящего программиста на C, и он скажет, что вы можете выполнять ООП со структурами.
Есть много видов языков ООП, но языки на основе C - это то, о чем я могу говорить наиболее осмысленно. Если вы хотите сделать это на Perl, выбейте себя из колеи. Я могу лишь кратко говорить об интерпретируемых языках с хорошей поддержкой ООП, таких как Python и Ruby, но, за некоторыми исключениями, эти языки лучше служили мне инструментами для написания сценариев, управляемых функциями. Например, при построении инфраструктуры автоматизации для вашего продукта иногда совсем не хочется думать об ООП и объектах; вам просто нужны многоразовые функции для выполнения работы.
Чистые ООП-языки, такие как Java, могут быть хорошими во многих отношениях и принесли много пользы, но всегда было что-то, что мешало мне любить Java. Я никогда не буду так хвалить его, как я начал уважать C # за его синтаксический сахар и за то, что он устарел так изящно, как современный язык. Такие языки отлично подойдут, если вы все-таки используете ООП. И наоборот, некоторые языки (например, Dart), последователи которых могут подчеркивать поддержку как ООП, так и ФП, позволяют вам выбирать, какая парадигма подходит для поставленной задачи.
..реализация интерфейсов, а не наследование.
Позже появляется Свифт. Опять же, вы можете выполнять как функциональные, так и ООП с его помощью, но они действительно настаивали на протокольно-ориентированном программировании, которое сначала я подумал «отличная, еще одна [ругательная] парадигма». Оказывается, если я правильно понимаю, это действительно то, что программисты OO должны были практиковать в любом случае - реализация интерфейсов, а не сосредоточение внимания на наследовании.
Тот же коллега (который видел появление Javascript) однажды сказал мне, что «наследование ради повторного использования кода - зло», а также «ключевое слово« новое »- зло», среди других настроений, которые я считал крайними в то время. Я так и не понял, что он имел в виду, пока год спустя не научился применять принципы SOLID и MVC в своей повседневной работе. Это все изменило для меня.
... это случается почти с каждым объектно-ориентированным программистом, который когда-либо вносил свой вклад в что-то значимое.
Прежде чем изучать SOLID и MVC, вы просто занимаетесь программированием, кодируя то и это, как обычно, изо дня в день. Иногда вы видите, что классы или целые проекты становятся недоступными для обслуживания, а некоторые части становятся просто кошмаром для работы, но вы никогда не можете увидеть общую картину, соедините все точки. Конечно, вы можете провести рефакторинг некоторых классов, сделать некоторые вещи немного по-другому в ретроспективе, но вы не можете понять, как все многочисленные проблемы связаны с тем фактом, что подход и архитектура были обречены на провал с самого начала. .
Это слишком часто. Я могу представить, что это случается почти с каждым объектно-ориентированным программистом, который когда-либо внес свой вклад в что-то значимое. Если вы знаете SOLID сейчас, но не знали, когда начинали ООП, то вы точно знаете, о чем я говорю.
..поначалу почти все антипаттерны кажутся достаточно невинными.
Как это произошло? Что ж, когда вы даете мощный, но опасный инструмент кому-то, кто должным образом не обучен владеть им, он обязательно нанесет сопутствующий ущерб. Вы можете изучить все правила языка программирования, но в обычных руках этих правил недостаточно для написания хорошего, долговечного поддерживаемого кода.
Это и тот факт, что последствия не всегда очевидны во время написания кода; поначалу почти все антипаттерны кажутся достаточно невинными. Я полагаю, вы можете сказать, что ООП - это активатор анти-шаблона, если вы не знаете, на что обращать внимание. Проблема не в том, чтобы просто потерпеть неудачу, а в том, что вы не знаете, что код не удался, пока не попытаетесь его сохранить.
И почему так? Потому что в отличие от других инженерных дисциплин (которые могут быть связаны законами физического мира), программная инженерия очень открыта, почти без ограничений - нет ничего незаконного, кроме, возможно, синтаксических ошибок и… недопустимых символов :), но вы можете получить вокруг даже этого.
Программисты ..OO, использующие современные языки в 2020 году, все еще повторяют те же ошибки, что и десятилетия назад.
Действительно ли это вина языка программирования или парадигмы? Может быть, но это тоже человеческая проблема. Давайте строить так, как мы хотим, и мы сможем построить хаос. Забавно, что все попадают в один и тот же беспорядок независимо друг от друга, в то время как нужно учить предусмотрительности и осмотрительности, необходимым для избежания типичных ошибок.
Так что технически SOLID и другие модели существуют уже около 20 лет. И все же ОО-программисты, использующие современные языки в 2020 году, все еще повторяют те же ошибки, что и десятилетия назад. Вероятно, это связано с тем, что многие замечательные концепции, применимые к большинству языков ООП, не преподаются как стандартные вместе с ООП. Мы учим людей создавать рабочий код, и почему-то все еще остается секретом, как создавать долговечный код, хотя все это общеизвестно.
Есть ли принципы или шаблоны, которыми вы хотели бы поделиться, которые изменили ваше отношение к ООП или сделали вас в целом лучшим программистом? Что, по вашему мнению, должен знать каждый объектно-ориентированный программист? Пожалуйста, поделитесь в комментариях.
