Behavioral design patterns are concerned with the relationships among communications using different objects. They identify common communication patterns and provide a well-known solution to implement this communication, offering a higher degree of flexibility.

The most used behavioral patterns are:

Chain of responsibility

The Chain of responsibility Pattern can be used when there is a potentially high number of processing elements, and a stream of requests must be handled in different ways. Each request will be processed by different elements.

This pattern is implemented by encapsulating the processing elements inside a pipeline abstraction, and have objects launch and leave their requests at the entrance to the pipeline. The pattern chains the receiving objects together, and then passes any request messages from object to object until it reaches an object capable of handling the message.

Chain of Responsibility simplifies object interconnections. Instead of senders and receivers maintaining references to all candidate receivers, each sender keeps a single reference to the head of the chain, and each receiver keeps a single reference to its immediate successor in the chain

Command

The Command Pattern can be used when there is a need to issue requests to objects without knowing anything about the operation being requested or the receiver of the request.

Command decouples the object that invokes the operation from the one that knows how to perform it. To achieve this separation, the designer creates an abstract base class that maps a receiver (an object) with an action (a pointer to a member function). The base class contains an execute() method that simply calls the action on the receiver. All clients of Command objects treat each object as a “black box” by simply invoking the object’s virtual execute() method whenever the client requires the object’s “service”.

Command objects can be thought of as “tokens” that are created by one client that knows what needs to be done, and passed to another client that has the resources for doing it.

Interpreter

The Interpreter Pattern can be used when we’re facing a class of problems that occurs repeatedly in a well-defined and well-understood domain. If the domain were characterized with a “language”, then problems could be easily solved with an interpretation “engine”.

The Interpreter pattern discusses: defining a domain language (i.e. problem characterization) as a simple language grammar, representing domain rules as language sentences, and interpreting these sentences to solve the problem. The pattern uses a class to represent each grammar rule. And since grammars are usually hierarchical in structure, an inheritance hierarchy of rule classes maps nicely.

An abstract base class specifies the method interpret(). Each concrete subclass implements interpret() by accepting (as an argument) the current state of the language stream, and adding its contribution to the problem solving process.

Iterator

The Iterator Pattern can be used when there’s a need to “abstract” the traversal of very different data structures so that algorithms can be defined that are capable of interfacing with each transparently.

An aggregate object such as a list should give you a way to access its elements without exposing its internal structure. Moreover, you might want to traverse the list in different ways, depending on what you need to accomplish. But you probably don’t want to bloat the List interface with operations for different traversals, even if you could anticipate the ones you’ll require. You might also need to have more than one traversal pending on the same list. And providing a uniform interface for traversing many types of aggregate objects (i.e. polymorphic iteration) might be valuable.

The Iterator pattern lets you do all this. The key idea is to take the responsibility for access and traversal out of the aggregate object and put it into an Iterator object that defines a standard traversal protocol.

Mediator

When you have a big number of objects interacting among them, a rather complex structure might be formed. It can become so complex that trying to reutilize some functionality might show the spaghetti code phenomenon: trying to scoop a single serving results in an all or nothing clump. To avoid this, the Mediator Pattern encapsulates the behavior of the whole group in a single object.

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

In this pattern, peers are not coupled to one another. Each one talks to the Mediator, which in turn knows and conducts the orchestration of the others. The many to many mapping between colleagues that would otherwise exist, has been promoted to full object status. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Memento

The Memento Pattern can be used when you need to restore an object back to its previous state (undo or rollback operations).

The client requests a Memento from the source object when it needs to checkpoint the source object’s state. The source object initializes the Memento with a characterization of its state. The client is the “care-taker” of the Memento, but only the source object can store and retrieve information from the Memento (the Memento is “opaque” to the client and all other objects). If the client subsequently needs to “rollback” the source object’s state, it hands the Memento back to the source object for reinstatement.

An unlimited undo and redo capability can be readily implemented with a stack of Command objects and a stack of Memento objects.

Observer

The Observer Pattern can be used when a large monolithic design does not scale well as new graphing or monitoring requirements are requested.

Define an object that is the “keeper” of the data model and/or business logic (the Subject). Delegate all “view” functionality to decoupled and distinct Observer objects. Observers register themselves with the Subject as they are created. Whenever the Subject changes, it broadcasts to all registered Observers that it has changed, and each Observer queries the Subject for that subset of the Subject’s state that it is responsible for monitoring.

This allows the number and “type” of “view” objects to be configured dynamically, instead of being statically specified at compile-time.

Further reading

• Object Oriented Design
• Behavioral Pattern [Wikipedia]

Related posts:

1. Software design patterns (III): structural patterns
2. Software design patterns (I)
3. Software design patterns (II): creational patterns

These design patterns are all about class and object composition. Class-creation patterns use inheritance to compose interfaces, whilst object patterns define ways to compose objects to obtain new functionality. All of these patterns aim to ease the design by identifying a simple way to realize relationships between entities.

The most common structural patterns are:

Adapter

An off the shelf component may offer interesting functionality that you may want to reuse, but its view of the world is not compatible with the philosophy and architecture of the system currently being developed. This is where the Adapter Pattern steps in.

This pattern is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object, which redirects them into calls to the legacy component.

Bridge

The Bridge Pattern decomposes the original component’s interface and implementation into different class hierarchies. The interface class contains a pointer to the abstract implementation class. This pointer is initialized with an instance of a particular implementation class, but all subsequent interaction from the interface class to the implementation class is limited to the abstraction maintained in the implementation base class. The client interacts with the interface class, and it in turn “delegates” all requests to the implementation class.

The interface object is the handle known and used by the client. The implementation object, or body, is encapsulated to ensure that it may continue to evolve, or be entirely replaced.

Composite

The Composite Pattern might be used when an application needs to manipulate a hierarchical collection of objects of different types: different types of objects are handled in different ways, and querying the type of each object before processing it is not desirable.

This pattern is implemented by defining an abstract base class that specifies the behavior that needs to be performed upon all primitive and composite objects. Then, primitive and composite classes must be subclassed off of the Component class. Each composite object couples itself only to the abstract type component.

This pattern should be used when you have composites that contain components, each of which could be a composite.

Decorator

The Decorator Pattern can be used when a particular behavior or state must be applied to individual objects at run-time – in this case inheritance cannot be used because it is static.

The original object must be encapsulated inside an abstract wrapper interface, from which both the core and the decorator object inherit. The interface then uses recursive composition to allow an unlimited number of decorator layers to be added to each core object.

Note that this pattern allows functionality to be added to an object, not methods to an object’s interface. The interface presented to the client must remain constant as successive layers are specified.

Facade

When a segment of the client community needs a simplified interface to the overall functionality of a complex subsystem, you can use the Facade Pattern: this kind of software design encapsulates a complex subsystem within a single interface object.

The Facade Pattern defines a unified, higher level interface to a subsystem that makes it easier to use. This way, the learning curve necessary to successfully leverage the subsystem is reduced. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that power users might need.

Flyweight

The Flyweight Pattern is designed to solve problems related to granularity and performance: use it when designing objects down to the lowest levels of system granularity, with those objects being extremely expensive in terms of performance.

This pattern describes how to share objects to allow their use at fine granularities without prohibitive cost. Each Flyweight object is divided into two pieces: intrinsic (stateless) and extrinsic (state-dependent). Intrinsic state is stored in the Flyweight object. Extrinsic state is stored or computed by client objects, and passed to the Flyweight when its operations are invoked.

Flyweights are stored in a Factory’s repository. The client doesn’t create Flyweights directly, but requests them from the Factory. Each Flyweight cannot stand on its own. Any attributes that would make sharing impossible must be supplied by the client whenever a request is made of the Flyweight. The Flyweight uses sharing to support large numbers of objects efficiently.

Proxy

If you need to support resource-hungry objects, and you do not want to instantiate them unless and until they are absolutely necessary, you can use the Proxy Pattern.

The Proxy object instantiate some real object the first time the client makes a request of the proxy, remembers the identity of this real object, and forwards the request to it. Then, all subsequent requests are simply forwarded directly to the encapsulated real object. Implemented as an interface, the presence of the Proxy object standing in place of the real object is transparent to the client.

Continue reading Software design patterns (IV): behavioral patterns »

Further reading

• Object Oriented Design
• Structural Pattern [Wikipedia]

Related posts:

1. Software design patterns (II): creational patterns
2. Software design patterns (IV): behavioral patterns
3. Software design patterns (I)

Creational design patterns deal with class creation and instantiation, and how to use those instances. Basic class creation could result in design problems or added complexity to the design. These patterns solve these problems by controlling this object creation.

Some examples of creational design patterns:

Abstract factory

The Abstract Factory Pattern implements a new level of abstraction in charge of creating families of related or dependent objects without directly specifying their concrete classes. The Factory object provides creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application – where it is instantiated. The application can replace the entire family of products simply by instantiating a different instance of the abstract factory.

Builder

The Builder Pattern separates the algorithm for interpreting a stored persistence mechanism from the algorithm for building and representing one of many target products. The focus is on creating highly-complex objects.

This pattern affords finer control over the construction process. Unlike creational patterns that construct products in one shot, the builder pattern constructs the product step by step.

Factory Method

The Factory Method pattern is the standard way to create objects. It is similar to the Abstract Factory, but without the emphasis on families. This pattern defines an interface for creating an object, but defers the actual creation to subclasses. A superclass specifies all standard and generic behavior, and delegates the creation details to subclasses that are supplied by the client.

Factory Methods are routinely specified by an architectural framework, and then implemented by the user of the framework.

Object Pool

The Object Pool pattern lets others “check out” objects from its pool, and when those objects are no longer needed by their processes, they are returned to the pool in order to be reused.

We don’t want processes to be idle waiting for a particular object to be released, so the Object Pool also instantiates new objects as they are required. Furthermore, this pattern must also implement a facility to clean up unused objects periodically.

Prototype

The Prototype pattern creates new instances of an object by cloning others already in used, rather than by actually creating a new one. To do so, an abstract class must be declared specifying a pure virtual clone() method. Any class that needs a polymorphic constructor capability derives itself from the abstract base class, implementing the clone() operation.

The client then, instead of writing code that invokes the new() operator, calls a clone() operation on the abstract base class, indicating the particular concrete derived class desired.

Singleton

The Singleton pattern is used when the application needs one, and only one, instance of an object. By using this pattern, a global access point to the instance is provided, and the instance is created when the first access is made.

When choosing which ones to use, keep in mind that sometimes creational patterns are complementary, so you might be able to use more than one of these.

Further reading

• Object Oriented Design
• Creational Pattern [Wikipedia]

Related posts:

1. Software design patterns (III): structural patterns
2. Software design patterns (I)
3. Software design patterns (IV): behavioral patterns

A pattern describes a problem that happens over and over again in our environment, and then explains the core of the solution to that particular problem. Since it is just a scheme of the solution, the application of this pattern is not literal: it requires adaptation. You could use the same pattern a thousand times, and never repeat the way you applied it.

Software design patterns aim to:

• Provide reusable elements in the design of software projects
• Avoid spending time in the search of a solution to well-known and previously solved problems
• Standardize the process of designing software applications
• Facilitate the learning process of new generations of software developers and designers

Software design patterns are not used for:

• Imposing some alternatives against others: there are plenty of design patterns out there, and the software engineer must compare all of them and choose the one that best suits the needs of the project, if any at all.
• Erase the creativity inherent to software design: these patterns are a just a guide to an easier design process, a set of advices to follow. Developers can choose to either follow these rules or adapt them to better fit requirements.

These patterns are only recommended in case we’re facing a similar problem that the pattern addresses, having always in mind that it could just not be applied to our particular case. Abusing or forcing the use of design patterns can be a mistake.

In brief, a pattern is a common structure that similar applications have. This happens in all levels of life. For example, in our ordinary life we apply the pattern “greeting – introduction– message – farewell” in many different occasions. If you don’t think patterns are useful, then try to use the scheme “farewell – message – introduction – greeting” and see what happens.

The most widespread catalogue of design patterns can be found in the book Design Patterns: Elements of Reusable Object-Oriented Software, from Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (1995, Addison-Wesley), AKA GOF (Gang-Of-Four). According to this book, design patterns can be categorized regarding the purpose they have been defined for:

• Creational patterns: solve instance creation problems. They help in encapsulating and abstracting these creations.
• Structural patterns: solve class and object composition problems.
• Behavioral patterns: solve problems about interaction and responsibilities among classes and objects.

Software design patterns are usually easy to understand. What might get you more headaches might be using them. They really help and make software development less problematic, so it is very important to get to know some of them. I’ll mention some of them in the next few posts.

Further reading

• Software (design) patterns resources
• Patterns and Software: Essential Concepts and Terminology
• Design Patterns: Elements of Reusable Object-Oriented Software (ISBN 0-201-63361-2)

Related posts:

1. Software design patterns (II): creational patterns
2. Software design patterns (III): structural patterns
3. Software design patterns (IV): behavioral patterns

CSS 3 has quite a few new concepts. Let’s take a look:

New properties

• Borders: border-color, border-image, border-radius, box-shadow.
• Backgrounds: background-origin, background-clip, background-size, layering multiple background images.
• Color: HSL colors, HSLA colors, RGBA colors opacity.
• Text: text-shadow, text-overflow.
• Interface: box-sizing, resize.
• Selectors: attribute selectors.
• Formats: media queries, multiple column layout, speech.

New features

Using these new properties we’ll be able to achieve things such as:

• Borders, background
  CSS 3 will allow images for borders, round corners and shadows. Objects can not only be positioned, but its direction can also be changed (horizontal or vertical).
• Multi-column layout
  Designing pages with multiple columns now will be easier than ever. Until now we needed to enclose the content in two separate DIVs to simulate a two-column layout; now we’ll just use column-count: 2. Not all that hard, right?
• Advanced Layout
  This new feature will allow objects to be distributed along the screen in a better an easier way, and combine them in different manners without additional tags. Besides, the page model will be included: this means that we will be able to indicate page footers, crossed references, and section headers.
• Selectors
  There are new selectors to make it easier locating exactly the element you want:
  E:only-of-type: an element which is unique in its type.
  E:not(s): an element which doesn’t match simple selector.
  E ~ F: an element F with an element E right before.
  E:nth-child: the n-th child element of a parent node. With this selector we’ll be able to implement things such as zebra tables.
  E:nth-last-child: the last child element from a parent node.
  E:nth-of-type: the n-th element which is of a certain type.
  E:first-of-type: the first element which is of a certain type.
• Resizing
  Up till now, if we wanted our elements to be resizable we needed to use Javascript to alter its attributes. With CSS 3 it will now be a task of the browser, just by using the resize property.
• And many more things …

Some properties of CSS 3 are already being implemented in most major browsers. There’s not a 100% fully compliant web browser yet (specially because CSS 3 is not finished yet), but it won’t take much time to have one. This means that maybe we won’t be able to use all of these new features right now, but we can certainly start using some of them. So, what are you waiting for? The sooner the better!

Further reading

• W3C CSS3
• www.css3.info
• 70 Must-Have CSS3 and HTML5 Tutorials and Resources

Related posts:

1. HTML 5: dramatic improvements in the web language

New tags

• <article /> This new element defines a portion of the content as an article. Perfect for newspapers or blogs.
• <aside /> Represents a fragment of information that slightly relates with the rest of the content.
• <dialog /> Depicts conversations.
• <figure /> Used to associate a caption with an embedded content, such as graphics or video.
• <footer /> Page section to hold author information, copyright statement, etc…
• <header /> Page section to hold some introductory information.
• <nav /> Section oriented to navigation.
• <section /> Element that defines a generic section.
• <audio /> and <video /> Provides multimedia content.
• <embed /> Supports plugin contents.
• <m /> Marked text.
• <meter /> Used to display measures.
• <time /> Used to display dates and/or time.
• <canvas /> Used to show real-time renderized graphics, such as games. For example, Sierra adventure games.
• <command /> Related with commands a user can invoke.
• <datagrid /> Shows additional information if it is requested by the user.
• <datalist /> Used together with the new attribute for <input /> can be used to create comboboxes.
• <output /> Denotes what kind of output the page produces.
• <progress /> Represents a progress bar in a time consuming task, such as donwloading a file.

New local attributes

There’s a few new attributes for some of the elements that were already present in HTML4.

• media: for greater consistency with the link element.
• ping: whitespace-delimited URLs list to which a ping will be produced when the link is followed. For the elements <area /> and <a />.
• target: for greater consistency the <a /> element.
• autofocus: indicates that the <input />, <select />, <textarea /> or <button /> element should get the focus at page load.
• form: attribute for <input />, <ouput />, <select /> <textarea />, <button /> and <fieldset /> which allows them to be associated to a form. This way, they can now be placed anywhere on a page, not as children of the form element.
• replace: will affect the element once changes are performed to it. For elements <input />, <button /> and <form />.
• data: specifies data for the elements <form />, <select /> and <datalist />.
• required: denotes a required element, for <input /> and <textarea />.
• disabled: for the <fieldset /> element.
• autocomplete, min, max, pattern, step: these attributes delimitate the possibilities of the <input /> element.
• list: for <datalist /> and <select /> elements.
• template: for <input /> and <button /> elements, it will be used to repeat templates.
• scoped: for the <style /> element, enables the use of scoped style sheets.
• async: for the <script /> element. AJAX turned into an attribute.

New global attributes

Some attributes that apply to the whole web page document:

• contenteditable: denotes an editable area.
• contextmenu: contextual menu supplied by the user.
• draggable: … needs explanation?
• tabindex: a numeric value representing the order of elements we will tour around when pressing the TAB key.
• irrelevant: … need I say more?
• repeat, repeat-start, repeat-min, repeat-max: these attributes refer to iterations.

HTMLDocument extensions

There are some improvements, and some other elements that finally get standarized:

• getElementsByClassName(): selects elements given a class. Time responses seem to be dramatically improved by using this function.
• innerHTML: present in all ECMAScript implementations, it was not a standard till now.
• activeElement, hasFocus(): will allow us to know which is element is active and which one has the focus.
• getSelection(): returns an object with the current selection.
• designMode, execCommand(): used to edit documents.

HTMLElement extensions:

The DOM element has also had some changes:

• getElementsByClassName(): returns the children of an element that has a given class.
• innerHTML: reads/changes the content of a node.
• classList: a very interesting implementation that, along with className, lets us interact with element classes, providing methods such as has(), toggle(), add() and remove().
• relList: works as classList on the rel attributes of the elements <a />, <area /> and <link />.

This is just a quick overview of the most important changes that HTML will bring. But there’s many more not mentioned here. For a complete reference guide, consult the W3C official draft.

HTML 5 is still a draft. Its definition is not finished yet. But all major browsers are already starting to implement some of its features. There’s still many years to wait for HTML 5 to be as widespread as HTML 4.01 is today, but the improvements this new version bring are so impressive that may affect its adoption speed. The originally proposed name for HTML 5 was Web Applications 1.0, which provides a very good idea about the goal of this new standard.

Further reading

• Yes, you can use HTML 5 today!
• HTML 5 cheat sheet
• Coding an HTML 5 layout from scratch
• A selection of supported features in HTML 5
• Preparing for HTML 5 with semantic class names

Related posts:

1. CSS 3: one more step in the evolution of the web

Semantics is the study of meaning, usually in language. The word “semantics” itself denotes a range of ideas [...]. It is often used [...] to denote a problem of understanding that comes down to word selection or connotation.

The Semantic Web is an extended web, with a greater meaning, in which users will be able to find answers to their questions faster and easier due to a better-defined information. This meaning-based web is supported by a set of standardized  languages that solve the problems the semantic-less web has, in which access to some information is a difficult and frustrating task.

The web has changed the way we communicate and do our work. Worldwide low-cost instantaneous communication is possible nowadays. We have access to millions of resources, regardless of our geographic location or language. These features have made the web tremendously successful… and at the same time they have provided its biggest problems: information overload and heterogeneity of information sources.

The Semantic Web aims at solving these two great problems, allowing software to perform some of the tasks the user must take care of now. Thanks to semantics in the web, software can process its contents and make logical decisions to solve everyday problems automatically.

Imagine you would want to find the nearest open pharmacy. You would go to your favorite web search engine and type “pharmacies open right now”. Today’s search engines would offer different information about pharmacies, but nothing related to what the user exactly wants to know. The next step would be to go through all the options listed and manually search for the precise information. Figure 1 shows the results a user would get with a regular search engine today.

By building semantics into the core of the web the search results would be accurate. Software would be able to properly understand what the user is asking for. Figure 2 shows results with a semantic search engine. These results give the user the exact information he was looking for. Geographic location would be detected automatically, and words like “right now” acquire greater sense and get translated to today’s date. All the information would be full of meaning.

The way information will be processed won’t be based on input/output parameters, but on its semantics. The Semantic Web provides an infrastructure based on metadata, allowing software to reason on the web, extending its capabilities.

It’s not about a magical artificial intelligence that will enable machines to understand human words… it’s just the skill of a machine to solve well-defined problems through well-defined operations that will be performed on a well-defined data set.

Further reading

This article covered just the very basics of the Semantic Web. If you’re still interested, you can expand your knowledge at:

• Semantic Web
• Web Ontology Language
• semanticweb.org
• Swoogle: experimental semantic search engine (if you’re going to use this, you might as well be interested in the FAQ)

So I thought that this report I did for university could be a good starting point for my blog. Besides, it’s already linked at wikipedia.

Open Source Software - History and overview