OOP vs prosedürel programlama - sayfa 12

 

Sınıfları koyacak hiçbir yerim bile yoksa OOP'yi nasıl kullanabilirim ? Sadece onlara ihtiyacım yok. Benim yapılara ihtiyacım yok. Bu, programımın kendi kendini geliştirmesiyle haklı çıkmayan yapay bir bölünmedir. Kendini geliştirme budur. Başka türlü adlandıramazsınız.

Dolayısıyla, bu süreçte, kod bloklarının kendileri, onları geliştirme ve yeni işlevler ekleme sürecinde doğan ihtiyaca göre bölünür. İlk olarak, işlevler oluşturulur, daha sonra bunlar yavaş yavaş cilalanmış ve yeni özelliklerle büyümüş büyük bloklar halinde birleştirilir. Zamanla, bu bloklar dağılır ve yeni bloklar ortaya çıkar. Her şey doğal olarak gerçekleşir. Yalnızca yeni özellikler elde etmek için yeni işlevleri "geliştiririm" ve ardından onu yüksek kaliteli bir duruma getiririm. Aynı zamanda, kodun yapısı sürekli değişiyor ve dönüşüyor. Net bir planım yok ve her şey öngörülemeyen bir yönde gelişiyor. Beklenmedik bir şekilde, bu süreçte ileriye doğru bir kuantum sıçraması için fırsatlar buluyorum. Ve bu atlayışı yapıyorum.

Programım bu şekilde gelişiyor. Genişler, sonra küçülür, çöker ve dönüştürülerek geri yüklenir. Küresel yeniden dağıtımlar, niteliksel sıçramalar var ama aynı zamanda uzun vadeli istikrarlı durumlar da var.

Bu süreçte, yabancı bir dil ile herhangi bir ekstra kural ve sözdizimi sadece yavaşlayacaktır.

 
Реter Konow :

Sınıfları koyacak hiçbir yerim bile yoksa OOP'yi nasıl kullanabilirim ? Sadece onlara ihtiyacım yok. Benim yapılara ihtiyacım yok. Bu, programımın kendi kendini geliştirmesiyle haklı çıkmayan yapay bir bölünmedir. Kendini geliştirme budur. Başka türlü adlandıramazsınız.

Dolayısıyla, bu süreçte, kod bloklarının kendileri, onları geliştirme ve yeni işlevler ekleme sürecinde doğan ihtiyaca göre bölünür. İlk olarak, işlevler oluşturulur, daha sonra bunlar yavaş yavaş cilalanmış ve yeni özelliklerle büyümüş büyük bloklar halinde birleştirilir. Zamanla, bu bloklar dağılır ve yeni bloklar ortaya çıkar. Her şey doğal olarak gerçekleşir. Yalnızca yeni özellikler elde etmek için yeni işlevleri "geliştiririm" ve ardından onu yüksek kaliteli bir duruma getiririm. Aynı zamanda, kodun yapısı sürekli değişiyor ve dönüşüyor. Net bir planım yok ve her şey öngörülemeyen bir yönde gelişiyor. Beklenmedik bir şekilde, bu süreçte ileriye doğru bir kuantum sıçraması için fırsatlar buluyorum. Ve bu atlayışı yapıyorum.

Programım bu şekilde gelişiyor. Genişler, sonra küçülür, çöker ve dönüştürülerek geri yüklenir. Küresel yeniden dağıtımlar, niteliksel sıçramalar var ama aynı zamanda uzun vadeli istikrarlı durumlar da var.

Bu süreçte, yabancı bir dil ile herhangi bir ekstra kural ve sözdizimi sadece yavaşlayacaktır.


Belki de uğraşılacak yapılarla birlikte bir hafta harcamaya değer? "Yapılara ihtiyacım yok" ifadesi gerçekten aptalca. Tek bir sonuç var - ne olduğunu bilmiyorsunuz.

 
Dmitry Fedoseev :

Prosedürel olarak en iyi şekilde çözülemeyen problemler vardır.

"Optimal yol") ile ne kastedildiğine bağlı olarak

Bana gelince, OOP sadece uygun bir paketleyici ve bazı sorunlara çözüm değil. Böylece tartışma burada sona erdi.

Genel olarak, herkes herhangi bir görevin yapısal-prosedürel bir yaklaşım kullanılarak çok daha hızlı ve daha kompakt bir şekilde çözüleceği konusunda hemfikir görünüyor. Ve sınıfları sarmak, kendisini kodlamaktan daha fazla zaman alır. Bazen kendinizi çok kaptırırsınız, bir sürü dersi yığarsınız ve sonra düşünürsünüz - ve neden tüm bunlar gerekliydi ...

Peki, "işlev işaretçileriyle prosedürel programlama" hakkında bir şey daha - neden ayrı bir kategoride seçilsin? Benim düşünceme göre, işlev işaretçileri bir şekilde yapısal-yordamsal stile aittir.

 
Alexey Navoykov :

"Optimal yol") ile ne kastedildiğine bağlı olarak

Bana gelince, OOP sadece uygun bir paketleyici ve bazı sorunlara çözüm değil. Böylece tartışma burada sona erdi.

Genel olarak, herkes herhangi bir görevin yapısal-prosedürel bir yaklaşım kullanılarak çok daha hızlı ve daha kompakt bir şekilde çözüleceği konusunda hemfikir görünüyor. Ve sınıfları sarmak, kendisini kodlamaktan daha fazla zaman alır. Bazen kendinizi çok kaptırırsınız, bir sürü dersi yığarsınız ve sonra düşünürsünüz - ve neden tüm bunlar gerekliydi ...

Peki, "işlev işaretçileriyle prosedürel programlama" hakkında bir şey daha - neden ayrı bir kategoride seçilsin? Benim düşünceme göre, işlev işaretçileri bir şekilde yapısal-yordamsal stile aittir.


Polimorfizm , belki de fonksiyon işaretçileri dışında, prosedürel yollarla hiçbir şekilde uygulanmaz. OOP açıkça polimorfizmdir ve prosedürel programlamada fonksiyon işaretçilerinin olduğu bir gerçek değildir.

Bir satırdaki her şeyin sınıflara sarılması gerekmez.

 
Dmitry Fedoseev :

Belki de uğraşılacak yapılarla birlikte bir hafta harcamaya değer? "Yapılara ihtiyacım yok" ifadesi gerçekten aptalca. Tek bir sonuç var - ne olduğunu bilmiyorsunuz.

Yapı kendini açıklayıcıdır. Çeşitli türlerde adlandırılmış değişkenler kümesini birleştirir. Programımdaki ana tür int. double sadece birkaç yerde kullanılmaktadır. dize yalnızca belirli bir blokta.

Neden OOP bağlamında yapılara ihtiyacım var?

Çekirdeğe ait bir yapıya sahibim. Yani çekirdeğin yapısı kendi içinde. Tek gereken bu.

 
Реter Konow :

Yapı kendini açıklayıcıdır. Çeşitli türlerde adlandırılmış değişkenler kümesini birleştirir. Programımdaki ana tür int. double sadece birkaç yerde kullanılmaktadır. dize yalnızca belirli bir blokta.

Neden OOP bağlamında yapılara ihtiyacım var?

Çekirdeğe ait bir yapıya sahibim. Yani çekirdeğin yapısı kendi içinde. Tek gereken bu.


Muhtemelen üç yıl kendin için bir program gördün.

 
Dmitry Fedoseev :

Bu mümkündür, ancak farklı işleyiş verimliliği ile. Burada destekten söz edilmiyor, çok göreceli.

Prosedürel olarak en iyi şekilde çözülemeyen problemler vardır.


Ben OOP destekçisiyim ama aslında işlemci OOP'nin varlığı hakkında hiçbir şey bilmiyor, makine kodunu çalıştırabiliyor, hepsi bu. Bilgisayarların ilk zamanlarında, programlar tam da makine kodlarında bu şekilde yazılırdı.

Bu yüzden çok fazla kadın programcı vardı. Böyle bir işten gelen adamlar için keskin bir şekilde sarhoş bir sarhoş oldu ve bir kuleye bindi))

 
Реter Konow :

Sonuçta, en önemli olanın kararın etkililiği olduğunu kabul edeceksiniz.

Söz dizimi yığınları ve kuralların karmaşıklığı, çözümlerin etkinliğinin korunmasına hiçbir zaman katkıda bulunmamıştır. Kod bloklarının özlülüğü, evrenselliği ve okunabilirliği ile ifade edilen sadelik ve kısalığa katkıda bulunmuştur.

Etkili çözümler ile ne kastedilmektedir?

Programlamadaki kurallarım daha az kod, daha az kural, daha az sözdizimi...

Benim kurallarım: kural yok
 

OOP hayranı değilim.

Ancak bakım, ölçeklenebilirlik ve üçüncü taraflarca kullanım kolaylığı açısından TC'yi (Karputov değil Peter) iten şey taş devridir.

Her programcının bir ekipte, ideal olarak 4 kişiden fazla, sadece kodun verimliliğinin ve çok yönlülüğünün bu kodun iyi olduğu anlamına gelmediğini anlamak için çalışması gerektiğine dair güçlü bir fikrim var.

 
Alexey Volchanskiy :

Ben OOP destekçisiyim ama aslında işlemci OOP'nin varlığı hakkında hiçbir şey bilmiyor, makine kodunu çalıştırabiliyor, hepsi bu. Bilgisayarların ilk zamanlarında, programlar tam da makine kodlarında bu şekilde yazılırdı.

Bu yüzden çok fazla kadın programcı vardı. Böyle bir işten gelen adamlar için keskin bir şekilde sarhoş bir sarhoş oldu ve bir kuleye bindi))


Ne olmuş yani? Şimdiye kadar, bir sonuç kendini gösteriyor - şafakta makine kodlarında çok şey yazmak zorunda kaldınız))