Benim yaklaşımım. Çekirdek - Motor. - sayfa 18
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
hayır, gündelik programlama hakkında bir tartışma varken, ben tüm konuyu OOP'ye sürüklemek üzereyim, konu başlatıcı hala devam ediyor! her şeyi kafanızda tutabileceğinizi yazıyor - peki, bu sıradan programlama)))
çekirdek motor
gelişigüzel programlama
Sıradan programlama :)
Sıradan programlama :)
belki haklısın, böyle bir terimi hatırladım - birkaç ay önce başka bir forumda bir kişi kendine şöyle dedi: gündelik programcı, hatta bunun ne anlama gelebileceğini açıklamaya çalıştım, bildiğim kadarıyla, gündelik kelimesi yalnızca Android oyunu - "Zuma", bunun rastgele programlayan bir programcı olduğunu gördüğünüz ortaya çıktı - durumdan duruma)))
OOP çok esnek bir metodolojidir, bu nedenle "çekirdek" kavramı gibi apriori fikirleri yoktur. Ancak, OOP kullanarak, burada tartışılan çekirdeğin modelini çok iyi oluşturabilirsiniz. Bu nedenle, ifade tamamen doğru değildir.
Hayır, hiç OOP yok. Çekirdek Unix, her şeyi çekirdek etrafında topluyoruz; kabuk - Windows'a benzeyen her şey - gereksiz olanı kaldırırız, geri kalanıyla çalışırız. Genel olarak, bu işletim sistemi ile ilgilidir.
Sıradan programlama :)
Rahat, endişelenme.
Kod yazmanın katı formatı beni OOP'ta itiyor. Gördüğünüz gibi, büyük veri tabloları oluşturma eğilimindeyim ve bunu çok pratik buluyorum. OOP'de, kişisel olarak beni çok fazla kısıtlayan bir dizi kurala uymak zorundayım.
Kısacası, farklı bir OOP ile programlama yapıyorum. Onun. Birkaç kural ve çok fazla özgürlük var. İşlevselliğin kendisi büyük bloklar halinde oluşturulur ve veriler çekirdeklerde düzenlenir. Yapılarını kasten düşünmüyorum bile. Her şey kendi kendine gelişir. Sezgisel düzeyde.Peter, bu kurallar senin ihtiyacın olan şey. Tam da sizi "zincirlemek" için. Böylece yanlışlıkla hiçbir şeyi bozmazsınız ve olmaması gereken bir yere sığmazsınız. Aslında, OOP tarzı "yolun kurallarıdır" - elbette sürücüyü kısıtlarlar. Ve üç yardalı bir köyde - kimse onlara bakmaz, daha kolay ve daha hızlıdır (daha verimli). Ancak, büyük bir şehirde bunun tersi doğrudur - en verimli ulaşım iletişimini mümkün kılan trafik kurallarıdır. OOP ile aynı. Bunlar, büyük karmaşık sistemleri en verimli şekilde oluşturmanıza izin veren kurallardır.
Sisteminiz - sadece henüz herhangi bir değişiklik olmadı, çok sınırlı bir şekilde kullanılıyor ve değiştirilmesi gerekmiyor. Bu yüzden kafanızda tutabilirsiniz. Hiçbir şey, eğer sistem kullanıcıları olacaksa ve iyileştirmeler gerekiyorsa - kontrol ve kapsülleme eksikliği - çok stresli olacaktır.
Diğer her şey - fark yok, OOP ve stiliniz (daha önce de belirtildiği gibi, prosedür stiliniz de aynı dezavantajlardan muzdarip - global değişkenler , tip kontrolünün olmaması vb.) Aksi takdirde yakındır.
Tarzınızı savunmak için kanıtlamanız gereken tek şey, tüm sistemi büyük bir küresel rastgele erişim dizisinde tutmanın, programı polimorfik kalıtım zincirlerinde yuvalanmış ve kapsülleme ile gizlenmiş bir grup küçük parçaya bölmekten daha iyi olduğudur.
Bu arada, forumda mirası sevmeyen insanlar var - sanırım size destek olabilirler.
Peter'ın yönteminin aksine OOP kullanmanın bir başka avantajı. OOP'de programcı, temel sınıfın kaynak koduna ihtiyaç duymaz ve nasıl çalıştığını anlaması gerekmez. Temel sınıfın işlevselliğini genişletmek veya değiştirmek için bu sınıfın bir mirasçısını oluşturmak yeterlidir.
Peter'ın yöntemini kullanırsanız, programcının uzun kod ayak örtüsünün tamamını anlaması gerekecek ve bu kod için kaynak kodu yoksa, tekrar yazılması gerekecektir.
Diğer her şey - fark yok, OOP ve stiliniz (daha önce de belirtildiği gibi, prosedür stiliniz de aynı dezavantajlardan muzdarip - global değişkenler , tip kontrolünün olmaması vb.) Aksi takdirde yakındır.
Tabii ki, yanılıyor olabilirim ve google için çok tembelim, ancak prosedür stili, prosedürün (işlev) mantıksal eksiksizliğini ima ediyor - kaynaktan “çıkarıldı” ve başka bir kodda kullanın, yani. yerleşik MQL işlevlerinin verileri nasıl parametre olarak alıp sonucu döndürdüğü .... ve burada Peter için her iki pençede de her şey topal ))) - küresel olarak bildirilen değişkenler aracılığıyla yapılan alışveriş, kodun taşınabilirliğini azaltır ve görünümüne izin verir. izlemesi zor hatalar ;)
İyi. Bırak ikna olayım.
Prensip olarak, tüm bunları uzun zamandır anlıyorum. Ve buna katılıyorum. Ancak aynı zamanda yaklaşımımı tercih ederim. Niye ya?
Belirli bir nedeni var:
PROGRAM GELİŞTİRME.
//--------------------------------------
Program, OOP ve benim yaklaşımımla ne kadar hızlı gelişecek? Mekanizmaların büyümesi ve karmaşıklığı için hangi yaklaşım daha uygundur?
Benim yaklaşımımın + koddaki anadilin (%60 Rusça ve %40 İngilizce) programın en hızlı büyümesini sağladığı sonucuna vardım.
Bu hızlı büyüme tam da ihtiyacım olan şey. Ayrıntılara girme. Her kod satırının üzerine gelmemek. Profesyonel bir yaklaşım değil.
Programın hızla gelişmesine ve daha karmaşık hale gelmesine ihtiyacım vardı. Kendilerine atanan işlevleri uygulayan mekanizmalar oluşturmak. Çabuk ve kolay.
Böylece birkaç satır kodla yeni özellikler ekleyebilirsiniz.
Yaklaşımım, bu özel sorunu çözmede OOP'den daha üstün.