DOMANDA Il mio primo programma C# - Che ne pensate? Consigli?

pabloski

Utente Èlite
1,903
341
Hardware Utente
senza avere prima fatto una seria analisi del progetto, incluse le implicazioni future (prima tra le quali, e' il prgramma scritto in modo che si possa facilmente cambiare e aggiungere nuove features. Diciamo che adesso passo un buon 60% solo a progettare, dopodiche' sedersi davanti al computer e scrivere il codice non ci vuole nulla.
Se c'è il tempo. Oggi la vita va di corsa e il concorrente ti frega. Purtroppo è un dato di fatto e infatti tutti i software ( compreso Linux e compari ) vengono messi in circolazione senza che si sia potuta completare una seria fase di progettazione...il testing, vabbè ormai non compare nemmeno più nel vocabolario.

Windows, macOS, non parliamo dell'IoT...

Meglio disegnare il software a tavolino, secondo metodologie waterfall. Almeno quando c'è il tempo.
 

Andretti60

Utente Èlite
3,265
2,151
Hardware Utente
Se c'è il tempo ...
Faccio questo lavoro da trenta anni ormai. Ormai quando un manager alla mia risposta della sua domanda "quanto tempo ci vuole" mi dice "troppo tempo" non rispondo piu' come Scotty di Star Trek (Aye aye cap'ain), gli dico "fallo fare a qualcun altro, ma se poi non funziona non chiedere a me di riscriverlo". Ho perso troppo tempo nella mia professione nel risolvere problemi dovuti a una cattiva progettazione (inclusi quelli creati da me stesso). In questo momento ho davanti a me codice che scrissi in VisualBasic nel 1997 per una demo di un nuovo prodotto, funziona ancora, ma e' praticamente impossibile modificarlo.
 
  • Mi piace
Reactions: TheLastViper

TheLastViper

Nuovo Utente
8
2
Hardware Utente
CPU
Intel core i5 - 4590
Scheda Madre
ASUS H81I-PLUS
Hard Disk
SSD 120/128 GB SATA
RAM
DDR3-1600 DIMM 8GB
Scheda Video
KFA Geforce GTX 1060 OC
Scheda Audio
Logitech 5.1 Sound system 75W
Monitor
24"(60.9 cm) Full HD monitor gaming
Periferiche
Wireless keyboard with touchpad + Logitech G29 steering wheel/pedal set
Internet
Fastweb ADSL2+ 20Mb
Sistema Operativo
Windows 10
@Andretti60 @pabloski Grazie mille ad entrambi per i suggerimenti. Volevo comunicarvi che sto imparando a fare la fase di progettazione quando programmo, faccio un'analisi su carta della soluzione, compresa di flow chart e di schemi relazionali, che mi aiutano ad avere piú chiaro in mente cosa dovró fare in fase di programmazione. Purtroppo, peró, non riesco ancora a distaccarmi dal mio modo di programmare in maniera procedurale, secondo me é una questione di logica perché questo tipo di programmazione mi risulta essere il piú intuitivo. Nel mio attuale ambiente lavorativo, peró, purtroppo ho bisogno di programmare ad oggetti, per caso sapete consigliarmi guide o testi che possano aiutarmi nel mio caso? Grazie ancora :)
 

fabio93

Utente Attivo
372
98
Hardware Utente
CPU
AMD Ryzen 5 2400G
Dissipatore
Arctic Alpine64 Plus
Scheda Madre
Gigabyte GA-AX370-Gaming 3
Hard Disk
Crucial MX500 250 GB, Crucial BX500 240 GB
RAM
G.Skill F4-3200C14D-16GFX FlareX 16 GB
Monitor
HP 2010i
Alimentatore
Corsair TX550M
Case
Sharkoon M25-W
Sistema Operativo
Windows 10 Pro, Ubuntu 19.04
Anch'io ho studiato il paradigma OO da dispense universitarie, quindi non saprei consigliarti un libro in particolare, ma ti direi di leggere articoli online (guarda quest'altro mio post). Di seguito cerco di farti un'introduzione spicciola all'argomento.

In informatica e anche nella progettazione software un concetto chiave è quello di astrazione: dal latino abstrahere, significa tralasciare dettagli particolari e guardare un problema da una prospettiva più generale, o più consona a quello che si deve fare in un dato momento. I computer capiscono solo il linguaggio macchina fatto di sequenze di 0 e 1. Negli anni '50 furono inventati i primi linguaggi di programmazione assemblativi, che consentivano di scrivere programmi in maniera più comprensibile per un umano: questo è un primo embrionale esempio di astrazione.
Facendo qualche salto in avanti nel tempo, il costrutto di funzione o procedura, che ben conoscerai se già programmi in C++, altro non è che un'applicazione dell'astrazione funzionale, che consiste nel racchiudere del codice atto a risolvere un certo problema in un blocco invocabile dall'esterno: in questo modo l'utente (programmatore) di una funzione non deve sapere come funziona ma solo cosa fa e quali sono le sue regole di invocazione (i parametri ecc.): ecco dove si cela l'astrazione.
Il passo successivo è stata la definizione del concetto di astrazione dati: non si astrae più solo sulle operazioni, ma anche sulla rappresentazione dei dati, il che apre nuove possibilità: si può incapsulare in un modulo software la rappresentazione dei dati (la loro struttura interna) con delle operazioni lecite che sono le sole autorizzate ad operare su di essi. In questo modo è possibile nascondere la rappresentazione dei dati (information hiding) in modo che sia sconosciuta all'esterno: il chiamante di un tale modulo non deve più sapere come è fatto (indovinato... astrazione!) ed è quindi indipendente dalla struttura interna dei dati (meno cose si sanno, meno si dipende da esse -> se la rappresentazione dei dati dovesse cambiare, non occorre modificare il codice dell'utilizzatore di quei dati, che ne ignora la struttura). In programmazione, ciò si traduce nei tipi di dato astratti, e nei concetti di oggetto e classe. Ora cercherò brevemente di spiegarteli.
Un tipo di dato astratto è un modulo software in cui dichiari un nuovo tipo, che si basa su tipi già esistenti o primitivi: tipicamente si riferisce ai record, o alle struct di C e C++. Perciò la forma più antica di astrazione dati in programmazione consiste nello scrivere un modulo (tipo un file header di C) in cui dichiari un record (nuovo tipo) e definisci delle operazioni (funzioni o procedure) operanti su di esso. Dichiarando privato il record e facendo sì che vi si possa accedere solo indirettamente attraverso le operazioni lecite (non mi riferisco a un linguaggio in particolare, sono concetti teorici) si realizza l'information hiding e quindi il requisito di protezione dei dati. Puoi immaginare questo modulo come una capsula formata dalla definizione di un tipo, e dalle funzioni operanti su di esso. Alcune di queste operazioni possono servire per operazioni di inizializzazione dei valori del nuovo tipo, e prendono il nome di costruttori. Un modulo del genere non contiene dati di per sé, ma solo la definizione di un nuovo tipo (struct), perciò per usarlo si deve dichiarare una variabile del nuovo tipo, e solo dopo utilizzarla con le operazioni lecite, alle quali si passerà la variabile come parametro. Quindi questo genere di moduli non conserva uno stato, ovvero non contiene in sé le variabili, ma solo la definizione di tipo.
Un modulo dotato di stato locale, invece, contiene non solo la definizione di un tipo (struct) ma anche una sua istanza (variabile): un entità del genere prende il nome di oggetto. Perciò un oggetto è un modulo che racchiude la definizione di un tipo, una sua variabile, il cui tempo di vita è pari a quello dell'intero modulo, e dei metodi operanti su di essa (negli oggetti le funzioni/procedure sono dette metodi). Quindi un oggetto = una variabile. Storicamente, il concetto di oggetto è alla base del paradigma Object Based (es. il linguaggio Modula-2).
Il passo successivo è stato quello di astrarre ancora, definendo moduli che rappresentassero non solo una variabile ma una classe di variabili dello stesso tipo, cioè una classe di oggetti. Una classe è quindi un modulo generico che non identifica un solo oggetto ma un insieme di oggetti dello stesso tipo (la classe sta all'oggetto come la specie sta all'individuo in una popolazione). Questa è una forma di astrazione generica, ovvero si astrae su una dichiarazione di qualcosa, in questo caso sulla dichiarazione di un modulo. Si ebbero così i linguaggi Class Based (es. Ada-83).
Queste nozioni, unite a quella di ereditarietà (inheritance) costituiscono la base del paradigma Object Oriented (= objects + classes + inheritance secondo una celebre definizione accademica). L'ereditarietà consiste nel poter definire nuove classi (sottoclassi) derivate a partire da altre (superclassi), allo scopo di riutilizzarne il codice o di modellare meglio le entità del problema che si sta affrontando. Altro concetto cardine del paradigma OO è il polimorfismo, di cui ci sono vari tipi e sul quale ci sarebbe molto da dire (vedi qui). Ti dico solo che il tipo più potente di polimorfismo è quello di inclusione, che dice che un oggetto di una classe B può comparire ogniqualvolta ci si aspetta un oggetto di classe A, se B è sottoclasse di A. Questo in virtù del fatto che la relazione di ereditarietà (in genere) implica una relazione is a, ovvero un oggetto di classe B è anche un oggetto di classe A, se B eredita (è sottoclasse di) da A. In letteratura questo è indicato come principio di sostituibilità di Liskov, in nome della prof.ssa Barbara Liskov che lo enunciò negli anni '90.
Per progettare software con il paradigma OO, devi pensare in termini di entità, che sono gli attori nell'universo del programma. Queste entità, che possono essere basate su entità reali prese dal dominio del problema, diventeranno le classi nel programma. Il programma perciò sarà un insieme di classi che interagiscono fra loro (o meglio, i cui oggetti o le cui istanze interagiscono fra loro) scambiandosi messaggi (invocando metodi).
Nel paradigma OO spesso ci si avvale di un linguaggio di modellazione chiamato UML, che serve a rappresentare, mediante diagrammi, sia il modello di dominio del problema che la struttura del software (diagramma delle classi) o il suo funzionamento in esecuzione (diagramma di sequenza), e tante altre cose.
Infine, ti dico che a proposito del paradigma OO (ma non solo) ci sono una serie di principi di progettazione e linee guida, come ad esempio i principi SOLID (di cui ho postato un link nel post menzionato all'inizio), o i principi di alta coesione, basso accoppiamento e il principio DRY (Do not Repeat Yourself). Questi argomenti sono trattati dall'ingegneria del software, materia affascinante e complessa che si occupa proprio della progettazione dei programmi nel loro insieme astraendo (ancora una volta) dai singoli algoritmi. Scusa il pippone ma spero di averti dato un'infarinatura sull'Object Oriented in modo che tu possa per lo meno avere un minimo di basi teoriche. Buona programmazione!
 

rodhellas

Utente Attivo
1,467
394
Hardware Utente
CPU
Intel i5 3470
Scheda Madre
AsRock H77 pro4/mvp
Hard Disk
120GB SSD + 1TB HD
RAM
12GB Corsair XMS3 1333mhz
Scheda Video
Gigabyte GTX 960 OC
Scheda Audio
Integrata
Monitor
SyncMaster 223BW
Alimentatore
Antec HCG-520M
Case
Thermaltake Commander Ms-i Snow Edition
Sistema Operativo
Windows 10 64bit
Per progettare software con il paradigma OO, devi pensare in termini di entità, che sono gli attori nell'universo del programma. Queste entità, che possono essere basate su entità reali prese dal dominio del problema, diventeranno le classi nel programma. Il programma perciò sarà un insieme di classi che interagiscono fra loro (o meglio, i cui oggetti o le cui istanze interagiscono fra loro) scambiandosi messaggi (invocando metodi).
Bastava dire questo :)
 

Entra

oppure Accedi utilizzando