Это - Pythonic для функции для возврата повторяемого или неповторяемого в зависимости от ее входа?
Можно объявить несколько методов:
- (void)print;
- (void)printWithParameter:(id)parameter;
- (void)printWithParameter:(id)parameter andColor:(NSColor *)color;
В реализации можно сделать это:
- (void)print {
[self printWithParameter:nil];
}
- (void)printWithParameter:(id)parameter {
[self printWithParameter:nil andColor:[NSColor blackColor]];
}
Редактирование:
не используйте print и print: одновременно. В первую очередь, это не указывает на то, что параметр, и во-вторых никакой (ab) использует Objective C этот путь. Большинство платформ имеет очень ясные имена методов, это - одна вещь, которая делает Objective C таким образом без боли к программе с. Нормальный разработчик не ожидает этот вид методов.
существуют лучшие имена, например:
- (void)printUsingBold:(BOOL)bold;
- (void)printHavingAllThatCoolStuffTurnedOn:(BOOL)coolStuff;
7 ответов
Если вы собираетесь иногда возвращать итераторы, а для других - отдельные объекты, я бы посоветовал всегда возвращать итератор, поэтому вам не нужно об этом думать.
Как правило, вы должны использовать эту функцию в контексте, который ожидает итератора, поэтому, если вам нужно будет проверить, где это список для итерации или объект, который выполняет только один раз работу, тогда проще просто вернуть итератор и выполнять итерацию всегда, даже если это один раз.
Если вам нужно сделать что-то другое, если вам возвращается один элемент, просто используйте if len (var): .
Помните, согласованность является ценным товаром.
Я склоняюсь к возврату согласованного объекта, не обязательно одного и того же типа, но если я когда-либо возвращаю итерацию, я всегда возвращаю итерацию.
В общем, я бы сказал, что возвращение двух разных типов - плохая практика.
Представьте, что следующий разработчик придет, чтобы прочитать и поддержать ваш код. Сначала он / она прочитает метод, использующий вашу функцию, и подумает: «Ах, read () возвращает один элемент».
Позже они увидят код, обрабатывающий результат read () как список. В лучшем случае это просто запутает их и заставит исследовать использование read (). В худшем случае они могут подумать, что в реализации есть ошибка с помощью read (), и попытаться исправить ее.
Наконец, как только они поймут, что read () возвращает два возможных типа, им придется спросить себя: «Возможно ли третье возвращение типа, к которому мне нужно быть готовым? »
Это напоминает мне поговорку:« Код, как если бы следующий человек, поддерживающий ваш код, - это маньяк-убийца, который знает, где вы живете.
Определенно сложно иметь дело с возвратом одного объекта или итерации объектов, в зависимости от аргументов. Но вопрос в вашем заголовке гораздо более общий, и утверждение, что функция стандартной библиотеки избегает (или «в основном избегает») возврата разных типов на основе аргумента (ов), совершенно неверно. Существует множество контрпримеров.
Функции copy.copy и copy.deepcopy возвращают тот же тип, что и их аргумент, поэтому, конечно, они «возвращают разные типы в зависимости от " Аргумент. «Возврат того же типа, что и входной» на самом деле ОЧЕНЬ распространено - здесь вы также можете классифицировать «получить объект обратно из контейнера, в который он был помещен», хотя обычно это делается с помощью метода, а не функции ;-) . Но и, в том же ключе рассмотрим itertools.repeat (после итерации по его возвращенному итератору) или, скажем, filter ...:
>>> filter(lambda x: x>'f', 'zaplepidop')
'zplpiop'
>>> filter(lambda x: x>'f', list('zaplepidop'))
['z', 'p', 'l', 'p', 'i', 'o', 'p']
фильтрация строки возвращает строку, фильтрация списка возвращает список.
Но подождите, это еще не все! -) Функции pickle.loads и его друзья (например, в модуле marshal и c) возвращают объекты типов , полностью зависящих от значение, которое вы передаете в качестве аргумента. То же самое и со встроенной функцией eval (и аналогичным образом input в Python 2. *). Это второй распространенный паттерн: построить или реконструировать объект в соответствии со значением аргумента (ов) из широкого (или даже неограниченного) разнообразия возможных типов и вернуть его.
Я не знаю хорошего примера конкретный анти-шаблон вы ' я заметил (и я действительно считаю, что это анти-паттерн, мягко говоря - не по какой-либо причине, вызывающей большое количество фалов, просто потому, что это надоедливо и неудобно иметь дело ;-). Обратите внимание, что эти случаи, которые я проиллюстрировал, ДЕЙСТВИТЕЛЬНО удобны и удобны - это настоящий дискриминант дизайна в большинстве стандартных библиотечных проблем! -)
Единственная ситуация, в которой я бы сделал это, - это параметризованная функция или метод, где один или несколько параметров, которые дает вызывающий объект, определяют возвращаемый тип; например, «фабричная» функция, которая возвращает один из логически аналогичного семейства объектов:
newCharacter = characterFactory("human", "male", "warrior")
В общем случае, когда вызывающий не может указать, я бы избегал поведения «коробки шоколадных конфет». :)
Возможно, дело не в «питоническом», а скорее в «хорошем дизайне». Если вы возвращаете разные вещи И , никто не должен проверять их типы, тогда это, вероятно, нормально. Это для вас полиморфизм. OTOH, если вызывающий должен «пронзить завесу», то у вас есть проблема дизайна, известная как нарушение принципа замещения Лискова. Pythonic или нет, это явно не объектно-ориентированный дизайн, что означает, что он будет подвержен ошибкам и неудобствам при программировании.
Я бы прочитал ( целое ) и read_list ( итерабельный ).
Таким образом, вы могли бы прочитать (10) и вернуться один результат и read_list ([5, 5, 10, 5]) и получить обратно список результатов. Это и более гибкий, и ясный вариант.
В списках Python есть объекты :) Так что несоответствия типов нет