OOP uzmanları için soru. - sayfa 10
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
Ben de aynısını yapıyorum - yavaş yavaş ... ve tam bir anlayış sadece 4-5 yıl sonra geliyor (ve bu sıradan bir insan için normaldir)
Benim düşünceme göre, "tam anlayış" gerekli değildir. Ana şey "özü yakalamak". OOP metodolojisiyle tanıştığımda, 1995'ti.
K&R damarında "düz C" ile zaten biraz deneyimim oldu (eski kafalılar hatırlamalı) ve ayrıca assembler fonksiyonlarını oldukça sık kullandım. İlk başta, OOP fikirleri hakkında oldukça şüpheliydim, programcının bazı ek eylemler gerçekleştirmesi gerektiğinden değil, tamamen işlemci "ek yükü" nedeniyle. Ancak bu teknolojinin faydalarına çok çabuk ikna oldu. Bence ana "anahtar" CString sınıfıydı .
Sadece bu değil, dizelerle çalışmak büyük ölçüde basitleştirildi. O zaman bir veri sarmalayıcı yazıyorduk, benim bölümüm giriş metni ayrıştırıcısıydı. Buna göre, CString sınıfını temel alarak, paketleyicimiz için önemli farklılıkları olan farklı dizelerden oluşan bir hiyerarşi oluşturmanın çok uygun olduğu ortaya çıktı.
Özellikle veri paketleyici yazıldıktan sonra, paketleyicinin orijinal olarak tasarlanmadığı çok sayıda dijital bilgi içeren dizeler için kullanma görevinin ortaya çıkması hoşuma gitti. Tabii ki, bu tür verileri paketledi, ancak giriş alfabesini sadece semboller olarak kabul etti, ancak bir dizenin birkaç kelime ve sayıdan oluştuğunu bilerek, hız kaybetmeden paketlemeyi önemli ölçüde geliştirdi. Böylece, bu tür dizeleri sayılarla temsil eden bir sınıf (ve sayılar için belirli bir sıkıştırıcı) yazıldı, her şey mevcut sınıflara eklendi ve bu tür bir işlevsellik başlangıçta amaçlanmamasına rağmen, paketleyici yeni verilerle çalışmaya başladı.
İşte o zaman OOP'nin kodu değiştirme ve koruma yeteneğini kontrol ettim. Tabii ki, bir işlemci ek yükü var, ancak bu, programcıların çalışmalarında bir azalma ile dengelenmekten daha fazlası.
Bu nedenle, OOP'ye başlayan herkese, OOP'nin avantajının açık ve net bir şekilde görülebileceği bu tür görevlerle çalışmaya başlamalarını tavsiye ederim. Yani, ortak bir ataya sahip sınıfların örneklerini temsil edecek olan listelerdeki farklı nesneleri işleme görevlerinden.Bakın, aboneliklerimde bu kanal var, genel olarak yazar hakkında olumlu bir fikrim var, videonuzun anlaşmazlığının başladığı konunun tekrarı bile var:
Videodaki hemen hemen her şeye katılıyorum. Birkaç küçük itiraz var, hatta itirazlar bile değil, ancak açıklamalar (diyelim ki, NULL bir hatayı gösteren çok kullanışlı bir işaretçidir, sadece işlevin bu boş işaretçiyi döndürebileceğini aklınızda tutmanız gerekir ve tabii ki) , video doğru bir şekilde söylüyor - bir nesne olarak manipüle edilemez).
Ve diğer her şey ve yanlışlıklar ve geliştirme sırası ve alıcı-ayarlayıcılar hakkında ve aynı NULL hakkında - her şey doğru.
Yazara saygılar.
Felsefi düşünceye sahip ve soyutlamada iyi olan biri olarak, profesyoneller tarafından sevilen programlama yaklaşımını umutsuzca reddetmem garip. Tasarlanan pratiklik ile, OOP varlıklar edindi ve görevlerinde gereksiz hale geldi. Araçların "fazlalığı", eksikliğin yanı sıra çözümü de engeller. Ve bu fazlalık şüphesiz pazarlamanın bir sonucudur. Bunu düşün. Minimal OOP, bilgisayar problemleri alanındaki her şeyi çözmek için yeterlidir. Tıpkı her şeyin basit işlevlerle ve bellekle düzgün çalışmayla oluşturulabilmesi gibi. İlköğretim düzeyinde, hemen OOP'yi kabul ettim. Daha sonra bazı varlıkların varlık ihtiyacını haklı çıkaramadıklarını ve büyüyen bir kavram içinde görevlerden soyutlanmış kendi hayatlarını yaşadıklarını fark etti. Evet, çözümlere entegre edilmişlerdir, ancak geliştiricinin zekasını parazitleştirirler. İş sürecini yavaşlatarak verimliliğini düşürürler. Karışıklığa, söz dizimine, kurallara müdahale ediyorlar... Çözümün içindeki bu seçeneği beğenmedim.
Bu yüzden, en minimal OOP'yi kullanacağım. Pazarlamaya başlamadan önce yaratılan.
Felsefi düşünceye sahip ve soyutlamada iyi olan biri olarak, profesyoneller tarafından sevilen programlama yaklaşımını umutsuzca reddetmem garip. Tasarlanan pratiklik ile, OOP varlıklar edindi ve görevlerinde gereksiz hale geldi. Araçların "fazlalığı", eksikliğin yanı sıra çözümü de engeller. Ve bu fazlalık şüphesiz pazarlamanın bir sonucudur. Bunu düşün. Minimal OOP, bilgisayar problemleri alanındaki her şeyi çözmek için yeterlidir. Tıpkı her şeyin basit işlevlerle ve bellekle düzgün çalışmayla oluşturulabilmesi gibi. İlköğretim düzeyinde, hemen OOP'yi kabul ettim. Sonra bazı varlıkların varlıklarının gerekliliğini haklı çıkaramadıklarını ve büyüyen bir kavram içinde görevlerden soyutlanmış kendi hayatlarını yaşadıklarını fark etti. Evet, çözümlerde yerleşiktirler, ancak geliştiricinin zekasını parazitleştirirler. İş sürecini yavaşlatarak verimliliğini düşürürler. Karışıklığa, söz dizimine, kurallara müdahale ediyorlar... Çözümün içindeki bu seçeneği beğenmedim.
Bu yüzden, en minimal OOP'yi kullanacağım. Pazarlamaya başlamadan önce yaratılan.
Evet. Burada bir sınıf oluşturdunuz, örneğin bir dosyayla çalışın. Kullanmaya başladınız ve böcekler düşmeye başladı. Kodun bir bölümünde tutamaç kapatıldı ve diğerinde onunla bir şeyler yapmaya çalışıyorsunuz. İkiye yaklaş. Birincisi, her zaman nerede, ne yapıldığını hatırlamaya çalışmaktır ve tek bir geliştiriciyle bile bu çok başarılı değildir. İkincisi, eylemden önce doğrulama işlemlerini yapmaktır. Tamam, sıradaki hata: Kod boyunca dağılmış doğrulama işlemlerinde, burada ve orada yazım hataları var, işaret aynı değil, bir yerde düzeltildi, başka bir yerde unutuldu vb. Ve sonuç olarak, en sevdiğiniz kod verimliliğinden, banal ve basit bir tanesine geliyoruz, her Okuma / Yazma yöntemi ve bunun gibi diğerleri, kontrol yöntemine bir çağrı içeriyor ve çağrıldığında iptal etme olasılığı ile ki bunu yapacaksınız. neredeyse hiç kullanma. Ve sonra bunun iyi olduğunu anlıyorsunuz, çünkü modern donanım, çözülen görevlerin %98'inde harcanan döngüleri ve tüketilen belleği saymamanıza izin veriyor.
Evet. Burada bir sınıf oluşturdunuz, örneğin bir dosyayla çalışın. Kullanmaya başladınız ve böcekler düşmeye başladı. Kodun bir bölümünde tutamaç kapatıldı ve diğerinde onunla bir şeyler yapmaya çalışıyorsunuz. İkiye yaklaş. Birincisi, her zaman nerede, ne yapıldığını hatırlamaya çalışmaktır ve tek bir geliştiriciyle bile bu çok başarılı değildir.
Peter alır.
Sorun bu - Peter'ın tüm programda her zaman mevcut olan ve istediği zaman ihtiyaç duyduğu şeyi aldığı tüm değişkenlerin büyük bir tablosunu kullanması uygundur. Bir titan için ezberleme oldukça uygundur.
OOP'de kapsülleme, kullanıcının kodun herhangi bir yerinde, başka herhangi bir değişkene değil, yalnızca ihtiyaç duyduğu değişkenlere erişmesini sağlamak için kullanılan temel bir özelliktir. Ve Peter için bu bir eksi, nerede, neyi ve nasıl kullandığını zaten hatırlıyor. Programın herhangi bir bölümündeki herhangi bir değişkene istediği zaman erişebilmek istiyor. Yaklaşımımı beğenmiyor, bir değişkene erişmek için önce arayüze bir işaretçi almanız, istediğiniz işlevi arayüzden almanız ve ancak o zaman gerekli değeri size döndürmeniz gerektiğinde. Ve bu adımlardan herhangi birinde erişim kısıtlamalarıyla karşılaşabilirsiniz. Bunu bir nimet olarak görüyorum, çünkü bir kısıtlama olduğu için - bir nedenden dolayı tanıtıldı, bu, bazı önemli ayrıntıları hesaba katmadığım anlamına geliyor. Ve Peter için bu bir engel çünkü her zaman her şeyi hesaba katıyor.
Evet. Burada bir sınıf oluşturdunuz, örneğin bir dosyayla çalışın. Kullanmaya başladınız ve böcekler düşmeye başladı. Kodun bir bölümünde tutamaç kapatıldı ve diğerinde onunla bir şeyler yapmaya çalışıyorsunuz. İkiye yaklaş. Birincisi, her zaman nerede, ne yapıldığını hatırlamaya çalışmaktır ve tek bir geliştiriciyle bile bu çok başarılı değildir. İkincisi, eylemden önce doğrulama işlemlerini yapmaktır. Tamam, sıradaki hata: Kod boyunca dağılmış doğrulama işlemlerinde, burada ve orada yazım hataları var, işaret aynı değil, bir yerde düzeltildi, başka bir yerde unutuldu vb. Ve sonuç olarak, en sevdiğiniz kod verimliliğinden, banal ve basit bir tanesine geliyoruz, her Okuma / Yazma yöntemi ve bunun gibi diğerleri, kontrol yöntemine bir çağrı içeriyor ve çağrıldığında iptal etme olasılığı ile ki bunu yapacaksınız. neredeyse hiç kullanma. Ve sonra bunun iyi olduğunu anlıyorsunuz, çünkü modern donanım, çözülen görevlerin %98'inde harcanan döngüleri ve tüketilen belleği saymamanıza izin veriyor.
Tersi durumu hayal edelim. Peki, senin böceklerin yok. Hiç ve neredeyse hiç olmaz, çünkü HER ŞEYİ hatırlayın ve HER ŞEYİ hesaba katın! OOP'yi "mesleki görev" dışında kullanır mıydınız ? bence hayır. O zaman seni ne endişelendirecek? - Sadece kodlarınızın verimliliği. Kodun olabildiğince hızlı çalışması için tüm ek yükü kaldırmaya çalışacaksınız. Ayrıca hızlı gelişecek şekilde kod oluşturmaya çalışacaksınız.
Bana burada ve orada görünen böceklerden bahsettiklerinde anlıyorum, ancak OOP kullanımıyla veya kullanımıyla ilişkilendirildiklerinde aynı fikirde değilim. Hataların sayısı, kodunuzun bilgisine ve anlayışına bağlıdır. Hepsinden iyisi, kodu yazan kişi tarafından bilinir ve onu bağlamaz. Bu her zaman daha az hataya sahiptir. Anladığınız gibi, OOP, diğer programcılar tarafından anlaşılmayan arka yüzü olan kodların taşınabilirliğini destekler. Hataların kaynağı burada.
Her şeyi kendim yazıyorum ve profil oluşturucu ve kontrol fonksiyonları olmadan 2000 satırlık bloklarda hatalar buluyorum. Sadece, kodumu biliyorum. Böcekler için en iyi tedavi.))
Peter alır.
Sorun bu - Peter'ın tüm programda her zaman mevcut olan ve istediği zaman ihtiyaç duyduğu şeyi aldığı tüm değişkenlerin büyük bir tablosunu kullanması uygundur. Bir titan için ezberleme oldukça uygundur.
OOP'de kapsülleme, kullanıcının kodun herhangi bir yerinde, başka herhangi bir değişkene değil, yalnızca ihtiyaç duyduğu değişkenlere erişmesini sağlamak için kullanılan temel bir özelliktir. Ve Peter için bu bir eksi, nerede, neyi ve nasıl kullandığını zaten hatırlıyor. Programın herhangi bir bölümündeki herhangi bir değişkene istediği zaman erişebilmek istiyor. Yaklaşımımı beğenmiyor, bir değişkene erişmek için önce arayüze bir işaretçi almanız, istediğiniz işlevi arayüzden almanız ve ancak o zaman gerekli değeri size döndürmeniz gerektiğinde. Ve bu adımlardan herhangi birinde erişim kısıtlamalarıyla karşılaşabilirsiniz. Bunu bir nimet olarak görüyorum, çünkü bir kısıtlama olduğu için - bir nedenden dolayı tanıtıldı, bu, bazı önemli ayrıntıları hesaba katmadığım anlamına geliyor. Ve Peter için bu bir engel çünkü her zaman her şeyi hesaba katıyor.
George, bu sadece hafızayla ilgili değil. Ana dilimin yanı sıra İngilizceyi de kullanarak kendime rahat bir gelişim ortamı oluşturdum. İki dilli bir kod, tek dilli olandan ÇOK daha iyi hatırlanır. Özellikle standart kelimelere takılıp kalmadığınız ve değişkenleri istediğiniz gibi çağırdığınız zaman. Kontrol. Programlamadaki profesyonellik umurumda değildi ve uygun şekilde yazmaya başladım. Sonuç olarak, kodumda hızlı bir şekilde gezinmeye başladım ve kodu okuması, hatırlaması ve geliştirmesi kolaydı. Sonrası biliyorsun...
not. Profesyonelliği kafaya takmak için aradığımı sanmasınlar. Hiçbir durumda. Aşırı şişirilmiş egom yüzünden umurumda değildi. Bunun sadece kötü değil, aynı zamanda iyi olduğu ortaya çıktı. :)
Peter, hiç bir takımda çalışmadığını düşünüyorsun. Herkesin büyük bir görevin üzerine düşeni nasıl yaptığını ve sonunda nasıl bir araya geldiklerini görmedik.
Örneğin, OOP olmadan Windows oluşturmak ve geliştirmek imkansızdı.
İhtiyaç yoksa, o zaman dersleri kullanmamaya da çalışacağım. Ama robotumu çok para birimine sahip bir robota dönüştürmeye karar verdiğimde, OOP olmadan ne olacağı zaten belli olduğu için hemen sınıflara başvurdum.
Sınıfları kullanarak, kullanılan çiftlerin aynı sınıfın nesneleri olduğu açıktır ve onlarla aynı anda çalışmak zaten çok kolaydır.
Peter, hiç bir takımda çalışmadığını düşünüyorsun. Herkesin büyük bir görevin üzerine düşeni nasıl yaptığını ve sonunda nasıl bir araya geldiklerini görmedik.
Örneğin, OOP olmadan Windows oluşturmak ve geliştirmek imkansızdı.
İhtiyaç yoksa, o zaman dersleri kullanmamaya da çalışacağım. Ama robotumu çok para birimine sahip bir robota dönüştürmeye karar verdiğimde, OOP olmadan ne olacağı zaten belli olduğu için hemen sınıflara başvurdum.
Sınıfları kullanarak, kullanılan çiftlerin aynı sınıfın nesneleri olduğu açıktır ve onlarla aynı anda çalışmak zaten çok kolaydır.
Evet, bir ekipte çalışmadım. Yaklaşımım bir geliştirici tarafından bir deney olarak görülmelidir. Onu takip etmesi için ısrar etmiyorum. Yaklaşımımda çok fazla küstahlık var.))
Bir programcı forex dünyasına girerse, profesyonel olmaya ve OOP'yi bilmeye gerek yoktur.
Piyasanın inceliklerini incelemek ve karlı bir ticaret stratejisi geliştirmek daha iyidir. OOP kullanıp kullanmamanız önemli değil. Bu, EA'nın karlılığını etkilemeyecektir.
Enerjinizi boşa harcamanıza gerek yok.