Collect, test, and experiment with interface pattern pairings of CSS & HTML. Pears is an open source WordPress theme, enabling people like you to get your own pattern library up and running quickly.

Grab the theme at Github.
Install the theme.
Create markup & style patterns.
Learn.

approaches, personalities of software developers

Basic
Domain Logic
Data Source
Object-Relational Behavior
Object-Relational Structure
Object-Relational Metadata
Web Presentation
Distribution patterns
Concurrency
Session State
Practical PHP Patterns: Visitor

Subtle Patterns http://subtlepatterns.com/ I like 'em. (And am already thinking of using one or two on a project.)

Dependency injection (DI) in object-oriented computer programming is a technique that indicates to a part of a program which other parts it can use, i.e. to supply an external dependency – a reference – to a software component. In technical terms, it is a design pattern that separates behavior from dependency resolution, thus decoupling highly dependent components.
Developers of software strive to reduce dependencies between components for various reasons. This leads to a new problem, though: How can a component know all the other components it needs to fulfill its purpose?
The traditional approach was to hard-code the dependency. As soon as the database driver was necessary, the component would execute a piece of code that would load a specific driver, configure it, and call the necessary methods to interact with the database. If a second database must be supported, this piece of code would have to be modified or, even worse, copied and modified (violating the DRY principle).
The dependency injection offers a solution. Instead of hard-coding the dependencies, a component just lists the necessary services and a DI framework supplies these. At runtime, an independent component will load and configure the database driver and offer a standard interface to interact with the database. Again, the details have been moved from the original component to a set of new, small, database-specific components, reducing the complexity of them all. In DI terms, these new components are called "service components", as they render a service (database access) for one or more other components.
Dependency injection is a specific form of inversion of control, where the concern being inverted is the process of obtaining the needed dependency. The term was first coined by Martin Fowler to describe the mechanism more clearly.[1]

Style in jQuery Plugins and Why it Matters
1. A few "pro tips"
DRY = Don't repeat yourself
Use the jQuery API
Avoid premature optimization
Avoid over-avoiding premature optimization
2. Playing nice with others
Don't modify objects you don't own
Declare your variables
Use a closure
Use namespaces when binding event handlers
Use unique data names
3. Elements of style
Line length
Tabs vs. spaces
Crowding arguments or code blocks
Comments
Curly braces
4. In conclusion

Comments (0)

Find Ben on:

Videos
Articles
Network
Content
Resources

Having seen the Strategy pattern, it’s time to look at two related patterns, which use the same notion of a unified API to control a collection of (possibly) unrelated objects.

Both of these patterns give us the opportunity to turn our applications into something much “bigger” than we origionally planned, with minimal effort required to re-write code.

1)

The Adapter Pattern

The adapter pattern is conceptually a bit like an international power adapter that you take on holiday, so you can plug in your electric shaver or hairdryer to the local power supply.

You use an adapter pattern when you’ve already built a class to perform some task but now need to an alternative class (with perhaps a very different API) to perform the same function.

It’s similar to the Strategy pattern but where the Strategy pattern deals with hiding a set of algorithms behind a common interface, the Adapter pattern deals with hiding a collection of objects behind an interface.

Note: there are two variants of the Adapter pattern: the Object Adapter (which is what we’re talking about here) and the Class Adapter (which requires multiple inheritance, not supported by PHP).

It’s best demonstrated with an example. We’ve looked at the MVC Pattern.

Working, in general, from that example, which used MySQL as the target database, imagine now that we have customers for our “Products” application. Customer A says “I love it but I use Oracle”. Customer B says “I want to deploy you application in my N-Tier environment using SOAP to provide your application with data”.

So here we have two problems. For Oracle, simple database abstraction isn’t enough, because MySQL uses an SQL syntax which often varies significantly from Oracle. For example, imagine we want limit the number of rows we return from a SEL

The Observer Pattern
The observer pattern, also known as subject-observer and listener, is a more complicated but very prevalent and useful pattern. Anyone who has done event handling in Java knows this pattern, every kind of event listener is an observer to one subject or another - the keyboard, a window, a mouse, etc.

The pattern describes how to attach any number of observers to a subject, which can then act on events that occur involving the subject. For example, this pattern is available in the PEAR Log:: package, allowing you to monitor log data with an observer object and take action - such as sending an email page on any critical errors - on certain kinds of log messages.

Here's a simple usage of this implementation of the observer pattern:

The Observer Pattern is designed to help cope with one to many relationships between objects, allowing changes in an object to update many associated objects. It provides a powerful mechanism to extend our applications, in terms of how they respond to events, without needing alter existing (and working) code.

We’ll take a simplified look at how the observer pattern might be used in a typical PHP forum application then suggest other uses for the observer pattern

Under Observation

1) The Observer pattern is defined by the Gang of Four in Design Patterns as behavioural pattern - that is one we can use to modify the behaviour of our applications. It’s regarded as being so useful, that Sun bothered to implement it in the Java API (see Observable and Observer).

The basic principle behind the observer pattern is if you have some object, such as a Post object for a forum system, you can have other objects, such as a Mailer object, act as an observer and respond to any changes in the Post object, such as emailing relevant forums users that a new post has been added to the thread they were subscribed to.

Conceptually, the Observer pattern in something like a trigger in a database, which runs a stored procedure when a table row is modified for example (we won’t go too far with this analogy though).

Normally we might implement the mailing functionality in the Post object itself but what if later we want add further “events” to Post, when a new post is made, such as adding an entry to our forums RSS feed for example? And how many more things might we want to add in future?

The observer pattern provides us the mechanism to add such functionality without needing to alter the Post object.

The is easiest to see will some some example code.

First we define two interface classes; an Observable class which will be inherited by the Post class and allows it to become the subject of observation and an Observer class which will be inherited by the classes used to observer Post.

We have dozens of best practices to improve performances. We also have common practices to accomplish daily tasks. This post is about the most used JavaScript ArrayLike Object, aka arguments, and its performances impact over basic tasks.

Inside every JavaScript function an arguments object is available containing all the parameters passed to the function.

function aha(a, b) {
console.log(arguments[0] === a); // true
console.log(arguments[1] === b); // true
}

aha(1, 2);
However, it's not a good idea to use arguments for the reasons of :

performance
security
The arguments object is not automatically created every time the function is called, the JavaScript engine will only create it on-demand, if it's used. And that creation is not free in terms of performance. The difference between using arguments vs. not using it could be anywhere between 1.5 times to 4 times slower, depending on the browser (more info and bench)

As for the security, there is the POLA (Principle of Least Authority) which is violated when one function A passes arguments to another B. Then a number of bad things can happen including:

B calls A through arguments.callee - something A never intended when calling B in the first place
B overwrites some arguments and causes A to misbehave
While in these scenarios B looks a little malicious, it can actually cause trouble unvoluntarilly. Consider this example that illustrates the second case (B changing values behind A's unsuspecting back)

If you have never created a jQuery plugin, it takes just a few simple steps to get started. By following a handful of guidelines, you can develop a plugin that behaves and feels like a native jQuery method.

Before I begin describing these guidelines, I want to acknowledge some sources that were instrumental when I first started learning how to write a jQuery plugin. Some of them have been around a long time, and their content is always top notch.

* Plugins/Authoring on jQuery.com
* A Plugin Development Pattern from Oct 30, 2007, by Mike Alsup
* You Still Can't Create a jQuery Plugin? from Feb 19, 2009, by Jeffrey Way

Why Create a jQuery Plugin?

Here is a brief list of reasons you might want to create a jQuery plugin:

* Reuse, reuse, reuse
* Encapsulation
* Easy to write
* Maintain chainability
* Public distribution
* Prevent namespace clashing

Among these, I think that one of the best reasons to create a plugin is to encapsulate your code for reuse across your project. Plugins are relatively easy to write, so there’s very little holding you back from cleaning up your code and making it easier to maintain. If at some point you bundle your plugin for public distribution, that is great too, but organizing your own personal code is of greatest value. If you do distribute your jQuery plugin to the public, it’s a good idea to provide a namespace for your plugin so that it doesn't collide with one of the many other plugins out there.

If none of these reasons hit home with you, know that jQuery plugins are just plain fun to write, use, and reuse.

SPL Iterator wrapper (PHP)

I would avoid the Singleton approach suggested by Flavius. There are numerous reasons to avoid this approach. It violates good OOP principles. The google testing blog has some good articles on the Singleton and how to avoid it:

http://googletesting.blogspot.com/2008/08/by-miko-hevery-so-you-join-new-project.html http://googletesting.blogspot.com/2008/05/tott-using-dependancy-injection-to.html http://googletesting.blogspot.com/2008/08/where-have-all-singletons-gone.html

Alternatives

1) a service provider

http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceLocator.html

2) dependency injection

http://en.wikipedia.org/wiki/Dependency_injection
and a php explanation:
http://components.symfony-project.org/dependency-injection/trunk/book/01-Dependency-Injection

This is a good article about these alternatives:

http://martinfowler.com/articles/injection.html

Implementing dependency injection (DI):

-I believe you should ask what is needed in the constructor for the object to function: new YourObject($dependencyA, $dependencyB);
-You can provide the needed objects (dependencies) manually ($application = new Application(new MessageHandler()). But you can also use a DI framework (the wikipedia page provides links to PHP DI frameworks). Important is that you only pass in what you actually use (call an action on), NOT what you simply pass to other objects because they need it. Here's a recent post from 'uncle Bob' (Robert Martin) discussing manual DI vs using framework.

Some more thoughts on Flavius's solution. I don't want this post to be an anti-post but I think it's important to see why dependency injection is, at least for me, better than globals. Even though it is not a 'true' Singleton implementation, I still think Flavius got it wrong. Global state is bad. Note that such solutions also use difficult to test static methods. I know a lot of people do it, approve it and use it. But reading Misko Heverys blog articles (a google testability expert), rereading it and slowly digesting what he says did alter the way I see design a lot. If you want to be able to test you application you'll need to adopt a different approach to designing your application. When you do test-first programming, you'll have difficulty with things like this: 'next I want to implement logging in this piece of code, let's write a test first that logs a basic message' and then come up with a test that forces you to write and use a global logger that can't be replaced. I am still struggling with all the information I got from that blog and it's not always easy to implement and I have many questions. But there's no way I can go back to what I did before (yes, global state and Singletons (big S)) after I grasped what Misko Hevery was saying :-)

When I’ve talked about managing large applications in the past, I was criticized for going through many different options and then telling you that you can decide which one you liked the best. I suppose I might be afraid I’d make the wrong choice too, so in this article, I’m going to explain what I would use in my totally sweet large applications, but just know, there are lots of smart people who have different opinions.

What are interfaces?

The best description I could find so far is: An interface is a contract.

* An interface defines public methods that a class needs to implement
* An interface does not contain any code
* A class can implement multiple interfaces
* Interfaces can be used for type hinting

Basically if you see a class implementing an interface you know how to use it no matter how the implementation within the class is achieved.
What are abstract classes?

* An abstract class can implement methods (code)
* An abstract class can define abstract methods (no code)
* An abstract class can not be instantiated
* Classes can only inherit from one abstract class

And the difference is now what?

Abstract classes and interfaces are in some ways similar but they do each have their unique use cases.

The simplest rule is:

* If you write an abstract class containing only abstract methods you use an abstract class as an interface.

The Active Record pattern effectively prescribes to wrap a row of a database table in a domain object with a 1:1 relationship, managing its state and adding business logic in the wrapping class code.

An Active Record implementation is in fact a classical C structure aka Record aka associative array of data, with the addition of utility methods that encapsulate behavior that acts on these data. The most useful method is usually the save() one, which updates the database reflecting in the row the current state of the record. Thus, the Active Record transparently works with SQL queries and provides an higher-level Api.

Although Active Record is similar in implementation to the Row Data Gateway pattern, it is distinguished from it in the fact that it defines methods with domain-specific logic. The consequence of the presence of domain-specific logic is that generic implementations of Active Record provided by libraries must be customized to met the need of the object model. Typically this customization is done with a thin subclassing, which at least renames the library class with a domain name (like User or Post) and may specify metadata on the database table where the Active Records state is kept, if they are not inferred.

The Row Data Gateway pattern's intent is encapsulating a single row of a database table, and abstract away the mechanism used to access it and modify its data. Performance enhancements (such as delayed queries) and abstraction of the underlying SQL language are responsibilities of this pattern's implementation.

31 jQuery Snippets That Will Help Make You A JavaScript Pro

3362 ♻ Retweet
11,858
Delicous: 601
Buzz it

Posted on April 7, 2010 in: Web Development|Jump To Comments

Hey guys. Hopefully if you’re reading this you’ve discovered some of the true power jQuery has to offer and you’re now looking for ways to improve your JavaScript skills even further.

There was such a huge response to my last post on jQuery Snippets that I thought it only right to follow up with a fresh list that focuses on some of the more recent features introduced in jQuery 1.4.x. Because it’s always useful to have a second pair of eyes look over your code, I asked Paul Irish from the jQuery Team to take a look at all of today’s snippets and he’s included some useful optimizations to a few of the snippets which I’ve intregated.

Now, if I only we could fit Paul into a useful Browser plugin, all my articles would be just as sensible ;) The snippets from today can be applied to a wide range of projects so remember to bookmark the post if you find it useful so you can easily come back to it anytime you want. So without further adieu, I give you today’s 31 Snippets that will help make you a JavaScript Pro.

More and more people on the Web digging into JavaScript and using it for daily tasks. It is always fascinating to watch how they approach inheritance in JavaScript.

I want to introduce/reinforce a pattern for developing large applications with jQuery. I did not invent any of this, but I find that the resources that describe this technique are few and far-between.- so I'm taking a shot at it.

By and large, when using jQuery, developers seem to forget the paradigms they learned for well structured code in other languages. This is likely due to the fact that jQuery is effectively neutral when it comes to your structural methodology or inheritance patterns, and therefore doesn't push someone in any one direction. Many times in other libraries (See Dojo Declare/Provide/Require, or MooTools Class, etc.), a paradigm is used and exclusively offered, and then code generally ends up more uniform than the oh-so-common-massive-jquery-indented-chains that I'm sure you've seen .

Sometimes you have a nice concept for a design in your mind, but you don’t know where to start; or sometimes you are just not aware of the right size for the design to implement. That’s where templates come handy. I have collected some very useful templates with proper guidelines, sizes and resolutions for design projects like business cards, letterheads, vinyl designs, brochures etc. I believe that these will prove to be a great time-saver for many of you guys. Most of these are in PSD or AI format, and are easily editable. Hope you find them useful.

JavaScript is meant to be used to add behaviour to a website, might it be for form validation or for more complex operations like drag & drop functionality or performing asynchronous requests to the webserver (aka Ajax). During the past few years, JavaScript libraries became increasingly popular. One of the reasons is definitely that websites are getting more and more complex and reinventing the wheel each time is not acceptable if you are working on a tight schedule. But letting aside libraries and focusing on the “bare” syntax of JavaScript, it is very valuable to know what kind of options you have in terms of programming patterns when writing JavaScript.

In this article I am trying to present some of the techniques out there that I have discovered. The patterns I would like to mention are the following:

* The Old-School Way
* Singleton
* Module Pattern
* Revealing Module Pattern
* Custom Objects
* Lazy Function Definition

The programming community discourages using global data and objects. Still, there are times when an application needs a single instance of a given class and a global point of access to that class. The general solution is the design pattern known as singletons. However, singletons are unnecessarily difficult to test and may make strong assumptions about the applications that will use them. In this article I discuss strategies for avoiding the singleton pattern for that majority of cases where it is not appropriate. I also describe the properties of some classes that are truly singletons.

The key steps in creating singleton classes are as follows:

* Prevent direct instantiation by making the contructor private
* Store the only instance of the class as a static property of the class.
* Provide a static method to access the instance. The instance is created the first time this method is called.

User Interface Design Pattern Library. UI patterns for web designers. See examples and read rationale, solutions, and implementations for each pattern.

A Plugin Development Pattern at Learning jQuery