Posted a new article: Authentication Model. Also made some retroactive modifications to take into account new details about DomainConfig::Url.
The next steps are:
- Handling the interruption in the user action created by the login requirements, so that the user activity is resumed after the process.
- Resetting the user password.
- Applying some lipstick to the login page to make it look better, and include some JavaScript.
JITBrain contains 843 lines of PHP so far.
20 config/db.php
48 config/domain.php
17 config/error.php
45 controllers/do-login.php
66 controllers/do-signup.php
3 controllers/index.php
14 controllers/login.php
70 models/authentication.php
77 objects/lazy.php
115 utils/db.php
67 utils/error.php
52 utils/pervasive.php
27 utils/redirect.php
40 utils/request.php
40 utils/session.php
67 views/loginpage.php
17 views/plainpage.php
58 views/twocolform.php
843 total
Hi. I'm Victor Nicollet,
I’ve read through what you’ve written so far, and I’m curious as to why you’ve chosen to use static classes for the majority of the classes you are using, rather than creating new instances of the classes when you need it. I can see it would be easier to create as you don’t have to worry about passing instances of classes around everywhere, but that’s the only benefit I can see.
I’m still learning to use OO techniques in PHP (and C++) but from I’ve read, people prefer to create new instances, rather than using static classes (because they’re similar to Singletons?).
There are three important things to be told here.
First, 99% of the code in JITBrain so far is not object-oriented. A vast majority is pure functional code (or damn close to it). Then, you have some procedural code (the controllers, mostly), and you have some object-oriented code in the form of LazyObj, which is an object implementation of functional concepts that are not native to PHP. The use of classes is merely a trick to accomodate autoloading, but my use of them is closer to C++ namespaces and Objective Caml modules than to actual classes, and if there was an autoloading mechanism for functions inside namespaces (or namespaces) then I would have used that instead to remove confusion.
Second, 75% of the code in JITBrain so far would gain absolutely nothing from being object-oriented. The core of object-oriented programming is to bind together data (as the object state) and behavior. However, since the vast majority of what JITBrain does (configure PHP settings, compute strings, and so on) is related to behavior more than data, and handles vast amounts of trivial data (strings and arrays thereof), so there would not be many benefits to object implementation. Sure, some complex aggregates (such as those used as arguments for LoginPageView) could be reimplemented as arrays, but they don’t have an actual behavior of their own, and are merely representations of the data that is displayed by the view: they may be complex, but they’re still aggregates.
Third, using instances as a replacement for static classes is somewhere between stupid and insane. A static class, almost by definition, has no state (and that is the case for almost all of them in my example, with the only state being private memoization support), which means it is perfectly useless to use instances here. Having two instances is not different from having one instance, so that’s not a benefit. Polymorphism could be a benefit, except that all needs for polymorphism have already been implemented in an object-oriented fashion (see the LazyObj $content argument in PlainPageView::Render for an example). If anything, a proper object-oriented refactoring would take function StaticClass::Frobnicate($data) and turn it into $data -> Frobnicate(), not $singleton -> Frobnicate($data). Except that since most of these functions take string arguments, it would be pretty pointless.
This is just a re-discovery of a classic C++ observation: non-member functions (in this case, static class functions) improve encapsulation instead of reducing it.
Thank you for your comments!
Thanks for replying, that clears things up for me
Where would you see object-oriented programming being a benefit in PHP programs/scripts? PHP is mainly used to process websites, and websites don’t have a state (at least not during the processing of any input data).
As soon as you stop manipulating simple data types (strings, arrays, hashes, scalars) object-oriented programming becomes interesting: you have data types which have a non-aggregate state, and the optimal solution for representing such state constraints is to use an object.
Additionally, theres the code/configuration duality. Consider an algorithm that proceses data, where the processing consists of sub-routines that can be rearranged at will (one example is, precisely, examining the data that returns from a form postback and checking it for validity). Youhave two ways of doing that: the first is to turn the sub-routines into functions that operate on the data (which means making the data an object if its state is complex enough), or to create a configuration system that lets you specify what processing should happen as a plain data object.
In functional programming, functions being first-class citizens mean the two are equivalent (code that manipulates data IS a configuration object), but in object-oriented programming they are not. Programmers not familiar with functional programming may choose to turn the processed data into an object (think “request object”) and call its functions, instead of setting up processing configurations.