Page 1 of 2
Classes vs. Function Librarys
Posted: Wed Aug 17, 2005 12:47 pm
by jwalsh
Hi All,
A buddy of mine here at work were having a discussion over using function library's or classes for our programaming standards. I'm a big player for using both, depending on the need, but often times I will build my API based primarily around class architecture.
On the other hand, he doesn't use classes for anything, all function librarys. I understand his arguements to a point, but I still think classes create much easier to read code.
Anyone have any thoughts about this, or how I could persuade him to use classes??
Thanks,
Josh
Posted: Wed Aug 17, 2005 1:10 pm
by feyd
as per ususal, I almost always use Classes. Although I'm not a zealot like some around here, there are certainly places where I find it silly to create a class, since the scope and usage would be quite limited anyways; however they most certainly can be classes.
I will definitely say one thing: "Procedural code is 'teh yuck'" (misspelt on purpose)
Posted: Wed Aug 17, 2005 1:24 pm
by dbevfat
I hope this doesn't turn into another endless OOP vs procedural code debate. With classes, you have encapulation and polymorphism. That, by itself, provided one know what it means (and finds use for it), is the only argument ever needed in that decision

Posted: Wed Aug 17, 2005 1:30 pm
by jwalsh
It's not my intention to start another endless debate. My arguement for classes, if nothing else, is just moving toward the future with OOP. Procedural code is quickly being pushed backward, and things like polymorph and encapsul can't be easily overlooked.
I think part of the problem is laziness. Unwilling to take the time to learn how to do his tasks better. It's one of those "If the car aint broke, don't fix it" even though fixing it now could mean its easier to maintain in the long run....
Josh
Posted: Wed Aug 17, 2005 1:40 pm
by nielsene
There's room for both; and I would be very careful with assigning "lazyness" to procedural programmers
To me, it depends very greatly on the anticipated use of the library.
Is it a framework for building systems? If so I'ld say "classes".
Is it a collection or useful slightly related functions? If so I'd say "function library".
For instance (and this is probably my C background talking), I find working fopen, fwrite, etc much more useful than some File class that wraps them. Ditto for all the string functions (but I do wish PHP were more consistent with its needle/haystack orders). Ditto for most math libraries... I HATE stuff like Math::acos(foo), that feels completely wrong to me.
Now in languages where Strings are a first-class object, my objection to string function libraries goes away, but that's not the case in PHP and while its possible to write your own wrapper for it, its still not a "good" answer as PHP doesn't naturally "think" that way and you constantly be having to convert.
Posted: Wed Aug 17, 2005 1:45 pm
by jwalsh
Thanks everyone for your thoughts.
As you can tell from my first post...
I'm a big player for using both, depending on the need, but often times I will build my API based primarily around class architecture.
... you can tell I have no objection to using function library's. My objection comes with using a mis-mash of function library's where a class would get the job done cleanly. While the library's get the job done, why wouldn't you look towards using a class that's designed specifically for what you need?
BTW: I wasn't calling procedural programmers lazy, I know many very successful procedural programmers who will be around for a long time. I was saying it's "lazy" to purposly build a procedural routine for a project that would be much more efficient as an OOP module.
I mean no offense to any procedural programmers here

Posted: Wed Aug 17, 2005 1:58 pm
by nielsene
Sure, I too, prefer classes, when they make sense (which is a growing percent of the time for me).
But you have to look at how you anticipate the functions/methods being used :
Questions to ask yourself:
1. Is this a collection of static methods? If so why are you bothering with a class? Namespace issues only?
2. What is the calling convention of these methods in the class? If its
Code: Select all
// Either
$foo= new Foo();
$baz = $foo->bar($qux);
// Or
$foo = new Foo();
$foo->setQux($qux);
$baz = $foo->bar();
and foo isn't used again, perhaps you're forcing a class where it doesn't belong and just creating a more awkward way of invoking your method. (This is one of my biggest pet peeves, but why go through the extra overhead of creating a class just to call a single method -- its even worse than the all statics)
Posted: Wed Aug 17, 2005 2:19 pm
by Roja
I definitely don't have any desire to jump into another flamefest on OOP v. Proc, as I still have the burn marks McGruff left last time.
However, I primarily spend my hobby time working on a 40,000 line codebase (Blacknova Traders) that is almost entirely procedural. Recoding it to be consistent, well-formed, and more secure has taken over three years, and only now are the functions really fitting my definition of a function (defined input, defined processing (with no output), and single defined output).
With that level of legacy, which cannot be thrown out and recoded from scratch (as people are playing it even today), I bring a certain level of skepticism to the "OOP always" discussions.
However, I also work on projects that are extensively OOP (Wordog). So I absolutely know the value and power, and I'm quick to encourage its use "where it makes sense".
So, my response to your question is, it depends on the situation. If you are designing from the ground up, OOP it.
If you are refactoring code that isn't inter-connected and rats-nested to the point where ANY attempt to add objects would break thousands of lines of code, you have a strong argument for refactoring the procedural first - at least to the level where you can make statements about what portions of code do.
(I can say with great humility that there are thousands of lines of code that I cannot honestly give a good description of what some of my code does. General description, sure, but specifics? Its voodoo in there!).
A good example is the
validateemail function from the game. Its a solid function, acting on a single variable, with a defined input, well defined processing rules, and a defined single output. Since the email is a user-submitted item, that is being validated *before* placing into any other context (user object), it makes little sense for it to be a class.
Now, if the opposite were true, and I had a user object already, and the email was already in that object, and I wanted to perform an action on that object? A class would absolutely be the right thing, and a function would be lazy programming.
It all depends on the situation.
Re: Classes vs. Function Librarys
Posted: Wed Aug 17, 2005 6:05 pm
by McGruff
jwalsh wrote:Anyone have any thoughts about this, or how I could persuade him to use classes??
Without wishing to offend anyone, in my experience, the more people learn the more enthusiastic they become about OOP - and not just OOP but testing (by testing I mean unit testing, acceptance testing etc for which you'll be using a framework like SimpleTest or phpUnit). Experienced OOP-ists never go back to functions or naive, globally-scoped code unless it's something like a simple shell script. If you've got a hundred lines of code you've almost certainly found enough different responsibilities for a class or two.
OOP is paradoxically hard and simple at the same time. It's simple because, when done right, it brings all the different responsibilities in a script into clear focus. The code will be easier to understand - if you know OOP - and easier to work with. Re-use sometimes happens but that was an early dream for OOP which didn't quite pan out. Clarity and ease of use is quite enough on its own to justify the methodology.
It's hard because you have to become something of a philospher. Objects should be highly cohesive but loosely coupled which is just another way of saying that well-conceived classes should deal with a single responsibility, encapsulating data and the methods which act upon the data. They shouldn't try to do too much - a god class - and they shouldn't be too interested in the properties of other objects. Although they do have to communicate, too many getters and setters can be a smell that you haven't encapsulated well. To create good classes you have to think carefully about the different responsibilities in a script. It's a kind of semantic engineering: is foo a bar or is it just used by bar?
For example, in Roja's email function, there's a line to strip slashes added by magic quotes. I'd see this as an input filter and as such something extraneous to an email validation rule. On planet gruff the rule would be an object, sets of rules would be combined into a Specification, and an email parameter would be validated against the specification (yet more classes). Input filters would be applied elsewhere, and the validation code wouldn't need to deal with that.
Input filters (and some validation rules) are context-specific: if, for argument's sake, you wanted to run the app from the command line you wouldn't need to for check magic quotes. I certainly don't mean to pick holes in Roja's code - I'm sure it does exactly what it needs to do - I'm just using this as an example to illustrate the kind of things an OOP-ist would be thinking about when analysing code. It all starts with the standard presentation / domain / data access layering, and proceeds from there, breaking things down into discrete responsilbilities.
Experienced OOP programmers don't always produce perfect code. Agile methods and test-drive-design emphasise doing only what you have to do to get a test to pass (such as "spaces and non-alphanumeric chars are word boundaries"). It's assumed there will be a fair amount of refactoring later perhaps to add new features or simply to tidy up the design as you learn more about it.
Incidentally, test-driven design, refactoring, regression testing and continuous integration are all powerful arguments for the combination of OOP and testing.
So, how to persuade your colleague? You probably can't. He or she will have to make a leap of faith. It takes a year or two to begin to understand all this stuff and longer to become expert. It's perfectly possible to write functional applications without it but if you want to become the best programmer you can be, this is the way to go.
Posted: Wed Aug 17, 2005 6:15 pm
by patrikG
I generally prefer OOP over function libraries due to flexibility and clarity. But here's another "real world" case:
Long version:
A client of mine approached me some time ago because he wanted this website extended in functionality (shop, event-manager, proper CMS, user-management etc.) I usually jump in and say "classes!", but then I saw the code: "talking pages" instead of an application - everything entirely created in Dreamweaver. Everything lumped together, business logic (including tons of SQL-queries), templating, plain HTML, some weird includes that were utterly pointless, lots of useless and redundant code and that on every single one of those couple of hundred pages. As if someone had rolled an armadillo over the keyboard.
That is the worst definition of "procedural" to my mind. While some function libraries existed, there was no cohesion, no coherence (I even had to redesign about a third of the tables in the database). Given the limited budget of my client plus a strict timeframe, I did use classes but was forced to compromise on a number of issues (sessions especially) simply because the code I created had to seamlessly fit into what existed already. I am no purist, but with code like that (and a database like the mess it was), the deadline and the limit budget you do what works. I did feel a bit like a programmer working on Netscape 4.7.
As long as there is a well thought out API, I can live with either function or class libraries but prefer the latter. The problems come with the abscence of either.
Short version:
Do what works best for you, but think about it first.
Re: Classes vs. Function Librarys
Posted: Wed Aug 17, 2005 6:34 pm
by dbevfat
Well put, McGruff
Posted: Wed Aug 17, 2005 7:58 pm
by Roja
Fairly offtopic..
McGruff: Thanks. You were 100% on the money. Not only did that not belong in that function, it also didn't belong in the game - we already do a full cleaning of all variables for magic_quotes issues.
It's been removed, and our code is better thanks to your feedback. As to the point about running it on a CLI, its a web-based game. It doesn't get run on the CLI.
I still feel the function proves my point: There was little to gain from OOP for it as an example. As McGruff said, it does what it is supposed to do.
Of course, I think the OP's question "how I could persuade him to use classes" shows that this wasn't going to be a balanced conversation.
Thankfully, we've all answered it basically the same: It depends on the situation, and if its the right situation for OOP, you can't really convince them - they have to choose to do it based on the value for them, which may be substantial, or minor.
Posted: Thu Aug 18, 2005 11:39 am
by BDKR
There have been some great posts in this thread. Mine won't be as good but here goes.
To echo everyone else, it depends on what's needed.
However, any developer should learn as much as they can to avoid being a one trick pony. Hopefully this freind at work will get beyond his
ideas about OO and learn it.
My personal feeling is that the single most important aspect of OO can have a dramatic effect on your procedural coding as well. Design. Through OOD we begin to (first) conceptualize code in a much more abstract manner then we were used to from a purely procedural
viewpoint.
Another very important point that purely procedural coders need to realize is that systems and applications ARE NOT getting simpler. The primary reasons for the direction of language development that lead to OOP were dealing with complexity and issues surrounding teams of developers working on the same code base. As we move forward into ever more complex or feature rich applications, controllers, etc,... it becomes imperative that the developers view of the world becomes more OO.
However, procedural isn't going to go away ever. But it's use in application development will fade, and it prolly should.
Posted: Thu Aug 18, 2005 5:01 pm
by jwalsh
Thanks everyone for your thoughts. You've confirmed everythign I use in my coding practices, and made me stop second-guessing myself in many regards.
Josh
Posted: Fri Aug 19, 2005 3:06 pm
by protokol
nielsene wrote:There's room for both; and I would be very careful with assigning "lazyness" to procedural programmers
Is it a framework for building systems? If so I'ld say "classes".
Is it a collection or useful slightly related functions? If so I'd say "function library".
I feel that even with the second statement about functions, you should still use classes. For example, if you need slightly related functions as a library, then create a static class with the functions as methods of that class.
Code: Select all
class Tools
{
function f()
{
}
function g()
{
}
}
This way you can encapsulate your methods in a clean way. Then you just call them statically: