La programmazione OO è tanto importante quanto lo richiedono le società di collocamento? [chiuso]

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

Questo breve periodo non è sufficiente per rendere chiaro l'obiettivo di OOP, specialmente se le persone coinvolte nel progetto sono principianti. Ma attenersi a qualche modellizzazione è cruciale per i grandi progetti, direi > 50.000 linee di codice. OOP non è l'unica soluzione a questo, ma questo è il più utilizzato nel settore.

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

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

Poiché queste cose non sono apprese a scuola, esiste una variazione semplicemente enorme di conoscenze tra candidati diversi. E siamo i più onesti: non penso che qualcuno con una scarsa conoscenza in OOP possa lavorare su qualsiasi grande progetto, semplicemente perché richiederebbe agli sviluppatori di lead più tempo per gestire queste persone piuttosto che scrivere semplicemente il codice stesso.

Se non pensi ancora a "OOP", ti suggerirei di leggere alcuni libri su di esso e applicarli in società che non hanno progetti veramente grandi; abituarsi a OOP continuando a fare un lavoro utile per il tuo datore di lavoro (e fintanto che ti dà il tuo stipendio, questo sarà utile anche per te).

EDIT: ha, e vorrei aggiungere che ho già scritto il codice OOP in C, anche se non è l'uso più comune di C, questo è possibile con una conoscenza approfondita. Devi solo costruire vtables manualmente.

E dietro la tecnica OOP, qualcosa è nascosto: progettazione del software. La progettazione del software è davvero utile, in C come in qualsiasi altra lingua. Molti reclutatori metteranno alla prova le tue competenze di progettazione del software e la domanda OOP andrà bene, 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 dei computer è la gestione della 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 informatici non banali si concentra sulla complessità del domare e lo rende accessibile al maggior numero possibile senza dedicare prima una durata dell'apprendimento.

Esempi:

• Modularizzazione: i programmi si semplificano concettualmente con moduli di codice, in cui ogni modulo conosce solo un po 'di altri moduli (invece, ad esempio, il routing di un'icona del mouse può manipolare direttamente i buffer delle schede di rete).
API
• : forniscono un percorso di utilizzo semplice per i programmi complessi dietro le API. Quando apri un file non ti interessa che le condivisioni di rete siano gestite diversamente da un disco USB. L'API è la stessa.
• Orientamento all'oggetto. Ciò ti consente di riutilizzare il codice esistente e farlo funzionare in modo trasparente con il nuovo codice che aggiungi, nascondendo comunque tutta la complessità sottostante.

In altre parole, conoscere molti trucchi è necessario se vuoi lavorare su software non banali, da solo 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 il polimorfismo, l'ereditarietà e tutto il resto).

Le aziende non si preoccupano specificamente dell'orientamento agli oggetti come tecnologia - questa non è una questione di ideologia, bensì di persone che possono sviluppare soluzioni ai loro problemi in modo da allinearsi alla 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 lasciare l'università (a qualsiasi livello) come l'articolo finito. Hai ancora molto da imparare e questo è comprensibile (probabilmente meglio dalle aziende rispetto agli studenti).

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

Sì, se mantieni il paradigma OO lucido e sempre nella parte posteriore della 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 alla procedura
• team con più sedi, più fornitori
• il codice precedente non ha alcun orientamento
• finché funziona, alcuni si preoccupano di come il codice è scritto
• anche se il codice non funziona, la motivazione è di correggerlo, non di "OO"
• moduli, limiti della piattaforma, framework che semplicemente non ti permettono di fare un buon OO

In un vero lavoro, devi lavorare con i problemi precedenti. Questo suona demoralizzante. Ma, considera questo come un testa a testa. Le società di noleggio danno troppa importanza a OO durante l'assunzione. È facile capire perché. L'unico modo in cui possono testare il candidato è chiedere la comprensione di OO. E sfortunatamente, molti candidati rispolverano queste domande prima di presentarsi per un colloquio.

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

Ho avuto la stessa sensazione quando ho 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 . Vi raccomando sinceramente di dare una sbirciatina, è scritto in un modo davvero divertente e fornisce molti validi punti sul perché un approccio OOP sia desiderabile quando si lavora con sistemi su larga scala e in continua evoluzione.

Anche per alcuni lavori in C, potrebbe essere necessario conoscere la progettazione orientata agli oggetti (e probabilmente è meglio farlo se non che il compilatore lo ha fatto per te), come evidenziato da una recente serie di articoli sul design orientato agli oggetti nel Kernel Linux. ( Parte 1 , Parte 2 )

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

Devo esprimere un certo disaccordo con questa nozione secondo cui OO è tutto - si potrebbe dire che OO ti permette di costruire città, ma i programmi procedurali sono i mattoni.

Per dare la mia risposta sotto forma di analogia, un generale ha bisogno di oggetti, il soldato ha bisogno di procedurali. Una volta che hai eseguito il drill down 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 di gioco degli scacchi OO:

-findBestMove
-makeBestMove
-waitForPlayerInput

ma poi qualcuno deve scrivere il codice dietro -findBestMove e puoi essere certo che non è 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 non lavori sul colosso di Fortran legacy di 12000 vars globali e 1200 "moduli" di linea che attualmente mantengo.

Jon Hopkins ha scritto:

Yes, primarily because perhaps the two most popular development platforms used in commercial development (Java and .NET) are object oriented and that means yes, OO is used a lot (including polymorphism, inheritance and everything else).

Che è più o meno quello che stavo per dire, ma non è solo Java e .Net, C ++ è ovunque, Objective-C è tutto su OSX, tutti i ragazzi fantastici stanno facendo Ruby o Python e tutte queste cose e molti altri ancora si concentrano sull'orientamento agli oggetti. Un sacco di lingue più recenti 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 ti preoccupare troppo, avendo appena completato i corsi universitari significa che sei pronto per iniziare a imparare a sviluppare codice nel mondo reale:)

Ho fatto programmazione per un lungo periodo, e trovo che i concetti di OO siano utili anche quando si programma in C - anche se in fase di test probabilmente non riuscirei a descrivere quei concetti in ogni piccolo dettaglio. A un certo punto, ho persino creato un linguaggio OO, anche se rudimentale, per capire i concetti e trovare il godimento in OO da una nuova angolazione.

BTW, C ++ ha creato un enorme e brutto pasticcio di OO, mentre l'Objective C ha ragione.

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 sono sbalorditi dal numero di persone che non superano anche i test di programmazione di base.

Detto questo, ci sono alcuni enormi sacchetti di spazzatura che lavorano nell'industria del software in questo momento che non conoscono NULLA eppure si aspettano il mondo da potenziali dipendenti.

L'apprendimento dell'OOP non è utile come lo sviluppo del software di apprendimento. Leggi codice completo 2 .

Certo è uno strumento utile, ma lo stesso OOP è veramente piccolo. In generale quando le aziende e i reclutatori dicono "OOP" intendono "sviluppo del software". Viene utilizzato come termine generico.

I veri reclutatori diranno la differenza tra voi sapendo come sviluppare software e abbinare la casella di controllo "Ha 3 anni in" OOP ".

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

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

EDIT: Perdona il mio caso per il cinismo e il senso dell'umorismo del pistolero. Come ha detto Raynos, solo perché qualcosa è OO non significa che sia buono. La corretta applicazione di OO richiede lavoro e pensiero reali; solo avere delle istanze non significa automaticamente che un'app sia ben fatta. E al contrario, sono sicuro che ci sia un codice procedurale ben scritto là fuori. La mia esperienza nei negozi IT aziendali negli anni '90 e '000 è stata che un sacco di codice cattivo è stato scritto e probabilmente esiste ancora. Ma più vicino alla domanda dell'OP, ho notato che gli sviluppatori più intelligenti sono, quando ne hanno la possibilità, il passaggio a più sistemi OO.

OO è una base fondamentale su cui sono costruite altre tecniche. Un punto chiave è comprendere innanzitutto la differenza tra un tipo (classe) e un'istanza di quel tipo. Non provare a leggere senza comprenderlo completamente (pensando che diventerà chiaro più tardi), perché dovrai leggere il resto da capo una volta che hai catturato la visione.

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

In una società, i miei colleghi desideravano il più possibile il caricamento lazy (costruttori vuoti, proprietà voluminose che dovevano verificare la presenza di valori null ovunque). Stavano costruendo oggetti sul lato server basati sul web che hanno avuto una vita breve.

Il prossimo lavoro era totalmente opposto. Oggetti vissuti all'interno di un'applicazione desktop (basata su Excel). Tanto inizializzazione quanto possibile dovrebbe essere nel costruttore (o uno dei tanti sovraccarichi del costruttore). I costruttori vuoti non erano consentiti poiché gli oggetti vuoti non avevano il diritto di esistere (il che rendeva la persistenza una vera sfida). Inoltre ho dovuto adattarmi ai loro "standard di stile di codifica" (dove aprire parentesi, aggiungere spazi bianchi dopo i commenti ecc ...), perché il mio codice non poteva essere archiviato se non passava attraverso style-cop.

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 capacità di 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. Essere riluttante a "buttarlo via e ricominciare". Il tuo capo preferirà sceglierti quando si tratta di buttare fuori. Sfortunatamente "fare soldi" è più importante di un codice elegante.

Ci scusiamo per la lunga risposta ma ho cercato di coprire gran parte della portata della tua domanda: -)

OOP non è importante a causa di se stesso, ma per quello che serve con esso. Qualcosa che riguarda la capacità di astrarre e isolare, raggruppare le cose insieme terminano di esporre solo le parti che sono necessarie per interagire insieme.

Questa è una tecnica di ingegneria comune chiamata "modularizzazione", che consente di creare sistemi complessi come l'aggregazione di quelli più semplici, senza prendersene cura ogni singolo dettaglio ad alto livello e che richiede componenti sostituibili, anche senza di loro essere esattamente uguali.

Questi "concetti ingegneristici" sono stati tentati di essere mantenuti nel software sviluppo dal momento in cui il prodotto software stesso era diventato più grande del "capacità di sviluppatore singolo", che richiede quindi un modo per far funzionare gli sviluppatori su pezzi indipendenti, e lascia che questi pezzi interagiscano insieme.

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

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

Pensa prima a OOP non come " lingua " ma come " lessico comune " che rende gli ingegneri del software avvicinarsi alla progettazione del software.

Il fatto che una determinata lingua abbia o no delle primitive che la applicano direttamente lessico che garantisce, ad esempio, che una "capsula" non viene aperta inavvertitamente da chi non lo è dovrebbe farlo è un aspetto secondario del design OOP. Ecco perché anche un grande progetto C viene spesso "gestito come" OOP, anche se la lingua in sé non offre alcun supporto diretto.

Il vantaggio di tutto ciò non è riconoscibile fino a quando non rimarrà una dimensione del progetto la capacità di un singolo sviluppatore di comprendere e tracciare tutto ciò che fa (in effetti, in quelle situazioni può anche essere visto come "overhead") o in un piccolo gruppo che sviluppa qualcosa in un breve periodo. E questo è il motivo principale per cui i juniores hanno studiato l'OOP in termini di "funzionalità linguistica" spesso lo interpretano male producendo codice progettato male.

Il modo in cui OOP si adatta alle lingue dipende da come interpretano i linguisti il principio OOP nel proprio costrutto.

Quindi "incapsulamento" in C ++ diventa "membri privati" (e una "capsula" diventa una classe), la "sostituzione" diventa sovrascrittura delle funzioni virtuali o parametrizzazione / specializzazione del modello ecc. mentre in D una capsula è un "modulo" (e la sostituzione passa attraverso le classi ecc.), quindi rendendo certi paradigmi o schemi direttamente disponibili in una determinata lingua e non in un altro e così via.

Ciò che i reclutatori cercano nel porre la domanda OOP è solo verificare la tua capacità di progettazione software astratta e intuitiva per grandi progetti e sviluppi futuri. OOP, per loro è solo un "dizionario", hanno supposto che sia tu che loro conoscete questo puoi parlare di altre cose più generali o concretizzare in un'implementazione specifica.

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

Se Mr. Gates avesse avviato la sua azienda nel modo giusto, probabilmente avremmo studiato lo SCHEME prima di fare domanda per un posto di lavoro.

Risposta breve è Sì

La versione più lunga perché ti senti o in un dilemma sul motivo per cui è importante solo perché non hai lavorato su progetti o implementazioni che hanno un qualche scopo. È perfettamente valido in classe per avere esempi sull'Automobile, quindi esteso a Car, Trucks ... ma quando si entra nello sviluppo del software si tratta di una soluzione mirata alla facilità di alcune attività. Ora se non fosse per OO avremmo tutti che scrivono codici simili attraverso il codice base o reinventando le ruote ogni giorno. Immagina cosa sarebbe un disastro se uno si tuffasse in un tale codice per sistemare qualcosa. Gli esempi di classe sono per una vaga definizione o rappresentazione di come / perché è fatto. Il vero test è fuori quando si inizia a costruire la tua app, senza dubbio come qualcosa che potrebbe essere terribilmente usato, ma che ben pesa la sanità mentale a causa del suo uso chiaro e conciso. Quindi, prima di iniziare a lavorare su queste aree deboli, è meno importante sfornare codici di incubo.

Dipende. Una ragione per cui devi conoscere OO perché è la lingua franca del mondo della programmazione. Come indica un'altra risposta, quasi tutte le lingue principali sono OO in qualche modo, il che significa che praticamente qualsiasi azienda che potrebbe assumerti usa 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 avuto successo, non sarai in grado di assumere programmatori abbastanza in fretta e non farai più affari. Pertanto, quasi tutte le aziende con più di 3 programmatori utilizzano un linguaggio OO e per comunicare con i tuoi colleghi e utilizzare le librerie della piattaforma, è necessario avere una comprensione di OO.

A seconda del particolare linguaggio che l'azienda utilizza, l'ereditarietà e il polimorfismo sono estremamente importanti o solo moderatamente rilevanti. Non è possibile fare nulla in Java senza eliminare 10 schemi di progettazione GoF e un'infrastruttura per le dipendenze. Java è uno dei linguaggi più utilizzati, quindi i principi OO sono davvero importanti per le molte aziende che utilizzano Java.

Se l'azienda utilizza un moderno linguaggio OO / funzionale ibrido con lambda e puntatori di funzioni, come Scala o C #, l'ereditarietà diventa improvvisamente meno importante perché si dispone di funzioni di ordine superiore per gestire molte delle cose veramente semplici che altrimenti richiedono molte cerimonie Tuttavia, devi comunque essere in grado di lavorare con le cose OO perché la maggior parte delle librerie che utilizzi saranno scritte in modalità OO.

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

• Sei intervistato da una persona delle risorse umane che non sa nulla di programmazione e sta facendo domande su una lista di controllo. Hai 3 anni di X, fai il 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 sommarie a riguardo.
• Sei intervistato da un ingegnere che non è molto abile nel colloquio. In generale, gli ingegneri amano le banalità e la complessità, quindi avrai molte domande sul polimorfismo, sull'ereditarietà e sui modelli di progettazione GoF solo perché queste cose sono interessanti per la persona che ti intervista.

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 on line.