Избегать многих наследующих классов - PullRequest
2 голосов
/ 20 сентября 2010

Допустим, у меня есть этот класс (просто в качестве примера):

internal class Packet
{

    private readonly UInt32 _length;
    private readonly Byte _type;
    private readonly UInt32 _requestId;

}

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

Есть ли способ реализовать каждый тип пакета без использования наследования?

Я думал об использовании свойства, такого как List<Tuple<Type,Value>> _typesSpecificValues - я знаю, что оно не скомпилируется, но я не знаю, как еще выразить то, что я имею в виду.

Мне нужно избегать создания класса наследования для каждого типа пакета, потому что существует около 50 типов - или я просто ленивый ??

Ответы [ 4 ]

7 голосов
/ 20 сентября 2010

Похоже, вы должны создавать отдельные классы, да.

Тем не менее, я не уверен, что заставил бы их быть производными от этого класса. Похоже, это должно быть в Header классе (или, возможно, даже в структуре), и тогда у вас может быть несколько классов, каждый из которых содержит a Header.

2 голосов
/ 21 сентября 2010

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

1 голос
/ 21 сентября 2010

Если у вас так много разных типов классов с множеством различных характеристик между ними, вы не должны использовать наследование, но вместо этого вы должны использовать Composition.

Прочитайте эту статью , которая объясняет это лучшечем я мог.

РЕДАКТИРОВАТЬ

Прочитайте еще лучше главу о шаблоне декоратора из превосходной книги Head First: Design Patterns

Чтобы привлечь ваше внимание к этой книге, здесь есть несколько скриншотов:

Наследование Inheritance

Композиция Composition

1 голос
/ 21 сентября 2010

Вы должны спросить себя: имеет ли смысл использовать сам пакет? . Будете ли вы получать доступ к свойствам базового класса во всех / большинстве случаев использования?

Например, допустим, у вас есть:

public class CommPacket : Packet
{
    public string Message { get; set; }
}

Типично ли получить доступ к CommPacket.Length? Или когда-нибудь имеет смысл передать CommPacket какому-то классу, который принимает пакет в качестве параметра? Если ответом на один из них является «Да», вы должны использовать базовый класс.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...