OOP vs prosedürel programlama - sayfa 39

Yeni yorum
 
Andrei :

Bir sınıfın sadece iç değişkenleri vardır ve hiçbir girdisi veya çıktısı yoktur... Dış dünyayla teması olmayan ve kendi suyunda kaynayan böyle bir nesnenin programlanmasındaki kullanımını nerede gördünüz?


Neden görmediğin şeylerden bahsediyorsun? Bir sınıf yapıcısı oluşturulur ve herhangi bir sayıda parametre alabilir. Farklı alt sınıflar, yapıcılarında tamamen farklı parametre kümelerine sahip olabilir. Evet, parametreleri ayarlamak için basitçe yöntemler yazabilirsiniz.

 
СанСаныч Фоменко :

1. Bu, OOP ihtiyacına verilen ana cevaptır.

2. Bu bir ekip deneyimi meselesidir. 2008-2009'da ihtiyacınız olan her şeyi yazdım. Birkaç yıl önce daha fazla yazmaya karar verdim - her şey okunabilir, sorun yok.


Cevaplarınızdan bir şeyi anladım: OOP, bir programlama disiplini tanıtan, tekdüzelik getiren bir tür standarttır ve bu temelde başlangıçta daha az hata vardır ve en önemlisi ve en önemlisi, değişiklik sırasındaki sorunlar temelde azalır. Ancak aynı sonuç, GOST'lerin, geliştirme aşamalarının, belgelerin dikkatle gözlenmesiyle elde edildi.


Aynı şeyi ne kadar tekrar edebilirsin? OOP sadece bir kod yapılandırma aracı değildir, aynı zamanda prosedürel programlamanızda olmayan mekanizmalara da sahiptir.

Muhtemelen durum bunlardır, insan dağları görmediyse ne olduğunu anlamaz, en azından söyle.

 
Реter Konow :

Kişisel olarak çözümlerde evrensellik için çabalıyorum. Bu , kod miktarını artırmadan benzer işlevleri bir bloğa "birleştirmeyi" gerektirir. Mekanizmanın verimini arttırır ve aşırı yük ve ayırma gerektirmez. Sadece beynini kullan ve hepsi bu.)

Yani, her biri 20 satırlık iki fonksiyon vardı. Her ikisi de benzer eylemler gerçekleştirir veya aynı tür görevleri çözer. Amacım, onları her iki işlevin de işini yapan 20 satırdan fazla olmayan tek bir işlev haline getirmek. Blokları bu şekilde alıyorum.


Ne zamandır bu kitaplığınıza göz atıyorsunuz?

 

Holivar adına - R, "erişim kontrolü olmayan hepsi bir arada çöp kutusu" modunda kesinlikle iğrenç bir şekilde yazılmıştır. Kapsam, koruma ve çoklu oturum olmadan yirmi yıl öncesinden eski tarz yaklaşım. Sanki yalnızmışım gibi yazıyorum. Evet , proje profesyonel olmayan geliştiriciler tarafından bir kişinin altında doğdu. Sıfırdan yeniden yazılması gerekiyor. En azından bir kere.

MQL5'ten R'de normal bir arayüz yapma fikri vardı, ancak daha derine indikten sonra entegrasyonu hemen reddettim. Sistem kategorik olarak verileri ve oturumları koruma konusunda yetersizdir.

Bir programcı, katı gereksinimleri olan (en azından birkaç yıl el ele vererek) normal geliştirme ekiplerinde çalışana kadar, normal anlamda bir geliştirici olmayacaktır. Adayları değerlendirirken test maddelerine baktığımızda zamanın %90'ını kafamıza takıyoruz. Geliştirme endüstrisi boyunca toplam korku.

Bu nedenle, bir kez daha tekrar ediyorum - FKÖ karşıtları burada bir tür saçmalık sergiliyor.

Tekrar özür dilerim.

 
СанСаныч Фоменко :

sersemlemiş!

Merak ediyordum: Modern programlamada yenen yumurta seviyesi sorununu daha ani bir şekilde karıştırmak için başka bir olasılık var mı?

Trafik sıkışıklığındaki arabaya gelen sizsiniz, nasıl çalıştığına bakın - ve sürücüye söyleyin, "sorunu daha ani bir şekilde karıştırmanın, sonra yüz metre yürümenin bir yolu var mı?" diyorlar.

Deneyimlerimin gösterdiği gibi, bu tür "karmaşık sorunları" çözmek, tüm global değişkenlerle tek bir şablondan kopyala-yapıştır kullanılarak yapılan "sorunsuz" Uzman Danışmanlardan çok daha kolaydır.

 
Dmitry Fedoseev :

Neden görmediğin şeylerden bahsediyorsun? Bir sınıf yapıcısı oluşturulur ve herhangi bir sayıda parametre alabilir.

Daha dikkatli okuyun, bu, sınıf kurucusuyla değil, sınıfla ilgiliydi.

Ek olarak, yine maymun işi yapmayı öneriyorsunuz - bir bahçedeki bir bahçeyi çitle çevirmek, dış değişkenler durumunda HİÇBİR ŞEY yapmadan veya yapıcılar-yıkıcılar ve her türlü gereksiz baş ağrısı olmadan doğrudan iletmeden parametrelere erişebiliyorsanız. ilgili bellek sızıntıları.

 
СанСаныч Фоменко :

OnInit()'im hemen hemen aynı görünüyor - bir düzine satır...

Ne olmuş?

Buna gelirsek, o zaman TÜM danışmanda bir düzine satırım var (eklemeler ve yorumlar hariç).

 #include <MyLib\DebugOrRelease\DebugSupport.mqh>
#include <MyLib\Factories\ForTrade\EURGBP\B1H2C20T2_0001_EPF.mq5>
#include <MyLib\Factories\ForTrade\EURGBP\B2H2C20T4_0001_EPF.mq5>
#include <MyLib\Factories\ForTrade\EURGBP\B3H2C20T2_0001_EPF.mq5>

// Объявляем фабрики частей эксперта.
CB1H2C20T2_0001_EPF epfFact_0;
CB2H2C20T4_0001_EPF epfFact_1;
CB3H2C20T2_0001_EPF epfFact_2;

// Объявляем функцию получения указателя на фабрику.
CEAPartsFactoryT* CEAPartsFactoryT::GetAdvisorsPartsFactory( uint uiFactIdx = 0 )
{
   if (uiFactIdx == 0 ) return ( GetPointer (epfFact_0)); 
   if (uiFactIdx == 1 ) return ( GetPointer (epfFact_1)); 
   if (uiFactIdx == 2 ) return ( GetPointer (epfFact_2)); 
   return ( NULL ); 
};

#include <MyLib\TSTemplate\ExpertAdvisorT.mq5>

Burada bir Uzman Danışmanda aynı anda ÜÇ tamamen farklı TS vardır. Birbirlerine müdahale etmeden aynı anda çalışırlar.

Uygun fabrikayı bildirerek ve onu işleve döndüren kodu yazarak ek TS'ler ekleyebilirsiniz.

Ancak asıl soru, kodda az veya çok satır olup olmadığı değildir. Soru, gerekirse bakımının ve değiştirilmesinin ne kadar kolay olduğudur.

SanSanych, Peter tarafından sağlanan tablo dosyasını kolayca anlayabiliyor musun? Ve kolayca değiştirebilir misin? Öyleyse, Peter gibi senin de OOP'ye ihtiyacın yok.

 
Реter Konow :
OOP, bir mekanizmanın parçalarını ayırma, sarma ve gizleme yöntemidir. Gerekli olup olmadığına geliştirici karar verir. Mekanizmanın verimliliğini artırmakla hiçbir ilgisi yoktur. Düşünmeyi yapılandırmak, evet. Doğru yapılandırılıp yapılandırılmadığı bilinmiyor. Bunun gerekli olup olmadığı kişiye bağlıdır. BENİM NACİZANE FİKRİME GÖRE.

Aynen öyle. Kapsüllemenin özü budur.

Kalıtım ve polimorfizm de var.

 
Реter Konow :
OOP, bir mekanizmanın parçalarını ayırma, sarma ve gizleme yöntemidir. Bunun gerekli olup olmadığı kişiye bağlıdır. BENİM NACİZANE FİKRİME GÖRE.

İşte bu, belirli bir kişiden. Neden şizofreniden muzdarip olmayan bir programcı, hatalarını ayıkladığı kendi kodunun bir kısmına erişimini kendisinden saklamak için çok uğraşsın? Belki ellerini bağlamak daha iyidir? :)

 
Renat Fatkhullin :

Bir programcı, katı gereksinimleri olan (en azından birkaç yıl el ele vererek) normal geliştirme ekiplerinde çalışana kadar, normal anlamda bir geliştirici olmayacaktır. Adayları değerlendirirken test maddelerine baktığımızda zamanın %90'ını kafamıza takıyoruz. Geliştirme endüstrisi boyunca toplam korku.

Ve burada bu "korku" nun gösterilmesi ilginçtir.

Bunun OOP kullanımından kaynaklandığını varsayabilirim, çünkü prosedürel programlamada odak, herhangi bir yoğunluktaki bir ormanı yığması çok kolay olan herhangi bir harici OOP eklentisinde değil, algoritmanın mantığındadır.

1...323334353637383940414243444546...48
Yeni yorum
Neden: