Vedo spesso in giro programmatori e appassionati che si sbattono per cercare di entrare in un'ottica di programmazione a classi, dopo esser sempre stati fedeli ad un approccio più procedurale. In particolare lo vivono come una sorta di "passaggio ad un livello superiore", come se fosse una tappa obbligata del percorso professionale di un programmatore.

Niente di più sbagliato. Cercate di non sforzare mai un approccio a classi all'interno di un applicativo che non "sentite" destinato a quel tipo di sviluppo, perché peggiorereste solo le cose. Innanzi tutto perdereste tantissimo tempo nel cercare di entare in un'ottica che, evidentemente, ancora non vi appartiene del tutto. In secondo luogo doterete il programma di una complessità che probabilmente non è necessaria. In definitiva non forzate troppo la mano. Se in fase di progettazione il tipo di applicativo che dovete sviluppare necessita di una più profonda e vasta organizzazione, e quindi può trarre grande vantaggio dalle classi, state certi che lo avvertirete in modo netto e preciso. Altrimenti continuate pure tranquillamente a programmare nel classico modo procedurale, non c'è nulla di male o "dilettantesco". Il tutto cercando però di delineare blocchi specifici di codice o funzioni in modo da non ritrovarvi con un unico immenso listato difficile da leggere e interpretare.

Un'ottima via di mezzo, che per esempio utilizzo anche io in un certo tipo di applicativo multifunzionale, è quello di programmare la struttura esterna (l'involucro) tramite le classi, e le procedure relative alle varie funzioni in gran parte in modo procedurale. In questo modo avrete uno scheletro flessibile e profondamente particolareggiato, e allo stesso tempo potrete arricchire l'intero applicativo a seconda delle specifiche esigenze che vi si presenteranno, perché i moduli relativi alle singole funzioni sono indipendenti.