Originating from architectural design (as in design of buildings), when design patterns crossed over to computer programming in the 1980’s, only a small group of people using a language called “SmallTalk” were applying them. In 1995, a group of four authors released a book called “Design Patterns: Elements of Reusable Object-Oriented Software”.
The four authors where nicked the “Gang of Four”. SmallTalk, but also C++ where the languages applying design patterns at that time. It is still the most respected book on design patterns to this date. “Gang of Four” (abbr. GoF) is also commonly used to refer to the book, rather than the authors.
Soon after, ‘Gurus’ such as Martin Fowler started publishing their own works, perhaps most notably “Patterns of Enterprise Application Architecture” (abbr. PoEAA). By then, most books where using Java in their examples. The Java community has played a big part in the evolution of Design Patterns, not in the last place thanks to efforts from Alur et al. with their “J2EE Core Patterns”.
Nowadays it’s a quite common approach to have models that essentially just represent database tables, and may support saving the model instance right to the database. While the ActiveRecord pattern and things like Doctrine are useful, you may sometimes want to decouple the actual storage mechanism from the rest of the code.
This is where the Data Access Object pattern comes in. It’s a pattern which abstracts the details of the storage mechanism – be it a relational database, OO database, an XML file or whatever. The advantage of this is that you can easily implement different methods to persist objects without having to rewrite parts of your code.
I’m again going to use the programming language quiz game I wrote as an example. Since I initially wrote it to use Doctrine ORM directly, and both the old and new code are available, you can easily see how the code was improved.
Tony Marston gives a nice intro to OOP:
The problem with OOP is that there is no clear definition of what it is and what it is not. Since its first appearance numerous people have expanded on its original definition (whatever that was) and invented new ‘rules’ which in turn have been subject to different interpretations. For each interpretation there are also many different possible implementations. There is no single definition, or set of definitions, which is universally accepted, therefore, no matter what you do, somebody somewhere will always find a reason to complain that ‘you are wrong!’
This article is highly recommended if you want to know the basics of OOP and also the intermediate level of OO programming.
This article by Tony Marston is an important one since it deals with the best practices of OO programming. I could say the article is not language specific but since he mostly deals with PHP and MySQL, the codes are based on PHP. Describes topics such as Data Dictionary, Entities, and OOP pagination system. He also shows how to store the state of an object in one page and then “resume” that state in another PHP script by using PHP’s built-in session object. Pretty neat, huh?
Some other good resources to learn about TraceMonkey:
The article from noupe.com provides the reader with 10 useful and practical ideas for using AJAX (don’t know what’s that yet?) After the “Ajaxian Revolution”, many sites started to AJAX almost without thinking. They were trying to squeeze AJAX into whatever they think was possible. This lead to memory leaks, security holes, and made them look like ***holes (even though I censored my badmouth, people can still get what I am saying. See RIAA and the homeez, you can NEVER censor the Internet!). So here are the 10 practical uses for AJAX:
- Login Forms
- Voting and Rating
- Updating With User Content
- Form Submission & Validation
- Chat Rooms And Instant Messaging
- Slicker UIs
- External Widgets
- Lightboxes instead of pop-ups
- Using AJAX With Flash
I was just thinking…the #10 usage seems pretty cool. We all know how Flash revolutionized the Internet and we also know how AJAX is revolutionizing the web today, and now if you think about mashing up these two mammoths of web, you can create a monolith!
Database connectivity is one of the most important columns of a dynamic web. Besides being able to handle database queries with great flexibility, a website must provide the database with strong security. One solution is to write some thousands of lines codes and repeat the process for future projects OR use a single class to handle all the database functions for all your projects. Since I have one of the most powerful assets a good programmer must have that is, laziness, I would opt for the second option.
This article from Particletree.com provides a solid background for creating really flexible database classes that you can extend in the future. Also, they provide the article for three different languages (although you can adapt the idea for almost infinite number of languages). Enjoy!