Здравствуйте, Shmj, Вы писали:
SS>>Сам код проверки можно спрятать под капот класса параметров, вызывать из конструктора основного класса. S>Это хуже, так как нельзя отличить опциональные параметры от обязательных. Нужно смотреть документацию.
Ну а что мешает спрятать в класс параметров только опции, как в XmlWriterSettings?
Тут сама проблема прям подсказывает решение
S>Лучше так: все обязательные в конструктор, опциональные устанавливаете через свойства. И пофиг что их много -- никто запрет на количество параметров не устанавливал.
Угу, или так.
Re: Порядок параметров в методе (и вообще про порядок членов)
Здравствуйте, Shmj, Вы писали:
S>Вот, задумался.
S>В каком порядке лучше писать параметры в методе? Видимо лучше по смыслу, чем по алфавиту. Но какой лучше принцип применить? По очереди появления в теле метода? По важности (менее важные, опциональные, уже после).
Принято так расставлять: что, где, как.
S>Добавлю. И даже более широкий вопрос. Вот, порядок полей и свойств в классе, порядок методов. Должен ли он быть? Или просто хаотично?
Порядок должен быть.
S>Update. Добавлю пример:
S>
S>class Book
S>{
S> public string Author {get; set;}
S> public DateTime PublishDateTime {get; set;}
S> public string Name {get; set;}
S> public long Id {get;set;}
S> public DateTime PurchaseDateTime {get; set;}
S> public int AvailableCount {get; set;}
S> public string Description {get; set}
S>}
S>
S>Не кажется ли вам, что сначала нужно расположить Id, книги, а не в середине. Потом желательно Name. А может Author? Вот как тут понять? А потом что первым AvailableCount или PublishDateTime?
Это зависит от важности этих данных в рамках решаемой задачи: что важнее, то и идёт первым. И идентификаторы у книг уже есть — ISBN — наверное, стоит использовать его.
Re[3]: Порядок параметров в методе (и вообще про порядок членов)
Прочитал комент и не понял. Можете обьяснить что имелось в виду:
S>Вот тут обязательно надо читать вот это. Иначе рано или поздно выстрелит.
Если вы про
DO NOT add a parameter in the middle of existing optional parameters
DO NOT add multiple overloads with optional parameters
то как бы и ежу понятно. Или имелось в виду какое-то другое "ружье"?
S>Вообще я удивлён, что нашлась хоть одна схема работы с optional args, которая почти не создаёт проблем с бинарной совместимостью. Все остальные варианты рано или поздно подкладывали очень обидный MissingMethodException.
Без понятия что такое "бинарная совместимость".. что-то из области создания библиотек и позднего связывания? Точно в C#?
---
ПроГLамеры объединяйтесь..
Re[4]: Порядок параметров в методе (и вообще про порядок членов)
S>Это как бы и ежу понятно. Или имелось в виду какое-то другое "ружье"?
Не, я про запрет нескольких перегрузок с optional args и про порядок действий при добавлении параметров. Вот этого совета нам в своё время не хватало.
S>>Вообще я удивлён, что нашлась хоть одна схема работы с optional args, которая почти не создаёт проблем с бинарной совместимостью. Все остальные варианты рано или поздно подкладывали очень обидный MissingMethodException.
S>Без понятия что такое "бинарная совместимость".. что-то из области создания библиотек и позднего связывания? Точно в C#?
Это про "заменить библиотеку такой же, только без бага, не перекомпилируя все зависимости".
Для большого софта реально нужная штука.
Re: Порядок параметров в методе (и вообще про порядок членов)
Здравствуйте, Shmj, Вы писали:
S>Вот, задумался.
S>В каком порядке лучше писать параметры в методе? Видимо лучше по смыслу, чем по алфавиту. Но какой лучше принцип применить? По очереди появления в теле метода? По важности (менее важные, опциональные, уже после).
S>Я старался по важности. Но когда параметров много, сложно отследить их важность.
S>Или вообще без всякого порядка, просто хаотично?
S>Кто что думает?
S>Добавлю. И даже более широкий вопрос. Вот, порядок полей и свойств в классе, порядок методов. Должен ли он быть? Или просто хаотично?
S>Update. Добавлю пример:
S>
S>class Book
S>{
S> public string Author {get; set;}
S> public DateTime PublishDateTime {get; set;}
S> public string Name {get; set;}
S> public long Id {get;set;}
S> public DateTime PurchaseDateTime {get; set;}
S> public int AvailableCount {get; set;}
S> public string Description {get; set}
S>}
S>
S>Не кажется ли вам, что сначала нужно расположить Id, книги, а не в середине. Потом желательно Name. А может Author? Вот как тут понять? А потом что первым AvailableCount или PublishDateTime?
Самый общий подход, которым я пользуюсь и который очень давно рекомендовали. Атрибуты класса: от "легких" к "тяжёлым", т.е. сначала bool,int,double затем структуры, потом объектные типы. В параметрах метода наоборот: от "тяжелых" к "легким". Это если нет каких-то других ограничений.
Программа – это мысли спрессованные в код
Re[2]: Порядок параметров в методе (и вообще про порядок членов)
Здравствуйте, Qulac, Вы писали:
Q>Самый общий подход, которым я пользуюсь и который очень давно рекомендовали. Атрибуты класса: от "легких" к "тяжёлым", т.е. сначала bool,int,double затем структуры, потом объектные типы. В параметрах метода наоборот: от "тяжелых" к "легким". Это если нет каких-то других ограничений.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Qulac, Вы писали:
Q>>Самый общий подход, которым я пользуюсь и который очень давно рекомендовали. Атрибуты класса: от "легких" к "тяжёлым", т.е. сначала bool,int,double затем структуры, потом объектные типы. В параметрах метода наоборот: от "тяжелых" к "легким". Это если нет каких-то других ограничений.
S>
S>Ничего не смущает?
S>На мой взгляд, подобные рекомендации из серии "ну и что, что неудобно, зато формально проверить легко" скорее мешают, чем помогают.
Да нет, это дело привычки. По мне всё норм.
Программа – это мысли спрессованные в код
Re[4]: Порядок параметров в методе (и вообще про порядок членов)
Здравствуйте, Shmj, Вы писали:
S>Мне нужна удочка а не рыба. Т.е. принцип, по которому нужно сортировать параметры, а не это отдельное решение.
Ты же сам привел этот пример , значит на его основе был готов делать какие-то выводы. А правильного и единственно верного решения быть не может, и даже если его установить, рыбы от этого больше не поймаешь.
Re[3]: Порядок параметров в методе (и вообще про порядок членов)
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, SergeyT., Вы писали:
ST>>+1. Со мной тоже периодически такое происходит! S>Оффтоп
S>Можешь глянуть вот этот
, значит на его основе был готов делать какие-то выводы. А правильного и единственно верного решения быть не может, и даже если его установить, рыбы от этого больше не поймаешь.
