OOP vs prosedürel programlama - sayfa 40
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
İş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? :)
Pekala, zaten söyledim - Peter'ın yukarıda sağladığı yapı dosyasıyla çalışmayı deneyin. Oradan ihtiyacınız olan verileri "yakalayın" ve ardından doğru yere geri girin.
Ve aynı yapının küçük bir bölümünü veren "kesilmiş" bir arayüzden gerekli verileri almakla karşılaştırın. Arayüz ile - başka bir şey elde etmenin veya "yanlış yere" bir şey yazmanın hiçbir yolu yoktur.
Hayır, unutma yeteneği körelmiş bir ezberleme titanıysanız, o zaman şanslısınız ve OOP'ye ihtiyacınız yok. Ama herkes o kadar şanslı değil.
SanSanych, OOP'nin belgelerle değiştirilmesini önerir - prensipte, aynı zamanda bir seçenektir, ayrıca Peter tarafından önerilen yapılara çok daha yakındır. Sadece Peter'ın tüm belgeleri "aklında", SanSanych'te ise kağıt üzerinde (veya elektronik ortamda) var.
Ve burada bu "korku" nun gösterilmesi ilginçtir.
Bu arada, Renat Fatkhullin, gerçekten de örneklere bakmak ilginç olurdu ...
Hayır, unutma yeteneği körelmiş bir ezberleme titanıysanız, o zaman şanslısınız ve OOP'ye ihtiyacınız yok. Ama herkes o kadar şanslı değil.
SanSanych, OOP'nin belgelerle değiştirilmesini önerir - prensipte, aynı zamanda bir seçenektir, ayrıca Peter tarafından önerilen yapılara çok daha yakındır. Sadece Peter'ın tüm belgeleri "aklında", SanSanych'te ise kağıt üzerinde (veya elektronik ortamda) var.
Değişkenin anlamını herhangi bir şekilde bilmeniz gerekir, ancak hatırlamak gerekli değildir - bağlamdan net değilse bir yorum yazabilirsiniz. Açık görünüyor.
OOP ile, çok daha fazlasını hatırlamanız ve belgelemeniz gerekiyor, yani neyin ne zaman ve hangi anda yaratıldığını ve yok edildiğini, hangi arayüzlerden hangi anda aktığını ve nihai sonuç için tamamen işe yaramaz benzer fare yaygaralarını - sadece bundan. tek başına, zihinsel olarak sağlıklı herhangi bir insan delirebilir ve beynini kırabilir.
Bu arada, tüm OOP muhaliflerinin programların assembler ile yazıldığı zamanları hatırlaması iyi olur.
Ve özellikle - BIOS ve DOS kullanarak dosyalarla çalışın.
Benim düşünceme göre, prosedürel ve OOP yaklaşımı arasındaki fark, BIOS ve DOS kullanan bir diskle çalışmakla hemen hemen aynı.
Hem BIOS hem de DOS - diskle çalışmak için gerekli tüm işlevlere sahiptir.
Ancak, BIOS işlevlerine sahip bir dosya oluşturun ve "Merhaba dünya!" - bu, FAT sistemli diskler için bile oldukça ciddi bir sorundur. Bir zamanlar bunu bir cesaretle yaptım ve benim için çok zordu. DOS'ta bu, tek bir işlevle kolayca yapılır.
BIOS kullanarak bir NTFS sistemi için böyle bir dosya oluşturmanın ne kadar zor olduğunu hayal edebiliyorum ...
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ı.
Evet, içeri girmem gerekiyor ve sen bana buradaki kapıyı göster. Muhtemelen bir sınıf kurucusunun ne olduğunu bilmiyorsunuzdur.
Sadece ortak parametreler - zaten sınıf içinde görünürler, ancak bunları kullanmak iyi değil, OOP ortak alandan kaçabilmek için iyidir.
Doğrudan nasıl? Kapıdan değilse, duvarı çıkar mı? Yapıcı aracılığıyla doğrudan transfer olarak da görünüyor. Yeni olmadan bile bir nesne oluşturulurken parametreler anında iletilebilir. Sınıfın kabul etmesi gereken parametreleri açıklamak için çok tembel olduğun ortaya çıktı? Fonksiyon ve değişken yazamayacak kadar tembel misiniz?
Stopudo yazılan hiçbir şeyi anlamadın))
Dmitry Fedoseev :
Fonksiyon ve değişken yazamayacak kadar tembel misiniz?
Fonksiyonlar yazılmalı ve değişkenler her yerde ve OOP ile bildirilmelidir. Sadece OOP ile, bununla daha gereksiz bir yaygara olacak ve sonra, her şey önceden tahmin edilirse, projenin sonunda yüz kez yeniden yazmamak için ne tür bir veri yapısı olacak. Açık görünüyor.
Fonksiyonlar yazılmalı ve değişkenler her yerde ve OOP ile bildirilmelidir. Sadece OOP ile, bununla daha gereksiz bir yaygara olacak ve sonra, her şey önceden tahmin edilirse, projenin sonunda yüz kez yeniden yazmamak için ne tür bir veri yapısı olacak. Açık görünüyor.
Daha fazla yaygara, ancak oyunun muma değdiği durumlar ve çoğu var. Genellikle ölümcül değildir.
Daha fazla yaygara, ancak oyunun muma değdiği durumlar ve çoğu var. Genellikle ölümcül değildir.
Ne zamandır bu kitaplığınıza göz atıyorsunuz?
2 yıl kesintisiz çalışma.
Grafik arayüzün çekirdeği (bu arada, eleman prototiplerini içeren bir proto-çekirdek de var. 2 megabayt alır. Benim verdiğim gibi tablolardan oluşur), binlerce değişken içerir. Ne dersiniz, eğer çekirdeği bir merkez olarak kullanmasaydım ve değişkenleri sınıflar ve yapılar arasında dağıtmasaydım ve aralarında çeşitli erişim kontrolleri aracılığıyla bir bağlantı kursaydım, görevimin üstesinden gelebilir miydim? - Asla yalnız değil. Program varlıklarının sayısı birkaç kat artacaktı. Kod içindeki işlevler ve sınıflar arasındaki bağlantılar o kadar karmaşık hale gelirdi ki kendi başıma çalışmaya devam edemezdim. Bir bütün olarak tüm mekanizmanın verimliliği düşecektir.
Sınırıma çok daha erken ulaşır ve dururdum.
Çoğu zaman kendime şu soruyu sordum: " OOP kullansaydım ne elde ederdim?" ve her seferinde, günlük pratiğe güvenerek, o kadar ileri gidemeyeceğimi anladım.
Ek olarak, benim düşüncem zaten yapılandırılmış ve bu nedenle bu konuda OOP'ye ihtiyacım yok.
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.
Renat, lütfen gergin olma. Ben kendim R'nin destekçisi değilim. Sen mükemmel bir lider ve programcısın, forumdan kalbe ağlama.
Size ve Rashid'e ve ekibinize sağlık ve yaratıcı başarılar diliyorum!