OOP için genel gider - sayfa 3
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
1. Örneğin, bir dizi nesneye ihtiyacınız var.
Bu hem yordamsal biçimde hem de CArrayObj ve CObject temelinde yapılabilir. Örneğin nesneleri eklerken veya çıkarırken veya bunları sıralarken davranışı değiştirmek gerektiğinde sorunlar başlayacaktır. OOP'de, gerçek işaretçi dizisi için destek ve onunla çalışma, temel nesnelerde bulunur. Dizide gerçekten bulunan alt nesnelerin değiştirilmesi hiçbir şeyi etkilemez. Prosedürel stille - dizide bulunan gerçek nesnelerin değiştirilmesi - kural olarak, en azından nesnelerin boyutundaki değişikliğin dikkate alınması gerektiğinden, daha fazla yeri etkiler. Hangi hata yapmak çok daha kolay.
2. Çapraz platform - OOP tarzında organize etmek de çok daha uygundur. Diyelim ki bir ticaret pozisyonunun talebi üzerine - bir arayüz alıyoruz ve bizim için hangi platformda çalıştığımız önemli değil - arayüz sanal işlevler sunuyor , bu sayede tüm siparişlerdeki tüm verileri alabilirsiniz ( MT4) veya pozisyonlar (MT5) için ayrıca, Bir uzmanın bakış açısından hiçbir fark yoktur. Uzmanın hangi platformda çalıştığını bilmesine gerek yoktur.
3. Ne de olsa, "prosedürel programlamada akla getirmek" - bu "nesneler-prosedürler yazmak", yani OOP'de nesneleri temsil eden veriler ve prosedürler arasında bazı bağlantılar oluşturmaktır.
4. Ve sonra, diyelim ki, pek çok ortak noktanın olduğu bir dizi emir tipine sahibiz. Temel nesne olacak COorderInfo nesnesini ve onun soyundan gelenleri farklı emir türlerini temsil etmek mantıklıdır. Aynı zamanda, alım satım işlemcisi (CTradeProcessor sınıfına sahibim), kendisine iletilen emri tam olarak bu emri işlemek için gereken prosedürlerle tam olarak destekleyecektir.
5. Çapraz bağlantıların en az olduğu yerde hataları yakalamak daha kolaydır. Bu sadece kapsülleme ve polimorfizm ile sağlanır. Alım satım pozisyonu arayüzünü (CTradePositionI) talep ediyoruz - ve bu pozisyonu temsil eden gerçek sınıflara (CMT4PositionInfo, CMT5PositionInfo) tüm linkler - sadece bu arayüz üzerinden yapılıyor, bu da hataları düzeltmeyi doğrudan gerçek fonksiyonlarla çalışmaktan daha kolay hale getiriyor. , hangi ticaret pozisyonu verilerini döndürür.
1. Örneğin ne için?
2. Aynı fonksiyon neden farklı platformlarda derlenemiyor ve buna arayüz üretilemiyor?
3. Bir işlevi bir sınıfın üyesi olarak çağırmaya benzeterek ele almayı daha uygun hale getirmek için işlevlerin metnini yapının türüne göre paketlemek anlamına geliyordu. Bunun için prensipte hiçbir nesnenin oluşturulmasına gerek yoktur.
4. Arayüzler üzerinden birden fazla nesne ve gereksiz bağlantılar üretmemek, ayarlarla tek bir fonksiyon yapmak daha mantıklıdır.
5. Buna ek olarak, tüm bu bağlantıların programlanması ve ardından, hataların da ince olabileceği arabirimler vb. aracılığıyla izlenmesi gerekir. Meslek, başlangıçta gereksiz ve anlamsızdır.
1. Örneğin ne için?
2. Neden aynı fonksiyon farklı platformlarda derlenemiyor ve buna arayüz üretilemiyor?
3. Bir işlevi bir sınıfın üyesi olarak çağırmaya benzeterek ele almayı daha uygun hale getirmek için işlevlerin metnini yapının türüne göre paketlemek anlamına geliyordu. Bunun için prensipte hiçbir nesnenin oluşturulmasına gerek yoktur.
4. Arayüzler üzerinden birden fazla nesne ve gereksiz bağlantılar üretmemek, ayarlarla tek bir fonksiyon yapmak daha mantıklıdır.
5. Buna ek olarak, tüm bu bağlantıların programlanması ve ardından, hataların da ince olabileceği arabirimler vb. aracılığıyla izlenmesi gerekir. Meslek, başlangıçta gereksiz ve anlamsızdır.
1. CTradePosition sınıfı aslında açık siparişlerin bir listesidir. Sıralamalar farklıdır ve onlar için bir arayüze, bir temel sınıfa ve gerçek sınıflara sahip olmak çok uygundur.
2. Sadece bir arayüz. Tüm platformlar için. Ve OOP durumunda - sadece nerede çalıştığımızı düşünmüyoruz. Platforma bağlı ve siparişe bağlı anları hesaba katmak gerekli değildir.
3. Ve böyle bir pakette bir nesne ile bir fonksiyon arasındaki fark nedir? Bundan bahsediyorum - aslında aynı şey. Bir nesne durumunda, otomatik bir yapıcı işlevi de eklenir, ancak varsayılan olarak boştur.
4. İşte bu, sadece bu "ayarlı tek işlev" sorunların kaynağıdır. Genellikle çok fazla ayar olduğundan. Ve sınıf hiyerarşisinin farklı seviyeleri tarafından ayrılmazlar, tam da bu işlevde yoğunlaşırlar. Arayüz ise, bu bağlamda kullanılmayan tüm ayarları - "değerlendirme kapsamı dışında" - bırakmanıza izin verir ve bu, kodu anlama ve hata yapma olasılığı üzerinde çok iyi bir etkiye sahiptir. , ve onların tespiti. Bu kesinlikle OOP'nin ana avantajıdır - nesnelerdeki hiyerarşinin farklı seviyelerine "dağılmış" tüm işlevselliğe sahibiz ve bir veya başka bir kısmı ile çalışırken - geri kalanı - müdahale etmeyin. Ayarlarla birlikte tek bir işlevde, gereksiz olsa bile tüm işlevler her zaman kullanılabilir. Bu genellikle bir sorun kaynağıdır çünkü yanlışlıkla değişkenleri karıştırabilirsiniz. Ana dezavantajı, böyle tek bir işlevde oshikbi'yi tespit etmenin çok daha zor olmasıdır.
5. Her durumda, bu bağlantılara ihtiyaç vardır ve programlanmaları gerekir - bunlar aslında tek bir işlevde aynı ayarlardır. Burada, benim örneğim için - tek bir fonksiyonda platform farklılıklarına, farklı emir türlerine, pozisyonların temsilindeki farklılığa erişimimiz var - tüm bunlar dikkate alınmalıdır. Bir arayüz olduğunda - bizim için her şey "kesilir" - sadece arayüzün tanımladığı şeyi dikkate almak mümkündür.
Kapsüllemenin amacı, bir kod bloğundan başka bir bloğa erişimi kısıtlamaktır. Bunun tam tersini, "maksimum ayarlara sahip büyük bir evrensel işlev" olmasını önerirsiniz, böylece bu işleve erişimi olan herkes maksimum fırsatlara sahip olur. Tecrübelerime göre bu yanlış yoldur. Programın bir bloğunun başka bir bloğun işlevselliğine ihtiyacı varsa, kullanıcıyı mümkün olduğunca sınırlamak için doğru yol tam tersidir - yalnızca bu işlevselliğe sahip olmalıdır, daha fazla değil. Bu, daha kararlı ve hatasız bir kodun anahtarıdır.
1. CTradePosition sınıfı aslında açık siparişlerin bir listesidir. Emirler farklıdır ve onlar için bir arayüze, bir temel sınıfa ve gerçek sınıflara sahip olmak çok uygundur.
Emirleri bir dizi yapıda veya MT4'te uygulanma biçiminde tutmak neden kötü?
Emirleri bir dizi yapıda veya MT4'te uygulanma biçiminde tutmak neden kötü?
Her kullanıcının bu diziye erişirken çok fazla hakka ve çok fazla ek bilgiye sahip olması.
Benim düşünceme göre, kullanıcıya sadece ihtiyaç duyduğu işlevsellik kısmını sağlamak daha doğru - sadece siparişlere erişmek için önceden kararlaştırılmış bir arayüz yardımıyla.
Her kullanıcının bu diziye erişirken çok fazla hakka ve çok fazla gereksiz bilgiye sahip olması.
Benim düşünceme göre, kullanıcıya sadece ihtiyaç duyduğu işlevsellik kısmını sağlamak daha doğru - sadece siparişlere erişmek için önceden kararlaştırılmış bir arayüz yardımıyla.
Siparişler için kendi veri tipinizi oluşturabilirsiniz, herhangi bir arayüze, nesnelere ve gereksiz bug ve kararsızlıklara neden olan diğer gereksiz karmaşıklıklara gerek yoktur.
Siparişler için kendi veri tipinizi oluşturabilirsiniz, herhangi bir arayüze, nesnelere ve gereksiz bug ve kararsızlıklara neden olan diğer gereksiz karmaşıklıklara gerek yoktur.
Uygulamam gösteriyor ki, sonuçta buna ihtiyaç var.
Bu yolu beş yıl önce, o zamanlar MT4'te izledim. (OOP hakkında bilgim olmadığı için değil, arayüzler ve kalıtımla uğraşamayacak kadar tembeldim, özellikle o zamanlar MT4 ve MT5 MQL uygulaması açısından önemli ölçüde farklılık gösterdiğinden). Bu, onun yanıldığını anlamamı sağladı. Bu "karmaşıklıklar" değil, oldukça makul bir kısıtlama, bir tür "aptallara karşı koruma". Yüzlerce değişkenin her birinin neden sorumlu olduğunu her zaman hatırlıyorsanız, kapsüllemeye ihtiyacınız yoktur. Bunu hatırlamıyorum ve programın her bloğunda mümkün olduğunca az varlığa erişim olmasını tercih ediyorum.
MT4'te OOP ortaya çıkar çıkmaz, tüm geliştirmelerimi hemen arayüzlere dayalı tek bir forma çevirmeye başladım.
1. Uygulamam gösteriyor ki, sonuçta buna ihtiyacınız var. Bu, onun yanıldığını anlamamı sağladı.
2. Bunu hatırlamıyorum ve programın her bloğunun mümkün olduğunca az varlığa erişimi olmasını tercih ediyorum.
1. Neyin gerekli olduğu ve neyin yanlış olduğu açıklanmadı. Bu özel bir veri türü olduğundan, oraya erişimi istediğiniz gibi yapılandırabilirsiniz. Örnek açıkça başarısız.
2. Programcının, iddiaya göre orada karıştıracağı bahanesiyle programında kendi verilerine erişmesini yasaklamak - bu açıkça hatalı bir düşüncedir, çünkü o zaman programcıya bu erişimi nasıl vereceğiniz konusunda her türlü zor geçici çözümü oluşturmanız gerekecektir. daha sonra ve yol boyunca bir grup olası hatayla birlikte kararsız bir kod oluşturulur. Bu, sürücünün direksiyon simidine dokunmasını yasaklamaya ve ardından geçici çözümler-arayüzler bulmaya benzer, daha sonra direksiyon simidi yerine arabayı nasıl kullanabilir.
2. Programcının, iddiaya göre orada karıştıracağı bahanesiyle programında kendi verilerine erişmesini yasaklamak - bu açıkça hatalı bir düşüncedir, çünkü o zaman programcıya bu erişimi nasıl vereceğiniz konusunda her türlü zor geçici çözümü oluşturmanız gerekecektir. daha sonra ve yol boyunca bir grup olası hatayla birlikte kararsız bir kod oluşturulur. Bu, sürücünün direksiyon simidine dokunmasını yasaklamaya ve ardından geçici çözümler-arayüzler bulmaya benzer, daha sonra direksiyon simidi yerine arabayı nasıl kullanabilir.
Hayır. Kodun herhangi bir yerinde - yalnızca bu yerde ihtiyaç duyulanlar mevcut olmalıdır - mümkünse diğer her şey kesilmelidir.
Sürücü ile olan durumunuzda, bu, sürücünün araç park halindeyken direksiyona dokunmayı yasaklamasının makul olduğu anlamına gelir. Otoparkta direksiyon simidini çevirmeyi kafasına almaması için - sonuçta, şu anda, örneğin, tekerlek hizalama sensörleri tekerleklere bağlanabilir ve direksiyon simidinin sürücü tarafından tutulması yol açacaktır. bu açıların ayarlanmasındaki hatalara.
Buradaki fikir, her an yalnızca o anda ihtiyaç duyduğu işlevselliğin program tarafından kullanılabilir olması ve diğer her şeyin kapatılacağıdır. Uzun zamandır en az hatanın bu şekilde yapıldığına ikna oldum.
Hayır. Kodun herhangi bir yerinde - yalnızca bu yerde ihtiyaç duyulanlar mevcut olmalıdır - mümkünse diğer her şey kesilmelidir.
Buradaki fikir, her an yalnızca o anda ihtiyaç duyduğu işlevselliğin program tarafından kullanılabilir olması ve diğer her şeyin kapatılacağıdır. Uzun zamandır en az hatanın bu şekilde yapıldığına ikna oldum.Kendinizi yasaklamanız ve izin vermeniz gereken şeylerle sürekli olarak uğraşmak, açıkçası çok mantıksız bir gerekliliktir, tabii ki programcı sarhoş bir şekilde kod yazmak için oturmadıysa ve kendini kontrol etmiyorsa, bu da anlaşılmaz bir sürü kod yazabilir. kendisi. Bunun sarhoş bir alkolik programcının koddaki hatalardan kaçınmasına yardımcı olmayacağını düşünüyorum ve ayık insanların başlangıçta buna ihtiyacı yok.
Kendinizi yasaklamanız ve izin vermeniz gereken şeylerle sürekli olarak uğraşmak, açıkçası çok mantıksız bir gerekliliktir, tabii ki programcı sarhoş bir şekilde kod yazmak için oturmadıysa ve kendini kontrol etmiyorsa, bu da anlaşılmaz bir sürü kod yazabilir. kendisi. Bunun sarhoş bir alkolik programcının koddaki hatalardan kaçınmasına yardımcı olmayacağını düşünüyorum ve ayık insanların başlangıçta buna ihtiyacı yok.
Bu, birçoğunun geldiği çok mantıklı bir gerekliliktir.
Buna ihtiyacınız yok - peki... OOP kullanmayın.