Обзор парадигм
Существует три основных парадигмы: структурное, объектно-ориентированное и функциональное. Интересно, что сначала было открыто функциональное, потом объектно-ориентированное, и только потом структурное программирование, но применяться повсеместно на практике они стали в обратном порядке.
Структурное программирование было открыто Дейкстрой в 1968 году. Он понял, что goto – это зло, и программы должны строиться из трёх базовых структур: последовательности, ветвления и цикла.
Объектно-ориентированное программирование было открыто в 1966 году.
Функциональное программирование открыто в 1936 году, когда Чёрч придумал лямбда-исчисление. Первый функциональный язык LISP был создан в 1958 году Джоном МакКарти.
Каждая из этих парадигм убирает возможности у программиста, а не добавляет. Они говорят нам скорее, что нам не нужно делать, чем то, что нам нужно делать.
Все эти парадигмы очень связаны с архитектурой. Полиморфизм в ООП нужен, чтобы наладить связь через границы модулей. Функциональное программирование диктует нам, где хранить данные и как к ним доступаться. Структурное программирование помогает в реализации алгоритмов внутри модулей.
Объектно-ориентированное программирование
ООП – это парадигма, которая характеризуется наличием инкапсуляции, наследования и полиморфизма.
Инкапсуляция позволяет открыть только ту часть функций и данных, которая нужна для внешних пользователей, а остальное спрятать внутри класса.
Однако в современных языках инкапсуляция наоборот слабее, чем была даже в C. В Java, например, вообще нельзя разделить объявление класса и его определение. Поэтому сказать, что современные объектно-ориентированные языки предоставляют инкапсуляцию можно с очень большой натяжкой.
Наследование позволяет делать производные структуры на основе базовых, тем самым давая возможность осуществлять повторное использование этих структур. Наследование было реально сделать в языках до ООП, но в объектно-ориентированных языках оно стало значительно удобнее.
Наконец, полиморфизм позволяет программировать на основе интерфейсов, у которых могут быть множество реализаций. Полиморфизм осуществляется в ОО-языках путём использования виртуальных методов, что является очень удобным и безопасным.
Полиморфизм – это ключевое свойство ООП для построения грамотной архитектуры. Он позволяет сделать модуль независимым от конкретной реализации (реализаций) интерфейса. Этот принцип называется инверсией зависимостей, на котором основаны все плагинные системы.
Инверсия зависимостей так называется, что она позволяет изменить направление зависимостей. Сначала мы начинаем писать в простом стиле, когда высокоуровневые функции зависят от низкоуровневых. Однако, когда программа начинает становиться слишком сложной, мы инвертируем эти зависимости в противоположную сторону: высокоуровневые функции теперь зависят не от конкретных реализаций, а от интерфейсов, а реализации теперь лежат в своих модулях.
Любая зависимость всегда может быть инвертирована. В этом и есть мощь ООП.
Таким образом, между различными компонентами становится меньше точек соприкосновения, и их легче разрабатывать. Мы даже можем не перекомпилировать базовые модули, потому что мы меняем только свой компонент.
Ответ 1
Лучшей книгой, которую я когда-либо читал о OO, является Бертран Мейер Объектно-ориентированное программное обеспечение.
Его огромный, но это было очень полезно для меня. Он охватывает каждый отдельный аспект OO-дизайна IMVHO.
Ответ 10
Несмотря на то, что мы склоняемся к Rational UP, я нашел, что эти два предлагают много понимания дизайна OO.
- Применение UML и шаблонов — Craig Larman
- UML 2 и единый процесс: практический объектно-ориентированный анализ и дизайн — Джим Арлоу и Ила Нойштадт
Ответ 2
Большинство фундаментальных работ по объектной ориентации когда-либо публикуются. Это абсолютно необходимо иметь книгу для каждого «объектно-ориентированного» программиста.
2.
» Объектно-ориентированный анализ и дизайн с приложениями» от Grady Booch и др.
Не так формально, как книга Мейера, но эта книга может открыть вам глаза на многие вопросы в объектно-ориентированном мире и в разработке программного обеспечения вообще
3.
» Шаблоны проектирования: элементы многоразового объектно-ориентированного программного обеспечения» Эриха Гамма и др.
Это знаменитая книга «Банда четырех» о шаблонах дизайна
4.
» Рефакторинг: улучшение дизайна существующего кода» Мартина Фаулера и др.
Это еще одна классическая книга. Первая часть прекрасно описывает многие проблемы, с которыми может столкнуться современный разработчик программного обеспечения во время своей работы: запахи кода, читаемость и производительность, преждевременные недостатки оптимизации и многие другие темы.
5.
» Мышление в Java» от Брюса Эккеля
Эта книга может помочь многим новичкам не только на языке Java, но и в объектно-ориентированном мышлении.
6.
» Touch of Class: обучение программированию с объектами и контрактами» Бертран Мейер
Отличный учебник известного автора.
Ответ 3
Я полностью понимаю вашу ситуацию. Также есть три из этих книг;) Я бы предложил Head First edition. Объектно-ориентированный анализ и дизайн. Это поможет вам на правильном пути. Книга GoF великолепна, но бесполезна, пока вы не освоите основы в своей голове, и книга Head First позаботится об этом. Приветствия:)
Ответ 4
На самом деле программирование — это большая помощь, чем чтение о программировании.
парализованный некоторыми очень фундаментальными решениями, является симптомом более глубокой проблемы — чрезмерной инженерии. Пока вы не строите много вещей, вы действительно не знаете, какие решения имеют значение, и которые не имеют значения.
Лучший способ получить необходимый опыт — построить много вещей.
Ответ 5
Роберт К. Мартин «Разработка гибких программных продуктов: принципы, шаблоны и практика», которые объясняют вам принципы OO
Эрик Эванс: «Domain Driven Design» занимается тем, как создать хороший дизайн, соответствующий вашей бизнес-проблеме.
Мартин Фаулер: «Шаблоны архитектуры корпоративных приложений» для основных принципов архитектуры предприятия
Ответ 6
Старики, но лакомства.
Ответ 7
Единственный способ узнать, является ли дизайн надежным, — это реализовать его. Существует не одна книга, которая научит вас, как создавать реалистичные проекты, это сводится к опыту и таланту. Тем не менее, я делаю второе голосование за книгу Бертрана Мейера — просто имейте в виду, что это не превратит вас в бога дизайна OO.
Ответ 8
Крейг Ларман Применение UML и паттернов подробно рассказал о том, что я узнал из опыта. Что мне нравится в этом, так это то, что он затрагивает все аспекты разработки программного обеспечения, который включает в себя такие вещи, как итеративный дизайн и разработка.
Не смотрите слишком сильно на использование UML: описания дизайна — это средство для достижения цели, и я нашел подход Лармана довольно прагматичным. Вы не можете просто кодировать: вы должны сообщить свои намерения (и понять, что нужно). UML и продуманный, хорошо прокомментированный код — вот некоторые из средств для достижения этой цели.
И, конечно, как говорят другие: ни одна книга не сделает вас хорошим разработчиком или дизайнером. Но это может ускорить процесс.
Ответ 9
Для стартера я предлагаю Head First Объектно-ориентированный анализ и дизайн.
Он поможет вам создать приложение OO простым интуитивным пошаговым способом.
Парадигмы программирования
Дисциплину, которая в дальнейшем стала называться программированием, зародил Алан Тьюринг в 1938 году. В 1945 он уже писал полноценные программы, которые работали на реальном железе.
Первый компилятор был придуман в 1951 году Грейс Хоппер (бабушка с татуировкой Кобола). Потом начали создаваться языки программирования.
Структурное программирование
Дейкстра понял, что программирование – это сложно. Большие программы имеют слишком большую сложность, которую человеческий мозг не способен контролировать.
Чтобы решить эту проблему, Дейсктра решил сделать написание программ подобно математическим доказательствам, которые также организованы в иерархии. Он понял, что если в программах использовать только if, do, while, то тогда такие программы можно легко рекурсивно разделять на более мелкие единицы, которые в свою очередь уже легко доказуемы.
С тех пор оператора goto не стало практически ни в одном языке программирования.
Таким образом, структурное программирование позволяет делать функциональную декомпозицию.
Однако на практике мало кто реально применял аналогию с теоремами для доказательства корректности программ, потому что это слишком накладно. В реальном программировании стал популярным более «лёгкий» вариант: тесты. Тесты не могут доказать корректности программ, но могут доказать их некорректность. Однако на практике, если использовать достаточно большое количество тестов, этого может быть вполне достаточно.
Функциональное программирование
В основе функционального программирования лежит запрет на изменение переменных. Если переменная однажды проинициализирована, её значение так и остаётся неизменным.
Какой профит это имеет для архитектуры? Неизменяемые данные исключают гонки, дедлоки и прочие проблемы конкурентных программ. Однако это может потребовать больших ресурсов процессора и памяти.
Применяя функциональный подход, мы разделяем компоненты на изменяемые и неизменяемые. Причём как можно больше функциональности нужно положить именно в неизменяемые компоненты и как можно меньше в изменяемые. В изменяемых же компонентах приходится работать с изменяемыми данными, которые можно защитить с помощью транзакционной памяти.
Интересным подходом для уменьшения изменяемых данных является Event Sourcing. В нём мы храним не сами данные, а историю событий, которые привели к изменениям этих данных. Так как в лог событий можно только дописывать, это означает, что все старые события уже нельзя изменить.
Заключение
Таким образом, каждая из трёх парадигм ограничивает нас в чём-то:
Продолжение здесь.
