Benim yaklaşımım. Çekirdek - Motor. - sayfa 4

 
OOP, tam tersine, çekirdeğin uygulanmasına müdahale etmez.
Genellikle kod ve veri vardır. Bizim durumumuzda çekirdek, verilerden güçlü bir şekilde ayrılmış koddur. Kodun kendisi de veri olarak kullanılabilir. Çekirdek genellikle belirli verilerle çalışmak için daha eksiksiz bir işlevselliğe veya en azından kendi kendine yeterli bir minimuma sahiptir.
Bu yaklaşım, en uygun veri formatını kullanmanıza izin verir, çok fazla veri olacağı varsayılır.
Bu yaklaşımı uygulayabileceğiniz başka bir örnek: danışmanda birçok strateji vardır, yalnızca stratejilerin mantığı veri görevi görür, çekirdek bunları yönetmek için işlevselliktir ve özellikle siparişleri , riskleri, ticaretle çalışmak ortam, göstergeler, hata işleme, istatistikleri tek tek veya toplu olarak görüntüleme, takip/ızgaralar/.....
 

Реter Konow :

Bir dizi oluşturuyorsunuz ve içine oluşturmak istediğiniz butonun özelliklerinin değerlerini yazıyorsunuz.

Düğme üç nesneden oluşur: Temel, Metin, Görüntü.

Her nesne, Düğme Öğesinin içinde bulunur, bu nedenle dizi iki boyutlu olmalıdır.

Ve neden bir dizi ile bu sapkınlıklar, bunun için bir yapı kullanabiliyorsanız (ve kullanmanız gerekiyorsa). Aynı şekilde başlatılır - virgülle ayrılmış değerlerle. Ve bu değerlere insan olarak erişilebilir - dizin aracılığıyla değil (birçok aptal hatayla dolu olan) alanın adıyla.

Sonuç olarak, iki boyutlu bir dizi yerine, bir dizi yapı olacaktır. Bildirinin özlülüğü aynıdır, ancak kolaylık ve güvenilirlik, bir büyüklük sırası daha yüksektir, artı belleğin rasyonel kullanımı, çünkü her alanın kendi türü vardır. OOP'nin bununla hiçbir ilgisi yok.

İşte bir örnek:

 struct TObject { char type;   string name;   int x;   int y;   int width;   int height;   color clr; };

TObject Objects[]= { { OBJ_BITMAP , "Bitmap" , 100 , 100 , 200 , 200 , clrRed },
                     { OBJ_BUTTON , "Button" , 150 , 150 , 50, 10 , clrWhite },
                   };
 
Alexey Navoykov :


Sonuç olarak, iki boyutlu bir dizi yerine, bir dizi yapı olacaktır . Bildirinin özlülüğü aynıdır, ancak kolaylık ve güvenilirlik, bir büyüklük sırası daha yüksektir, artı belleğin rasyonel kullanımı, çünkü her alanın kendi türü vardır. OOP'nin bununla hiçbir ilgisi yok.


burada olduğu gibi, iki şekilde .. hangisi daha iyi - bir dizi yapı mı yoksa bir dizi yapısı mı?

ama MQL, Fortran dizileriyle çalışmak üzere tasarlandı, bu bir gerçek..

 
Maxim Kuznetsov :

burada olduğu gibi, iki şekilde .. hangisi daha iyi - bir dizi yapı mı yoksa bir dizi yapısı mı?

Ne tür bir dizi yapısından bahsediyoruz? Yazarın sadece dizileri var

 

Sanırım Peter, Visual C ++'da bir DialogBox şablonunun nasıl oluşturulduğunu hiç görmedi, görsel modda Button, CheckBox, EditBox, ComboBox, vb. Gibi Kontroller oraya sürüklenecek.

Yani, alanları ve satırları ayarlama yeteneğine sahip DB satırlarını görüntülemek için çeşitli seçenekler dahil olmak üzere Windows'ta bulunan öğeler.

Ve MFC kullanımıyla, birkaç dakika içinde ve çok kısa bir sürede oldukça karmaşık iletişim kutuları oluşturabilirsiniz.

 
Alexey Navoykov :

Ve neden bir dizi ile bu sapkınlıklar, bunun için bir yapı kullanabiliyorsanız (ve kullanmanız gerekiyorsa). Aynı şekilde başlatılır - virgülle ayrılmış değerlerle. Ve bu değerlere insan olarak erişilebilir - dizin aracılığıyla değil (birçok aptal hatayla dolu olan) alanın adıyla.

Sonuç olarak, iki boyutlu bir dizi yerine, bir dizi yapı olacaktır. Bildirinin özlülüğü aynıdır, ancak kolaylık ve güvenilirlik, bir büyüklük sırası daha yüksektir, artı belleğin rasyonel kullanımı, çünkü her alanın kendi türü vardır. OOP'nin bununla hiçbir ilgisi yok.

İşte bir örnek:

Güzel çözüm. Ancak bu yapı Çekirdeğe entegre edilemez. Çekirdeği benim teknolojime göre oluştururken, eleman prototipleriyle dizide dolaşmanız ve bunları Çekirdeğe yeniden yazmanız gerekiyorsa, kararınız durumunda döngü imkansızdır.

Mümkün olsa da, ancak her bir unsuru ayrı bir yapıya sarmak... Peki bu nasıl küresel boyuta getirilebilir? Bütün bunları nereye ilan edeceğimiz... Belli değil.

Benim için her şey basit. Bir dizi eleman prototipi. İçindeki nesnelerin tüm özellikleri . Dizinin kendisi küreseldir. Erişim en basitidir ve programın herhangi bir yerinden.

 
Ve bağırsaklarınız çift kullanırken direnmiyor mu? Sonuçta o da kendine has yöntemleri olan bir bileşik nesnedir. Ortodoks çekirdek dizilerinde yeri yok! Bak, etkileyici (mantis, üs, işaret):
_NEW_OBJECT, тра-та-та-та-та-та, 3 , 10 , 1 , тра-та-та-та-та-та
 
pavlick_ :
Ve bağırsaklarınız çift kullanırken direnmiyor mu? Sonuçta o da kendine has yöntemleri olan bir bileşik nesnedir. Ortodoks çekirdek dizilerinde yeri yok! Bak, etkileyici (mantis, üs, işaret):

Hiçbir şey anlamadım.

 

Gereksiz söz diziminden ve bir tef ile dans etmekten kurtulduktan sonra, küresel prototip dizisindeki öğelerin özelliklerini başlatıyorum.

Çekirdekte eleman prototipleri yeniden yazıldığında yalnızca bir kez kullanılır.

Yeniden yazma basit bir döngüde yapılır.

Sonuç olarak, yapım aşamasında, Çekirdek, kullanıcı tarafından seçilen elemanların prototiplerini içermeye başlar.

Ayrıca, Çekirdekte yeni döngüler başlar. İçlerinde elementlerin özellikleri için özel değerler yazıyorum.

Sonunda, tüm unsurları ile hazır kullanıcı pencerelerini içeren bitmiş Çekirdeği alıyoruz.

 

Yukarıda açıklanan süreç, benim "Çekirdeği oluşturma süreci" dediğim şeydir.

Çekirdeği inşa ettikten sonra "motor" çalışmaya başlar.

Motor, elemanların mekaniğini kontrol eden koddur.

Motor yalnızca Core ile çalışmak üzere tasarlanmıştır. Motoru çeşitli olaylardır (çoğunlukla OnChartEvent() 'den gelir).