> For the complete documentation index, see [llms.txt](https://mirkorap16.gitbook.io/clean-architecture/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mirkorap16.gitbook.io/clean-architecture/politiche-e-livelli.md). # Politiche e livelli > Un programma è una descrizione dettagliata delle politiche attraverso le quali gli input vengono trasformati in output. Sviluppare un'architettura software significa imparare a separare le politiche l'una dall'altra. Le politiche che cambiano per gli stessi motivi e contemporaneamente, si trovano allo stesso livello e, pertanto, dovrebbero appartenere allo stesso componente. Le politiche che cambiano per motivi o in momenti differenti, si trovano a livelli differenti e, pertanto, dovrebbero trovarsi in componenti separati. ### Livello Se volessimo dare una definizione di livello potremmo dire che esso è **la distanza dagli input e dagli output**. Più lontana è una politica dagli input e dagli output del sistema, maggiore è il suo livello. Le politiche più vicine agli input e agli output sono quelle di livello più basso. Guardate lo schema seguente, il quale rappresenta un semplice programma di crittografia che legge dei caratteri da un device di input, li traduce e poi scrive i caratteri tradotti su un device di output: ![](/files/-M-LqJgAHTEX2oXCMqZJ) Il componente *Translate* è quello di livello più elevato, perché è più lontano dagli input e dagli output. Notate anche come le dipendenze, rappresentate dalle frecce tratteggiate, puntano in una direzione differente rispetto al flusso di controllo. Se volessimo rappresentare sotto forma di diagramma UML il grafico precedente, avremo qualcosa di questo tipo: ![](/files/-M-LriN4t48frWx9JbtP) Il componente tratteggiato è composto dalla classe *Encrypt* e dalle interfacce *CharReader* e *CharWriter*. Le classi *ConsoleReader* e *ConsoleWriter* si trovano ad un livello inferiore, perché sono più vicine agli input e agli output. Questa suddivisione delle politiche ci consente di apportare modifiche ai device di input e output senza influenzare la politica di crittografia. Sarà molto più probabile che cambi il device di input/output rispetto all'algoritmo di crittografia. Le politiche di alto livello, infatti, tendono a cambiare meno frequentemente e per motivi più importanti rispetto alle politiche di basso livello. ### Conclusioni Da questo semplice esempio abbiamo visto l'applicazione dei principi: SRP, OCP, CCP, DIP, SDP e SAP. Osservate bene l'esempio e cercate di identificare dove e perché è stato utilizzato ognuno di questi principi. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://mirkorap16.gitbook.io/clean-architecture/politiche-e-livelli.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.