La programmazione OO è davvero importante quanto le aziende di collocamento lo collocano? [chiuso]

Sto solo finendo il mio master (in informatica) e facendo domanda per un lavoro. Ho notato che molte aziende chiedono specificamente una comprensione dell'orientamento agli oggetti. Le domande più frequenti sull'intervista riguardano ereditarietà, polimorfismo, accessori, ecc.

OO è davvero così cruciale? Ho anche avuto un'intervista per un lavoro di programmazione in C e metà dell'intervista era OO.

Nel mondo reale, sviluppando applicazioni reali, l'orientamento agli oggetti è quasi sempre usato? Le caratteristiche chiave come il polimorfismo sono utilizzate MOLTO?

Penso che la mia domanda provenga da uno dei miei punti deboli. Anche se conosco OO, non riesco a incorporarlo molto nei miei programmi.

OOP è un paradigma che consente al programma di crescere senza diventare impossibile da mantenere / comprendere. Questo è un punto che gli studenti quasi mai ottengono perché fanno solo piccoli progetti che durano da due settimane a un massimo di due mesi.

Questo breve periodo non è sufficiente per chiarire l'obiettivo di OOP, soprattutto se le persone del progetto sono principianti. Ma attenersi a una modellizzazione è cruciale per i grandi progetti, direi> 50.000 righe di codice. OOP non è l'unica soluzione a questo, ma è la più ampiamente utilizzata nel settore.

Questo è il motivo per cui le persone vogliono che tu sappia OOP.

Aggiungerei, per esperienza, che quasi tutti i programmatori junior hanno un grave difetto di modellizzazione e OOP. Molti di loro sanno come scrivere classi, ereditare da loro e cose di base come quelle, ma non pensano in "OOP" e finiscono per abusarne. Questo è il motivo per cui qualsiasi reclutatore serio guarderà sempre quali sono le tue competenze nel dominio OOP.

Poiché queste cose non vengono apprese a scuola, esiste una variazione semplicemente enorme di conoscenza tra i diversi candidati. E siamo più cordiali: non credo che qualcuno con una scarsa conoscenza di OOP possa lavorare su qualsiasi grande progetto, semplicemente perché richiederebbe più tempo agli sviluppatori principali per gestire queste persone che semplicemente scrivere il codice da soli.

Se non pensi ancora a "OOP", ti suggerirei di leggere alcuni libri a riguardo e di candidarti in una compagnia che non ha progetti veramente grandi; abituarsi a OOP continuando a fare un lavoro utile per il tuo datore di lavoro (e fintanto che ti darà il tuo stipendio, questo sarà utile anche per te).

EDIT: ah, e aggiungerei che ho già scritto il codice OOP in C, anche se non è l'uso più comune di C, questo è possibile con una forte conoscenza. Devi solo creare vtables manualmente.

E dietro la tecnica OOP, qualcosa è nascosto: la progettazione del software. La progettazione del software è davvero utile, in C come in qualsiasi altra lingua. Molti recruiter metteranno alla prova le tue competenze di progettazione software e la domanda OOP è buona per questo, ma OOP non è la cosa principale che viene testata qui. Questo è il motivo per cui hai queste domande anche per un lavoro C.

Il travolgente problema con la programmazione informatica sta gestendo la complessità e i programmi moderni possono essere davvero molto complessi, e questo sembra solo aumentare.

Gran parte del lavoro svolto nell'ingegneria del software di programmi per computer non banali si concentra sulla complessità dell'addomesticamento e lo rende accessibile al maggior numero possibile senza dedicare prima una vita all'apprendimento.

Esempi:

• Modularizzazione: rendi i programmi concettualmente più semplici avendo moduli di codice, in cui ogni modulo conosce solo un po 'di altri moduli (anziché ad esempio un'icona del mouse che disegna il routing che consente di manipolare direttamente i buffer della scheda di rete).
• API: forniscono un percorso di utilizzo semplice ai programmi complessi dietro le API. Quando apri un file non ti interessa che le condivisioni di rete vengano gestite in modo diverso da un disco USB. L'API è la stessa.
• Orientamento agli oggetti. Ciò consente di riutilizzare il codice esistente e farlo funzionare in modo trasparente con il nuovo codice aggiunto, nascondendo comunque tutta la complessità sottostante.

In altre parole, è necessario conoscere molti trucchi se si desidera lavorare su software non banali, da soli o (molto probabilmente) con altri.

Sì, principalmente perché forse le due piattaforme di sviluppo più popolari utilizzate nello sviluppo commerciale (Java e .NET) sono orientate agli oggetti e questo significa sì, OO è usato molto (incluso polimorfismo, eredità e tutto il resto).

Le aziende non si preoccupano specificamente dell'orientamento agli oggetti come tecnologia: questa non è una cosa ideologica, si preoccupano delle persone che possono sviluppare soluzioni ai loro problemi in modo che si allineino con la loro strategia IT.

Ma non mi preoccuperei troppo di sentire che è un punto debole. Senza mancare di rispetto alla tua istruzione, la maggior parte delle persone nel mondo commerciale non vede i programmatori che lasciano l'università (a qualsiasi livello) come l'articolo finito. Ti resta ancora molto da imparare e questo è compreso (probabilmente meglio dalle aziende che dagli studenti).

Come nella vita reale, la programmazione della vita reale differisce da quella teorica.

Sì, se mantieni il paradigma OO lucido e sempre dietro la tua mente, puoi fare meglio a scrivere codice che sia gestibile, comprensibile e facilmente estensibile.

Sfortunatamente, il mondo reale ha questo:

• pressioni temporali del progetto
• membri del team orientati proceduralmente
• team incrociati, più fornitori
• codice legacy che non ha alcun orientamento
• finché funziona, alcuni si preoccupano di come viene scritto il codice
• anche se il codice non funziona, la motivazione è risolverlo, non "OO"
• moduli, limitazioni della piattaforma, framework che semplicemente non ti permettono di fare buone OO

In un vero lavoro, devi lavorare con i problemi di cui sopra. Sembra demoralizzante. Ma tratta questo come un avvertimento. Le società di collocamento attribuiscono troppa importanza a OO durante l'assunzione. È facile capire perché. L'unico modo in cui possono testare il candidato è chiedere informazioni sulla comprensione di OO. E sfortunatamente, molti candidati si limitano a rispolverare quelle domande prima di presentarsi per un colloquio.

OO nella vita reale arriva lentamente. Aiuta se continui a leggere e a migliorarlo nel tempo.

Ho avuto la stessa sensazione dopo aver finito la mia laurea, e un grande libro che mi ha mostrato perché e come OOP è rilevante per le applicazioni del mondo reale è Head First: Design Patterns . Consiglio vivamente di dare una sbirciatina, è scritto in un modo davvero divertente e fa un sacco di punti validi sul perché un approccio OOP è desiderabile quando si lavora con sistemi su larga scala, in continua evoluzione.

Anche per alcuni lavori in C, potrebbe essere necessario conoscere la progettazione orientata agli oggetti (e probabilmente essere più brava rispetto a se il compilatore lo avesse fatto per te), come evidenziato da una recente serie di articoli sulla progettazione orientata agli oggetti nel kernel Linux. ( Parte 1 , Parte 2 )

GTK + utilizza anche molti modelli di design orientati agli oggetti.

Devo esprimere un certo disaccordo con l'idea che OO sia tutto - si potrebbe dire che OO ti consente di costruire città, ma i programmi procedurali sono i mattoni.

Per dare la mia risposta sotto forma di un'analogia, un oggetto generale ha bisogno di oggetti, il soldato ha bisogno di un procedimento. Una volta approfondito abbastanza in OO trovi le procedure e, se questa è la tua esperienza e sei abbastanza bravo, non preoccuparti di OO, perché è abbastanza facile per qualcuno scrivere questo codice del gioco di scacchi OO:

-findBestMove
-makeBestMove
-waitForPlayerInput

ma poi qualcuno deve scrivere il codice dietro -findBestMove e puoi essere sicuro che non sia solo questo:

foreach $move (@moves){
    $bestMove = ($move > $bestMove ? $move : $bestMove)
}
return $bestMove

D'altra parte, se non sai come leggere il codice OO, preoccupati. Perché puoi essere sicuro (quasi) che il tuo codice farà casino con oggetti di qualche tipo. A meno che tu non lavori al colosso ereditario fortran di 12000 var globali e 1200 "moduli" di linea che attualmente mantengo.

Jon Hopkins ha scritto:

Sì, principalmente perché forse le due piattaforme di sviluppo più popolari utilizzate nello sviluppo commerciale (Java e .NET) sono orientate agli oggetti e questo significa sì, OO è usato molto (incluso polimorfismo, eredità e tutto il resto).

Il che è praticamente quello che stavo per dire, ma non è solo Java e .Net, il C ++ è ovunque, Objective-C è su OSX, tutti i ragazzi carini stanno facendo Ruby o Python, e tutte queste cose e molte molte più si concentrano sull'orientamento agli oggetti. Molte nuove lingue sono multiparadigm, quindi qualcosa come F # è principalmente un linguaggio funzionale, ma supporta anche l'orientamento agli oggetti. È ovunque e avere almeno una certa comprensione è molto utile. Non preoccuparti troppo, però, avendo appena completato i corsi universitari, sei pronto per iniziare a imparare a sviluppare codice nel mondo reale :)

Ho programmato per molto tempo e trovo che i concetti di OO siano utili anche durante la programmazione in C - anche se se testato probabilmente non riuscirei a descrivere questi concetti in ogni piccolo dettaglio. A un certo punto, ho persino creato un linguaggio OO, anche se rudimentale, per orientare i concetti e trovare divertimento in OO da una nuova prospettiva.

A proposito, C ++ ha fatto un casino enorme e brutto di OO, mentre Obiettivo C lo fa bene.

A proposito di interviste, sono diventati uno spettacolo horror - da entrambi i lati del tavolo. La maggior parte degli intervistati è molto spaventata da loro. La maggior parte dei responsabili delle assunzioni è stupita da quante persone falliscono anche i test di programmazione molto basilari.

Detto questo, ci sono alcune enormi valigie che lavorano nel settore del software in questo momento che non sanno NIENTE e tuttavia si aspettano il mondo da potenziali dipendenti.

L'apprendimento di OOP non è utile quanto lo sviluppo di software di apprendimento. Vai a leggere Codice completo 2 .

Certo, è uno strumento utile ma OOP stesso è davvero piccolo. In generale, quando le aziende e i recruiter dicono "OOP" intendono "Sviluppo software". Viene utilizzato come termine generico.

I veri recruiter diranno la differenza tra te che sai come sviluppare software e abbinare la casella di spunta "Ha 3 anni in 'OOP'".

La risposta è sì, come molti altri hanno notato.

MA, se vuoi lavorare su pile di codice spaghetti procedurale non OO, puoi scoprirlo anche lì. Penso che preferirai il lavoro OO.

EDIT: perdona il mio caso di cinismo dei pistoleri e senso dell'umorismo. Come ha detto Raynos, solo perché qualcosa è OO non significa che sia buono. La corretta applicazione di OO richiede lavoro e pensiero reali; il solo fatto di avere istanze non significa automaticamente che un'app sia ben realizzata. E viceversa, sono sicuro che ci sia un codice procedurale ben scritto là fuori. La mia esperienza nei negozi IT aziendali negli anni '90 e 2000 è stata che molti codici errati sono stati scritti e probabilmente esistono ancora. Ma più vicino alla domanda del PO, ho notato che gli sviluppatori più intelligenti, quando ne hanno la possibilità, si stanno spostando su più sistemi OO.

OO è una base fondamentale su cui sono costruite altre tecniche. Un punto chiave è innanzitutto comprendere appieno la differenza tra un tipo (classe) e un'istanza di quel tipo. Non cercare di continuare a leggere senza averlo compreso appieno (pensando che diventerà più chiaro in seguito), perché dovrai rileggere tutto il resto una volta catturata la visione.

Una volta capito, non vorrai più farne a meno. Non sono un purista quando si tratta di incapsulamento, schemi, strutture o altro. Sul lavoro, dovrai adattarti a vari punti di vista e concetti. Elencherò alcune mie precedenti esperienze lavorative:

In una società, i miei colleghi volevano il più possibile il caricamento lento (costruttori vuoti, proprietà ingombranti che dovevano verificare ovunque valori null). Stavano costruendo oggetti lato server basati sul web che hanno vissuto una vita breve.

Il lavoro successivo fu totalmente opposto. Gli oggetti vivevano all'interno di un'applicazione desktop (basata su Excel). Il maggior numero possibile di inizializzazioni dovrebbe essere nel costruttore (o in uno dei tanti sovraccarichi del costruttore). Costruttori vuoti non erano ammessi poiché gli oggetti vuoti non avevano il diritto all'esistenza (il che rendeva la persistenza una vera sfida). Inoltre, mi sono dovuto adattare ai loro "standard di stile di codifica" (dove aprire parentesi, aggiungere spazi bianchi dopo commenti, ecc ...), perché il mio codice non poteva essere verificato se non riusciva a superare lo stile-poliziotto.

Attualmente sto lavorando in un'azienda in cui nessuno degli sviluppatori ha mai provato a capire OO. È difficile esprimere quanto sia stato estremamente frustrante. Ho dovuto migliorare le mie abilità in Grep, infatti ho una macro HotScripts assegnata al mio tasto F12 per fare un grep sul testo selezionato. Risparmierò le altre frustrazioni ...

Una volta acquisite le abilità OO, sarai quasi allergico agli spaghetti! Tuttavia, in tutti i casi, OO o no, sii paziente e adatta. Sii riluttante a "buttarlo via e ricominciare". Il tuo capo preferirà scegliere te quando si tratta di buttare fuori. Sfortunatamente "fare soldi" è più importante del codice elegante.

Ci scusiamo per la lunga risposta, ma ho cercato di coprire gran parte dell'ambito della tua domanda :-)

OOP non è importante per se stesso, ma per ciò che ne consegue. Qualcosa che riguarda la capacità di astrarre e isolare, raggruppare le cose insieme espone solo le parti che sono necessarie per interagire insieme.

Questa è una tecnica di ingegneria comune chiamata "modularizzazione", che consente di creare sistemi complessi come aggregazione di quelli più semplici, senza occuparsi di ogni singolo dettaglio ad alto livello e che richiedono che i componenti siano sostituibili, anche senza che siano esattamente i stesso.

Questi "concetti di ingegneria" sono stati tentati di essere mantenuti nello sviluppo del software dal momento in cui il prodotto software era diventato più grande della "capacità di singolo sviluppatore", richiedendo così un modo per far lavorare gli sviluppatori su pezzi indipendenti e lasciare che interagire insieme.

Detto questo, quei principi non si trovano necessariamente solo in OOP (se la teoria del calcolo è valida, ci sono infiniti metodi possibili per arrivare a quei risultati).

OOP è semplicemente un tentativo riuscito di mettere insieme queste cose, dando a quei termini generali (come moduli, incapsulamento, sostituzione) definizioni più precise ed elaborata concettualizzazione su quelle definizioni (schemi) che possono adattarsi ai linguaggi di programmazione.

Pensa a OOP prima non come una " caratteristica del linguaggio " ma come un " lessico comune " che avvicina gli ingegneri del software alla progettazione del software.

Il fatto che un determinato linguaggio abbia o meno primitivi che impongono direttamente quel lessico garantendo, ad esempio, che una "capsula" non venga aperta inavvertitamente da chi non dovrebbe farlo è un aspetto secondario della progettazione di OOP. Ecco perché anche i grandi progetti C sono spesso "gestiti come" OOP, anche se la lingua stessa non offre alcun supporto diretto a questo.

Il vantaggio di tutto ciò che non è riconoscibile fino a quando le dimensioni di un progetto non rimangono nella capacità del singolo sviluppatore di comprendere e tracciare tutto ciò che fa (in effetti, in quelle situazioni può anche essere visto come "sovraccarico") o in un piccolo gruppo che sviluppa qualcosa in un breve periodo. E questa è la ragione principale per cui i giovani che hanno studiato OOP in termini di "caratteristica del linguaggio" spesso interpretano erroneamente producendo codice mal progettato.

Il modo in cui OOP si adatta alle lingue dipende da come i designer linguistici interpretano il principio OOP nel loro costrutto.

Quindi "incapsulamento" in C ++ diventa "membri privati" (e una "capsula" diventa una classe), "sostituzione" diventa funzione virtuale o modello parametrizzazione / specializzazione ecc., Mentre in D una capsula è un "modulo" (e la sostituzione va attraverso classi ecc.), rendendo così determinati paradigmi o modelli direttamente disponibili in una determinata lingua e non in un'altra e così via.

Ciò che i recruiter cercano di porre una domanda OOP è semplicemente verificare la tua capacità di astrarre e concedere la progettazione del software per progetti e sviluppi futuri di grandi dimensioni. OOP, per loro è solo un "dizionario" che entrambi sapevano che tu e loro conoscete in modo da poter parlare di altre cose più generali o concretizzare in una specifica implementazione.

Un linguaggio orientato agli oggetti ti aiuta a mantenere un design orientato agli oggetti nel tuo codice, il che è positivo. Ma è anche vero che un tale design può essere ottenuto con qualsiasi altro linguaggio paradigmatico: la ragione della popolarità (specialmente tra le aziende) dei linguaggi OO sta probabilmente nel successo commerciale di Java e C #.

Se il signor Gates avesse fondato la sua compagnia nel modo giusto, probabilmente avremmo studiato SCHEME prima di fare domanda per un lavoro.

La risposta breve è Sì

La versione più lunga del motivo per cui ti senti o in un dilemma sul perché è importante solo perché non hai lavorato su progetti o implementazioni che hanno qualche scopo. È perfettamente valido nelle aule scolastiche avere esempi su Automobile poi estesi ad Auto, Camion ... ma quando si passa allo sviluppo del software è una soluzione mirata per facilitare alcune attività. Ora, se non fosse perché OOavremmo tutti scrivere codici simili attraverso la base di codice oreinventare le ruote ogni giorno. Immagina che confusione sarebbe se uno si immergesse in una tale base di codice per sistemare qualcosa. Gli esempi di classe sono per una definizione vaga o una rappresentazione di come / perché è fatto. Il vero test termina quando inizi a creare la tua app, senza dubbio come qualsiasi cosa possa essere terribilmente utilizzata, ma di gran lunga pesa la sanità mentale a causa del suo utilizzo chiaro e conciso. Quindi, meglio iniziare a lavorare su queste aree deboli, almeno si sfornano codici da incubo.

Dipende. Uno dei motivi per cui devi conoscere OO perché è la lingua franca del mondo della programmazione. Come sottolinea un'altra risposta, quasi ogni lingua principale è in qualche modo OO, il che significa che praticamente qualsiasi azienda che potrebbe assumerti sta usando una lingua OO. Hai mai provato ad assumere programmatori OCaml? È impossibile; il pool di talenti è troppo piccolo. Se hai avviato la tua azienda utilizzando OCaml e la tua azienda ha successo, non sarai in grado di assumere programmatori abbastanza velocemente e andrai fuori dal mercato. Pertanto, quasi tutte le aziende con più di 3 programmatori utilizzano un linguaggio OO e per comunicare con i colleghi e utilizzare le librerie della piattaforma, è necessario conoscere OO.

A seconda del linguaggio specifico utilizzato dall'azienda, l'ereditarietà e il polimorfismo sono estremamente importanti o solo moderatamente rilevanti. Non puoi fare nulla in Java senza svelare 10 modelli di progettazione GoF e un framework di iniezione delle dipendenze. Java è uno dei linguaggi più utilizzati, quindi i principi di OO sono davvero importanti per le molte aziende che usano Java.

Se la società utilizza un moderno linguaggio OO / funzionale ibrido che ha lambda e puntatori di funzioni, come Scala o C #, l'eredità diventa improvvisamente meno importante perché hai funzioni di ordine superiore per gestire molte delle cose davvero semplici che altrimenti richiederebbero un sacco di cerimonia. Tuttavia, devi comunque essere in grado di lavorare con le cose OO perché la maggior parte delle librerie che usi saranno scritte in modo OO.

Se l'ereditarietà e il polimorfismo non sono importanti per l'azienda, è comunque probabile che tu riceva domande sull'OO perché:

• Sei intervistato da una persona delle risorse umane che non sa nulla di programmazione e fa domande da una lista di controllo. Hai 3 anni di X, sei multitasking, ecc.
• Sei intervistato da un ingegnere che vuole assicurarsi di non aver vissuto sotto una roccia. OO è la lingua franca, quindi ti verranno poste alcune domande superficiali al riguardo.
• Sei intervistato da un ingegnere che non è molto abile nell'intervista. In generale, gli ingegneri adorano le curiosità e la complessità, quindi avrai molte domande sul polimorfismo, l'eredità e i modelli di progettazione GoF solo perché queste cose sono interessanti per la persona che ti sta intervistando.

In una parola "Sì".

Potresti pensare di conoscere la teoria, ma devi scrivere del codice e metterlo in pratica. Ci sono - letteralmente - migliaia di esempi ed esercizi disponibili online.