MQL5'te OOP hakkında sorular - sayfa 50

 
Aleksey Mavrin :

Dmitry, muhtemelen bu durumda Koruyucu ve Prototip kalıplarının görevlerini ve bunların tüm olası kombinasyonlarını ve tezahürlerini biraz karıştırıyorsunuz. İlk olarak, bir Anlık Görüntü, bir Prototipten farklı olarak tüm nesneyi kopyalamak zorunda değildir.

Ve evet, kapsülleme ihtiyacı kendini esas olarak bir grup insanla büyük projelerde gösterir. Yerel problemlerin çoğu gibi bu tür oyuncaklar için, elbette bir abartı)

Oturup tüm ciddiyetiyle akıllı bir bakışla, bir değişkene bir değer atanabileceğini ve sonra kullanılabileceğini tartışmaya geldi. Ah evet - herhangi bir şey üzerinde herhangi bir şey programlarken, birçok kez farklı değişkenlere farklı değerler atanır ve ardından bunlar kullanılır. Ama şimdi farklı deniyor ve şimdi tartışırken kaşlarınızı çatmanız ve ciddi bir bakış atmanız gerekiyor.

Ve tüm alanlar kaydedilirse, hata yapmamak önemlidir, o zaman bu Prototiptir ve hepsi değilse, Koruyucu, aksi takdirde çocuklar güler.

 
Sergey Dzyublik :

"Intyrnet koymuşlar, intyrnet, bizim buna ihtiyacımız yok, sizin internetiniz..." tarikatından olma ihtimaliniz var mı ???


1. Kaleci, bir değil, bu değişikliklerden birkaç yüz varken değişiklikleri geri almak için değiştirilebilir içerikle yazarken durumu saklamak için kullanılan desene benzer tasarım. Örneğin fotoğraf düzenleyici, metin düzenleyici...
Yazdıktan sonra bulundu - https://refactoring.guru/en/design-patterns/memento
2. Aslında orada bir şeyi eleştirmek konuyu bilmemek ve anlamamak kötü bir uygulamadır...
3. Sizin için zaten anlaşılmaz olan bir şey nasıl daha kafa karıştırıcı ve anlaşılması zor hale gelebilir?
4. Kendiniz...


Peki ya OOP?

 
Sergey Dzyublik :

"Intyrnet koymuşlar, intyrnet, bizim buna ihtiyacımız yok, sizin internetiniz..." tarikatından olma ihtimaliniz var mı ???


1. Kaleci, bir değil, bu değişikliklerden birkaç yüz varken değişiklikleri geri almak için değiştirilebilir içerikle yazarken durumu saklamak için kullanılan desene benzer tasarım. Örneğin fotoğraf düzenleyici, metin düzenleyici...
Yazdıktan sonra bulundu - https://refactoring.guru/en/design-patterns/memento
2. Aslında orada bir şeyi eleştirmek konuyu bilmemek ve anlamamak kötü bir uygulamadır...
3. Sizin için zaten anlaşılmaz olan bir şey nasıl daha kafa karıştırıcı ve anlaşılması zor hale gelebilir?
4. Kendiniz...


Tamamen destekliyorum! Şakamı tartıştığınız için teşekkür ederim .. Çok tembeldim))

1. paragrafta, yalnızca bir anlık görüntünün bir nesnenin tüm verilerini saklaması gerekmediğini ve aynı nesnenin yüzlerce anlık görüntüsünün "farklı taraflarından anlık görüntüsünün" bulunduğu birkaç dal olabileceğini eklerdim. Bu durumda, kullanılmayan verilerin yüzlerce kopyasını saklamak gerçekten en kötü uygulamadır.

 
Dmitry Fedoseev :

Oturup tüm ciddiyetiyle akıllı bir bakışla, bir değişkene bir değer atanabileceğini ve sonra kullanılabileceğini tartışmaya geldi. Ah evet - herhangi bir şey üzerinde herhangi bir şey programlarken, birçok kez farklı değişkenlere farklı değerler atanır ve ardından bunlar kullanılır. Ama şimdi farklı deniyor ve şimdi tartışırken kaşlarınızı çatmanız ve ciddi bir bakış atmanız gerekiyor.

Ve tüm alanlar kaydedilirse, hata yapmamak önemlidir, o zaman bu Prototiptir ve hepsi değilse, Koruyucu, aksi takdirde çocuklar güler.

Dmitry, seni temin ederim, sana memnuniyetle gülerdim, bu işi seviyorum) ama bu durumda abarttın, hatta özellikle iyi gülümsedin.

Gerçekten kafa karıştırdın - SHOT, COPY OBJECT'e eşit değil, demiştim sana.

Fark net değilse, bunu sizin için özel olarak bir örnekle açıklayacağım - bir nesne 1000 bayttır, bir anlık görüntü için 200'e ihtiyacınız vardır, neden 800 kopyalamalısınız, özellikle çok, çok sayıda anlık görüntü saklamanız gerekiyorsa.

p / s / Evet ve genel olarak. İnsanlar, kalıpların basit bir TİPİK görevi çözmenin basit bir örneği olduğunu gerçekten anlamıyor mu? Ama aslında, görevler temel değil, daha karmaşık. Ve gerçek problemleri çözmek için, kalıplara ihtiyaç vardır, sadece çoğu zaman saf bir kitap biçiminde değil, belirli bir görev için uyarlanmış bir modelde, muhtemelen birbirleriyle birleştirilmiş, muhtemelen bir tür doğaçlamanın eklenmesiyle, bazen basitleştirmede ifade edilir, görev izin veriyorsa veya tam tersi "ağırlıklandırma" uygulaması.

Yine, neden kapsülleme ve arayüzlere ihtiyaç duyulduğunu - aikyu'nuzun Wasserman'dan daha düşük olup olmadığını veya gerçek projelere katılmadıysanız, projenin farklı bölümleri aynı anda farklı kişiler tarafından değiştirildiğinde anlamak muhtemelen imkansızdır ve OO Design'ın temel ilkelerine uyulmaması, hataları yakalamak için büyük maliyetler gerektirir. Gerçekten de, tüm bunlar neden pazar için danışmanları damgalamak için?))

 
Verilen:
1. Sonlu durum makinesi (KA)
2. Uzay aracının sayısı bilinmiyor
3. SC durumları: başarılı / başarısız / çalışıyor
4. CA'lar birkaç iş parçacığında (iş parçacığı) yürütülür, iş parçacığı sayısı bilinmiyor

Desen izin vermelidir:
1. Her KA için benzersiz bir kimlik verin - sayaç dönmez
2. Konular arasında CA'yı eşit olarak ekleyin
3. KA'nın durumunu alın
4. Uzay aracının durumu, daha önce verilen görevle tam olarak başarısız olursa, uzay aracını yeniden başlatın.
5. CA'yı veritabanına kaydedin ve durum başarılıysa onu akıştan kaldırın
6. Uzay aracının durumunu geri yükleyin (kaydedin kimliği) ve akışa ekleyin
7. CA mesajlarını değiş tokuş etmek için ortak bir havuza sahip olun, havuz kauçuk değil, uzak CA'lar mesaj almıyor, ancak yeni oluşturulan CA'lar yeni mesajları almalı ve öldürülen CA'lardan kalanları değil, iş parçacıkları ve CA'lar arasında senkronizasyon yok
8. Tüm kalıbın ve mesaj havuzunun durumunu kaydedin ve geri yükleyin

* KA aynı tür görevleri yerine getirmez
** Asıl sorun mesaj havuzudur, ancak CA veya DB veya ?
*** Belki de tüm bunlar veritabanı ile çalışıyor ve burada kalıplara hiç ihtiyaç yok mu?
 
?
 
Igor Makanu :
Verilen:
1. Sonlu durum makinesi (KA)
2. Uzay aracının sayısı bilinmiyor
3. SC durumları: başarılı / başarısız / çalışıyor
4. CA'lar birkaç iş parçacığında (iş parçacığı) yürütülür, iş parçacığı sayısı bilinmiyor

Desen izin vermelidir:
1. Her KA için benzersiz bir kimlik verin - sayaç dönmez
2. Konular arasında CA'yı eşit olarak ekleyin
3. KA'nın durumunu alın
4. Uzay aracının durumu, daha önce verilen görevle tam olarak başarısız olursa, uzay aracını yeniden başlatın.
5. CA'yı veritabanına kaydedin ve durum başarılıysa onu akıştan kaldırın
6. Uzay aracının durumunu geri yükleyin (kaydedin kimliği) ve akışa ekleyin
7. CA mesajlarını değiş tokuş etmek için ortak bir havuza sahip olun, havuz kauçuk değil, uzak CA'lar mesaj almıyor, ancak yeni oluşturulan CA'lar yeni mesajları almalı ve öldürülen CA'lardan kalanları değil, iş parçacıkları ve CA'lar arasında senkronizasyon yok
8. Tüm kalıbın ve mesaj havuzunun durumunu kaydedin ve geri yükleyin

* KA aynı tür görevleri yerine getirmez
** Asıl sorun mesaj havuzudur, ancak CA veya DB veya ?
*** Belki de tüm bunlar veritabanı ile çalışıyor ve burada kalıplara hiç ihtiyaç yok mu?
1. Karmaşık bir göreviniz var, bu nedenle kelime kalıbı, sorunuzda kulağa hoş geliyorsa, yalnızca çoğuldur :)
2. Ayrıca KA'yı akışlar boyunca eşit olarak eklemeniz gerekir. Bir singleton-idemaker ve bir thread manager ile uygulanan bir fabrikanın nesi yanlış? Neden basit bir sayaç anlaşılmaz bir şekilde uymuyor? Chtoli uzay aracının yaratılmasını yönetmenin bir yolu yok mu? Yani başka birinin projesi için mi yoksa kendi projeniz için mi eklenti yapıyorsunuz?
7. Uzay aracının oluşturulduğu zamana göre filtreleme yapan gözlemci. MT için tüm uygulamalar.
Veritabanındaki tüm tasarruflar - veritabanı katmanı zor değildir.
Bir veritabanından geri yükleme ile fabrikaları birbirine bağlamakta hiçbir zorluk yoktur.
Genel olarak - sorunuzun doğru cevabı - en azından TÜM kalıplara ihtiyacınız var. Gerçekten. Hepsinde ustalaştıktan sonra, bu tür görevleri üstlenmeniz gerekir. Çünkü yol boyunca, uçtan uca etkinlikleri ve diğerlerini uygulamak için hem bir dekoratöre hem de bir cepheye (veritabanı için) ve bir ziyaretçiye ihtiyacınız olabilir.

 

Sergey Dzyublik :

1. Kaleci, bir değil, bu değişikliklerden birkaç yüz varken değişiklikleri geri almak için değiştirilebilir içerikle yazarken durumu saklamak için kullanılan desene benzer tasarım. Örneğin fotoğraf düzenleyici, metin düzenleyici...

2. Aslında orada bir şeyi eleştirmek konuyu bilmemek ve anlamamak kötü bir uygulamadır...

Önemli bir noktayı vurguladı. OOP'nin yanlış kullanım sorunlarının çoğunun temelinde yer alan değiştirilebilir içeriktir. Ben de uzun zamandır buna düşkündüm, ancak deneyimle birlikte anlayış yavaş yavaş geliyor. Nesneler (işaretçiler) arasında birçok ilişkinin olduğu ve aynı zamanda nesnelerin değişken olduğu bir kod - bu, şeytanın daha sonra bacağını kıracağı cehennem erişteleridir. Bu nedenle, referans nesnelerinin değişmez olduğundan emin olmak için çaba gösterilmelidir. Yalnızca değer nesneleri değişmelidir, yani. yapılar ve basit tipler, iyi, işaretçiler.

Onlar. bu durumda, orijinal nesneyi bir sınıf olarak değil, bir yapı olarak bildirmek istenir. Ardından içeriğini değiştirebilirsiniz. Aynı zamanda, doğal olarak, tartışılan modelde olduğu gibi artık herhangi bir işaretçi alıp kaydedemezsiniz ve bu doğrudur. Nesneleri, yöntemlerine açıkça başvurarak veya bir işleve argüman olarak ileterek değiştirmeniz gerekir. Onlar. Böyle:

memento.restoreState(myObject);

veya

myObject.restoreState(memento);

Ve böyle değil:

memento.restoreState();

bu, memento nesnesini değiştiriyor gibi görünüyoruz, ama aslında, muhtemelen programın başka bir yerinde bulunan başka bir nesne değişiyor. Bir yan etkisi var. Global bir değişkeni bir yerde değiştirmek ve değerini başka bir yerde kullanmakla aynı şey.

Onlar. memento, orijinal nesneye bir referans saklamamalıdır. Ve yalnızca içeriği saklayın. Bunların hepsi benim görüşüm, ama bunun gerçeklerden uzak olmadığını düşünüyorum)

 
Aleksey Mavrin :
Genel olarak - sorunuzun doğru cevabı - en azından TÜM kalıplara ihtiyacınız var. Gerçekten.

Kendi fikrim varmış gibi davranmıyorum, belki bir yerde okudum, ama IMHO, programlamada sadece iki görev var: programın doğru yapısı ve değişken için hızlı bir şekilde iyi bir isim seçin ve diğer her şey oldukça yapılır. basitçe

ben de ciddiyim

teşekkür ederim kalıplarınızı okuyacağım

Bekleyeceğim, aniden başka biri ortaya çıkacak, aksi takdirde akademik geliştiriciler acemi ve eğitmen seviyesi sorularına uçacak)))

 
Alexey Navoykov :

1) Nesneler (işaretçiler) arasında birçok ilişkinin olduğu ve aynı zamanda nesnelerin değişken olduğu kod - bu, şeytanın daha sonra bacağını kıracağı cehennem erişteleridir. Bu nedenle, referans nesnelerinin değişmez olduğundan emin olmak için çaba gösterilmelidir.
2)
Yalnızca değer nesneleri değişmeli, yani. yapılar ve basit tipler, iyi, işaretçiler.
3)
yani bu durumda, orijinal nesneyi bir sınıf olarak değil, bir yapı olarak bildirmek istenir. Ardından içeriğini değiştirebilirsiniz. Aynı zamanda, doğal olarak, tartışılan modelde olduğu gibi artık herhangi bir işaretçi alıp kaydedemezsiniz ve bu doğrudur.
4)
Nesneleri, yöntemlerine açıkça başvurarak veya bir işleve argüman olarak ileterek değiştirmeniz gerekir.
bu, memento nesnesini değiştiriyor gibi görünüyoruz, ama aslında, muhtemelen programın başka bir yerinde bulunan başka bir nesne değişiyor. Bir yan etkisi var.

1. Veri yapısı ortaya çıkıyor Ağaç tamamen kötü olandan ...
2. Kendi sınıfında zayıf C++ == özel yapı, ne yapmalı, muhtemelen yapıları ve sınıfları terk etmeye değer.
3. Ve haklı olarak: desen yok, işaretçiler arasında sıralama yok, özellikle büyük nesneler için bellek tasarrufu yok, ...
4. Arayüzlerin ve şablon işlevlerinin kullanımını yasaklamayı unutmamalıyız, aksi takdirde işin hangi nesneyle yapıldığı hiç belli olmaz - ne dehşet ...