2013-12-09 3 views
0

Я начинаю программировать на языке программирования. У меня есть запрос относительно абстрактного класса.Использование не абстрактного метода и конструктора в абстрактном классе

Аннотация не может быть создан экземпляр класса, а затем использовать неабстрактный метод и конструктор в абстрактном классе .....?

пожалуйста, помогите ....

ответ

2

Это будет иметь смысл только тогда, когда существуют производные классы.

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

Посмотрите на этот пример:

abstract class Fruit 
{ 
    private Logger log; 

    // init private stuff 
    public Fruit() 
    { 
     this.log = new Logger("C:\\Temp"); 
    } 

    // do common functionality 
    public int CalculatePrice(double weight) 
    { 
     return weight * GetPricePerKilo(); 
    } 

    // specific stuff must be implemented by derived classes 
    public abstract double GetPricePerKilo(); 
} 

class Apple : Fruit 
{ 
    // must implement in non-abstract derived class 
    public override double GetPricePerKilo() 
    { 
     return 4.30; 
    } 
} 
+0

Спасибо вам обоим ...... так что основное отличие - это «абстрактное» ключевое слово позволяет мне определить все или некоторые свойства этого абстрактного класса в разных производных классах в соответствии с требованием производного класса, а также его предоставляет некоторые уже определенные свойства (метод в этом случае), которые могут использоваться, когда я создаю объект производного класса. я прав, сэр? – Anadi

+0

@ user2897975 Если некоторые методы или свойства являются абстрактными, весь класс должен быть абстрактным, поскольку он не может использоваться, если реализация, например, метод отсутствует. И да, в основном вы правы, но 1) Не путайте свойства и методы и 2) Все это входит в игру во время компиляции, когда определяется производный класс, а не объект этого производного класса. – helb

1

Абстрактные классы есть в абстрактном определенное поведение, а также принуждение, что вы добавить по крайней мере какое-то поведение, чтобы сделать это реальный объект. Подумайте об этом как о дорожных транспортных средствах. Вы можете иметь абстрактный класс RoadVehicle, который содержит не абстрактную функцию Drive. Если вы затем наследуете абстрактную функцию, скажем, конкретный класс Car, у нас уже будет доступ к поведению Drive.

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

0

Абстрактные классы являются наиболее полезными в ситуациях, когда некоторые члены будут иметь поведение, которое каждая реализация будет обрабатывать самостоятельно. Рассмотрим, например, ReadableDoubleMatrix класс, с тремя свойствами:

int Rows {get;}; 
int Columns {get;} 
double this[int row, int column] {get;} 

Простейшая реализация общего назначения может быть класс ImmutableArrayBackedMatrix который содержит double[,], которая заполняется при строится класс, но и другие варианты реализации будут включать IdentityMatrix, который содержит значение size [Rows и Columns оба возвращаются size, а this[row, column] вернет row==column ? 1.0 : 0.0]. Поскольку эти производные классы не имеют общих полей, было бы бессмысленно включать базовый класс. Однако без каких-либо полей нет ничего значимого, чтобы экземпляр базового класса мог работать с этими свойствами.

Обратите внимание, что даже если хотя бы можно было это сделать. имеют базовый класс, реализующий Rows и Columns, чтобы вернуть 1 и this, чтобы вернуть 0.0, а код может в некоторых случаях найти такой объект полезным, не было бы никаких причин, по которым код должен иметь несколько экземпляров такого элемента. Даже если код часто нуждался в такой матрице и хотел, чтобы он был другого типа из всех других матриц, обычно было бы лучше использовать для этой цели герметичный тип.

Смежные вопросы