Codice di esempio per spiegare il problema di Banana Monkey Jungle di Joe Armstrong [chiuso]


14

Nel libro Coders at work Joe Armstrong affermava che:

Penso che la mancanza di riusabilità arrivi nei linguaggi orientati agli oggetti, non nei linguaggi funzionali. Perché il problema con i linguaggi orientati agli oggetti è che hanno tutto questo ambiente implicito che portano con sé. Volevi una banana, ma quello che hai ottenuto è stato un gorilla con in mano la banana e l'intera giungla

Non capisco proprio qui. Se il problema è ottenere una banana, possiamo incapsulare tutta la logica dietro la funzione 'getBanana'. Come sono coinvolte scimmia e giungla in questo contesto. Qualcuno potrebbe scrivere uno snippet di codice che spieghi il problema in un modo più facile da capire, per esempio, dimostrare il fatto che l' Bananaoggetto richiede l'oggetto Monkeye Jungleper essere avviato, per favore?



Peccato che questo si sia chiuso - stava dando alcune buone discussioni. Guarda le funzioni di prima classe come antipasto.
Robbie Dee,

1
Le domande sul tipo di discussione euforica sono effettivamente consentite, ma quali domande sono soggettive potrebbero essere ... soggettive.
Robbie Dee,

2
Credo che questa intervista si sia tenuta prima che Joe Armstrong scrivesse la sua tesi di dottorato. Mentre scriveva la sua tesi di dottorato, Armstrong ha appreso la vera definizione di OO e ha realizzato che Erlang è in realtà completamente orientato agli oggetti, in realtà, di tutti i linguaggi tradizionali attuali, Erlang è probabilmente il linguaggio più orientato agli oggetti! Non avrebbe fatto quella dichiarazione in quel modo se avesse saputo che Erlang era in realtà una lingua OO. Quello di cui sta parlando è l' autorità ambientale , che non ha assolutamente nulla a che fare con OO.
Jörg W Mittag,

1
Ciao, la mia domanda riguarda la fornitura di un codice di esempio che aiuti me (e altri) a capire meglio il problema. Qualsiasi frammento di codice che dimostra il problema è accettabile, non solo l'opinione.
Kha Nguyễn,

Risposte:


16

Sta accennando a un fatto, che la maggior parte dei programmi OOP reali non rispetta la separazione delle preoccupazioni. Ad esempio, potresti avere delle classi:

public class Banana
{
    public Monkey Owner {get;}
}

public class Monkey
{
    public Jungle Habitat {get;}
}

public class Jungle
{
}

Se lo usi Banana, è transitivamente necessario anche dipendere da Monkeye Jungle.

Ma non sono assolutamente d'accordo sul fatto che questo sia un problema con OOP e che lo stile funzionale in qualche modo non lo abbia. Questo può essere facilmente risolto in OOP con l'introduzione della giusta astrazione.

Il problema riguarda più gli sviluppatori che non si preoccupano della separazione delle preoccupazioni. E non avrei paura di affermare che la maggior parte dei programmatori OOP sono principianti, mentre i programmatori funzionali hanno una certa esperienza, che li motiva a separare correttamente il loro codice.

L'astrazione possibile potrebbe essere:

public class Banana
{
    public IBananaOwner Owner {get;}
}

public interface IBananaOwner
{
}

public class Monkey : IBananaOwner
{
    public Jungle Habitat {get;}
}

public class Jungle
{
}

In questo modo, sai che Bananaha un proprietario, ma non deve esserlo Monkey. Può essere qualsiasi cosa. E limita ciò che può Bananafare con il proprietario solo alle operazioni definite da IBananaOwner, il che semplifica il ragionamento.


E viceversa, mentre i linguaggi funzionali supportano funzioni di prima classe pronte all'uso, ciò non significa che la funzione X possa essere tranquillamente consumata dalla funzione Y senza effetti collaterali.
Robbie Dee,

Anche se fai un punto eccellente, penso che potresti andare leggermente fuori pista qui. La citazione menziona esplicitamente l' ambiente e non il modo in cui il codice è stato progettato.
Robbie Dee,

@RobbieDee Il Monkeye Junglesono un ambiente per Banana. Introducendo un'astrazione simile IBananaOwner, l'ambiente diventa esplicito. E come è progettato questo ambiente è il suo problema.
Euforico

Si può benissimo avere ragione, ma non posso fare a meno di pensare dopo aver letto questo , tra l'altro che l'elefante nella stanza (per aggiungere un altro animale) è che la questione è in corretta composizione delle funzioni che la programmazione funzionale, storicamente, ha si prestava di più.
Robbie Dee,

@RobbieDee Non puoi sostituire ciò che ho scritto con una semplice composizione di funzioni. Almeno non al di fuori dei problemi di esempio del giocattolo. In pratica, per sostituire completamente il design OOP, sono necessarie cose come generici complessi, classi di tipi, monadi e altro. E questo sta solo cambiando un tipo di complessità per un altro tipo.
Euforico

13

I gorilla non sono scimmie!

A parte questo, rispondi alla tua domanda con " possiamo incapsulare tutta la logica dietro la funzione 'getBanana' ". Tutto quello che voglio è una banana, ma per ottenerlo devo chiamare getBananaun oggetto, ad esempio un'istanza della Gorillaclasse. Quell'oggetto banana probabilmente contiene un riferimento al gorilla a cui appartiene e quell'oggetto gorilla avrà a sua volta un riferimento alla foresta a cui appartiene. Quindi chiedo una banana, ma incapsulato dietro c'è l'intera giungla.

È un esempio estremo e non sarà sempre così male. Ma non è raro finire con un sistema OO come questo. Quindi, per testare quel getBananametodo, ho bisogno di istanziare, o deridere, un'intera foresta.


1
Questo non risponde alla domanda in quanto non ha un codice di esempio ...
Robbie Dee
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.