Ho appena finito di leggere il post di Pierre e relativi commenti sul fatto che un metodo privato sia comunque accessibile dall'esterno. Io mi trovo d'accordo con quello che dice Corrado, sì per i controlli dei parametri e sì che è a rischio e pericolo del programmatore smanettare con l'interfaccia privata ma vorrei provare ad aggiungere una cosa: la differenza tra privato e privato forzato.
Uno dei linguaggi object oriented per eccellenza è Smalltalk (che per inciso è dinamico e *vivo*). Smalltalk non ha il concetto di private vs public, o meglio, non lo ha alla maniera di C++, Java, C# e tutti i linguaggi di questa famiglia (VB.NET compreso, che in fondo è molto più simile a C# di quanto si creda secondo me). In Smalltalk il tutto si basa sul buon senso e sulle convenzioni. Se io marco un metodo come privato è ovvio che non faccia parte della interfaccia e magari non lo documento nemmeno. Se poi tu programmatore vuoi usarlo sono cavoli tuoi e sai _benissimo_ che io posso farlo sparire alla seconda release.
Il vantaggio di questo approccio è che se una classe è programmata male (ricordo di roba "sealed" per errore nelle prime versioni di .NET) io posso comunque girare intorno al problema senza dover aspettare una patch fino alla prossima release della libreria o di quello che sto usando
Python usa questa convenzione senza alcun problema da 10 anni e passa. Un attributo o metodo privato viene marcato con "_nome" (notare l'underscore davanti). Ciò per qualsiasi Pythonista vivente significa: quello è privato, usalo se devi ma sappi che non è parte dell'interfaccia (oltre a quello che ovviamente viene esplicitato nella documentazione). Esiste un blando modo per forzare la privateness (che poi è più che altro una convenzione interna per motivi che non sto qui a spiegare che per "legare le braccia" il programmatore) che è quello di usare "__nome" (doppio underscore). Questo impedisce all'utente di fare "classe.__nome" per accedervi ma è sempre possibile accedervi tramite una semplicissima regola di name mangling o tramite "reflection" per usare un termine "dotnettaro".
Questo perché Smalltalk, Python e altri linguaggi usano una filosofia diametralmente opposta di quella di Java e C# che è quella di non legare le mani al programmatore, limitare il numero di keyword (e combinazioni delle stesse). Questo non significa che leda i principi dell'OOP, anzi, la differenza sta nel *forzare* o nel *comunicare*. Python comunica qual è l'interfaccia, C# forza. Differenza tra safety vs freedom languages, appunto. Vi invito a leggere quell'articolo, sicuramente alla fine sarete comunque della vostra idea, ma almeno avrete compreso almeno in parte il mio punto di vista.