Return to Answer

It's impossible to discern just by looking at these field names (and without reading methods) that otherTables is meant to hold table aliases. Why not be kind to the code reader (who is often you, just at a later time) and call it tableAliases?

Additionally, relationship between ScopedData and LinkedList are not polymorphic, because in order leverage behavior that specific to ScopedData you have to use its concrete type, not super type. If you declare it as a List, Queue or Deque it would be a LinkedList in disguise (more over, ScopedData is not supposed to used like that)

It's impossible to discern just by looking at these fields (and without reading methods) that otherTables is meant to hold table aliases. Why not be kind to the code reader (who is often you, just at a later time) and call it tableAliases?

Additionally, the relationship between ScopedData and LinkedList are not polymorphic, because in order to leverage behavior that specific to ScopedData you have to use its concrete type, not super type. If you declare it as a List, Queue or Deque it would be a LinkedList in disguise (more over, ScopedData is not supposed to be used like that)

In case if you want to keep ScopedData implementation generic, then at the very least you should give domain-specific methods to types it's meant to work with instead of treating them "bags of values" with no encapsulation and useful behavior:

In case if you want to keep ScopedData implementation generic, then at the very least you should give domain-specific methods to types it's meant to work with instead of treating them as "bags of values" with no encapsulation and useful behavior:

It's impossible to discern just by looking at these field names (and without reading methods) that otherTables is meant to hold table aliases. Why not be kind to the code reader (which is often is you, only time later) and call it tableAliases?

At the same time you clearly have intention is to give ScopedData business behavior though which it's state should be manipulated. But at the same this class inherited dozens of methods (which can also update it's state) from LinkedList and which doesn't reveal business intent.

In this case it makes more sense to use composition by declaring a field of type Deque (that's the JDK type you need, when a stack data structure is required) and exposing only methods that communicate business intent.

If you have chosen the route of specific solution focused of the problem at hand, these lines might have look like this:

It's impossible to discern just by looking at these field names (and without reading methods) that otherTables is meant to hold table aliases. Why not be kind to the code reader (who is often you, just at a later time) and call it tableAliases?

At the same time, you clearly have intention is to give ScopedData business behavior though which it's state should be manipulated. However, this class also inherits numerous methods from LinkedList which can update its state and doesn't communicate business intent.

In this case it makes more sense to use composition by declaring a field of type Deque (that's the JDK type you need, when a stack data structure is required) and exposing only methods that reveal business intent.

By design, you're always working with the data on the top of the stack representing query score (i.e. your current()). And aren't columns and aliases is something that you'll be dialing with in other use-cases?

If you have chosen the route of specific solution, these lines might have look like this: