Alım-satım fırsatlarını kaçırıyorsunuz:
- Ücretsiz alım-satım 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
Bir sınıfın sadece iç değişkenleri vardır ve hiçbir girdisi veya çıktısı yoktur... Dış dünyayla teması olmayan ve kendi suyunda kaynayan böyle bir nesnenin programlanmasındaki kullanımını nerede gördünüz?
Neden görmediğin şeylerden bahsediyorsun? Bir sınıf yapıcısı oluşturulur ve herhangi bir sayıda parametre alabilir. Farklı alt sınıflar, yapıcılarında tamamen farklı parametre kümelerine sahip olabilir. Evet, parametreleri ayarlamak için basitçe yöntemler yazabilirsiniz.
1. Bu, OOP ihtiyacına verilen ana cevaptır.
2. Bu bir ekip deneyimi meselesidir. 2008-2009'da ihtiyacınız olan her şeyi yazdım. Birkaç yıl önce daha fazla yazmaya karar verdim - her şey okunabilir, sorun yok.
Cevaplarınızdan bir şeyi anladım: OOP, bir programlama disiplini tanıtan, tekdüzelik getiren bir tür standarttır ve bu temelde başlangıçta daha az hata vardır ve en önemlisi ve en önemlisi, değişiklik sırasındaki sorunlar temelde azalır. Ancak aynı sonuç, GOST'lerin, geliştirme aşamalarının, belgelerin dikkatle gözlenmesiyle elde edildi.
Aynı şeyi ne kadar tekrar edebilirsin? OOP sadece bir kod yapılandırma aracı değildir, aynı zamanda prosedürel programlamanızda olmayan mekanizmalara da sahiptir.
Muhtemelen durum bunlardır, insan dağları görmediyse ne olduğunu anlamaz, en azından söyle.
Kişisel olarak çözümlerde evrensellik için çabalıyorum. Bu , kod miktarını artırmadan benzer işlevleri bir bloğa "birleştirmeyi" gerektirir. Mekanizmanın verimini arttırır ve aşırı yük ve ayırma gerektirmez. Sadece beynini kullan ve hepsi bu.)
Yani, her biri 20 satırlık iki fonksiyon vardı. Her ikisi de benzer eylemler gerçekleştirir veya aynı tür görevleri çözer. Amacım, onları her iki işlevin de işini yapan 20 satırdan fazla olmayan tek bir işlev haline getirmek. Blokları bu şekilde alıyorum.
Ne zamandır bu kitaplığınıza göz atıyorsunuz?
Holivar adına - R, "erişim kontrolü olmayan hepsi bir arada çöp kutusu" modunda kesinlikle iğrenç bir şekilde yazılmıştır. Kapsam, koruma ve çoklu oturum olmadan yirmi yıl öncesinden eski tarz yaklaşım. Sanki yalnızmışım gibi yazıyorum. Evet , proje profesyonel olmayan geliştiriciler tarafından bir kişinin altında doğdu. Sıfırdan yeniden yazılması gerekiyor. En azından bir kere.
MQL5'ten R'de normal bir arayüz yapma fikri vardı, ancak daha derine indikten sonra entegrasyonu hemen reddettim. Sistem kategorik olarak verileri ve oturumları koruma konusunda yetersizdir.
Bir programcı, katı gereksinimleri olan (en azından birkaç yıl el ele vererek) normal geliştirme ekiplerinde çalışana kadar, normal anlamda bir geliştirici olmayacaktır. Adayları değerlendirirken test maddelerine baktığımızda zamanın %90'ını kafamıza takıyoruz. Geliştirme endüstrisi boyunca toplam korku.
Bu nedenle, bir kez daha tekrar ediyorum - FKÖ karşıtları burada bir tür saçmalık sergiliyor.
Tekrar özür dilerim.
sersemlemiş!
Merak ediyordum: Modern programlamada yenen yumurta seviyesi sorununu daha ani bir şekilde karıştırmak için başka bir olasılık var mı?
Trafik sıkışıklığındaki arabaya gelen sizsiniz, nasıl çalıştığına bakın - ve sürücüye söyleyin, "sorunu daha ani bir şekilde karıştırmanın, sonra yüz metre yürümenin bir yolu var mı?" diyorlar.
Deneyimlerimin gösterdiği gibi, bu tür "karmaşık sorunları" çözmek, tüm global değişkenlerle tek bir şablondan kopyala-yapıştır kullanılarak yapılan "sorunsuz" Uzman Danışmanlardan çok daha kolaydır.
Neden görmediğin şeylerden bahsediyorsun? Bir sınıf yapıcısı oluşturulur ve herhangi bir sayıda parametre alabilir.
Daha dikkatli okuyun, bu, sınıf kurucusuyla değil, sınıfla ilgiliydi.
Ek olarak, yine maymun işi yapmayı öneriyorsunuz - bir bahçedeki bir bahçeyi çitle çevirmek, dış değişkenler durumunda HİÇBİR ŞEY yapmadan veya yapıcılar-yıkıcılar ve her türlü gereksiz baş ağrısı olmadan doğrudan iletmeden parametrelere erişebiliyorsanız. ilgili bellek sızıntıları.
OnInit()'im hemen hemen aynı görünüyor - bir düzine satır...
Ne olmuş?
Buna gelirsek, o zaman TÜM danışmanda bir düzine satırım var (eklemeler ve yorumlar hariç).
Burada bir Uzman Danışmanda aynı anda ÜÇ tamamen farklı TS vardır. Birbirlerine müdahale etmeden aynı anda çalışırlar.
Uygun fabrikayı bildirerek ve onu işleve döndüren kodu yazarak ek TS'ler ekleyebilirsiniz.
Ancak asıl soru, kodda az veya çok satır olup olmadığı değildir. Soru, gerekirse bakımının ve değiştirilmesinin ne kadar kolay olduğudur.
SanSanych, Peter tarafından sağlanan tablo dosyasını kolayca anlayabiliyor musun? Ve kolayca değiştirebilir misin? Öyleyse, Peter gibi senin de OOP'ye ihtiyacın yok.
OOP, bir mekanizmanın parçalarını ayırma, sarma ve gizleme yöntemidir. Gerekli olup olmadığına geliştirici karar verir. Mekanizmanın verimliliğini artırmakla hiçbir ilgisi yoktur. Düşünmeyi yapılandırmak, evet. Doğru yapılandırılıp yapılandırılmadığı bilinmiyor. Bunun gerekli olup olmadığı kişiye bağlıdır. BENİM NACİZANE FİKRİME GÖRE.
Aynen öyle. Kapsüllemenin özü budur.
Kalıtım ve polimorfizm de var.
OOP, bir mekanizmanın parçalarını ayırma, sarma ve gizleme yöntemidir. Bunun gerekli olup olmadığı kişiye bağlıdır. BENİM NACİZANE FİKRİME GÖRE.
İşte bu, belirli bir kişiden. Neden şizofreniden muzdarip olmayan bir programcı, hatalarını ayıkladığı kendi kodunun bir kısmına erişimini kendisinden saklamak için çok uğraşsın? Belki ellerini bağlamak daha iyidir? :)
Bir programcı, katı gereksinimleri olan (en azından birkaç yıl el ele vererek) normal geliştirme ekiplerinde çalışana kadar, normal anlamda bir geliştirici olmayacaktır. Adayları değerlendirirken test maddelerine baktığımızda zamanın %90'ını kafamıza takıyoruz. Geliştirme endüstrisi boyunca toplam korku.
Ve burada bu "korku" nun gösterilmesi ilginçtir.
Bunun OOP kullanımından kaynaklandığını varsayabilirim, çünkü prosedürel programlamada odak, herhangi bir yoğunluktaki bir ormanı yığması çok kolay olan herhangi bir harici OOP eklentisinde değil, algoritmanın mantığındadır.