AS3 переопределить addChild (), тест для типа

Question

это работает для меня, но выглядит ли это правильно с точки зрения лучших практик as3.правильно ли возвращать нуль в случае сбоя?

        override public function addChild(child:DisplayObject):DisplayObject {
        if(child is Screen) {
            super.addChild(child);
            return child;
        }

        return null;
    }

Answer 1

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

if (!addChild(child))
{
   //couldn't be added
}

вместо

if (child is Screen)
{
    addChild(child);
}
else
{
    // couldn't be added
}

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

Я не думаю, что это лучший вопрос для практики, если он работает для вас.

Answer 2

Нет хорошего способа сделать то, что ты хочешь.Если вы хотите желаемого поведения, вы должны использовать композицию вместо наследования.То, что вы пытаетесь сделать, - это нарушение принципа замены Лискова .

Answer 3

Я вижу несколько вариантов, и ни один из них не кажется полностью "правильным".

Лучшее, на мой взгляд, решение невозможно в Actionscript (я думаю, что это разрешено на других языках).То есть, объявите, что вы будете принимать только экземпляры Screen:

override public function addChild(child:Screen):Screen {
    return super.addChild(child);
}

Так как это невозможно, другие варианты, о которых я могу подумать, будут:

1) Выдача ошибки.

Я, как правило, не очень люблю выбрасывать ошибки, но профессионал здесь в том, что он соответствует поведению расширенного класса.Если вы передадите недопустимый экранный объект в addChild, он выдаст.С другой стороны, это допустимо, учитывая, что подпись метода говорит вам, что вы должны передать DisplayObject.В этом случае ваш метод в некотором смысле «лжет», потому что он говорит, что принимает DisplayObjects, но на самом деле он принимает только экземпляры Screen.Таким образом, вы полагаетесь на документацию (надеюсь), а не на систему типов, чтобы сообщить пользовательскому коду, как он должен использовать вашу функцию.

2) Добавление метода addScreen, который вызывает addChild.

public function addScreen(child:Screen):Screen {
    return super.addChild(child) as Screen;
}

Это несколько более безопасно, но вы теряете некоторые преимущества полиморфизма (и, возможно, это не возможно / невозможно в вашем коде).Может быть, если бы у нас была перегрузка метода ... но у нас нет, опять же, я думаю, это компромисс.

3) Проверка типа во время выполнения и возврат нуля при ошибке.

Вот чтотвой код делает.Это может быть просто отлично.Что мне не нравится в этом, так это то, что я упомянул выше: ваш метод - это своего рода «ложь».Я не ожидаю, что метод, который принимает DisplayObject, потерпит неудачу, потому что я передал DisplayObject.Но иногда это не имеет большого значения.

Боюсь, я не могу дать однозначного ответа на этот вопрос.Если возможно, я думаю, что я бы, вероятно, пошел с вариантом 2), но все эти варианты кажутся одинаково действительными.В какой-то момент вы должны согласиться на тот, который имеет больше смысла для вас и вашего проекта, я думаю.