To the original poster, the answer to "should I use classes?" A few and don't overdo it without advice. OO is hard and you will spend a year digging yourself a deep hole before you learn to dig yourself out.
I tend to avoid this type of thread these days, but I couldn't resist commenting on this one. Forum discussions are never 100% precise in the lawyer sense and once the temperature rises, well every word gets poured over. I am sure i am going to say some things that are both imprecise and contentious. I may have to backtrack here and there, but what the hell. Asbestos undies at the ready...BDKR wrote:If it were the case that
OOP is good for everything and the only possible route to success then MySQL, Postgres, Linux, Windows, Solaris, Apache, PHP, Python, the Half Life 2 engine, the Quake engines, fuel injection control code, and even drivers would be written using actual objects.
Firstly minor point. I don't have access to the Windows source code, but I am reliably informed that since the NT code base took over, everything above the HAL is C++. The Solaris source has just been released, but I couldn't find anything on the Sun site that gave me easy access to it. Python is written mostly in Python and has a small core. Apache is built around dynamic modules that are actually quite small and have a much more sophisticated dispatch mechanism in Apache 2. BMW at least uses Java in it's engine management code (I think they wrote the java CAN stuff). The Quake I engine (haven't looked at the others) uses a whole language layer (a C like language) on top of the core code. That core is actually suprisingly object based.
The other apps. I have not looked at and don't have time right now
Now I am not going to say that every domain is best solved with OO, but I will say (here is the contentious bit) that in each domain there is a better paradigm than procedural. By "better" I mean more maintainable by the way, as this is the part that deals with the economics of software. Open source stuff does not always follow economics, but that's another story
Within the enterprise software domain (big web sites and stuff) the dominant paradigms are OO and relational (data mining). Regarding application delivery, OO dominates hands down. Do a web search for consultants that have Fortune 500 companies as their clients and you'll see what I mean. Reading the Thoughtworks blogs gives a pretty clear idea too. OK, this is just proof by association, so I am only one step up from repeated assertion.
Time to resort to code (hooray
Code: Select all
class CallMetered extends ApiChargingModel {
function CallMetered(&$account) { ... }
function payForCall($function, $results, $searches) {
$template = &$this->_account->getPaymentTemplate();
$currency = &$template->getCurrency();
$cost = $template->getCost();
$this->_account->deduct(new $currency($cost));
}
function paySubscriptionCost($now) {
}
}The flex points involved in this are the account, the payment model for that account, the currency, the function called, the amount of results, a monthly or other subscription or surcharge, a banded payment, the success or otherwise of the call, the transport protocol and the means of payment (in advance, in arrears, immediately). We can keep this code clean and separated because so much is polymorphic. Dollars look like UkPounds, CallMetered looks like MonthlySubscription, ThesaurusService looks like AdultFilterService and XmlrpcServer looks like RestServer. Robbed of polymorphism this would be a nightmare, so hard to maintain that it would be impossible for practical purposes. OO is forced here.
But why not functional programming? After all it works for Google's mapping thingy. Well that involves a mental translation, one so complicated that I just don't know how to do it in this case. The functions have to dance around the data like a choreographed ballet. Business almost always focuses on behaviour and really doesn't care about data too much except for the final bank balance and as stuff that gets passed around. Objects allow us to hide data like no other paradigm. It allows us to bundle behaviour into named entities. This is a good fit for business modelling.
Why not relational? Relational is great for fixed tasks on complex data, but doesn't do so well if the data changes the structure of the processing. You would have to come up with a datamodel that captured every type of charging inone schema. A schema that would then be terribly sensitive to change and anightmare to understand. Relational doesn't do encapsulation very well. At least not yet. Relational theory had types in, but that's a whole other debate.
Business also changes a lot. Someone said in this thread that you had to design thoroughly if you were using OO? The opposite is the case. You can change things around much easier with OO, to the point you can actually put the design in after you start coding. Agile development is built around this principle.
The problems with OO? LIke any powerful paradigm it takes some learning. You wouldn't be a data modeller after only a year. You wouldn't be able to use a functional language to full effect without a university course and a fair understanding of mathematics.
Rasmus is a lone voice and now works for Oracle. He proposes putting all of the business logic into the database and having PHP as a thing templating system. Well that's probably a good thing for Oracle. Unfortunately only a small proportion of my code deals with a database, so that's no use to me, and I have to build something rather more complicated than a template layer. I think Rasmus is out of touch with the enterprise end of the PHP market.
I think the procedural option is a good thing for PHP because it opens it up to a wider audience. No use to me though. I no longer doing projects where it's viable.
yours, Marcus