È possibile implementare OOP senza utilizzare operazioni di heap estese?

No, OOP non ha nulla a che fare con dove gli oggetti risiedono nella memoria. Ad esempio, le istanze della stessa classe possono essere allocate staticamente, nell'heap o nello stack in C ++. In altre lingue, come Python, la gestione della memoria è quasi trasparente, quindi la domanda di posizione non si applica realmente.

Tecnicamente no, ma "normale OOP" presuppone l'allocazione dinamica, per la quale un heap è un buon meccanismo generale. Potresti sicuramente provare a utilizzare un altro metodo, ma probabilmente finiresti per reinventare l'heap.

Eccessivo, probabilmente no, e direi che un codice orientato agli oggetti ben scritto in linguaggi come il C ++ non deve fare un uso "eccessivo" dell'heap (anche se purtroppo un sacco di codice lo fa), ma è spesso difficile creare codice OOP non banale e tanto meno qualsiasi tipo di codice che mantiene lo stato persistente con effetti collaterali che seguono un modello push / pop rigoroso di allocazione / deallocazione di memoria.

Ad esempio, un editor di immagini come Photoshop potrebbe allocare un oggetto immagine ogni volta che l'utente richiede di creare una nuova immagine e dovrebbe deallocare l'immagine quando l'utente richiede di chiudere l'immagine.

Questo non è nemmeno un esempio di OOP complesso che implica l'incapsulamento o il polimorfismo, ma già non siamo più in grado di utilizzare praticamente un pattern push / pop per allocazione e deallocazione della memoria poiché la memoria viene liberata su richiesta dell'utente, non quando usciamo ambito della funzione che ha assegnato l'immagine.

Ogni volta che hai la necessità di liberare memoria in un modo che è legato agli input esterni determinati in fase di runtime, come l'input dell'utente, non puoi più utilizzare efficacemente uno stack allocator / struttura dati poiché non supporta la rimozione dal centro della struttura dati, solo la parte anteriore / superiore.

Più pratico per me potrebbe essere un linguaggio che raccoglie memoria da una diversa lista libera per ogni tipo di oggetto, anche se questo potrebbe finire riservando molta memoria in anticipo a meno che non possiamo semplicemente usarlo in modo selettivo per gli oggetti dove fa più senso (es: quelli che stiamo allocando in un numero sufficiente).

Mi piacerebbe davvero vedere un tale linguaggio se potesse venire con puntatori a 32 bit su elementi invece che a 64-bit anche se il puntatore indiretto richiede un po 'più di aritmetica, dato che spesso sto facendo quel tipo di cose a molto, traducendo i puntatori a 64 bit in indici a 32 bit in un particolare contesto rispetto a un particolare tipo di dati quando posso anticipare che non avrò bisogno di più di 4,29 miliardi di istanze di quell'oggetto.