Un consiglio su classe, sottoclasse....cosa è meglio.

di il
16 risposte

16 Risposte - Pagina 2

  • Re: Un consiglio su classe, sottoclasse....cosa è meglio.

    Alka ha scritto:


    Creare classi innestate ha senso solo quando esse costituiscono meramente un dettaglio implementativo della classe più ampia e si vuole nascondere tale dettaglio.

    E' come se tu dovessi realizzare un trapano e avessi incollato assieme batteria, corpo, mandrino e punta, rendendoli insostituibili, solo per il timore che qualcuno lo possa smontare, di fatto rendendo il sistema in sé meno modulare.

    Ciao!
    Perfetto sempre più chiaro.
    La difficoltà principale che incontro, non è tanto la scrittura del codice (anche se sicuramente quello che scrivo è ottimizzabile e può essere fatto con meno istruzioni o con l'uso di altri oggetti), ma individuare come una classe deve essere progettata e le relazioni che ha con le altre, il discorso di "Is a" o "Has a", pensare in object oriented.

    vengo da quasi 30 anni di programmazione procedurale in cobol, quale sarebbe il prossimo argomento da studiare, dopo il linguaggio? libri come "Design pattern object oriented" possono essere utili?

    Lavorare in C# al momento è escluso, ho almeno 1 altro anno, se non 2 in cobol.
  • Re: Un consiglio su classe, sottoclasse....cosa è meglio.

    CiSharpe ha scritto:


    vengo da quasi 30 anni di programmazione procedurale in cobol, quale sarebbe il prossimo argomento da studiare, dopo il linguaggio? libri come "Design pattern object oriented" possono essere utili?
    Approfondire i Design Pattern (intesi come quelli del famigerato libro della Gangs of Four) può essere una cosa interessante, ma proprio perché hai parlato delle difficoltà di comprendere i legami "Has/Is" (sintetizzo) e non hai (a quanto pare) alcuna difficoltà né remora nel documentarti (ottimo atteggiamento!!), io ti suggerirei invece di approfondire il discorso dei , che trovo più ampi, generici e moderni, più orientati a dare una visione ampia rispetto all'applicare una "ricetta" precostituita a problemi noti.

    Scoprirai che hanno nomi spesso assurdi, però non sono assolutamente complicati e secondo me rappresentano un bagaglio culturale veloce ma indispensabile per poter usare bene la OOP in primis, e strutturare una applicazione nel modo corretto (abilitando la possibilitàdi fare test e adottare altre tecniche correlate).

    Chiaramente, continua a porti esercizi e problemi da risolvere analoghi a questo del carrello, e poi confronta le soluzioni che applicherai man mano che ti documenti: scoprirai molte differenze lungo il percorso e le risposte a parecchie domande appariranno poi ovvie un domani.

    Ciao!
Devi accedere o registrarti per scrivere nel forum
16 risposte