AS3 - когда внедрять или расширять? - PullRequest
Новая
       1

AS3 - когда внедрять или расширять?

3 голосов
/ 16 мая 2011

Возьмем, к примеру, игру с несколькими вариантами ответов.

У вас есть классы MathQuestion и WordQuestion, должны ли они реализовывать интерфейс IQuestion, который определяет функции вопросов, ответов и затруднений, ИЛИ Является ли более обычным расширение базового класса вопросов и переопределение этих функций?1003 *

Какой самый правильный способ делать такие вещи?

Ответы [ 2 ]

2 голосов
/ 16 мая 2011

Вот еще один способ размышления о проблеме - есть ли разница между MathQuestion и WordQuestion? Для меня это звучит так, как будто они оба являются объектами Вопроса, и вы можете различать разные типы с помощью композиция .

Вы могли бы начать с определения класса Enum , в котором перечислены различные типы Вопросов, которые появляются в вашем Викторине (строго говоря, ActionScript 3 не имеет надлежащих Enums, но мы все же можем обеспечить безопасность типов с помощью следующего код.) 

public class QuestionType {
    public static const MATH : QuestionType = new QuestionType("math");
    public static const WORLD : QuestionType = new QuestionType("world");

    private var _name : String;

    // Private constructor, do no instantiate new instances.
    public function QuestionType(name : String) {
        _name = name;
    }

    public function toString() : String {
        return _name;
    }
}

Затем вы можете передать одну из констант QuestionType в класс вопросов при его создании: 

public class Question {
    private var _message : String /* Which country is Paris the capital of? */
    private var _answers : Vector.<Answer>; /* List of possible Answer objects */
    private var _correctAnswer : Answer; /* The expected Answer */
    private var _type : QuestionType; /* What type of question is this? */

    public function Question(message : String, 
                              answers : Vector.<Answer>, 
                              correctAnswer : Answer, 
                              type : QuestionType) {
        _message = message;
        _answers = answers.concat(); // defensive copy to avoid modification.
        _correctAnswer = correctAnswer;
        _type = type;
    }

    public function getType() : QuestionType {
        return _type;
    }
}

Наконец, клиент (код, который использует объект Question) может легко запросить тип вопроса: 

public class QuizView extends Sprite {
    public function displayQuestion(question : Question) : void {
        // Change the background to reflect the QuestionType.
        switch(question.type) {
            case QuestionType.WORLD:
                _backgroundClip.gotoAndStop("world_background");
                break;

            case QuestionType.MATH:
                _backgroundClip.gotoAndStop("math_background");
                break;
        }
    }
}
2 голосов
/ 16 мая 2011

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

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

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

...