Имеет пустой базовый класс, плохо разрабатывают?
Мне нужен базовый класс для моих классов DTO, которые будут использоваться в моих универсальных интерфейсах.
Но классы DTO не имеют ничего общего. Они - просто немые классы, содержащие некоторые свойства.
public void GetGridData()
{
IDataForGrid<DTOBase> aa;
if(request == 1) aa = new CustomerGridData;
if(request == 2) aa = new OrderGridData;
var coll = aa.GetList();
}
public class CustomerGridData : IDataForGrid<CustomerDTO>
{
...
}
4 ответа
Если у них нет ничего общего, что вы собираетесь делать с экземплярами, которые вы извлекаете из своего списка?
В любом случае, наличие базового класса означает, что когда (ладно, если) вы определите что-то, что должно быть у них общим позже, вам не придется возвращаться и рефакторить (перебазировать) все. Но я бы в любом случае рассмотрел возможность использования интерфейса, а не базового класса для такого рода вещей, поскольку не похоже, что есть сильная необходимость в повторном использовании базовой реализации (поскольку у них пока нет ничего общего!). Это будет зависеть от того, что, по вашему мнению, у них может оказаться общим позже.
Это неплохой дизайн, хотя и несколько необычный. Подумайте об этом так - есть по крайней мере два преимущества при отсутствии недостатков:
- Базовый класс служит фильтром для ваших интерфейсов, так что вы не можете передать им какой-либо объект - только ваши объекты DTO. Маркерные интерфейсы тоже могут это сделать.
- Когда они в конце концов получат что-то общее, это будет легко добавить, и вам не придется все реорганизовывать.
В Java это называется Интерфейс тегов . Ссылка дает хорошее представление об интерфейсах тегов, их использовании и проблемах.
В рекомендациях по кодированию .NET говорится, что наличие пустого базового класса или интерфейса (также называемого интерфейсом «тег») - действительно плохой стиль. Предпочтительный стиль - использовать атрибут вместо аннотации классов одного и того же типа. Существует также правило FxCop , обеспечивающее соблюдение этого соглашения.
Однако я иногда (в редких случаях) использую эту идиому, когда общий базовый класс полезен для обозначения общей иерархии, даже если общих функций не существует. Атрибуты для этого использовать нельзя.
Например, в интерпретаторе языка программирования несколько методов возвращают значение специального базового класса , то есть то, что имеет значение внутри этого языка программирования. По сути, это значение может быть все от числа до строки (которые являются специальными классами, а не System.Int32 или System.String ) до составного объект. Я мог бы также вернуть System.Object , но это ослабило бы типизацию моего открытого интерфейса.
Хороший самодокументированный код выигрывает от ограниченного интерфейса.