Prosedürel kodun yapamayacağı hangi OOP kodu yapabilir? - sayfa 3
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
Küçük ölçekli projelerle, herhangi bir sorunun prosedürel kodlara bölünebileceğini gösterebilirsiniz. Bununla birlikte, hepsi aynı anda "modelde" değişiklik yapmak isteyen 100'den fazla geliştirici, birkaç İş analisti ve mimardan oluşan ekiplerle milyonlarca satır kod tabanına sahip olduğunuzda işler çok daha zorlaşır. Bu koşullar altında "iş" modeli genellikle UML gibi bir tasarım aracında tanımlanır ve tüm ekip tarafından erişilebilirdir.
Yalnızca iş modeli 5000'den fazla sınıf içerir. Bu iş modelinden, nesne modeli, SQL arabirimleri ve ağ katmanları için sınıfları "üreten" araçlar vardır ve temel sınıf sayısını 15.000'e çıkaran ağ katmanları vardır.
Bu tartışma için, prosedüre karşı OOP argümanını, 1960/1970'lerden beri prosedüre eklenen üç "uzantıya" bölmek istiyorum.
1) "Nesne Tabanlı", bu, davranışları da olabilen gelişmiş bir "yapılar" oluşturmak için nesnelerin ve kodun kapsüllendiği yerdir.
2) "Sınıf tabanlı" burası, Nesnelerin birbirinden miras alabileceği ve hiyerarşiler halinde düzenlenebileceği yerdir.
3) "Nesne yönelimli" burası, kullanıcının sınıf hiyerarşileri içinde "polimorfik" davranışları (sanal yöntemler veya arayüzler) tanımlayabileceği yerdir.
Yukarıdakilerin hepsinin yeterli çabayla prosedürel dillerde uygulanabileceğine dair bir argüman var, örneğin 80/90'lardaki GUI araç takımlarının çoğu c'de oluşturuldu ve bu özelliklere sahipti, ancak gündelik kodlayıcı tarafından uygulanması kolay değil ve bu tartışma için pek geçerli değil.
Öyleyse soruyu cevaplamak için, 3 OOP özelliğini kullanmadan 100'den fazla geliştiriciyle multi milyon satırlık bir proje uygulayabilir miyiz?
Kişisel görüşüm, 1) ve 2) olmadan büyük ölçekli bir proje teslim etmek neredeyse imkansız çünkü "sınıf tabanlı" bir sistem olmadan gerçek dünya veri yapılarını ve davranışlarını temiz ve özlü bir şekilde koda dönüştürmek çok zor. Ve projenizin boyutu büyüdükçe, "bunu c'de uygulayabiliriz" olarak başlayan şey, daha az yapıya sahip, bakımı zorlaşan sonsuz bir yöntem listesi haline gelir.
Artık yalnızca 1) ve 2) sağlayan diller tam olarak OOP dilleri değildir. Bu yüzden "polimorfik (sanal) yöntemler" gerçekten gerekli olup olmadığını düşünmeliyiz. Bu biraz daha "belki" veya "bazen" gibidir, çünkü polimorfizm bir sorunu çözmek için her zaman doğru araç değildir ve tasarımı aşırı karmaşık hale getirebilir. Örneğin, bir nesne deposuna veya SQL veritabanına eşlenen bazı veri yapılarını modellerken, sanal davranışlar eklemek veri eşlemeyi daha zor hale getirebilir, ancak genişletilebilir araç takımları veya API'leri bir "arayüz" veya "sanal yöntemlerle" temel sınıf kullanarak tanımlarken paha biçilmezdir. Genel olarak, idareli ve doğru bağlamda kullanıldığında büyük bir polimorfizm hayranıyım.
Birkaç multi-milyon satırlık "C" kod tabanı ve birkaç multi-milyon satırlık C++/Java/C# kod tabanı üzerinde çalıştım ve geliştiricilerin Kod çok kırılgan olduğundan ve değişiklikler genellikle aylarca sancılı yeniden geliştirme ve testlere neden olduğu için mimariyi değiştirmekten korkar. Genel olarak Nesne Yönelimli projeler, değişiklik ve yeniden düzenlemeye karşı çok daha dirençlidir.
"if...then...else..." ifadesi işi yapmalıdır.
if...then...else "sanal" yöntemleri kodlayamaz.
"C" de birkaç "polimorfizm" uygulaması vardır ve bunların çoğu, gerekli eşlemeleri tutmak için işlev işaretçilerinin vektörlerini kullanır. Daha da önemlisi, bu "işlev işaretçilerinin vektörleri", "hiyerarşide" modellemek istediğiniz her "tip" için tanımlanmalıdır. Tabii ki "C" doğrudan hiyerarşileri desteklemez, bu yüzden bu sorunu da çözmeniz gerekecek.
"C" de uygulanan "sanal" yöntemler olan solucanlar çantasına gerçekten girmek istiyorsanız, o zaman her Linux dağıtımında ücretsiz olarak bulunan X Windows araç setlerini keşfedebilirsiniz.
Windows elbette biraz farklı olmalı ve tamsayı mesaj kimlikleriyle genişletilebilir yapılar kullanıyor. Bu, "polimorfik" davranışın kimliklerdeki switch ifadeleri aracılığıyla uygulandığı anlamına gelir. (muhtemelen bunu yapmanın en kirli yolu, ama sizi oraya götürecek)
Windows işletim sisteminin iyi bir GUI sunduğuna katılıyor musunuz? Bildiğim kadarıyla C ile yazılmış. Prosedürel dilde OOP değil.
Karmaşık bir programın yalnızca OOP ile oluşturulabileceğini düşünüyorsanız, yanılıyorsunuz Dirk. OOP ile kodlamanın neden daha iyi olduğunu açıklamanız gerekir.
Windows Çekirdeği "C"dedir, ancak Çekirdek, Windows kod tabanının yalnızca küçük bir bileşenidir ve daha yüksek seviyeli kod tabanının çoğu, birden çok dili desteklemek için "C" tarzı harici arabirimlerle C++'da uygulanır.
Eski Windows GUI bileşenleri bile, "C" de etkin bir şekilde "OOP" uygulanan kendi elleriyle yuvarlanan "polimorfik davranışları" uygular. Örneğin, bir GUI kontrolünden bir "Handle" aldığınızda, polimorfik davranışa sahip genişletilebilir bir "C" yapısı elde edersiniz, bu OOP sadece çirkin bir "C" sözdizimi kümesine sarılır.
"C" ile yazıldığı için Windows'un OOP değil demesi tamamen doğru değil.
Yanlış olduğunuzu kanıtlamak için prosedürel dilde bir GUI oluşturmayacağım. Ama hiç şüphesiz yapabilirdim.
Bu arada, OOP'de okunamayan ve çok daha yavaş kodu kodlamak da kolaydır ve bildiğiniz gibi Metaquotes Standard Library bunun iyi bir kanıtıdır.
OOP'nin prosedür kodundan çok daha yavaş olması tam bir efsanedir. Birçok OOP projesinin daha yavaş olmasının nedeni, kötü tasarlanmış olmalarıdır. Bir sanal işlev çağrısı için ek yük, beklediğinizden çok daha küçüktür, özellikle de paralel olarak bakabilen ve yürütülebilen günümüzün çipli bellek getirme mimarileri ile.
https://hbfs.wordpress.com/2008/12/30/the-true-cost-of-calls/
Yukarıdaki bağlantıdan alıntı: "Ancak, tadı ne olursa olsun, bir çağrının maliyeti, argümanlarının değerlendirilmesine göre belirlenir. İster C tarzı ister C++ sanal yöntemleri olsun, dolaylı çağrıların doğal olarak ucuz olduğunu gördük. sanal yöntem, bir yapı üyesi (bir şey->işlev(arg1,arg2)) kullanan dolaylı bir çağrıdan daha pahalı değildir, bu nedenle sanal işlevi inanılmaz derecede yavaş olarak kabul etmek yanlış bilgidir."
Java, C++'dan çok daha yavaş olabilir, çünkü kapsüllenmiş her veri parçasının kendisi yığın tabanlı bir sınıf olmalıdır, böylece çok daha fazla nesne referansı kaldırma elde edersiniz. Ancak Java bile döngülerde ve temel matematik işlemlerinde C ile tam olarak aynı hızda olabilir.
C'yi C# ile karşılaştırırsanız, bazı OOP özelliklerini ekleseniz bile, C'ye karşı C#'da önemli ölçüde daha hızlı olan bazı kodlar yazmak gerçekten oldukça zordur.
Metaquotes standart kitaplığı yavaşsa, kitaplık özelliklerinin tasarımı nedeniyle %90 olacaktır ve kullanılan OOP özellikleriyle çok az ilgisi olacaktır.
(Karşılaştırma olarak, C++ Standart Şablon Kitaplığı, şimdiye kadar yazılmış herhangi bir C projesinin %95'ini gerçekleştirir)
...
Büyük katkınız için teşekkür ederiz.
Büyük katkınız için teşekkür ederiz.
Teşekkürler, ben de sana kızmıyordum, prosedürle ilgili tartışmayı savunan tek kişi sensin :)
Endişelenmeyin, "moderatör" olarak rolümü oynamak zorundayım
Elbette, bahsettiğiniz şey her ne ise onunla ilgili bazı örnekler görmek güzel olurdu. Konuşma/yazma, tüm bunlarda deneyimi olan insanlar için iyi ve iyidir, ancak ben görsel bir öğrenci tipiyim, lütfen örnekler gönderin.
Mql4, mql5'e geçiş yapmaya devam edip etmeyeceğim veya başka bir platformla devam edip etmeyeceğim konusunda kararsızım.
Bu konuyu başlattığın için teşekkürler Alain. Bu forumun buna gerçekten ihtiyacı var.
Gerçekten profesyonel birinin bir "kanıt" olarak bir compex kitaplığı yayınlamasını bekliyor musunuz? ;) Sana burada markette satılamayan bir şeyin linkini verebilirim ama yaparsam Alain beni tekmeler ;) Profilimi ziyaret edebilir ve duvar resmine bakıp fikir edinebilirsin ya da bir fikir verebilirsin. bana bir pm.
Başka bir platform mu? Bu kadar güçlü bir derleyiciye sahip başka bir platform bulamazsınız. Hiç de bile.
@James Cater - yorumlarınız için çok teşekkürler.
Gerçekten profesyonel birinin bir "kanıt" olarak bir compex kitaplığı yayınlamasını bekliyor musunuz? ;) Sana burada markette satılamayan bir şeyin linkini verebilirim ama yaparsam Alain beni tekmeler ;) Profilimi ziyaret edebilir ve duvar resmine bakıp fikir edinebilirsin ya da bir fikir verebilirsin. bana bir pm.
Başka bir platform mu? Bu kadar güçlü bir derleyiciye sahip başka bir platform bulamazsınız. Hiç de bile.
@James Cater - yorumlarınız için çok teşekkürler.