Why does this question still come up: How Many Classes Per Business Object?
I get nauseous every time I see this question asked. I wholly believe this question exists only to start infighting amongst the development community and attract the numerous comments to the post that is assured. All the while, the poster sits back with lotion and Kelnex and smiles while the chaos unfolds around them.
I come to classify the commentors to these posts into 3 categories:
First and foremost, you have the OO purists. These are the people that use OO to the extreme. DAO, BO, IOC and any other acronym you can throw out there, they’re using it and loving it. The more abstraction and configuration, the better. They will claim that it makes developing applications faster and easy to maintain and cut down anyone that saids otherwise. If they had it there way, they would have 30 different classes per business object each containing one method. Their mortal enemy is anyone still believing and writing procedural programs.
Our next category and mortal enemy of everything OO; is the procedural programmer. They’re the ones still hanging on to the days when cfincludes and custom tags flourished in applications. Who needs CFCs when a group of functions inside a cfinclude will do just fine. Don’t tell them about design patterns or code organization, they know it all too well. If they could, they would go back in time and kill the person that mentioned cfcomponent in that one board meeting. To them OO is evil and so are the people using it.
The final category is the one that I fall into: the who gives a shit and flying fuck category. Program the way you want to program and quit telling us that we’re doing it right or wrong. We don’t want nor care how you program or the philosophy that you follow. To us, both of the other two categories need to just shut the fuck up altogether.