OOP uzmanları için soru. - sayfa 9

 
Roman :

Evet, C++'da OOP anlayışı hemen gelmiyor, prosedürel yaklaşımı anladıktan bir buçuk yıl sonra bir yerde OOP'a biraz girmeye başladım.

Ben de aynısını yapıyorum - yavaş yavaş ... ve tam bir anlayış sadece 4-5 yıl sonra geliyor (ve bu sıradan bir insan için normaldir)

 
Igor Makanu :


Not: Düğme rengi nasıl değiştirilir? - önceki nesneyi öldür ve farklı renkte yeni bir düğme oluştur? - ve düğmenin durumu nasıl alınır? - ve eğer bu yüzlerce düğmeden oluşan bir renk şemasıysa - yine her şeyi öldürüp başkalarını mı yaratıyorsunuz? ;)

Ve MQ'da nasıl oluyor?

class CButton : genel CWndObj :

 private :
   CChartObjectButton m_button;             // chart object
..
virtual bool       OnSetColor( void )             { return (m_button.Color(m_color));                }

sınıf CChartObjectText : genel CChartObject

sınıf CChartObject : genel CObject :

 bool CChartObject::Color( const color new_color) const
  {
//--- check
   if (m_chart_id==- 1 )
       return ( false );
//--- result
   return ( ObjectSetInteger (m_chart_id,m_name, OBJPROP_COLOR ,new_color));
  }

sınıf CWndObj : genel CWnd :

color             m_color;               // object color
...
bool CWndObj::Color( const color value )
  {
//--- save new value of parameter
   m_color= value ;
//--- call virtual event handler
   return (OnSetColor());
  }


Bu nedenle, CButton sınıfına bir fonksiyon eklemek yeterlidir:

 virtual bool       OnSetColor( uint clr)         { return (m_button.Color(clr));  }
 
Nikolai Semko :

Ve MQ'da nasıl oluyor?

class CButton : genel CWndObj :

sınıf CChartObjectText : genel CChartObject

sınıf CChartObject : genel CObject :

sınıf CWndObj : genel CWnd :


Bu nedenle, CButton sınıfına bir fonksiyon eklemek yeterlidir:

her şey doğru, tüm OOP hileleri böyle görünüyor, MQL'de bile - SB'nin kaynak kodlarına baktım, Delphi'de, hatta VS'de bile - kod yapısı ve mantık her zaman tekrar ediyor


Bakın, aboneliklerimde bu kanal var, genel olarak yazar hakkında olumlu bir fikrim var, videonuzun anlaşmazlığının başladığı konunun tekrarı bile var:



ve sevdiğim başka bir kanal daha var:


videonun OOP açısından anlamı taban tabana zıt


Mesajımı sildim, tartışma planladığımdan daha uzun sürecek, ayrıntıları bekleyeceğimden şüpheliyim ve "küresel OOP" yi pratik fayda olmadan tartışmak en iyi fikir değil

 
Igor Makanu :

her şey doğru, tüm OOP hileleri böyle görünüyor, MQL'de bile - SB'nin kaynak kodlarına baktım, Delphi'de, hatta VS'de bile - kod yapısı ve mantık her zaman tekrar ediyor


Bakın, aboneliklerimde bu kanal var, genel olarak yazar hakkında olumlu bir fikrim var, videonuzun anlaşmazlığının başladığı konunun tekrarı bile var:


ve sevdiğim başka bir kanal daha var:


videonun OOP açısından anlamı taban tabana zıt


Mesajımı sildim, tartışma planladığımdan daha uzun sürecek, ayrıntıları bekleyeceğimden şüpheliyim ve "küresel OOP" yi pratik fayda olmadan tartışmak en iyi fikir değil

Dürüst olmak gerekirse, ben de yavaş yavaş FKÖ'ye girmeye başlıyorum. Egor Bugaenko'ya daha sezgisel olarak ve zaten sahip olduğumuz küçük deneyime dayanarak katılıyorum.  
Ayrıca, karmaşıklığın genellikle bir çıkmaza yol açtığını tamamen felsefi olarak biliyorum, bu nedenle "basit bileşenlerden oluşan bir bütün" şemasının "tek bir karmaşık bileşenden oluşan bir bütün" den daha mükemmel olduğunu düşünüyorum.  

yani izledikten sonra  
Bugün nasılsın?   video Aşağıdaki mantık ve paradigmaya bağlı kalmaya çalışacağım:
Bir noktada, sorunu çözmenin tek yolunun hantal karmaşıklıklardan geçtiği görülüyorsa, o zaman onu daha basit öğelere ayırmanın zamanı gelmiştir. Bunun imkansız olduğu görülüyorsa, yanlış konsept seçilmiştir ve bunun değiştirilmesi ve tüm kodun yeniden yazılması gerekir. Bunun gelecekte zaman kazandıracağını düşünüyorum.

 

Birçok seçenek. Her şey neye ihtiyacınız olduğuna ve hayal gücünüzün ne için yeterli olduğuna bağlıdır. Örneğin öyle.

 class A
  {
public :
                     A( void )  {    };
                    ~A( void )  {    };
  };
  
class B
  {
public :
                     B( void )  {    };
                    ~B( void )  {    };
  };

class C
  {
public :
                     C( void )  {    };
                    ~C( void )  {    };
  };

struct STest
  {
   A a[];
   B b[];
   C c[];
  } test[];
 
Igor Makanu :

Gönderimi sildim, tartışma beklenenden uzun sürecek

Peter'ın temaları, yolundaki her şeyi çeken acımasız bir unsurdur)) bu sadece bir giriş, ileride "çekirdek motor konseptine" bir çıkış var ve orada Peter daha fazla deneyime sahip))).

 
Nikolai Semko :

yani izledikten sonra   Bugün nasılsın?   video Aşağıdaki mantık ve paradigmaya bağlı kalmaya çalışacağım:
Bir noktada, sorunu çözmenin tek yolunun hantal karmaşıklıklardan geçtiği görülüyorsa, o zaman onu daha basit öğelere ayırmanın zamanı gelmiştir. Bunun imkansız olduğu görülüyorsa, yanlış konsept seçilmiştir ve bunun değiştirilmesi ve tüm kodun yeniden yazılması gerekir. Bunun gelecekte zaman kazandıracağını düşünüyorum.

teorik olarak işe yarayacaktır, pratikte - herhangi bir hatanın oyuncunun oyun donanımı veya ofis yazılımı tarafından telafi edileceği, hataların da çok kritik olmadığı oyun geliştirme hariç, çalışacağınız sektöre bağlıdır - o zaman biz yama yapacak veya yeniden yazacak, programcının faaliyet alanları var , hata yapamazsınız, üretim otomasyonu üzerinde çalıştım ve otomasyon ışıklarla yanıp sönmedi ve enerji - güç türbinleri. Yazılım ve otomasyon "bojili vagon" - otomatik kontrol sistemleri rafları, otomatik proses kontrol sistemleri, titreşim kontrolü, operatör iş istasyonları ve kontrolörler ve aktüatör sensörleri ve tüm bunlar aynı anda bir kompleks içinde çalışır, konseptteki herhangi bir hata acil bir durumdur. en iyi ihtimalle dur, en kötü ihtimalle ekipman imhası ve maddi hasar.

Bu ne için? - yine, kodun her şeyden önce verimli olması gerektiği gerçeğine! Yıllar boyunca yaratılan her şey "OOP'nin yanlış kullanımı" üzerine yazılmıştır ve yenilikçiler ... bir bardak bira üzerine oturun, Microsoft ve Google'ın yanıldığını hayal edin - bu harika! ama henüz sorumluluk yok

 
A100 :

Bana 1. yazdın (bu seni endişelendiren anlamına geliyor), Alexey Viktorov'un Standart Kütüphane ile ilgili sorularını genel olarak cevapladım

Soru retorikti. Belli değil miydi?

 
Alexey Viktorov :

Soru retorikti. Belli değil miydi?

Retorik soru bariz bir ifade içeriyor - ifadenin ne olduğunu anlamadım. Açıklayabilir misin?
 
A100 :
Retorik soru bariz bir ifade içeriyor - ifadenin ne olduğunu anlamadım. Açıklayabilir misin?

Bir retorik soru, herhangi bir soru gibi, hiçbir şekilde bir ifade içeremez. Soru Afrika'da, soru. Bu aynı sorudur, ancak bir cevap gerektirmez, beklemez. Soru hiçbir yerde değil.