Добрый день, подскажите плиз материалы где бы была информация (или посоветуйте какие-то свои идеи), о том, как именовать классы, чтобы было в целом понятно что и где искать? Про entity и DAC/DAL все понятно... а как насчет остального?
А>Добрый день, подскажите плиз материалы где бы была информация (или посоветуйте какие-то свои идеи), о том, как именовать классы, чтобы было в целом понятно что и где искать? Про entity и DAC/DAL все понятно... а как насчет остального?
Я не встречал стандартныъ рекомендаций, по крайней мере ничего, что было бы направлено на упрощение понимания. Обычно достаточно, чтобы имя класса отражало его назначение. И при вменяемой декомпозиции именование не будет проблемой.
Re[2]: Именование классов
От:
Аноним
Дата:
24.05.11 13:03
Оценка:
Здравствуйте, pagrus, Вы писали:
А>>Добрый день, подскажите плиз материалы где бы была информация (или посоветуйте какие-то свои идеи), о том, как именовать классы, чтобы было в целом понятно что и где искать? Про entity и DAC/DAL все понятно... а как насчет остального?
P>Я не встречал стандартныъ рекомендаций, по крайней мере ничего, что было бы направлено на упрощение понимания. Обычно достаточно, чтобы имя класса отражало его назначение. И при вменяемой декомпозиции именование не будет проблемой.
А может вы встречали обсуждения какие классы именовать например xxxFacade или xxxHelper или xxxWorker ?
А>А может вы встречали обсуждения какие классы именовать например xxxFacade или xxxHelper или xxxWorker ?
Надо стараться не включать в имена типов и методов общие, ни о чем не говорящие слова, а также названия когда-то примененных паттернов (OrdersManager, QuickSortStrategy, TheThirdTabPresenter, MainView, Worker.DoStuff(), MainProcessor.ProcessNext(), CustomerRepository.Get() и тому подобный бред). Если никак не получается придумать хорошее имя — на 98% перед нами god-тип.
Здравствуйте, -VaS-, Вы писали: VS>Надо стараться не включать в имена типов и методов общие, ни о чем не говорящие слова, а также названия когда-то примененных паттернов (OrdersManager, QuickSortStrategy, TheThirdTabPresenter, MainView, Worker.DoStuff(), MainProcessor.ProcessNext(), CustomerRepository.Get() и тому подобный бред). Если никак не получается придумать хорошее имя — на 98% перед нами god-тип.
Хм... Почему?
Person
PersonView
PersonComparer
PersonRepository
PersonTypeConverter
PersonTypeEditor
Здравствуйте, Аноним, Вы писали:
А>Добрый день, подскажите плиз материалы где бы была информация (или посоветуйте какие-то свои идеи), о том, как именовать классы, чтобы было в целом понятно что и где искать? Про entity и DAC/DAL все понятно... а как насчет остального?
В вопросе наименований классов, методов, переменных и т.д. как-то мало правил, много творчества. Класс должен иметь единое назначение, собственно пишете это назначение в названии. Если назначение трудно выразить или оно не одно, значит что-то не то. Чтобы понять как лучше коротко выразить назначение: напишите комментарий к классу, как бы вы ответили на вопрос коллеги "Для чего нужен этот класс", обычно это несколько строчек. Посмотрите на получившееся, оставьте 2, а если надо, то 3 слова.
Здравствуйте, Аноним, Вы писали:
А>Добрый день, подскажите плиз материалы где бы была информация (или посоветуйте какие-то свои идеи), о том, как именовать классы, чтобы было в целом понятно что и где искать? Про entity и DAC/DAL все понятно... а как насчет остального?
Я бы порекомендовал тщательно изучить замечательный труд
K>Person K>PersonView K>PersonComparer K>PersonRepository K>PersonTypeConverter K>PersonTypeEditor
K>ИМХО удобно, из названия сразу следует что и как
Что касается подобных классов, то, в силу их процедурной природы и отсутствия какого-либо самостоятельного поведения (personFromLayer22 = _personTypeConvertor.Convert(personFromLayer21) — это не поведение класса, это процедура, одна из многих, сгруппированных в "класс"), именовать их иначе просто невозможно, да и не нужно — все это малоинтересный инфраструкрурный слой адаптеров.
Я же говорил про ООП и классы, образующие доменное поведение.
Re[2]: Именование классов
От:
Аноним
Дата:
30.05.11 05:52
Оценка:
Здравствуйте, Nuseraro, Вы писали:
N>В вопросе наименований классов, методов, переменных и т.д. как-то мало правил, много творчества. Класс должен иметь единое назначение, собственно пишете это назначение в названии. Если назначение трудно выразить или оно не одно, значит что-то не то. Чтобы понять как лучше коротко выразить назначение: напишите комментарий к классу, как бы вы ответили на вопрос коллеги "Для чего нужен этот класс", обычно это несколько строчек. Посмотрите на получившееся, оставьте 2, а если надо, то 3 слова.
Класс да... единое назначение, но аспектов сущности может быть тьма. Например по Person : DAC, хелперные методы для расширения Enumerable, бизнес правила (тут может быть еще полно аспектов), мапинг в json, хелперные методы для отображения на web формах, хелперные методы для выгрузки в файл на клиенте, если есть web service интерфейс то опять же могут появится аспекты...
А если таких сущностей с десяток (а реально это десятки) то никаких комментариев не начитаешься. А хуже всего из за отсутствия подхода к наименованию, "не сильно аккуратные" программисты валят вообще все аспекты в один класс. Потому собственно я и задался данным вопросом.
Мс например делает кое какие шаги в направлении снижения бардака. Например в mvc они перешли от "конфигурирования" к стандартам наименования, что имхо очень грамотно.
Здравствуйте, Аноним, Вы писали:
А>Добрый день, подскажите плиз материалы где бы была информация (или посоветуйте какие-то свои идеи), о том, как именовать классы, чтобы было в целом понятно что и где искать? Про entity и DAC/DAL все понятно... а как насчет остального?
Имя должно отражать, назначение класса исходя из принципа единой ответственности. Тип как правило совершает какие-то действия над какими-то сущностями или абстракциями, вот из этого и надо исходить и стараться именовать СущностьДействие.
Re[2]: Именование классов
От:
Аноним
Дата:
02.06.11 09:51
Оценка:
Здравствуйте, diez_p, Вы писали:
_>Имя должно отражать, назначение класса исходя из принципа единой ответственности. Тип как правило совершает какие-то действия над какими-то сущностями или абстракциями, вот из этого и надо исходить и стараться именовать СущностьДействие.
Спасибо, интересно... Но еще есть entity классы не совершают действий и таких классов на одну бизнес сущность может быть несколько (доменный обьект, json, Db entity, win service entity) может подскажете как их именовать?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, diez_p, Вы писали:
_>>Имя должно отражать, назначение класса исходя из принципа единой ответственности. Тип как правило совершает какие-то действия над какими-то сущностями или абстракциями, вот из этого и надо исходить и стараться именовать СущностьДействие.
А>Спасибо, интересно... Но еще есть entity классы не совершают действий и таких классов на одну бизнес сущность может быть несколько (доменный обьект, json, Db entity, win service entity) может подскажете как их именовать?
У меня таких ситуаций не было. Но тут, как всегда есть компромисс, касаемо в .NET одинаковые имена классов можно разрулить вот так
допустим 2 пространства имен:
Web.Presenter.JSON
Web.Data.Entity
в каждом есть по Person
using Ui=Web.Presenter.JSON;
using Dal=Web.Data.Entity;
// использование
Ui.Person uiPerson = new Ui.Person();
Dal.Person dalPerson = new Dal.Person();
Если же такое перекрытие повсеместно, то я бы наиболее широко используемую абстракцию обозначил как Person, а остальное PersonUiData или PersonDalData, имена не нравятся, но в голову ничего лучше не пришло.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, diez_p, Вы писали:
_>>Имя должно отражать, назначение класса исходя из принципа единой ответственности. Тип как правило совершает какие-то действия над какими-то сущностями или абстракциями, вот из этого и надо исходить и стараться именовать СущностьДействие.
А>Спасибо, интересно... Но еще есть entity классы не совершают действий и таких классов на одну бизнес сущность может быть несколько (доменный обьект, json, Db entity, win service entity) может подскажете как их именовать?
Не должно быть таких классов. Если у вас Person достается из баз, то он же должен сериализоваться в JSON для передачи по сети. А еще лучше настраивать маппинг на БД с помощью expression tree, чтобы компилятор проверял правильность замапенных полей.
Re[4]: Именование классов
От:
Аноним
Дата:
03.06.11 06:03
Оценка:
Здравствуйте, gandjustas, Вы писали:
G>Не должно быть таких классов. Если у вас Person достается из баз, то он же должен сериализоваться в JSON для передачи по сети. А еще лучше настраивать маппинг на БД с помощью expression tree, чтобы компилятор проверял правильность замапенных полей.
Как мне кажется данный подход серьезно нарушает "Single responsibility", к тому же он никак не решает проблемы с доменными обьектами, win service entity и различными entity которые возникают в бизнес слое.
Для json конечно есть привлекательный (и иногда годный) выход — вынести код в отдельный класс serializer/deserializer (т.к. на выходе/входе строка). Но на практике композиция объектов из бд не всегда тождественна композиции объектов json для отправки на клиент.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, gandjustas, Вы писали:
G>>Не должно быть таких классов. Если у вас Person достается из баз, то он же должен сериализоваться в JSON для передачи по сети. А еще лучше настраивать маппинг на БД с помощью expression tree, чтобы компилятор проверял правильность замапенных полей.
А>Как мне кажется данный подход серьезно нарушает "Single responsibility"
Каким образом? Сериализация, маппинг и BL не находятся в классе Person, там находятся только данные. SRP не нарушишь никак.
А>к тому же он никак не решает проблемы с доменными обьектами, win service entity и различными entity которые возникают в бизнес слое.
Ну и пусть возникают. Есть person, который достается из базы и может быть в нее сохранен, есть PersonWithOrders для отображения, который также достается из базы (но уже не сохраняется), оба сериализуются в JSON внешним сериализатором.
А>Для json конечно есть привлекательный (и иногда годный) выход — вынести код в отдельный класс serializer/deserializer (т.к. на выходе/входе строка).
Так и нужно делать, иначе ты нарушаешь SRP.
А>Но на практике композиция объектов из бд не всегда тождественна композиции объектов json для отправки на клиент.
А сделать гибкий маппинг, как для БД — не судьба? Или использовать классы вроде PersonWithOrders ?
А>А может вы встречали обсуждения какие классы именовать например xxxFacade или xxxHelper или xxxWorker ?
Увы, тоже нет, но здесь у меня есть пара косьвенных соображений.
* Если функции компонента выражаются через широко известный паттерн, лучше использовать его имя. Например, Facade — это хорошо описанный и известный паттерн.
Соответственно,
* Если функции компонента не выражаются через широко известный паттерн, лучше не использовать его имя.
* imho xxxHelper — это плохое имя. В мей практике такие компоненты появлялись, когда
— лень/нехватает квалификации провести декомпозицию
— но видно, что компонент перегружен функциями
— так вынесу-ка я из него функции наружу
— вынесу в "helper" — свалку для всего, что непонятно куда пристроить.
* Чтобы выбрать имя, имеет смысл сформулировать responsibility компонента. Например,
— xxx выполняет преобразование из X в Y
— xxx выставляет сервис X как веб-сервис
— xxx предлагает набор утилитных методов, предназначенных для X
— xxx реализует часть бизнес-логики: расчёт скидки для заказа
и т.д.
обычно это приводит к одному из двух вариантов
1. становится понятно, как назвать компонент
2. оказывается, что компонент делает слишком много всякого и непонятно что в целом. Тогда имеет смысл пересмотреть компоненты на предмет следования SRP. (этим путём идут Helper'ы)
3. выясняется, что проблема просто в английском — кратко перевести название. Тут лучше просто спросить кого-нибудь с хорошим знанием языка.
* Не стоит использвать несколько подходов к именованию в коде одного проекта. Лучше уж не сильно удачный, но один.
* Помогает, когда дизайн/архитектура хоть как-от задокументирована. Все смотрят на, скажем, sequence-диаграмму, и не только реадизуют, но и именуют компоненты как нарисовано.
Re[6]: Именование классов
От:
Аноним
Дата:
10.06.11 11:21
Оценка:
Здравствуйте, gandjustas, Вы писали:
G>>>Не должно быть таких классов. Если у вас Person достается из баз, то он же должен сериализоваться в JSON для передачи по сети. А еще лучше настраивать маппинг на БД с помощью expression tree, чтобы компилятор проверял правильность замапенных полей.
А>>Как мне кажется данный подход серьезно нарушает "Single responsibility" G>Каким образом? Сериализация, маппинг и BL не находятся в классе Person, там находятся только данные. SRP не нарушишь никак.
Ну т.е. мы вернулись к изначальному вопросу — по какому принципу именовать кучу разных классов реализующих аспекты (и представления) сущности "Person".
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, gandjustas, Вы писали:
G>>>>Не должно быть таких классов. Если у вас Person достается из баз, то он же должен сериализоваться в JSON для передачи по сети. А еще лучше настраивать маппинг на БД с помощью expression tree, чтобы компилятор проверял правильность замапенных полей.
А>>>Как мне кажется данный подход серьезно нарушает "Single responsibility" G>>Каким образом? Сериализация, маппинг и BL не находятся в классе Person, там находятся только данные. SRP не нарушишь никак.
А>Ну т.е. мы вернулись к изначальному вопросу — по какому принципу именовать кучу разных классов реализующих аспекты (и представления) сущности "Person".
Сериализация делается обобщенными сериализаторами, доставание и сохранение в базе — ORM, логика живет в контроллере, который нужно будет именовать уже не от сущности, а если будет только crud, то можно также обобщенный алгоритм придумать. Если в контроллере повторяющиеся куски логики, то их вынести в отдельные методы и сгруппировать по смысловому признаку. Может быть какой-нибудь PersonManager появится.
Автор(ы): С. Макконнелл
