|
In C#, an interface cannot mark any method as static. i'm told the ILASM
supports it but i've never tested that
Two questions. First, why? OK, i've heard the reason about interfaces being
allocated on the stack but that's not a real reason. Which is OK because this
isn't a real question, it's just a complaint dressed up to look like a reason
Second question. If a language doesn't support a fairly obvious feature, one
has to wonder if perhaps what one is trying to do is stupid. As in, if my
code benefits from a static interface member maybe i've created a bad design.
So i'll describe what i'm doing and why i want a static method and anyone
curious enough to read it all can tell me what i should be doing instead
We're using a pretty typical request/response architecture. One party fills
out a request, the other party processes it. It's the software equivalent of
any time you've ever had to fill out a work order or fill up a shopping cart,
with you spending some time building a comprehensive, atomic request and when
you're all done someone (school, carpenter, checkout guy, etc.) processes it
all in a single, atomic, stateless transaction. You've seen it a billion
times in transaction processors, Web Services, other services (e.g., calls to
credit scoring companies or credit card companies), booking airline tickets,
processing home loans, etc.
So here's an example of how we're using it. A person sits down with an
ASP.NET page and wants to edit a bunch of data about a person. They type in
an ID or a name or something and hit Search. In this example, the UI builds a
SearchRequest and passes it to the UserManager. UserManager does whatever it
does and returns the data. SearchManager is done now - he is stateless
(relative to you) and works only on atomic operations. The user and the
ASP.NET page then change all the data, using a bunch of objects and whatnot
to do so. The user finishes and presses the Save button. When this happens,
all the changes are packed up into a ChangeRequest and sent, once again, to
the UserManager. The UserManager does whatever it does, calling however many
data sources and downstream systems it needs to call, and returns a status
(in our case, a status object, but that's not important here)
So our system has lots of objects but the actual persisting of data is
handled by stateless, atomic transaction managers (RequestProcessors)
We do not allow the UI to talk directly to the manager(s). Instead, they
have to go through a factory of sorts which checks the user's credentials and
returns an interface tailored to the user's security rights and business
process. Behind that interface is one of the manager objects. Some of the
manager objects implement multiple interfaces, but you don't know that, all
you know is that you have an interface tailored to your task. And if we
switch which manager implements your interface or which interfaces a manager
implements, you don't know and don't get affected
So our objects might look something like this:
public UserFactory {
IUserView UserViewManager;
IUserUpdate UserUpdateManager;
}
public IUserUpdate {
Update(UserChangeRequest changeRequest);
Validate(UserChangeRequest changeRequest);
}
internal UserManager : UserUpdateManager {
public Update(UserChangeRequest changeRequest);
public Validate(UserChangeRequest changeRequest);
}
User.aspx.cs {
UserChangeRequest changeRequest = BuildChangeRequest();
ValidationResult result =
UserFactory.UserUpdateManager.Update(changeRequest );
}
OK, hopefully it's made sense so far. Here's where we get to the static
stuff. The manager classes are stateless and atomic. There is no reason that
they should ever be explicitly instantiated. Maybe if internally it was
caching stuff, but for the most part everything it does can (and i think
should) be static
However, none of the methods on the manager can be static because - and only
because - it uses interfaces. If the user called the manager directly (and
assuming they knew which one to call and we didn't change it on them and we
made all their methods public rather than selectively hiding them based on
roles), all the methods could be static. But because we use interfaces, none
of the methods can be static because a method defined in an interface cannot
be defined as static
i've heard the argument that an interface is just a contract and shouldn't
have to know implementation details. Which would be fine if the object
implementing the interface were allowed to add the static keyword to the
method. After all, it has absolutely no impact on the interface or the
contract it represents. But you can't do that meaning that interfaces aren't
just a contract, it's an implementation specification too, in this case
telling me i am not allowed to use static methods. i can (and have to) add
the keyword "public" when implementing the interface methods, i don't see why
i shouldn't be allowed to add "static" as well
Anyway, the question was, since i have a real (if small) benefit to using
interfaces with static methods and since that's not allowed, is there
something horribly wrong with my design? Is there something obvious i should
be doing different?
The one thing that leaps to mind is replacing the interfaces with facades.
That gives me a little better protection against change than the interfaces
since i can split delegation (right now all methods in an interface must be
implemented by the Manager). Another is that i dump the interfaces altogether
and make the manager objects facades (if need be). In either case, i suppose
i wouldn't need the factory since a facade factory seems kind of silly (a
facade using a factory, however...). Using interfaces is less work than
either, however, and is not exactly uncommon where factories are concerned
Ideas? | |
Share:
|
Hi, I am sorry if I didn't understand the idea but I think that the static
method is also called class method, so in your example you want to use
samething like this:
....
public UserFactory {
IUserView UserViewManager;
IUserUpdate UserUpdateManager;
}
...
...
User.aspx.cs {
UserChangeRequest changeRequest = BuildChangeRequest();
// Calling a static method defined in the interfase
ValidationResult result =
UserFactory.IUserUpdateManager.Update(changeReques t);
// this is your original sentence
// ValidationResult result =
// UserFactory.UserUpdateManager.Update(changeRequest );
}
I think that the CLR has no way to know which is the class that implements
the IUserUpdateManager static method, so you need a class (such as it is
implemented in the factory method design pattern you used).
"baylor" <ba****@discussions.microsoft.com> escribió en el mensaje
news:0E**********************************@microsof t.com... In C#, an interface cannot mark any method as static. i'm told the ILASM supports it but i've never tested that
Two questions. First, why? OK, i've heard the reason about interfaces being allocated on the stack but that's not a real reason. Which is OK because this isn't a real question, it's just a complaint dressed up to look like a reason
Second question. If a language doesn't support a fairly obvious feature, one has to wonder if perhaps what one is trying to do is stupid. As in, if my code benefits from a static interface member maybe i've created a bad design. So i'll describe what i'm doing and why i want a static method and anyone curious enough to read it all can tell me what i should be doing instead
We're using a pretty typical request/response architecture. One party fills out a request, the other party processes it. It's the software equivalent of any time you've ever had to fill out a work order or fill up a shopping cart, with you spending some time building a comprehensive, atomic request and when you're all done someone (school, carpenter, checkout guy, etc.) processes it all in a single, atomic, stateless transaction. You've seen it a billion times in transaction processors, Web Services, other services (e.g., calls to credit scoring companies or credit card companies), booking airline tickets, processing home loans, etc.
So here's an example of how we're using it. A person sits down with an ASP.NET page and wants to edit a bunch of data about a person. They type in an ID or a name or something and hit Search. In this example, the UI builds a SearchRequest and passes it to the UserManager. UserManager does whatever it does and returns the data. SearchManager is done now - he is stateless (relative to you) and works only on atomic operations. The user and the ASP.NET page then change all the data, using a bunch of objects and whatnot to do so. The user finishes and presses the Save button. When this happens, all the changes are packed up into a ChangeRequest and sent, once again, to the UserManager. The UserManager does whatever it does, calling however many data sources and downstream systems it needs to call, and returns a status (in our case, a status object, but that's not important here)
So our system has lots of objects but the actual persisting of data is handled by stateless, atomic transaction managers (RequestProcessors)
We do not allow the UI to talk directly to the manager(s). Instead, they have to go through a factory of sorts which checks the user's credentials and returns an interface tailored to the user's security rights and business process. Behind that interface is one of the manager objects. Some of the manager objects implement multiple interfaces, but you don't know that, all you know is that you have an interface tailored to your task. And if we switch which manager implements your interface or which interfaces a manager implements, you don't know and don't get affected
So our objects might look something like this:
public UserFactory { IUserView UserViewManager; IUserUpdate UserUpdateManager; }
public IUserUpdate { Update(UserChangeRequest changeRequest); Validate(UserChangeRequest changeRequest); }
internal UserManager : UserUpdateManager { public Update(UserChangeRequest changeRequest); public Validate(UserChangeRequest changeRequest); }
User.aspx.cs { UserChangeRequest changeRequest = BuildChangeRequest(); ValidationResult result = UserFactory.UserUpdateManager.Update(changeRequest ); }
OK, hopefully it's made sense so far. Here's where we get to the static stuff. The manager classes are stateless and atomic. There is no reason that they should ever be explicitly instantiated. Maybe if internally it was caching stuff, but for the most part everything it does can (and i think should) be static
However, none of the methods on the manager can be static because - and only because - it uses interfaces. If the user called the manager directly (and assuming they knew which one to call and we didn't change it on them and we made all their methods public rather than selectively hiding them based on roles), all the methods could be static. But because we use interfaces, none of the methods can be static because a method defined in an interface cannot be defined as static
i've heard the argument that an interface is just a contract and shouldn't have to know implementation details. Which would be fine if the object implementing the interface were allowed to add the static keyword to the method. After all, it has absolutely no impact on the interface or the contract it represents. But you can't do that meaning that interfaces aren't just a contract, it's an implementation specification too, in this case telling me i am not allowed to use static methods. i can (and have to) add the keyword "public" when implementing the interface methods, i don't see why i shouldn't be allowed to add "static" as well
Anyway, the question was, since i have a real (if small) benefit to using interfaces with static methods and since that's not allowed, is there something horribly wrong with my design? Is there something obvious i should be doing different?
The one thing that leaps to mind is replacing the interfaces with facades. That gives me a little better protection against change than the interfaces since i can split delegation (right now all methods in an interface must be implemented by the Manager). Another is that i dump the interfaces altogether and make the manager objects facades (if need be). In either case, i suppose i wouldn't need the factory since a facade factory seems kind of silly (a facade using a factory, however...). Using interfaces is less work than either, however, and is not exactly uncommon where factories are concerned
Ideas? | | This discussion thread is closed Replies have been disabled for this discussion. Similar topics
7 posts
views
Thread by mdc |
last post: by
|
5 posts
views
Thread by Andy |
last post: by
|
2 posts
views
Thread by Paul Selormey |
last post: by
|
5 posts
views
Thread by TruongLapVi |
last post: by
|
3 posts
views
Thread by bauscharln |
last post: by
|
17 posts
views
Thread by Picho |
last post: by
|
1 post
views
Thread by baylor |
last post: by
|
6 posts
views
Thread by Christian Convey |
last post: by
|
6 posts
views
Thread by GroupReader |
last post: by
| | | | | | | | | | |