|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
Привет. Нельзя описывать методы с одинаковой сигнатурой. Но вот есть у меня метод, принимающий 3 параметра. 2 последних строковые, для логики метода необязательные. Мне кажется удобным писать перегруженные методы под каждый вариант входных параметров. Однако компилятор не позволит создать функции принимающие те два необязательные параметра по отдельности. Теоретически, методы можно обозвать по разному. Однако тогда теряется весь смысл создания перегруженных методов. Как можно обойти такую дилемму ? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2015, 18:12 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
ProBiotekМне кажется удобным писать перегруженные методы под каждый вариант входных параметров. Однако компилятор не позволит создать функции принимающие те два необязательные параметра по отдельности. В смысле? Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2015, 18:59 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
ну и типа имена одинаковые сделать у методов ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2015, 19:00 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
ТС имеет ввиду, что он хочет иметь: Код: c# 1. 2. 3.
но задвоить второй не позволяют одинаковые сигнатуры ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2015, 20:59 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
ProBiotek, если аргументы необязательные, то можно использовать именованные параметры: Код: c# 1. 2. 3. 4. 5. 6. 7.
... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2015, 21:51 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
Shocker.ProТС имеет ввиду, что он хочет иметь: Код: c# 1. 2. 3.
но задвоить второй не позволяют одинаковые сигнатурыЭто потому, что названия аргументов и функций - условность, исчезающая после компиляции. Остаются порядковые номера функций и их параметров (и типы, само собой), поэтому между вторым и третьим вариантом нет никакой разницы. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2015, 22:08 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
ProBiotekПривет. Нельзя описывать методы с одинаковой сигнатурой. Но вот есть у меня метод, принимающий 3 параметра. 2 последних строковые, для логики метода необязательные. Мне кажется удобным писать перегруженные методы под каждый вариант входных параметров. Однако компилятор не позволит создать функции принимающие те два необязательные параметра по отдельности. Теоретически, методы можно обозвать по разному. Однако тогда теряется весь смысл создания перегруженных методов. Как можно обойти такую дилемму ?А мне кажется, что удобнее передавать один параметр типа Query, или Options, или Condition, или Criteria, или... Дайте больше конкретики, с примером кода. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2015, 22:24 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
skyANAА мне кажется, что удобнее передавать один параметр типа Query, или Options, или Condition, или Criteria, или... Не сказал бы, что это удобно для прикладного кода. Такие объекты удобно «спускать» в виртуальные методы, при реализации сервисных классов, обычно именно так и делается чаще всего, но для прикладного использования это крайне неудобно, как и взвесь перегрузок методов и куча аргументов. ProBiotekКак можно обойти такую дилемму ? Пили fluent-интерфейс. На разработку такого интерфейса нужно больше времени, чем для других вариантов, но в последствии это окупится сторицей. Я бы сказал даже больше: вложений на десять копеек, профит на 1000 рублей. Суть такая: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38.
вот так. и никаких перегрузок. ни одной, ни единой. всё чисто, просто, читабельно, удобно, прозрачно. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2015, 22:59 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
hVosttskyANAА мне кажется, что удобнее передавать один параметр типа Query, или Options, или Condition, или Criteria, или... Не сказал бы, что это удобно для прикладного кода. Такие объекты удобно «спускать» в виртуальные методы, при реализации сервисных классов, обычно именно так и делается чаще всего, но для прикладного использования это крайне неудобно.Чем же это крайне не удобно? Особенно в сочетании с fluent-интерфейс? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2015, 07:43 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
skyANAЧем же это крайне не удобно? Особенно в сочетании с fluent-интерфейс? :) семантика теряется, метод требует Criteria, а как Criteria должен быть рожден -- с ходу непонятно, т.е. нужен ещё билдер Criteria. если же всё можно задать в конструкторе, то точно также можно передать и в параметрах метода. т.е. объекты состояний не очень хорошо подходят как аргегаты данных для непосредственного вызова функций. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2015, 10:58 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
hVostt, Про текучий интерфейс я знаю, хорошая задумка. Linq тот же построен по этому принципу. Но при его использовании, как замену конструктора, мне не нравится то, что он не показывает наглядно сколько и какие параметры вообще нужны. Также, наряду с рабочими методами класса, появляется десяток методов предназначенных только для создания. Если уж и использовать флюент интерфейс для конструирования. То в отдельных фабриках. В которых сконцентрированы все эти методы и обязательный метод типа Build, завершающий построение и возвращающий уже рабочий класс. Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
Стоит ли это того, чтобы вообще с этим заморачиваться, не знаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2015, 11:56 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
ProBiotekСтоит ли это того, чтобы вообще с этим заморачиваться, не знаю. так и твоя задача не стоит того, чтобы с ней заморачиваться ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2015, 12:39 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
ИзопропилProBiotekСтоит ли это того, чтобы вообще с этим заморачиваться, не знаю. так и твоя задача не стоит того, чтобы с ней заморачиватьсявообще программирование не стоит того, чтобы с ним заморачиваться. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2015, 12:47 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
ProBiotekСтоит ли это того, чтобы вообще с этим заморачиваться, не знаю. Трудно сказать, не зная деталей задачи Предложил как вариант, если возникает потребность в перегрузках и большом количестве аргументов, это явный звоночек, что надо это решать по-другому. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2015, 12:47 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
AntonariyИзопропилпропущено... так и твоя задача не стоит того, чтобы с ней заморачиватьсявообще программирование не стоит того, чтобы с ним заморачиваться. Ничто не стоит того, чтобы с ним заморачиваться (ц) ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2015, 13:08 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
ProBiotekНо вот есть у меня метод, принимающий 3 параметра. 2 последних строковые, для логики метода необязательные. наводит на мысль, что внутри метода есть что то типа? Код: c# 1. 2. 3. 4.
... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2015, 13:41 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
ЕвгенийВ, В общем. Эти два параметра, это дополнительное указание процессу о том, что ему делать. Соответственно да, идет проверка, что если есть первый параметр, то делаем первое действие. Если есть второй параметр, то и второе. Параметры никак не связаны друг с другом, но и не являются необходимыми - нету, ну и не делаем. Почему не стал делать отдельными методами SetA, SetB - хочется укоротить код. Не три строчки кода, а одна. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2015, 13:54 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
ProBiotekСоответственно да, идет проверка, что если есть первый параметр, то делаем первое действие. Если есть второй параметр, то и второе. SRP failure detected ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2015, 15:04 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
PallarisProBiotekСоответственно да, идет проверка, что если есть первый параметр, то делаем первое действие. Если есть второй параметр, то и второе. SRP failure detected Single responsibility principle Не факт, что нарушение. Это просто опциональные действия. И не факт, что эти действия будет делать именно данный класс :) Но спасибо за замечание. Я больше всего склоняюсь к решению bazile Код: c# 1. 2. 3.
В целом наглядно. Желающие могут указывать как все опциональные параметры, так и часть. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2015, 15:19 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
ProBiotekИ не факт, что эти действия будет делать именно данный класс :) SRP относится как к классам, так и к методам. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2015, 15:23 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
hVosttskyANAЧем же это крайне не удобно? Особенно в сочетании с fluent-интерфейс? :) семантика теряется, метод требует Criteria, а как Criteria должен быть рожден -- с ходу непонятно, т.е. нужен ещё билдер Criteria. если же всё можно задать в конструкторе, то точно также можно передать и в параметрах метода. т.е. объекты состояний не очень хорошо подходят как аргегаты данных для непосредственного вызова функций.Слушай, давай я заменю Criteria на Command, или Action, или Predicat :) Какая ещё семантика у тебя теряется? Мы задачи не знаем. К примеру в CQRS есть Commands и есть Queries... И никакая семантика там не теряется, а код прикладнее некуда :) ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2015, 16:42 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
наглядное пособие - как раздуть из мухи слона -) ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2015, 16:50 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
Изопропилнаглядное пособие - как раздуть из мухи слона -) Форума то проста.Вопрос задан таков, что позволяет широкий выбор правильного ответа. Появилось несколько вариантов, и, классически, началось обсуждение чужих решений. В принципе, я и хотел узнать разные варианты, выбрал один из них. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2015, 17:06 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
ProBiotek Linq тот же построен по этому принципу. O_O Ваще мимо. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2015, 18:00 |
|
Нельзя описывать методы с одинаковыми сигнатурами.
|
|||
---|---|---|---|
#18+
Monochromatique, В принципе для классического флюента важно, что методы вызываются у одного и того же объекта, а в Линке, методы возвращают новые объекты/списки. Linq правильней назвать Method Chaining конечно. Это я к слову писал просто :) ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2015, 19:12 |
|
|
start [/forum/topic.php?fid=20&fpage=76&tid=1401176]: |
0ms |
get settings: |
12ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
32ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
90ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 187ms |
0 / 0 |