Canvas üzerinde bir kitle kaynaklı proje yapma - sayfa 24
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
Aynı deneyime ve zekaya sahip iki programcı rekabet ederse, benzer büyük projeler yaratır. Ancak ilki yalnızca işlevleri, ikincisi ise işlevleri ve sınıfları kullanır. Galibiyet kesinlikle ikinci olacak. Ancak tekrar ediyorum - bu hacimli bir projeyse, daha hızlı hale getirecek çünkü. daha az hata ve daha fazla düzen olacak. İkinci ürün ise daha okunabilir, bakımı kolay ve daha kolay güncellenip yenilenebilecek. Bu benim fikrim bile değil, sadece bir gerçeğin ifadesi. Kürekle çukur kazmak kürekle kazmaktan daha kolaydır. Mekanizmanızı sadece fonksiyonlara değil sınıflara da uygularsanız daha verimli olur. İşte benim IMHO'm.
Büyük mekanizmaların uygulanmasında sınıflara duyulan ihtiyaç sorusuyla başlayalım. Sınıf, bazı işlevler için bir sarmalayıcıdır ve "büyük mekanizma", bir dizi görevi uygulayan bir kod bloğudur. Uygulamamda, "Büyük mekanizma" neredeyse her zaman çok büyük bir işlev ve ona hizmet eden bir dizi küçük işlevdir. Sözde "motor". Servis fonksiyonları ile bir sınıfa koyarsanız hiçbir şey değişmez, ancak farklı sınıflarda ise aralarında erişim daha karmaşık hale gelir ve mekanizmanın verimliliği düşer.
Mekanizmanın boyutu büyüdüğünde, kodunu optimize etmek veya işlevselliği dosyalara ayırmak gerekir. Bu yeterli değil mi? Ayrıca, kodun bir blokta periyodik olarak optimize edilmesi, verimlilik mucizelerine yol açar. Sürekli küçülüyor ve artan sayıda uygulanan işlevi üstleniyor. Yani, aksine, fonksiyonların sayısı düşer. Kodu sürekli olarak geliştirilmekte olan bir blokta özetlenirler. Bu, verimliliğe giden doğrudan bir yoldur.
Ayrıca, önemli değişkenleri global yaparsanız, bunlar mekanizmanın içinde her yerde görünür olacaklardır ve onlarla çalışmak kolaydır ve onlar için kapsamlar tanımlarsanız, o zaman mekanizmanın verimliliği açısından bir ekstra görev. Yine, erişmek daha zor. Sınıf nesnelerinin yaratılması vb... Mekanizmayı çok sayıda işleve bölme eğilimi, yalnızca verimliliği değil, aynı zamanda kod bloklarının evrenselliğini de yok eder. Her belirli görev için ayrı bir işleve ihtiyaç duyulduğu ve kod bloklarının evrenselliğinin basitçe gelişmediği ortaya çıktı. Çağrıların ve geçirilen parametrelerin sayısı da artıyor. Bu, mekanizmanın verimliliğini artırmaz, ancak bu eğilim aslında FKÖ tarafından desteklenmektedir.
OOP, bir grup programcı bir proje üzerinde çalışırken daha verimlidir. O zaman onsuz hiçbir yerde. Gerçi, düşünürsen buralarda da dolaşmanın bir yolunu bulabilirsin...
Ama elbette, bunların hepsi kelimeler. Pratikte, neden bahsettiğimi çabucak ispatlardım.
Nikolai Semko :
Ve Peter, kodunuza kısaca baktım ve canvas'ı Might ve main ile kullandığınızı fark ettim (CCanvas sınıfı olmasa da, fark nedir). O zaman neden tuvalle ilgili tüm bu sorular ve neden burada çarmıha gerdim? :)).
))), tuval üzerine çizim ilkelerine ilişkin açıklamalarınıza da biraz şaşırdım çünkü size daha önce her şeyi çizdiğimi söyledim ve gösterdim.)) (Neredeyse her şeyi. :))
Konuyu açtım çünkü neden kimse benimkiyle aynı düğmeyi çizmemiş anlayamadım. Sonuçta, size göre, basit.
))), tuval üzerine çizim ilkelerine ilişkin açıklamalarınıza da biraz şaşırdım çünkü size daha önce her şeyi çizdiğimi söyledim ve gösterdim.)) (Neredeyse her şeyi. :))
Konuyu açtım çünkü neden kimse benimkiyle aynı düğmeyi çizmemiş anlayamadım. Sonuçta, size göre, basit.
Eğer görmediyseniz, bu, sizden başka kimsenin yapabileceği anlamına gelmez. Sadece o kadar önemsiz ki, kodunu göndermek için - çok önemsiz bir olay - sadece bir düğme oluşturarak - yayınlamanıza bile gerek yok, en iyisi olduğunuz için değil ;)
Hepiniz rekabet ediyorsunuz ve Anatoly haklı olarak - yel değirmenleriyle.
Eğer görmediyseniz, bu, sizden başka kimsenin yapabileceği anlamına gelmez. Sadece o kadar önemsiz ki, kodunu göndermek için - çok önemsiz bir olay - sadece bir düğme oluşturarak - yayınlamanıza bile gerek yok, en iyisi olduğunuz için değil ;)
Hepiniz yarışıyorsunuz ve Anatoly haklı olarak - yel değirmenleriyle.
Sakin ol Artem. Benden hoşlanmadığını zaten biliyorum. Görünüşe göre ve bu kaynaktaki diğerleri. Belki bu haklı olabilir, ancak açıkçası ve "sebepsiz" teknik sorunlar tartışılırken kişiselleşmek çok fazla.
Sakinim, neden tam tersini aldınız?
Bir kişiyi beğen / sevme - bu teknik bir forumda tartışılmaz. Benim için tarafsızsın - artık yok. Geri kalanı için olduğu gibi, bana öyle geliyor.
Ama "ah-ah-ah-ah ..., bu Don Kişot ... Hatırlıyorum, hatırlıyorum ..." üslubunda anılmamak için en azından faydalı bir şeyler yapmanız gerekiyor.
Yapabilirsiniz, aklınızdaki şeyi yapamazsınız - hakkınız ve kimse buna itiraz etmez. Burada kimsenin sözüne ihtiyacı yok - her şeyden önce kendine vermelisin ;)
Atmosfer çok arkadaş canlısı - insanlar size bazı durumlarda OOP kullanmanın güzelliğinin ne olduğunu söylüyorlar, bir kişi sizin önünüzde çarmıha geriyor, bir konuda yardım etmeye çalışıyor, size göstermeniz için kodlar ve daha erişilebilir hale getiriyor. Ama - kendi sözlerinle - buna ihtiyacın olmadığı ortaya çıktı - sadece başka kiminle rekabet edeceğini bilmiyorsun ve insanlara “zayıf” meydan okumaya çalışıyorsun.
Ve bir şey daha, bana OOP yazmamaya ve çalışmamaya karar vermemişsiniz gibi geldi çünkü her şeyi tarttınız ve prosedürel programlama kullanarak çok daha iyi ve optimize edilmiş kod yazdığınızı fark ettiniz (burada herkese sunduğunuz gibi) ), ama sadece orada hiçbir şey anlamadıkları için ve kendilerine bir mazeret buldular, bunu herkese dile getirdiler, kelimelerle desteklediler ve “Yalnızca beni yenene inanacağım” bir meydan okuma.
Elusive Joe şakasını hatırlıyor musun?
...
Elusive Joe şakasını hatırlıyor musun?
Kesinlikle katılıyorum.
Zor söz yazarı/filozof... :-) "Joe" ile aynı saçmalık, sadece "diğer taraftan"... :-)
Büyük mekanizmaların uygulanmasında sınıflara duyulan ihtiyaç sorusuyla başlayalım. Sınıf, bazı işlevler için bir sarmalayıcıdır ve "büyük mekanizma", bir dizi görevi uygulayan bir kod bloğudur. Uygulamamda, "Büyük mekanizma" neredeyse her zaman çok büyük bir işlev ve ona hizmet eden bir dizi küçük işlevdir. Sözde "motor". Servis fonksiyonları ile bir sınıfa koyarsanız hiçbir şey değişmez, ancak farklı sınıflarda ise aralarında erişim daha karmaşık hale gelir ve mekanizmanın verimliliği düşer.
Mekanizmanın boyutu büyüdüğünde, kodunu optimize etmek veya işlevselliği dosyalara ayırmak gerekir. Bu yeterli değil mi? Ayrıca, kodun bir blokta periyodik olarak optimize edilmesi, verimlilik mucizelerine yol açar. Sürekli küçülüyor ve artan sayıda uygulanan işlevi üstleniyor. Yani, aksine, fonksiyonların sayısı düşer. Kodu sürekli olarak geliştirilmekte olan bir blokta özetlenirler. Bu, verimliliğe giden doğrudan bir yoldur.
Ayrıca, önemli değişkenleri global yaparsanız, bunlar mekanizmanın içinde her yerde görünür olacaklardır ve onlarla çalışmak kolaydır ve onlar için kapsamlar tanımlarsanız, o zaman mekanizmanın verimliliği açısından bir ekstra görev. Yine, erişmek daha zor. Sınıf nesnelerinin yaratılması vb... Mekanizmayı çok sayıda işleve bölme eğilimi, yalnızca verimliliği değil, aynı zamanda kod bloklarının evrenselliğini de yok eder. Her belirli görev için ayrı bir işleve ihtiyaç duyulduğu ve kod bloklarının evrenselliğinin basitçe gelişmediği ortaya çıktı. Çağrıların ve geçirilen parametrelerin sayısı da artıyor. Bu, mekanizmanın verimliliğini artırmaz, ancak bu eğilim aslında FKÖ tarafından desteklenmektedir.
OOP, bir grup programcı bir proje üzerinde çalışırken daha verimlidir. O zaman onsuz hiçbir yerde. Gerçi, düşünürsen buralarda da dolaşmanın bir yolunu bulabilirsin...
Ama elbette, bunların hepsi kelimeler. Pratikte, neden bahsettiğimi çabucak ispatlardım.
Peter, eskiden sadece fonksiyonlarla programlama yapardım ve hemen hemen şimdi yaptığınız gibi mantık yürütürdüm ve sonra neredeyse zorla (çünkü alışkanlığın gücü inanılmazdır) sınıfları kullanarak programlamaya başladım. Şimdi bu iki durumu karşılaştırabilirim ve siz sınıfları kullanmayı deneyene kadar hayır. Suç yok. Sadece bana farklı bir durumu hatırlatıyor. Uzun yıllardır vejeteryanım. Ve kıskanılacak bir düzenlilikle, asla vejeteryan olmayan ve bana proteinler, temel amino asitler vb. hakkında bir şeyler anlatmaya çalışan insanlar var. Onlara şunu söylüyorum: Eşit şartlarda değiliz, ben bir et yiyiciydim ve şimdi bir vejeteryandım, bu yüzden bu iki durumu uygulama açısından karşılaştırabilirim. Ama değilsiniz ve bilginiz sadece teorik ve pratikle ilgisi yok.
Zaman kaybetmeyin - OOP öğrenin.
Bu forumda seni tamamen gagalamışlar dostum. :)) Ben dahil. :( Umutsuzluğa kapılmayın - bizi öldürmeyen şey güçlendirir. Sana inanıyorum!!! :))
Zaman kaybetmeyin - OOP öğrenin.
Bu forumda seni tamamen gagalamışlar dostum. :)) Ben dahil. :( Umutsuzluğa kapılmayın bizi öldürmeyen şey güçlendirir. Sana inanıyorum!!! :))
Büyük mekanizmaların uygulanmasında sınıflara duyulan ihtiyaç sorusuyla başlayalım. Sınıf, bazı işlevler için bir sarmalayıcıdır ve "büyük mekanizma", bir dizi görevi uygulayan bir kod bloğudur. Uygulamamda, "Büyük mekanizma" neredeyse her zaman çok büyük bir işlev ve ona hizmet eden bir dizi küçük işlevdir. Sözde "motor". Servis fonksiyonları ile bir sınıfa koyarsanız hiçbir şey değişmez, ancak farklı sınıflarda ise aralarında erişim daha karmaşık hale gelir ve mekanizmanın verimliliği düşer.
Mekanizmanın boyutu büyüdüğünde, kodunu optimize etmek veya işlevselliği dosyalara ayırmak gerekir. Bu yeterli değil mi? Ayrıca, kodun bir blokta periyodik olarak optimize edilmesi, verimlilik mucizelerine yol açar. Sürekli küçülüyor ve artan sayıda uygulanan işlevi üstleniyor. Yani, aksine, fonksiyonların sayısı düşer. Kodu sürekli olarak geliştirilmekte olan bir blokta özetlenirler. Bu, verimliliğe giden doğrudan bir yoldur.
Ayrıca, önemli değişkenleri global yaparsanız, bunlar mekanizmanın içinde her yerde görünür olacaklardır ve onlarla çalışmak kolaydır ve onlar için kapsamlar tanımlarsanız, o zaman mekanizmanın verimliliği açısından bir ekstra görev. Yine, erişmek daha zor. Sınıf nesnelerinin yaratılması vb... Mekanizmayı çok sayıda işleve bölme eğilimi, yalnızca verimliliği değil, aynı zamanda kod bloklarının evrenselliğini de yok eder. Her belirli görev için ayrı bir işleve ihtiyaç duyulduğu ve kod bloklarının evrenselliğinin basitçe gelişmediği ortaya çıktı. Çağrıların ve geçirilen parametrelerin sayısı da artıyor. Bu, mekanizmanın verimliliğini artırmaz, ancak bu eğilim aslında FKÖ tarafından desteklenmektedir.
OOP, bir grup programcı bir proje üzerinde çalışırken daha verimlidir. O zaman onsuz hiçbir yerde. Gerçi, düşünürsen buralarda da dolaşmanın bir yolunu bulabilirsin...
Ama elbette, bunların hepsi kelimeler. Pratikte, neden bahsettiğimi çabucak ispatlardım.
Ve içinde bir şey var. OOP'nin yaratıcısı Alan Kay, aslında bugün OOP ile kastedilenden çok farklı bir anlama sahipti. Bu sizin vizyonunuza daha da benzer. Buradaki fikir, bir veya başka işlevsellik için ona erişen bir çekirdek ve hizmetlerin olacağı bir proje oluşturmaktır. Bu durumda, öğeler arasındaki iletişim yalnızca mesaj olayları aracılığıyla gerçekleşecektir. Verilerle birlikte gönderilen olay isteği - sonuçla birlikte alınan olay yanıtı. Bu durumda kalıtım, polimorfizm ve içerme yoktur.
Bu arada, bu yaklaşımla, çoklu iş parçacığının düzenlenmesi daha kolaydır, çünkü. tanım gereği tüm öğeler birbirinden bağımsız olarak çalışır.
Ve içinde bir şey var. OOP'nin yaratıcısı Alan Kay, aslında bugün OOP ile kastedilenden çok farklı bir anlama sahipti. Bu sizin vizyonunuza daha da benzer. Buradaki fikir, bir veya başka işlevsellik için ona erişen bir çekirdek ve hizmetlerin olacağı bir proje oluşturmaktır. Bu durumda, öğeler arasındaki iletişim yalnızca mesaj olayları aracılığıyla gerçekleşecektir. Verilerle birlikte gönderilen olay isteği - sonuçla birlikte alınan olay yanıtı. Aynı zamanda kalıtım, polimorfizm ve içerme yoktur.
Bu arada, bu yaklaşımla, çoklu iş parçacığının düzenlenmesi daha kolaydır, çünkü. tanım gereği tüm öğeler birbirinden bağımsız olarak çalışır.