OOP vs prosedürel programlama - sayfa 12
Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
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.
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.
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.
"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.
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.
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.
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))
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...
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.
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))