Come affrontare la progettazione del programma rispetto alle strutture e agli algoritmi di dati: esiste un elemento di riferimento del processo di progettazione OO per d.s.'s + algs? [chiuso]

1

Le mie applog per probabilmente il peggior corpo di testo scritto che ho prodotto nella mia vita e molte grazie a coloro che sono disposti a scavare tutto.

Ero (e sono tuttora) non in grado di esprimere chiaramente ciò che stavo chiedendo, poiché dalla natura della mia domanda non posso essere chiaro su cosa esattamente sia dopo. Fondamentalmente sospetto strongmente che qualcosa nella mia conoscenza dello sviluppo del software sia mancante, ma poiché "Non so, cosa non so", non posso specificare cosa esattamente sto cercando (e in effetti non posso essere sicuro se tale esiste una cosa) - quindi suppongo di chiedere una certa direzione in questa materia. Pensavo che se gli sviluppatori proffessionali non sapessero / non usassero una cosa del genere nel processo di desingin code - allora non c'è niente da sapere in questo senso (e posso smettere di preoccuparmi).

Essenzialmente temo qualcosa di simile ad aver imparato a programmare, ma sono rimasto ignaro del tema del corretto design del software OO. Ho studiato le strutture e gli algoritmi di dati standard (per quanto riguarda la copertura trovata nei tipici libri di testo universitari), ma non posso fare a meno di pensare che dovrebbe esserci qualcosa di più. Quindi non posso non sentirmi come se avessi imparato le nozioni di base, ma non diventare consapevole delle strutture dati e delle alghe. equatore di progettazione OO. Essenzialmente immagino che ci sia un qualche "processo" alla progettazione della soluzione (nel contesto del lato dss e alg della programmazione - come avviene per il lato progettazione OO del software di codifica - Vedo che entrambi fanno parte del stesso tutto nella programmazione) che ne informa su come procedere nel compito di scrivere un codice "buono" (nell'aspetto ds e algs del codice del programma scritto). Temo in assenza di conoscenza di tale processo / soggetto, sarei incompetente come uno sviluppatore laureato (un po 'come se considerassi un nuovo dipendente, se il suo codice risultasse non informato dai principi / principi del processo di progettazione OO). Prenderò in considerazione il codice prodotto da qualcuno privo di conoscenza dei principi / processi di progettazione OO per essere "codice cattivo" - e quindi di essere incompetente. Al momento temo il mio knwolege rispetto al d.s. + alg. lato della codifica mi colloca in una posizione simile. Quindi, qualcuno può dirmi di cosa potrei ancora aver bisogno di essere a conoscenza in questo senso?

(Un altro modo di porre la mia domanda potrebbe essere se dovessi dire: "I principi e gli schemi di progettazione orientati agli oggetti, è alla programmazione, che" ... "è per le strutture e gli algoritmi dei dati". Qualcuno potrebbe dirmi cosa si potrebbe completare questa frase con, o se non c'è nulla da considerare qui)

    
posta man of 13.08.2014 - 22:23
fonte

1 risposta

9

Per prima cosa, OOD non è qualcosa che puoi affrontare sistematicamente. Non ci sono caselle di controllo per qualcosa che varierà in base a chi lo sta facendo e a quale ambiente ci si trova. Quindi la tua ipotesi che l'efficienza segua un percorso simile è errata.

In pratica, pochissime aziende si preoccupano molto del codice efficiente. Quelle sciocchezze sono (molto spesso) inserite dalle persone delle risorse umane o dai quadri intermedi che non hanno idea di cosa significhi. Le aziende vogliono che il tuo software funzioni. Vogliono che continui a funzionare. E a meno che la tua azienda non abbia requisiti rigidi in termini di prestazioni e scalabilità, hai un sacco di margine di manovra su come vengono implementate le tue soluzioni.

Ma consideriamo per un momento cosa significa in realtà nella minoranza di posti di lavoro in cui è importante. Hai ragione che il "codice efficiente" si concentra principalmente sulla complessità temporale e spaziale degli algoritmi e delle strutture dati nei tuoi libri. Sfortunatamente, è raramente chiaro quale sarà il tuo input o quale metrica stai ottimizzando (puoi recuperare più memoria in cambio di prestazioni più veloci? Puoi sacrificare la precisione per lo spazio su disco?). In pratica, le scelte che affronti (sia in termini di efficienza che di OOD) saranno una serie di compromessi. Non ci saranno caselle di controllo da contrassegnare. Molto spesso non esiste una sola risposta corretta.

Dovrai fare alcune ipotesi su come sarà il tuo input, e alla fine assomiglierà. Dovrai fare alcune ipotesi su ciò che è importante per (la maggior parte) dei tuoi utenti. E poi dovrai fare la tua ipotesi migliore sulla soluzione appropriata per bilanciare l'incontro con tutte le tue richieste mentre usi un minimo di risorse.

    
risposta data 13.08.2014 - 22:52
fonte