Когда функции должны быть функциями членства?

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

Таким образом, он должен быть функцией-членом какого-либо другого класса более высокого уровня, например класса Mechanic или класса WheelReplacementOperation . И в случае, если у вас нет такого класса (хотя я думаю, что у вас должен быть!), Лучше сделать эту функцию глобальной.

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

Итак, вы говорят, что у String не должно быть открытого члена « bool IsEmpty () const » только потому, что у него есть « int Size () const », а IsEmpty определен и реализован как Size () == 0 ?

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

Один из способов взглянуть на это так:

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

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

В зависимости от того, насколько они реляционные, вам может быть лучше читать данные только для чтения из списка. Plist легко загружать / сохранять (они превращаются в NSDictionaries) и, вероятно, их легче редактировать

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

ОК

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

Ваш помощник прав, потому что легче создавать общие методы, если они не являются частью класса (например, почему std :: find не является членом std :: vector? потому что тогда это не будет ' t работает со списками, картами и т. д.).

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

Когда вы выходите в реальный мир и начинаете писать приложения и работаете в установленные сроки, вы обнаружите, что каждое приложение представляет собой конкурирующий набор требований. «Нам нужно получить A, B и C, но к концу следующего месяца. Это невозможно, у них могут быть B и C или A и C, но не A и B. Или они могут иметь не- идеальная версия A & B и хорошая версия C ».

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

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

Надеюсь, это поможет.

Рекомендация Херба Саттера и Андрея Александреску по этому поводу:

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

Функции, не являющиеся членами группы, не являющиеся друзьями:

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

Теперь, чтобы ответить на ваш вопрос ( когда? ), вот алгоритм, чтобы определить, должна ли функция быть членом и / или другом:

If the function is one of the operators =, ->, [], or (), which must be members:
=> Make it a member

Else if: 
    a) the function needs a different type as its left-hand argument (as do stream operators, for example); 
 or b) it needs type conversions on its leftmost argument; 
 or c) it can be implemented using the class's public interface alone:
=> Make it a nonmember (and friend if needed in cases a) and b) )

If it needs to behave virtually:
=> Add a virtual member function to provide the virtual behavior, and implement the nonmember in terms of that

Else: 
=> Make it a member

Ссылки:

• H. Саттер и Андрей Александреску . Стандарты кодирования C ++ (Addison-Wesley, 2004)
• S. Мейерс . «Как функции, не являющиеся членами, улучшают инкапсуляцию» (журнал пользователей C / C ++, 18 (2), февраль 2000 г.)
• Б.Строуструп . Язык программирования C ++ (специальное 3-е издание) (Addison-Wesley, 2000). §10.3.2, §11.3.2, §11.3.5, §11.5.2, §21.2.3.1
• H. Саттер . Исключительный C ++ (Аддисон-Уэсли, 2000).
• Н. Саттер . Исключительный стиль C ++ (Addison-Wesley, 2004).