OOP'a ilginç bir bakış

 
radikal FP'lerden daha az makale okuyun. FP kavramı bir veya iki yıl değil, devrim hakkında bir şeyler duyulmuyor
 

Bu bir OOP sorunu değil, uygulaması ve hatta daha fazlası - onu uygulayanların sorunudur. Onlar da deneyimliyor

özel coşku, hatta OOP'nin yardımıyla inanılmaz derecede yazabileceğiniz gerçeğinden ecstasy

gizlenmiş kod (ve hatta onunla rekabet :). Bundan özel bir elit gibi hissediyorlar.

Hatta okudukları, okudukları, okudukları, okudukları, ama hiçbir şekilde kendi "BÜYÜK KİTABI" ile ortaya çıktılar.

üzerinde okuyabilir. İnsan dilinde buna " Tasarım Kalıpları" denir.

"Çamurlu, anlaşılmaz ve kafa karıştırıcı kod yazmanın en yüksek sanatı" olarak tercüme edilir. Eğer

OOP'yi akıllıca kullanmak için - bu çok, çok harika bir şey, inanılmaz derecede basitleştirici ve

hayatı kolaylaştırıyor.

 

Burada, bu tür makalelerin büyük olasılıkla bu FP'ye ve her biri 20 sekme içerebilen karmaşık kancalarına aşina olmayan kişiler tarafından yazıldığını anlamanız gerekir....

Sert FP başka bir şeydir. sonra bir şekilde OOP'nin özlü ve kullanışlı olduğunu düşünmeye başlarsınız, yani işlevselliğin bir kısmını önceden beyan edebilirsiniz vb. ..... Aslında birbirine benzer bir şey. Ancak bu tür makaleler genellikle yalnızca prosedür koduna hakim olan kişiler tarafından yazılır - ve bu FP'ye yakın bile değildir, bu nedenle kancaların ne olduğunu ve ateşli kullanımını bilmiyorsak, herhangi bir FP'den söz edilemez.

ayrıca "ölen" makalesinde listelenenlerin çoğu   diller "FP ve OOP'nin tam işlevselliğini destekliyor, neden eğilmeleri garip ?! ve bunlardan birkaçı BDT'de en yüksek ücretli  
 
FP için "boğulma" düşüncesi olmadan, OOP'de "spaggetizasyon" ile ilgiliydi. Benim için prosedürel paradigma, OOP'den gerçekten ve daha fazla kaynak verimlidir.
 
Mikhail Mishanin :
FP için "boğulma" düşüncesi olmadan, OOP'de "spaggetizasyon" ile ilgiliydi. Benim için prosedürel paradigma, OOP'den gerçekten ve daha fazla kaynak verimlidir.

OOP kodunun kendisinin daha uzun olduğu gerçeğiyle mi ilgili? evet, bir kurucu var ve bazı durumlarda kod daha uzun, kural olarak, üzerinde .... teknik olarak, FP'yi dağıtmak makine kodu oluşturmak için daha verimli olmalı .... ama kod değil daha basit hale gelir ve yazmaktan bahsedersen normal sarmalayıcıları yapamazsın...

günümüzde çoğu zaman birbirinin karışımını bulabilirsiniz - yöntemler birbiriyle karışmaz

 
Alexandr Andreev :

OOP kodunun kendisinin daha uzun olduğu gerçeğiyle mi ilgili? evet, bir kurucu var ve bazı durumlarda kod daha uzun, kural olarak, üzerinde .... teknik olarak, FP'yi dağıtmak makine kodu oluşturmak için daha verimli olmalı .... ama kod değil daha basit hale gelir ve yazmaktan bahsederseniz normal sarmalayıcıları yapamazsınız...

günümüzde çoğu zaman birinin diğeriyle bir karışımını bulabilirsiniz.

OOP ve FP olmadan, her şey daha kolay ve daha hızlı sürer (evet, "güzel şeyler", paneller vb. olmadan), ancak bazen kendi kodunuzu bile anlamak zordur)

 
Mikhail Mishanin :

OOP ve FP olmadan, her şey daha kolay ve daha hızlı sürer (evet, "güzel şeyler", paneller vb. olmadan), ancak bazen kendi kodunuzu bile anlamak zordur)

önce birinde veya diğerinde ve tercihen her ikisinde de ustalaşın ve ardından en çok neyi sevdiğinize karar verin. Ve şimdi olduğu gibi bir yaklaşımla, zamanla, anlamadığı her şeye (yani hemen hemen her şeye) saldıran bir Fedoseev'e dönüşür.

 
Küresel yeni teknoloji trendi, üç ay boyunca yeni bir şey üzerinde çalışmak, bir ay boyunca uygulamak (bir grup böcek toplamak), sonra onu bir çöp sahasına göndermek ve üç ay boyunca yeni bir şey üzerinde çalışmak, böylece bir ay içinde (başka bir şey toplamak) bir sürü böcek) bir çöp sahasına gönderin. Biri hayatını bu şekilde yakmayı seviyorsa - lütfen.
 

Konuya bir tür yıkıcı tepki ve yıkıcı bir tartışma. Söyleyin bana, bir Prosedürel Programcı, OOP'de spaggetizasyondan nasıl kaçınılır, nasıl ayrıştırılır ve diğer insanların spagget'larını kullanmanın mantıklı olup olmadığını?

Sonuçta, ne olur, OOP çoğunlukla okunabilirlik ve komut programlama içindir, yani. büyük projeler için. Bakiye/hesap fonlarından maksimum riskin kontrolü ile eklendiği çizelgeye bir sembol ticareti yapan bir Uzman Danışman hiçbir şekilde büyük bir proje olarak adlandırılamaz - bu, prosedürel programlamanın yeterli ve bellek açısından daha karlı olduğu anlamına gelir. /hız.

Sorular:

- kişisel deneyimden OOP'nin eksileri / artıları (zorunlu olarak)

- kişisel deneyimden FP'nin eksileri / artıları (bildirimsel olarak).

Ve beklentiler hakkındaki görüş, özellikle paralel hesaplama yönünde, elbette ilginç. Kuantum konusuna değinmek için bir neden göremiyorum.

 
Mikhail Mishanin :

Bana bir Prosedürel Programcıya OOP'de "spagging" den nasıl kaçınılacağını söyle

Tarif, alıntı yapılan makalede verilmiştir: Deterministik fonksiyonlar yazmaya çalışın.

, nasıl sökülür ve başkalarının "spagetti"sini kullanmak mantıklı mı?

İyi kod evet, ama spagetti hayır.

Sonuçta, ne olur, OOP çoğunlukla okunabilirlik ve komut programlama içindir, yani. büyük projeler için.

Doğru.

Bakiye/hesap fonlarından maksimum riskin kontrolü ile eklendiği çizelgeye bir sembol ticareti yapan bir Uzman Danışman hiçbir şekilde büyük bir proje olarak adlandırılamaz - bu, prosedürel programlamanın yeterli ve bellek açısından daha karlı olduğu anlamına gelir. /hız.

Avustralya'ya seyahat etmek için bir uçak (PLO) kullanmak daha uygundur, komşu bir şehre seyahat için bir araba veya hatta bir bisiklet (PP) yeterlidir. Hedefe ulaşmak için daha uygun araçlar seçmeniz yeterlidir.

Neden: