Я видел это в контексте классов. Я подозреваю, что это означает, что класс может использовать разбивку на логические субъединицы, но я не могу найти хорошее определение. Не могли бы вы привести несколько примеров?
Спасибо за помощь.
Изменить: мне нравятся интеллектуальные ответы, но я, очевидно, имею в виду "монолитный" в контексте программного обеспечения. Я знаю о монолитах, мегалитах, дольменах и всех связанных с камнем контекстах. Да, у меня их достаточно в моей стране...
Интересный вопрос. Я не думаю, что есть какие-то формальные определения того, что такое монолитный класс, но у вас есть идея. Класс, который содержит несколько компонентов, логически несвязанных или бессмысленно связанных, является монолитным классом.
Если вы прочитали The Pragmatic Programmer, который я настоятельно рекомендую, вы можете определить монолитный класс как анти-шаблон, который противоречит почти всему, что из этой книги.
Как для примеров, вы найдете больше в области дизайна чипов и ОС, где есть формальные определения монолитных чипов /ядра, которые похожи на монолитный класс. Вот несколько примеров, хотя каждый из них может возражать против того, чтобы быть в этом списке:
Если вы начали программировать самостоятельно, а не присоединяетесь к команде, то есть вероятность, что вы можете открыть один из своих первых проектов, и будет монолитный класс.
Если вы посмотрите на этимологию слова, вы увидите, что оно происходит от греческих монов (одиночных) и литонов (камень). В контексте программного обеспечения, как вы его упоминаете, он описывает одноранговое приложение в котором код для пользовательского интерфейса и доступа к данным объединен в одну программу с единой платформы.
"Монолит" - это термин, который использовался для успешного использования программного обеспечения. Эта ссылка раскрывает предположения, присущие термину, и их ограниченную полезность.
Основное предположение состоит в том, что система работает лучше, если она построена из программных компонентов, каждая из которых имеет индивидуальную, четко определенную задачу. Интуитивно это кажется правильным. Если каждый компонент работает, вся система должна работать, правильно?
На самом деле это не так просто. Большая, композиционная (немонолитная) система может пропустить критическую функцию, даже если в ней нет ни одного компонента. Это происходит, когда архитектурный дизайн не может выделить функцию для любого конкретного компонента. Это может произойти, особенно если это функция, которая не однозначно отображает один компонент.
Теперь Linux (для продолжения связанного примера) на самом деле не монолитен. Он имеет модульное пользовательское пространство поверх монолитного ядра, пользовательское пространство, которое поставляется со многими отдельными утилитами. За исключением случаев, когда это не так.
Это означает, что что-то противоположно модульной. Модульное приложение может иметь части, называемые модулями, заменяемые без необходимости замены всего приложения. Принимая во внимание, что монолитное приложение после частичной или обновленной части должно быть полностью заменено.
Из Wikipedia: "Модульность желательно, в общем, поскольку она поддерживает повторное использование частей логики приложения, а также облегчает обслуживание разрешая ремонт или замену частей приложения без необходимости замены оптом".
Итак, в контексте монолитного класса все его функции являются автономными, и если вы хотите добавить или изменить функцию в класс, вам нужно будет изменить/добавить код в класс и перекомпилировать его. И наоборот, модульный класс предоставляет доступ к функциональности, которая реализуется извне. Например, класс "Калькулятор" может использовать отдельный класс "Добавить" для фактического добавления чисел; вызвать функцию "Умножить" из отдельной библиотеки; или даже вызвать функцию "Амортизация" из веб-службы. Пока каждая из этих функциональных частей может быть изменена извне из класса, она является модульной.
Мое определение монолитного дизайна в разработке программного обеспечения - это дизайн, который требует добавления дополнительных функциональных возможностей в единый неделимый блок кода.
PRO:
МИНУСЫ:
Монолитная архитектура - это модель структуры программного обеспечения, которая создается как единое целое, где все инструменты Rails (ActionMailer, ActiveJob, ActionCable и т.д.) Могут быть собраны вместе с кодом, который применяются этими инструментами. Инструменты не связаны друг с другом, но они также не являются автономными.
Если одна функция нуждается в изменениях, это повлияет на работу всего процесса и других функций, поскольку они являются частью одного процесса.
Давайте вспомним, что такое Ruby on Rails, что он может предложить, его плюсы и минусы. Его главное преимущество в том, что с ним легко работать.
Если вы пишете rails new, вы сразу получаете новое приложение сразу, тогда вы можете создать любой REST API по вашему желанию и использовать помощники и генераторы Rails, что делает разработку еще проще.
Если вам нужно отправлять электронные письма в приложении Rails, используйте Rails ActionMailer. Когда вам нужно выполнить сложную обработку, ActiveJob поможет вам. С Rails 5 вы также сможете использовать веб-сокеты из коробки. Таким образом, будет легко создавать чаты или делать ваше приложение более интерактивным.
Если вы используете правильный синтаксис DSL, вы можете использовать все это и даже больше сразу. Более того, вам не нужно знать все о внутренней реализации этих инструментов, учитывать их DSL и получать ожидаемый результат.