Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Code design

Name: Anonymous 2012-07-26 12:21

I'm trying to make better structured code, and I have this sort of love hate relationship with OO. Well mostly hate, but it's what I know so it's also what I use.

There's one problem I'm always coming back to and I've yet to solve; Is it ok to use classes to lump code? I know a hardcore old-schooler would scream no, but does it in any way hurt? Say I have this small operation which requires a state but I really don't want to pass it around as data and I shouldn't have more than one of it, do I make it a class or a module or whatever you'd call it?

Somehow it feels better to make it an object, perhaps mostly because again, it's what I'm used to. If the tiny system requires dynamic data, I can blame not deleting the object rather than not shutting down the system. If it's all static, then I still get the feeling that "here it is, right here!", if you know what I mean.. Actually if I make all the member variables and methods static, is there really any difference at all? So if it's not static, is there any difference other than that the state will be lumped as an object on the heap instead?

At the same time it hurts to think that there's an object out there.. which is simply not an object at all.

Name: Anonymous 2012-07-26 20:54

OOP has little to offer outside GUI programming. I've seen perfectly good procedural code turned into absolute nightmare in an attempt to move towards OOP. It doesn't help that everyone's OOP concepts and implementations differ greatly. If you ask two developers on how to best tackle a problem using OOP, you'd get three different answers. The problem stems from OOP's proponents insistence on objectifying anything and everything. You will then end up with a kingdom-of-noun code base.

The truth of the matter is, business layers are made out of business rules and these rules can be perfectly modeled using functions, modules and basic data structures. There is absolutely no reason to use objects. In fact, it is counter-productive to express these rules and constraints using classes and objects. If you insist on using them, you will spend a lot of time just thinking about what to name your classes, what responsibilities they ought to have, what mechanism do they use to interact with each other and so on and so forth instead of just making a function/procedure and get it over with. You will then begin a slow but sure path to depression, fighting and cursing your tools instead of working with it. I could give you examples if you're interested.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List