Rusça kod yazma. Böyle bir programın artıları ve eksileri. - sayfa 3
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
1. Kaç yıldır programlama yapıyorsunuz?
2. En az bir kez (kendiniz için) Rusça bir program yazmayı denediniz mi?
Soru şu ki, bir klişe var mı ve biz onun rehineleri değil miyiz?
İlişki sorusu. İngilizce yazmayı tercih ederim çünkü Her şekilde daha rahat buluyorum. Destek, özlülük, yanlış anlamaları araştırmak, topluluk.
Hatta İngilizce yazma konusundaki isteksizliğinizin, İngilizceyi düzgün bir şekilde öğrenme konusundaki isteksizliğinizden beslenen bir klişe olduğunu söyleyebilirim.
Dış değişkenler Rusça ise, işaretlerle karşılaşabilirsiniz ?????? sistemde, örneğin sunucuda yazı tipi yoksa.
1C - evet, orada bir şekilde Rusça daha tanıdık. Ancak diğer dillerde, sadece İngilizce (bir şekilde 90'ların sonunda "Rus dili" Visual Basic'i denedim, o zamandan beri yemin ettim).
OOP ile Rusça yazabilirsiniz.
OOP terk edildiğinde kesmenin özü nedir?
OOP'nin özü, programcıya değişkenlerin kapsamını kendisinin belirleme fırsatı verilmesidir. Bu fırsatı görmezden gelerek ne kazanırsınız?
Kapsamı artık kontrol etmediğiniz için sürekli olarak yeni sayaçlar ve yeni değişkenler kullanmanız gerekir.
İsimler son ek ve öneklerle daha uzun yazılmalıdır.
Kodu yeniden kullanma yeteneğinizi kaybedersiniz (OOP'nin temel taşlarından biri).
Tabii ki hepsi bu değil, ama kısaca.
Hangi yaklaşımı tercih edersiniz?
Not Bu arada, bir program geliştiriyorsanız ve metni doldurmuyorsanız, dönüşüm olasılığı önemlidir. OOP ile bir İncil'i yeniden yazmak yeterlidir. Diğer yaklaşımlarla, tüm programı düzenlemeniz gerekir.
Ayrıca OOP'de Rusça yazabilirsiniz. Kabul ediyorum. Ancak, OOP hakkında kendi şikayetlerim var. Uygulamamda bu yöntemin beyan edilen etkinliği tamamen reddedildi ve ben bu yaklaşımı etkisiz olarak reddettim. Aslında, OOP programlama dilini "insanlaştırmanıza" izin verir, ancak onu makinenin hiç ihtiyaç duymadığı gereksiz varlıklarla doldurur. Daha da fazlası ortaya çıkıyor - bu varlıklar bir kişi için çok gerekli değil ve onlarsız yapabilirsiniz. Değişken kapsamdan mı bahsediyorsunuz? Değişkenlerinizi global bir 3B dizide düzenleyin. Bu dizinin her alanını bir sınıf olarak adlandırın ve alanın her satırına bir numaralandırma diyelim. Her bir değişkenin değerini yerelleştirmek, ona erişmek kadar kolay olacaktır...
Dönüşümü düşünmemiz lazım... Mantıksal çekirdekle çalışacak evrensel bir yazılım motoru yapma fikri var. Mantıksal zincirler çekirdeğe yazılacaktır. Çekirdek aracılığıyla motor, işlevlere dizinlerine göre erişecektir. Onu dönüştürmek çok kolay olacak.
Gelişmiş C++'a bakın. Sanki bu programlama dili kendi argosunu çoktan edinmiş gibi... Muhtemelen başka hiçbir dilde böyle bir varlık yığını yoktur. Bir çalışma yürütür ve içinde yalnızca gerekli olanı bırakırsanız, birkaç kez küçülür. Bu nedenle, çoğunluk için daha anlaşılır ve erişilebilir hale gelecektir. Ancak, birisinin bu dilin herkes için anlaşılır ve erişilebilir olmasını istemediğini ve bu nedenle onu son derece karmaşıklaştırdığını hissediyorum ...
C++'da katmanlı birçok özellik vardır. Ana sistem dili olarak kalır ve herhangi bir şey yazabilmek için içine çeşitli özellikler kaydedilir.
ACMe'den OpenCL'ye ve iş parçacığı kontrolüne.
C # saf OOP Hoş Geldiniz istiyorum
Konu başlatıcı, daha önce kabul edilen prosedürel programlama yönteminin aksine, OOP'nin avantajlarını henüz tam olarak anlamamıştır. Daha önce, prosedürel yöntemden önce, programlar koşulsuz atlama operatörleri kullanılarak yazılmıştır. Ve bu şekilde yazılan programların hata ayıklaması ve çalışmalarının mantığını takip etmesi çok zordu, hatta onlara "spagetti yemeği" deniyordu.
Benim yaklaşımım şudur:
1. Program fonksiyonlarının çağrılarını indeksliyoruz. İşlevleri, olayları kontrol edenlere (mantıksal işlevler - evet / hayır döndür), prosedürel işlevlere (yürütücü) ve hesaplananlara böleriz.
2. Küresel bir üç boyutlu dizi şeklinde mantıksal bir çekirdek yaratıyoruz. İçinde belirli bir hiyerarşide mantıksal işlevlerin dizinlerini belirleriz (kontrol ettikleri olayların önemine göre ayırma: küresel ve yerel olaylar). Çekirdek alanındaki bu olaylardan adeta çevreler yaratırız.
3. Mantıksal zincirlerin uçlarına prosedürel ve hesaplamalı fonksiyonların indekslerini koyarız.
4. Çekirdekteki olayların çevresi etrafında zamanlayıcı frekansında dönen ve gerekli fonksiyonları indeksleri aracılığıyla çağıran bir mantık motoru oluşturuyoruz.
5. Programın yeniden yapılandırılması, yalnızca belirli mantıksal zincirlerin yeniden yapılandırılmasından veya yenilerinin oluşturulmasından oluşacaktır.
11 uni dahil değil.
Kesinlikle.
İlişki sorusu. İngilizce yazmayı tercih ederim çünkü Her şekilde daha rahat buluyorum. Destek, özlülük, yanlış anlamaları araştırmak, topluluk.
Hatta İngilizce yazma konusundaki isteksizliğinizin, İngilizceyi düzgün bir şekilde öğrenme konusundaki isteksizliğinizden beslenen bir klişe olduğunu söyleyebilirim.
İngilizce Dostoyevski okudum. Asıl mesele bu değil ... Rusça benim için genetik düzeyde programlamada daha uygun.
Sorun değil, 47. kromozom bir kuvvettir.
OOP, en zeki insanlar, profesörler tarafından oluşturuldu. Yıllar boyunca, program yazmanın en uygun olması için programcıların ihtiyaçlarına göre honlandılar, değiştirildiler.
MQ'dan OOP, kodu kullanmanın güvenliği ile ilgili olarak da sonuçlandırılmıştır.
Yeni bir dinin peygamberi mi olmak istiyorsunuz? sorun değil sonuçta sıra sende