I always view it on two levels:

• I make sure my methods only do one thing and do it well
• I see a class as a logical (OO) grouping of those methods that represents one thing well

So something like a domain object called Dog:

Dog is my class but Dogs can do many things! I might have methods such as walk(), run() and biteDotNetDeveloper() (sorry couldn't resist ;p).

If Dog becomes to unwieldy then I'd think about how groups of those methods can be modeled together in another class, such as a Movement class, which could contain my walk() and run() methods.

There's no hard and fast rule, your OO design will evolve over time. I try to go for a clear cut interface/public API as well as simple methods that do one thing and one thing well.

I always view it on two levels:

• I make sure my methods only do one thing and do it well
• I see a class as a logical (OO) grouping of those methods that represents one thing well

So something like a domain object called Dog:

Dog is my class but Dogs can do many things! I might have methods such as walk(), run() and bite(DotNetDeveloper spawnOfBill) (sorry couldn't resist ;p).

If Dog becomes to unwieldy then I'd think about how groups of those methods can be modeled together in another class, such as a Movement class, which could contain my walk() and run() methods.

There's no hard and fast rule, your OO design will evolve over time. I try to go for a clear cut interface/public API as well as simple methods that do one thing and one thing well.