I have a service that takes a dependency on HttpContextBase.
Ninject is injecting this for me already as it's set up in the MvcModule to return new HttpContextWrapper(HttpContext.Current) when HttpContextBase is requested
I want to use this service in Application_AuthenticateRequest, so i'm using property injection so that Ninject resolves it for me
When I try and access Request.UserHostAddress on the HttpContextBase I get a Value does not fall within the expected range exception
If I call HttpContext.Current.Request.UserHostAddress directly it works without problems
ExampleService.cs
public class ExampleService : IExampleService {
HttpContextBase _contextBase;
public ExampleService(HttpContextBase contextBase) {
_contextBase = contextBase;
}
public void DoSomething() {
var ip = HttpContext.Current.Request.UserHostAddress; <== this works
ip = _contextBase.Request.UserHostAddress; <== this fails
}
}
Global.asax
[Inject]
public IExampleService ExampleService { get; set; }
public void Application_AuthenticateRequest() {
ExampleService.DoSomething();
}
I'm missing something here, but I can't see what
Dependencies that are injected into classes live as long as the the class they get injected into, because the class holds a reference to them. This means that in general you should prevent injecting dependencies that are configured with a lifetime that is shorter than the containing class, since otherwise their lifetime is 'promoted' which can cause all sorts of (often hard to track) bugs.
In the case of an ASP.NET application, there is always just one HttpApplication instance that lives as long as the AppDomain lives. So what happens here is that the injected ExampleService gets promoted to one-per-appdomain (or singleton) and since the ExampleService sticks around, so does its dependency, the HttpContextBase.
The problem here of course is that an HTTP context -per definition- can't outlive a HTTP request. So you're storing a single HttpContextBase once, but it gets reused for all other requests. Fortunately ASP.NET throws an exception, otherwise you would probably be in much more trouble. Unfortunately the exception isn't very expressive. They could have done better in this case.
The solution is to not inject dependencies in your HttpApplication / MvcApplication. Ever! Although it's fine to do so when you're injecting singletons that only depend on singletons recursively, it is easy to do this wrong, and there's no verification mechanism in Ninject that signals you about this error.
Instead, always resolve IExampleService on each call to AuthenticateRequest. This ensures that you get an ExampleService with the right lifetime (hopefully configured as per-web-request or shorter) and prevents this kind of error. You can either call into the DependencyResolver class to fetch an IExampleService or call directly into the Ninject Kernel. Calling into the Kernel is fine, since the Application_AuthenticateRequest can be considered part of the Composition Root:
public void Application_AuthenticateRequest() {
var service = DependencyResolver.Current.GetService<IExampleService>();
service.DoSomething();
}
In my understanding the strategy pattern is used to make behaviour interchangable. This involves that the responsibility of the strategy is defined in an interface, to which the client may then delegate calls. E.g. suppose a value can be obtained in different ways, the interface would have a method "getValue()".
My question concerns the case where the flow of control is opposite. For example if the concrete strategy initiates the request "onValueChanged()" on the client (suppose it has a reference to the client or a callback interface).
Is this still considered a strategy pattern?
Update - added the following source code example:
interface DataSupplierCb
{
void onValueChanged(int a);
}
interface DataSupplier
{
void check();
}
// NOTE 1: Data supplier knows how the get the value
class ConcreteDataSupplier : public DataSupplier
{
void check()
{
myDataSupplierCb.onValueChanged(47);
}
}
class Client : public DataSupplierCb
{
void onValueChanged(int a)
{
// NOTE 2: Client knows what to do with the value
}
void changeDataSupplier(int i)
{
if (i == 1)
{
myCurrentDataSupplier = new ConcreteDataSupplier(this);
}
}
}
No. That would not be the strategy pattern. In the strategy pattern, the strategy interface, and the concrete strategy implementations do not know about the client.
The client knows about the strategy interface, and knows nothing about the actual implementations.
The goal of this pattern is the ability of replacing one strategy with another without modifying the client. A strategy is usually some sort of algorithm.
What you are describing seems to be closer to the Observer design pattern in which there is a subject and one or several observers implementing a common interface (or inheriting from a common base class). The subject is the object that is being observerved, and the observers are objects that need to be notified whenever the subject changes. e.g: the subject can be some kind of data source, and one observer can be an histogram view, and another a pie chart view.
http://en.wikipedia.org/wiki/Observer_pattern
http://en.wikipedia.org/wiki/Strategy_pattern
If the intent of the DataSupplier interface to allow your Client to swap in, and delegate to, different concrete data-fetching implementations then yes it can be considered a strategy. Your Client is shielded from the details (aka strategy) used to fetch the value as expected in the use of the Strategy pattern. And the fact that the Client reference is passed to the Strategy is fine and common:
(From the GoF)
"Strategy and Context interact to implement the chosen algorithm. A
context may pass all data required by the algorithm to the strategy
when the algorithm is called. Alternatively, the context can pass
itself as an argument to Strategy operations. That lets the strategy
call back on the context as required."
The Context for you is Client.
Now that all being said, rare is a solution that uses only one pattern. Your notification does seem to use the Observer pattern as another poster commented, and that is fine.
What I don't like about what you have implemented though is that your Strategy is a pure interface. Not always a bad thing, but in this case, with that notification callback, an interface does not provide a guarantee that the notifictaion callback is going to happen. Interfaces only guarantee the method signatures. I would recommend using the Template pattern in a base class to derrive the strategies from.
abstract class DataSupplier
{
protected ClientInterface _client;
// ctor takes in context
public DataSupplier(ClientInterface client)
{
_client - client;
}
public void check()
{
int priorValue = 46;
int newValue = OnGetValue();
if (priorValue != newValue)
_client.onValueChanged(newValue)
}
protected abstract int OnCheck();
}
And then:
class ConcreteDataSupplier : DataSupplier
{
// Check, and notification, are handled by the base. We only need
// to implement the actually data fetching
int OnGetValue()
{
return someValue;
}
}
With this approach, I know the notification will be handled. I don't need to worry about an implementor forgetting it in a new strategy later.
I have this code
class Duck {
protected $strVocabulary;
public function Learn() {
$this->strVocabulary = 'quack';
}
public function Quack() {
echo $this->strVocabulary;
}
}
The code is in PHP but the question is not PHP dependent.
Before it knows to Quack a duck has to Learn.
My question is: How do I make Quack() invokable only after Learn() has been called?
No, that does not violate any OOP principle.
A prominent example is an object who's behavior depends on whether a connection is established or not (e.g. function doNetworkStuff() depends on openConnection()).
In Java, there is even a typestate checker, which performs such checks (whether Duck can already Quack()) at compile time. I often have such dependencies as preconditions for interfaces, and use a forwarding class whose sole purpose is protocolling and checking the state of the object it forwards to, i.e. protocol which functions have been called on the object, and throw exceptions (e.g. InvalidStateException) when the preconditions are not met.
A design pattern that handles this is state: It allows an object to alter its behavior when its internal state changes. The object will appear to change its class. The design pattern book from the Gang of Four also uses the example above of a network connection either being established or not.
If you want to fix the order then you can use an abstract base class where in the function quack() you call learn() first and then abstract method doquack() (some other good name, and this will have to be implemented by each derived class).
My question is: How do I make Quack() invokable only after Learn() has
been called?
you can separate concerns:
class EnrolleeDuck {
public function Learn() {
return new AlumnusDuck('quack');
}
}
class AlumnusDuck
{
protected $strVocabulary;
public function __construct(&strVocabulary) {
&this->strVocabulary = &strVocabulary;
}
public function Quack() {
echo $this->strVocabulary;
}
}
It's my first lines in PHP, feel free to correct
One of my WCF functions returns an object that has a member variable of a type from another library that is beyond my control. I cannot decorate that library's classes. In fact, I cannot even use DataContractSurrogate because the library's classes have private member variables that are essential to operation (i.e. if I return the object without those private member variables, the public properties throw exceptions).
If I say that interoperability for this particular method is not needed (at least until the owners of this library can revise to make their objects serializable), is it possible for me to use WCF to return this object such that it can at least be consumed by a .NET client?
How do I go about doing that?
Update: I am adding pseudo code below...
// My code, I have control
[DataContract]
public class MyObject
{
private TheirObject theirObject;
[DataMember]
public int SomeNumber
{
get { return theirObject.SomeNumber; } // public property exposed
private set { }
}
}
// Their code, I have no control
public class TheirObject
{
private TheirOtherObject theirOtherObject;
public int SomeNumber
{
get { return theirOtherObject.SomeOtherProperty; }
set { // ... }
}
}
I've tried adding DataMember to my instance of their object, making it public, using a DataContractSurrogate, and even manually streaming the object. In all cases, I get some error that eventually leads back to their object not being explicitly serializable.
Sure, write a wrapper class that has all of the same public properties available and simply put "get { return internalObject.ThisProperty; }. Decorate the wrapper class so that it works with WCF.
Another option is to write a Proxy class which mirrors the properties of the type you wish to use exactly, and return that via WCF.
You can use AutoMapper to populate the proxy object.
This approach has the advantage that your service's consumers don't need to take a dependency on the third party library in trying to use it.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am confused that what is the actual role of a delegate?
I have been asked this question many times in my interviews, but I don't think that interviewers were satisfied with my answer.
Can anyone tell me the best definition, in one sentence, with a practical example?
I like to think of a delegate as "a pointer to a function". This goes back to C days, but the idea still holds.
The idea is that you need to be able to invoke a piece of code, but that piece of code you're going to invoke isn't known until runtime. So you use a "delegate" for that purpose. Delegates come in handy for things like event handlers, and such, where you do different things based on different events, for example.
Here's a reference for C# you can look at:
In C#, for example, let's say we had a calculation we wanted to do and we wanted to use a different calculation method which we don't know until runtime. So we might have a couple calculation methods like this:
public static double CalcTotalMethod1(double amt)
{
return amt * .014;
}
public static double CalcTotalMethod2(double amt)
{
return amt * .056 + 42.43;
}
We could declare a delegate signature like this:
public delegate double calcTotalDelegate(double amt);
And then we could declare a method which takes the delegate as a parameter like this:
public static double CalcMyTotal(double amt, calcTotalDelegate calcTotal)
{
return calcTotal(amt);
}
And we could call the CalcMyTotal method passing in the delegate method we wanted to use.
double tot1 = CalcMyTotal(100.34, CalcTotalMethod1);
double tot2 = CalcMyTotal(100.34, CalcTotalMethod2);
Console.WriteLine(tot1);
Console.WriteLine(tot2);
a delegate is simply a function pointer.
simply put you assign the method you wish to run your delegate.
then later in code you can call that method via Invoke.
some code to demonstrate (wrote this from memory so syntax may be off)
delegate void delMyDelegate(object o);
private void MethodToExecute1(object o)
{
// do something with object
}
private void MethodToExecute2(object o)
{
// do something else with object
}
private void DoSomethingToList(delMyDelegate methodToRun)
{
foreach(object o in myList)
methodToRun.Invoke(o);
}
public void ApplyMethodsToList()
{
DoSomethingToList(MethodToExecute1);
DoSomethingToList(MethodToExecute2);
}
Taken from here
Q What are delegates?
A When an object receives a request, the object can either handle the request itself or pass the request on to a second object to do the work. If the object decides to pass the request on, you say that the object has forwarded responsibility for handling the request to the second object.
Or, as an easy pseudo example: something sends a request to object1. object1 then forwards the request and itself to object2 -- the delegate. object2 processes the request and does some work. (note: link above gives good examples)
Think about delegate as about a simplified implementation of Command pattern.
A delegate is an object that can refer to a method. Thus, when we create a delegate, we are creating an object that can hold a reference to a method. Furthermore, the method can be called through this reference. Thus, a delegate can invoke the method to which it refers.
The principal advantage of a delegate is that it allows us to specify a call to a method, but the method actually invoked is determined at runtime, not at compile time.
Simple Delegate
Declaration of delegate:
delegate-modifier delegate return-type delegate-name(parameters)
Implementation of delegate:
Delegate-name delegate-object=new Delegate-name(method of class)
http://knowpacific.wordpress.com/2012/01/26/delegate/
Here I am going to explain delegates, multicast delegates and their usage..
Delegate is a type which holds the method(s) reference in an object. It is also referred to as a type safe function pointer. We can say a delegate is a type that defines a method signature.
When you instantiate a delegate, you can associate its instance with any method with a compatible signature. You can invoke (or call) the method through the delegate instance.
Delegates are used to pass methods as arguments to other methods.
Event handlers are nothing more than methods that are invoked through delegates.
Advantages of using delegates are,
Encapsulating the method's call from caller
Effective use of delegate improves the performance of application
Used to call a method asynchronously.
There are some properties of delegates are
Delegates are like C++ function pointers but are type safe.
Delegates allow methods to be passed as parameters.
Delegates can be used to define callback methods.
Delegates can be chained together; for example, multiple methods can be called on a single event.
Methods do not have to match the delegate signature exactly.
public delegate type_of_delegate delegate_name() // Declaration
You can use delegates without parameters or with parameter list
If you are referring to the method with some data type then the delegate which you are declaring should be in the same format. This is why it is referred to as type safe function pointer. Here I am giving an example with String.
The following example shows a delegate operation:
namespace MyDelegate
{
class Program
{
private delegate void Show(string s);
// Create a method for a delegate.
public static void MyDelegateMethod(string me
ssage)
{
System.Console.WriteLine(message);
}
static void Main(string[] args)
{
Show p = MyDelegateMethod;
p("My Delegate");
p.Invoke("My Delegate");
System.Console.ReadLine();
}
}
}
What is Multicast Delegate?
It is a delegate which holds the reference of more than one method. Multicast delegates must contain only methods that return void, else there is a run-time exception.
delegate void MyMulticastDelegate(int i, string s);
Class Class2
{
static void MyFirstDelegateMethod(int i, string s)
{
Console.WriteLine("My First Method");
}
static void MySecondDelegateMethod(int i, string s)
{
Console.WriteLine("My Second Method");
}
static void Main(string[] args)
{
MyMulticastDelegate Method= new MyMulticastDelegate(MyFirstDelegateMethod);
Method+= new MyMulticastDelegate (MySecondDelegateMethod);
Method(1,"Hi"); // Calling 2 Methodscalled
Method-= new MyMulticastDelegate (MyFirstDelegateMethod);
Method(2,"Hi"); //Only 2nd Method calling
}
}
Here Delegate is added using the += operator and removed using the -= operator.
Delegate types are derived from the Delegate class in the .NET Framework. Delegate types are sealed—they cannot be derived.
Because the instantiated delegate is an object, it can be passed as a parameter, or assigned to a property. This allows a method to accept a delegate as a parameter, and call the delegate at some later time. This is known as an asynchronous callback.
A great explanation and practical implementation of the Delegate pattern can be found in the Google Collections Forwarding Classes (also, the Decorator pattern).
In Event communication sender does not know which object will handle the event.
Delegate is type which hold the reference of method.
Delegate has signature and holds reference to method which matches its signature
so Delegate is like type safe function pointer.
button1.Click += new System.EventHandler(button1_Click)
System.EventHandler is declared as a delegate here
In .net Events work on the concept of Delegate (like Button Click)
Delegate is used when you do not know which code to invoke at run time
So at that time Delegate is used to handle Events
http://msdn.microsoft.com/en-us/library/ms173171(v=vs.80).aspx
A delegate object
is an object that another object consults when something happens in that object. For
instance, your repair man is your delegate if something happens to your car. you go to your repair man and ask him to fix the car for you (although some prefer to repair the car themselves, in which case, they are their own delegate for their car).
A delegate is an object that represents a pointer to a function. However, it is not an ordinary function pointer in that it:
1) Is Object Oriented
2) Is type safe, i.e. it can only point to a method and you cannot read the raw memory address it is pointing to
3) Is strongly typed. It can only point to methods that match its signatures.
4) Can point to more than one method at the same time.
Delegates is mainly used with events.
The need is:
You do not want to execute a piece of code at the time when you run the program.
After running the program you want to execute that piece of code whenever an event occurs.
Example :
Console application - code can be executed only at the time you run the program. (Written inside Main method)
Windows application (user interface programming ) - code can be executed when clicking the button after running the program.
This is what they say, you do not know which method will invoke at compiling time. you know it only at runtime that is when clicking the button.
Without delegates no user interface programming is possible. Because you are executing code whenever the user makes events that is clicking button , typing in textbox, selecting dropdownlist item and so on....
A delegate is something to which a task is being delegated. The primary purpose of delegation is to decouple code and allow for greater flexibility and reuse.
In programming, and specifically object-oriented programming, this means that when a method is called to do some work, it passes the work on to the method of another object that it has a reference to. The reference could point to whatever object we wish, as long as the object conforms to a predefined set of methods. We call it "programming to an interface" (versus programming to a concrete class implementation). An interface is basically a generic template and has no implementation; it simply means a recipe, a set of methods, preconditions and postconditions (rules).
Simple example:
SomeInterface
{
public void doSomething();
}
SomeImplementation implements SomeInterface
{
public void doSomething()
{
System.err.println("Was it good for you?");
}
}
SomeCaller
{
public void doIt(SomeInterface someInterface)
{
someInterface.doSomething();
}
}
Now you see I can use whatever implementation I want at any time without changing the code in SomeCaller because the type that doIt() is passed is not concrete but rather abstract since it's an interface. In the Java world, this is often expressed in the service paradigm where you call out to a service (an object advertising itself as a service via a specific interface) and the service then calls out to delegates to help it do its work. The service's methods are named as coarse-grained tasks (makePayment(), createNewUser(), etc.), while internally it does lots if nitty-gritty work through delegation, with the delegates' types being interfaces instead of the concrete implementations.
SomeService
{
SomeInterface someImplementation = ... // assign here
SomeOtherInterface someOtherImplementation = ... // okay, let's add a second
public void doSomeWork()
{
someImplementation.doSomething();
someOtherImplementation.doSomethingElse();
}
}
(N.B.: How an implementation gets assigned is beyond the scope of this thread. Lookup inversion of control and dependency injection.)
While not really a "function pointer", a delegate might look like this is a dynamic language like PHP:
$func = 'foo';
$func();
function foo() {
print 'foo';
}
or in JavaScript you could do something like:
var func = function(){ alert('foo!'); }
func();