OOP Dışı Tasarım Desenleri? [kapalı]

70

Nesne yönelimli kod için yalnızca "tasarım deseni" teriminin kullanıldığını duydum ve GoF kalıpları sadece OOP tasarım kalıplarını içeriyor, ancak tasarım kalıpları yaygın olarak ortaya çıkan programlama problemleri için zarif çözümler. İçinde OOP ile sınırlı olması gerektiğini söyleyen hiçbir şey yok, değil mi?

Nesne yönelimli programlama alanı dışında da bazı tasarım örnekleri örnekleri görmek istiyorum . Sende hiç var mı? Böyle bir şey bile var mı (GoF kitabı gibi hiçbir kitap mutlaka yazılmış olmalı, sadece kullanılmalı, bu yeterli olmalı)?

Bazı programlama dillerine özel olabilirler, ancak nesneye yönelik olandan farklı paradigmalardan genel (paradigma düzeyinde) modeller tercih edilir.

design-patterns 
— Anto
kaynak
8
Popüler tasarım deseni kitaplarının yaptığı en büyük sorun, kalıpların sadece nesne yönelimli dillere uygulandığına inanan bir grup insan yaratmaktı. Yaratılış kalıpları tartışılabilir, ancak hemen hemen hepsi diğerlerinin hiçbiri nesne yönelimli dillerde her zaman yapamaz ve uygulanır. Bu yan etkinin yazarın amacı olmadığından eminim, bir yan etki de az değil.
— Pemdas
14
Eh, nesneler OO olmayan dillerde bir tasarım deseni :)
— back2dos
1
daha da kötüsü, kalıp kitapları, her sorunun belirli bir kalıp uygulayarak çözülmesi gerektiğine inanan tüm insan sınıfını yarattı (genellikle aynı şekilde inanan bazı okul öğretmenleri tarafından en son öğretildikleri).
— 04

Yanıtlar:

25

Linux Çekirdek Tasarım Desenleri serisine bir göz atın. Makaleler nesne yönelimli olmayan bir dille (C) ilgilidir ve iyi yazılmış olduklarına inanıyorum:

— sakisk
kaynak
Yine de nesneye yönelik bir yaklaşım kullanıyorlar.
— Kais
12

Aslında bu paradokstur - en popüler olmayan OO modellerinden biri ... "Sınıf".

OO, OO dışı dillerde icat edildiğinden, geliştiriciler onu simüle etmek zorunda kaldılar (ve şu anda bile yapıyorlar) - yani desen doğdu. LISP ve C buna örnek olarak verilebilir.

Ancak benim tavsiyeme uyun: Sık yapılan bir hata yapma - yalnızca kalıpları kullanmayın, çünkü serin olduğu için, kalıp kullanımını haklılaştırmak için ciddi nedenlere ihtiyacınız var (en azından OO olanlar).

Örneğin Command paternini alın - güzel ve her ne kadar arayanı alıcıdan ayırsa da, aslında gerekmediğiniz sürece kullanılmamalı - çünkü işlemler fiiller kullanılarak ifade edilmelidir - bu da yöntemler anlamına gelir. Ve bir sürü tamamen merkezi olmayan OO-lambda ile son bulacağınız her yeri komutları kullanarak -> aynı şekilde bir çok Strateji için de geçerli olacaktır.

— Kamil Tomšík
kaynak
11

“Tasarım deseni” aslında “geçici çözüm” için bir örtmecedir. Tasarım desenleri, OO dillerindeki eksiklikler ve kusurlar etrafında çalışmak üzere icat edildi . Örneğin, sonunda Java'daki koleksiyonların tanıtımına yol açan yineleyici deseni kullanın. Groovy, dil özelliklerine dönüştürerek daha birçok örüntüden kurtuldu: Artık dekoratör kalıbına ihtiyacınız yok çünkü Groovy'deki mevcut sınıflara yöntemler ekleyebilirsiniz.

Bu, tasarım kalıplarını her yerde bulabileceğiniz anlamına gelir. Aslında, her "en iyi uygulama" basit bir tasarım modelinin şekli olarak kabul edilebilir.

— Aaron Digulla
kaynak
9
Kabul! Gönderen Paul Graham : desenleri ' "Örneğin, OO dünyada yaklaşık iyi bir anlaşma duymak' Ben programlarında desenleri görünce [...], bunun sorunun belirtisi düşünün bir programın şekli yansıtmalıdır.. Sadece çözmesi gereken sorun: Koddaki diğer herhangi bir düzenlilik, en azından benim için yeterince güçlü olmayan soyutlamalar kullandığımın bir işaretidir - genellikle bazı makroların genişlemelerini elle oluşturduğumu "yazmam gerekiyor."
— Andres F.
7
Bir tasarım modelinin geçici bir çözüm olmasına katılmıyorum. İkisi karşıt. Geçici bir çözüm, belirli bir engeli atlamak için bir araya getirilen kısa vadeli bir yamadır. Tasarım kalıpları uzun vadeli yeniden kullanılabilir çözümlerdir. Dekoratör modelinin amacı, sınıfı değiştirmeden işlevsel olarak 'eklemeden' eklemektir. Nesneyi bilmeden, bir nesneye farklı dekoratörler koyabilirsiniz.
— Despertar
Kalıpların "geçici bir çözüm" olarak kabul edilmesinin nedeni, bir nesneyi dekore etmenin dilin bir özelliği olması gerektiğidir. Bunun yerine, bunu uygulamak için çok sayıda kod satırı yazmamız gerekiyor. Örnek olarak, yineleyici desen birçok modern dilin bir parçası haline geldi. Eski OO dilleri için, onları simüle etmek için birkaç çemberin içinden atlamanız gerekir.
— Aaron Digulla
@AaronDigulla Dekoratör gibi bir modelin neden bu kadar ağır bir uygulama olduğunu düşündüğünüzü anlamıyorum; Birkaç kod satırından bahsediyorsun. Bir sınıf başka bir sınıf içerir ve bazı ek işlevlerle istekleri iletir. Kalıtım ve kompozisyonu, süslü bir nesneyi çağrının, nesneyi çağırmaya eşdeğer kılacak şekilde kullanır. Bu şeffaflığın bir güç olduğunu düşünüyorum. Bu, çalışma zamanında dekoratörleri değiştirmenize olanak sağlar. Groovy'nin dekoratöre ihtiyacı olmadığını söylediğinizde, bir sınıfa yöntemler ekleyebildiğinden, noktayı kaçırmışsınız gibi geliyor.
— Despertar
2
Yineleyici düzeni, modern dillerde hiçbir yeni dil özelliği ile değiştirilmemiştir. Sadece ortak koleksiyonlar için varsayılan bir uygulama ile birlikte geliyor. Sadece varsayılan bir uygulamaya sahip olması, desenin kullanılmadığı anlamına gelmez. Kendi koleksiyonunuzu yazarsanız kendiniz uygulamak zorunda kalacaksınız.
— Despertar
10

LTU bahseder o Jeremy Gibbons fonksiyonel programlamada desenleri üzerine bir kitap yazıyor. Bir kaç iltifat için Bay Gibbon'un İşlevsel Programlama bloğundaki kalıplarını inceleyin . Notlarını, en eskiden yeniye doğru okumanızı tavsiye etti.

Onun kağıt Yüksek Dereceden Datatype-Jenerik Programlar olarak Design Patterns Kompozit, Iterator, Ziyaretçi ve Builder: (pdf) Dört kalıplarının işlevsel modeller Çetesi. Origami Programlama'da özyinelemeli denklemlerle programlama kalıplarını (katlar ve açmalar) tanımlar .

— Corbin March
kaynak
7

Oo olmayan tasarım kalıplarını adlandırmak yerine, size birçok tasarım tasarımına sahip birkaç kitap örneği vermek istiyorum (bunlarda bazı desenler hala OO'ya özgü olacaktır):

Bu yardımcı olur umarım

— KeesDijk
kaynak
Bunlar tavsiye edebileceğim ve Hohpe & Woolf'un Kurumsal Entegrasyon Kalıpları .
— TMN
Fowler'in kalıpları oldukça OO :)
— David Conde
@David Conde :) Bunların çoğu saf OO, Hepsi OO şeklinde yazılıyor, ancak bazıları OO dışı için de geçerli: "Web sunumu düzenleri", "Oturum durumu düzenleri", "Dağıtım düzenleri" ne bakın "
— KeesDijk
0

Kuyruklar, bağlantılı Listeler, Ağaçlar, grafikler, vb. Gibi Veri Yapıları öğelerini desen olarak düşünmeyi seviyorum. Verileri depolamak ve işlemek için belirli kalıpları tanımlarlar. Gang of Four'un daha yüksek seviye bilmece ile karşılaştırıldığında ilkel gözükebilirler, ama yine de bir kalıptırlar. Demek istediğim, eğer biri bir LIFO yerine FIFO olarak bir yığın uyguladıysa ve bir sıra için tam tersi olarak adlandırdıysa ne olur?

— DPD
kaynak
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.