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

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

открытые подпрограммы

  • выполнить строки кода

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

закрытые подпрограммы

  • проверить входные параметры
  • выполнить строки кода

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

функции

  • проверить входные параметры
  • выполнить строки кода для входных параметров
  • возвращаемое значение результата

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

методы

  • проверять объекты ввода
  • применить алгоритм к собственному объекту с входными объектами
  • вернуть объект результата

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

Таким образом, ключевые факторы роста структуры подпрограмм двояки: Принцип единой ответственности (SRP) и Не повторяйтесь (DRY). SRP помогает иметь части кода, посвященные одной ответственности. Его можно писать, просматривать, анализировать, тестировать и рефакторить изолированно, что способствует более чистому коду. DRY помогает упростить навигацию, чтение и изменение кода.

Итак, куда это может пойти отсюда, каков следующий шаг?

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

Каковы ваши идеи для следующего большого скачка в мире подпрограмм?