Prosedürel kodun yapamayacağı hangi OOP kodu yapabilir?

 

Bu konuyu, prosedürel programlamaya karşı nesne yönelimli programlamanın avantajları hakkında faydalı bilgiler toplamak umuduyla açıyorum.

Ayrıca, bu konu dilden bağımsızdır, çünkü mql4 ve mql5 aynı OOP dilini sunar (şu anda mql4'te henüz mevcut olmayan bazı yeni gelişmiş özellikler dışında).

OOP destekçileri ve karşıtları arasında bir "savaş" istemiyorum, bu yüzden bu konu yakından yönetilecek, lütfen zamanınızı ve benim zamanımı boşa harcamayın.

Lütfen, yüksek teori veya soyut kavramları değil, amacınızı açıklamak için örnekler ve kodlar sağlayın.

EDIT: Bu konu dilden bağımsız olsa da, hala ticaret ve mql4/mql5 hakkında konuşuyoruz, bu yüzden "savaş oyunları" veya "elma ve portakal" örnekleri vermeyin lütfen.

 
Aslında, prosedürel koddan OOP'ye veya tam tersine yeniden düzenlenemeyecek bir görev olabileceğini düşünmüyorum. Fark, kodun sürdürülebilirliği ve okunabilirliğidir. Örneğin, prosedürel kodda global ve/veya yerel verilere (değişkenler) başvurabilirsiniz. Bunlara ek olarak, OOP bir kapsam daha ekler - nesne dahili değişkenleri (durum). Bunları OOP'de kullanmak çok kolay ve doğaldır ve aynı mantığın prosedürel olarak uygulanması, ek kod ve veri yapılarıyla bir tür geçici çözümler gerektirecektir. Başka bir deyişle OOP, kodlamanın daha kısa ve daha güzel bir yoludur.
 
OOP'nin en önemli parçası olan miras ağacı da dahil olmak üzere aşırı yüklenmiş sanal işlevler için nasıl bir geçici çözüm oluşturmak istersiniz? OOP değil, yapılar hakkında konuşuyorsunuz.
 

OOP, doğa varlıkları gibi çalışmak ve düşünmek için tasarlanmıştır, birçok türde araçlarımızın, birçok beceriye sahip askerlerimizin ve birçok özelliğe sahip silahlarımızın olduğu bir savaş oyunu geliştirmek istiyorsak hayal edelim.

OOP'siz bu tür bir oyun geliştirmek, geliştiricinin tüm bu tür nesneleri takip etmesi ve veri yapılarını ve hafızayı iyi yönetmesi ve ayrıca kalıtım gibi OOP özelliklerini simüle etmesi zor olacaktır (ancak zor olacaktır). yapılabilir), OOP, düşünmeyi ve geliştirmeyi kolaylaştırdı, ayrıca kod okumayı ve hata ayıklamayı daha kolay hale getirdi.

bazen gereğinden fazla OOP'ye sahip olmak, kodun anlaşılmasını ve okunmasını sevmediğim düşmanca (kişisel bakış açım) yapacaktır.

 
Stanislav Korotky :
Aslında, prosedürel koddan OOP'ye veya tam tersine yeniden düzenlenemeyecek bir görev olabileceğini düşünmüyorum. Fark, kodun sürdürülebilirliği ve okunabilirliğidir. Örneğin, prosedür kodunda global ve/veya yerel verilere (değişkenler) başvurabilirsiniz. Bunlara ek olarak, OOP bir kapsam daha ekler - nesne dahili değişkenleri (durum). Bunları OOP'de kullanmak çok kolay ve doğaldır ve aynı mantığın prosedürel olarak uygulanması, ek kod ve veri yapıları ile bir tür geçici çözümler gerektirecektir. Başka bir deyişle OOP, kodlamanın daha kısa ve daha güzel bir yoludur.
OOP'nin daha kısa bir kodlama yolu olduğundan kesinlikle şüpheliyim.
 
Doerk Hilger :
OOP'nin en önemli parçası olan miras ağacı da dahil olmak üzere aşırı yüklenmiş sanal işlevler için nasıl bir geçici çözüm oluşturmak istersiniz? OOP değil, yapılar hakkında konuşuyorsunuz.
"if...then...else..." ifadesi işi yapmalıdır.
 
Mohamed Hamdy :

OOP, doğa varlıkları gibi çalışmak ve düşünmek için tasarlanmıştır, birçok türde araçlarımızın, birçok beceriye sahip askerlerimizin ve birçok özelliğe sahip silahlarımızın olduğu bir savaş oyunu geliştirmek istiyorsak hayal edelim.

OOP'siz bu tür bir oyun geliştirmek, geliştiricinin tüm bu tür nesneleri takip etmesi ve veri yapılarını ve hafızayı iyi yönetmesi ve ayrıca kalıtım gibi OOP özelliklerini simüle etmesi zor olacaktır (ancak zor olacaktır). yapılabilir), OOP, düşünmeyi ve geliştirmeyi kolaylaştırdı, ayrıca kod okumayı ve hata ayıklamayı daha kolay hale getirdi.

bazen gereğinden fazla OOP'ye sahip olmak, kodun anlaşılmasını ve okunmasını sevmediğim düşmanca (kişisel bakış açım) yapacaktır.

Ticaret, otomatik ticaret sistemleri ve ticaret stratejilerinin test edilmesi hakkında forum

Prosedürel kodun yapamayacağı hangi OOP kodu yapabilir?

Alain Verleyen , 2016.05.22 14:03

Bu konuyu, prosedürel programlamaya karşı nesne yönelimli programlamanın avantajları hakkında faydalı bilgiler toplamak umuduyla açıyorum.

Ayrıca, bu konu dilden bağımsızdır, çünkü mql4 ve mql5 aynı OOP dilini sunar (şu anda mql4'te henüz mevcut olmayan bazı yeni gelişmiş özellikler dışında).

OOP destekçileri ve karşıtları arasında bir "savaş" istemiyorum, bu yüzden bu konu yakından yönetilecek, lütfen zamanınızı ve benim zamanımı boşa harcamayın.

Lütfen, yüksek teori veya soyut kavramları değil, amacınızı açıklamak için örnekler ve kodlar sağlayın.

EDIT: Bu konu dilden bağımsız olsa da, hala ticaret ve mql4/mql5 hakkında konuşuyoruz, bu yüzden "savaş oyunları" veya "elma ve portakal" örnekleri vermeyin lütfen.


 

Ben OOP'nin büyük bir hayranıyım - prosedürel MQL'ye geri döneceğimi hayal bile edemiyorum. Programları daha karmaşık hale getirmek daha kolaydır. Her neyse... MQL ile ilgili sorun, yeni bir kullanıcının buradan başlamakta güçlük çekmesidir.

  • yerleşik olay yöntemleri OO değildir. Onlara bağlanmanız gerekir, bu da dinleme nesnelerinin kök düzeyinde bildirilmesini gerektirir. Bu tasarımla temel OOP ilkelerinden biri tehlikeye atılmıştır.
  • ortak kalıplara sahip eksik 'sistem' kod paketleri var. Kullanıcılar arasında uyumlu paketler oluşturmayı engeller ve ciddi bir OOP kodlayıcının kendi özel paketlerini oluşturmak için çok zamana ihtiyacı vardır. Desteklenmeyen sınıf adı önekleri (paket adları) yalnızca küçük bir sorundur - harici kodu yine de yeniden kullanamadığınızda.

Bu yüzden OOP'yi doğrudan MQL'de öğrenmeye başlamanızı tavsiye etmem. Kodlayıcı, çalışması için neye ihtiyacı olduğunu bilmelidir.

 
Alain Verleyen :
"if...then...else..." ifadesi işi yapmalıdır.
Hadi ama ;) Pek değil ;) Yerli bir şey işi bir şekilde garip yapabilirse, o zaman işaretçileri, ancak MQL'de kısıtlamalar var. Aksi takdirde ... kod saçma olur. Ve eğer bu başlıktaki soruya cevap olarak absürd kodu kabul ederseniz, o zaman eskimiş olur ;) Absürtlüğün iyi bir sınır olduğuna katılıyor musunuz? Haydi evet deyin, sadece bir kez ve sadece egom için ;)
 
Doerk Hilger :
Hadi ama ;) Pek değil ;) Yerli bir şey işi bir şekilde garip yapabilirse, o zaman işaretçileri, ancak MQL'de kısıtlamalar var. Aksi takdirde ... kod saçma olur. Ve eğer bu başlıktaki soruya cevap olarak absürd kodu kabul ederseniz, o zaman eskimiş olur ;) Absürtlüğün iyi bir sınır olduğuna katılıyor musunuz? Haydi evet deyin, sadece bir kez ve sadece egom için ;)

Üzgünüm ama hayır, evet demeyeceğim...Bir kod ya amacına ulaşıyor ya da ulaşmıyor, eğer teknik özelliklere uygun çalışıyorsa, saçma bir şey yok.

Soru, "OOP, prosedürün yapamayacağı ne yapabilir"? Stanislav , OOP'nin prosedürle aynı şeyi yapabileceğini, ancak "daha kısa ve daha güzel" bir şekilde yapabileceğini söylüyordu. Katılıyorum (daha kısa fikir dışında ama bu o kadar da önemli değil).

 

Programlama GUI'leri, bir programcı olarak tüm zamanımda en çok yaptığım şeydi. Eğer öyleyse, aksi takdirde birkaç yönde iletişim kurması gereken eksiksiz bir GUI'yi kodlamak mümkün değildir. Kodun okunamaz hale geleceğine ve sonunda çok yavaşlayacağına dair o kadar çok ifadeye ihtiyacınız olacak ki bu da şu anlama gelir: Hedefe ulaşılmadı, çünkü sonucu görene kadar her tıklamadan sonra bir fincan kahve içmeye zorlanmak istemiyorum.

Bir CPU'nun OOP hakkında hiçbir şey bilmemesi durumundan dolayı - elbette - sadece işaretçiler ve karmaşık diziler kullanmadan her şeyi kodlayabilirsiniz. Ama bu çok saçma. Ayrıca ekran içeriğimi gerçek zamanlı olarak filme çeken ve duvardaki bir ışık projektörü ile sırayla ışınlayan 10000 kişiyi işe alabilirdim. Bu da hedefe ulaşıyor mu?