Classes are the design-time version of instanciated Objects, which are active at run-time. Objects, are like little minature software programs, inside of a lar

Classes are the design-time version of instanciated Objects, which are active at run-time. Objects, are like little minature software programs, inside of a larger programs. Think fractals, that is, smaller things inside of larger ones... So why have a minature software program inside of a bigger one? The short answer is boundaries. If the larger program is permitted to modify the internal state of an object, then that's really no different than having one big program where all of the variables are global, and any line of code can make any change to any variable at any time. Is that OK? For small programs it is, but the larger the program, and the more programmers that work on it, the more it must be segmented into boundaries, and these boundaries enforced (aka, encapsulation) in order to prevent bugs. That, and the ability to divide code into logical groups which can be individually tested will yield a great deal of clarity and information about a codebase, when done by a competent programmer or programming team. At 100,000+ lines of code (and sometimes a lot less), you will trip over your own code unless you segregate it into seperately manageable sub-systems with clearly defined boundaries. "Divide and conquer" as the old saying goes. On the other hand, programmers inexperienced with Object-Oriented development can make code more obscure, unreadable, and harder to work with... It's a double-edged sword... Use wisely.