Canvas üzerinde bir kitle kaynaklı proje yapma - sayfa 24

 
Nikolai Semko :

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.

 
Реter Konow :

))), 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.

 
Artyom Trishkin :

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.

İlgilenen varsa, projemi MT4 için uygulamayacağım. sana söz veriyorum. Belki MT5 için de yapmayacağım. Bir tür çok düşmanca atmosfer gelişiyor ... Bunun için hiç çabalamadım. Belki de mizacım suçludur. Muhtemelen. Herkese iyi şanslar.
 
Реter Konow :
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.

İlgilenen varsa, projemi MT4 için uygulamayacağım. sana söz veriyorum. Belki MT5 için de yapmayacağım. Bir tür çok düşmanca atmosfer gelişiyor ... Bunun için hiç çabalamadım. Belki de mizacım suçludur. Muhtemelen. Herkese iyi şanslar.

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?

 
Artyom Trishkin :

...

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"... :-)

 
Реter Konow :

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!!! :))
 
Nikolai Semko :

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!!! :))
Evet, her şey yolunda :) Uzun zaman önce kendimi gagaladım, o yüzden bırakıyorum. ))

Evet Nikolai, boş zamanlarımda OOP öğreteceğim.

Bu başlığı kendim için kapattım. İyi şanlar.
 
Реter Konow :

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.

Алан Кэй, создатель ООП, про разработку, Лисп и ООП
Алан Кэй, создатель ООП, про разработку, Лисп и ООП
  • habrahabr.ru
Если вы никогда не слышали про Алана Кэя, то как минимум слышали его знаменитые цитаты. Например, это высказывание 1971 года: The best way to predict the future is to invent it. Лучший способ предсказать будущее это изобрести его. У Алана очень яркая карьера в информатике. Он получил Премию Киото и Премию Тьюринга за работу над парадигмой...
 
Vasiliy Sokolov :


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.

Fikirlerimi desteklemenizi beklemiyordum. )) Ancak elbette bunlar sadece benim fikirlerim değil. İyi iyi.)

Alan Kay çok ilginç bir insan. Onu daha önce duymadım bile.