Как правильно организовать приведение типов при работе с generic стеком?

А что Вам мешает сделать Node типизированным? Сделать наследников по типу StringNode, IntNode и т.д. и в момент разбора создавать нужную ноду.

Евгений: Брр, не совсем понял что вы имеете ввиду. Можно поподробнее?

Евгений:
Я имел ввиду сделать так, например:
public class Node {

private T value;

public T getValue() {
return value;
}

И наследников, типа:
public class StringNode extends Node {
...
}

А где-то у Вас будет такая коллекция
List> nodes = new ArrayList();

И в момент парсинга Вы будете понимать, что за нода перед Вами, создавать объект нужного типа и класть его в Вашу коллекцию.

Тарасов Константин:
редактор сожрал теги)
Node<T> конечно же

Евгений: Я примерно понял о чем вы, но у меня есть ноды с совершенно разным поведением.
Т.е. как я показывал выше, присваивание хранит правую и левую часть, а например, нода метода хранит имя метода + список операций в нем.

Тарасов Константин:
Хорошо, а для чего Вам знать тип ноды? Можете на конкретном примере показать?

Евгений: Ну, если дополнить уже существующий пример с AssignNode конструтором, то
class AssignNode extends Node {
private VarNode left;
private ExpressionNode right;
public AssignNode (VarNode left, ExpressionNode right) {}
Нам же надо передать туда значения правильных типов, чтобы система проверки типов java была счастлива)
Ну а дальше - нам предстоит анализировать его и так далее. Сначала я пытался написать что-то похожее на паттерн Composite, но слишком разная логика у нод.

Тарасов Константин: Тоесть Вы не можете выделить общие правила для нод? Тогда какой смысл в классе Node? Может тогда использовать просто Object в списке нод?

Евгений: Нуу, так красивее и структурированнее) И даже если использовать Object, вопрос остается вопросом - нам все равно рано или поздно надо приводить типы.

Тарасов Константин:
Парсер это, по-моему, ярчайший пример паттерна Compositor. Попробуйте его все-таки. Нужно понять, что есть часть целого. Если это Node, то наверное как минимум она должна возвращать значение, которое в том числе так же может быть типа Node. Т.е. как минимум в интерфейсе Node может быть метод evaluate(). Имея единый интерфейс Вы сможете с легкостью добавлять новые элементы в Ваш парсер. Если поведение нод очень разное, то можно воспользоваться паттерном Visitor (Посетитель). Он немного избыточен но все-же для каждого типа Node можно сделать таких посетителей.
Сейчас примерно такую же задачу решаем просто (парсер и интерпретатор формул), и остановились именно на этих двух паттернах. Пока что они закрывают все потребности.

Евгений: Ну, по сути, сейчас я нахожусь в процессе переписывания кода с первой костыльной реализации, в которой я абсолютно все возможные типы нод запихнул в один класс (там был список для хранения чего угодно и Enum для определения какой тип ноды), которая работала ну очень плохо. И да, я и использую посетителей. Класс Node - просто абстрактный и обязывает всех его потомков определять для себя метод accept(visitor). Но тем не менее, я не представляю как можно запихнуть в Compositor совершенно разные по логике работы ноды, допустим нода идентификатор и нода операция сложения. Первая просто хранит внутри себя строку и выдает ее по геттеру, вторая же вообще не имеет имени и хранит внутри себя две других ноды.

Тарасов Константин:
Ну при реализации компоновщика обычно из чего исходят. Есть какой-то интерфейс, который задает базовые методы, такие как add, get, remove. Оперирует интерфейс с такими же экземплярами самого себя. Делаются наследники, типа LeafNode, CompositeNode. В них те самые базовые методы реализуются. Т.е. компоновщик позволяет Вам только построить что-то из кусочков. А вот что Вы с этими кусочками будете делать потом, это уже не его[компоновщика] дело :). Т.е. Ваш парсер, на основе входных данных может построить одну такую RootNode из конкретных реализации, а потом Вы делаете что хотите с этим, например, через посетителей. Т.е. грубо говоря интерфейсу Node про логику вообще знать не обязательно, он[интерфейс] должен предоставить только базовые методы для композиции.