Значительные соперники ООП
VB эквивалент того, что написал @Matthew:
Public Module StringExtensions
<Extension()>
Public Function StripIncompatableQuotes(BadString As String) As String
If Not String.IsNullOrEmpty(BadString) Then
Return BadString.Replace(ChrW(&H2018), "'").Replace(ChrW(&H2019), "'").Replace(ChrW(&H201C), """").Replace(ChrW(&H201D), """")
Else
Return BadString
End If
End Function
End Module
11 ответов
На мой взгляд, причина такого широкого использования ООП не столько в том, что это правильный инструмент для работы. Я думаю, это больше, когда решение может быть описано клиенту в понятной для него форме.
АВТОМОБИЛЬ - это АВТОМОБИЛЬ, у которого есть ДВИГАТЕЛЬ. Это программирование и реальный мир - все в одном!
Трудно постичь что-либо, что может так элегантно соответствовать программированию и реальному миру.
Вы можете взглянуть на Erlang, написанный Джо Армстронгом.
Википедия:
«Erlang - это язык параллельного программирования общего назначения и исполняющая система. Последовательное подмножество Erlang - это функциональный язык, {{1 }} со строгим вычислением, однократным присваиванием и динамической типизацией »
Джо Армстронг:
« Поскольку проблема с объектно-ориентированными языками заключается в том, что они {{1} } получили всю эту неявную среду, которую они носят с собой. Вы хотели банан, но у вас была горилла, держащая банан и целые джунгли ».
Linux - это крупномасштабный проект, который в значительной степени не является ООП. И это тоже мало что от этого выиграет.
Я думаю, что ООП имеет хорошее отношение к этому, потому что оно ассоциируется с хорошими практиками программирования, такими как инкапсуляция, скрытие данных, повторное использование кода, модульность и т. д. Но эти достоинства ни в коем случае не уникальны для ООП.
Обещанием ООП было повторное использование кода и упрощение обслуживания. Я не уверен, что он доставлен. Я считаю, что такие вещи, как точечная сеть, очень похожи на библиотеки C, которые мы использовали для различных поставщиков. Вы можете вызвать это повторное использование кода, если хотите. Что касается обслуживания, плохой код - это плохой код. ООП не помогло.
Я самый большой поклонник ООП, и я практикую ООП каждый день. Это наиболее естественный способ написания кода, потому что он похож на реальную жизнь.
Хотя я понимаю, что виртуализация ООП может вызвать проблемы с производительностью. Конечно, это зависит от вашего дизайна, языка и выбранной вами платформы (системы, написанные на языках, основанных на сборке мусора, таких как Java или C #, могут работать хуже, чем, например, системы, написанные на C ++).
Я полагаю, что в системах реального времени процедурное программирование может быть более подходящим.
Обратите внимание, что не все проекты, претендующие на звание ООП, на самом деле являются ООП. Иногда большая часть кода носит процедурный характер, или модель данных анемична и так далее ...
См. это и это . Очевидно, вы можете использовать C # с пятью различными парадигмами программирования, C ++ с тремя и т. Д.
Построение программного обеспечения не похоже на фундаментальную физику. Физики стремятся описывать реальность, используя парадигмы, которым могут бросить вызов новые экспериментальные данные и / или теории. Физика - это наука, которая ищет «истину» в отличие от конструирования программного обеспечения.
Построение программного обеспечения - это бизнес . Вы должны быть продуктивными , т.е. достигать каких-то целей, за которые кто-то будет платить деньги. Парадигмы используются, потому что они полезны для эффективного создания программного обеспечения . Вам не нужно, чтобы все соглашались. Если я использую ООП, и у меня это хорошо работает, мне все равно, если "новый" парадигма потенциально была бы для меня на 20% полезнее, если бы у меня было время и деньги, чтобы изучить ее, а затем переосмыслить всю структуру программного обеспечения, над которой я работаю, и перепроектировать ее с нуля.
Кроме того, вы можете использовать другую парадигму и Я по-прежнему буду счастлив, так же как я могу зарабатывать деньги, управляя рестораном японской кухни, а вы можете зарабатывать деньги в ресторане мексиканской кухни по соседству. Мне не нужно обсуждать с вами, лучше ли японская кухня мексиканской.
так же, как я могу зарабатывать деньги, управляя рестораном японской кухни, и вы можете зарабатывать деньги в ресторане мексиканской кухни по соседству. Мне не нужно обсуждать с вами, лучше ли японская кухня мексиканской. так же, как я могу зарабатывать деньги, управляя рестораном японской кухни, и вы можете зарабатывать деньги в ресторане мексиканской кухни по соседству. Мне не нужно обсуждать с вами, лучше ли японская кухня мексиканской.Zyx, вы писали: «Большинство систем используют реляционные базы данных ...»
Боюсь, что такого нет. В следующем году реляционной модели исполнится 40 лет, и она так и не была реализована. Я думаю, вы имеете в виду «базы данных SQL». Вы должны прочитать что-нибудь у Фабиана Паскаля, чтобы понять разницу между реляционной базой данных и базой данных SQL.
«... реляционная модель обычно выбирается из-за ее популярности»
Верно, она популярна.
«... наличие инструментов»
Увы, без основного необходимого инструмента: реализации реляционной модели.
«поддержка»
Ага, я уверен, что у реляционной модели есть отличная поддержка, но это полностью не поддерживается реализацией dbms.
"
Да, это математическая концепция, но, поскольку она не реализована, она в основном ограничивается башнями из слоновой кости. Теория струн - это тоже математическая концепция, но я бы не стал реализовывать с ней систему.
На самом деле, несмотря на то, что это математическая концепция, это определенно не наука (как в информатике), потому что в ней отсутствует первое требование - любая наука: что это фальсифицируемо: нет реализации реляционной СУБД, по которой мы могли бы проверить ее утверждения.
Это чистое змеиное масло.
«... вопреки ООП».
И вопреки ООП , реляционная модель никогда не была реализована.
Купите книгу по SQL и начните продуктивно.
Оставьте реляционную модель непродуктивным теоретикам.
Да, это математическая концепция, но, поскольку она не реализована, она в основном ограничивается башнями из слоновой кости. Теория струн - это тоже математическая концепция, но я бы не стал реализовывать с ней систему.
На самом деле, несмотря на то, что это математическая концепция, это определенно не наука (как в информатике), потому что в ней отсутствует первое требование - любая наука: что это фальсифицируемо: нет реализации реляционной СУБД, по которой мы могли бы проверить ее утверждения.
Это чистое змеиное масло.
«... вопреки ООП».
И вопреки ООП , реляционная модель никогда не была реализована.
Купите книгу по SQL и начните продуктивно.
Оставьте реляционную модель непродуктивным теоретикам.
в основном ограничивается башнями из слоновой кости. Теория струн - это тоже математическая концепция, но я бы не стал реализовывать с ней систему.На самом деле, несмотря на то, что это математическая концепция, это определенно не наука (как в информатике), потому что в ней отсутствует первое требование - любая наука: что это фальсифицируемо: нет реализации реляционной СУБД, по которой мы могли бы проверить ее утверждения.
Это чистое змеиное масло.
«... вопреки ООП».
И вопреки ООП , реляционная модель никогда не была реализована.
Купите книгу по SQL и начните продуктивно.
Оставьте реляционную модель непродуктивным теоретикам.
в основном ограничивается башнями из слоновой кости. Теория струн - это тоже математическая концепция, но я бы не стал реализовывать с ней систему.На самом деле, несмотря на то, что это математическая концепция, это определенно не наука (как в информатике), потому что в ней отсутствует первое требование - любая наука: что это фальсифицируемо: нет реализации реляционной СУБД, по которой мы могли бы проверить ее утверждения.
Это чистое змеиное масло.
«... вопреки ООП».
И вопреки ООП , реляционная модель никогда не была реализована.
Купите книгу по SQL и начните продуктивно.
Оставьте реляционную модель непродуктивным теоретикам.
Использование ООП упрощает управление и понимание кода (например, изменение / обновление / добавление новых функций). Это особенно актуально для более крупных проектов. Поскольку модули / объекты инкапсулируют свои данные и операции с этими данными, легче понять функциональность и общую картину.
Преимущество ООП состоит в том, что легче обсуждать (с другими разработчиками / руководством / заказчиком) LogManager или OrderManager, каждый из которых включает в себя определенные функции, а затем описывает «группу методов, которые выгружают данные в файл» и «методы, которые отслеживают детали заказа».
Так что я полагаю, что ООП полезно, особенно в больших проектах, но есть всегда появляются новые концепции, так что ищите что-то новое в будущем, оценивайте и сохраняйте то, что полезно.
Людям нравится думать о различных вещах как о «объектах» и классифицировать их, поэтому нет сомнений в том, что ООП так популярно. Однако есть некоторые области, в которых ООП не приобрело большей популярности. Большинство систем используют реляционные базы данных, а не объективные. Даже если вторые имеют заметные рекорды и лучше подходят для некоторых типов задач, реляционная модель выбрана неправильно из-за ее популярности, доступности инструментов, поддержки и того факта, что реляционная модель на самом деле является математической концепцией, в отличие от ООП.
Еще одна область, в которой я никогда не видел ООП, - это процесс создания программного обеспечения. Все сценарии настройки и сборки являются процедурными, частично из-за отсутствия поддержки ООП в языках оболочки, частично из-за того, что ООП слишком сложен для таких задач.
Я сомневаюсь, что ООП уйдет в ближайшее время, просто оно слишком хорошо соответствует нашим проблемам и ментальным моделям.
Однако мы начинаем видеть многопарадигмальные подходы, в которых декларативные и функциональные идеи включаются в объектно-ориентированные проекты. Хорошим примером этого являются большинство новых языков JVM (JavaFX, Scala, Clojure и т. Д.), А также LINQ и F # на платформе .net.
Важно отметить, что я говорю не о замене объектно-ориентированного подхода, а о его дополнении.
JavaFX показал, что декларативная решение выходит за рамки SQL и XSLT, а также может использоваться для привязки свойства и события между визуальными компоненты в графическом интерфейсе
Для отказоустойчивости и высокой параллельные системы, функциональные программирование очень подходит, как продемонстрировал Ericsson AXD301 (запрограммирован с использованием Erlang)
Итак ... по мере того, как параллелизм становится все более важным, а FP становится более популярным, я полагаю, что языки, не поддерживающие эту парадигму, пострадают. Сюда входят многие популярные в настоящее время, такие как C ++, Java и Ruby, хотя JavaScript должен с этим справиться очень хорошо.