Server Requests
(→Possible Design Flaws) |
|||
| Line 1: | Line 1: | ||
| − | = | + | = Filip's Project = |
== Background == | == Background == | ||
Revision as of 00:45, 11 August 2010
Contents |
Filip's Project
Background
My design study is related to my part time job, where I am developing an application that can retrieve and plot data from a device that monitors air quality. The application is connected to a back end server where certain data is stored.
User operations that require communication with the server roughly include:
- Requesting help (and that the user be contacted)
- Electronically registering a device
- Calibrating a device - data about the calibration process is uploaded
Additionally, server communication is needed when the application:
- Authenticates with the server
- Pings the server to ensure network connectivity
My goal here is to create a design for the application side server interface framework. HTTPS POST requests are to be used to transfer data to the server.
Requirements
As this is a just a part of the app, the requirements are largely self imposed & generic:
- something that works
- is as nicely designed as practical
- is as easy to understand and maintain as practical
- is flexible so that new server requests can be added without much hassle
And not to forget:
- apply & learn better OO techniques
Design Study
Deliverables
- Classes that model the different request types
- Classes that allow requests to be sent over the network
Initial Design
This is my initial attempt at the design.
Design Summary
Sending Requests
Server requests are sent, and responses received using concrete insteances of IRequestSender. HttpPOSTRequestSender is the most generic concrete implementation of this interface - the two methods it has implement the actual sending/receiving mechanisms. XRequestSender is a class with a specific implementation of the IRequestSender interface for the application's purpose. It uses a composition relationship, containing an HttpPOSTRequestSender instance. Functionally, after computing and attaching a checksum to a given IRequest, the class is used to delegate Send/Receive calls to the contained HttpPOSTRequestSender.
Representing Requests
The IRequest interface is the most generic representation of a server request. In the style of HTTP POST/GET requests, a request is defined simply as something which can return a list of name-value pairs, representing the request parameters and their names (in particular a .NET 2.0 NameValueCollection).
XRequest is the abstract implementation of IRequest, implementing the shared functionality (send/get response) for all child classes. Each concrete request is then defined by a particular implementation of GetPOSTParameters() method - returning a list with different name-value parameter contents.
Using the classes together
The application creates concrete instances of the request classes, and interacts with them using the Send/GetResponse methods. The individual request objects then interact with the server using supplied instances of IRequestSender (concretely, XRequestSender). The application does not need knowledge of the IRequestSender family of objects, except for creating them and supplying them to request objects. Perhaps a factory method/class could tidy this up slightly.
Possible Design Flaws
- Possibly Lazy class smell, for the numerous concrete implementations of XRequest. Many 1 method classes, which have a very similar implementation (populate a list, though with different parameters).
- Something feels weird in the diagram about how requests are sent/ An IRequestSender is capable of sending any/many IRequest instances; an IRequest cannot send itself, while an XRequest can send itself and be sent by an IRequestSender.
- The request class hierarchy doesn't seem too bad and it works. Polymorphism is only utilized in dealing with IRequest instances in IRequestSender implementations. The child classes of XRequest are always used directly; XRequest only exists to factor out the common functionality of child classes. Possibly breaks Class hierarchies should be deep and narrow, however as suggested by that maxim, does extract common behaviour into XRequest superclass. The shallow but wide hierarchy "smells".
