Основной модульный принцип построения компьютерной презентации

Обновлено: 04.07.2024

Презентация на тему: "Ch:10 Component Level Design Unit 4. Что такое компонент? Компонент представляет собой модульный строительный блок компьютерного программного обеспечения, поскольку компоненты находятся внутри." — Транскрипт:

1 Ch:10 Модуль проектирования уровня компонентов 4

2 Что такое компонент? Компонент представляет собой модульный строительный блок для компьютерного программного обеспечения. Поскольку компоненты находятся в архитектуре программного обеспечения, они должны взаимодействовать и взаимодействовать с другими компонентами и объектами, которые существуют за пределами программного обеспечения Объектно-ориентированное представление Традиционное представление Представление, связанное с процессом < бр />

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

4 Традиционный взгляд В контексте традиционной разработки программного обеспечения компонент — это функциональный элемент программы, который включает в себя логику обработки, внутреннюю структуру данных, необходимую для реализации логики обработки, и интерфейс, который позволяет вызывать компонент и передавать данные. передать ему

5 Он также называется модулем, находится в архитектуре ПО и выполняет одну из трех важных ролей: – Компонент управления, который координирует вызов всех других компонентов предметной области – Компонент предметной области, реализующий полную или частичную функцию который требуется заказчику — компонент инфраструктуры, который отвечает за функции, поддерживающие обработку, требуемую в проблемной области

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

7 Проектирование компонентов на основе классов Основные принципы проектирования Рекомендации по проектированию на уровне компонентов Сплоченность

8 основных принципов проектирования Принцип открытости-закрытости (OCP): «Модуль должен быть открыт для расширения, но закрыт для модификации». Компонент должен быть расширен без необходимости внесения внутренних изменений (логический уровень/код) в сам компонент. Принцип замещения Лискова (LSP): «Подклассы должны быть взаимозаменяемыми для своих базовых классов». Компонент, использующий базовый класс, должен продолжать функционировать должным образом, если вместо этого компоненту передается класс, производный от базового класса

9 Принцип инверсии зависимостей (DIP): «Зависите от абстракций. Не полагайтесь на конкреции». Абстракции — это то место, где дизайн можно расширить без особых сложностей. Чем больше компонент зависит от конкретных компонентов, тем сложнее будет расширить Принцип разделения интерфейсов (ISP): «Многие интерфейсы для конкретных клиентов лучше, чем один интерфейс общего назначения». Мы должны создать специализированный интерфейс для обслуживания каждой основной категории клиентов

10 Принципов упаковки Принцип эквивалентности повторного использования релиза (REP): «Гранула повторного использования — это гранула релиза». Целесообразно сгруппировать повторно используемые классы в пакеты, которыми можно управлять и контролировать по мере развития новых версий. Общий принцип закрытия (CCP): «Классы, которые изменяются вместе, принадлежат друг другу». Когда классы упаковываются как часть дизайна, они должны относиться к одной и той же функциональной или поведенческой области. (классы должны быть упакованы связно) Общий принцип повторного использования (CRP): «Классы, которые не используются повторно вместе, не должны группироваться вместе». Таким образом, в пакет следует включать только те классы, которые повторно используются вместе

11 Рекомендации по проектированию на уровне компонентов Компонент – Соглашения об именах Интерфейсы – Должны отображаться только те интерфейсы, которые относятся к рассматриваемому компоненту Зависимости и наследование – Зависимости следует моделировать слева направо, а наследование следует моделировать снизу вверх

12 Cohesion Типы связности – Функциональная: проявляемая операциями, этот уровень связанности возникает, когда компонент выполняет целевое вычисление, а затем возвращает результат – Слой: демонстрируемый пакетами, компонентами и классами, этот тип связности возникает, когда более высокий уровень имеет доступ к услугам более низкого уровня, но более низкий уровень не имеет доступа к более высокому уровню

13 – Коммуникативный: все операции, которые обращаются к одним и тем же данным, определены в одном классе – Общая связь: имеет место, когда несколько компонентов используют глобальную переменную

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

15 – Связывание управления: происходит, когда операция A() вызывает операцию B() и передает флаг управления в B – Связывание штампа: происходит, когда класс B объявлен как тип для аргумента операции класса A – Связывание данных : Происходит, когда операции передают длинные строки аргументов данных – Связывание обычных вызовов : Происходит, когда одна операция вызывает другую – Связывание использования типа : Происходит, когда компонент A использует тип данных, определенный в компоненте B

16 – Включение или связывание импорта: происходит, когда компонент A импортирует или включает пакет или содержимое компонента B. – Внешнее связывание: происходит, когда компонент обменивается данными или сотрудничает с компонентами инфраструктуры (функции ОС, телекоммуникационная функция)

17 шагов для проведения проектирования на уровне компонентов. Определите все классы дизайна, соответствующие предметной области. Определите все классы дизайна, соответствующие предметной области инфраструктуры: компоненты графического интерфейса пользователя, компоненты ОС и компоненты управления данными. повторно используемые компоненты – Укажите детали сообщения, когда классы или компоненты взаимодействуют (сообщения, передаваемые между объектами) – Определите соответствующие интерфейсы для каждого компонента

18 – Разработайте атрибуты и определите типы данных и структуры данных, необходимые для их реализации. Подробно опишите поток обработки в рамках каждой операции (псевдокод/диаграмма действий). Опишите постоянные хранилища данных и определите классы, необходимые для управления ими. Разработайте и проработайте поведенческое представление для класса или компонента: используется диаграмма состояний. Пример (как состояния меняются от одного состояния к другому) Разработка диаграмм развертывания для предоставления дополнительных сведений о реализации Рефакторинг каждого представления проекта на уровне компонентов и всегда рассмотрение альтернатив

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

20 Дизайн контента на уровне компонентов фокусируется на объектах контента и способе их упаковки для представления конечному пользователю WebApp. Формальность дизайна контента на уровне компонентов должна соответствовать характеристикам создаваемого веб-приложения. Дизайн контента на уровне компонентов

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

22 Проектирование традиционных компонентов Нотация графического дизайна Нотация табличного дизайна Язык разработки программ

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

24 Обозначение табличного дизайна Во многих приложениях может потребоваться модуль для оценки сложной комбинации условий и выбора соответствующих действий на основе этих условий. Таблица решений предоставляет нотацию, которая переводит действия и условия в табличную форму. Он состоит из четырех разделов: (1) Операторы условий (2) Записи условий (3) Операторы действий (4) Записи действий

25 Правила ConditionDecision Заявления условийЗаписи условийЗаписи действий Заявления действийЗаписи действий

26 Язык разработки программ PDL также называется структурированным английским языком или псевдокодом. Разница между PDL и реальным языком программирования заключается в использовании описательного текста (например, на английском языке), встроенного непосредственно в операторы PDL. Базовый синтаксис PDL должен включать конструкции для определения компонента, описания интерфейса, объявления данных, конструкции условия и повторения, конструкции ввода-вывода и т. д.

27 Разработка на основе компонентов Разработка программного обеспечения на основе компонентов (CBSE) — это процесс, в котором основное внимание уделяется проектированию и созданию компьютерных систем с использованием программных компонентов многократного использования. Этапы: 1. Разработка предметной области 2. Квалификация, адаптация и композиция компонентов 3. Анализ и дизайн для повторного использования 4.Классификация и получение компонентов

28 Проектирование домена Целью проектирования домена является идентификация, создание, каталогизация и распространение набора программных компонентов, применимых к существующему и будущему программному обеспечению в конкретной прикладной области. Он включает три основных действия: –Анализ –Конструирование – Распространение (трансляция, распространение)

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

Кстати, этот блог является первым в серии статей о том, как мы используем принципы программирования в Tiny, так что следите за будущими статьями.

Давайте начнем с некоторых определений.

Что такое модульное программирование?

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

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

Хотя большинство людей говорят о модульности на уровне файлов/папок/репозиториев, я думаю о модульности на нескольких уровнях:

Функции внутри файлов
Файлы в репозиториях/библиотеках
Библиотеки/репозитории в проектах

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

Модули и API

Одним из очень полезных способов взаимодействия модулей является использование интерфейсов или API. С помощью API вы показываете только то, что нужно разработчикам для использования модуля, скрывая при этом внутренности кода.

В некотором смысле это означает, что ваш API может действовать как контракт, определяя, что делает модуль/библиотека и как они могут использоваться внешним кодом. Например, API может сказать: «У этого модуля есть функция, которая делает это и возвращает это».

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

Модульное программирование в Tiny

Мы в Tiny очень любим модульность. Например, монорепозиторий TinyMCE содержит несколько модулей, каждый из которых содержит код, относящийся к определенной функциональности. Например:

Катамари – используется для структур данных.
Sugar – Манипулирование HTML DOM – наш тестировщик

Каждый «модуль» содержит файлы и папки, соответствующие определенным правилам. Katamari — хороший пример со своими папками API и Util, которые содержат определенные виды кода в соответствии с нашими стандартами и рекомендациями. Затем папка API содержит файл для каждой концепции, предоставляемой через API Katamari, и все они собраны в файле Main.ts. Таким образом, если мы хотим узнать, какие методы у Katamari есть для массивов, мы можем просто заглянуть в Main.ts, чтобы увидеть, что предоставляет Katamari, а оттуда перейти к любому из файлов API, например Arr.ts, который содержит методы. для работы с массивами. Это позволяет быстро и легко найти нужный код.

В результате такой архитектуры TinyMCE сам состоит из большого дерева зависимостей библиотек вспомогательных функций (построенных на дополнительных библиотеках вспомогательных функций!), которые в конце объединяются в редактор. Это может показаться сложным, но мы считаем, что преимущества того стоят.

Зачем модульное программирование?

Цель модульного программирования – упростить разработку и обслуживание больших программ путем их разбиения на более мелкие части. Он имеет ряд преимуществ:

Код легче читать

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

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

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

Код легче тестировать

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

Кроме того, более простое тестирование может означать, что требуется меньше объемных и подробных комментариев, поскольку тесты могут служить примерами того, как работает код. Если вы не понимаете какой-либо блок кода, проверка тестов может быть простым способом получить хорошее представление о нем.

Легкий поиск вещей позже

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

Вспомогательные функции Unicode
Вспомогательные методы для работы с объектами
Вспомогательные методы для массивов

… и этот список можно продолжить. Разделение функций таким образом может значительно ускорить и упростить поиск нужной информации позже.

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

Повторное использование без раздувания

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

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

Единый источник для быстрого исправления

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

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

Обновление проще и с меньшим риском

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

Легкий рефакторинг

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

В конце 2017 года мы преобразовали TinyMCE в TypeScript. В рамках этого преобразования мы также реструктурировали TinyMCE, сделав его более модульным, разделив большую часть кода на плагины и библиотеки. Затем мы смогли использовать эту повышенную модульность и, в частности, структуру API, которую мы представили при автоматизации частей преобразования TypeScript. Это также помогло с последующей ручной работой, так как мы могли работать в разделах, плагин за плагином и библиотека за библиотекой. И годы спустя он по-прежнему помогает нам в адаптации новых разработчиков, поиске и исправлении ошибок, добавлении новых функций и многом другом.

Легче сотрудничать

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

Вы также можете назначать права собственности на определенные модули кода, чтобы команды несли ответственность за свою часть программного обеспечения и позволяли им разбивать работу на более мелкие задачи. Команды (и модули) объединяются с помощью четко определенных интерфейсов и общедоступных API, что гарантирует совместимость всех компонентов при развертывании.

Есть ли недостатки?

Должна быть причина, по которой некоторые люди не занимаются модульным программированием, верно? Ну да.

Альтернативой модульному программированию обычно является создание монолитного приложения кода, в котором весь ваш код (более или менее) хранится в одном месте. Это может привести к «коду спагетти», поскольку он скрученный и запутанный, как большая миска спагетти 🍝

На самом деле есть несколько причин, по которым некоторые люди до сих пор пишут спагетти-код:

Размер кода. Модульность может увеличить размер кода и повлиять на производительность, если вы не можете изменить структуру зависимостей.
Сложность. Иногда сложные файловые системы не нужны и могут привести к дополнительным издержкам.
Безопасность. Монолитный код может усложнить людям работу с кодом, который исходный разработчик не хочет изменять, взломать или пиратить.

И давайте будем честными: некоторым людям просто нравится жить на грани. Это волнующе, когда ты не уверен, что (в тысячах строк кода) не работает 😆

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

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

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

Будущее модульного программирования

Модульное программирование – не новая концепция, но она по-прежнему очень популярна. Я думаю, что разработчикам важно узнать, что это такое и почему это полезно. В конце концов, то, как многие современные библиотеки, платформы и менеджеры пакетов настроены для совместного использования кода и управления зависимостями, делает модульное программирование естественным выбором.

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

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

Использование TinyMCE с сборщиком модулей

Уже внедряете принципы модульного программирования в свои проекты или хотите поэкспериментировать с этой концепцией?

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

Вы занимаетесь модульным программированием? Почему или почему бы и нет?

Давайте продолжим обсуждение в Твиттере @joinTiny. Расскажите нам, используете ли вы или ваша команда модульное программирование и почему. И дайте нам знать, какой ваш любимый инструмент, который поможет вам сделать ваш код модульным!

Подпишитесь на нашу рассылку, чтобы не пропустить остальные наши блоги из этой серии!

Модульное программирование – это метод проектирования программного обеспечения, в котором основное внимание уделяется разделению функциональных возможностей программы на независимые взаимозаменяемые модули, каждый из которых содержит все необходимое для выполнения только одного аспекта желаемой функциональности. [1]

Концепция модуляризации

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

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

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

определить функцию (ее определение или код, который она будет выполнять)
вызвать функцию
объявить функцию (прототип — это объявление для компилятора)

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

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

нет связи на входе и нет связи на выходе
нет входящей связи с некоторой исходящей связью
некоторая связь входящая и некоторая исходящая информация
некоторые входящие сообщения без исходящих сообщений

Функция управления программой

Главной частью программы во многих языках программирования является специальная функция с идентификатором main. Особенность или уникальность main как функции заключается в том, что именно здесь программа начинает выполнение кода, и именно здесь она обычно останавливает выполнение кода. Часто это первая функция, определенная в программе, и она появляется после области, используемой для включения, других технических элементов, объявления прототипов, списка глобальных констант и переменных и любых других элементов, обычно необходимых программе. Предоставляется код для определения функции main; однако она не является прототипом и обычно не вызывается, как другие функции в программе.

Конкретная функция задачи

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

Общий вид функции на языке с динамической типизацией, таком как JavaScript и Python:

В некоторых языках программирования функции имеют набор фигурных скобок <>, используемых для обозначения группы или блока операторов или строк кода. Другие языки используют отступы или некоторые типы операторов начала и конца для идентификации блока кода.Обычно функция состоит из нескольких строк кода.

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

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

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

Большинство программ имеют несколько элементов перед функциями, в том числе:

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

Ключевые термины

Ссылки

Лицензия

Книга «Основы программирования» Кеннета Лероя Басби и Дэйва Брауншвейга распространяется под лицензией Creative Commons Attribution-ShareAlike 4.0 International License, если не указано иное.

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

Боян — старший веб-дизайнер и разработчик интерфейса, специализирующийся на дизайне UX, с 12-летним опытом разработки для веб-сайтов и мобильных устройств.

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

Модули на веб-сайте очень похожи на Lego. Думайте о модулях как о деталях Lego, которые позволяют вам создавать свой веб-сайт. Когда вы соединяете их вместе правильным образом, они образуют веб-страницы. Чтобы создавать веб-сайты, такие как Lego, вы должны думать о веб-сайтах как о наборе независимых модулей. Эта статья поможет вам сделать именно это при разработке интерфейса и дизайне.

Модульные коллажи

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

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

Вот часть моего недавнего коллажа модулей, пример кнопки, которую я разработал в Sketch в начале проекта:

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

Браузер – это естественная среда для веб-сайта, поэтому использование идей, созданных в графическом редакторе, может иметь неприятные последствия. Вполне естественно тестировать и принимать проектные решения в браузерах. Вы слышали это раньше, вы услышите это снова — дело не в том, как это выглядит, а в том, как это работает.

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

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

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

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

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

Создание модулей для фронтенд-разработки

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

Модульное проектирование тесно связано с модульной разработкой в рамках итеративного процесса. Я кодирую модуль, затем пробую его в браузере, чтобы увидеть, как он работает, а затем повторяю, если необходимо. Опять же, этот процесс очень похож на сборку конструктора «Лего»: вы проектируете и разрабатываете одновременно и пробуете разные варианты, пока не ощутите себя хорошо.

Я часто начинаю разработку модулей с создания чего-то простого, например кнопки. Представьте, что вы создаете его самостоятельно, и вам нужно закодировать оранжевую кнопку, обычно используемую для контактной формы. Вот что вы можете придумать:

Достаточно просто, не так ли? Вы бы применили класс .submit-button к своему HTML, и это решило бы вашу текущую проблему. А что произойдет, если вам понадобится создать новую кнопку, точно такую же, но с синим цветом фона? Вы, вероятно, скопировали бы именно этот класс, а затем изменили бы имя класса и цвет фона. Быстро и грязно. Теперь представьте, что вам нужно использовать ту же кнопку, но с оранжевым фоном. Вы можете видеть, к чему это идет — вы можете получить много повторений CSS. В очень маленьком проекте это может не стать реальной проблемой, но в более крупных, вероятно, станет. Прежде чем вы это заметите, ваш CSS раздуется, и его будет сложно поддерживать.

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

Код беспорядочный, непоследовательный, сложный для сканирования и понимания.
Раздутый код и XXL-файлы CSS с большим количеством дубликатов.
Код, который сложно поддерживать.
Отсутствие разделения структуры и оболочки.

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

Один из способов избежать или свести к минимуму эти проблемы – использовать модульный подход.

Модульная кнопка

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

Мы сделали разумное разделение стилей. Класс .button содержит стили, используемые каждой кнопкой в вашем проекте, поэтому вам не нужно повторять его. Класс .button-orange использует только те стили, которые относятся к оранжевой кнопке. Вы должны сделать то же самое для всех других кнопок и определить их цвет фона и текста.

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

А что насчет более сложных вещей?

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

Для дальнейшего чтения по модульной разработке интерфейса я настоятельно рекомендую SMACSS, архитектуру, которую я обычно использую во всех своих проектах, больших или малых.

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

Вовлечение клиента

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

Обычно я представляю модули клиенту так же, как это делает Bootstrap: настройка изолированного модуля вместе с его кодом — отличный способ вовлечь в процесс всех дизайнеров, разработчиков и клиентов.< /p>

Используйте созданные вами модули в качестве строительных блоков для страниц. Для вашей индексной страницы вы можете поместить модуль навигации вверху, затем модуль героя, затем некоторые модули контента, а затем нижний колонтитул. Прежде чем вы это узнаете, у вас уже есть страница для прототипа HTML. Но что такое прототип? Мне всегда нравилось определение прототипа, данное Лией Бьюли из ее замечательной книги «Команда взаимодействия с пользователем»:

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

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

Повторное использование строительных блоков

Модули и прототипы позволят вам повторно использовать код для текущего проекта, а также для будущих проектов. Настройка модуля из вашего последнего проекта может сэкономить вам много времени — модули, которые вам нужны в каждом проекте, часто похожи. У меня есть большая библиотека модулей, которые я часто использую повторно: вкладки, навигационные меню, кнопки, хлебные крошки, формы, таблицы, нумерация страниц, списки и т. д. Хотя код этих модулей не совсем одинаков во всех проектах, хорошие его фрагменты можно использовать повторно, что сэкономит мне много времени на разработку. Мой вам совет: создавайте повторно используемые модули и для себя. Ознакомьтесь с BASSCSS, Pure и Refills, чтобы вдохновиться.

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

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

< /p>

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

В этой статье мы рассмотрим лучшие методы создания модульных приложений, но сначала давайте начнем с введения в модульные приложения.

Введение в разработку модульных приложений

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

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

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

Почему важна модульность?

Эффективная разработка программы

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

Множественное использование подпрограмм

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

Простота отладки и модификации

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

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

Разработка модульных приложений

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

Модулизируйте по функциям

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

Модулизация кода по функциям имеет следующие ключевые характеристики:

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

Модулизируйте по слоям

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

Модулизация кода по уровням имеет следующие ключевые характеристики:

Этот подход позволяет сократить количество изолированных модулей и упрощает управление.
Только слои можно повторно использовать для нескольких приложений
Похоже на монолитные приложения.

Разработка модульных приложений

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

Понимание деталей проекта

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

Сделайте свой код простым

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

Использовать абстрактные интерфейсы

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

СУХОЕ кодирование

Держите код СУХИМ или не повторяйтесь. DRY — это ключевой принцип разработки программного обеспечения, поскольку он гарантирует, что никакая часть информации не будет сохранена дважды в разных частях исходного кода программы.

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

Используйте понятные имена

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

Заключение

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

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

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

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