Привет всем.
Столкнулся (и постоянно сталкиваюсь) с дилеммой при проектировании методов и функций: давать методу минимум информации (например, в терминах .NET методу который пока просто выполняет некую операцию над коллекцией элементов, дать не List<T>, а IEnumerable<T>, т.е. не "список", а просто "последовательность"), или дать какой-либо большой объект, рассчитывая, что в будущем метод, возможно, будет выполнять не только операции над каким-то одним его свойством, а и над другими тоже (сравнивая Print(user.FirstName) и Print(user), тупой пример, но все же).
Как можно обобщить этот выбор? МакКоннела читал давно, и такого там не помню

Здравствуйте, Shizuka-kun, Вы писали:

SK>Привет всем.
SK>Столкнулся (и постоянно сталкиваюсь) с дилеммой при проектировании методов и функций: давать методу минимум информации (например, в терминах .NET методу который пока просто выполняет некую операцию над коллекцией элементов, дать не List<T>, а IEnumerable<T>, т.е. не "список", а просто "последовательность"), или дать какой-либо большой объект, рассчитывая, что в будущем метод, возможно, будет выполнять не только операции над каким-то одним его свойством, а и над другими тоже (сравнивая Print(user.FirstName) и Print(user), тупой пример, но все же).
SK>Как можно обобщить этот выбор? МакКоннела читал давно, и такого там не помню

Law of Demeter?

Здравствуйте, Shizuka-kun, Вы писали:

http://msdn.microsoft.com/en-us/library/ms229015.aspx

Здравствуйте, Курилка, Вы писали:
К>Law of Demeter?

Согласен, loose coupling это наше всё, но допустим у меня куча методов, которым достаточно для операции было принимать user id, который был типа Int32, потом стал String. Не является ли выходом передача в эти же методы всего объекта User? Или более правильный путь — сокрытие данных путем введения нового типа UserId и операций над ним? Можете поделиться опытом, как приходилось выходить из подобных ситуаций?

Здравствуйте, Shizuka-kun, Вы писали:

SK>Столкнулся (и постоянно сталкиваюсь) с дилеммой при проектировании методов и функций: давать методу минимум информации (например, в терминах .NET методу который пока просто выполняет некую операцию над коллекцией элементов, дать не List<T>, а IEnumerable<T>, т.е. не "список", а просто "последовательность"), или дать какой-либо большой объект, рассчитывая, что в будущем метод, возможно, будет выполнять не только операции над каким-то одним его свойством, а и над другими тоже (сравнивая Print(user.FirstName) и Print(user), тупой пример, но все же).
SK>Как можно обобщить этот выбор? МакКоннела читал давно, и такого там не помню

Главный принцип посроения дерьмового ПО — это делать как можно на всякий случай.

Второй принцип — создавать как можно менее универсальные функции.

Так что выбор за тобой. Или ты постоянно "думаешь о будущем" и засоряешь свой код мертвым кодом.
Или ты пишешь код таким каким он нужен сейчас, а в случае изменения потребностей изменяешь его соответствующим образом (делаешь рефакторинг).

Здравствуйте, Shizuka-kun, Вы писали:

SK>Или более правильный путь — сокрытие данных путем введения нового типа UserId и операций над ним?
Да, мыслить надо в этом направлении. Разные формы синтаксического сахара помогают.

SK>Можете поделиться опытом, как приходилось выходить из подобных ситуаций?
Действую по обстоятельствам, где-то в рамках "если изменение проще сделать, если бы был некоторый рефакторинг, делайте этот рефакторинг".

Здравствуйте, Shizuka-kun, Вы писали:

SK>Согласен, loose coupling это наше всё, но допустим у меня куча методов, которым достаточно для операции было принимать user id, который был типа Int32, потом стал String. Не является ли выходом передача в эти же методы всего объекта User? Или более правильный путь — сокрытие данных путем введения нового типа UserId и операций над ним? Можете поделиться опытом, как приходилось выходить из подобных ситуаций?

Правильным выходом будет введение интерфейса IIdentity в котором уже будет все что нужно для идентификации объекта. Ну, и возможно некоторого базового класса для укрощения реализации. Хотя тут уже может быть много вариантов.

Здравствуйте, Shizuka-kun, Вы писали:

SK>Как можно обобщить этот выбор? МакКоннела читал давно, и такого там не помню

Я заморачиваюсь этим вопросом в двух случаях: (1) не уверен в правильности дизайна (2) я возвращаюсь к уже написанной функции. Потому как в 90% случаев к этому коду никто не вернется. Если рассматривать (1), то речь идет о выработке общих правил в системе. Потому как в таких вопросах важно единообразие. В случае (2) возникает проблема пересмотра ранее написаного кода, если он оказался не очень удобным.

Здравствуйте, Shizuka-kun, Вы писали:

SK>Привет всем.
SK>Столкнулся (и постоянно сталкиваюсь) с дилеммой при проектировании методов и функций: давать методу минимум информации (например, в терминах .NET методу который пока просто выполняет некую операцию над коллекцией элементов, дать не List<T>, а IEnumerable<T>, т.е. не "список", а просто "последовательность"), или дать какой-либо большой объект, рассчитывая, что в будущем метод, возможно, будет выполнять не только операции над каким-то одним его свойством, а и над другими тоже (сравнивая Print(user.FirstName) и Print(user), тупой пример, но все же).
SK>Как можно обобщить этот выбор? МакКоннела читал давно, и такого там не помню

Это зависит от разных условий.
Допустим вы хотите передать методу userID и выбираете между передачей User user и int userID. Тут я бы выбрал передачу именно userID, т.к. не всегда у клиентской стороны может быть в наличии полный объект User. Если же надо передать несколько свойств объекта, то лучше передать полный объект.
Чисто по моему опыту — очень редко когда в будущем становятся нужны дополнительные свойства некоего объекта. Поэтому я бы склонялся все-таки к минимализму, но все равно в каждой конкретной ситуации надо обдумывать. Ну и, повторюсь, помните, что когда вы передаете полный объект, то у клиентского кода его может не быть — меня несколько раздражает, когда у меня в наличии только customerID, а метод требует полный объект customer, хотя я знаю что ему на самом деле нужен только ID (т.е. фактически это была ошибка дизайна метода).
Еще нужно смотреть по типу проекта. В частности, если это внутренний проект, и обновления производятся легко (допустим система автоматизации для маленькой компании), то можно вообще сильно не заморачиваться — всегда сможете отрефакторить и обновить. Если это публичная библиотека или фреймворк — тут надо 100 раз подумать, потому что исправить потом уже может быть невозможно.

Большое спасибо всем за советы )

Здравствуйте, Shizuka-kun, Вы писали:

SK>Как можно обобщить этот выбор? МакКоннела читал давно, и такого там не помню

А вот и есть там такое. Лишний повод заглянуть в старую-добрую красную книжку

Здравствуйте, Shizuka-kun, Вы писали:

SK>Как можно обобщить этот выбор?

Правило большого пальца при проектирования метода с точки зрения этого выбора — принимать как можно меньше информации, отдавать как можно больше. Т.е. если все что вам нужно от коллекции это IEnumerable<> — то не надо писать List<> в качестве агрумента. С другой стороны если вы можете вернуть List<>, то не нужно возвращать просто IEnumerable<>.

Причем заметьте, что это именно правило большого пальца. При проектировании функции могут быть другие соображения. Например, иногда стоит вернуть IEnumerable вместо List, чтобы получить слабую гарантию неизменности коллекции (слабая гарантия означает, что коллекцию не будут изменять случайно, API декларирует это как бы — но от downcast тут никто не защищает).