Как часто Вы разбиваете описание одного класса на несколько файлов через partial?

Question

[littleguga]

Чем плох этот подход? Пока я вижу только плюсы.
Также иногда разбиваю ui функции по отдельным файлам - нормально это? Или как и куда(в какой класс) прописывать функции ui(клик по кнопке, drag&drop на окно и т.д.)

Answer 1

[Петр]

В моих проектах partial присутствует только для классов описания форм в WinForms.
И явно он больше и не нужен. Классы нужны для какого-то конкретно функционала и если в одном классе кода становится столько, что у добнее разбить на файлы, то явно такой класс можно разбить и на более мелкие классы.

Comments

[Алексей Кулаков]

В идеальном мире - да, таких больших классов не должно быть. Но на практике бывают случаи, что классы берут на себя очень много работы и эта работа должна производиться именно этими классами, потому что она связанна основной функцией этого класса. Внутри себя они конечно используют какие-то более узко специализированные классы.

Может быть и стоило бы разделить их на более мелкие, но это же нужно тестировать и тратить время на разделение. А иногда начальство осознанно не дает времени на рефакторинг, то есть они знают что такие классы есть, их уведомили о последствиях, но новые фичи им важнее поддержания кода в хорошем состоянии.

А еще бывают проекты без тестов вообще, где куча хомячков проверяет все и вся, пробегая по всей функциональности, потому что нанять кучу индусов дешевле чем тратить время, которое деньги, на покрытие тестами всего проекта. Такое встречается в старых проектах.

Такие дела :)

[Петр]

Алексей Кулаков: Видать у вас отсутствие большого опыта в проектировании.

[Алексей Кулаков]

@peterm Не спорю, в сравнении с кем-то у меня действительно отсутствие большого опыта, а в сравнении с кем-то он есть. Все в мире относительно. Может быть вы не имели опыта с такими проектами и такими компаниями, или еще что. Я повторюсь, реальный мир он далек от вашего совершенства. Что вы будете делать если придете в проект, который уже лет 5 на поддержке и не слабо так разросся, а в нем нет юнит-тестов (его тестируют куча людей, прокликивая все что можно), и он сделан из каких-то костылей? Будете говорить "у вас тут все не правильно давайте переделывать, чтобы архитектура была кошерненькая"? с большой долей вероятности на вас посмотрят как на "не очень понимающего человека". вы хоть представляете сколько труда и бабла уйдет на рефакторинг такого кода? А никто не хочет терять деньги потому что у вас там припекает от архитектуры приложения. Кастомеры хотят новые фичи и отчетики, и начальство уже наобещало новых возможностей потенциальному клиенту. И это не российский проект скажу я вам. Такой он энтерпрайз.

Каждый в этом проекте старается делать новые таски так чтобы было правильно и по возможности вносить свою лепту в рефакторинг, но вот переработать весь проект целиком - это не реально!

[Петр]

Алексей Кулаков: Не реально на потолке спать, хотя тоже можно. )) Работали на поддержке и 5 летних здоровенных проектов и с куда большим уровнем жизни. У проектов есть особенность устаревать, они перестают удовлетворять новым потребностям, а вот тут и появляется возможность для рефакторинга и улучшений. Захотел клиент клиент новый функционал, реализовываем и улучшаем старый код. Если натыкаемся на ограничения устаревающего оборудования, то появляется еще больше возможностей.
Ваша проблема тут "начальство уже наобещало новых возможностей потенциальному клиенту", вы просто не доросли до начальства, когда уже сами решаете, что и как делать.
И верну вас к первоначальному вопросу. В нем говориться о написании в таком стиле нового кода.

[Алексей Кулаков]

офтопик "не реально но можно" = реально ;)
Про начальство и проект который я описывал. Мое начальство - адекватные люди. а вот в соседнем проекте что за стенкой начальство - продаваны. И проект не устаревает и очень даже пользуется популярностью. Наши сотрудники и рады бы его отрефакторить а вот забугорные партнеры не хотят.

Свою точку зрения на этот вопрос я уже высказал в своем ответе. Еще добавлю что нет слов о новом коде в вопросе. Нужно было высказать за и против partial классов.

Изначально я был не согласен с вашим выражением "если в одном классе кода становится столько, что у добнее разбить на файлы, то явно такой класс можно разбить и на более мелкие классы." потому что это не всегда бывает реально сделать в плане отдачи - можно затратить намного больше времени и ресурсов чем может быть выделено

Answer 2

[Станислав Макаров]

Поддержу Петр . В целом, если говорить более формально, partial удобен, если:
1) часть определения класса является генерируемой - что как раз и есть случай с WinForms. Другой пример - генерация интерфейса/определения класса для какого-нибудь веб-сервиса. На 100% не помню, но кажется генератор RAML для ASP.NET WebAPI именно так и делает.
2) когда класс настолько большой, что пора бы уже разбить на два, но вы не можете этого сделать (слишком сложный рефакторинг, или нужно поддерживать совместимость); ну т.е. эдакое грубое решение проблемы. Если вы пишете весь класс руками, то определенно лучше стремиться к тому, чтобы его определение можно было охватить в рамках одного не слишком большого файла.

Answer 3

[Алексей Кулаков]

Разбиваем. Ничего плохого не вижу, все зависит от класса, как и везде главное не переборщить.

У нас есть классы, которые берут на себя много работы и, соответственно, в них много кода. его нужно как-то группировать по функциям. тут либо делать region-ы либо распихать по файлам и обозначить класс как partial

приведу простой пример когда я бы разделил. есть класс, у него есть какие-то методы отвечающие за работу, свойства, поля и сравнительно большое количество event-ов. вероятность того что эти самые эвенты будут часто просматривать не очень велика, в основном смотрят методы потому что в них основная работа. соответственно чтобы эти эвенты глаза не мозолили их можно:
1) запихать в region и свернуть. но! это дело у кого-то будет свернуто у кого-то нет, при поиске по файлу регион, опять таки, может быть развернут и его опять нужно свернуть. неудобненько.
2) договориться убирать эти эвенты в самый конец файла. но! они же когда-нибудь могут понадобится и листать в конец не очень приятно.
3) сделать класс partial и переместить часть с эвентами в отдельный файл. в какой нибудь SuperAwesomeClass.Events.cs. что мы этим добьемся? расчистим основной файл от редко просматриваемых членов класса, группируем некий код по смыслу, получаем быстрый доступ к эвентам если нам понадобится в них заглянуть и они точно будут все и в одном месте.

но это лишь мое имхо.

Answer 4

[Дмитрий Ковальский]

Еще один пример использования partial - расширение функциональности классов-сущностей из Entity Framework.
В собственных классах в 99% не использую, хотя в коде проекта видел контроллер MVC разделенный на 3 файла из-за разростания кол-ва Action, но я считаю это плохой практикой. Для схлопывания больших классов используем регионы (#region) с заранее согласованными именами( закрытые поля, события, публичные методы и т.д.)

Answer 5

[Виктор]

Никогда в жизни не разбивал. Ни разу! Может быть потому, что никогда не кодил на C#? :-)

Comments

[littleguga]

Теги посмотрите, пожалуйста.

[Виктор]

Да посмотрел, конечно. Но пятница, вечер, впереди два дня с прекрасной погодой... Не удержался.
Но если уж по теме - смотрите как будет удобнее. Выработайте одно правило и следуйте ему. Как говорил один мой шеф (правда, слегка в другой области) "Пусть будет безобразно, но единообразно".