COOL helps you enjoy a well organized code: your code. It also helps your project become maintainable over the time.

Developing with Drupal is awesome, because we can do a lot of things with hooks and some already built APIs, from core and contrib, becoming common to have projects with some custom modules that has a .module file where hooks, internal functions, preprocessing, etc, happens together.

And you think it's beautiful! Uhh... maybe until you have to maintain such code.

A lot of Object Oriented Programming topics are being said because of Drupal 8, but in fact, we always could make Drupal 7 work with a lot of Object Oriented concepts. The main concept that we always SHOULD apply is: encapsulation. A code should have ONE responsibility(even if it is to bundle other code within a workflow, etc) and do it well.

With this ideas on mind and some experiments on DDD(Domain Driven Design), 2 big projects were supported over the last year, successfully combining Drupal 7 and OOP:
* - a crowdfunding platform
* - a crowdsourcing platform

It's not a prototype. It's a fact. After using this approach, we refactored a lot of components and:
* it reduced the amount of code
* it turns the code more readable
* it becomes easier to find bugs
* it becomes easier to change project rules
* it becomes easier to improve code

Technical overview

The idea is enhancing the Drupal DX through classes and helpers to make it easier to know "which piece of code is responsible for each feature", separating the logic through classes, instead of a big file with dozens of responsibilities and functions.

Currently, it provides wrappers to the following drupal components:
* hook_menu - create pages(menu routes)
* hook_block - create blocks(with configuration forms, submit, etc, inside the class)
* forms - bundle the form definition, validate and submit rules inside 1 class


Take a look at the "cool_examples" submodule to see the module working. Wanna read a little more? Go to OOP in Drupal 7: Cool module in practice.


The same approach used by this module can be used by other modules to find classes that implement Interfaces or extend parent or abstract classes, avoiding the need to declare/register each class on even more hooks. All you need is follow PSR-0 and define some folder structure so that other module can apply themselves to these patterns.

Modules already using COOL


It's very useful for me, so i'm sharing here, so feel free to give your opinion(bad or good) on the issue queue.

Project information