The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Существуют два противоположных подхода: “Если работает, значит, хорошо” против “Если хорошо, значит, работает”; или “Заставьте это работать” против “Заставьте это быть правильным”. Я говорю о программном коде. Я слышу это практически каждый день в комментариях блога: Зачем нам все эти новые принципы ООП, если наш код работает отлично и без них? В чем смысл введения нового, предполагаемо “лучшего” способа, если существующий, традиционный, полуобъектно-полупроцедурный, не такой уж идеальный подход просто работает?
Давайте попробуем подумать глобальнее. И не только о объектно-ориентированном программировании, но вообще о разработке программного обеспечения. Существует множество примеров подхода “просто работает”.
Возьмем Perl, язык программирования, известный своей способностью делать все тремя разными способами. Это означает, что нет одного “правильного” способа. Я не являюсь экспертом по Perl; поэтому вместо этого предлагаю взглянуть на этот код на Ruby:
Мы можем переписать это следующим образом:
Or this:
m = 'Hello!' if a > b
And one more:
m = a > b ? 'Hello' : nil
Какой из них “правильный”? Есть ли разработчики Perl? Можете ли вы предложить другой способ достичь того же результата?
Неудивительно, что в Java (более строгом языке, чем Ruby) есть только один способ сделать это:
Ну, я думаю, я ошибся; на самом деле их два. Вот второй:
Что дает нам такое разнообразие вариантов, как программистам? Думаю, ответ в значительной степени зависит от того, что мы, программисты, делаем с кодом: пишем его или читаем. Также это зависит от нашего отношения к создаваемому нами программному обеспечению; мы либо владеем им (мыслить как хакер), либо строим его (мыслить как дизайнер).
Если мы пишем код и считаем себя его владельцами, нам определенно понадобится арсенал оружия синтаксического сахара. Нам нужны они, чтобы доказать себе, что мы умные, и, конечно же, чтобы похвастаться перед друзьями и этой бездушной интерпретатором Ruby.
С другой стороны, если мы дизайнеры и случайно читаем код, который полон сахара и “просто работает”, мы будем очень раздражены и разочарованы. Хорошо, возможно, мне говорить за себя, но я определенно буду.
Этот излишне сахарный синтаксис Ruby - идеальный пример позиционирования “работает против хорошего”. Философия Ruby состоит в том, что не имеет значения, как вы его пишете, главное - чтобы работало. Философия Java отличается; она гораздо ближе к “сделай правильно, и оно будет работать”. Слабая и динамическая типизация в Ruby по сравнению с сильной и статической типизацией в Java также подтверждают мою точку зрения.
В целом я считаю, что чем более гибкий язык программирования, тем ниже поддерживаемость - ключевая характеристика качества кода, который он создает. Проще говоря, высокое качество достигается с помощью более простых языков.
То же самое верно и для всего процесса разработки программного обеспечения: чем больше ограничений мы накладываем на программистов и чем меньше у них возможностей для “творчества в синтаксисе”, тем выше качество программного обеспечения, которое они создают. Статические анализаторы, такие как Checkstyle для Java или Rubocop для Ruby, пытаются решить эту проблему и запрещают нам использовать определенные возможности языка, но они значительно отстают. Мы очень “творческие”.
Теперь вернемся к первоначальному вопросу об ООП: зачем нам что-то улучшать, если все работает так, как есть? Вот ответ: современное ООП (как в Java, Ruby и C++) не создает качественного кода, потому что у него нет сильной и должным образом ограниченной парадигмы. У него просто слишком много “возможностей”, которые в основном были введены в C++ и остались там для нашего общего “удобства”.
Они действительно работают, но поддерживаемость создаваемого нами программного обеспечения очень низкая. Хорошо, она намного ниже, чем могла бы быть, если бы наша “творческая” свобода была ограничена.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-22 at 09:48
