Ho letto molte persone che dicono che alcune cose non dovrebbero essere scritte in uno stile orientato agli oggetti - come una persona che sta imparando lo stile OO proveniente da uno sfondo C, cosa significano con questo?Cosa dovrebbe essere OO e cosa non dovrebbe?
Cosa non dovrebbe essere OO, perché alcune cose si adattano meglio a questo design e come facciamo a sapere quando è meglio fare cosa?
Il mondo reale è pieno di oggetti.
È utile rendere il mondo del software adatto al mondo reale.
"Che dire di 'utilità di sistema'? Si occupano solo di astrazioni come socket e processi e file system." Mi sembrano cose simili. Hanno attributi e comportamenti, hanno associazioni.
Se siete alla ricerca di una prova che OO è meglio, non v'è alcuna. Niente è meglio perché meglio è un termine gloriosamente vago. Chiunque sia abile può scrivere qualsiasi programma in qualsiasi stile. Potresti adottare un approccio funzionale, procedurale, orientato agli oggetti o qualsiasi cosa tu voglia.
Io uso OO perché ho un cervello molto piccolo e devo imparare a vivere entro i suoi limiti. OO è una stampella per aiutarmi a lottare attraverso la programmazione. Se fossi più intelligente, più ricco e di bell'aspetto, non avrei bisogno dell'aiuto e potrei scrivere programmi non OO. Purtroppo, non sono intelligente Senza le definizioni di classe per isolare la responsabilità e strutturare un'architettura, continuerei a scrivere varianti "ciao mondo" a file singolo.
Tutto ciò che viene detto qui è valido e vero, OO consente un maggiore controllo sull'uso del codice senza dover scrivere codice per farlo, basta provare a ignorare il tono derisorio e arrogante della risposta;) (sono sicuro che fosse per scherzo) – RAGNO
@RAGNO: Immagino che tu stia parlando del 3 ° paragrafo che è inteso come reale - migliore è indefinito e la maggior parte delle domande (come questa) non hanno un concreto qualificatore. Solo termini vaghi come "migliore". Non sono sicuro su come altro dirlo. Consigli? –
Solo un suggerimento: dovresti taggare questa domanda come "soggettiva" dato che tutti sembrano avere un'opinione diversa su cose come questa.
E dovresti mettere questo tipo di nota nei commenti e non come una risposta alla domanda ... No, non ero io che ti ho votato, ma Somone ha fatto e presumo questo perché. –
Perché non l'hai fatto tu stesso, hai il rappresentante. – Rik
Il design orientato agli oggetti si basa sulla gestione della complessità man mano che il sistema cresce. Pertanto il design OO può essere eccessivo per sistemi meno complessi, o per sistemi che non cresceranno mai.
Ovviamente il problema è che raramente sappiamo con certezza che un sistema non sta per crescere.
Non riesco a pensare ad altro che alle stored procedure. Prendi una copia di Reflector e usala per guardare le dll del framework .NET come una buona lezione di apprendimento. In alternativa ci sono un sacco di libri su C++ e OO sul mercato da quando è stato un po 'di tempo.
Sono d'accordo con la maggior parte di quanto sopra (o sotto?) Che OO esiste per semplificare problemi complessi e progettazione del software.
Tuttavia, ci sono molte volte in cui è estremamente esagerato. Non riesco a dirti quante volte preferisco che ci fosse un pulsante di Visual Studio Unrefactor solo per dare un senso al codice e mettere tutte le classi base in un file per la leggibilità.
sì, proprio! Come la denormalizzazione di oo code! – alchemical
Una semplice regola empirica è incapsulare dati complessi e codice utilizzato ripetutamente e ignorare ciò che non lo è. Ciò consente di inserire strutture dati complicate insieme ai loro metodi di manipolazione per una maggiore portabilità e flessibilità. Come un elenco di oggetti di database con ordinamento intelligente per tipo di proprietà.
Il codice OO offusca anche ciò che non è necessario conoscere. Ad esempio, non ho bisogno di sapere quale sia il mio algoritmo di ordinamento finché non rallenta, o se sto già programmando per un ambiente ad alte prestazioni.
Un'altra grande cosa del codice OO è il suo polimorfismo, il modo in cui è possibile utilizzare i tipi successivi per modificare le azioni senza che il programma ne sappia o si preoccupi. Un esempio è un formato di archivio con più tipi di elenco di file: l'elenco può avere una matrice di strutture (record o strutture) al suo interno che cambia tra i tipi di elenco, ma eredita da una classe base e la complessità di sapere quale struttura sottostante usare va via. Sarebbe piuttosto difficile gestirlo senza l'orientamento all'oggetto, e francamente è abbastanza difficile da gestire dato che è con l'orientamento dell'oggetto.
OO e MVC non risolvono i tuoi problemi, se non si sa come risolverli già, non fanno che ti danno modi più potenti per spararsi in un piede — solo che questa volta si potrebbe non sapere perché. Quindi ricorda che se è tutto, OO non è il "mirino magico" ... ma ricorda che può essere il proiettile magico data la situazione giusta e il programmatore giusto.
Se stai scrivendo applicazioni mobili (almeno posso parlare per .NET mobile), allora dovresti cercare di essere il più possibile non-OO. Per quanto i dispositivi mobili siano avanzati, non vuoi sprecare memoria di sistema perché hai bloccato l'elaborazione con i livelli di astrazione, i grandi set di dati in memoria o altre entità che rallentano le cose. Avrai voglia di scrivere le cose il più semplice possibile.
non è un po 'vicino alla tua domanda precedente: "Quali sono i vantaggi della programmazione OO? Mi aiuterà a scrivere codice migliore?" ?? –
In un certo senso, anche se questo non mi ha davvero aiutato a capire cosa si adatta naturalmente al design OO - non ho ancora scritto alcun codice che mi sembra naturale, e mi chiedo se sto forzando le cose sbagliate nel modello di progettazione sbagliato. –
Forse dovresti concentrarti sulla tua domanda specifica. Le domande generali ottengono generalmente risposte inutili. Pubblica un disegno per commenti o qualcosa del genere. –