Usi pratici dell'OOP

Question

Recentemente ho avuto un dibattito con un collega che non è un fan di Ops.Ciò che attirò la mia attenzione fu ciò che disse:

"Che senso ha scrivere il mio codice in oggetti?Se si tratta di riutilizzo, posso semplicemente creare una libreria e chiamare tutte le funzioni di cui ho bisogno per qualunque attività sia a portata di mano.Ho bisogno di questi concetti di polimorfismo, ereditarietà, interfacce, modelli o altro?"

Siamo una piccola azienda che sviluppa piccoli progetti per siti di e-commerce e immobiliari.

Come posso sfruttare l'OOP in una configurazione "quotidiana, nel mondo reale"?Oppure l'OOP era davvero pensato per risolvere problemi complessi e non per lo sviluppo "quotidiano"?

Answer 1

Le cose buone di programmazione orientata agli oggetti provengono da legare un set di dati da un insieme di comportamenti.

Quindi, se avete bisogno di fare molte operazioni correlate su un insieme correlato di dati, è possibile scrivere molte funzioni che operano su una struttura, oppure è possibile utilizzare un oggetto.

Oggetti darvi qualche aiuto il riutilizzo del codice sotto forma di eredità.

IME, è più facile lavorare con un oggetto con una serie nota di attributi e metodi che è quello di mantenere un insieme di structs complesse e le funzioni che operano su di essi.

Alcune persone andare avanti su ereditarietà e polimorfismo. Questi sono preziosi, ma il valore reale nella programmazione orientata agli oggetti (a mio parere) deriva dal modo bello incapsula e dei dati associati con i comportamenti.

Si dovrebbe utilizzare OOP sui vostri progetti? Questo dipende da quanto bene la vostra lingua supporta OOP. Questo dipende dal tipo di problemi che è necessario risolvere.

Ma, se si sta facendo piccoli siti web, si sta ancora parlando di complessità sufficiente che avrei usato OOP disegno dato adeguato sostegno nella lingua di sviluppo.

Answer 2

La mia opinione personale: di contesto

Quando si programma in OOP si dispone di una maggiore consapevolezza del contesto. Ti aiuta a organizzare il codice in modo che sia più facile da capire perché il mondo reale è anche orientato agli oggetti.

Answer 3

Più di ottenere qualcosa a lavorare solo - il punto del tuo amico, un design OO ben progettato è più facile da capire, a seguire, di espandersi, per estendere e da implementare. E 'molto più facile, ad esempio delegare il lavoro che categoricamente sono simili o sulla raccolta di dati che dovrebbero stare insieme (sì, anche una struct C è un oggetto).

Answer 4

Bene, sono sicuro che un sacco di gente darà molto più accademico risponde correttamente, ma qui è il mio prendere su alcuni dei più preziosi vantaggi:

• OOP consente una migliore incapsulamento
• OOP permette al programmatore di pensare in termini più logici, rendendo i progetti di software più facile da progettare e capire (se ben progettato)
• OOP è un risparmio di tempo. Ad esempio, guardare le cose si possono fare con un oggetto stringa C ++, vettori, ecc Tutto ciò che le funzionalità (e molto altro) viene per "libero". Ora, queste sono caratteristiche davvero delle librerie di classi e non OOP in sé, ma quasi tutte le implementazioni OOP sono dotati di librerie di classi belle. Si può implementare tutta quella roba in C (o la maggior parte di esso)? Sicuro. Ma perché scrivere voi stessi?

Answer 5

Guardate l'uso di modelli di progettazione e vedrete l'utilità della programmazione orientata agli oggetti. Non si tratta solo di incapsulamento e il riutilizzo, ma l'estensibilità e manutenibilità. Sono le interfacce che rendono le cose potenti.

A Alcuni esempi:

• L'implementazione di un flusso (modello decorator) senza oggetti è difficile

• Aggiunta di una nuova operazione di un sistema esistente come un nuovo tipo di crittografia (modello di strategia) può essere difficile senza oggetti.

• Guarda il modo in cui PostgreSQL è implementato rispetto al modo in cui il libro di database dice un database dovrebbe essere implementato e vedrete un grande differenza. Il libro suggerisce nodo oggetti per ciascun operatore. Postgres usa una miriade di tavoli e macro per cercare di emulare questi nodi. E 'molto meno bella e più più difficile da estendere a causa di questo.

L'elenco potrebbe continuare.

Answer 6

Il potere della maggior parte dei linguaggi di programmazione è nelle astrazioni che essi mettono a disposizione. Object Oriented Programming fornisce un potente sistema di astrazioni nel modo in cui consente di gestire le relazioni tra idee o azioni correlate.

Si consideri il compito di calcolare aree per un arbitrario e insieme di forme espansione. Ogni programmatore può scrivere rapidamente le funzioni per l'area di un cerchio, quadrato, triangolo, ect. e memorizzarli in una biblioteca. La difficoltà viene quando si cerca di scrivere un programma che identifica e calcola l'area di una forma arbitraria. Ogni volta che si aggiunge un nuovo tipo di forma, diciamo un pentagono, si avrebbe bisogno di aggiornare e ampliare qualcosa di simile a una struttura IF o CASE per consentire al programma per identificare la nuova forma e chiamare la corretta routine di area dalla tua "libreria di funzioni" . Dopo un po ', i costi di manutenzione associati a questo approccio cominciano ad accumularsi.

Con la programmazione orientata agli oggetti, un sacco di questo viene free-- solo definire una classe Shape che contiene un metodo di zona. Poi in realtà non importa quale forma specifica hai a che fare con in fase di esecuzione, basta fare ogni figura geometrica di un oggetto che eredita da Shape e chiamare il metodo zona. Il paradigma Object Oriented gestisce i dettagli di se in questo momento nel tempo, con questo input dell'utente, abbiamo bisogno di calcolare l'area di un cerchio, triangolo, quadrato, pentagono o l'opzione di ellisse che è stato appena aggiunto mezzo minuto fa.

Che cosa succede se si decide di modificare l'interfaccia dietro il modo in cui la funzione di zona era chiamata? Con Object Oriented Programming si sarebbe solo aggiornare la classe Shape ei cambiamenti automagicamente propagarsi a tutti i soggetti che ereditano da quella classe. Con un sistema non Object Oriented si troverebbe di fronte il compito di slogging attraverso la vostra "libreria di funzioni" e l'aggiornamento di ogni singola interfaccia.

In sintesi, programmazione Object Oriented fornisce una potente forma di astrazione che consente di risparmiare tempo e fatica, eliminando la ripetizione nel codice e razionalizzare le estensioni e la manutenzione.

Answer 7

Tutti i paradigmi di programmazione hanno lo stesso obiettivo: nascondere la complessità non necessaria.

Alcuni problemi possono essere facilmente risolti con un paradigma imperativo, come il tuo amico utilizza. Altri problemi sono facilmente risolvibili con un paradigma orientato agli oggetti. Ci sono molti altri paradigmi . I principali (programmazione logica, programmazione funzionale e programmazione imperativa) sono tutti equivalenti tra loro; programmazione orientata agli oggetti di solito è pensato come un'estensione imperativi programmazione.

Programmazione orientata agli oggetti è meglio utilizzato quando il programmatore sta modellando gli elementi che sono simili, ma non è la stessa. Un paradigma imperativo avrebbe messo i diversi tipi di modelli in una sola funzione. Un paradigma orientato agli oggetti separa i diversi tipi di modelli in diversi metodi su oggetti correlati.

Il suo collega sembra essere bloccato in un unico paradigma. In bocca al lupo.

Answer 8

Intorno al 1994 ho cercato di dare un senso di programmazione orientata agli oggetti e C ++, allo stesso tempo, e mi trovai frustrato, anche se ho potuto capire in linea di principio quale sia il valore della programmazione orientata agli oggetti è stato. Ero così abituata ad essere in grado di pasticciare con lo stato di qualsiasi parte della richiesta da altre lingue (per lo più di base, il montaggio, e Pascal-famiglia lingue) che sembrava che stavo dando la produttività a favore di una certa astrazione accademica. Purtroppo, i miei primi incontri con quadri OO come MFC reso più facile incidere, ma non necessariamente offrono molto in termini di illuminazione.

Solo attraverso una combinazione di persistenza, esposizione ad alternare (non C ++) modi di trattare con oggetti e attenta analisi di codice OO che sia 1) lavorato e 2): più coerente e intuitivo rispetto al codice di procedura equivalente che ho iniziato a farlo davvero. E 15 anni dopo, sono regolarmente sorpreso nuovo (per me) scoperte di soluzioni intelligenti OO, eppure straordinariamente semplici che non riesco a immaginare di fare come ordinatamente in un approccio procedurale.

Ho lavorato con la stessa serie di lotte che cercano di dare un senso al paradigma di programmazione funzionale, nel corso degli ultimi due anni. Per parafrasare Paul Graham, quando si sta guardando in basso il continuum di potenza, si vede tutto ciò che manca. Quando stai cercando il continuum di potere, non si vede la potenza, basta vedere stranezza.

Credo che, al fine di impegnarsi a fare qualcosa di un modo diverso, è necessario 1) vedere qualcuno, ovviamente, essere più produttivi con costrutti più potenti e 2) sospendere l'incredulità quando ti ritrovi a colpire un muro. Probabilmente aiuta ad avere un mentore che è almeno un pochino più avanti nella comprensione del nuovo paradigma, anche.

Blocco il buon senso necessario per sospendere l'incredulità, se si desidera che qualcuno di Grok rapidamente il valore di un modello OO, credo che si potrebbe fare molto di peggio che chiedere a qualcuno di trascorrere una settimana con il libro Pragmatic Programmers on Rails. Lo fa, purtroppo, lasciare fuori un sacco di dettagli di come funziona la magia, ma è una buona introduzione al potere di un sistema di astrazioni OO. Se, dopo aver lavorato con quel libro, il suo collega ancora non vede il valore di OO per qualche ragione, lui / lei può essere un caso senza speranza. Ma se sono disposti a spendere un po 'di tempo a lavorare con un approccio che ha un design OO fortemente supponente che funziona, e li ottiene da 0-60 di gran lunga più veloce di fare la stessa cosa in un linguaggio procedurale, ci può essere solo la speranza. Penso che sia vero anche se il vostro lavoro non comporta lo sviluppo web.

Io non sono così sicuro che il fanalino di "mondo reale" sarebbe tanto un punto di vendita come un quadro di lavoro per la scrittura di buone applicazioni, perché si scopre che, soprattutto in lingue staticamente tipizzati come C # e Java, la modellazione il mondo reale richiede spesso astrazioni tortuosi. Si può vedere un esempio concreto della difficoltà di modellare il mondo reale, cercando in migliaia di persone che lottano per modellare qualcosa di apparentemente semplice come l'astrazione geometrica di "forma" (forma, ellisse, cerchio).

Answer 9

Per me, il potere dell'OOP non si mostra finché non si inizia a parlare di ereditarietà e polimorfismo.

Se la propria argomentazione a favore dell'OOP si basa sul concetto di incapsulamento e astrazione, beh, questo non è un argomento molto convincente per me.Posso scrivere un'enorme libreria e documentare solo le interfacce di cui voglio che l'utente sia a conoscenza, oppure posso fare affidamento su costrutti a livello di linguaggio come i pacchetti in Ada per rendere i campi privati ​​ed esporre solo ciò che voglio esporre.

Tuttavia, il vero vantaggio arriva quando ho scritto il codice in una gerarchia generica in modo che possa essere riutilizzato in seguito in modo tale che le stesse esatte interfacce di codice vengano utilizzate per funzionalità diverse per ottenere lo stesso risultato.

Perché è utile?Perché posso stare sulle spalle dei giganti per portare a termine il mio compito attuale.L'idea è che posso ridurre le parti di un problema alle parti più basilari, gli oggetti che compongono gli oggetti che compongono...gli oggetti che compongono il progetto.Usando una classe che definisce molto bene il comportamento nel caso generale, posso usare lo stesso codice collaudato per costruire una versione più specifica della stessa cosa, e poi una versione più specifica della stessa cosa, e poi ancora una versione ancora più specifica versione della stessa cosa.La chiave è che ciascuna di queste entità ha elementi comuni che sono già stati codificati e testati e non è necessario reimplementarli nuovamente in seguito.Se non utilizzo l'ereditarietà per questo, finisco per reimplementare la funzionalità comune o collegare esplicitamente il mio nuovo codice al vecchio codice, il che mi fornisce uno scenario per introdurre bug del flusso di controllo.

Il polimorfismo è molto utile nei casi in cui devo ottenere una determinata funzionalità da un oggetto, ma la stessa funzionalità è necessaria anche per tipi simili, ma unici.Ad esempio, in Qt, c'è l'idea di inserire elementi in un modello in modo che i dati possano essere visualizzati e si possano facilmente mantenere i metadati per quell'oggetto.Senza polimorfismo, avrei bisogno di preoccuparmi di molto più dettagli di quanto faccio attualmente (I.E.avrei bisogno di implementare le stesse interfacce di codice che conducono la stessa logica di business dell'articolo originariamente previsto per il modello).Poiché la classe base del mio oggetto associato a dati interagisce in modo nativo con il modello, posso invece inserire metadati su questo modello senza problemi.Ottengo ciò di cui ho bisogno dall'oggetto senza preoccuparmi di ciò di cui ha bisogno il modello, e il modello ottiene ciò di cui ha bisogno senza preoccuparsi di ciò che ho aggiunto alla classe.

Answer 10

Chiedi al tuo amico di visualizzare qualsiasi oggetto nella sua stessa stanza, casa o Città ... e se può dire una sola tale oggetto, che un sistema di per sé ed è in grado di fare qualche lavoro significativo .
Cose come un isnt pulsante di fare qualcosa da solo - ci vuole un sacco di oggetti per fare una telefonata.
Analogamente il motore di un'automobile è fatta dell'albero a gomiti, pistoni, candele. OOPS concetti sono evoluti dalla nostra percezione nei processi naturali o cose nella nostra vita.
Il libro "Inside COM" racconta la fine di COM prendendo analogia da un gioco d'infanzia di identificazione degli animali, ponendo domande.

Answer 11

Progettazione trionfi tecnologia e della metodologia. Buoni disegni tendono a incorporare principi universali di complessità di gestione come il diritto di Demetra, che è al cuore di ciò che caratteristiche del linguaggio OO si sforzano di codificare.

Un buon design non è dipendente da uso di OO caratteristiche del linguaggio specifico, anche se è in genere in quelle migliore interesse di usarli.

Answer 12

Non solo fa

• la programmazione più semplice / più gestibile nella situazione attuale per gli altri (e te stesso)
• E 'già agevolare operazioni CRUD database (Create, Update, Delete) le operazioni.

E 'possibile trovare maggiori informazioni a questo proposito la ricerca: - Java: Hibernate - Dot Net: Entity Framework

Guarda anche come LINQ (Visual Studio) può rendere la vita di programmazione molto più facile.

• Inoltre, è possibile iniziare a utilizzare modelli di progettazione per risolvere i problemi della vita reale (modelli di progettazione sono tutti circa OO)

Forse è anche divertente per dimostrare con un po 'di demo:

• Diciamo che è necessario memorizzare i dipendenti, i clienti, i membri, i libri in un file di testo in un modo simile.

.PS. Ho provato a scrivere in modo PSEUDO:)

il modo OO

Codice si chiama: io.file.save (objectsCollection.ourFunctionForSaving ())

class objectsCollection

funzione ourFunctionForSaving () As String

Stringa _Objects

   for each _Object in objectsCollection
         Objects &= _Object & "-"
   end for

_Objects ritorno Metodo di chiusura

NON-OO Way

Non credo che scriverò giù codice non-oo. Ma pensare di esso:)

Ora diciamo che

Nel modo OO. La classe di cui sopra è la classe padre di tutti i metodi per salvare i libri, i dipendenti, i membri, i conti, ... Che cosa succede se si vuole cambiare il modo di salvare in un file di testo? Ad esempio, per rendere più comprimibile con uno standard corrente (.csv).

E diciamo che vorremmo aggiungere una funzione di carico, la quantità di codice hai bisogno di scrivere? Nel modo OO- è necessario solo il aggiungere un nuovo metodo secondaria che può dividere tutti i dati in parametri (Questo succede una volta).

Lasciate che il vostro collega pensare che:)

Answer 13

In domini in cui stato e il comportamento sono scarsamente allineati, Object-Orientamento riduce la densità complessiva di dipendenza (cioè complessità) all'interno di questi domini, che rende i sistemi risultanti meno fragile.

Questo perché il essenza di Object-orientamento si basa sul fatto che, organizzativo, non dustinguish tra stato e il comportamento affatto, trattando sia uniformemente come "features". Gli oggetti sono solo insiemi di caratteristiche clumpled per ridurre al minimo complessivo di dipendenza.

In altri domini, Object-Orientamento non è l'approccio migliore. Ci sono diversi paradigmi di lingua per problemi diversi. Gli sviluppatori esperti lo sanno, e sono disposti a usare qualsiasi lingua è più vicino al dominio.