Наследуйтесь классу или абстрактному классу

Если базовый класс нельзя инстанцировать, тогда делают это абстрактным классом - если базовый класс нужно инстанцировать, тогда не делают это кратким обзором.

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

abstract class WritingImplement
{
    public abstract void Write();
}

class Pencil : WritingImplement
{
    public override void Write() { }
}

Однако в этом следующем примере Вы видите, как базовый класс действительно имеет конкретное значение:

class Dog
{
    public virtual void Bark() { }
}

class GoldenRetriever : Dog
{
    public override void Bark() { }
}

Это все довольно субъективно действительно - необходимо быть в состоянии сделать довольно хороший личный выбор на основе потребностей конкретного домена.

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

Думайте об этом, другой путь

Является моим базовый класс полный объект на своем собственном?

, Если ответ не, то сделайте его кратким обзором. Если это - да тогда, Вы, вероятно, хотите сделать это реальным классом.

Абстрактные классы для частично реализованных классов.

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

мне нравится думать об абстрактных классах как об интерфейсах, которые имеют некоторых участников, предопределенных, так как они характерны для всех подклассов.

Я предлагаю:

• Делают интерфейс.
• Реализация интерфейс в Вашем базовом классе.
• Делают базовый класс реальным классом, не абстрактным (см. ниже для почему).

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

Да этого часто не происходит, но точка: создание краткого обзора базового класса предотвращает этот вид повторного использования/решения, когда нет никакой причины сделать так.

Теперь, при инстанцировании базового класса так или иначе было бы опасно, затем сделать это абстрактным - или предпочтительно сделать это менее опасным, если возможный;-)

Зависеть от того, хотите ли Вы, чтобы базовый класс был реализован самостоятельно или нет.

Как абстрактный класс, Вы не можете сделать объекты из него.

Я сказал бы, не являетесь ли Вы планированием вызова базового класса отдельно, тогдашний необходимо определить его как абстрактный класс.

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

abstract class ADataAccess
{
    abstract public void Save();
}

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

public class DataAccess
{
    public void Save()
    {
        if ( _is_new )
        {
            Insert();
        }
        else if ( _is_modified )
        {
            Update();
        }
    }
}

кроме того, Вы могли использовать интерфейсы (индивидуально или на классах, или кратком обзоре или не) для определения того же вида опытного определения.

interface ISaveable
{
    void Save();
    void Insert();
    void Update();
}

class UserAccount : ISavable
{
    void ISavable.Save() { ... }
    void ISavable.Insert() { ... }
    void ISavable.Update() { ... }
}

еще одна опция может использовать дженерики

class GenDataAccess<T>
{
    public void Save()
    {
        ...
    }
}

, Все эти методы могут использоваться для определения определенного прототипа для классов для работы с. Способы удостовериться, что код A может говорить для кодирования B. И конечно можно смешать и соответствовать всему вышеупомянутому к симпатии. Нет никакого определенного правильного пути, но мне нравится определять интерфейсы и абстрактные классы, затем обращаясь к интерфейсам. Тот путь устраняет некоторые требования мысли для "инфраструктуры" в высокоуровневых классах при хранении максимальной гибкости. (имеющие интерфейсы устраняют требование использования абстрактного базового класса, но оставляют его как опцию).

Нет. Твое понимание не совсем правильно.

Следующим узлом, который необходимо посетить в случае единообразного поиска затрат, будет D, так как он имеет наименьшую общую стоимость от корня (7, в отличие от 40 + 5 = 45).

Жадный поиск не возвращается к дереву - он выбирает наименьшее значение и фиксирует его. Единые затраты (Uniform Cost) - выбираются самые низкие общие затраты из всего дерева.

При единообразном поиске затрат всегда учитываются все неиспользованные узлы, которые вы видели до сих пор, а не только те, которые подключены к рассматриваемому узлу. Итак, в вашем примере, после выбора C, вы обнаружите, что посещение G имеет общую стоимость 40 + 5 = 45, которая выше, чем стоимость начала с корня и посещения D, которая стоит 7. Значит, вы навещаете Д следующим.

Подумайте об этом как о банковском счете:

Можно создать общий абстрактный базовый счет под названием «Счет», в котором содержится основная информация, например, сведения о клиенте.

Затем можно создать два производных класса, называемых «SavingAccount» или «DebitAccount», которые могут иметь свое собственное поведение, одновременно извлекая выгоду из поведения базового класса.

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

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