Come applicare uno dei concetti OOP (Chiuso per modifica e Aperto per estensione)?

Non vedo perché vorresti essere così pignolo riguardo ai principi OOP. OOP è fantastico, ei principi sono validi, ma poi di nuovo ogni progetto ha le sue particolarità. Voler essere OOP-perfetto a tutti i costi mi sembra un inconveniente.

Più codice, più flessibile sono con questi principi. Non sono qui per rendere la vita più difficile, sono qui per rendere più pulito il tuo codice. Se il tuo codice è pulito e ha un senso, al diavolo i principi.

Aggiunta di un metodo di "suggerimento" alla tua classe di domande, che non restituisce nulla se non c'è alcun suggerimento o che non viene chiamato dalle tue app che non ne hanno bisogno, non modifica nulla alla portabilità del tuo codice e il tuo impegno verso OOP.
Per quanto riguarda l'estensione della classe di domande, mi sembra che tu stia avendo un problema di nomenclatura. Il tuo problema è che se chiami la tua estesa domanda "suggerimento", non ha senso perché il suggerimento non è una domanda. Ma in quel caso, se la tua classe estesa, invece di "suggerimento", fosse chiamata "question_with_hint", allora avrebbe senso, giusto? Lo chiami "suggerimento" solo per renderlo più breve e più utilizzabile. Chiamalo "question_extended" se ti aiuta.

Astrazione

Ci sono due modi per aderire al principio Open-Closed. La definizione originale del principio prevedeva che si usasse l'ereditarietà, ma questo ha portato a problemi con grandi alberi di classi ereditate, solo per aggiungere un campo come si sta facendo. Come dice Xananax, potresti renderlo "corretto" nominando la classe QuestionWithHint, ma che cosa fare quando vuoi aggiungere tag, ecc.?

Uncle Bob ha scritto un pezzo nel '96 che descrive un altro approccio, che era diventato popolare da allora , dove si rinomina la classe QuestionWithoutHint, estrarre un'interfaccia Domanda dalla classe QuestionWithoutHint e quindi crearne una nuova chiamata QuestionWithHint, implementando anche Domanda. Puoi quindi sostituirlo con il codice finché non ci saranno più riferimenti a QuestionWithoutHint e sbarazzarti di quella classe, rinominando la nuova in qualcosa di più semplice (QuestionImpl).

Questo è il modo più moderno per aderire all'OCP.

Tuttavia, è mia ferma convinzione che ciò dovrebbe essere fatto solo nei casi in cui la logica viene sostituita, non per aggiungere nuovi campi / proprietà, in cui il codice esistente che utilizza la classe non verrà modificato. Questo è, dopo tutto, il problema che l'OCP mira a risolvere.

Non vedo l'OCP che si applica molto alle classi di dominio, ma più alle classi di applicazioni e servizi. Non lasciare che OCP ti impedisca di costruire il dominio in fasi evolutive. Notate invece come emergono i pattern nel modo in cui si usano le librerie esterne (le librerie standard, JDBC, JMS, Servlet, JSP e così via), quindi li spingono in classi di adattatore semplici che diventano sempre più chiuse nel tempo.