Здравствуйте, peer, Вы писали:
P>Если у вас есть уже немспейс
P>Portal.Model.Client
P>и внутри него вы создаете классы валидаций
P>GeneralInfoValidator P>BackHistoryValidator
P>пишите ли вы Client спереди? раньше писал, но вот думаю есть же немспейс ...Client
Я не пишу. Да и вообще любое дублирование схлопываю:
ns Portal.Model.Client.Validator
{
class GeneralInfo;
class BackHistory;
}
Здравствуйте, vopl, Вы писали:
P>>пишите ли вы Client спереди? раньше писал, но вот думаю есть же немспейс ...Client
V>Я не пишу. Да и вообще любое дублирование схлопываю:
V>
V>ns Portal.Model.Client.Validator
V>{
V> class GeneralInfo;
V> class BackHistory;
V>}
V>
а как потом используете валидаторы?
ведь может быть
ns Portal.Model.Client.Db
{
class GeneralInfo;
class BackHistory;
}
Здравствуйте, peer, Вы писали:
P>Здравствуйте, vopl, Вы писали:
P>>>пишите ли вы Client спереди? раньше писал, но вот думаю есть же немспейс ...Client
V>>Я не пишу. Да и вообще любое дублирование схлопываю:
V>>
V>>ns Portal.Model.Client.Validator
V>>{
V>> class GeneralInfo;
V>> class BackHistory;
V>>}
V>>
P>а как потом используете валидаторы?
так же как и раньше, с точностью до идентификации:
было
P>ns Portal.Model.Client.Db
P>{
P> class GeneralInfo;
P> class BackHistory;
P>}
P>
ну, если нормально подбирать иерархию пространств имен и их имена — все получается отлично. Непосредственно эту запись я бы прочитал так: "GeneralInfo и BackHistory — это базы данных клиента в модели портала"
Здравствуйте, peer, Вы писали:
P>Если у вас есть уже немспейс
P>Portal.Model.Client
P>и внутри него вы создаете классы валидаций
P>GeneralInfoValidator P>BackHistoryValidator
P>пишите ли вы Client спереди? раньше писал, но вот думаю есть же немспейс ...Client
Периодически это становится проблемой, когда две либы имеют одинаковые классы
Здравствуйте, vaa, Вы писали:
vaa>Здравствуйте, peer, Вы писали:
P>>Если у вас есть уже немспейс
P>>Portal.Model.Client
P>>и внутри него вы создаете классы валидаций
P>>GeneralInfoValidator P>>BackHistoryValidator
P>>пишите ли вы Client спереди? раньше писал, но вот думаю есть же немспейс ...Client
vaa>Периодически это становится проблемой, когда две либы имеют одинаковые классы
А это тут при чем? Приписать спереди Client или не приписывать — "одинаковость классов в разных либах" будет как то меняться от этого?
Здравствуйте, vopl, Вы писали:
V>Здравствуйте, vaa, Вы писали:
vaa>>Здравствуйте, peer, Вы писали:
P>>>Если у вас есть уже немспейс
P>>>Portal.Model.Client
P>>>и внутри него вы создаете классы валидаций
P>>>GeneralInfoValidator P>>>BackHistoryValidator
P>>>пишите ли вы Client спереди? раньше писал, но вот думаю есть же немспейс ...Client
vaa>>Периодически это становится проблемой, когда две либы имеют одинаковые классы
V>А это тут при чем? Приписать спереди Client или не приписывать — "одинаковость классов в разных либах" будет как то меняться от этого?
неоднозначность же, придется алиас создавать, чтобы разрешить конфликт имен.
Здравствуйте, vaa, Вы писали:
V>>А это тут при чем? Приписать спереди Client или не приписывать — "одинаковость классов в разных либах" будет как то меняться от этого? vaa>неоднозначность же, придется алиас создавать, чтобы разрешить конфликт имен.
это не про то, тут речь о разных неймспейсах. Их можно просто не импортировать, но тогда придется всегда прописывать полные имена с ns. Но ТС походу так и делает, так что ему не страшно.
Здравствуйте, peer, Вы писали:
P>пишите ли вы Client спереди? раньше писал, но вот думаю есть же немспейс ...Client
Я пишу.
1. импорт неймспейсов удобная вещь, чтобы не прописывать их явным образом повсеместно. Я ей обычно и пользуюсь. А с таким наименованием импорт ломается как только два похожих объекта из надо использовать совместно.
2. внешний поиск по коду, от обычного поиска по файлу до системы индексации типа Opengrok, обычно недостаточно умен, чтобы понять неймспейс объекта (потому что не компилирует, а только работает с текстом). И ClientValidator он найдет правильно, а просто Validator вывалит из всех неймспейсов. А суть же поиска чтобы быстро найти нужное, а не разбирать потом простыню результатов.
Здравствуйте, peer, Вы писали:
P>Если у вас есть уже немспейс
P>Portal.Model.Client
P>и внутри него вы создаете классы валидаций
P>GeneralInfoValidator P>BackHistoryValidator
P>пишите ли вы Client спереди? раньше писал, но вот думаю есть же немспейс ...Client
Если имя не очевидно-уникальное, то пишу. Но это в основном из-за того что в жаве нет нормальных импортов. Были бы — не писал бы. Типа import client.validator; var cv = new client.validator();
Здравствуйте, peer, Вы писали:
P>Если у вас есть уже немспейс P>Portal.Model.Client
P>и внутри него вы создаете классы валидаций P>GeneralInfoValidator P>BackHistoryValidator
P>пишите ли вы Client спереди? раньше писал, но вот думаю есть же немспейс ...Client
Ну а потом появляется пространство имён `Portal.Model.Server` со своими `GeneralInfoValidator` и `BackHistoryValidator`… и где-то, где вдруг понадобилось подключить оба этих пространства могут быть конфликты
В целом, для принятия решения надо лучше понимать, за что конкретно отвечают эти классы, как спроектировано именование в этой сборке и в этом пространстве имён (какие ещё типы есть, чем они занимаются и как называются или предполагают называться).
Лучшее (правильное?) именование может зависеть не столько от этих самих типов, сколько от совсем других сущностей или сценариев использования.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, peer, Вы писали:
P>Если у вас есть уже немспейс
P>Portal.Model.Client
P>и внутри него вы создаете классы валидаций
P>GeneralInfoValidator P>BackHistoryValidator
P>пишите ли вы Client спереди? раньше писал, но вот думаю есть же немспейс ...Client
Не пишу. Этот подход у меня распространяется на все виды классов, даже классы CSS.