Общие свойства и методы, назначенные различным типам подкласса - PullRequest
0 голосов
/ 23 марта 2009

Я работаю над созданием собственных базовых классов пользовательского интерфейса. На них я хочу, чтобы у них были одинаковые «общие» свойства и методы. Я мог бы определить класс интерфейса, но интерфейс, по-видимому, допускает только абстрактные методы и никаких свойств.

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

Предложения ???

Ответы [ 6 ]

1 голос
/ 23 марта 2009

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

0 голосов
/ 23 марта 2009

Я сам из C ++ - фона, где множественное наследование разрешено и широко используется, поэтому я часто сталкиваюсь с теми же проблемами, что и вы. Первое, что вам нужно сделать, это прочитать о дополнениях - здесь вы заметите, что вы использовали их все время, даже не называя их. Второй шаг - начать распознавать ваши миксины всякий раз, когда они вам нужны, и вы часто узнаете, что с таким же успехом можете использовать их через композицию. Третий шаг - реализовать их, используя композицию ... Да, я тоже ненавижу это, но нет никакого способа обойти это, если вы хотите перейти на .NET (или Java или ...):)

То, для чего вы должны использовать наследование, - не для ваших миксинов, а для вещей, которые фактически идентифицируют ваши предметы. Я рекомендую взглянуть на иерархию .NET для некоторых общих элементов управления (текстовое поле и тому подобное), чтобы получить вдохновение.

Удачи

0 голосов
/ 23 марта 2009

.Net не допускает множественное наследование, но вы можете использовать «иерархию наследования» для организации ваших базовых классов. Так выложен сам .Net.

0 голосов
/ 23 марта 2009

Определенно можно указать свойство в интерфейсе

interface IFoo {
  string Name { get; set; } 
  string Age { get; } // Read Only
}

Но в остальном вы правы. Интерфейсы не определяют поведение и, следовательно, могут определять только «абстрактные» методы и свойства. Реализация должна быть сделана на каждом разработчике. Это цена, которую платят за гибкость в интерфейсах.

Если поведение действительно идентично для всех дочерних классов, тогда я обычно выбираю абстрактный класс. Или часто сочетание. А именно, определить интерфейс и базовую реализацию, которая реализует этот интерфейс.

class Foo : IFoo { 
  private string _name;
  public Name { get { return _name; } set { _name = value; } }
  public Age { get { return 42; } }
}

Это дает вам гибкость быстрой реализации с выбором интерфейса usincg для классов, которые по некоторым причинам не могут быть получены из Foo.

0 голосов
/ 23 марта 2009

Вы можете объявить свойство в интерфейсе, как показано ниже:

public interface IMyInterface
{
   string Name { get; set; }
   int Age { get; set; }
}

Однако в этой ситуации это звучит так, как будто абстрактный класс будет лучше.

0 голосов
/ 23 марта 2009

Вы можете определить свойства на интерфейсах: свойства интерфейса

public interface ISampleInterface
{
    // Property declaration:
    string Name
    {
        get;
        set;
    }
}
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...