Как придумать более четкие имена интерфейсов?
Я видел в приложении, где у него были такие интерфейсы, как:
IHasContent
IHasValue
IHasMesh
IHasGeometry
IHasTransformation
Должны ли они быть?:
IHaveContent
IHaveValue
...
Или:
IIncludeContent
IIncludeValue
...
Лично я склоняюсь к их созданию:
IContent
IValue
IMesh
IGeometry
ITransform
Потому что не ISomething
уже подразумевает, что он имеет something
?
Что касается последнего, должен ли я сделать его ITransformable
?
Я думаю, что использование I + (Has/Have/Include/Exist, etc) + Name
делает имена интерфейсов более запутанными.
Любые идеи о том, как придумать лучшие имена интерфейсов, которые не кажутся неудобными, - это точка и получает значение через?
Ответы
Ответ 1
Некоторые из этих имен (Контент, Значение и т.д.) являются неопределенными и мало что описывают содержание/поведение элемента. В общем, имена должны быть как можно более конкретными и отчетливыми - IScriptParameter может быть более описательным, чем IValue. По мере роста вашего проекта, имея более описательные имена, ваши типы будут намного легче различать (если вы не будете осторожны, вы можете получить IValue и INumber и IAmount для обработки вариаций "значений"!)
Если ваш интерфейс (например, IMesh) означает "предоставляет свойства сетки", то IMesh - это прекрасное имя - он описывает тот факт, что вы можете обрабатывать объект так, как если бы это был Mesh.
Если ваш интерфейс используется для применения действия (например, для рендеринга объекта в виде сетки или для применения преобразования к объекту), подумайте об использовании глагола/прилагательного, а не о существительном именовании (например, IRenderable, ITransformable) - это общий шаблон в .net(например, IEnumerable (глагол/прилагательное), а не ICollection (существительное))
Для меня "IHasMesh" звучит скорее как IMeshContainer - т.е. это объект, который содержит сетку, и интерфейс позволяет мне "получить сетку". Таким образом, это не позволило бы мне действовать или запрашивать данные в пределах сетки, а просто извлекать весь объект Mesh через интерфейс.
Поэтому я бы использовал:
- ITransformable, если объект можно преобразовать через интерфейс
- ITransform, если объект можно использовать напрямую, как если бы это преобразование
- IHasTransform/ITransformContainer/ITransformProvider, если объект является контейнером , который может быть запрошен для извлечения объекта Transform
Ответ 2
Лично мне нравится IHas + Word, потому что имя интерфейса описывает свойство классов, которые их реализуют.
Например:
public class Lolcat : IHasCheezburger
Когда я прочитал, что я легко понимаю, что у lolcats есть чизбургеры в них.
С другой стороны,
public class Lolcat : ICheezburger
Заставляет меня задаться вопросом, являются ли lolcats HAVE чизбургеры или ARE чизбургеры (который является традиционным глаголом, используемым при интерпретации наследования).
Ответ 3
Первое, что вам нужно понять, это то, что "я" в первых именах не относится к местоимению "я", а скорее следует стандарту именования, интерфейс которого начинается с заглавной буквы "I.".
В этом смысле интерфейсы на самом деле называются "HasContent", "HasValue" и т.д., поэтому не изменяйте его на "HaveContent" и "HaveValue", поскольку это было бы так же неудобно.
С учетом сказанного я не могу точно понять, для чего используются эти интерфейсы. Интерфейс (по определению) предназначен для принудительного условия для всех классов, которые его реализуют, и я не уверен, что эти интерфейсы обеспечивают соблюдение - все классы имеют функцию с именем HasContent()
?
Я думаю, что вам следует сосредоточиться на интерфейсах, имеющих отношения is a
. Когда вы объявляете класс, реализующий интерфейс IList
, вы не подразумеваете, что ваш класс имеет список, а скорее ваш класс является списком.
Так, например, один из них IHasGeometry
... ну, это дает мне возможность проверить, имеет ли он геометрию, но я бы реально хотел иметь дело с цифрами, которые являются геометрическими фигурами, поэтому я бы создал интерфейс с именем IGeometricFigure
вместо этого, тем самым ограничивая его использование чем-либо, что работает с геометрическими фигурами.
Я согласен с тем, что имена звучат неудобно, но я думаю, что это связано с тем, что эти интерфейсы используются для неловкой цели, а не потому, что они ненадлежащим образом названы.
Ответ 4
Ваш первоначальный список имен интерфейсов звучит правильно. Имя интерфейса должно описывать контракт. Например, это один интерфейс, с которым я столкнулся недавно, что мне очень понравилось:
public interface IDeterminesEmptyValue
{
bool IsEmpty { get; }
}
Perfect! Имя говорит само за себя. "Я" ссылается на то, что это интерфейс, а остальное описывает, что будет выполнять контракт.
Если интерфейс был вызван IEmptyValue
, это означало бы, что интерфейс гарантирует, что разработчик является пустым значением. Это не так - у него есть возможность определить, пусто ли значение.
(Вероятно) никакой класс не будет называться DeterminesEmptyValue
. Но может быть тысяча классов, каждая из которых имеет возможность определить, являются ли разные типы значений пустыми, и этот интерфейс позволяет всем их вызывать в общем виде.
Интерфейс должен четко описывать конкретную характеристику классов, которые его реализуют. В случае IContent
- реализуют ли разработчики контент HAVE или контент-исполнители ARE?
Ответ 5
Мне нравится думать, что ISomething
означает, что это что-то, как в роли чего-то, а не в том, что оно имеет или включает в себя "Что-то". Итак, IFather
означает "я играю роль отца", или я отец ". IDispatcher
означает" Я играю роль диспетчера "или" Я - диспетчер" и т.д.
Некоторым людям нравится называть интерфейсы для ответа на вопрос "что мне делать?": IListenForEvents
, ILogExceptions
. Как в этом сообщении
Ответ 6
Интерфейсы используются для многих целей, с различными соглашениями об именах. Прежде чем беспокоиться о именах, вероятно, хорошо сначала решить, как отделить функциональность. В коллекциях Microsoft, к сожалению, слишком мало различных интерфейсов, самые большие ошибки - IReadableList и IAppendable, оба из которых могут быть унаследованы IList, но поддерживают поддержку контравариантности и ковариации [чтобы можно было пройти IList (от Cat) до кода, ожидающего IReadableList (Animal ) или IAppendable (Of SiameseCat)]. С другой стороны, это также возможно разделить вещи слишком мелко, поэтому любой полезный класс должен реализовывать десятки интерфейсов.
Не зная, какие типы функций были использованы в приложении и интерфейсах, трудно определить, были ли они разработаны с хорошим уровнем детализации. Похоже, они слишком мелко разделены, но я не могу сказать. После того, как функциональность сгруппирована соответствующим образом, тогда имеет смысл беспокоиться о названии.
Ответ 7
"Я" не поддерживает "меня". Это просто означает интерфейс.
Но у Microsoft есть свои собственные рекомендации для именования интерфейсов.
Имена должны отличаться только префикс я в имени интерфейса.