Silverlight can be likened to a Microsoft version of a Java Applet. It is a stripped down version of the CLR that is executed within the framework of a browser. It utilizes a sandbox type security scheme as well.
Silverlight affords us the ability to run C# (or any other CLR language) code at the client, thereby not requiring the burden of going back to the server for each operation, and also aaffording the application expanded capabilities that are not suitable for HTTP requests.
The caution regarding Silverlight is that it is in fact a stripped down version of the language. Applications must be compiled using the Silverlight tool set to be included in the Silverlight project. If trying to utilize code written in other applications, the compiler directives of
#if SILVERLIGHT
#else
#endif
prove to be very helpful!
Additional information on Silverlight can be found at:
Amongst the hot topics this week includes asynchronous methods for the Web Services. Why, one might ask??
There is no need to make the GUI wait, or be locked up, while waiting for an overly busy server to respond... By incorporating asynchronous methods, the designer has the ability to restrict only the GUI features that they want without the locking the entire interface. This affords the user the option to potentially change their mind, else the application while they wait. It also affords them an exit strategy should something happen with the link to the server.
Web related sources, shall use them frequently; Silverlight uses asynchronous methods exclusively. There are several ways of incorporating asynchronous methods, including:
1. The BeginXXX/EndXX method calls
2. The .XXXAsync method, after you have already wired the .XXXCompleted event handler.
For further information on this topic, please see:
The Facade Patterns allows us to use a class with a simple interface to hide the complexity associated with more sophisticated and complex functions... An example of this is programming your VCR. Many people can't navigate the sequences necessary to program their VCR. The "facade pattern" for the VCR programming is the VCR+ programming tool, in which all you do is pop in the six digit number provided in the TV listing, and voila, all the programming is complete... That may be a dated example, but proves the point.
This pattern is also useful for reducing the dependencies objects have on each other, as well as reducing the amount of communication required between objects.
The proxy pattern allows us to create an object that "represents" a different object, typically a remote object... Therefore, your application can interact with with a local object as it communicates with a proxy object. The proxy object then has the burden of communicating with the remote object, and whatever intricacies those objects imply. The proxy therefore becomes a local representative of the remote object.
The Producer/Consumer architecture allows us to provide provisions for thread cooperation, and exchanging values between threads in a safe manner. As recommended by Dr. Schreiner, we created a producer/consumer "cell" that has the thread safe locking mechanisms built into it. This affords us a few advantages:
1. Cleans the code up so that we don't need to have the locking mechanisms in every place that the pattern is to be used.
2. Reduces the tendency for error as the code does not have to be duplicated in each instance
Multiple instance of the cell can be created, else a since cell
This represents a very important design pattern for the cooperation of threads, and should be something that is committed to memory.
The observer pattern allows us to set-up an automatic 1-to-Many relationship between objects. These could be any objects, but of course the M-V-C pattern comes to mind. This affords us a great mechanism by which we can keep multiple views synchronized with a single model.
To take this a step further, however, this affords us the ability to loosely couple the Views to the Models as the Models don't need o know anything about the views that subscribe to it. Instead, a controller can marry methods in the views to events in the controller. Then neither the View nor the Model need to know about each other, yet the View can still perfectly reflect the status of the model.
"A subject may have any number of dependent observers. All observers are notified whenever the subject undergoes a change in state. In response, each observer will query the subject to synchronize its state with the subject's state." -- C# Design Patterns, Cooper, pg. 314, Addison-Wesley 2003
To implement the M-V-C architecture, we need some means by which updates to the Model can be reflected to the View. The Model, however, must direct the View, not vice-versa. Additionally, a polling type of mechanism by the View is not correct, therefore events from the Model must direct the View.
A delegate is a sort of event listener (IObservable in Java, for example). Created within a namespace, but outside of a class, they are, in essence, subscriptions that objects can subscribe to.
In the Model (the observable class), a queue is created of all the subscribers. In the View (the observer class), they can subscribe to the event by indicating the method they desire to have called when the event happens.
Factory Methods:
Factory Methods are: "simple decision making [method] that returns one of several possible subclasses of an abstract (emphasis added) base class, depending on the data provided."
- C# Design Patterns, Cooper, pg. 97, Addison-Wesley 2003
Examples from the HW include... How do you create the Board class, or the BoardWithClear class?
To tie the two patterns (factory patten and template pattern) together, an algorithm is completed when the Factory Method selects the proper subclass of a template class, and instantiates it.
