Gli schemi di progettazione sono indipendenti dai linguaggi di programmazione?

Se comprendo correttamente la tua domanda, la risposta si riduce a questa:

TLDR

La ragione per avere cose come classi astratte e interfacce / protocolli in un linguaggio dinamico come Objective-C sono principalmente la semplicità e la pulizia del codice.

La versione più lunga

È interessante quanto digitazione anatra, in realtà è una seccatura enorme se non si possono fare ipotesi sul tipo di oggetto:
ogni riga respondsToSelector: nel tuo codice lo rovina. Aggiunge rumore che offusca ciò che in realtà sta cercando di ottenere per poco o nessun beneficio.

Inoltre, è shit-work .

Quindi, se fornisci un contratto API perdendo un po 'di dinamismo, utilizzando un modello tipicamente più statico è quasi sempre una vittoria:

• Sostituire più metodi respondsToSelector: con un singolo conformsToProtocol: è una vittoria.
• Avere una lista succinta e chiara dei metodi necessari nella definizione del protocollo è una vittoria. (Scrivere quella definizione di per sé è anche merda, ma ti impedisce di fare più merda in un numero di posti, quindi è tollerabile.)
• In base a ciò, avere il compilatore ti avverte se hai omesso l'implementazione di uno di questi metodi è una grande vittoria.
• E: non dover scrivere un solo messaggio respondsToSelector: o conformsToProtocol: , perché il compilatore può ora avvisarti e dirti dove hai incasinato, è la più grande vittoria di tutti.

Se puoi andare oltre, fornendo una base comune dell'attuazione reale, creare una classe astratta potrebbe essere una vittoria ancora più grande (probabilmente non così utile nel contesto della delega ...) - dopo tutto, ripetendo l'implementazione è il peggiore dei casi di merda, poiché ogni cambiamento si tradurrà in un maggior lavoro di merda per mantenere le cose coerenti.

Quindi sì, il dinamismo è una cosa interessante e utile, dato che ti permette di tirare fuori ogni tipo di trucco divertente. Ma in pratica, sbarazzarsi di alcune di queste cose (se necessario) può renderti la vita molto più facile e impedirti di fare merda - come scrivere respondsToSelector: .

No. Questo è il motivo per cui penso che il libro Design Patterns sia un carico di crudezza. La tesi del libro è che alcune cose non possono essere automatizzate: modelli di design.

Ad esempio il più famoso, il pattern Visitor ... err .. in un linguaggio decente che è una piega (accumulata in C ++ STL).

Ciò che è effettivamente scoperto nel libro non è Design Patterns, ma Deficienze della lingua.

Se esiste un modello, è l'obiettivo dei progettisti di linguaggio di essere in grado di automatizzarlo. Quasi tutte le ricerche sulla teoria dei tipi sono incentrate sul rendere i sistemi di tipo polimorfico più espressivi.

Sappiamo tutti che, specialmente nella programmazione, c'è più di un modo per scuoiare un gatto. I moderni linguaggi sono molto potenti e flessibili al giorno d'oggi, e in alcuni casi offrono modi per aggirare alcuni schemi.

I pattern e la parola chiave abstract in PHP qualsiasi altro linguaggio OO è più incentrato sulla struttura e l'integrità. La parola chiave abstract , ad esempio, fornisce le istruzioni del programmatore su come scrivere una classe di estensione. Guarda questo esempio: link

A prima vista lo so:

1. Non posso usare AbstractClass da solo. Devo scrivere un'altra classe che la estende.
2. Ho già a disposizione il metodo printOut() , quindi non devo riscriverlo.
3. Qualunque cosa io faccia, devo scrivere i miei metodi getValue() e prefixvalue($prefix) protetti.
4. Finché seguirò questi requisiti, so che funzionerà. Quando qualcun altro vuole estendere questa classe, sapranno cosa fare.

Sì. Questo è il motivo per cui i libri di Design Patterns sono molto importanti. La tesi di tutti questi libri è che alcune cose non possono essere automatizzate: buon design.

Ciò che viene effettivamente scoperto nel libro non ha nulla a che fare con le carenze linguistiche, ma sono modelli di buon design. Alcuni di questi modelli sono riempiti da funzionalità linguistiche. Alcuni di questi modelli non sono coperti dalle funzionalità linguistiche.

Il buon design è indipendente dalla lingua.

Ci sono un numero illimitato di modelli di design distinti. Un progettista di linguaggi non può anticiparli o riempirli tutti.

So why do we have protocols here even if we need to use a delegate pattern ?

Perché i protocolli sono un'implementazione linguistica di un buon modello di progettazione.

do we need concept of abstract class or interface at all to implement few patterns ?

Una classe astratta formale è sempre utile, anche nelle lingue con dattilografia.

Un'interfaccia formale è un'implementazione, utilizzata da alcune lingue. Il modello di progettazione (anche in lingue dattiloscritte) esiste ancora.

La cosa principale che ottengo guardando a Design Patterns è imparare dai progetti di altre persone. Non sono tutti applicabili a tutte le lingue, ma studiarli potrebbe insegnarti un disegno che non hai capito o conosciuto prima. Un altro vantaggio è che, dato che abbiamo designato i design, possiamo parlarne più facilmente con altri sviluppatori. Anche se il modello sarebbe stato implementato in modo diverso nelle diverse lingue, ti offre strumenti per confrontare e confrontare, nonché argomenti attuali su quali situazioni funzionano bene con quali progetti e, forse ancora più importante, quali progetti non funzionano con quali situazioni.