Classes and OO

I'm not the greatest programmer ever, I'll brute force if I have to, and any professional programmer would probably cringe in horror at some of my code.  Just a small disclaimer.  I'm currently using a Java derivative language (Processing), and hence Object Oriented.  My question is, is there some kind of guideline for when a new class is or isn't a good idea? How do you know when you're over or underusing classes vs. new methods.

Switch to C.

years of experience, programming is all ad-hoc made up on the spot nonsense. no one know what they are doing

>>3
kinda.
there's a lot of well understood philosophic bullshite i.e. design patterns
but career programmers are totally ignorant of it.

The programming code is code that is efficient art.

The best*

>>1
most people don't know. just use common sense. the only good advice I guess I can give is, if you have a set of classes whose behaviour depends too much on the behaviour of the other classes, you're doing it wrong. For example, most stuff like this:

objectA.propertyB.methodC()

is wrong. Why? because propertyB is also an object, and maybe someday objectA will stop having propertyB. Yes, I know this sounds a bit too much like "enterprise scalabe programming", but actually it's not, it's about proper abstraction (SICP). So instead just write something like
methodD() {self.propertyB.methodC }

and then write

objectA.methodD()

You'll notice when following this guideline, it's easier to break down classes into two or adding up classes if needed.

OP here, thankyou for the replies so far.  It's nice to be reassured that I'm not a complete dumbarse for not being 100% certain on this subject.

>>8
You are a complete dumbarse

>>1
You need to implement X, and don't know if it should be a method or a class with a method? Simple thing to decide:
- Theory POV: does X correspond to a new entity in your problem, like "Person-Move" (need new class Person), or is it related to existing entities (class Person already exists), or perhaps it's not related to any particular entity (for which there's no solution in Java, but you can toss it into any misc class).
- Practical POV: does X need to hold information related to other methods you don't want to pass in and out of it all the time, right now or in the foreseeable future?

>>7
You're doing it wrong. Or at least, your language is doing it wrong. Ever heard of properties? Don't clutter and shitten the interface with shit like getBullshit(), setBullshit(lol), etc. just because it's a business enterprise best-practice. This is fuck ugly. With a decent language, you should be able to define simple properties that can be accessed as is (e.g. .prop) and act as lvalues (e.g. .prop += ...), yet these operations can actually correspond to methods should you need so. Or perhaps you could make it an object of a certain class which overrides some operators. Just don't jump in the getShit() bandwagon because it's a best-practices enterprise busines solution that creates synergy and maximizes profits.

>10

That was pretty much my understanding of it.  Unfortunately when it comes to pre-structuring code, I'm not great.  I should explain what I'm essentially programming is one big genetic algorithm.  At first I thought that it would be a good idea to have a population class, a genome class, and a gene class.  Unfortunately, when it comes to prestructuring code and information flow, i am not terribly good, so I went with the simplest possible solution in order to get it working.  And up til now I've just been using arrays, the GA works, and everything is fine. But lack of foresight means I've realised that each gene will need to be more complex than the 1 int per gene I've been using before, and other values will have to be associated with them.  My first thought is to use yet another array, but... surely I can't just keep using arrays forever.  On the other hand, the other solution sounds like a complete code restructure... which... is not an ideal solution either right now. 

Thoughts?

Classes are never a good idea, unless they're type classes.

COUPLING MOTHERFUCKER, DO YOU REDUCE IT?

Gah, that explicit set/get crap is what put me off Java. So much noise code to do so little.

>>11
surely I can't just keep using arrays forever
A common misconception. You can; as a matter of fact it's far more useful to have 10 data types with 100 functions to do useful things with each, than to have 100 data types with 10 functions to do useful things with each. The more arrays you use, the richier your array library (both built-in and application-specific) becomes. And surely a gene is nothing more than a list of one or more pairs of ACGT, which doesn't need to be "passed any message", right?

So don't jump into the enterprise best-practices bandwagon and shoot yourself in the foot by using enterprise scalable stuff when you can work the proper way.

Lists and dictionaries (AKA hash tables) are like violence: if it doesn't work, use more.

>>15
EXPERT '70S MAINFRAME PROGRAMMER?

Should be able to   point me to   look at the   mod rewrite documentation   and trying different   thing mod rewrite   but have been   a part of   our Zen club.

Was reading a SlashDot   article and it   must be some   are but trolls   are not retarded   as some may   consider this a   feature as a   desktop You fail   are are a   number too faggot.