Достижение множественного наследования через интерфейс - PullRequest
2 голосов
/ 18 июля 2011

Я новичок в концепции интерфейса.

при поиске информации о «Достижении множественного наследования через интерфейс» я наткнулся на эту ссылку. Многократное наследование

У меня такое же сомнение, как и в программеимел.

привет, хорошее объяснение, очень полезное На диаграмме uml для java нет связи с Animal от Bird и horse почему?Необходимо ли использовать тот же метод в производном классе и почему

void birdNoise(); 
void horseNoise(); 

, почему в классе Peagus

public void horseNoise()
{
    System.out.println("Horse Noise!");
}

public void birdNoise()
{ 
    System.out.println("Bird Noise!");
} 

почему это должно быть там?Почему «Помните, мы должны написать собственную реализацию каждого класса для каждого метода в интерфейсе. Причина? Спасибо за это хорошее объяснение. Спасибо

В этом посте они использовали множественное наследование в c ++ и преобразовали в интерфейсы в java.

1. Что я думал о наследовании, так это о наличии некоторых методов в родительском классе, и всякий раз, когда те же самые методы необходимы и в других классах, эти классы наследуют родительский класс и используютно в концепции интерфейса, если каждый производный класс (ы) должен определять свою собственную реализацию, тогда какая польза от ее наследования?

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

Кто-то, пожалуйста, объясните.

Заранее спасибо.

Ответы [ 4 ]

2 голосов
/ 18 июля 2011

Когда я перешел с c ++ на java, у меня появилось то же чувство, но теперь, когда я некоторое время работал с java, все это имеет смысл.

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

Как и в случае с оригинальным автором, вы все равно можете выполнять множественное наследование в Java, просто используя интерфейсы.Интерфейсы похожи на чистые виртуальные классы в c ++.

Но в концепции интерфейса, если каждый производный класс (ы) должен определять свою собственную реализацию, тогда какая польза от его наследования?

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

Дизайн Java немного отличается от дизайна c ++, но после выполнения нескольких Java-программ вы станететак же хорошо в использовании нескольких интерфейсов, как и в использовании множественного наследования.

1 голос
/ 18 июля 2011

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

public interface animal {
    //All implementers must define this method
    void speak();
}

В этом интерфейсе говорится, что любое животное ДОЛЖНО иметь возможность говорить. В принципе, любой тип животного будет способен шуметь. Затем у нас есть 2 подкласса или 2 разных типа животных, которые мы создаем.

public class Dog implements animal {
    //Define how a Dog speaks
    public void speak() {
        System.out.println( "woof" );
    }
}

Затем мы определяем другое животное, кошка

public class Cat implements animal {
    //Define how a Cat speaks
    public void speak() {
        System.out.println( "meow" );
    }
}

В этом примере и Кот, и Собака - животные, и поэтому должны иметь возможность говорить благодаря нашему интерфейсу. Однако все знают, что кошки и собаки издают разные звуки. Позволяя каждому подклассу определять, как он «говорит», мы можем дать Собакам и Кошкам их собственный соответствующий звук при вызове метода speak (), при этом они оба являются животными.

В ответ на ваш вопрос более конкретно, наследование заставляет его подклассы иметь определенный метод. Другими словами, интерфейс утверждает, что «все мои подклассы будут определять каждый из этих методов». Это позволяет нам писать код, который имеет дело с методами интерфейса, не зная конкретного подкласса. Мы можем сделать это безопасно, потому что знаем, что каждый подкласс ДОЛЖЕН определить метод в классе интерфейса. Если бы только подклассы, которые используют метод, определяли его, то у нас не было бы способа узнать наверняка, безопасно ли вызывать метод на всех подклассах.

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

public class MuteAnimal implements animal {
    //A MuteAnimal can't speak!
    public void speak() { }
}
0 голосов
/ 19 июля 2011

Если класс A наследуется от класса B, это фактически означает две вещи:

  1. Класс A может неявно использовать все методы и свойства класса B и должен определять только ту функциональность, которая фактически уникальна для класса A.
  2. Код, который ожидает, что объект типа B примет объект типа A.

Эти две особенности наследования в некотором смысле ортогональны; Можно представить себе места, где один может быть полезен без другого. Хотя производные классы могут иметь только один родительский класс, из которого они получают неявный доступ к методам и свойствам, они могут определять произвольное количество интерфейсов, для которых они могут быть заменяемыми.

Обратите внимание, что, хотя некоторые люди настаивают на том, что интерфейсы образуют отношения "имеет-а", а не "есть-есть", я думаю, что лучше думать о них, как о том, что они говорят что-то "это __able" или "это __er", Дело в том, что интерфейсы не просто определяют способности, но определяют заменяемость (то есть «является») в терминах способностей.

0 голосов
/ 18 июля 2011

Наследование часто бесполезно без полиморфизма.Это действительно нелегко объяснить всего лишь несколькими предложениями.Я бы посоветовал взглянуть на интерфейсы для определения поведения (что-то вроде can-do отношения) и конкретного наследования для is-a отношений.

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

Если вы берете свой пример, даже Пегас не является одновременно лошадью и птицей на 100%процентов.Он унаследует лошадь, но реализует специфические характеристики птиц, которые будут определены в интерфейсах, таких как Flyable, например.Вы можете сказать, что у птиц есть один общий для них способ полета, поэтому унаследуйте их от Птицы.Pegasus немного отличается, так что пользовательская логика может быть определена после реализации интерфейса Flyable с помощью метода Fly.Кроме того, пример с horseNoise и birdNoise немного нереалистичен, вам нужен один метод speak (), который из-за внутреннего алгоритма класса выполняет определенное действие.Что если этот пегас может говорить?У вас был бы метод для каждого слова?

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

foreach(Flyable flyableAnimal in animals)
    flyableAnimal.Fly();

Вы просто полагаетесь на полиморфизм ...

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

...