Philosophy
Usefulness, simplicity, and strong design are the three words that make up the core of Alloy's design philosophy. Above all else, code within Alloy must be useful, it must be simple both to use and understand, and it must be well designed and follow coding standards.
Alloy is about capturing the essence of PHP's simplicity and pragmatism with a more well designed and well structured toolset. Alloy exists for you to get more work done as quickly as possible, and to stay out of your way. The mantra of Alloy is users over correctness. Code should be designed for users first, computers and purists second. PHP is not Java with dollar signs. Alloy attempts to strike a balance between well-structured and well designed object-oriented code that adheres to the best programming practices and making the code truly simple and enjoyable for programmers who use it on a daily basis. This means that in some cases where appropriate, code in Alloy will intentionally bend the rules of a design pattern and step on the toes of an object-oriented purist or two to better suit the needs of its users.
Guiding Principles
-
Usefulness
All new code and features added to Alloy must be useful to the 80%. This rule exists primarily to combat any potential onslaught of feature bloat. Alloy is not a component library for everything - there are other libraries and framework projects that serve that purpose, and you can easily use them where needed within your Alloy project.
-
Simplicity
Code and libraries distributed with Alloy must be simple both to use and to understand. Code should not feel over-designed, cumbersome or clunky. Code should not require a lot of setup or boilerplate to use. Thoughtful conventions and helpers should be available where needed to reduce the distance between a developer's problem and their potential solution.
-
Strong Design
There is no excuse for sloppy programming. All code should follow known coding standards and should be developed to the highest E_STRICT error reporting level available. All bundled code libraries should be unit tested with PHPUnit to ensure quality and completeness.
On Design Patterns
Design patterns are useful, but they should never trump user experience or visibly get in the way. One of Alloy's main goals is strong design and good architecture, but never where it crosses the line into hindering or confusing users. You won't have to work with obtusely named "unitOfWork" or "Repository" objects within Alloy, even though those design patterns may be present.
