Не путайте этот вопрос с проблемами производительности. Не делайте преждевременных оптимизаций (пока вы не узнаете, что у вас есть проблема), и когда вы думаете о проблемных точках производительности в вашем коде, это почти всегда в областях, связанных с вводом / выводом (например, база данных, файлы). Итак, разделите ваш вопрос о стиле передачи сообщений с производительностью. Вы хотите сначала принять наилучшее проектное решение , а затем оптимизировать производительность только при необходимости .
Учитывая вышесказанное, Apple не рекомендует и не предпочитает передавать несколько параметров структуре / объекту. Обобщая это вне области Objective-C, используйте отдельные параметры или объекты, когда это имеет смысл в конкретном сценарии. Другими словами, нет черно-белого ответа, которому вы могли бы следовать. Вместо этого используйте следующие рекомендации при принятии решения:
- Передавать объекты / структуры, когда для метода имеет смысл понимать многие / все члены объекта
- Передача объектов / структур, когда вы хотите проверить некоторые правила отношений между различными членами объекта. Это позволяет вам гарантировать, что потребитель вашего метода создает допустимый объект до вызова вашего метода (таким образом устраняя необходимость метода для проверки этих условий).
- Передача отдельных аргументов, когда становится ясно, что метод имеет смысл и требует только определенных элементов, а не всего объекта
Используя вариант вашего примера, метод рисования, который принимает две координаты (X и Y), выиграл бы от использования объекта Point, а не двух переменных, X и Y.
Метод retrieveOrderByIdAndName лучше всего разрабатывать, принимая один параметр id и name, а не какой-либо контейнерный объект.
Теперь, если бы существовал какой-то метод для получения заказов по множеству различных критериев, было бы больше отправки для создания retrieveOrderByCriteria и передачи ему некоторой структуры критериев.