copal

Сделай из него девочку 6 лет, а затем долго и упорно заставляй решать Дональда Кнута. Работает, я так уже 5 раз делал.

Оставьте дедушку в покое...

var f = function() {}; — function expression
function f() {}; — function declaration

Основная разница в том, что второе поднимает определение функции до начала области видимости, в которой она объявлена. То есть можно использовать функцию до ее объявления.

hoisted(); // выведет 'foo'

function hoisted() {
  console.log('foo');
}

notHoisted(); // TypeError: notHoisted is not a function

var notHoisted = function() {
   console.log('bar');
};

upd:
Другое отличие состоит в возможности моментального вызова функции, так называемое iife

var expression = function() { console.log('foo'); }();
// выведет 'foo'

function declaration() { console.log('bar'); }();
// SyntaxError: expected expression, got ')'

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

Поищите по тостеру, такие темы уже поднимались.

Не имеет значения, на каком языке сравнивать агрегацию и композицию. Две концепции являются отношением has-a, то есть технически реализуются одинаково: например, класс или отдельный экземпляр класса (если у прототипа объекта нет такого свойства) ссылаются с помощью полей на экземпляры другого класса (хотя и не обязательно другого). Отличие состоит в том, что в случае композиции один класс сильнее зависит от другого явно заданного класса и, по большому счёту, не может без него существовать.

Вот пара ссылок:

* sergeyteplyakov.blogspot.com/2012/12/vs-vs.html
* programmers.stackexchange.com/questions/61376/aggr...

Также обратите внимание на то, что в случае композиции, класс/объект сам определяет связи и время жизни этих связей -- то есть, полностью владеет им.

Вот интересно... Я разрабатываю язык со встроенной поддержкой SOLID (в расширенном толковании), попробую ответить на ваш вопрос.

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

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

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

Данный ответ основывается на результатах оригинального исследования. :-)

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

class SomeClass 
        {
         public SomeClass parent;
         public SomeClass child;
  
          void execute{

          }
          
          void insert(SomeClass target)
          {
            this.child = target;
            target.parent = this;
          }
        }

не понял что за язык у вас в примере, пример привел в C#

Не нарушает, так как не является составляющей, которая определяет "правила" ООП. Под множественным наследованием, привносящим проблемы, скорее следует понимать наследование классов, то есть, готового поведения и состояния. С наследованием интерфейсов проблемы как таковой на уровне реализации интерфейсов нет, но может в некоторых случаях быть неприятной в JVM-языках, когда реализуемые интерфейсы декларируют методы с одинаковыми именами, но методы семантически разные. Это чисто техническая проблема. В то же время, в среде .NET, насколько я помню, этой проблемы нет. Класс, реализующий несколько интерфейсов -- вполне обычная и хорошо зарекомендовавшая себя практика (например, стандартная библиотека виджетов GWT; "наблюдаемые" коллекции в .NET и пр.)

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

Просто надо понимать, где стоит использовать множественное наследование в том или ином его варианте, где оно излишне, а где вообще не нужны объекты и классы.

В вашем случае больше подойдёт агрегация. И, в качестве совета: всегда старайтесь рассматривать агрегацию как альтернативу множественного наследования. Почитайте что-нибудь хорошее по ООП (найдите в сети, есть 100500 ответов на вопрос "что почитать по теме ...").

А каноны ООП -- это нечно мифическое. Есть базовый набор принципов и рекомендаций, а остальное -- опыт и знания. Никогда не будет так как в школе: вот это отлично и так надо делать, а вот это плохо и так делать не надо.

Если очень коротко:
Интерфейс следуют рассматривать как описание набора похожих по смыслу действий, которые можно произвести с экземпляром класса. Например мы можем постучать по всему, реализует интерфейс IKnockable, и в контексте использования данного интерфейса нам не важны остальные характеристики объекта. Постучать, допустим можно по дереву, а можно и по голове.
Понятие наследование от базового класса включает в себя наследование описательных и поведенческих характеристик. Допустим есть класс виджетов, которые умеют себя рисовать, реагировать на команды и прочее. Пусть от виджета наследуется класс MainWindow или класс Dialog. Эти классы умеют себя рисовать как и виджет, имеют свойства прозрачности (допустим) и прочие, однако содержат что-то новое элементы управления по умолчанию, предопределённые свойства модальности иное поведение и пр.
Конечно неплохо было бы учесть некоторые принципы SOLID, но вопрос не про это...

И вот теперь я хочу получить класс реализующий поведение и Task и Node. Это нормально?

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

Читаем про SOLID, в частности Принцип подстановки Барбары Лисков. Так же принцип единой ответственности, слабая связанность (low coupling) и высокое зацепление (high cohesion). По поводу реализации нескольких интерфейсов - скажем для композиции двух классов все будет ок, так как вы при этом мы не сломаем принцип единой ответственности, каждый компонент будет отвечать за свое и все будут счастливы. А класс который будет объеденять две реализаци интерфейсов будет просто проксировать вызовы в нужным инстансам.

Множественное наследование норм... только высок риск что все это дело благодаря оному будет нарушено.

Нашёл таки инфу, неправильно искал. Если кратко, то в about:crashes можно посмотреть отправленные отчёты.
https://helpx.adobe.com/flash-player/kb/report-fla...

Наверное, здесь opengameart.org можно что-то найти

community это professional