OOP vs prosedürel programlama - sayfa 35
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
Dikkatli olun, MT'nin dahili değişkenlerinden değil, izole ettiğiniz nesnenin dahili değişkenlerinden bahsediyoruz, hata ayıklama ve kod yazma sırasında değerlerini okuma olasılığını önlüyor...
Yani diyorum ki - bir Uzman Danışmanda hata ayıklarken - dahili MT değişkenlerine ihtiyacınız yok mu?
Benzer şekilde, bu durumda, ticari işlemci nesnesiyle - örneğin, TS'nizde gecikmeleri ayarlama yönteminde hata ayıklama yapıyorsanız - neden ticari işlemcinin dahili değişkenlerine erişmeniz gerekiyor?
Andrei, Peter veya Sansanych'ten bile daha klinik, zamanını boşa harca
Gençlere eğitim verilmeli.
Ayrıca muhaliflerin sözlerinde rasyonel bir zerre olması da mümkündür. Diyelim ki, Peter'ınki gibi bir anım var - muhtemelen OOP ile de uğraşmazdım.
Benzer şekilde, diğer yerlerde - eğer bazı veriler gerekliyse - bu blok uygun arayüzü sağlamalıdır.
Ben de aynı şeyden bahsediyorum... Sadece gerekli değişkenin değerini görmek yerine, ona uygun bir arayüzü nasıl ekleyeceğinizi düşünmeniz ve sonra onu geri çekmeniz gerekiyor. :)
Programlamada mazoşistler için bir mesleğe benziyor :)
Evet .. yaban turpu daha tatlı değil :) Fikir, minimum vücut hareketi ile hata ayıklamayı ve kod yazmayı kolaylaştırmak için yeterli bir programlama dilinde ama burada tamamen zıt bir durum var ...
Bu "tersi durum" değildir. Gerçekten de, OOP bazı ek adımlar gerektirir. Ancak bu, sistemin bakımının ve değiştirilmesinin rahatlığıyla dengelenmekten daha fazlasıdır.
Burada yine - ticaret işlemcisine dönersek - bir grup TS'de yazılır ve kullanılır. Dahili bileşenlerinin TS'den yalıtılmasıdır ve yalnızca sanal bir arayüz üzerinden çalışır - bu, içinde hangi değişkenlerin olduğunu ve bunların neye eşit olduğunu düşünmemenizi sağlar. Hatalar tespit edilirse, bunlar işlemcinin içinde olacak ve araç sınıflarını etkilemeden gerçek sınıf içinde düzeltilmesi gerekecektir. Hata TS'nin kendisindeyse, ticaret işlemcisinin değişkenlerini etkilemeyecektir.
Gerçekçi olarak, kapsülleme çok kullanışlı bir tekniktir.
Evet .. yaban turpu daha tatlı değil :) Fikir, minimum vücut hareketi ile hata ayıklamayı ve kod yazmayı kolaylaştırmak için yeterli bir programlama dilinde ama burada tamamen zıt bir durum var ...
Hata ayıklama, her sınıftaki sorumlulukların sınırlandırılmasıyla tam olarak kolaylaştırılır: her sınıf kendi değişken kümesinden sorumludur. Başka hiçbir sınıfın değerlerini değiştirme hakkı yoktur. Sonuç olarak, problemlerin çoğu, programın derlenmesi aşamasında zaten kesilmiştir. Ve programdaki herhangi bir yerden değişkenlere erişim , bir gemideki bir düzine direksiyon simidi ile karşılaştırılabilir.
Gençlere eğitim verilmeli.
Ayrıca muhaliflerin sözlerinde rasyonel bir zerre olması da mümkündür. Diyelim ki, Peter'ınki gibi bir anım var - muhtemelen OOP ile de uğraşmazdım.
1. OOP kullanımından Uzman Danışmanlarınızın karlılığı ne kadar arttı?
2. Danışmanlarınızın OOP kullanmayı reddetmeleri arasındaki süre ne kadar azaldı?
Ben de aynı şeyden bahsediyorum... Sadece gerekli değişkenin değerini görmek yerine, ona uygun bir arayüzü nasıl ekleyeceğinizi düşünmeniz ve sonra onu geri çekmeniz gerekiyor. :)
Programlamada mazoşistler için bir mesleğe benziyor :)
Vaughn, konunun üstünde, Peter sana bir tane gönderdi, en büyük yapısını değil.
Kolayca anladın mı?
Bu çok "mazoşizm" - sadece, öncelikle, çalışma koduna girmemeye ve onu bozmamaya izin verir. İkincisi, sistemin yapısını, programın uygun bloklarına gerekli verileri sağlayacak şekilde derhal tasarlamak .
Evet, gerçekten de, Aniden gerekli verileri elde etmenin neredeyse imkansız olduğu ortaya çıkan durumlar var. Birkaç sanal arabirimin arkasına gizlenirler. Ancak bu durum, sistemin orijinal olarak yanlış tasarlandığını, bu verilerin transferini sağlamadığını açıkça göstermektedir. Bu durum gerçekten çok kötü. Kişi ya aceleyle "koltuk değneklerini" ek arayüzler şeklinde şekillendirmeli ya da tüm sistemi basitçe yeniden yapılandırmalıdır. Bu, programcıyı sistemin mimarisi hakkında daha dikkatli düşünmeye motive eder.
Daha az duygu ve düşünce olsaydı ve tartışmanın özü hakkında daha fazla ayrıntı olsaydı, bir bedelin olmazdı. :)
bu tartışmanın artık bir anlamı yok. Temelde sel ve aptal gibi davranıyorsun.
Bir moderatör son birkaç sayfayı genel olarak dal ve programlama konusuyla ilgili olmayan bir şekilde ovuşturursa, onun eylemlerini desteklediğim nadir bir durum olacaktır.
1. OOP kullanımından Uzman Danışmanlarınızın karlılığı ne kadar arttı?
2. Danışmanlarınızın OOP kullanmayı reddetmeleri arasındaki süre ne kadar azaldı?
1. Ne kadar değil. Karlılık OOP'ye bağlı değildir.
2. Bence, bir büyüklük sırası (on kez). Ancak OOP'nin ana yararı kod bakımıdır. Şimdi bir yıl veya daha önce yazdığım kodu çok çabuk anlıyorum. İlk ANSI C programlarımı nasıl anladığımı çok iyi hatırlıyorum - tamamen prosedürel bir tarzda. Çok daha zordu.
Hata ayıklama, her sınıftaki sorumlulukların sınırlandırılmasıyla tam olarak kolaylaştırılır: her sınıf kendi değişken kümesinden sorumludur. Başka hiçbir sınıfın değerlerini değiştirme hakkı yoktur. Sonuç olarak, problemlerin çoğu, programın derlenmesi aşamasında zaten kesilmiştir. Ve programdaki herhangi bir yerden değişkenlere erişim , bir gemideki bir düzine direksiyon simidi ile karşılaştırılabilir.
İşimde neden HİÇ böyle bir şey görmediğimi anlayamıyorum. Çok büyük olmayan bir programda BİR geliştiricide değişkenlere erişimin farklılaşması sorunları nereden geliyor? Her biri 100 fonksiyon yazacak 100 geliştirici olacaktır. Teorik olarak, olabilir. Ama pratikte, programlama neredeyse 40 yıldır OOP'a dönüştü, dağlarca kod yazıldı ve ben hiç böyle bir şey duymadım.