Question

Suggest one or more analysis pattern for the following application domains: PLEASE DO NOT HAND WRITE THE ANSWER!! PLEASE ANSWER ALL PARTS OF THE QUESTION!!

A) Accounting Software

B) Email software

C) Internet Browsers

D) Word - Processing software

E) Website creation software

Answer 1

E). for programmers who are familiar with object oriented design,the domain model pattern is a natural one. int it, the developer implements an object model: that is, a variety of a related classes that represents object in the platform domain of the application. the classes with the domain model will have both data and behaviour and will be the natural location for implementing buisness rules. often the domain model will besimilar to the database schema,in that the diffrent domain classes will mirror the tables in the underlying database,while properties with in the class will mirror the fields with the table.A proper domain model will be organised around design principles and not around a Database schema.

D). Wordpress uses an event-driven architecture,in which there are a hooks in the core software and plugins and themes that acts as events.when Wordpress encounters a hook.it excutes all code hooked

This loosely conforms to the publisher/subscriber pattern where WordPress or a plugin or theme “publishes” an event with apply_filters() or do_action() that can be “subscribed to:” with add_filter() or add_action().

JavaScript runs in the browser using a similar event-driven approach. In JavaScript, we add event listeners to happen at specific events that are either triggered by page loading, such as window.onload() or based on user interaction with the browser such as a click event.

The event-driven architecture that WordPress and in-browser JavaScript use is fairly linear which makes it easy to understand. It can be summarized as “when this happens, do these things.”

The Model View Controller (MVC) pattern is not as easy to understand because it describes a real-time, circular relationship between the user and the application. There are many variations on the MVC pattern but in general, there are three parts: the view, controller, and model.

The view or template defines the visual representation of the data, based on the current state of the model, and can change based on user input.
The controller is the intermediary between the view and the data source or remote API. It also updates the model based on your interactions with the view and remote API.
The model is the current set of data, defined by the controller and displayed by the view.
In general, an application, framework, or language using MVC architecture is more difficult to understand than one using event-driven architecture. Neither is “better” or “more powerful,” but they are different and suited to different uses.

There are a few frameworks that have been created on top of WordPress that implement the MVC pattern. That’s great when they fit a specific need, however, it is just important to keep in mind that they are MVC on top of an event-driven architecture.

C). The Browsers page in Browser monitoring provides information about your end users' experience with your app based on which browser they use, such as Google Chrome, Mozilla Firefox, Microsoft Internet Explorer, and Apple Safari. This page includes:

Top browsers by throughput (pages per minute or ppm)
Average page load time by platform type (mobile, tablet, desktop)
Drill-down charts also segment the selected browser type by version; for example, Chrome 31, 32, 33, etc. This helps you quickly determine whether problems with page load timing may be related to a specific browser type or platform, or whether the problem is more widespread.Request queuing (black): Wait time between the web server and the application code. Large numbers indicate a busy application server.
Web application (purple): Time spent in the application code.
Network (brown): The network latency, or time it takes for a request to make a round trip over the Internet.
DOM processing (yellow): In the browser, parsing and interpreting the HTML and retrieving assets. Measured by the browser's DOMContentLoaded event.
Page rendering (blue): In the browser, displaying the HTML, running in-line JavaScript, and loading images. Measured by the browser's Load event.

B). I'm interested in building a better email client. Email clients today are not much different than email clients from fifteen years ago! I have a number of interesting ideas that I'd like to build into such an application.

The core of the application is an Email object. The Email class, presented here, is capable of sending an email via SMTP. It requires the JavaMail API and the JavaBeans Activation Framework (JAF), which are distributed in the JARs mail.jar and activation.

To send messages .you all need to specify a number of configuration properties.of course java gives you many ways to do so.you can set properties programmatically,you can load them from a properties file,or you can pass them to the application command line arguments to the java VM.

Adding Features
I'd like to add a number of features to the Email class. For example, I'd like to be able to initiate the spell checker when I'm about to send, but only for certain recipients. I'd like to be able to log emails to other recipients. I might want to censor other emails for content. I might like an attachment verifier—something that scans the email for the words "attached" or "attachment," and asks whether I forgot an attachment if one is not provided. I might like auto CCing capabilities for certain emails.

All of these features would be great, at least from my standpoint. I could build them all into my Email class, but that would result in a pretty bloated class, with lots of if statements. I'm also not totally oblivious to the needs of others—many people would want to turn off my pet features. An inheritance hierarchy would certainly be unworkable. What I want is the ability to dynamically specialize email handling—something that the decorator design pattern affords.

Using the Decorator Design Pattern
With an inheritance hieararchy, I would extend from Email and override the send method. Using the decorator pattern instead, I would first define a common interface, perhaps named Sendable, declaring the method send. I'd then build a number of classes implementing this interface. These Sendable implementations would be decorators of the core Email class. Within their implemention of the send method, each decorator would invoke its own special behavior. A decorator also would contain a reference to another Sendable object that it decorated, or wrapped. As part of its implementation of send, the decorator would need to delegate to the contained object's send method.

A).The basic idea of accounting pattern is events will be translated by posting rules into entries which are stored in an account.

I will use a motorcycle service station work orders processing as an example. Work order is created when customer requests his motorcycle to be repaired. This work order will then join a queue, waiting to be processed by a free mechanic. While repairing the motorcycle, mechanic sometimes need to request replacement for broken spare part. Those requests should be added to the work order.

Accounting pattern is quite abstract, so implementation in this post is based on my perception and fine-tuned for the case above. I see a work order as an account. Its entries consist of service cost, spare part price, amount of discount, registration fee and others. For the sake of simplicity, I will exclude spare part replacements in this implementation. The balance of the work order account is the amount that should be paid by customer. Entries are created based on work order’s events. Examples of such events are repair request, spare part replacement request, reparation complete, and payment. These events usually don’t have pricing information, so posting rules will translate these events into entries which have an amount.