Что я должен делать, когда имя класса очень распространено? - PullRequest
3 голосов
/ 24 мая 2009

Я только что добавил еще один сторонний компонент в свой проект .net, который содержит класс с именем Client, и это заставило меня задуматься об общих именах классов.

Вы называете ваши публичные классы чем-то общим, как Client, или вы пытаетесь сделать имя более конкретным?

В прошлом я бы сказал, что Client - это нормально, поскольку к нему всегда можно получить явный доступ через пространство имен (Company.Product.Client), но MS, похоже, придерживается более описательных имен классов в .net framework, таких как WebClient, TcpClient и SmtpClient.

Я думаю, что имена вроде MessagePub.Client выглядят довольно аккуратно, а MessagePub.MessagePubClient гораздо меньше, но тогда, когда много плавающих Client также кажется довольно грязным.

Все эти сторонние компоненты, которые я использую, на самом деле имеют открытый исходный код, поэтому рекомендуется ли реорганизовать и изменить их имена классов на что-то более наглядное, чтобы сделать мой код более читабельным, или лучше использовать доступ через их пространство имен? Или это просто не имеет значения? : -)

Ответы [ 8 ]

5 голосов
/ 24 мая 2009

Не забывайте о кванторе псевдонимов пространства имен , когда вам приходится иметь дело со сторонними библиотеками, использующими похожие / идентичные имена:

using Excel = Microsoft.Office.Interop.Excel;
using Word = Microsoft.Office.Interop.Word;

Таким образом, вы можете легко различать различные классы:

Excel.Application excelApp = new Excel.Application();
Word.Application wordApp = new Word.Application();
5 голосов
/ 24 мая 2009

Я думаю, что более описательное имя почти всегда лучше. Это не просто техническая проблема, но, конечно, и семантическая: во-первых, она обязывает вас подумать, с каким классом вы имеете дело, и помогает вам установить границы.

3 голосов
/ 24 мая 2009

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

Если для вас возможно иметь более одного вида, скажем, MessagePub.Client, например, тот, который требует только дайджесты сообщений, или тот, который является адаптером сообщений для какого-то другого интерфейса, тогда, конечно, вам необходимо уточнить тот. Возможно MessagePub.DefaultClient для общего случая, MessagePub.DigestClient для потребителя дайджеста или MessagePub.LogAdaptorClient для адаптера сообщений

1 голос
/ 24 мая 2009

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

using Company.Product;
using SomeOtherThing.Product;

... и если Client появляется в обоих пространствах имен, у вас есть нечитаемый код.

Распространенные имена объектов, такие как Client, Product, User, Person, Message и т. Д. ... Я бы почти всегда использовал префикс с некоторым идентификатором, который отражает их большую цель.

0 голосов
/ 02 февраля 2011

Клиент - это плохое имя, чем конкретно он является? Я бы сказал, что такое соединение, как MailClient, MicrowaveClient, TelephoneClient и т. Д.

0 голосов
/ 24 мая 2009

"Google твой друг". Если имя класса, о котором вы думаете, имеет 361 миллион просмотров, вы можете ожидать проблем. Кроме того, вы можете обнаружить, что ваш класс уже реализован.

0 голосов
/ 24 мая 2009

Вы называете ваши публичные классы чем-то таким же общим, как Client, или вы пытаетесь сделать имя более конкретным?

Я пытаюсь сделать две вещи:

  1. Нет двух из моих классов с одинаковыми именами (но мне все равно, совпадают ли какие-либо имена моих классов с именами третьих сторон: для этого предназначены пространства имен).

  2. Мои классы почти никогда не имеют того же имени, что и любой из классов системы Microsoft (например, я бы не создал класс с именем Dictionary или Form)

0 голосов
/ 24 мая 2009

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

Конечно, пространства имен - это отличный способ выделить имена и добавить объяснительную силу в ваш код. Однако я бы не стал рефакторировать что-либо, только чтобы присвоить другое имя.

...