Какая модель построения программ лежит в основе технологии процедурного программирования

Обновлено: 05.07.2024

"Парадигмы состоят из "набора предположений, концепций, ценностей и практик, которые составляют способ видения реальности для сообщества, которое их разделяет, особенно в интеллектуальной дисциплине". разработки программного обеспечения, парадигмы определяют, как разработчики видят проблему и организуют ее решение. Думайте об этом как о языке для описания проблемы, разработки и реализации программного решения. Термин смена парадигмы означает «фундаментальное изменение в [] подход или лежащие в его основе предположения». Применительно к разработке программного обеспечения это означает резкое изменение языка между частями процесса разработки. Ученые-компьютерщики использовали различные методы, чтобы помочь справиться с возрастающей сложностью программных систем. Они основывают каждый метод на другая парадигма, и каждое продвижение вызывало или приводило к изменению парадигмы.

Для разработки больших и сложных программных систем разработчики разбивают общий процесс разработки на более мелкие, более управляемые этапы или этапы. В Jurison 1 отмечается, что «Выбор процесса разработки программного обеспечения оказывает значительное влияние на успех проекта. Надлежащий процесс может привести к более быстрому завершению, снижению затрат, повышению качества и снижению риска. Неправильный процесс может привести к дублированию усилий и планировать промахи и создавать постоянные проблемы с управлением".

Процесс разработки программного обеспечения

Со временем было предложено множество процессов разработки программного обеспечения, и каждый из них определяет свой собственный набор фаз или шагов. Как правило, между шагами и названиями есть некоторые различия, но три из них являются общими для большинства процессов:

  • Пользовательский интерфейс
  • Управление данными
  • Управление задачами
  • Управление коммуникациями

Хотя анализ и проектирование — это разные этапы с разными целями, они основаны на одном и том же языке или парадигме. Поэтому на следующих рисунках они всегда показаны вместе.

Парадигмы разработки программного обеспечения

Исторически разработчики программного обеспечения экспериментировали с тремя основными парадигмами разработки программного обеспечения: процедурной, управляемой данными и объектно-ориентированной. Прежде чем перейти к формальным процессам проектирования, разработчики использовали «органические», специальные методы (то есть программы «росли» случайным образом). На рис. 1 показано, что каждая методика может привести к созданию работающей программы, но не за одно и то же время и не за одно и то же количество усилий.

Изображение, которое представляет четыре различные парадигмы разработки программного обеспечения как пути между реальным миром и программой, решающей реальную проблему. Путь ad hoc — самый длинный и наименее прямой путь. Процедурная парадигма представляет собой более короткий и прямой путь. путь еще короче и еще прямее. Но объектно-ориентированный путь кратчайший и самый прямой». ширина=

Четыре парадигмы разработки программного обеспечения. Разработчики программного обеспечения реагировали на постоянно растущий размер и сложность программных систем, разрабатывая более сложные парадигмы разработки. На рисунке показаны специальные, процедурные, управляемые данными и объектно-ориентированные парадигмы как пути между реальным миром и работающей программой.

Процедурный

Процедурная парадигма фокусируется на том, как решить проблему. Разработчики программного обеспечения, использующие эту парадигму, перечисляют шаги, необходимые для решения проблемы, а затем последовательно разбивают эти шаги на более мелкие и простые подзадачи, которые в конечном итоге представляются с помощью процедур, функций или методов. Процедурная декомпозиция часто изображается в виде иерархии, списка или дерева. Вершина или корень дерева представляет общую проблему, листья внизу обозначают отдельные процедуры или функции, а промежуточные узлы — это функции, вызываемые из функций выше и вызывающие функции ниже. Не существует четко определенных правил для выполнения декомпозиции или определения того, когда функции достаточно просты, чтобы можно было начать программирование. Отсутствие этих правил предполагает, что декомпозиция несколько произвольна.

Анализ и проектирование создают декомпозицию проблемы, представленную на следующем рисунке в виде дерева. Напротив, реализация или программирование создают программу, состоящую из функций. Похоже, что между этими этапами происходит сдвиг парадигмы, но процедуры или функции являются основным языком каждого этапа. Способ, которым разработчики представляют процедуры, меняется с деревьев на функции, но язык или парадигма последовательно ориентированы на процедуры. Но связь между реальным миром (то есть исходной проблемой) и декомпозицией проблемы более выражена.

В реальном мире мы видим, как люди занимаются своими повседневными делами. Например, они зарабатывают деньги, внесенные на счет, и тратят деньги, снятые со счета. Но они не видят, как перемещаются эти деньги. Они, конечно, не видят процедурной декомпозиции или функций, реализующих транзакции, которые перемещают деньги. Существует резкое изменение между проблемой и процедурной декомпозицией, которую создает анализ. Это резкое изменение является сменой парадигмы. Тем не менее, процедурная модель по-прежнему подходит для небольших простых программ, и то, что мы узнаем при ее изучении, перенесется в наше изучение объектно-ориентированной парадигмы.

На картинке изображен процедурный процесс разработки программного обеспечения. В частности, он иллюстрирует продукт анализа и проектирования в виде иерархии или дерева, а реализацию - в виде коротких скелетных функций. Анализ и проектирование логически близки к реализации, но существует большой разрыв между реальными мировая проблема, анализ и проектирование. Ошибка процедурной парадигмы заключается в большом логическом разделении между реальной проблемой и фазами анализа и проектирования, что показано на рисунке с человеком, перепрыгивающим через пропасть». /><br /></p> <p> Процедурная парадигма. Процедуры и функции — это согласованный язык, проходящий через анализ, проектирование и реализацию. Разработчики программного обеспечения следуют одной и той же парадигме на всех трех этапах. Однако анализ вводит существенно новый язык по мере перехода от исходной реальной проблемы к функциональной декомпозиции. Возникший в результате сдвиг парадигмы не помогает аналитику лучше понять предметную область и делает результаты анализа и проектирования (диаграммы декомпозиции) сложными для понимания не разработчиками программного обеспечения.</p> <h3>На основе данных</h3> <p>С середины 1970-х до середины 1990-х годов разработчики программного обеспечения создали и использовали множество парадигм, основанных на данных. У всех вариантов была одна важная общая черта: они следовали за данными, когда они поступали в систему, проходили через процессы, которые преобразовывали данные, и продолжали отслеживать данные, пока они не покидали систему. Анализ и проектирование смоделировали данные, проходящие через систему, в виде стрелок, входящих и выходящих из пузырьков процесса. Иногда несколько стрелок входили в пузырь и сливались в один исходящий поток; иногда один поток вошел только для того, чтобы быть разделенным на несколько потоков, выходящих из процесса. Результатом стала сеть данных и процессов, описывающих данную проблему.</p> <p>Анализ, основанный на любой парадигме, основанной на данных, приводит к лучшему пониманию предметной области, чем анализ, основанный на процедурной декомпозиции. Кроме того, модели проблемы, созданные во время анализа и разработанные во время проектирования, во многих случаях более полезны, чем соответствующие модели, основанные на процедурной парадигме. В частности, модели на основе потоков данных обеспечивали лучшую поддержку тестирования, проверки и документирования программного обеспечения. Диаграммы потоков данных также легче понять заинтересованным сторонам, чем процедурную декомпозицию или запрограммированные функции.</p> <p>Мне может показаться странным утверждать, что диаграммы потоков данных в целом понятны, и поэтому между реальной проблемой и анализом нет смены парадигмы. Но представьте, что мы рисуем пузырек, представляющий работодателя человека, со стрелкой, обозначающей деньги, идущей от пузыря работодателя к пузырю, представляющему банк этого человека. Затем мы рисуем стрелку от банка, снова представляющего деньги, к пузырю, представляющему магазин, в котором человек делает покупки. Я считаю, что поток данных, где данные — это деньги в этом примере, интуитивно понятен. К сожалению, между диаграммами потоков данных и программами, написанными на этапе реализации, был большой разрыв. Разрыв, сдвиг парадигмы, возникает в результате изменения основного языка с потоков данных, которые фокусируются на <em>что</em>, на процедуры, которые фокусируются на <em>как</em>.</p> <p><img class=

Парадигма, основанная на данных. Этапы анализа и проектирования логически близки к реальной проблеме. Анализ на основе данных помогает разработчикам лучше понять предметную область.Кроме того, получившиеся графы потока данных легче понять не разработчикам программного обеспечения, чем деревья декомпозиции, созданные с помощью процедурной техники. Однако диаграммы потоков данных труднее преобразовать в работающие программы, чем деревья декомпозиции, из-за смещения парадигмы от данных к функциям.

Объектно-ориентированный

Объекты, существующие в реальном мире, идентифицируются во время анализа и абстрагируются в классы. На этапе проектирования разработчики добавляют детали к классам, добавляют новые классы, а иногда и удаляют классы. Тем не менее, по большей части обнаруженные в ходе анализа классы переносятся на проектирование. Кроме того, классы, уточненные во время проектирования, переносятся на этап реализации. Когда разработчики программного обеспечения реализуют классы, они переводят диаграммы классов UML на соответствующий язык программирования. Примечательно, что концепции классов и объектов не меняются от одной фазы к другой. Концептуальная согласованность образует мосты между реальным миром, анализом и проектированием, а также реализацией.

Изображение, иллюстрирующее процесс разработки объектно-ориентированного программного обеспечения. На этапах анализа и проектирования создается набор классов. Разработчики переводят эти классы в рабочую программу на этапе реализации. На рисунке объектная ориентация изображена как мост между каждым этапом процесса разработки программного обеспечения с человек, легко идущий между фазами на мостах». ширина=

Объектно-ориентированная парадигма. Объектно-ориентированная парадигма равномерно распределяет этапы разработки без больших промежутков. То есть нет никаких межпроцессных сдвигов парадигмы. Разработчики определяют классы во время анализа, уточняют их во время проектирования и реализуют на этапе программирования. Но парадигма или язык классов остается неизменной на протяжении всего процесса разработки. Такое согласованное использование классов образует объектно-ориентированные мосты между каждым этапом процесса разработки программного обеспечения. Это эффективно устраняет пробелы или сдвиги парадигмы, возникающие в других методах разработки.

Способность объектно-ориентированной парадигмы устранять промежутки между фазами, сглаживая процесс разработки, — лишь одна из многих ее сильных сторон. Он сохраняет лучшие характеристики процедурных и управляемых данными парадигм, преодолевая или сводя к минимуму их худшие черты. Например, модели, созданные во время анализа, помогают разработчикам понять проблемную область так же, как и модели, управляемые данными, поскольку классы представляют данные. Но классы также обозначают операции или процедуры, поэтому переход от проектирования к реализации очень похож на процедурную парадигму. Кроме того, поскольку каждый класс определяет новую промежуточную область видимости (область программы, где переменная видима и доступна), объектно-ориентированная парадигма также позволяет некоторым, но не всем процедурам программы обращаться к данным. Управление доступом к данным уменьшает функциональную связь, что практически ограничивает размер и сложность программного обеспечения, созданного с помощью процедурной парадигмы. Многочисленные сильные стороны объектно-ориентированной парадигмы делают ее лучшей практикой для создания больших и сложных программных систем.

Парадигмы: Java против C++

Java — это чисто объектно-ориентированный язык, который поддерживает только объектно-ориентированную парадигму. По этой причине программы на Java обязательно определяют все, включая библиотечные методы и символические константы, внутри классов. С другой стороны, C++ представляет собой гибридный язык, поддерживающий как процедурную, так и объектно-ориентированную парадигмы. C++ позволяет разработчикам выбирать наиболее подходящую для данной проблемы парадигму: объектно-ориентированную парадигму для больших и сложных задач и процедурную парадигму для более мелких и менее сложных задач.

1 Джурисон, Дж. (1999). Управление программным проектом: взгляд менеджера. Сообщения Ассоциации информационных систем, 2, статья 17, 1–57.

Если вы новичок в программировании, парадигмы программирования не имеют большого значения. Но когда вы поднимаетесь по лестнице и начинаете создавать сложные программы и программное обеспечение, очень важно понять, какая парадигма программирования лучше всего подходит для вашего проекта. Прежде чем мы начнем, важно знать, что такое парадигма. Согласно многим цитируемым определениям, парадигма — это «набор предположений, концепций, ценностей и практик, которые составляют способ видения реальности для сообщества, которое их разделяет, особенно в интеллектуальной дисциплине».

Это определение является точным, поскольку парадигма отличается другим взглядом на реальность для сообщества. Парадигмы имеют значение, поскольку они часто путешествуют вместе с определенной культурой написания программ и размышлений о них.В этой статье мы обсудим основные парадигмы программирования, уделив особое внимание парадигме процедурного программирования.

Что такое процедурное программирование? [Определение]

Процедурное программирование может быть первой парадигмой программирования, которую изучает новый разработчик. По сути, процедурный код — это тот, который непосредственно инструктирует устройство о том, как завершить задачу логическими шагами. Эта парадигма использует линейный нисходящий подход и рассматривает данные и процедуры как две разные сущности. Основываясь на концепции вызова процедуры, процедурное программирование делит программу на процедуры, которые также известны как подпрограммы или функции, просто содержащие последовательность шагов, которые необходимо выполнить.

Проще говоря, процедурное программирование включает в себя запись списка инструкций, которые сообщают компьютеру, что он должен делать шаг за шагом, чтобы завершить поставленную задачу.

Ключевые особенности процедурного программирования

  • Предопределенные функции. Предопределенная функция обычно представляет собой инструкцию, идентифицируемую по имени. Обычно предопределенные функции встроены в языки программирования более высокого уровня, но они являются производными от библиотеки или реестра, а не от программы. Одним из примеров предопределенной функции является «charAt()», которая ищет позицию символа в строке.
  • Локальная переменная. Локальная переменная — это переменная, объявленная в основной структуре метода и ограниченная заданной ей локальной областью. Локальная переменная может использоваться только в методе, в котором она определена, и если она будет использоваться вне определенного метода, код перестанет работать.
  • Глобальная переменная. Глобальная переменная — это переменная, объявленная вне любой другой функции, определенной в коде. Благодаря этому глобальные переменные можно использовать во всех функциях, в отличие от локальных переменных.
  • Модульность. Модульность — это когда две разные системы выполняют две разные задачи, но сгруппированы вместе, чтобы сначала выполнить более крупную задачу. В этом случае каждая группа систем будет выполнять свои задачи одну за другой, пока не будут выполнены все задачи.
  • Передача параметров. Передача параметров — это механизм, используемый для передачи параметров функциям, подпрограммам или процедурам. Передача параметров может осуществляться через «передачу по значению», «передачу по ссылке», «передачу по результату», «передачу по значению-результату» и «передачу по имени».

Преимущества и недостатки процедурного программирования

Процедурное программирование имеет свои плюсы и минусы, некоторые из которых упомянуты ниже.

  • Предопределенные функции. Предопределенная функция обычно представляет собой инструкцию, идентифицируемую по имени. Обычно предопределенные функции встроены в языки программирования более высокого уровня, но они являются производными от библиотеки или реестра, а не от программы. Одним из примеров предопределенной функции является «charAt()», которая ищет позицию символа в строке.
  • Локальная переменная. Локальная переменная — это переменная, объявленная в основной структуре метода и ограниченная заданной ей локальной областью. Локальная переменная может использоваться только в методе, в котором она определена, и если она будет использоваться вне определенного метода, код перестанет работать.
  • Глобальная переменная. Глобальная переменная — это переменная, объявленная вне любой другой функции, определенной в коде. Благодаря этому глобальные переменные можно использовать во всех функциях, в отличие от локальных переменных.
  • Модульность. Модульность — это когда две разные системы выполняют две разные задачи, но сгруппированы вместе, чтобы сначала выполнить более крупную задачу. В этом случае каждая группа систем будет выполнять свои задачи одну за другой, пока не будут выполнены все задачи.
  • Передача параметров. Передача параметров — это механизм, используемый для передачи параметров функциям, подпрограммам или процедурам. Передача параметров может осуществляться через «передачу по значению», «передачу по ссылке», «передачу по результату», «передачу по значению-результату» и «передачу по имени».

Преимущества и недостатки процедурного программирования

Процедурное программирование имеет свои плюсы и минусы, некоторые из которых упомянуты ниже.

Преимущества

  • Процедурное программирование отлично подходит для программирования общего назначения.
  • Простота кода наряду с простотой реализации компиляторов и интерпретаторов
  • Большой выбор книг и материалов онлайн-курсов по проверенным алгоритмам, которые облегчают процесс обучения.
  • Исходный код является переносимым, поэтому его можно использовать и для другого процессора.
  • Код можно повторно использовать в разных частях программы без необходимости его копирования.
  • Благодаря методике процедурного программирования требования к памяти также резко сокращаются.
  • Ход программы можно легко отслеживать

Недостатки

  • При использовании процедурного программирования программный код писать сложнее
  • Процедурный код часто нельзя использовать повторно, что может потребовать повторного создания кода, если он потребуется для использования в другом приложении.
  • Трудно связать с реальными объектами.
  • Важное значение придается операции, а не данным, что может вызвать проблемы в некоторых случаях, связанных с данными.
  • Данные доступны для всей программы, что снижает безопасность

Как мы упоминали ранее, существуют различные типы парадигмы программирования, которые представляют собой не что иное, как стиль программирования. Важно понимать, что парадигма ориентирована не на конкретный язык, а на способ написания программы. Ниже приведено сравнение между процедурным программированием и объектно-ориентированным программированием.

Что такое объектно-ориентированное программирование (ООП)

ООП – это подход к программированию, который рассматривает жизнь в том виде, в каком мы ее знаем, как набор объектов, которые работают в тандеме друг с другом для решения конкретной задачи. Первое, что нужно знать об ООП, — это инкапсуляция, то есть идея о том, что каждый объект, содержащий программу, является самодостаточным, что означает, что все компоненты, составляющие объект, находятся внутри самого объекта. Теперь, поскольку каждый модуль в этой парадигме является самодостаточным, объекты можно взять из одной программы и использовать для решения другой проблемы с небольшими изменениями или без изменений.

Преимущества

  • Благодаря модульности и инкапсуляции ООП обеспечивает простоту управления.
  • ООП имитирует реальный мир, облегчая его понимание.
  • Поскольку объекты являются целыми сами по себе, их можно повторно использовать в других программах.

Недостатки

  • Объектно-ориентированные программы работают медленнее и потребляют много памяти.
  • Чрезмерное обобщение
  • Программы, созданные с использованием этой парадигмы, могут создаваться дольше

Процедурное программирование и объектно-ориентированное программирование: прямое сравнение

С другой стороны, процедурное программирование, в отличие от ООП, уделяет внимание шагам, которые будут выполняться для выполнения задачи, а не взаимодействию между объектами. Задачи разбиты на подпрограммы, переменные и структуры данных. В любой момент времени эти процедуры могут быть вызваны в процессе выполнения программы.

Другой часто используемой парадигмой программирования является функциональное программирование. Функциональное программирование сильно отличается как от процедурного программирования, так и от объектно-ориентированного программирования, поскольку оно использует математические функции. Благодаря этому операции выполняются только на основе введенных данных и не зависят от временных или скрытых переменных.

Преимущества

  • Функциональное программирование предлагает защищенную среду
  • В то время как многие другие языки требуют значительного объема информации для правильного выполнения операций, функциональное программирование устраняет необходимость в большом объеме кода, необходимого для определения состояний.
  • Поскольку эта парадигма зависит только от входных аргументов, побочных эффектов нет

Недостатки

  • Использование функционального программирования исключительно при разработке коммерческого программного обеспечения не рекомендуется и не допускается
  • Требуется большой объем памяти и времени.
  • Она может оказаться менее эффективной, чем другие парадигмы.

Заключение

Как мы уже говорили в этой статье, процедурное программирование — это больше то, что вы делаете, чем то, как вы это делаете. Это стандартный подход, используемый во многих компьютерных языках, таких как C, Pascal и BASIC. Хотя идеальной парадигмы программирования не существует, важно понимать, что правильная парадигма всегда будет зависеть от типа используемого вами языка и программы, которую вы хотите создать. Для достижения максимальных результатов и сильного портфолио рекомендуется владеть всеми тремя основными парадигмами программирования. Лучший способ улучшить парадигмы программирования — попробовать, и Hackr может вам в этом помочь.

Люди также читают:

Сагар Бхатия

Сагар имеет диплом инженера и увлекается технологиями. Уже более 5 лет он пишет статьи по различным дисциплинам. Сам заядлый геймер, он хочет создать предприятие, связанное с киберспортом в Индии. Просмотреть все сообщения автора

Портрет современного афроамериканца, вид сбоку, который смотрит на экран компьютера, работая до поздней ночи, пишет код, копирует пространство

Разработка программного обеспечения — это набор действий в области информатики, посвященных процессу создания, проектирования, развертывания и поддержки программного обеспечения.

Программное обеспечение — это набор инструкций или программ, которые сообщают компьютеру, что делать. Он не зависит от аппаратного обеспечения и делает компьютеры программируемыми. Существует три основных типа:

Системное программное обеспечение для обеспечения основных функций, таких как операционные системы, управление дисками, утилиты, управление оборудованием и другие необходимые операции.

Программное обеспечение для программирования, предоставляющее программистам такие инструменты, как текстовые редакторы, компиляторы, компоновщики, отладчики и другие инструменты для создания кода.

Возможный четвертый тип — это встроенное программное обеспечение. Программное обеспечение встроенных систем используется для управления машинами и устройствами, обычно не считающимися компьютерами, — телекоммуникационными сетями, автомобилями, промышленными роботами и многим другим. Эти устройства и их программное обеспечение могут быть подключены как часть Интернета вещей (IoT). 2

Разработкой программного обеспечения в основном занимаются программисты, инженеры-программисты и разработчики программного обеспечения. Эти роли взаимодействуют и пересекаются, а динамика между ними сильно различается в разных отделах разработки и сообществах.

Программисты или кодеры пишут исходный код для программирования компьютеров для определенных задач, таких как слияние баз данных, обработка онлайн-заказов, маршрутизация сообщений, выполнение поиска или отображение текста и графики. Программисты обычно интерпретируют инструкции разработчиков программного обеспечения и инженеров и используют для их выполнения такие языки программирования, как C++ или Java.

Инженеры-программисты применяют инженерные принципы для создания программного обеспечения и систем для решения проблем. Они используют язык моделирования и другие инструменты для разработки решений, которые часто можно применять к проблемам в общем виде, а не просто решать для конкретного экземпляра или клиента. Программные инженерные решения придерживаются научного метода и должны работать в реальном мире, как с мостами или лифтами. Их ответственность возросла по мере того, как продукты становились все более интеллектуальными благодаря добавлению микропроцессоров, датчиков и программного обеспечения. Мало того, что все больше продуктов используют программное обеспечение для дифференциации рынка, разработка программного обеспечения должна координироваться с разработкой механических и электрических компонентов продукта.

У разработчиков программного обеспечения менее формальная роль, чем у инженеров, и они могут быть тесно связаны с конкретными областями проекта, включая написание кода. В то же время они управляют общим жизненным циклом разработки программного обеспечения, включая работу функциональных групп по преобразованию требований в функции, управление группами разработчиков и процессами, а также тестирование и обслуживание программного обеспечения. 3

Важным отличием разработки программного обеспечения на заказ от разработки коммерческого программного обеспечения является разработка программного обеспечения на заказ. Разработка программного обеспечения на заказ — это процесс проектирования, создания, развертывания и обслуживания программного обеспечения для определенного набора пользователей, функций или организаций. Напротив, готовое коммерческое программное обеспечение (COTS) разработано с учетом широкого набора требований, что позволяет его упаковывать, продавать и распространять на коммерческой основе.

сравнение парадигм программирования

Как начинающий или, возможно, опытный специалист по кодированию, вы совершили невероятное путешествие, изучая типы данных, поток управления программой, функции и, возможно, даже классы. И эти фундаментальные строительные блоки действительно замечательны — они обеспечивают лучшее понимание и возможности для решения проблем как в ваших непосредственных усилиях по разработке, так и при абстрактном решении проблем в реальных приложениях (включая строительство, стратегическое бизнес-планирование, организацию и анализ). . Теперь вы готовы изучить стратегию и методологию разработки программного обеспечения.

Процедурное программирование

Вплоть до этого момента вы, вероятно, собирали блоки кода от начала до конца процедурным образом. Эта «процедура», о которой я упоминаю, ставит вас в очередь на процедурное программирование.

Процедурное программирование (PP) прекрасно, потому что оно простое, как правило прямолинейное (или может быть написано так, что оно прямолинейно), и при правильном дизайне оно обеспечивает хорошую изоляцию и сдерживание переменных при правильном использовании функций и циклов управления. . Несмотря на элегантность и простоту, предлагаемые PP, при создании чего-то наступает момент, когда вы начинаете понимать, примерно после 5000 строк, как я предполагаю, что ваш проект становится более запретительным для поддержки — можете ли вы представить, что вам нужно прочесать 6000 LOC только для того, чтобы обновить задержку setTimeout для функции сканирования? Становится легче разбивать код на более модульные блоки, которые взаимозависимо работают вместе. Познакомьтесь с объектно-ориентированным программированием (ООП) и дизайном.

Объектно-ориентированное программирование (ООП)

Когда вы начали читать эту статью, она шла в логическом порядке от начала до конца. Представьте, что эта статья продолжается для бесконечных символов. Это будет большая книга!Если бы я сказал вам дать мне первое предложение на предпоследней странице, вы бы почувствовали себя обескураженными бременем, прежде чем самодовольно ответить: «Конечно, пожалуйста, предоставьте math.ceil(∞) – 2, и я получу для вас это предложение! ”

Преобразование бесконечного сборника статей в объектно-ориентированный дизайн было бы похоже на преобразование этой статьи в книгу о приключениях по принципу «выбери свое собственное приключение». Разбивая контент на части, мы вместо этого получили бы независимые асинхронные единицы (хотя и число ∞), которые могли бы агрегировано, модульно работать, чтобы заполнить составное решение для множества деловых и научных приложений. Объектно-ориентированный дизайн выполняет нетривиальные вычислительные задачи с помощью фабрик (классов), которые создают виджеты (экземпляры с одной копией, определенные как «объект», используемый для обработки, оценки или хранения вычислений).

На дворе 2016 год, а язык C "With Classes" существует с 1979 года (верно, C++ скоро исполняется 40 лет). Более ранние языки, такие как Simula67, появились на десять лет раньше и заложили фундаментальные основы для более поздних языков. Симула возникла и использовалась при разработке симуляций. Объекты/объектно-ориентированное проектирование нашли место в программном обеспечении для моделирования, например, при моделировании вероятности авиакатастрофы из-за проблемы с двигателем, проблемы с погодой или проблемы среднего времени наработки на отказ из-за ухудшения целостности конструкции. Каким образом можно хранить и извлекать значения различных переменных, необходимых для расчета авиакатастрофы? Как можно сделать такое программное обеспечение абстрактным, чтобы *любой* объект моделирования самолета можно было определить с точки зрения веса, амортизационного возраста, погодных условий и т. д.? Такие проблемы возникают и в других приложениях. Магазинные фабрики, стремящиеся к повышению производительности, моделированию запасов и прогнозированию, секвенированию генов; все эти отрасли извлекли огромную пользу из решений, предложенных с появлением объектно-ориентированной методологии. Термин «объектно-ориентированное программирование» на самом деле восходит к Xerox в связи с инновациями в «тогда еще новом» языке Smalltalk в начале 1970-х годов.

Сравнение парадигм программирования: PP и OO

Вы можете удивиться, почему мы не начинаем с объектно-ориентированного проектирования с самого начала. Для этого есть веские причины. Примечательно, что большая часть тяжелой работы по разработке требует тщательного планирования и предусмотрительности текущих и будущих проектных соображений. Возьмем, к примеру, почтовый индекс. Почтовые индексы в Соединенных Штатах являются числовыми и могут быть представлены в виде пятизначного целого числа. Если ваша система ведения записей настроена таким образом, что у вас есть числовое поле в таблице базы данных, это поле вернет ошибку, если вы попытаетесь ввести буквы или символы — перемотка вперед на два года, бизнес был отлично, и ваш босс хотел бы увидеть экспансию в Канаду! О-о… Вы разработали поле как целое число — ваша логика проверки основана на том, что это возвращаемое целое число, вы создали бизнес-логику для обработки определения стоимости доставки на основе значения этого конкретного целого числа с помощью итераторов сравнения ( )… изменив его на простое целое не подойдет. В этом, друзья мои, важность предусмотрительности, и именно поэтому необходимо тщательно проанализировать проектные соображения, прежде чем приступать к созданию приложения. Связывание объектно-ориентированного проектирования с целями программирования может значительно увеличить время разработки и усовершенствования. Наличие нескольких предполагаемых вариантов использования до начала разработки может помочь вам решить, следует ли абстрагировать кодовую базу до повторно используемых модульных объектов.

Теперь, прежде чем вы решите отказаться от своего стиля процедурного программирования из своих привычек кодировщика, учтите, что существуют недоброжелатели ООП-дизайна, в том числе немало разумной критики, предупреждающей об опасностях «ложного» мышления ООП. Лука Карделли разделяет разумные опасения в исследовательской статье под названием «Плохие инженерные свойства объектно-ориентированных языков». Сравнивая многие преимущества процедурного программирования, полученные в ходе совершенствования и усовершенствования техники, Лука возражает против того, что те же самые выгоды не могут быть выражены с помощью концепций объектно-ориентированного программирования. Цитата из книги

«Несмотря на то, что повторное использование — это большая победа объектно-ориентированных языков, дело также в том, что эти языки имеют очень плохие свойства модульности в отношении расширения и модификации классов. Например, легко переопределить метод, который не следует переопределять, или переопределить класс таким образом, что возникнут проблемы в подклассах».

Кроме того, «Smalltalk изначально задумывался как язык, который будет легко выучить. C++ основан на довольно простой модели, унаследованной от Simula, но в остальном пугает сложностью своих многочисленных функций. Где-то на линии что-то пошло не так; то, что начиналось как экономное и единообразное («все есть объект»), превратилось в причудливую коллекцию классовых разновидностей».

Вопреки распространенному мнению, что ООП был панацеей компьютерных наук в течение последних 30 лет, особенно после распространения Java в середине-конце 90-х годов. Например, если вы взглянете на Stackoverflow, вы обнаружите настолько сильную поддержку ООП, что многие клянутся «любым намеком на процедурное программирование» как худшее в отношении возможности повторного использования кода, производительности и разделения задач. Однако контрапунктом ООП является то, что часто ограничения бюджета и сложности вынуждают команды выбирать принципы, когда это удобно, и не обязательно последовательно следовать концепциям из-за чрезмерной сложности и затрат (часто наблюдается в сквозных задачах между подклассами, чтобы сократить / подорвать). процесс рефакторинга правильной инкапсуляции и прототипного наследования при передаче сообщений между объектами).

Окончательный вердикт

Какую методологию выбрать? Я рад поделиться тем, что ответ не должен быть «это зависит»! На самом деле, ответ (на мой взгляд) заключается в том, что обе парадигмы должны использоваться вместе, независимо друг от друга в рамках одной и той же кодовой базы, где имеет смысл создание экземпляров объектов для хранения логики приложения. Используйте функции для инкапсуляции и объединяйте функциональность и интерфейсы в модули для экспорта и использования по мере необходимости при работе с блоками кода процедурного уровня в вашем приложении. Процедурный язык можно использовать исключительно в том случае, если архитектура ООП не обеспечит никаких преимуществ повторного использования в долгосрочной перспективе. Объектно-ориентированное программирование — это методология, с помощью которой мы можем лучше организовать нашу кодовую базу, чтобы проекты, содержащие более 5000 строк, не выходили из-под контроля. Кроме того, такие аспекты, как инкапсуляция, создание экземпляров, принципы DRY, легче реализовать с помощью методологий ООП.

Другие аспекты, которые следует учитывать, включают производительность и ремонтопригодность. Если вы действительно намереваетесь иметь специализированную программу, которая не будет иметь требований к изменениям, разработанную для высокой производительности, ваши усилия будут лучше работать при построении с концепциями PP. Короткий скрипт, такой как программы, которые запускаются против crontab, Windows Powershell или Launchctl, сияет здесь. Любое приложение, существующее за пределами командной строки, требующее асинхронного поведения, графического интерфейса или любых многопоточных приложений, получит большие выгоды и преимущества, используя методологию ООП. Модульность также следует использовать в качестве ориентира.

Планируете ли вы реализовать основную программу с несколькими отличительными функциями, которые можно было бы поместить в один файл размером менее нескольких тысяч строк? Рассмотрите возможность хранения функций, поддерживаемых локально, в одном файле с помощью методологии PP.

Планируете ли вы реализовать функции как часть более крупного приложения? Некоторые примеры функций, которые могут быть частью более крупного приложения, включают систему подсчета очков или систему инвентаризации в игре, модуль электронной почты, который используется как часть пакета программного обеспечения для создания отчетов, файл подключения к базе данных; все это примеры того, как модульный подход предпочтительнее благодаря преимуществам повторного использования кода без нарушения принципов DRY.

Заключение

Выявленная основная проблема звучит так: "Как, Фрэнк, я узнаю, что готов перейти к концепциям ООП?" По общему признанию, трудно понять, когда имеет смысл идти одним путем, а когда другим. Если время на вашей стороне и сложность достаточно высока, правильным подходом является выбор маршрута ООП в качестве предпочтения дизайна. Если у вас есть случай использования в экстренной ситуации, когда вам нужно исправить критическое исправление для рабочего сервера, то, безусловно, PP является идеальным методом для реализации и развертывания вашего исправления в рабочей среде. Просто помните, что нет жесткого/быстрого правила. Выберите комбинированную стратегию использования концепций обеих методологий, когда того требуют обстоятельства.

Создавали ли вы процедурное приложение, которое впоследствии пришлось преобразовать в объектно-ориентированное, и заметили ли вы в результате повышение производительности? Давайте обсудим в комментариях ниже.

Связанные руководства, которые могут вас заинтересовать:

Биография автора

Франкенминт — технофил со склонностью к биткойнам, разбирающийся в веб-разработке и разработке программного обеспечения.

Читайте также: