Category Archives: Books
Book Reviewed: Python Cookbook
Technobeans has added another feather to its cap!
Chetan Giridhar has reviewed ‘Python Cookbook’ book published by Packt Publishing House.
Python Cookbook
About the book
This cookbook is written as a collection of code recipes containing step-by-step directions on how to install or build different types of Python test tools to solve different problems. Each recipe contains explanations of how it works along with answers to common questions and cross references to other relevant recipes. The easy-to-understand recipe names make this a handy test reference book.
Author: Greg L. Turnquist
Technical Reviewer: Chetan Giridhar
Book Details
Language : English
Paperback : 364 pages [ 235mm x 191mm ]
Release Date : May 2011
ISBN : 1849514666
ISBN 13 : 978-1-84951-466-8
Mediator Design Pattern
Authors: Chetan Giridhar and Rahul Verma
As per wikipedia:
“ The mediator pattern provides a unified interface to a set of interfaces in a subsystem. This pattern is considered to be a behavioral pattern due to the way it can alter the program’s running behavior..”
Typically, mediator pattern is used in cases where many classes start communicating amongst each other to produce result. When the software starts getting developed, more user requests get added and in turn more functionality need to be coded. This results in increased interaction with in the existing classes and in addition of new classes to address new functionality. With the increasing complexity of the system, interaction between classes becomes tedious to handle and maintaining the code becomes difficult.
Mediator pattern comes in as a solution to this problem by allowing loose-coupling between the classes, also called as Colleagues in the Mediator Design Pattern. The idea is that there would be one Mediator class that is aware of the functionality of all the classes in the system. The classes are aware of their functionality and interact with the Mediator class. Whenever there is a need of interaction between the classes, a class sends information to the Mediator and it is the responsibility of the Mediator to pass this information to the required class. Thus the complexity occurring because of interaction between the classes gets reduced.
Facade Design Pattern
Authors: Chetan Giridhar and Rahul Verma
facade(n): the face or front of a building
As per wikipedia:
“The facade pattern is a software engineering design pattern commonly used with Object-oriented programming. (The name is by analogy to an architectural facade.). A facade is an object that provides a simplified interface to a larger body of code, such as a class library.”
Façade pattern falls under the hood of Structural Design Patterns. Façade is nothing but an interface that hides the inside details and complexities of a system and provides a simplified “front end” to the client. With façade pattern, client can work with the interface easily and get the job done without being worried of the complex operations being done by the system.
An important point to understand about the Facade pattern is that it provides a simplified interface to a part of the system, thereby providing ease-of-use for a sub-set of the functionality rather than complete functionality. Beauty of this is that the underlying classes are still available to the client if the client wants additional features/greater control and customization that are not provided in the current context of Facade pattern implementation.
Observer Design Pattern
Authors: Chetan Giridhar and Rahul Verma
As per wikipedia:
“The observer pattern (a subset of the publish/subscribe pattern) is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.”
Typically in the Observer Pattern, we would have:
-
Publisher class that would contain methods for:
-
Registering other objects which would like to receive notifications
-
Notifying any changes that occur in the main object to the registered objects (via registered object’s method)
-
Unregistering objects that do not want to receive any further notifications
-
-
Subscriber Class that would contain:
-
A method that is used by the Publisher Class, to notify the objects registered with it, of any change that occurs.
-
-
An event that triggers a state change that leads the Publisher to call its notification method
To summarize, Subscriber objects can register and unregister with the Publisher object. So whenever an event, that drives the Publisher’s notification method, occurs, the Publisher notifies the Subscriber objects. The notifications would only be passed to the objects that are registered with the Subject at the time of occurrence of the event.
Command Design Pattern
Authors: Chetan Giridhar and Rahul Verma
As per wikipedia:
“In object-oriented programming, the command pattern is a design pattern in which an object is used to represent and encapsulate all the information needed to call a method at a later time. This information includes the method name, the object that owns the method and values for the method parameters.
Command pattern is one of the design patterns that are categorized under ‘Observer’ design pattern. In command pattern the object is encapsulated in the form of a command, i.e., the object contains all the information that is useful to invoke a method anytime user needs. To give an example, let say we have a user interface where in the background of the interface would turn into RED if the button on the user interface named ‘RED” is clicked. Now the user is unaware what classes or methods the interface would call to make the background turn RED, but the command user sends (by clicking on ‘RED’ button) would ensure the background is turned RED. Thus command pattern gives the client (or the user) to use the interface without the information of the actual actions being performed, without affecting the client program.
The key to implementing this pattern is that the Invoker object should be kept away from specifics of what exactly happens when its methods are executed. This way, the same Invoker object can be used to send commands to objects with similar interfaces.
Command Pattern is associated with three components, the client, the invoker, and the receiver. Let’s take a look at all the three components.
-
Client: the Client represents the one that instantiates the encapsulated object.
-
Invoker: the invoker is responsible for deciding when the method is to be invoked or called.
-
Receiver: the receiver is that part of the code that contains the instructions to execute when a corresponding command is given.
Model-View-Controller Design Pattern
Authors: Chetan Giridhar, Rahul Verma
As per wikipedia:
“Model–View–Controller (MVC) is a software architecture,currently considered an architectural pattern used in software engineering. The pattern isolates “domain logic” (the application logic for the user) from input and presentation (GUI), permitting independent development, testing and maintenance of each.”
In MVC Design Pattern, the application is divided into three interacting categories known as the Model, the View and the Controller. The pattern aims at separating out the inputs to the application (the Controller part), the business processing logic (the Model part) and the output format logic (the View part).
