Наследование и типы данных, как сделать правильно?

[PlutDem]

Все виды коробок унаследованы от Box и могут содержать в себе вещь наследованную от Item.
Правильно ли объявлять в каждом подклассе Box одну и туже переменную (itemInside), но с разным типом данных?

class BoxForToys extends Box{
 
                public var itemInside:Toy;	
                public function BoxForToys ():void {
		    itemInside= new Toy();//Toy наследован от Item
	}
 
}

class BoxForApples extends Box{
 
                public var itemInside:Apple;		
                public function BoxForApples ():void {
		    itemInside= new Apple();//Apple наследован от Item
	}
}

[Aquahawk]

public var itemInside:Toy; переместить в Box

[Silicium]

Во первых, судя по контексту во втором примере должно быть

itemInside:Apple;

Во вторых вопрос не совсем ясен, что вы имели ввиду? Можете объявить public itemInside:Item в классе Box.

[PlutDem]

Сообщение от Silicium

Во первых, судя по контексту во втором примере должно быть

itemInside:Apple;

Да именно так, исправил.

Сообщение от Silicium

Можете объявить public itemInside:Item в классе Box.

Первоначально, так и хотел сделать, но в этом случае в itemInside будет доступны переменные и методы только Item, но ни Toy или Apple. Сейчас в BoxForApples и в BoxForToys объявляются идентичные по логике переменные itemInside , но с разным типом данных. Не уверен, что это правильно.

[anmelegov]

(someItem as Toy).toyMethod() - вот так пробовал обращаться?

[alexcon314]

Используйте интерфейс, в которм объявлены нужные для работы с Item и его наследниками методы.
Можно в Box прописать public var itemInside:IToy; и хранить там ссылки на нужные экземпляры итемов.

[Silicium]

(someItem as Toy).toyMethod()

это верно

Используйте интерфейс

в данном контексте это не нужно

[Wolsh]

В идеале программа вообще не должна оперировать такими сущностями как "игрушка" и "яблоко".
Старайтесь абстрагировать происходящее насколько возможно.
Допустим, у яблока есть метод eat(), а у игрушки – play(). Но может, это стоит абстрагировать до метода use(), который у яблока один, а у игрушки другой? В какой момент "яблоко" становится яблоком? Только когда отображается на экране? Для программы надо знать, что это какой-то фрукт и какого он цвета? Нужна только картинка с яблоком. А по сути и яблоко и игрушка это просто item, у которого есть метод use(), картинка для отображения - image, и текстовое имя name.

[HardCoder]

Это поместить в Box:

public var itemInside:Item;

Потом:

public class Apple extends Item{
}

public class Toy extends Item{
}

Добавлено через 9 минут
Если яблоко и игрушка - это просто предметы, поведенческие свойства которых, не интересны в данном случае, то можно создать класс Item и использовать лишь разные изображения и имена, как писал Wolsh (яблоко/игрушка/мопед).
Но если класс Apple и Toy совсем разные, например: яблоко может гнить со временем, поэтому у него есть метод rot(), чего не скажешь про игрушку, то лучше создать один обобщенный класс Item с общими свойствами и методами для одного и другого, и просто унаследовать яблоко и игрушку от него (как я написал выше).
Все зависит от конкретной ситуации и от того, что автор воплощает в понятия Apple и Toy.

[Wolsh]

Если типов итемов 3-4, то конечно можно построить баррикаду из свитчей и обращаться с каждым как с яблоком или мопедом. Я к тому, что вы вообще представляете, что это значит, разные типы с разными методами, разным поведением? Каждый из которых буквально запускает разные ветки программы? Стоит ли тут вообще говорить о каком-то единстве? То есть, зачем им вообще наследоваться от Item, если единственное что их объединяет – ящик Карабаса? Но "лежать в ящике" это не их метод, это метод ящика. Так же как у DisplayObject нет метода "добавитьМеняВКонтейнер()", из-за отсутствия которого вся красота интерфейсов обламывается, как только наступает пора добавлять их реализаторов в контейнер.
Я всетаки считаю правильным наследование от суперкласса Item с переопределением реализаций абстрактных методов. Тогда программа сможет оперировать любым наследником Item единым образом. Надо только выделить эти абстракции, при реализации которых и получаются "совершенно разные" Item'ы. Тогда и расширяемость будет на высоте, можно будет добавлять сколько угодно барахла в ящик, не переписывая всю программу.