È possibile progettare e costruire con successo un'applicazione procedurale (imperativa)?

Question

Potete fornire oggi esempi di applicazioni che sono procedurali e mantengono un alto livello di integrità ed efficienza? Ci sono libri, tutorial o link che forniscono esempi su come costruire e mantenere con successo un sistema imperativo? Se dovessi dare una guida in questo settore, quali consigli daresti su come dovrebbe essere strutturato? Chiedo perché OOP è spesso presentato come una naturale progressione della programmazione procedurale, ma ho difficoltà a credere che sia sempre così.

Answer 1

Esempi di applicazioni procedurali riuscite ??

Intendi dire, per esempio, il kernel Linux? Kernel BSD? Server web Apache? La grande mole dei programmi di utilità utente di Unix? Applicazioni del genere?

Naturalmente le tecniche OOP hanno valore nell'organizzazione, nella manutenibilità e nelle astrazioni all'interno del software, ma anche oggi OOP è probabilmente un sottogruppo di minoranza di tutto il codice e le applicazioni scritte oggi.

Prendi in considerazione tutto il codice Java o C # o VB che, mentre è scritto in un linguaggio di programmazione compatibile con OOP, l'unica ragione per cui sta usando molta tecnica OOP è di interagire con librerie o sistemi esterni. Nel frattempo le applicazioni stesse, pur sfruttando i framework OOP, sono probabilmente abbastanza procedurali nella progettazione e nell'implementazione.

OOP è un ottimo paradigma, ma in realtà non è realmente necessario per la maggior parte della logica in molti sistemi.

Answer 2

Anche se non posso puntare direttamente su alcun sistema esistente, ci sono enormi quantità di sistemi aziendali legacy scritti prima di OO COBOL. Molti programmi classici 4GL sono procedurali e mirano all'ingegneria dei sistemi ad alta integrità. Alcuni sono ben scritti, altri non così tanto.

I libri includono " COBOL da Micro a mainframe " ;, " Guida alla programmazione Enterprise COBOL. "

I consigli strutturali su un buon codice imperativo sono simili alle tecniche OO: nominare bene le cose, separare le tue preoccupazioni, non ripetere te stesso, principio di responsabilità singola, non lasciare incustodite le finestre rotte.

In effetti, suggerirei semplicemente di leggere il "Programmatore pragmatico" darebbe alla maggior parte delle persone l'idea giusta in qualsiasi paradigma.

Per quanto riguarda un motivo convincente per passare a OO per applicazioni orientate al business; i linguaggi procedurali consentono un script di transazione alla logica di dominio, mentre i linguaggi OO consentono l'app < href = "http://martinfowler.com/eaaCatalog/domainModel.html" rel = "nofollow noreferrer"> modello di dominio approccio.

Certamente per semplici esercizi, non è necessario utilizzare le lingue OO, ma non appena la complessità aumenta, la manutenibilità delle lingue OO vince sui linguaggi procedurali con un basso sovraccarico.