Здравствуйте!
[C# 4.0]

Вот столкнулся с такой проблемой.
1. Есть такие сущности:

class Person
{
  Guid ID {get;set;}
  ...
}

class PersonConsumer
{
  Guid ID {get;set;}
  Guid PersonID {get;set;}
  ...
}

class PersonAccount
{
   Guid ID {get;set;}
   Guid PersonConsumerID {get;set;}
}

Физ.лицо, Потребитель Физ.лицо, Лицевой счёт физ.лица, соотвественно.

2. Тож же самое, но для юр.лиц:

class Organization
{
  Guid ID {get;set;}
  ...
}

class OrgConsumer
{
  Guid ID {get;set;}
  Guid OrgID {get;set;}
  ...
}

class OrgAccount
{
   Guid ID {get;set;}
   Guid OrgConsumerID {get;set;}
}

Есть ли какая-нибудь замена для более короткого обозначения PersonConsumer и OrgConsumer. Дело в том, что эти названия потом очень часто повторяются в названиях других классов и сущностей (н-р: PersonConsumerMeterReadingPaymentPurposeParams — вместо выделенного, есть ещё длиннее ), тем самым определяя принадлежность: к физ.лицу или к юр лицу.

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

Спасибо.

А>Вопрос по ходу, а как должен называться общий (абстрактный) Person?
Общая категория для физлица и юрлица это что-то типа "контрагент"
А>XxxxxxxZzzzzzzzzPaymentPurposeParams — в зависимости от услуги, могут быть разные квитанции на оплату, в которых могут быть разного вида параметры оплаты (PaymentPurposeParams)
Можно примеры? Не присутствует ли здесь антипаттерн "mixing data with metadata" (как например некоторые разбивают документы разных фирм по нескольким одинаковым таблицам с разными именами)?

Здравствуйте, Аноним, Вы писали:

Разбираясь в подобном коде, я бы предпочел длинные и понятные названия коротким и непонятным.

А что вас смущает в длинных названиях? То, что никто обычно не делает длинных названий? или тяжело печатать? Если последнее, то поставьте себе "Resharper" — отличная вещь.

Я считаю, что во всем нужно руководствоваться логикой. Что из того, если все обычно не делают того, что в данном случае
целесообразно? Обычно не делают, потому что обычно такой потребности не возникает. Если у вас возникла объективная потребность сделать что-то, нерационально было бы отказываться от этого лишь из-за единственного аргумента "так обычно не делают".

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

Если название непонятное, то какая вообще к чертовой матери разница — длинное оно или короткое?

Да, и еще, мне кажется у вас в архитектуре присутствует некоторая нерациональность и дублирование. Если PersonConsumer и OrganizationConsumer оба являются потребителями (о чем намекает название), возможно, стоит выделить базовый класс Consumer, а если производные классы мало чем отличаются от базового, возможно стоит и оставить только класс Consumer, добавив свойство Type.

А> полный формат вместе с namespace-ом, что не сильно-то облегчает чтение
А> кода.
На 1й взгляд, PaymentЧегототам должен быть одного типа для физ. и юр., и
ссылаться на абстрактного Person. Чем вызвано создание отдельных FizPayment
и UrPayment? У них есть какие-то разные атрибуты?

Здравствуйте, Osaka, Вы писали:
O>На 1й взгляд, PaymentЧегототам должен быть одного типа для физ. и юр., и
O>ссылаться на абстрактного Person.
Вопрос по ходу, а как должен называться общий (абстрактный) Person?

O>Чем вызвано создание отдельных FizPayment и UrPayment? У них есть какие-то разные атрибуты?
Разные виды и формы оплаты, и, соответственно, атрибуты.

XxxxxxxZzzzzzzzzPaymentPurposeParams — в зависимости от услуги, могут быть разные квитанции на оплату, в которых могут быть разного вида параметры оплаты (PaymentPurposeParams)

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

А>>Вопрос по ходу, а как должен называться общий (абстрактный) Person?
O>Общая категория для физлица и юрлица это что-то типа "контрагент"
Не совсем так. любое лицо может участвовать в работе системы. Для правильного учёта, не должно быть просто каких-то "лиц". Они все должны быть заведены в соответствующие справочники: физ. лицо или юр лицо. Далеко не всегда юр.лицо, например, будет участвовать в каких-либо договорных отношениях (например, какой нибудь орган исполнительный власти; работодатель плательщика, который должен быть сохранён в базе, но не обязательно участвуюйщий в учёте и т.п.

А>>XxxxxxxZzzzzzzzzPaymentPurposeParams — в зависимости от услуги, могут быть разные квитанции на оплату, в которых могут быть разного вида параметры оплаты (PaymentPurposeParams)
O>Можно примеры? Не присутствует ли здесь антипаттерн "mixing data with metadata" (как например некоторые разбивают документы разных фирм по нескольким одинаковым таблицам с разными именами)?
Нет, такого здесь точно нет. Да и примеров-то особо и нет — пока идёт набрасывание ObjectModel-и (очень много связанных объектов: unit-тесты только в ближайшей перпеспективе). Тут проблему разрешили по другому, ещё раз пересмотрели структуру платежа.

PS. Прошу прощения за, практически, некропост

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>Разбираясь в подобном коде, я бы предпочел длинные и понятные названия коротким и непонятным.

А>А что вас смущает в длинных названиях? То, что никто обычно не делает длинных названий? или тяжело печатать? Если последнее, то поставьте себе "Resharper" — отличная вещь.

А>Я считаю, что во всем нужно руководствоваться логикой. Что из того, если все обычно не делают того, что в данном случае
А>целесообразно? Обычно не делают, потому что обычно такой потребности не возникает. Если у вас возникла объективная потребность сделать что-то, нерационально было бы отказываться от этого лишь из-за единственного аргумента "так обычно не делают".

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

А>Если название непонятное, то какая вообще к чертовой матери разница — длинное оно или короткое?

А>Да, и еще, мне кажется у вас в архитектуре присутствует некоторая нерациональность и дублирование. Если PersonConsumer и OrganizationConsumer оба являются потребителями (о чем намекает название), возможно, стоит выделить базовый класс Consumer, а если производные классы мало чем отличаются от базового, возможно стоит и оставить только класс Consumer, добавив свойство Type.
Спасибо! В принципе, так и думал. Правда сейчас, уже, добавли ещё один уровень абстракции: всё по гражданскому кодексу (в конце-концов, там не часто меняется вид субъектов) все делятся на физ.лиц и юр.лиц. А контрагенты разбиты на две группы: физ.лица и юр.лица (объяснения постом выше). А те уже, в свою очередь, разбиваются по видам. Мне кажется, так будет удобнее всем.

Здравствуйте, Аноним, Вы писали:
А>Мне кажется, так будет удобнее всем.
Или я ошибаюсь

Здравствуйте, Аноним, Вы писали:

А>>Да, и еще, мне кажется у вас в архитектуре присутствует некоторая нерациональность и дублирование. Если PersonConsumer и OrganizationConsumer оба являются потребителями (о чем намекает название), возможно, стоит выделить базовый класс Consumer, а если производные классы мало чем отличаются от базового, возможно стоит и оставить только класс Consumer, добавив свойство Type.
А>Спасибо! В принципе, так и думал. Правда сейчас, уже, добавли ещё один уровень абстракции: всё по гражданскому кодексу (в конце-концов, там не часто меняется вид субъектов) все делятся на физ.лиц и юр.лиц. А контрагенты разбиты на две группы: физ.лица и юр.лица (объяснения постом выше). А те уже, в свою очередь, разбиваются по видам. Мне кажется, так будет удобнее всем.
Это тоже самое, что тебе хотел сказать Osaka: "mixing data with metadata".