I wrote the following object type class.
public class ResponseType<T> : ObjectType<ResponseEntry<T>>
{
protected override void Configure(IObjectTypeDescriptor<ResponseEntry<T>> descriptor)
{
descriptor.Name("Response");
}
}
I want to use it like this as the outermost type in the resolver definition.
descriptor.Field<SharedResolvers>(r => r.GetObject1(default, default, default, default))
.Type<ResponseType<ListType<Object1>>>()
.Name("object1");
descriptor.Field<SharedResolvers>(r => r.GetObject2(default, default, default, default))
.Type<ResponseType<ListType<Object2>>>()
.Name("object2");
This code works if I only implement object1 however as soon as I add object2 I get the following error.
System.Collections.Generic.KeyNotFoundException: 'The given key 'HotChocolate.Configuration.RegisteredType' was not present in the dictionary.'
It seems as though there may be some issue with declaring two resolvers of the same class type. Is that the case? And if so, what are my options?
I was able to resolve the issue by setting the descriptor.Name to a unique value based on T.
descriptor.Name($"Response_{typeof(T).GetHashCode()}");
Then I realized my real issue was that I was defining the name at all. If you don't override the name it automatically comes up with a unique name/key based on the type definition.
We are using graphql-java and with com.coxautodev.graphql.tools.SchemaParser (from graphql-java-tools) we are creating executable schema - and it works just fine. Now we need to add user information and propagate it to our graphql method logic. The obvious approach is to use "context" object.
So, in mutations.graphql file there is:
type Mutations
createGroup(input: CreateGroupInput): IdRequest
...
On the other hand, there is a Java class with the corresponding method:
IdRequest createGroup(CreateGroupInput input) {
...
}
Then, when calling graphql.GraphQL.execute(myQuery, contextObject) how to read this contextObject into Java method above?
The thing I was looking for is DataFetchingEnvironment (see Fetching data).
The "contextObject" can then be retrieved in Java class by adding DataFetchingEnvironment as a last argument, like:
IdRequest createGroup(CreateGroupInput input, DataFetchingEnvironment environment) {
Object contextObject = environment.getContext();
...
}
Is it possible to have a ActionResult with a signature of:
[HttpPost]
public ActionResult SomeAction<T>([Bind(Prefix = typeof(T).Name)] T data)
{
MapAndUpdateModel<T>(data);
return Content(Boolean.TrueString);
}
I can't seem to use typeof(T).Name ?
Regards.
Attribute arguments must be types or compile-time constants. You can't call a method (the Name property getter) to supply a value to an attribute.
Unfortunately, BindAttribute is consumed by the MVC innards in long-ish hard-coded call chain without a trivial extension hook. If you want to add a similar attribute that would allow inference of the prefix, this is possible, but you would pretty much need to replace the ControllerActionInvoker merely in order to change the parameter binding behaviour.
"Replace conditional with polymorphism" is elegant only when type of object you're doing switch/if statement for is already selected for you. As an example, I have a web application which reads a query string parameter called "action". Action can have "view", "edit", "sort", and etc. values. So how do I implement this with polymorphism? Well, I can create an abstract class called BaseAction, and derive ViewAction, EditAction, and SortAction from it. But don't I need a conditional to decided which flavor of type BaseAction to instantiate? I don't see how you can entirely replace conditionals with polymorphism. If anything, the conditionals are just getting pushed up to the top of the chain.
EDIT:
public abstract class BaseAction
{
public abstract void doSomething();
}
public class ViewAction : BaseAction
{
public override void doSomething() { // perform a view action here... }
}
public class EditAction : BaseAction
{
public override void doSomething() { // perform an edit action here... }
}
public class SortAction : BaseAction
{
public override void doSomething() { // perform a sort action here... }
}
string action = "view"; // suppose user can pass either "view", "edit", or "sort" strings to you.
BaseAction theAction = null;
switch (action)
{
case "view":
theAction = new ViewAction();
break;
case "edit":
theAction = new EditAction();
break;
case "sort":
theAction = new SortAction();
break;
}
theAction.doSomething(); // So I don't need conditionals here, but I still need it to decide which BaseAction type to instantiate first. There's no way to completely get rid of the conditionals.
You're right - "the conditionals are getting pushed up to the top of the chain" - but there's no "just" about it. It's very powerful. As #thkala says, you just make the choice once; from there on out, the object knows how to go about its business. The approach you describe - BaseAction, ViewAction, and the rest - is a good way to go about it. Try it out and see how much cleaner your code becomes.
When you've got one factory method that takes a string like "View" and returns an Action, and you call that, you have isolated your conditionality. That's great. And you can't properly appreciate the power 'til you've tried it - so give it a shot!
Even though the last answer was a year ago, I would like to make some reviews/comments on this topic.
Answers Review
I agree with #CarlManaster about coding the switch statement once to avoid all well known problems of dealing with duplicated code, in this case involving conditionals (some of them mentioned by #thkala).
I don't believe the approach proposed by #KonradSzałwiński or #AlexanderKogtenkov fits this scenario for two reasons:
First, from the problem you've described, you don't need to dynamically change the mapping between the name of an action and the instance of an action that handles it.
Notice these solutions allows doing that (by simply assigning an action name to a new action instance), while the static switch-based solution doesn't (the mappings are hardcoded).
Also, you'll still need a conditional to check if a given key is defined in the mapping table, if not an action should be taken (the default part of a switch statement).
Second, in this particular example, dictionaries are really hidden implementations of switch statement. Even more, it might be easier to read/understand the switch statement with the default clause than having to mentally execute the code that returns the handling object from the mapping table, including the handling of a not defined key.
There is a way you can get rid of all conditionals, including the switch statement:
Removing the switch statement (use no conditionals at all)
How to create the right action object from the action name?
I'll be language-agnostic so this answer doesn't get that long, but the trick is to realize classes are objects too.
If you've already defined a polimorphic hierarchy, it makes no sense to make reference to a concrete subclass of BaseAction: why not ask it to return the right instance handling an action by its name?
That is usually implemented by the same switch statement you had written (say, a factory method)... but what about this:
public class BaseAction {
//I'm using this notation to write a class method
public static handlingByName(anActionName) {
subclasses = this.concreteSubclasses()
handlingClass = subclasses.detect(x => x.handlesByName(anActionName));
return new handlingClass();
}
}
So, what is that method doing?
First, retrieves all concrete subclasses of this (which points to BaseAction). In your example you would get back a collection with ViewAction, EditAction and SortAction.
Notice that I said concrete subclasses, not all subclasses. If the hierarchy is deeper, concrete subclasses will always be the ones in the bottom of the hierarchy (leaf). That's because they are the only ones supposed not to be abstract and provide real implementation.
Second, get the first subclass that answer whether or not it can handle an action by its name (I'm using a lambda/closure flavored notation). A sample implementation of the handlesByName class method for ViewAction would look like:
public static class ViewAction {
public static bool handlesByName(anActionName) {
return anActionName == 'view'
}
}
Third, we send the message new to the class that handles the action, effectively creating an instance of it.
Of course, you have to deal with the case when none of the subclass handles the action by it's name. Many programming languages, including Smalltalk and Ruby, allows passing the detect method a second lambda/closure that will only get evaluated if none of the subclasses matches the criteria.
Also, you will have to deal with the case more than one subclass handles the action by its name (probably, one of these methods was coded in the wrong way).
Conclusion
One advantage of this approach is that new actions can be supported by writing (and not modifying) existing code: just create a new subclass of BaseAction and implementing the handlesByName class method correctly. It effectively supports adding a new feature by adding a new concept, without modifying the existing impementation. It is clear that, if the new feature requires a new polimorphic method to be added to the hierarchy, changes will be needed.
Also, you can provide the developers using your system feedback: "The action provided is not handled by any subclass of BaseAction, please create a new subclass and implement the abstract methods". For me, the fact that the model itself tells you what's wrong (instead of trying to execute mentally a look up table) adds value and clear directions about what has to be done.
Yes, this might sound over-design. Please keep an open mind and realize that whether a solution is over-designed or not has to do, among other things, with the development culture of the particular programming language you're using. For example, .NET guys probably won't be using it because the .NET doesn't allow you to treat classes as real objects, while in the other hand, that solution is used in Smalltalk/Ruby cultures.
Finally, use common sense and taste to determine beforehand if a particular technique really solves your problem before using it. It is tempting yes, but all trade-offs (culture, seniority of the developers, resistance to change, open mindness, etc) should be evaluated.
A few things to consider:
You only instantiate each object once. Once you do that, no more conditionals should be needed regarding its type.
Even in one-time instances, how many conditionals would you get rid of, if you used sub-classes? Code using conditionals like this is quite prone to being full of the exact same conditional again and again and again...
What happens when you need a foo Action value in the future? How many places will you have to modify?
What if you need a bar that is only slightly different than foo? With classes, you just inherit BarAction from FooAction, overriding the one thing that you need to change.
In the long run object oriented code is generally easier to maintain than procedural code - the gurus won't have an issue with either, but for the rest of us there is a difference.
Your example does not require polymorphism, and it may not be advised. The original idea of replacing conditional logic with polymorphic dispatch is sound though.
Here's the difference: in your example you have a small fixed (and predetermined) set of actions. Furthermore the actions are not strongly related in the sense that 'sort' and 'edit' actions have little in common. Polymorphism is over-architecting your solution.
On the other hand, if you have lots of objects with specialised behaviour for a common notion, polymorphism is exactly what you want. For example, in a game there may be many objects that the player can 'activate', but each responds differently. You could implement this with complex conditions (or more likely a switch statement), but polymorphism would be better. Polymorphism allows you to introduce new objects and behaviours that were not part of your original design (but fit within its ethos).
In your example, in would still be a good idea to abstract over the objects that support the view/edit/sort actions, but perhaps not abstract these actions themselves. Here's a test: would you ever want to put those actions in a collection? Probably not, but you might have a list of the objects that support them.
There are several ways to translate an input string to an object of a given type and a conditional is definitely one of them. Depending on the implementation language it might also be possible to use a switch statement that allows to specify expected strings as indexes and create or fetch an object of the corresponding type. Still there is a better way of doing that.
A lookup table can be used to map input strings to the required objects:
action = table.lookup (action_name); // Retrieve an action by its name
if (action == null) ... // No matching action is found
The initialization code would take care of creating the required objects, for example
table ["edit"] = new EditAction ();
table ["view"] = new ViewAction ();
...
This is the basic scheme that can be extended to cover more details, such as additional arguments of the action objects, normalization of the action names before using them for table lookup, replacing a table with a plain array by using integers instead of strings to identify requested actions, etc.
I've been thinking about this problem probably more than the rest developers that I met. Most of them are totally unaware cost of maintaining long nested if-else statement or switch cases. I totally understand your problem in applying solution called "Replace conditional with polymorphism" in your case. You successfully noticed that polymorphism works as long as object is already selected. It has been also said in this tread that this problem can be reduced to association [key] -> [class]. Here is for example AS3 implementation of the solution.
private var _mapping:Dictionary;
private function map():void
{
_mapping["view"] = new ViewAction();
_mapping["edit"] = new EditAction();
_mapping["sort"] = new SortAction();
}
private function getAction(key:String):BaseAction
{
return _mapping[key] as BaseAction;
}
Running that would you like:
public function run(action:String):void
{
var selectedAction:BaseAction = _mapping[action];
selectedAction.apply();
}
In ActionScript3 there is a global function called getDefinitionByName(key:String):Class. The idea is to use your key values to match the names of the classes that represent the solution to your condition. In your case you would need to change "view" to "ViewAction", "edit" to "EditAction" and "sort" to "SortAtion". The is no need to memorize anything using lookup tables. The function run will look like this:
public function run(action:Script):void
{
var class:Class = getDefintionByName(action);
var selectedAction:BaseAction = new class();
selectedAction.apply();
}
Unfortunately you loose compile checking with this solution, but you get flexibility for adding new actions. If you create a new key the only thing you need to do is create an appropriate class that will handle it.
Please leave a comment even if you disagree with me.
public abstract class BaseAction
{
public abstract void doSomething();
}
public class ViewAction : BaseAction
{
public override void doSomething() { // perform a view action here... }
}
public class EditAction : BaseAction
{
public override void doSomething() { // perform an edit action here... }
}
public class SortAction : BaseAction
{
public override void doSomething() { // perform a sort action here... }
}
string action = "view"; // suppose user can pass either
// "view", "edit", or "sort" strings to you.
BaseAction theAction = null;
switch (action)
{
case "view":
theAction = new ViewAction();
break;
case "edit":
theAction = new EditAction();
break;
case "sort":
theAction = new SortAction();
break;
}
theAction.doSomething();
So I don't need conditionals here, but I still need it to decide which BaseAction type to instantiate first. There's no way to completely get rid of the conditionals.
Polymorphism is a method of binding. It is a special case of thing known as "Object Model". Object models are used to manipulate complex systems, like circuit or drawing. Consider something stored/marshalled it text format: item "A", connected to item "B" and "C". Now you need to know what is connected to A. A guy may say that I'm not going to create an Object Model for this because I can count it while parsing, single-pass. In this case, you may be right, you may get away without object model. But what if you need to do a lot of complex manipulations with imported design? Will you manipulate it in text format or sending messages by invoking java methods and referencing java objects is more convenient? That is why it was mentioned that you need to do the translation only once.
You can store string and corresponding action type somewhere in hash map.
public abstract class BaseAction
{
public abstract void doSomething();
}
public class ViewAction : BaseAction
{
public override void doSomething() { // perform a view action here... }
}
public class EditAction : BaseAction
{
public override void doSomething() { // perform an edit action here... }
}
public class SortAction : BaseAction
{
public override void doSomething() { // perform a sort action here... }
}
string action = "view"; // suppose user can pass either
// "view", "edit", or "sort" strings to you.
BaseAction theAction = null;
theAction = actionMap.get(action); // decide at runtime, no conditions
theAction.doSomething();
The switch is simple and looks OK. I don't think it would be that secure if a user could feed in a class name and you could directly use it without a switch conditional.
For obtaining data though, Coders have been known to use a look up table loop to get extra data reducing it to one if in an array look up search. Still thinking the switch looks simple enough to understand but would be cumbersome if you had 100s of choices.
Note: in this question, I am talking about formal Interfaces (e.g. public interface IButton {...} ).
I'm an Actionscript developer, but I suspect my question will resonate in many languages that allow both formal Interfaces and Events.
I love Interfaces. I love the separation between interface and implementation. (I wish Actionscript forced every class to implement a formal Interface, the way Objective-C does.) All of my classes implement an interface (or several), and you'll never find me writing a public method than isn't referenced in an Interface.
But Actionscript is also heavily dependent on Events. My problem is this: every part of a class that communicates with external classes or processes is (or should be) part of its Interface. (I realize this is a matter of opinion. If you disagree, this question will probably be meaningless to you.)
There are several ways to muddy this clear picture, but most of them are avoidable:
You can't list public properties in an Interface. Solution: don't use public properties in your classes. Use getters and setters instead (and I'm not all that crazy about them, either, but I use them when I must).
If classes communicate by passing arguments to constructors, those messages bypass Interfaces, since you can't list a constructor function in an Interface. I avoid this problem by (almost) never passing parameters through constructors. I prefer init() methods that can be made explicit in Interfaces.
Classes can have public methods that aren't listed in an Interface. I avoid this by not doing it. My classes implement Interfaces. Those Interfaces contain headers for ALL public methods.
Many classes dispatch Events.
That last one is the killer.
Let's say I give you a class called Blah, and you ask me how to use it. I can tell you, "It implements the IBlah Interface. Just look at that and you'll see everything you can do with Blah."
Except Blah extends EventDispatcher, which implies that it dispatches Events.
"What Events does it dispatch?" You ask.
"Uh..."
To know, you have to check the JavaDoc or read through Blah's source code. You shouldn't have to do either! You should be able to know how to interact with a class by checking its Interface(s).
I wish Interfaces could look like this:
public interface IBlah
{
function foo() : void;
function bar() : Boolean;
event BlahEvent;
}
But you can't specify events in an Interface.
Am I right that Events break Interfaces? To me, it's as if I gave you a car and said here's the manual. In the manual, it supposedly explains everything that's on the dashboard. But then, when you're driving the car, weird dohickies appear and strange sounds play -- Events that aren't mentioned in the manual.
If I'm wrong, please explain.
If I'm right, is there a good way to avoid the problem?
I think that what you are missing is that events are completely optional. There is no rule that says when you instantiate a class that you have to handle all events that it raises. You can (if your implementation calls for it) just completely ignore any events called raised by an object. Also, just definining and event says nothing about when or if it will actually be raised. So putting an event in an interface would be useless because there would be no way defining when or if the event was raised when the interface was implemented in a object.
My comment aside, I think you can declare function headers in the IBlah interface like dispatchMouseDownEvent (that takes required parameters, of course) and implement them in Blah to dispatch a mouse down event. Now instead of dispatching a mouse down event from a method, call dispatchMouseDownEvent from that method. Just make sure that you don't dispatch a mouse down event from anywhere else in the class.
Here's one way of doing it:
package
{
public interface IMortal
{
function stabMe() : void;
function dispatchDeathEvent() : void
}
}
package
{
import flash.events.EventDispatcher;
import flash.events.Event;
public class Person extends EventDispatcher implements IMortal
{
private var _dispatchesAllowed : Boolean = false;
private var _lifeForce : Number = 10;
public function stabMe() : void
{
if ( --_lifeForce == 0 ) iAmDead();
}
private function iAmDead() : void
{
_dispatchesAllowed = true;
dispatchDeathEvent();
}
public function dispatchDeathEvent() : void
{
if ( _dispatchesAllowed )
dispatchEvent( new Event( Event.COMPLETE ) );
_dispatchesAllowed = false;
}
}
}
I like this, because (a) it lists the event in the Interface and (b) locking the event from outside (_dispatchesAllowed) is optional. That's an implementation detail.
I dislike it because it's a hack. It's weird for a public method to be callable but useless unless it's called by and instance of its host class.
EventDispatcher implements IEventDispatcher and interfaces can extend other interfaces. So you can just do this:
public interface IButton extends IEventDispatcher
{
}
Now the IEventDispatcher methods are available on IButton
Edit: Also, regarding point #2, the class wouldn't have to use a constructor if it were given a factory interface.
Edit: Regarding point #1, fields (no get/set) are data. Interfaces only describe behavior without describing implementation. Having a field on an interface flies in the face of this by requiring you to implement it as a field.