Может, тогда всю тамошнюю тему процитируете, раз уж хочется ссылками перебрасываться? Речь шла о том, почему плохо иметь два паблик метода, делающих абсолютно одно и то же и отличающихся лишь формой вызова.
И да, вы знаете, сто методов в публичном контракте это плохо само себе, потому что у класса как бы обычно есть свое узкое предназначение. В противном случае вообще неясно, зачем вы программирует на ОО-языке.
Может, стоит, кстати, издалека начать? Давайте вы спросите, зачем нужны классы если все можно лепить внутри одного static class Program.
J>очевидно посмотрев на код метода. И все сразу станет понятно. А если менять метод, не смотря на его текущую реализацию, то косячить наш сферический "другой программист" булет постоянно.
Ну в вашей вселенной для любых изменений, видимо, придется изучать весь написанный до этого код. К счастью, обычно это не так.
Здравствуйте, Jack128, Вы писали:
J>Один авторитетный, судя по рейтингу, rsdn'овиц заявил сабж. Кто ниту может объяснить почему так?
Для начала следует определиться о каких классах идет речь: о библиотеках или о класса бизнес-логики. Этот момент очень важен, т.к. акценты в обоих случаях существенно отличаются.
Если речь идет о библиотеках, то ключевой вопрос, который задает себе архитектор следующий: как мне сделать так, чтобы этот класс (или библиотеку целиком) вообще использовали, а не принялись выдумывать собственный велосипед? В этом случае предъявляются другие требования к качеству и надежности, команда разработчиков проводит всяческие usability studies для определения и уменьшения "порога вхождения" (сколько нужно времени пользователю, чтобы он смог начать успешно пользоваться библиотекой). В случае с библиотечным классом не целесообразно разбивать класс на несколько, с целью упрощения последующего сопровождения; главным в этом случае был и остается пользователь библиотеки, а не ее разработчик. Для проектирования библиотек требует больше опыта и меньше фантазиии, чем более распространенные решения будут применяться, тем больше вероятность, что они будут удобны и понятны пользователю
(в Framework Design Guidelines достаточно много внимания уделено вопросу разработки библиотек и большая часть проблем, с которыми сталкиваются разработчики библиотек, поэтому если вопрос касается библиотек — то вам туда)
Итак, далее я буду рассчитывать, что речь идет о сущностях, предназначенных для решения некоторых бизнес-задач некоторого приложения и что эти сущности не предназначены для повторного использования в тысячами или десятками тысяч клиентов.
Ключевые проблемы, с которыми сталкиваются проектировщики (причем не только программного обеспечения) были замечены более 40 лет назад (возможно раньше...). Одними из первых в области разработки ПО эти принципы озвучили Эд Йордон и Ларри Константайн в 1979 году в своей книге “Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design” основываясь на понятиях, приведенных в книге Кристофера Алексендера “Notes On The Synthesis Of Form”.
По мнению Александера основной задачей при декомпозиции системы является осуществление следующих двух условий:
— максимизация связей внутри компонентов (высокое сцепление, high cohesion) и
— минимизация связей между компонентами (низкая связанность, low coupling).
Кроме этого, позднее был определен ряд принципов и критериев, качества проектной модели.
В частности существует ряд принципов проектирования, получивших название SOLID:
— S — SRP — Single responsibility principle
— O — OCP — Open/closed principle
— L — LSP — Liskov substitution principle
— I — ISP — Interface segregation principle
— D — DIP — Dependency inversion principle
А также существует ряд критериев для определения качества абстракции: зацепление; связность; достаточность; полнота; примитивность (подробнее см. книгу Гради Буча "ООА и ООП").
Несмотря на наличие достаточного количества формальных принципов, все в конечном итоге зависит от опыта и навыков архитектора, и зачастую интуиции и опыта бывает достаточно, чтобы судить о качестве тех или иных архитектурных решений. При этом, нельзя говорить, что количество открытых функций в этом вопросе играет решающую роль, любой "раздутый" класс тяжело анализировать, будь в нем 50 открытых функций, 50 защищенных или 100 закрытых.
Предположим есть класс, который содержит 2 открытые функции, семантически никак не связанные друг с другом, содержит 27 защищенных функции и 53 закрытых, а также содержит 20 членов данных. Этот класс отвечает критерию небольшого открытого интерфейса, но при этом обладает слабым сцеплением и высокой связанностью, и написан через одно место, поэтому разобрать для чего он нужен и нужен ли вообще, представляется весьма сложным...
Не нужно быть буквальным и всегда четко следовать определенным принципам... В конечном итоге основная задача разработчиков — это создать готовый продукт к определенному сроку с определенным функционалом и качеством. Хороший дизайн не должен быть самоцелью, это всего лишь средство упростить решение текущих задач и уменьшить стоимость последующих доработок или сопровождения. Кроме того, многие разработчики склонны считать, что все, что сделано не ими является ошибочным, поэтому как бы вы не стремились, но даже самый хороший дизайн, будет не понятен тем, кто не захочет его понимать.
Здравствуйте, Jack128, Вы писали:
J>отсюда следует просто вывод: в классе вообще _не должно_ быть методов, которые вызывают только паблик методы этого класса.
Совершенно верно.
J> Ты сам действительно так пишешь???
Да, действительно так пишу. Код от этого значительно чище и понятнее — попробуй.
ВВ>Может, тогда всю тамошнюю тему процитируете, раз уж хочется ссылками перебрасываться? Речь шла о том, почему плохо иметь два паблик метода, делающих абсолютно одно и то же и отличающихся лишь формой вызова.
авторитетный товарищ согласился, что это вполне допустимо. как тебя понимать, Саид??
А вообще — было бы хорошо иметь запрет на уровне синтаксиса — у класса не более 99 методов. Было бы круто
ВВ>И да, вы знаете, сто методов в публичном контракте это плохо само себе, потому что у класса как бы обычно есть свое узкое предназначение. В противном случае вообще неясно, зачем вы программирует на ОО-языке.
ВВ>Может, стоит, кстати, издалека начать? Давайте вы спросите, зачем нужны классы если все можно лепить внутри одного static class Program.
J>>очевидно посмотрев на код метода. И все сразу станет понятно. А если менять метод, не смотря на его текущую реализацию, то косячить наш сферический "другой программист" булет постоянно.
ВВ>Ну в вашей вселенной для любых изменений, видимо, придется изучать весь написанный до этого код. К счастью, обычно это не так.
Здравствуйте, minorlogic, Вы писали:
J>>есть метод J>>public void SameMethod(int param1, int param2)
J>>в 90% случаев он используется SameMethod(param1, 0)
M>В приведенно примере SameMethod(param1, 0) можно реализовать как внешнюю функцию , внешнюю по отношению к классу или модулю.
в данном случае эта функция не нужна.
Если параметров не два а поболе, лучше тогда параметры вынести в отдельный класс и там поперегружать конструкторы.
Здравствуйте, Jack128, Вы писали:
J>Один авторитетный, судя по рейтингу, rsdn'овиц заявил сабж. Кто ниту может объяснить почему так?
Само по себе число public методов (и классов) не о многом говорит, и минимизировать их число не самоцель.
У Enumerable<T> много public методов, а приватных могло бы вобще не быть. И они практически независимы, связаны только по смыслу.
Хорошо не минимальное число public, а когда мухи от котлет хорошо отделены.
Если делается интерфейс над подсистемой в виде сложного(и внутри сильно повязанного) графа, не поддающегося разделению. Т.е. публик члены образуют неделимую систему, и у нее сложная реализация, тогда однозначно выметать оттуда все хелперы — маленькие функции которые можно сделать снаружи успользуя публичный интерфейс.
А если класс — это хелпер какой-то, то пихать можно все что упростит частое использование.
Хелперы не нужно совсем удалять просто они должны быть в соответствующих местах.
А для промежуточных случаев, однозначно ничего не скажешь, дело вкуса.
Дурные примеры минимизации public тоже есть:
Взять например DirectX 10. То что там сделали в некоторых местах это просто ужасно, ни в какие рамки не лезет. То что он низкоуровневый не оправдание . Единственные оправдания — то что он в виде COM интерфейса и очень публичный.
Там применен стиль — "флаговое программирование". Это делается так, собирается несколько классов с совершенно разным функционалом, сваливается все в один (например, буфер). И при помощи флажков, при создании объекта указывается какой функционал создать. В дальнейшем, какие функции в этом классе можно вызывать и с какими комбинациями флажков, зависит от того с какими флажками создали. При недопустимых комбинациях либо ошибка "invalid parametr passed" , либо вызов игнорируется. Причем допустимых комбинаций гораздо меньше 1% от общего числа.
Видимо такой вид API не из-за кривых рук(хотя это тоже возможно), а из-за попыток уменьшить число COM интерфейсов, флажки ведь в COM гораздо дешевле.
То что в документации наверно процентов 15% текста, это оговорки — "Если с таким то флажком раньше такую-то функцию вызывал, то теперь эту функцию с таким флажком уже не вызовешь." Или — "Если этот флажок указан, то он отменяет все остальные".
Это еще не значит что они описали все грабли, их гораздо больше.
Здравствуйте, Jack128, Вы писали:
J>Один авторитетный, судя по рейтингу, rsdn'овиц заявил сабж. Кто ниту может объяснить почему так?
1. Меньше знаешь, лучше спишь
2. Windows — поставил и работай. Unix — вы можете сконфигурировать всё!!! И вы будете конфигурировать всё
3. ...
А фиг с ним с примерами
Удобство — это основа. Публичных методов должно быть ровно столько, чтобы можно выполнить работу, и ни на один метод больше, чтобы не смущать нежные умы начинающих и малоопытных. Это как в той истории про Дзен, когда учитель говорит, что главное — это баланс, но чтоб прийти к этой истине тебе сначала скажут, что "плохо иметь много паблик методов?", потом ты поймёшь, что на самом деле иногда можно, затем, что на самом деле всё равно, и в итоге, что самое главное — это соблюдать баланс между тем, что нужно и тем что удобно.
J>Один авторитетный, судя по рейтингу, rsdn'овиц заявил сабж. Кто ниту может объяснить почему так?
На самом деле всё очень просто.
Паблик методы — это внешний интерфейс: его надо согласовывать, за него надо отвечать, его надо описывать, его надо поддерживать.
Здравствуйте, VGn, Вы писали:
J>>Один авторитетный, судя по рейтингу, rsdn'овиц заявил сабж. Кто ниту может объяснить почему так?
VGn>На самом деле всё очень просто. VGn>Паблик методы — это внешний интерфейс: его надо согласовывать, за него надо отвечать, его надо описывать, его надо поддерживать.
Это не отвечает на вопрос почему это плохо, т.к. от того, что эти методы будут разбиты на группы и разбросаны по нескольким классам, "совокупный" публичный интерфей от этого не уменьшится.
L>Это не отвечает на вопрос почему это плохо, т.к. от того, что эти методы будут разбиты на группы и разбросаны по нескольким классам, "совокупный" публичный интерфей от этого не уменьшится.
Про количество классов вопроса не было. Был вопрос про количество методов.
Если, перемещаясь в другой класс, методы остаются публичными, при чём "много паблик методов"? Можете их вообще в веб-интерфейс перевести. Меньше их от этого не станет.
Здравствуйте, VGn, Вы писали:
L>>Это не отвечает на вопрос почему это плохо, т.к. от того, что эти методы будут разбиты на группы и разбросаны по нескольким классам, "совокупный" публичный интерфей от этого не уменьшится.
VGn>Про количество классов вопроса не было. Был вопрос про количество методов. VGn>Если, перемещаясь в другой класс, методы остаются публичными, при чём "много паблик методов"? Можете их вообще в веб-интерфейс перевести. Меньше их от этого не станет.
ну и тогда нахрен их вообще перемещать куда то? плодить кучу классов просто так??
Здравствуйте, Jack128, Вы писали:
J>ну и тогда нахрен их вообще перемещать куда то? плодить кучу классов просто так??
Да и зачем вообще классы нужны? WinAPI рулит!
Здравствуйте, Lloyd, Вы писали:
L>Это не отвечает на вопрос почему это плохо, т.к. от того, что эти методы будут разбиты на группы и разбросаны по нескольким классам, "совокупный" публичный интерфей от этого не уменьшится.
Во-первых не факт.
Во-вторых с большой вероятностью уменьшится объем писанины — не надо будет объяснять, чем конкретно вот этот метод отличается от вон того, такого же, но без одного параметра.
Ну и в-третьих если в разных местах кода требуется вызов разных методов, то описать это с помощью разных интерфейсов — часто бывает неплохой идеей само по себе, безотносительно размера "совокупного интерфея".
Здравствуйте, Jack128, Вы писали:
J>ну и тогда нахрен их вообще перемещать куда то? плодить кучу классов просто так??
потому что с классами Список, Стек, Дерево, Словарь и т.п. гораздо удобнее работать чем с классом Хранилище_Эмулирующее_Любое_Поведение с кучей флажков и методов которые нужно дернуть в правильном порядке для превращения Хранилища в Список, Стек, Дерево, Словарь и т.п.
Здравствуйте, jhfrek, Вы писали:
J>Здравствуйте, Jack128, Вы писали:
J>>ну и тогда нахрен их вообще перемещать куда то? плодить кучу классов просто так??
J>потому что с классами Список, Стек, Дерево, Словарь и т.п. гораздо удобнее работать чем с классом Хранилище_Эмулирующее_Любое_Поведение с кучей флажков и методов которые нужно дернуть в правильном порядке для превращения Хранилища в Список, Стек, Дерево, Словарь и т.п.
понимаешь, бывает я ничего не имеею против "single responsibility principle" . Тока нарушение этого приниципа — не единственная причина, которая приводит к большому кол-ву методов. Что делать в таких случаях??
Здравствуйте, Jack128, Вы писали:
J>понимаешь, бывает я ничего не имеею против "single responsibility principle" . Тока нарушение этого приниципа — не единственная причина, которая приводит к большому кол-ву методов. Что делать в таких случаях??
Здравствуйте, jhfrek, Вы писали:
J>Здравствуйте, Jack128, Вы писали:
J>>понимаешь, бывает я ничего не имеею против "single responsibility principle" . Тока нарушение этого приниципа — не единственная причина, которая приводит к большому кол-ву методов. Что делать в таких случаях??
J>нужен пример "не единственной причины"
Здравствуйте, Jack128, Вы писали:
J>>>понимаешь, бывает я ничего не имеею против "single responsibility principle" . Тока нарушение этого приниципа — не единственная причина, которая приводит к большому кол-ву методов. Что делать в таких случаях??
J>>нужен пример "не единственной причины"
J>пример класса: Control .
чего Control? — графический али реальный ака рубильник
Как вариант: методы Enable\Disable, Perform и свойство Enabled, хотя может быть достаточно одного Perform
Мы уже победили, просто это еще не так заметно...
