Objectify: A Better Way to Build Rails Applications
For almost 6 years, the dominant"best practice" for building rails applications has beenskinny controller, fat model. In other words, put all ofyour business logic in to your models — keeping it out of your controllers. Theresult is typically a small number of bloated objects that are impossible toreason about or test in isolation [1].
That property is important. To understandwhy, let's take a quick and highly selective look at the origins of objectoriented programming.
OnEncapsulation
One of the early papers that emphasizedthe importance of encapsulation in software development was James H. MorrisJr.'s Protection inProgramming Languages. He argued that if we were going to beable to write correct software, “programs” (probably most analogous to objectsin the OOP world) needed “protection” from each other.
...hostilityis not a necessary precondition for catastrophic interference between programs.An undebugged program, coexisting with other programs, might as well beregarded as having been written by a malicious enemy—even if all the programshave the same author!
Weoffer the following as a desideratum for a programming system: A programmershould be able to prove that his programs have various properties and do notmalfunction, solely on the basis of what he can see from his private balliwick.
The idea is that if we can prove thatcomponents work in isolation, then we have a better chance of having afunctioning system when we assemble them in to a larger whole.
Aside from being central to the thesis ina paper that heavily influenced the development of object oriented programmingitself, it doesn't seem like a stretch to argue that components that areprovably correct in isolation would make a good building block from which tobuild working systems [2].
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/301743/viewspace-731249/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/301743/viewspace-731249/