Сообщения / события против вызовов традиционных методов

Question

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

Одно из обнаруженных мной отличий было то, что Objective-C использует обмен сообщениями от Smalltalk, который, похоже, очень похож на события в vb.net.(vb.net и Java - мои самые беглые языки).В то время как C ++ использует традиционные вызовы методов Pass & Return.Я понимаю разницу между ними (я думаю).

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

Answer 1

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

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

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

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

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

Answer 2

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

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

------------------------------------------ Философия Каждый язык --------------------------------------------- ---

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

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

Объекты Objective-C должны быть в состоянии стоять самостоятельно. Здесь нет личных объектов, только одно пространство имен, а имена объектов разрешаются во время выполнения. Наличие тысяч объектов Objective-C порождает проблемы.

C ++ с его нулевыми издержками для не виртуальных классов поощряет программистов создавать подклассы int, rects и любую другую структуру данных. Написание небольшого количества кода может дать проверку диапазона, проверку типа, проверку значения или любую другую возможную проверку. Objective-C имеет много накладных расходов для объекта, и нет перегрузки операторов. Нецелесообразно иметь классы Objective C для rects, ints или других небольших структур данных.

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

Другая причина, по которой Objective-C быстрее разрабатывается, заключается в том, что это более простой язык. Я видел, как программисты проводят дни, пытаясь получить правильный синтаксис эзотерической функции C ++. В Objective-C не так много областей, где процветают языковые юристы. Худшая часть эзотерического синтаксиса C ++ заключается в том, что другие программисты могут быть не в состоянии понять некоторые из более сложных кодов C ++.

Самая большая причина для более быстрого времени разработки - это отдельный объект. Объекты Objective-C, как правило, являются автономными, поэтому, если вам нужна функциональность, вам нужно всего лишь включить этот один объект или иногда небольшое количество связанных объектов. Объекты C ++, с другой стороны, имеют тенденцию объединяться в группы. Каждый раз, когда вы хотите включить функциональность из объекта, вам, вероятно, потребуется включить дополнительные 10-20 объектов.

Все это и многое другое здесь

Answer 3

Стоит прочитать страницу википедии о Цель C , особенно раздел об обмене сообщениями .

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

Важное отличие между сообщениями Objective C и вызовами функций в таких языках, как C и C ++, заключается в том, что вызовы функций связаны во время компиляции. Это приводит к более быстрому выполнению, но менее динамичному поведению. Цель C использует динамическое (или позднее) связывание - посредством чего назначение сообщений определяется во время выполнения. Такая система неизменно включает в себя меньшее количество проверок типов во время компиляции, но допускает более динамическое кодирование и допускает некоторое интересное метапрограммирование . Динамизм обмена сообщениями допускает некоторые интересные концепции, такие как Objective C category , посредством которых вы можете заменить функциональность произвольных классов вашими собственными реализациями. Это похоже на подклассы, но не то же самое; например, категория не может иметь свои собственные данные; он действует как часть класса, который вы классифицируете.

Функции обмена сообщениями могут привести к получению более лаконичного кода. Например, в Задаче C вы можете отправить любое сообщение на nil, и система ничего не сделает и просто продолжит:

NSObject *thing = nil;
[thing someMessage];  // does nothing. No need for nil check!

Другие языки без этой функции (например, C ++, Java) могут использовать шаблон проектирования под названием Null Object для достижения такого же эффекта - но для этого требуется реализация (посредством чего вы фактически создаете объект-заглушку, который ничего не делает при вызове методов).