Почему плохо иметь много паблик методов?
От: Jack128  
Дата: 23.11.09 21:08
Оценка: 1 (1)
Один авторитетный, судя по рейтингу, rsdn'овиц заявил сабж. Кто ниту может объяснить почему так?
Re: Почему плохо иметь много паблик методов?
От: IT Россия linq2db.com
Дата: 23.11.09 21:11
Оценка:
Здравствуйте, Jack128, Вы писали:

J>Один авторитетный, судя по рейтингу, rsdn'овиц заявил сабж. Кто ниту может объяснить почему так?


Это актуально для разработки повторно-используемых компонент, т.к. public методы по сути являются контрактом, который в дальнейшем нельзя менять.
Если нам не помогут, то мы тоже никого не пощадим.
Re: Почему плохо иметь много паблик методов?
От: Anpek  
Дата: 23.11.09 21:11
Оценка:
Здравствуйте, Jack128, Вы писали:

J>Один авторитетный, судя по рейтингу, rsdn'овиц заявил сабж. Кто ниту может объяснить почему так?


К давалкам все пренебрежительно относятся... "Кто без греха, пусть первым бросит в меня камень"
Re[2]: Почему плохо иметь много паблик методов?
От: Jack128  
Дата: 23.11.09 21:20
Оценка:
Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Jack128, Вы писали:


J>>Один авторитетный, судя по рейтингу, rsdn'овиц заявил сабж. Кто ниту может объяснить почему так?


IT>Это актуально для разработки повторно-используемых компонент, т.к. public методы по сути являются контрактом, который в дальнейшем нельзя менять.


угу, это понятно.

Но например такая тема:

есть метод
public void SameMethod(int param1, int param2)

в 90% случаев он используется SameMethod(param1, 0)

являются ли соображения о публичном контракте поводом НЕ вводить перегрузку SameMethod(int param1) {SameMethod(param1, 0);} ??
Re[3]: Почему плохо иметь много паблик методов?
От: minorlogic Украина  
Дата: 23.11.09 21:29
Оценка:
Здравствуйте, Jack128, Вы писали:


J>есть метод

J>public void SameMethod(int param1, int param2)

J>в 90% случаев он используется SameMethod(param1, 0)


В приведенно примере SameMethod(param1, 0) можно реализовать как внешнюю функцию , внешнюю по отношению к классу или модулю.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[3]: Почему плохо иметь много паблик методов?
От: IT Россия linq2db.com
Дата: 23.11.09 21:29
Оценка: +1
Здравствуйте, Jack128, Вы писали:

J>в 90% случаев он используется SameMethod(param1, 0)

J>являются ли соображения о публичном контракте поводом НЕ вводить перегрузку SameMethod(int param1) {SameMethod(param1, 0);} ??

Думаю, не являются. В .NET FW это интенсивно используется. Но параметры по-умолчанию, которые появяться в C# 4.0 более правильная практика.
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Почему плохо иметь много паблик методов?
От: Jack128  
Дата: 23.11.09 21:39
Оценка:
Здравствуйте, IT, Вы писали:

IT>Думаю, не являются. В .NET FW это интенсивно используется. Но параметры по-умолчанию, которые появяться в C# 4.0 более правильная практика.


параметры по умолчанию сами по себе не решают проблему, тока в сосокупности с "именнованными" параметрами(не знаю как он официально называются) в VB есть такая фишка: SameMethod(param2 = 10, param1 = 5)
Re: Почему плохо иметь много паблик методов?
От: Lloyd Россия  
Дата: 23.11.09 21:39
Оценка: 1 (1) +6
Здравствуйте, Jack128, Вы писали:

J>Один авторитетный, судя по рейтингу, rsdn'овиц заявил сабж. Кто ниту может объяснить почему так?


Потому что чаще всего такая ситуация сведетельствует, что класс берет на себя слишком много. Погуглите по SRP (single responsibility principle).
Re[4]: Почему плохо иметь много паблик методов?
От: Jack128  
Дата: 23.11.09 21:40
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>Здравствуйте, Jack128, Вы писали:



J>>есть метод

J>>public void SameMethod(int param1, int param2)

J>>в 90% случаев он используется SameMethod(param1, 0)


M>В приведенно примере SameMethod(param1, 0) можно реализовать как внешнюю функцию , внешнюю по отношению к классу или модулю.


можно. А зачем??
Re[2]: Почему плохо иметь много паблик методов?
От: Jack128  
Дата: 23.11.09 21:53
Оценка: :)
Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, Jack128, Вы писали:


J>>Один авторитетный, судя по рейтингу, rsdn'овиц заявил сабж. Кто ниту может объяснить почему так?


L>Потому что чаще всего такая ситуация сведетельствует, что класс берет на себя слишком много. Погуглите по SRP (single responsibility principle).


ну в таком случае — если я вижу в класса — 100 паблик методов — это просто повод посмотреть на него повнимательнее, не более того.
Re[5]: Почему плохо иметь много паблик методов?
От: IT Россия linq2db.com
Дата: 23.11.09 22:23
Оценка:
Здравствуйте, Jack128, Вы писали:

IT>>Думаю, не являются. В .NET FW это интенсивно используется. Но параметры по-умолчанию, которые появяться в C# 4.0 более правильная практика.


J>параметры по умолчанию сами по себе не решают проблему, тока в сосокупности с "именнованными" параметрами(не знаю как он официально называются) в VB есть такая фишка: SameMethod(param2 = 10, param1 = 5)


Вот это и будет в 4.0.
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Почему плохо иметь много паблик методов?
От: Lloyd Россия  
Дата: 23.11.09 22:27
Оценка: +3
Здравствуйте, Jack128, Вы писали:

L>>Потому что чаще всего такая ситуация сведетельствует, что класс берет на себя слишком много. Погуглите по SRP (single responsibility principle).


J>ну в таком случае — если я вижу в класса — 100 паблик методов — это просто повод посмотреть на него повнимательнее, не более того.


Смотря какую цель ты преследуешь. Если у тебя нет желания писать качественный код, то достаточно просто посмотреть внимательнее, хотя и этого делать не обязательно.
Re: Почему плохо иметь много паблик методов?
От: TimurSPB Интернет  
Дата: 23.11.09 23:04
Оценка: 4 (1) +1
Здравствуйте, Jack128, Вы писали:

J>Один авторитетный, судя по рейтингу, rsdn'овиц заявил сабж. Кто ниту может объяснить почему так?


При использовании такого класса придется разбираться в этой куче методов. И если на эти методы повязаться, то при переделке public методов класса придется переделать код, который эти методы использует.
Но здесь есть опасность. Если класс имеет очень сложное внутреннее устройство, и один метод SetValue( ... ), то становиться еще хуже.
Все зависит от конкретного случая. Количество методов доступных пользователю должно быть минимально достаточным для полноценного и эффективного использования функционала, реализуемого классом.
"Много" или "мало" это слишком абстрактно. Наверное, нужно исходить из принципа, что класс должен предоставлять методы, объединяемые в три-четыре семантических единицы, т.е. 3-4 группы методов.
Make flame.politics Great Again!
Re[5]: Почему плохо иметь много паблик методов?
От: minorlogic Украина  
Дата: 24.11.09 06:04
Оценка:
Здравствуйте, Jack128, Вы писали:

J>Здравствуйте, minorlogic, Вы писали:


M>>В приведенно примере SameMethod(param1, 0) можно реализовать как внешнюю функцию , внешнюю по отношению к классу или модулю.


J>можно. А зачем??


Меньше связанность, меньше зависимостей.
Попробуйте ответить на вопрос , почему вообще пишут разные классы модули и т.п. Можно ведь все писать в одном большом модуле всемогутере.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re: Почему плохо иметь много паблик методов?
От: minorlogic Украина  
Дата: 24.11.09 06:08
Оценка: +2
Здравствуйте, Jack128, Вы писали:

J>Один авторитетный, судя по рейтингу, rsdn'овиц заявил сабж. Кто ниту может объяснить почему так?


Меньше баплик методов , меньшн интнрфейс.
Меньше интерфейс, меньше зависимостей и связей.
Меньше зависимостей и связей, лучшая декомпозиция.
Лучшая декомпозиция, код гибче к изменениям и потдержке.
Код гибче к изменениям и потдержке, могут заплатить больше денежек

и т.д. ...
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[4]: Почему плохо иметь много паблик методов?
От: Sinix  
Дата: 24.11.09 06:23
Оценка: 4 (1)
Здравствуйте, IT, Вы писали:


IT>Думаю, не являются. В .NET FW это интенсивно используется. Но параметры по-умолчанию, которые появяться в C# 4.0 более правильная практика.


Добавлю свои 5 копеек.

1) Практика не пройдёт для virtual members — см
http://msmvps.com/blogs/jon_skeet/archive/2009/07/03/evil-code-of-the-day.aspx
http://bartdesmet.net/blogs/bart/archive/2008/10/31/c-4-0-feature-focus-part-1-optional-parameters.aspx

2) В FCL Guidelines всё придумано за нас:

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 — не более чем сахар для вызова основного мембера и контракт не портят.
Re[5]: Почему плохо иметь много паблик методов?
От: 0x7be СССР  
Дата: 24.11.09 06:39
Оценка:
Здравствуйте, Jack128, Вы писали:

M>>В приведенно примере SameMethod(param1, 0) можно реализовать как внешнюю функцию , внешнюю по отношению к классу или модулю.

J>можно. А зачем??
Что бы не плодить дополнительные сущности в контракте. В С#, начиная с версии 3.0, для решения подобных задач есть хороший механизм — extension methods.
Re[6]: Почему плохо иметь много паблик методов?
От: Sinix  
Дата: 24.11.09 06:47
Оценка: -1
Здравствуйте, 0x7be, Вы писали:

0>Что бы не плодить дополнительные сущности в контракте. В С#, начиная с версии 3.0, для решения подобных задач есть хороший механизм — extension methods.


Ребят, а никому не кажется странным решение в стиле структурного программирования в эпоху развитого ООП? Перед extension methods слегка другие задачи ставились.

Как всегда, уже всё сказано:
http://blogs.msdn.com/brada/archive/2009/01/12/framework-design-guidelines-extension-methods.aspx.
Там же, в комментариях:

...the disadvantages of 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.

Re[7]: Почему плохо иметь много паблик методов?
От: 0x7be СССР  
Дата: 24.11.09 07:24
Оценка: +1
Здравствуйте, 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]
Тут не поспоришь.
"У всех свои недостатки" (с)
Re[8]: Почему плохо иметь много паблик методов?
От: Sinix  
Дата: 24.11.09 07:34
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Здравствуйте, Sinix, Вы писали:


0>Не совсем. В данном случае extension methods не добавляют функциональности классу/интерфейсу, который расширяют, а всего ли реализую некоторые часто употребляемые паттерны вызова. При этом эти паттерны могут быть специфичны для конкретного случая использования и не являются каким-то неотъемлемым свойством потребляемого интерфейса.


Ну вообще-то расширения изначально планировались контекстными. Грубо говоря using System.Net — и у строки появляются фичи, нужные для работы с сетями (например "localhost".Ping()). Пруфлинк не найду. В мейнстриме реализация ограничилась линком (и правильно имхо).

0>В эпоху развитого intellisense это не так

Развитому интеллисенсу надо ещё скормить пачку юзингов. Ну и не все изучают библиотеки через автодополнение. Тот же рефлектор о наличии расширений умалчивает.

0>"У всех свои недостатки" (с)

+1
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.