Prosedürel kodun yapamayacağı hangi OOP kodu yapabilir? - sayfa 4

 
Doerk Hilger :

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.

MT dışında başka platformlar da var, derleyici az çok güçlü olduğu sürece, basit kod yazabildiğim sürece gerçekten umurumda değil.

Burada eksik olan şey eğitim, hepimiz hala öğreniyoruz, bazıları diğerlerinden biraz daha ileride. Bildiğim kadarıyla burası bir yarışma değil, bilgi ve destek alışverişi yeri.

Ve bu arada, bu forumdaki hiç kimsenin bir milyon satırlık program yazacağına inanmıyorum.

 
Alain Verleyen :
Noktayı kaçırdın Dirk. Uzman olmayan kişiler basit ve anlaşılır kod örnekleri istiyor, aslında bu konuyla ilgili amacım buydu. Ancak bu, uzmanların anlayışının tamamen ötesinde görünüyor.

Anahtarın her dilde olduğunu söylemiştin. En son diller, daha az bilgisi olan insanlar için işleri basitleştirmeye çalışır, "kodlayıcılar" grubuna kodlama eklenebilir. En iyi örnek, sözde dil HTML'dir. Ve bu büyük hata. MT5 geliştirildiğinde birçok "acemi" zor olduğu için OOP stilini suçluyordu. Ama gerçek şu ki, her işin kendi uzmanları vardır. Bir platformu geliştirmek istiyorsanız, onu karmaşık hale getirdiniz. Daha fazla özellik daha fazla esneklik. Kodlama bilgisi olmayanlar yapsınlar, bilmeden biri ev inşa etmiş gibi. Bir felaket olacak.

Uzunluk projeleri hakkında kodlayıcıya bağlıdır. Kütüphanem MQL dili için orta büyüklükte. Diğerleri, oluşturma araçları için yalnızca küçük kitaplıklara ihtiyaç duyar. Benim durumumda, zamandan tasarruf etmek ve gelecekte geliştirmeyi basitleştirmek için çerçeve oluşturmak için zaman harcamayı tercih ederim. Karmaşık kullanıcı arayüzleri oluşturduysanız veya kodu başka projeler için yeniden kullanıyorsanız, daha akıllı bir yoldur.

 
Juan Fernandez :

Anahtarın her dilde olduğunu söylemiştin. En son diller, daha az bilgisi olan insanlar için işleri basitleştirmeye çalışır, "kodlayıcılar" grubuna kodlama eklenebilir. En iyi örnek, sözde dil HTML'dir. Ve bu büyük hata. MT5 geliştirildiğinde birçok "acemi" zor olduğu için OOP stilini suçluyordu. Ama gerçek şu ki, her işin kendi uzmanları vardır. Bir platformu geliştirmek istiyorsanız, onu karmaşık hale getirdiniz. Daha fazla özellik daha fazla esneklik. Kodlama bilgisi olmayanlar yapsınlar, bilmeden biri ev inşa etmiş gibi. Bir felaket olacak.

Uzunluk projeleri hakkında kodlayıcıya bağlıdır. Kütüphanem MQL dili için orta büyüklükte. Diğerleri, oluşturma araçları için yalnızca küçük kitaplıklara ihtiyaç duyar. Benim durumumda, zamandan tasarruf etmek ve gelecekte geliştirmeyi basitleştirmek için çerçeve oluşturmak için zaman harcamayı tercih ederim. Karmaşık kullanıcı arayüzleri oluşturduysanız veya kodu başka projeler için yeniden kullanıyorsanız, daha akıllı bir yoldur.

Yani insanlar bilgi edinemez mi?

 

Prosedürel vs OOP işe yaramaz bir tartışma, 3 yıl önce zaten tartışıldı ve cevabım tamamen geçerli, burada daha fazla bir şey söylenmedi:

MQL5 Sihirbazı ile görebilirsiniz, böyle bir aracı prosedürel programlama ile geliştirmek mümkün olsa da çok zor olurdu .

OOP kullanılmalıdır:

  • Doerk ve James tarafından çok iyi belirtildiği gibi karmaşık projede.
  • Kodunuzu yeniden kullanmak istediğinizde.

Şu andan itibaren, yukarıdaki durumlarda OOP'nin neden ve nasıl daha iyi kullanılması gerektiğini gösteren kod örneği olmadan somut olmayan hiçbir gönderiyi kabul etmeyeceğim.

 
Alain Verleyen :

Prosedürel vs OOP işe yaramaz bir tartışma, 3 yıl önce zaten tartışıldı ve cevabım tamamen geçerli, burada daha fazla bir şey söylenmedi:

OOP kullanılmalıdır:

  • Doerk ve James tarafından çok iyi belirtildiği gibi karmaşık projede.
  • Kodunuzu yeniden kullanmak istediğinizde.

Şu andan itibaren, yukarıdaki durumlarda OOP'nin neden ve nasıl daha iyi kullanılması gerektiğini gösteren kod örneği olmadan somut olmayan hiçbir gönderiyi kabul etmeyeceğim.

Teşekkür ederim
 
Tüm bu konuyu okudum ve bunu ilginç buluyorum, ancak makine kodu prosedürel değil mi? Yani yüksek seviyeli diller ve OOP dahil, sonunda hepsi derleyicide prosedürel olarak çevrilir, değil mi? Tüm diller prosedürel makine koduna çevrilirse, yani prosedürel olarak her şeyin yapılabileceğini söyleyebiliriz, programcı becerileri kazanırsa lütfen yanlışsam biri beni düzeltsin
 
Mrluck07 :
Tüm bu konuyu okudum ve bunu ilginç buluyorum, ancak makine kodu prosedürel değil mi? Yani yüksek seviyeli diller ve OOP dahil, sonunda hepsi derleyicide prosedürel olarak çevrilir, değil mi? Tüm diller prosedürel makine koduna çevrilirse, yani prosedürel olarak her şeyin yapılabileceğini söyleyebiliriz, programcı becerileri kazanırsa lütfen yanlışsam biri beni düzeltsin

Her şey teorik olarak prosedürel olarak yapılabilir. Pratik değil.
Binlerce kum parçacığından bir tuğla inşa edilir, böylece sadece kumdan tuğlasız bir ev inşa edebilirsiniz.
Ama tuğlanız varken kimse denemiyor bile.

Bir Uçak, kanatlar, tekerlekler, koltuklar, bilgisayarlar vb. gibi hazır parçalardan yapılmıştır. Bunların tümü sonunda metal veya plastik veya camdan yapılmıştır. Ama hiç kimse saf cam, plastik ve metalden bir uçak yapmayacak.

Genel olarak tartışma için (Alain ve diğerlerine yanıt olarak): Bir dizi nesne olan CArrayObj'yi alın. Bu tek başına OO'nun gücünün ne olduğunu (bundan çok daha fazlası) cevaplamak için yeterlidir. Herhangi bir nesne dizisini depolayabilir - örneğin göstergeler gibi.
Ve hiçbir çaba sarf etmeden, tüm bu farklı göstergeler için karmaşık şeyler yapın. Ve şimdi bunun için yeni bir güç istiyorsanız, örneğin bir gösterge arabelleğinin ne zaman aşıldığını bilmek istiyorsanız, yöntemi CIndicator'a koymanız yeterlidir, o kadar. Ve benzeri. Prosedürel olarak nasıl yapardınız?

Ve bu her açıdan yapılabilir - Stratejiler, İşlemler, Anlaşmalar, Sinyaller - her neyse.

 
Amir Yacoby :

Her şey teorik olarak prosedürel olarak yapılabilir. Pratik değil.
Binlerce kum parçacığından bir tuğla inşa edilir, böylece sadece kumdan tuğlasız bir ev inşa edebilirsiniz.
Ama tuğlanız varken kimse denemiyor bile.

Bir Uçak, kanatlar, tekerlekler, koltuklar, bilgisayarlar vb. gibi hazır parçalardan yapılmıştır. Bunların tümü sonunda metal veya plastik veya camdan yapılmıştır. Ama hiç kimse saf cam, plastik ve metalden bir uçak yapmayacak.

Genel olarak tartışma için (Alain ve diğerlerine yanıt olarak): Bir dizi nesne olan CArrayObj'yi alın. Bu tek başına OO'nun gücünün ne olduğunu (bundan çok daha fazlası) cevaplamak için yeterlidir. Herhangi bir nesne dizisini depolayabilir - örneğin göstergeler gibi.
Ve hiçbir çaba sarf etmeden, tüm bu farklı göstergeler için karmaşık şeyler yapın. Ve şimdi bunun için yeni bir güç istiyorsanız, örneğin bir gösterge arabelleğinin ne zaman aşıldığını bilmek istiyorsanız, yöntemi CIndicator'a koymanız yeterlidir, o kadar. Ve benzeri. Prosedürel olarak nasıl yapardınız?

Ve bu her açıdan yapılabilir - Stratejiler, İşlemler, Anlaşmalar, Sinyaller - her neyse.

Bu konu kasıtlı olarak kışkırtıcıydı, ancak asıl sorunun cevabı (OOP ne yapabilir, prosedürel kod yapamaz) HİÇBİR ŞEYDİR.

OOP kesinlikle tuğla inşa etmenin ve kullanmanın tek yolu değildir. En azından OOP'de hatalı kod oluşturmanın prosedürel koddan (ve muhtemelen daha fazla yoldan) daha fazla yoludur. Metaquotes tarafından sağlanan ve aslında "standart" olmaktan uzak olan "Standart kitaplığa" bakmanız yeterlidir.

OOP'ye karşı prosedürel, işe yaramaz ve sonsuz bir tartışmadır. Daha kullanışlı olanı "Kalite kodu nasıl üretilir? OOP ile ve olmadan, prosedürlü ve prosedürsüz, herhangi bir programlama paradigması ile ve olmadan" olmalıdır. İhtiyacınız olan tek bir ahşap ev inşa etmekse, tuğlaya ihtiyacınız yok, ama iyi, sağlam ve güvenilir bir ev olması için ihtiyacınız var.

 
Kışkırtıcı olduğunu biliyorum Alain.
Ve iyi programlama kesinlikle her yerde uygulanabilir. Ancak, her dünya nesnelerden inşa edildiğinden ve buna ticaret dünyası da dahil olduğundan, bu dünyayı tarif etmeye prosedürlerden çok daha uygundur. Tabii ikisi de iyi yazdığında.


 
Amir Yacoby :

Her şey teorik olarak prosedürel olarak yapılabilir. Pratik değil.
Binlerce kum parçacığından bir tuğla inşa edilir, böylece sadece kumdan tuğlasız bir ev inşa edebilirsiniz.
Ama tuğlanız varken kimse denemiyor bile.

Bir Uçak, kanatlar, tekerlekler, koltuklar, bilgisayarlar vb. gibi hazır parçalardan yapılmıştır. Bunların tümü sonunda metal veya plastik veya camdan yapılmıştır. Ama hiç kimse saf cam, plastik ve metalden bir uçak yapmayacak.

Genel olarak tartışma için (Alain ve diğerlerine yanıt olarak): Bir dizi nesne olan CArrayObj'yi alın. Bu tek başına OO'nun gücünün ne olduğunu (bundan çok daha fazlası) cevaplamak için yeterlidir. Herhangi bir nesne dizisini depolayabilir - örneğin göstergeler gibi.
Ve hiçbir çaba sarf etmeden, tüm bu farklı göstergeler için karmaşık şeyler yapın. Ve şimdi bunun için yeni bir güç istiyorsanız, örneğin bir gösterge arabelleğinin ne zaman aşıldığını bilmek istiyorsanız, yöntemi CIndicator'a koymanız yeterlidir, o kadar. Ve benzeri. Prosedürel olarak nasıl yapardınız?

Ve bu her açıdan yapılabilir - Stratejiler, İşlemler, Anlaşmalar, Sinyaller - her neyse.

Örneğinizde, OO'yu kodladığınızda ve derlemeye tıkladığınızda, makine kodu üretecektir. Ama bu makine kodu prosedürel mi değil mi? Cevabı gerçekten bilmiyorum, burada bilen var mı? Makine kodu prosedürel ise, OO'yu yalnızca daha yüksek seviyeli bir dil olarak arayabilirsiniz, bu yalnızca kodlamayı kolaylaştırır, ancak özel bir şey değildir, bu nedenle yetenekli bir C programcısı, bir OO programcısının yaptığı işi yapabilir, aslında, hatta olabilir daha iyi optimize edilmiştir. Öyleyse sorum, eski kod produral mı değil mi?


Neden: