Yes, SpecialTable can be produced by the same factory (and by the same factory method) that produces Table. This not a problem, as long as SpecialTable provides at least the methods guaranteed by the Table interface (which it does).
This sort of situation makes sense when objects returned from the factory have some guaranteed behaviour/functionality (interface Table), and some optional stuff (interface SpecialTable).
So, in order to make use of the optional extra abilities/stuff available on some concrete objects returned by the factory, you have a few choices:
use polymorphism (recommended)
make use of instanceof (or similar), which can be used to check for interface compliance/exact typing (avoid this if possible!)
Using polymorphism
An example to illustrate: suppose SpecialTable has extra data and an extra widget 'blarg' which appears on the UI representing special tables. Do you really need the code which uses SpecialTable to know that it needs to add 'blarg' to the UI? Or can you just have your external code ask the thing of type Table to add its necessary UI components to some UI container? Then the calling code doesn't care what exact type the thing is -- SpecialTable deals with it, adding the 'blarg' to the container itself. This pattern can be described as the delegate pattern (also sometimes also known as strategy pattern).
Using instanceof (type checking)
Example of instanceof use:
// Table and SpecialTable are interfaces
Table table = TableFactory.instance().getDefaultTable();
if (table instanceof "SpecialTable") {
SpecialTable specialTable = (SpecialTable)table;
specialTable.specialMethod();
}
table.normalMethod();
Note that when you define your SpecialTable interface you can declare it as extending the Table interface and then only list the extra methods.
Your factory will be producing concrete objects of either type. So you might have a concrete class called BoringTable which implements Table, and a concrete class called ExcitingTable which implements SpecialTable.
Beware instanceof!
It's generally better to avoid things like 'instanceof' (or generally speaking, ifs of any kind which depend on what type an object is). You should favour polymorphism instead. By this I mean having multiple different classes, of a common type, enclosing different behaviour in their implementation code.
Ask yourself this: does the class using something of type Table (which might also be of type SpecialTable) need to care if it's a special table or not? Can you not hide that distinction in some sort of implementation of the SpecialTable -- have it do something different, something extra, that plain old Table does?
Client-side measures can never solve such a problem. Even if you disable smth and/or place validation, it is still possible to send invalid requests.
In this case I would disable the Cancel button in the UI. When the server receives a request to change state, I would validate it at server-side, ignore the request if the state is invalid and send an error status back to client. depending on the situation, I would also show an error message like The order has already been canceled.
Best Answer
I know I'm being pedantic here, but all objects can have state. The question is whether or not they should have state.
The answer to that question for strategies is the same as the answer for every other kind of inheritance relationship: Yes, as long as you're not violating the Liskov Substitution Principle.
The point of a strategy (or really any other inheritance-based design pattern) is that the caller/owner doesn't care about the implementation. So if the state is initialized either internally or through an instance constructor, and completely self-managed, then state is fine. On the other hand, if the outside world is supposed to be aware of this instance-specific state, then you've got a problem.
In a nutshell, if you find yourself needing to make this state public, then you've probably got a poor design; doubly so if you find yourself doing typecasts from the interface. But private state is, well, private; the whole point of patterns like Strategy is that the caller really doesn't care.
One other thing: Try to avoid sequential coupling. Even though it's OK for the strategy to have state, if the behaviour of the strategy depends significantly on that state then you are wading into dangerous territory, because you have no idea who else is going to try to use this strategy in the future and be unaware of the correct order of operations, so to speak.