{"id":230382,"date":"2022-11-20T17:28:00","date_gmt":"2022-11-20T14:28:00","guid":{"rendered":"https:\/\/wordpress.mediadoma.com\/?p=230382"},"modified":"2022-11-20T17:31:32","modified_gmt":"2022-11-20T14:31:32","slug":"i-primi-due-pilastri-di-oop","status":"publish","type":"post","link":"https:\/\/wordpress.mediadoma.com\/it\/i-primi-due-pilastri-di-oop\/","title":{"rendered":"I primi due pilastri di OOP"},"content":{"rendered":"\n

Quando si tratta di parlare di programmazione orientata agli oggetti (o OOP), \u00e8 probabile che tu senta parlare dei tre pilastri della programmazione orientata agli oggetti o dei quattro pilastri della programmazione orientata agli oggetti.<\/p>\n

A seconda del tuo background, potresti averne gi\u00e0 sentito parlare, sapere cosa sono e non hai davvero bisogno di immergerti troppo. Ma se non l’hai fatto, credo che capirli sia fondamentale per la programmazione orientata agli oggetti.<\/p>\n

Abbiamo coperto l’intera fase di analisi<\/a><\/strong> della programmazione orientata agli oggetti:<\/p>\n

    \n
  1. Analisi, parte 1<\/a><\/li>\n
  2. Analisi, parte 2<\/a><\/li>\n
  3. Comprendere le aspettative dei clienti<\/a><\/li>\n
  4. Dichiarazione di lavoro<\/a><\/li>\n
  5. Termini e Condizioni<\/a><\/li>\n<\/ol>\n

    Detto questo, entriamo nelle discussioni di progettazione e implementazione. Dopotutto, questo \u00e8 ci\u00f2 a cui molte persone vogliono saltare comunque, vero?<\/p>\n

    \"I<\/a><\/p>\n

    Prima di scrivere qualsiasi codice, vorrei fare due post sui quattro punti della programmazione orientata agli oggetti (perch\u00e9 sono uno di quelli che aderisce all’idea che ce ne siano quattro).<\/p>\n

    Due pilastri dell’OOP<\/h2>\n

    Ancora una volta, comprenderli \u00e8 la chiave per comprendere le basi della programmazione orientata agli oggetti. Senza di loro, sar\u00e0 difficile navigare nel resto di ci\u00f2 che verr\u00e0 discusso nei post futuri.<\/p>\n

    Detto questo, parliamo di ciascuno di essi. Tratteremo i primi due in questo post e gli ultimi due nel prossimo post.<\/p>\n

    1 Astrazione<\/h3>\n

    In generale, questa \u00e8 la chiave per scrivere codice orientato agli oggetti. Con ci\u00f2, intendo tutto ci\u00f2 che \u00e8 contenuto all’interno di una classe. Astraiamo l’idea di qualcosa in una classe. In molti libri vedremo cose come Animali<\/strong> o Macchine<\/strong> rappresentate come classi.<\/p>\n

    Funziona, in teoria, ma in pratica, non stiamo programmando animali n\u00e9 stiamo programmando automobili (anche se immagino che a questo punto della storia, potresti sostenere che lo siamo, ma sto divagando perch\u00e9 sai cosa intendo).<\/p>\n

    Invece, astrarremo le idee nelle loro classi. E qui c’\u00e8 un’idea chiave:<\/p>\n

    \n

    Una classe dovrebbe rappresentare un sostantivo.<\/p>\n<\/blockquote>\n

    Cio\u00e8, non dovresti avere una classe che rappresenti qualcosa come "Running". Invece, potresti avere qualcosa che funziona e, quindi, le corse<\/strong> sarebbero un metodo. E questa \u00e8 la ripartizione generale di come funziona l’astrazione:<\/p>\n

      \n
    1. La cosa che deve essere rappresentata \u00e8 la classe,<\/li>\n
    2. Le cose che fa la cosa sono i suoi metodi,<\/li>\n
    3. E il modo in cui descrivi la cosa di solito pu\u00f2 essere fatto tramite i suoi attributi o propriet\u00e0.<\/li>\n<\/ol>\n

      Questo non significa che non abbiamo funzioni o metodi che ne modifichino le propriet\u00e0, ma i tre punti precedenti sono buone regole pratiche. Quindi, quando stai progettando una classe, puoi chiedere cose come:<\/p>\n