Actionscript 3.0, почему отсутствуют хорошие элементы ООП?

Question

Любой, кто программировал с помощью ActionScript 3.0, наверняка заметил отсутствие поддержки частных конструкторов и абстрактных классов. Есть способы обойти эти недостатки, например, выбрасывать ошибки из методов, которые должны быть абстрактными, но эти обходные пути раздражают и не очень элегантны. (Выдача ошибки из метода, который должен быть абстрактным, является проверкой во время выполнения, а не во время компиляции, что может привести к большому разочарованию).

Я знаю, что actionscript 3.0 следует текущему стандарту ECMAscript, и в этом причина отсутствия у него частных конструкторов, но как насчет абстрактных классов, не так ли они в стандарте ECMAscript?

Я предполагаю, что более конкретный вопрос - почему стандарт ECMAscript не поддерживает частные конструкторы? Это то, чего можно ожидать в будущем?

Мне было интересно, что когда-нибудь я бросил, любое понимание будет высоко оценено.

Answer 1

частные конструкторы и абстрактные классы не являются "хорошими элементами ООП". это хорошие хаки, зародившиеся в C ++. в более динамичных языках они обычно не нужны.

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

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

Answer 2

Ни частные конструкторы, ни абстрактные классы не были определены в старом стандарте ECMAScript 4, на котором основан ActionScript 3. Если я правильно помню, рабочая группа ECMAScript решила не реализовывать эти более сложные функции ООП, поскольку особое внимание уделялось простоте и обратной совместимости со старыми версиями ECMAScript. Я интерпретировал то, что услышал от них, как «мы можем добавить эти функции позже, но давайте это сделаем медленно». Например, абстрактное ключевое слово является зарезервированным словом, так что имейте это в виду.

Стоит отметить, что рабочая группа решила перезапустить следующую версию языка с новым акцентом. Это усилие называется «Гармония», потому что две конкурирующие подгруппы имели очень разные мнения о том, куда ECMAScript должен пойти в будущем. Это немного компромисс. Гармония будет развиваться гораздо медленнее, чем старая ES4, и даже синтаксис класса, который уже был реализован в AS3, будет изначально исключен из стандарта. Другими словами, они будут на некоторое время выглядеть более похожими на сегодняшний JavaScript, чтобы сосредоточиться на некоторых других функциях, важных для группы, которая собиралась перейти. Это станет ES3.1. Позже классы и некоторые из более похожих на Java функций ООП будут пересмотрены для нового ES4.

А как же AS3? По сути, Adobe прыгнула за руль, используя стандарт, который еще не был готов, и они стали немного политиками. Однако Adobe намерена продолжать участвовать в рабочей группе ECMAScript , и они, вероятно, рассмотрят вопрос о добавлении функций, рекомендованных рабочей группой. Тем не менее, AS3 может никогда не быть полной (или полностью совместимой) реализацией будущего ECMAScript. Что это значит? Что ж, поскольку они снова нестандартны, у Adobe есть возможность добавлять функции в ActionScript, даже если эти функции не являются частью стандарта. Если вы чувствуете, что абстрактные классы или частные конструкторы важны для вас как разработчика, запросите эти функции в общедоступной базе данных ошибок проигрывателя Flash Player или проголосуйте за существующие запросы функций, если они уже есть.

Answer 3

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

Конструкторы не OO. Объекты должны быть созданы фабриками.
Абстрактные классы не являются ОО. Вместо этого следует использовать интерфейсы (которые есть в AS3) и миксины (которых нет в AS3).

AS3 - плохой язык, но по многим более фундаментальным причинам, чем эти два. AS3 в основном представляет собой структурированное представление байт-кода AVM2. Отображение 1: 1 легко выполнимо. И я предполагаю, что, скорее всего, так и останется, потому что Adobe, очевидно, больше интересуется продвижением функций платформы, их коммерческих инструментов разработки и гибкой среды (включая mxml).

Greetz
back2dos