"Troppo orientato agli oggetti"

Non ti sei lamentato del fatto che sia impossibile da mantenere, solo che non è di tuo gradimento. Se si tratta di una scelta di stile deliberata, potrebbe essere solo un caso di differenze creative inconciliabili e dovresti adattare il tuo stile per adattarlo o trovare un posto che si adatti al tuo stile preferito.

Le persone possono scrivere e scrivere codice modulare, efficiente, ben astratto, relativamente privo di bug in uno stile procedurale tutto il tempo. Java è una strana scelta di linguaggio per un negozio del genere, ma posso vederlo accadere se fattori esterni decidessero la lingua, ad esempio, come per lo sviluppo di Android, per esempio.

Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid. — Albert Einstein

Se era una scelta deliberata, non puoi giudicarli realmente in base alla loro adesione a buoni principi di progettazione orientati agli oggetti, dovresti giudicare dal modo in cui aderiscono ai buoni principi procedurali di progettazione e anche il refactoring di conseguenza. Java non ti permette di scrivere codice al di fuori di una classe, quindi la semplice presenza di uno non significa che intendessero un modulo orientato agli oggetti.

D'altro canto, se il codice è un disastro nel paradigma o , dovresti probabilmente tagliare le perdite.

Leggendo la tua domanda, ho ricordato un suggerimento del libro Pragmatic Programmer.

Uno dei suoi suggerimenti è Be a Catalyst for Change :

You may be in a situation where you know exactly what needs doing and how to do it. The entire system just appears before your eyes—you know it's right. But ask permission to tackle the whole thing and you'll be met with delays and blank stares. People will form committees, budgets will need approval, and things will get complicated. Everyone will guard their own resources. Sometimes this is called "start-up fatigue."

It's time to cook Stone Soup. Work out what you can reasonably ask for. Develop it well. Once you've got it, show people, and let them marvel. Then say "of course, it would be better if we added…." Pretend it's not important. Sit back and wait for them to start asking you to add the functionality you originally wanted. People find it easier to join an ongoing success. Show them a glimpse of the future and you'll get them to rally around.

Quindi, penso che se inizi a fare un buon lavoro con la tua conoscenza OO e TDD, presto inizieranno a guardare e a chiedere del tuo lavoro.

Per vendere nuovi modi di lavorare, è necessario mostrare evidenti benefici. Scrivere più livelli di astrazione, senza un chiaro vantaggio ma una vaga: "può essere utile per il futuro" non funzionerà.

Crea fabbriche in cui le fabbriche producono più di un tipo di oggetto. Utilizzare l'iniezione di dipendenza, dove mostra immediatamente benefici. Crea interfacce che verranno implementate da più di una classe.

Quello che vedo troppo spesso in "OO vero" è che vengono utilizzate tecniche avanzate per risolvere problemi davvero semplici in un modo eccessivamente complesso.

Come puoi mostrare il beneficio di una fabbrica se realizzerà sempre lo stesso oggetto? Trova un problema nel codice che benefici delle tecniche avanzate e mostra il tuo punto di vista e lavora da lì.

Le guerre vengono vinte una battaglia alla volta.

Puoi solo convincerli assumendo una piccola porzione di codice e implementando TDD e migliori pratiche OO su di esso per realizzare i benefici. Li hai condotti nella terra promessa, non solo mostrare belle cartoline di esso.

Certamente, penso che ci siano casi di astrazione eccessiva in uso in molte basi di codice oggi. Inserisci solo ciò di cui hai bisogno e anche le astrazioni.