Есть два противоположных мышления: «Если это работает, это хорошо» против «Если это хорошо, это работает;» или «Сделай так» или «Сделай правильно» Я говорю об исходном коде программного обеспечения. Я слышал об этом почти каждый день в комментариях блога: зачем нам все эти новые принципы ООП, если наш код работает без них? Какой смысл вводить новый способ, который должен быть «лучше», если существующий, традиционный, полуобъектный, полупроцедурный, не очень совершенный подход просто работает ?
Scarface (1983) Брайан Де Пальма
Давайте попробуем думать больше. И не только об объектно-ориентированном программировании, но и вообще о разработке программного обеспечения. Есть много примеров менталитета «просто дела».
Возьмите Perl, язык программирования, известный своей способностью делать что-либо тремя различными способами. Это означает, что не существует единого «правильного» пути. Я не эксперт Perl; вот почему я заставлю вас взглянуть на этот код Ruby:
|
1
2
3
|
if a > b m = 'Hello!'end |
Мы можем переписать это так:
|
1
2
3
|
m = if a > b 'Hello!'end |
Или это:
|
1
|
m = 'Hello!' if a > b |
И еще один:
|
1
|
m = a > b ? 'Hello' : nil |
Какой из них «правильно?» Есть ли разработчики Perl? Можете ли вы предложить другой способ достижения того же результата?
Неудивительно, что в Java (более строгом языке, чем Ruby) есть только один способ сделать это:
|
1
2
3
|
if (a > b) { m = "Hello!";} |
Ну, я думаю, я не прав; На самом деле их два. Вот второй:
|
1
|
if (a > b) m = "Hello!"; |
Что дает нам, программистам, это разнообразие возможностей? Я предполагаю, что ответ серьезно зависит от того, что мы, программисты, делаем с кодом: пишем или читаем его. Кроме того, это зависит от нашего отношения к программному обеспечению, которое мы создаем; мы либо владеем им (менталитет хакеров), либо создаем его (менталитет дизайнеров).
Если мы пишем это, и нам нравится думать о себе как о владельцах кода, нам определенно понадобится этот арсенал синтаксического сахарного оружия. Нам нужно, чтобы они доказали себе, что мы умны, и, конечно, выпендривались перед нашими друзьями и этим бездушным переводчиком Ruby.
С другой стороны, если мы разработчики и будем читать код, полный сахара, который «просто работает», мы будем очень раздражены и расстроены. Ну, может быть, я должен говорить за себя, но я определенно буду.
Проще говоря, более высокое качество обеспечивается простыми языками.
Этот чрезмерно засахаренный синтаксис Ruby является прекрасным примером позиционирования «работает против хорошего». Философия Ruby такова: не важно, как ты это пишешь, пока это работает. Философия Java отличается; это гораздо ближе к: сделать это правильно, и это будет работать. Слабая и динамическая типизация в Ruby против сильной и статической в Java также подтверждают мою точку зрения.
В целом, я считаю, что чем более гибкий язык программирования, тем ниже удобство сопровождения — ключевая характеристика качества — кода, который он производит. Проще говоря, более высокое качество обеспечивается простыми языками.
То же самое относится ко всей разработке программного обеспечения: чем больше ограничений мы накладываем на программистов и чем меньше у них возможностей для их «творческого подхода к синтаксису», тем выше качество написанного ими программного обеспечения. Статические анализаторы, такие как Checkstyle для Java или Rubocop для Ruby, пытаются решить эту проблему и запрещают нам использовать определенные функции языка, но они сильно отстают. Мы очень «креативны».
Теперь вернемся к первоначальному вопросу ООП: зачем нам что-либо улучшать, если оно работает так, как есть? Вот ответ: Современный ООП (как в Java, Ruby и C ++) не производит качественный код, потому что у него нет строгой и правильно ограниченной парадигмы. У него просто слишком много «функций», которые в основном были представлены C ++ и остались там для нашего взаимного «удобства».
Они действительно работают, но ремонтопригодность программного обеспечения, которое мы производим, очень низкая. Ну, это намного ниже, чем могло бы быть, если бы наше «творчество» было бы ограничено.
| Ссылка: | Гибкость приравнивается к низкому качеству от нашего партнера JCG Егора Бугаенко в блоге About Programming . |