OOP vs prosedürel programlama - sayfa 13
Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
Etkili çözümler ile ne kastedilmektedir?
Kararların etkinliği ile, mekanizmanın (ve programın şüphesiz bir mekanizma olduğu) en istikrarlı şekilde çalışacağı kararın kalitesini kastediyorum. Mekanizma açık, tutarlı ve üretken olmalıdır. Mekanizmanın işlevselliği, kendisine atanan tüm görevleri yerine getirmelidir. Mekanizma fazlalığı kabul etmez ve bu mekanizmanın geliştirilmesinde fazlalığın kesilmesi gerekir.
Aksi takdirde ya gelişme olmaz, ya da verim olmaz.
not. Bu sadece benim görüşüm ve bunu kimseye empoze etmiyorum.
OOP hayranı değilim.
Ancak bakım, ölçeklenebilirlik ve üçüncü şahıslar tarafından kullanım kolaylığı açısından, TS'yi (Karputov değil Peter) iten şey sadece taş devridir.
Her programcının bir ekipte, ideal olarak 4 kişiden fazla, sadece kodun verimliliğinin ve çok yönlülüğünün bu kodun iyi olduğu anlamına gelmediğini anlamak için çalışması gerektiğine dair güçlü bir fikrim var.
Burada bir holivar oluşturmak istemiyorum, ancak merak ediyorum, OOP destekçileri, bu çözümün OOP'siz bir çözümden daha verimli olduğu açıkça görülen bazı sorunları çözen bir kod sağlayabilir mi?
Ben OOP'siz bir problem çözücüyüm ve OOP'lu bir problem çözücü ile rekabet etmek istiyorum.
Ben size açıklamaya çalışayım, diyelim ki müteahhitsiniz ve sürekli iş kusturan bir müşteriniz var.. Sonra 5-6 siparişten sonra, bütün işlerinin bir anlamda aynı tip olduğunu fark ediyorsunuz.. Ve bunları bir şablonda birleştirebileceğinizi .. Ve ayrıca müşteri bu şablonları çok sayıda birbirleriyle birleştirmeyi sever .. OOP açısından, sonucun yerleştirileceği bir şablon oluşturmanız gerekir (ki sınıf içinde hesaplanacaktır) ve ardından müşteri tekrar zor bir iş çıkardığında, bu şablonun (sınıfın) istenen sayıda örneğini (10 diyelim) oluşturmanız ve özelliklerini (yapıcıda) ayarlamanız yeterli olacaktır. her biri müşterinin bulduğu... Sonuç olarak, bir sipariş açma kararı, sadece 10 örneğin her birinde sonuca bakacak bir döngüye dayanacaktır ve her şey.. Bu tür siparişleri perçinleyebilirsiniz. 5 dakika..
Ve OOP olmadan, bir kopya yapmak mümkün olmayacak ve değişikliklerin olanı bozmayacağını umarak hemen hemen her şeyi yeniden yapmak gerekecek .. sonuç olarak, çok daha fazla zaman harcanacak, ..
Sonuç: OOP bilen bir programcı (OOP için uygun olan) problemleri çok daha hızlı ve çok daha az hata ile çözebilecektir..
Ben size açıklamaya çalışayım, diyelim ki icracısınız ve sürekli iş kusturan bir müşteriniz var.. Sonra 5-6 siparişten sonra tüm görevlerinin bir anlamda aynı tip olduğunu fark ediyorsunuz.. Ve bunları bir şablonda birleştirebileceğinizi .. Ve ayrıca bir müşteri bu şablonları birbirleriyle çok sayıda birleştirmeyi sever .. OOP açısından, sonucun yerleştirileceği bir şablon oluşturmanız gerekir (ki sınıf içinde hesaplanacaktır) ve daha sonra müşteri tekrar zor bir iş attığında, sadece gerekli sayıda örnek oluşturmanız (diyelim ki 10) bu şablonu (sınıf) ve özellikleri (yapıcıda) ayarlamanız gerekecektir. her biri müşterinin bulduğu... Sonuç olarak, sipariş açma kararı, sadece 10 örneğin her birinde sonuca bakacak bir döngüye dayanacak ve bu kadar.. Yapabileceksiniz. bu tür siparişleri 5 dakikada perçinlemek.
Ve OOP olmadan, bir kopya yapmak mümkün olmayacak ve değişikliklerin olanı bozmayacağını umarak hemen hemen her şeyi yeniden yapmak gerekecek .. sonuç olarak, çok daha fazla zaman harcanacak, ..
Sonuç: OOP bilen bir programcı (OOP için uygun olan) problemleri çok daha hızlı ve çok daha az hata ile çözebilecektir..
Belki sen haklısın. Hiçbir zaman siparişleri tamamlamadım ve müşterilerin ne istediğini bilmiyorum. Tarif ettiğiniz şey daha çok rutin çalışma gibi ve ben burada geliştirmeden bahsediyorum. Muhtemelen, rutin işler için (bir ekip tarafından da gerçekleştirilir), OOP basitçe yeri doldurulamaz. Öyle bir deneyimim yok ve bilmiyorum.
OOP olmadan yapmamak daha iyi olan aynı türdeki bu görevlere özel bir örnek verebilir misiniz?
OOP hayranı değilim.
Ancak bakım, ölçeklenebilirlik ve üçüncü şahıslar tarafından kullanım kolaylığı açısından, TS'yi (Karputov değil Peter) iten şey sadece taş devridir.
Her programcının bir ekipte, ideal olarak 4 kişiden fazla, sadece kodun verimliliğinin ve çok yönlülüğünün bu kodun iyi olduğu anlamına gelmediğini anlamak için çalışması gerektiğine dair güçlü bir fikrim var.
Oh, ekip çalışması tamamen başka bir hikaye! Ve bir programcı ekibini yönetmek, katılımcı sayısına eşit derecede bir şarkıdır.
Cumartesi akşamı size bir hikaye anlatacağım. Şirketimizin bir parça demir püskürttüğü zamanlar hakkında. Tekrarlarsa, özür dilerim, bir zamanlar hikayeyi zehirleyebilirdi.
Patron beni arar, sorar - işte çok meşgul müsün? o kadar da değil diyorum
-Şu anda ne yapıyorsun? Kendime sürekli devamsızlık içeren kişisel bir program aldığım için patron ne yaptığımı asla bilmiyordu))
Evet diyorum, eksperlerimiz için ekipmanımız için bir test paketi yazıyorum. Şef çok sevindi - harika, sadece Sibirya koşullarında deneyimleyeceksiniz. Aleksey, uçmamız lazım, adamlar orada mahsur kaldı, çözemiyorlar. Eh, gerekli, gerekli, genellikle iş gezilerini sevdim, tam özgürlük.
Krasnoyarsk'a geliyorum, çocuklar benimle buluşuyor, bakıyorum, bir şekilde suçlu davranıyorlar, açıkçası buruşuyorlar. Bir kafeye gittik, içtik, konuştuk. Neyin işe yaramadığını soruyorum? Oradaki şef zaten perişan durumda, üçüncü aydır bir iş seyahatindesiniz ve bir noktada sıkışıp kaldınız. Size sadece transfer yoluyla para göndermeyi başarır.
Neyse açtılar. Bir Sibirya köyüne ulaştık, beklemek için durduk ve iki genç kız kardeş vardı. Eh, aşk dönmeye başladı, arkadaşlar da çekildi, böylece kimse kırılmadı.
Ben de senden vazgeçmeyeceğim diyorum, ben de aynıyım. Ama ilerlemeye devam etmelisin. Şunu yapalım, bütün çelengi kuralım, sadece çöp kalır, 500 kilometre, sonra seni ödüllendireceğim, patrondan para sızdıralım ve sen ve bu arkadaşlar yılbaşını kutlar, tamam mı?
Şimdi kadınlar kızacak, ama ilk kabul eden Lyokha oldu, karımın doğurması gerektiğini söylüyor, burada fikrimi değiştirsem iyi olur! Hepsi evliydi ve bir nedenden dolayı hiçbiri eve acele etmeye başlamadı)))
Ama sonra genç, güzel Sibiryalılar onları beklerken erkeklerin nasıl saban sürdüğünü içimden anladım))
Argüman hiç bir şey değil.
Herhangi bir görev hem OOP ile hem de onsuz çözülebilir. OOP olmadan, yeniden kullanılacak ve üzerinde yapılan değişiklikler nedeniyle tüm program bozulmayacak birleşik işlevleri kolayca oluşturabilirsiniz. OOP ile biraz daha kod. OOP kullanılarak okunabilirlik artırıldı mı? xs.
Her sınıfın ayrı bir dosyada saklandığını, her işlevin de ayrı bir dosyada olduğunu biliyorum. Sadece bir alışkanlık ve rahatlık meselesi.
Yüzeyde yatan bir başka basit örnek.. Metaeditördeki danışmanların jeneratörü... Programlamayı bile bilmeyen herkes, çok sayıda gösterge ve koşuldan oluşan bir danışmanı 10 saniyede perçinleyebilir )) ) Ve tüm bunlar OOP ))
Argüman hiç bir şey değil.
Herhangi bir görev hem OOP ile hem de onsuz çözülebilir. OOP olmadan, yeniden kullanılacak ve üzerinde yapılan değişiklikler nedeniyle tüm program bozulmayacak birleşik işlevleri kolayca oluşturabilirsiniz. OOP ile biraz daha kod. OOP kullanılarak okunabilirlik artırıldı mı? xs.
Her sınıfın ayrı bir dosyada saklandığını, her işlevin de ayrı bir dosyada olduğunu biliyorum. Sadece bir alışkanlık ve rahatlık meselesi.
İşte bu başlıkta OOP olmadan çözülebilecek bir görev örneği vardı ama pek mantıklı değil.
Argüman hiç bir şey değil.
Herhangi bir görev hem OOP ile hem de onsuz çözülebilir. OOP olmadan, yeniden kullanılacak ve üzerinde yapılan değişiklikler nedeniyle tüm program bozulmayacak birleşik işlevleri kolayca oluşturabilirsiniz. OOP ile biraz daha kod. OOP kullanılarak okunabilirlik artırıldı mı? xs.
Her sınıfın ayrı bir dosyada saklandığını, her işlevin de ayrı bir dosyada olduğunu biliyorum. Sadece bir alışkanlık ve rahatlık meselesi.
Kişisel gelişimde OOP'ye ihtiyacım olmadığını kesin olarak söyleyebilirim, ancak ekibin büyük bir projede çalışması konusunda tam bir güvenim yok. Çeşitli programcılar tarafından oluşturulan kodun geliştirilmesi ve bağlantısı benim tarafımdan hiç düşünülmedi ve bunu kendi yolumla nasıl uygulayacağımı bilmiyorum. Şu anda kabul ettiğim geliştirme aşamasında OOP lehine tek argüman bu.
Bu ana argüman değil.
Prosedürel programlamada polimorfizmin bir benzeri yoktur.