Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Jack128, Вы писали:
J>>Один авторитетный, судя по рейтингу, rsdn'овиц заявил сабж. Кто ниту может объяснить почему так?
IT>Это актуально для разработки повторно-используемых компонент, т.к. public методы по сути являются контрактом, который в дальнейшем нельзя менять.
угу, это понятно.
Но например такая тема:
есть метод
public void SameMethod(int param1, int param2)
в 90% случаев он используется SameMethod(param1, 0)
являются ли соображения о публичном контракте поводом НЕ вводить перегрузку SameMethod(int param1) {SameMethod(param1, 0);} ??
Здравствуйте, Jack128, Вы писали:
J>в 90% случаев он используется SameMethod(param1, 0) J>являются ли соображения о публичном контракте поводом НЕ вводить перегрузку SameMethod(int param1) {SameMethod(param1, 0);} ??
Думаю, не являются. В .NET FW это интенсивно используется. Но параметры по-умолчанию, которые появяться в C# 4.0 более правильная практика.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Думаю, не являются. В .NET FW это интенсивно используется. Но параметры по-умолчанию, которые появяться в C# 4.0 более правильная практика.
параметры по умолчанию сами по себе не решают проблему, тока в сосокупности с "именнованными" параметрами(не знаю как он официально называются) в VB есть такая фишка: SameMethod(param2 = 10, param1 = 5)
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, Jack128, Вы писали:
J>>есть метод J>>public void SameMethod(int param1, int param2)
J>>в 90% случаев он используется SameMethod(param1, 0)
M>В приведенно примере SameMethod(param1, 0) можно реализовать как внешнюю функцию , внешнюю по отношению к классу или модулю.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Jack128, Вы писали:
J>>Один авторитетный, судя по рейтингу, rsdn'овиц заявил сабж. Кто ниту может объяснить почему так?
L>Потому что чаще всего такая ситуация сведетельствует, что класс берет на себя слишком много. Погуглите по SRP (single responsibility principle).
ну в таком случае — если я вижу в класса — 100 паблик методов — это просто повод посмотреть на него повнимательнее, не более того.
Здравствуйте, Jack128, Вы писали:
IT>>Думаю, не являются. В .NET FW это интенсивно используется. Но параметры по-умолчанию, которые появяться в C# 4.0 более правильная практика.
J>параметры по умолчанию сами по себе не решают проблему, тока в сосокупности с "именнованными" параметрами(не знаю как он официально называются) в VB есть такая фишка: SameMethod(param2 = 10, param1 = 5)
Вот это и будет в 4.0.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Jack128, Вы писали:
L>>Потому что чаще всего такая ситуация сведетельствует, что класс берет на себя слишком много. Погуглите по SRP (single responsibility principle).
J>ну в таком случае — если я вижу в класса — 100 паблик методов — это просто повод посмотреть на него повнимательнее, не более того.
Смотря какую цель ты преследуешь. Если у тебя нет желания писать качественный код, то достаточно просто посмотреть внимательнее, хотя и этого делать не обязательно.
Здравствуйте, Jack128, Вы писали:
J>Один авторитетный, судя по рейтингу, rsdn'овиц заявил сабж. Кто ниту может объяснить почему так?
При использовании такого класса придется разбираться в этой куче методов. И если на эти методы повязаться, то при переделке public методов класса придется переделать код, который эти методы использует.
Но здесь есть опасность. Если класс имеет очень сложное внутреннее устройство, и один метод SetValue( ... ), то становиться еще хуже.
Все зависит от конкретного случая. Количество методов доступных пользователю должно быть минимально достаточным для полноценного и эффективного использования функционала, реализуемого классом.
"Много" или "мало" это слишком абстрактно. Наверное, нужно исходить из принципа, что класс должен предоставлять методы, объединяемые в три-четыре семантических единицы, т.е. 3-4 группы методов.
Здравствуйте, Jack128, Вы писали:
J>Здравствуйте, minorlogic, Вы писали:
M>>В приведенно примере SameMethod(param1, 0) можно реализовать как внешнюю функцию , внешнюю по отношению к классу или модулю.
J>можно. А зачем??
Меньше связанность, меньше зависимостей.
Попробуйте ответить на вопрос , почему вообще пишут разные классы модули и т.п. Можно ведь все писать в одном большом модуле всемогутере.
Здравствуйте, Jack128, Вы писали:
J>Один авторитетный, судя по рейтингу, rsdn'овиц заявил сабж. Кто ниту может объяснить почему так?
Меньше баплик методов , меньшн интнрфейс.
Меньше интерфейс, меньше зависимостей и связей.
Меньше зависимостей и связей, лучшая декомпозиция.
Лучшая декомпозиция, код гибче к изменениям и потдержке.
Код гибче к изменениям и потдержке, могут заплатить больше денежек
Do make only the longest overload virtual (Overridable in Visual Basic) if extensibility is required. Shorter overloads should simply call through to a longer overload.
...
Do allow null (Nothing in Visual Basic) to be passed for optional arguments. If a method takes optional arguments that are reference types, allow null to be passed to indicate that the default value should be used. This avoids the problem of having to check for null before calling a member.
Так что правильно приготовленные overloads — не более чем сахар для вызова основного мембера и контракт не портят.
Здравствуйте, Jack128, Вы писали:
M>>В приведенно примере SameMethod(param1, 0) можно реализовать как внешнюю функцию , внешнюю по отношению к классу или модулю. J>можно. А зачем??
Что бы не плодить дополнительные сущности в контракте. В С#, начиная с версии 3.0, для решения подобных задач есть хороший механизм — extension methods.
Здравствуйте, 0x7be, Вы писали:
0>Что бы не плодить дополнительные сущности в контракте. В С#, начиная с версии 3.0, для решения подобных задач есть хороший механизм — extension methods.
Ребят, а никому не кажется странным решение в стиле структурного программирования в эпоху развитого ООП? Перед extension methods слегка другие задачи ставились.
— They are not discoverable. You can't just look at intellisense or the class documentation to discover its capabilities. You have to have foreknowledge that the functionality you want exists and what namespace to find it in.
— The are fragile. Extension methods introduce a new version of the Fragile Base Class problem, where an instance method introduced in a later version of a class will silently and transparently replace the extension method. For some reason, no steps were taken to mitigate this problem in the design of extension methods.
Здравствуйте, Sinix, Вы писали:
0>>Что бы не плодить дополнительные сущности в контракте. В С#, начиная с версии 3.0, для решения подобных задач есть хороший механизм — extension methods. S>Ребят, а никому не кажется странным решение в стиле структурного программирования в эпоху развитого ООП? Перед extension methods слегка другие задачи ставились.
Не совсем. В данном случае extension methods не добавляют функциональности классу/интерфейсу, который расширяют, а всего ли реализую некоторые часто употребляемые паттерны вызова. При этом эти паттерны могут быть специфичны для конкретного случая использования и не являются каким-то неотъемлемым свойством потребляемого интерфейса.
S>- They are not discoverable. You can't just look at intellisense or the class documentation to discover its capabilities. You have to have foreknowledge that the functionality you want exists and what namespace to find it in.
В эпоху развитого intellisense это не так
S>- The are fragile. Extension methods introduce a new version of the Fragile Base Class problem, where an instance method introduced in a later version of a class will silently and transparently replace the extension method. For some reason, no steps were taken to mitigate this problem in the design of extension methods. S>[/q]
Тут не поспоришь.
"У всех свои недостатки" (с)
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, Sinix, Вы писали:
0>Не совсем. В данном случае extension methods не добавляют функциональности классу/интерфейсу, который расширяют, а всего ли реализую некоторые часто употребляемые паттерны вызова. При этом эти паттерны могут быть специфичны для конкретного случая использования и не являются каким-то неотъемлемым свойством потребляемого интерфейса.
Ну вообще-то расширения изначально планировались контекстными. Грубо говоря using System.Net — и у строки появляются фичи, нужные для работы с сетями (например "localhost".Ping()). Пруфлинк не найду. В мейнстриме реализация ограничилась линком (и правильно имхо).
0>В эпоху развитого intellisense это не так
Развитому интеллисенсу надо ещё скормить пачку юзингов. Ну и не все изучают библиотеки через автодополнение. Тот же рефлектор о наличии расширений умалчивает.
0>"У всех свои недостатки" (с)
+1