window.pipedriveLeadboosterConfig = { base: 'leadbooster-chat.pipedrive.com', companyId: 11580370, playbookUuid: '22236db1-6d50-40c4-b48f-8b11262155be', version: 2, } ;(function () { var w = finestra if (w.LeadBooster) { console.warn('LeadBooster esiste già') } else { w.LeadBooster = { q: [], on: function (n, h) { this.q.push({ t: 'o', n: n, h: h }) }, trigger: function (n) { this.q.push({ t: 't', n: n }) }, } } })() AVERE O ESSERE? - The Codest
The Codest
  • Chi siamo
  • Servizi
    • Sviluppo di software
      • Sviluppo Frontend
      • Sviluppo backend
    • Staff Augmentation
      • Sviluppatori Frontend
      • Sviluppatori backend
      • Ingegneri dei dati
      • Ingegneri del cloud
      • Ingegneri QA
      • Altro
    • Consulenza
      • Audit e consulenza
  • Industrie
    • Fintech e banche
    • E-commerce
    • Adtech
    • Tecnologia della salute
    • Produzione
    • Logistica
    • Automotive
    • IOT
  • Valore per
    • CEO
    • CTO
    • Responsabile della consegna
  • Il nostro team
  • Case Studies
  • Sapere come
    • Blog
    • Incontri
    • Webinar
    • Risorse
Carriera Contattate
  • Chi siamo
  • Servizi
    • Sviluppo di software
      • Sviluppo Frontend
      • Sviluppo backend
    • Staff Augmentation
      • Sviluppatori Frontend
      • Sviluppatori backend
      • Ingegneri dei dati
      • Ingegneri del cloud
      • Ingegneri QA
      • Altro
    • Consulenza
      • Audit e consulenza
  • Valore per
    • CEO
    • CTO
    • Responsabile della consegna
  • Il nostro team
  • Case Studies
  • Sapere come
    • Blog
    • Incontri
    • Webinar
    • Risorse
Carriera Contattate
Freccia indietro TORNA INDIETRO
2016-09-10
Sviluppo di software

AVERE O ESSERE?

Katarzyna Jaruga

Durante l'apprendimento della programmazione orientata agli oggetti e dopo aver acquisito le nozioni di base su oggetti, campi e metodi, la maggior parte del tempo viene dedicata all'ereditarietà. Ereditare significa acquisire una parte dell'implementazione da una classe base. È sufficiente creare una sottoclasse di una classe base per ereditare ogni campo e metodo non privato.

Un'auto e un aereo sono veicoli, quindi è ovvio che entrambe queste classi debbano essere espanse dalla loro classe base comune, chiamata Veicolo. Questo è un tipico esempio accademico, ma mentre decidiamo di legare queste classi con la relazione di ereditarietà, dobbiamo essere consapevoli di alcune conseguenze.

Fig. 1 Implementazione della relazione di eredità.

In questo caso, le classi sono strettamente collegate tra loro: ciò significa che le modifiche al comportamento di ogni classe possono essere ottenute apportando modifiche alla classe base. codice. Questo può essere un vantaggio o uno svantaggio: dipende dal tipo di comportamento che ci si aspetta. Se l'ereditarietà viene applicata nel momento sbagliato, il processo di aggiunta di una nuova funzione può incontrare alcune difficoltà di implementazione, perché non si adatta al modello di classe creato. Dovremo scegliere tra la duplicazione del codice e la riorganizzazione del modello, un processo che può richiedere molto tempo. Possiamo definire il codice che esegue la relazione di ereditarietà come "aperto-chiuso": ciò significa che è aperto per le estensioni, ma chiuso per le modifiche. Supponendo che nella classe Veicolo ci sia un funzionamento generale e definito del motore di ogni veicolo, nel momento in cui volessimo aggiungere un modello di veicolo senza motore (ad esempio una bicicletta) alla nostra gerarchia di classi, dovremmo apportare alcune serie modifiche alle nostre classi.

classe Veicolo
  def start_engine
  fine

  def stop_motore
  fine
fine

classe Aereo < Veicolo
  def muovere
    avvia_motore
    ...
    stop_motore
  fine
fine

Composizione

Se siamo interessati solo a una parte del comportamento della classe esistente, una buona alternativa all'ereditarietà è l'uso della composizione. Invece di creare sottoclassi che ereditano tutti i comportamenti (quelli che ci servono e quelli che non ci servono affatto), possiamo isolare le funzioni di cui abbiamo bisogno e dotare i nostri oggetti di riferimenti ad esse. In questo modo, rinunciamo al pensiero che l'oggetto sia un tipo di un oggetto base, a favore dell'affermazione che contiene solo alcune parti delle sue proprietà.

Fig. 2 Utilizzo della composizione

Seguendo questo approccio, possiamo isolare il codice responsabile del funzionamento del motore nella classe autonoma chiamata Motore e fare riferimento ad essa solo nelle classi che rappresentano i veicoli con motore. L'isolamento delle funzioni con l'uso della composizione renderà più semplice la struttura della classe Veicolo e rafforzerà l'incapsulamento delle singole classi. Ora, l'unico modo in cui i veicoli possono avere un effetto sul motore è usare la sua interfaccia pubblica, perché non avranno più informazioni sulla sua implementazione. Inoltre, consentirà di utilizzare diversi tipi di motori in diversi veicoli e persino di scambiarli durante l'esecuzione del programma. Naturalmente, l'uso della composizione non è impeccabile: stiamo creando un insieme di classi non collegate tra loro, che può essere facilmente esteso e aperto alle modifiche. Allo stesso tempo, però, ogni classe è collegata a molte altre e deve avere informazioni sulle loro interfacce.

classe Veicolo
fine

classe Motore
  def inizio
  fine

  def stop
  fine
fine

classe Aereo < Veicolo
  def initialize
    @engine = Engine.new
  fine

  def spostare
    @engine.start
    @engine.stop
  fine

  def change_engine(new_engine)
    @engine = nuovo_motore
  fine
fine

La scelta

Entrambi gli approcci descritti hanno vantaggi e svantaggi, quindi come scegliere tra loro? L'ereditarietà è una specializzazione, quindi è meglio applicarla solo ai problemi in cui esistono relazioni di tipo "is-a", in modo da avere a che fare con la vera gerarchia dei tipi. Poiché l'ereditarietà lega strettamente le classi tra loro, per prima cosa dovremmo sempre considerare se usare la composizione o meno. La composizione dovrebbe essere applicata ai problemi in cui ci sono relazioni di tipo "has-a" - quindi la classe ha molte parti, ma è qualcosa di più di un insieme di classi. Un aereo è composto da parti, ma da solo è qualcosa di più: ha capacità aggiuntive, come il volo. Proseguendo con questo esempio, le singole parti possono essere presenti in diverse varianti specializzate, e allora è un buon momento per usare l'ereditarietà.

L'ereditarietà e la composizione sono solo strumenti che i programmatori hanno a disposizione, quindi scegliere lo strumento giusto per un particolare problema richiede esperienza. Quindi, facciamo pratica e impariamo dai nostri errori 🙂

Articoli correlati

Sviluppo di software

Costruire applicazioni web a prova di futuro: le intuizioni del team di esperti di The Codest

Scoprite come The Codest eccelle nella creazione di applicazioni web scalabili e interattive con tecnologie all'avanguardia, offrendo esperienze utente senza soluzione di continuità su tutte le piattaforme. Scoprite come la nostra esperienza favorisce la trasformazione digitale e il business...

IL CANCRO
Sviluppo di software

Le 10 principali aziende di sviluppo software con sede in Lettonia

Scoprite le migliori aziende di sviluppo software della Lettonia e le loro soluzioni innovative nel nostro ultimo articolo. Scoprite come questi leader tecnologici possono aiutarvi a migliorare la vostra attività.

thecodest
Soluzioni per aziende e scaleup

Essenziali di sviluppo software Java: Guida all'outsourcing di successo

Esplorate questa guida essenziale sullo sviluppo di software Java con successo outsourcing per migliorare l'efficienza, accedere alle competenze e guidare il successo del progetto con The Codest.

thecodest
Sviluppo di software

La guida definitiva all'outsourcing in Polonia

L'aumento di outsourcing in Polonia è guidato dai progressi economici, educativi e tecnologici, che favoriscono la crescita dell'IT e un clima favorevole alle imprese.

IlCodesto
Soluzioni per aziende e scaleup

Guida completa agli strumenti e alle tecniche di audit IT

Gli audit IT garantiscono sistemi sicuri, efficienti e conformi. Per saperne di più sulla loro importanza, leggete l'articolo completo.

The Codest
Jakub Jakubowicz CTO e cofondatore

Iscrivetevi alla nostra knowledge base e rimanete aggiornati sulle competenze del settore IT.

    Chi siamo

    The Codest - Società internazionale di sviluppo software con centri tecnologici in Polonia.

    Regno Unito - Sede centrale

    • Ufficio 303B, 182-184 High Street North E6 2JA
      Londra, Inghilterra

    Polonia - Poli tecnologici locali

    • Parco uffici Fabryczna, Aleja
      Pokoju 18, 31-564 Cracovia
    • Ambasciata del cervello, Konstruktorska
      11, 02-673 Varsavia, Polonia

      The Codest

    • Casa
    • Chi siamo
    • Servizi
    • Case Studies
    • Sapere come
    • Carriera
    • Dizionario

      Servizi

    • Consulenza
    • Sviluppo di software
    • Sviluppo backend
    • Sviluppo Frontend
    • Staff Augmentation
    • Sviluppatori backend
    • Ingegneri del cloud
    • Ingegneri dei dati
    • Altro
    • Ingegneri QA

      Risorse

    • Fatti e miti sulla collaborazione con un partner esterno per lo sviluppo di software
    • Dagli Stati Uniti all'Europa: Perché le startup americane decidono di trasferirsi in Europa
    • Confronto tra gli hub di sviluppo Tech Offshore: Tech Offshore Europa (Polonia), ASEAN (Filippine), Eurasia (Turchia)
    • Quali sono le principali sfide di CTO e CIO?
    • The Codest
    • The Codest
    • The Codest
    • Privacy policy
    • Condizioni di utilizzo del sito web

    Copyright © 2025 di The Codest. Tutti i diritti riservati.

    it_ITItalian
    en_USEnglish de_DEGerman sv_SESwedish da_DKDanish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish arArabic jaJapanese ko_KRKorean es_ESSpanish nl_NLDutch etEstonian elGreek it_ITItalian