Höyükte OOP hakkında konuşun - sayfa 10
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
Empoze etmek gerekli değildir, ancak prosedürel biçimde kodun mantığının gereksiz hareketler olmadan zaten görülebildiği ve işe alınan bir programcının her hareketinin işverene paraya mal olduğu açıktır. Bu nedenle, işveren aptal değilse, OOP'ye düşmeyecektir, ancak diğer yandan kurnaz bir programcı, avantajından yararlanarak ondan daha fazla kesinti yapmak için OOP'nin aşamalılığı hakkında ona erişte asabilir. okuma yazma bilmeme. :)
Ha!
Sonuçta Duc, yürürken - "gereksiz hareketler olmadan" mantığı da görülebilir, ancak bir nedenden dolayı herkes ulaşımla gitmeye çalışıyor. Deliliğe geliyor - bir arabaya biniyorlar, bir spor salonuna iki kilometre sürüyorlar, böylece orada bir koşu bandında beş kilometre "sarabiliyorlar".
Programlamaya daha yakın - DOS'ta, video arabelleğine basit bir yazma ile bir pencere oluşturulur. Ve Windows'ta en basit pencereyi oluşturmak için - bir pencere sınıfı kaydetmeniz, oluşturmanız, bir mesaj işleme döngüsü başlatmanız gerekir - ancak bir nedenden dolayı herkes bu "ekstra hareketleri" yapar.
Yani burada da. OOP, "ilericilik" için değil, bu tekniğin sağladığı avantajlar için ve sonuçta işveren için daha ucuz olduğu için seçilmiştir. Çünkü prosedürel bir tarzda bir şey yazarsanız, o zaman OOP tarzında yazılan aynı verimlilikle sürdüremezsiniz.
İyi bir örnek, Peter Konov'un kodudur - bir yandan, oldukça normal bir prosedür kodudur, ancak diğer yandan, onunla çalışmak için, yapısı hakkında bu kadar çok bilgiyi sürekli aklınızda tutmanız gerekir. Ben şahsen böyle bir görev için büyük bir sistem için bile para almayacağım. Aynı zamanda, OOP tarzında yazılan SB, bakım ve modifikasyon için çok uygundur. Standard Library TS şablonundaki nesnelerin mimarisi, Peter'ın kodundan çok daha karmaşıktır, ancak onu anlamak ve değiştirmek çok daha kolaydır.
"Gereksiz hareketler olmadan prosedürel stil" gerçeğiyle ilgili tüm konuşmalar, yalnızca gerçekten karmaşık bir yapı yazmanız ve özellikle üzerinde bir değişiklik yapmanız gerektiğinde ana kadardır. OOP'nin bu kadar yaygın olarak kullanılmasının nedeni budur - programcılar için daha kolay ve müşteriler için daha ucuzdur. Bununla birlikte, üzerinde çok basit bir şey yapmak için "aşırı hareketler" gerekir. Sadece bu en "basit" - kimsenin buna ihtiyacı yok, herkesin "karmaşık" ihtiyacı var, bu da OOP kullanılarak daha iyi yapılır.
PS Ve hala (hadi "Siz") OOP erişim değiştiricileri olmadan hiçbir yerde kullanılmaması gereken işlevlere erişimi kısıtlamayı nasıl önerdiğinizi anlamıyorum?
George Merts :
Çünkü bir şeyi prosedürel bir tarzda yazarsanız, o zaman OOP tarzında yazılan verimliliğin aynısını sürdüremezsiniz.
PS Ve hala (hadi "Siz") OOP erişim değiştiricileri olmadan hiçbir yerde kullanılmaması gereken işlevlere erişimi kısıtlamayı nasıl önerdiğinizi anlamıyorum?Numara. Her şey tam tersi.
OOPish kodunun bakımı ve değiştirilmesi de aynı derecede zordur, çünkü oradaki mantık bir sürü farklı numara tarafından gizlenir ve bu durumda kodu yeniden yazmak daha kolaydır. Sonuçta, OOP'nin amacının mantığı gizlemek olduğu söyleniyor, iyi ki saklamışlar ve aniden ortaya çıkarmanız gerekiyorsa, bu ek bir ücret karşılığında bir hizmettir.
İşlev sarmalayıcı, dahili işlevleri gizlemenize izin verir, ancak elleriniz kaşınıyorsa ve yine de bu dahili işlevi vidalamak istiyorsanız, kaynağı DLL'de ayrı bir dosyada ve dosyayı en uzak dizinde gizleyebilirsiniz. Böylece tüm arzunuz bulunamadı, belki de özellikle şiddetli programcılar için hala seçenekler var. :)
Numara. Her şey tam tersi.
OOPish kodunun bakımı ve değiştirilmesi de aynı derecede zordur, çünkü oradaki mantık bir sürü farklı numara tarafından gizlenir ve bu durumda kodu yeniden yazmak daha kolaydır. Sonuçta, OOP'nin amacının mantığı gizlemek olduğu söyleniyor, iyi ki saklamışlar ve aniden ortaya çıkarmanız gerekiyorsa, bu ek bir ücret karşılığında bir hizmettir.
İşlev sarmalayıcı, dahili işlevleri gizlemenize izin verir, ancak elleriniz kaşınıyorsa ve bu dahili işlevi yine de mahvetmek istiyorsanız, kaynağı DLL'de ayrı bir dosyada ve dosyayı en uzak dizinde gizleyebilirsiniz. Böylece tüm arzunuz bulunamadı, belki de özellikle şiddetli programcılar için hala seçenekler var. :)
Mantık gizliyse neden "değiştirmek zor" olsun? Bunun mantığı gizlidir, böylece bunun yapılamayacağı hiçbir şeyi değiştirme fırsatınız olmaz.
Sadece prosedürel yaklaşımda bir şeyi değiştirmek istediniz, değiştirdiniz ve sonra neden işe yaramadığını anlamıyorsunuz (veya daha kötüsü, BAZEN anlaşılmaz hatalar ortaya çıkıyor). Ve OOP yaklaşımında bunu değiştirmek istediniz - ve sınıfın içindekilere erişiminiz yok. Ve erişim olmadığı için, bunun bir nedenden dolayı yapıldığı anlamına gelir, orada hileli bir şey vardır, kullanım için bazı örtülü koşullar vardır. Buna göre, eğer bir şeyi değiştirmek istiyorsanız, o zaman aynı sınıfı alırsınız, ondan kendi sınıfınızı miras alırsınız ve orada ihtiyacınız olanı değiştirirsiniz, mirasçıda zaten korumalı yöntemlere erişiminiz olur.
Üstelik, miras kalmış olsa bile - özel bir yöntem veya alanla karşılaşabilirsiniz - mirasçıda bile erişilemez ve bu bir kez yapıldığında - yine, bir nedenden dolayı, bu alanın soyundan gelenlerde bile değiştirilmemesi gerektiği anlamına gelir.
"DLLku'da gizle" hakkında konuşmak - buradaki sorun, DLLku'daki HER ŞEYİ aynı anda gizleyebilmenizdir. Bir nesnenin parçası değil. Ve erişim değiştiricisi, nesnenin yalnızca bir kısmını gizlemek için gereken şeydir. Bunun için her şey başlatılır - böylece programın her yerindeki programcı yalnızca ihtiyaç duyduğu şeye erişebilir ve "yukarıdan" hiçbir şeye erişemez - bu, yanlışlıkla gerekli olanı değiştirmeyeceğinden korkmamanızı sağlar. , ancak değişiklik için geçerli olan kısmı değiştirebilecektir. Ve o zaman DLL'deki nokta nedir? DLL kodunu açın - ardından erişim, parçaları değil tümünü açar. Kapat - tekrar, tüm erişim kapatılacak.
Özel-korumalı-kamusal bölümleri kullanmadan prosedürel bir şekilde erişimi kısıtlamanın nasıl mümkün olduğunu bilmiyorum. Ve bu sınırlama bana çok yardımcı oluyor.
Mantık gizliyse neden "değiştirmek zor" olsun? Bunun mantığı gizlidir, böylece bunun yapılamayacağı hiçbir şeyi değiştirme fırsatınız olmaz.
Sadece prosedürel yaklaşımda bir şeyi değiştirmek istediniz, değiştirdiniz ve sonra neden işe yaramadığını anlamıyorsunuz (veya daha kötüsü, BAZEN anlaşılmaz hatalar ortaya çıkıyor). Ve OOP yaklaşımında bunu değiştirmek istediniz - ve sınıfın içindekilere erişiminiz yok. Ve erişim olmadığı için, bunun bir nedenden dolayı yapıldığı anlamına gelir, orada hileli bir şey vardır, kullanım için bazı örtülü koşullar vardır. Buna göre, eğer bir şeyi değiştirmek istiyorsanız, o zaman aynı sınıfı alırsınız, ondan kendi sınıfınızı miras alırsınız ve orada ihtiyacınız olanı değiştirirsiniz, mirasçıda zaten korumalı yöntemlere erişiminiz olur.
Üstelik, miras kalmış olsa bile - özel bir yöntem veya alanla karşılaşabilirsiniz - mirasçıda bile erişilemez ve bu bir kez yapıldığında - yine, bir nedenden dolayı, bu alanın soyundan gelenlerde bile değiştirilmemesi gerektiği anlamına gelir.
"DLLku'da gizle" hakkında konuşmak - buradaki sorun, DLLku'daki HER ŞEYİ aynı anda gizleyebilmenizdir. Bir nesnenin parçası değil. Ve erişim değiştiricisi, nesnenin yalnızca bir kısmını gizlemek için gereken şeydir. Bunun için her şey başlatılır - böylece programın her yerindeki programcı yalnızca ihtiyaç duyduğu şeye erişebilir ve "yukarıdan" hiçbir şeye erişemez - bu, yanlışlıkla gerekli olanı değiştirmeyeceğinden korkmamanızı sağlar. , ancak değişiklik için geçerli olan kısmı değiştirebilecektir. Ve o zaman DLL'deki nokta nedir? DLL kodunu açın - ardından erişim, parçaları değil tümünü açar. Kapat - tekrar, tüm erişim kapatılacak.
Özel-korumalı-kamusal bölümleri kullanmadan prosedürel bir şekilde erişimi kısıtlamanın nasıl mümkün olduğunu bilmiyorum. Ve bu sınırlama bana çok yardımcı oluyor.
Georges, yine boncuk atıyorsun))) anlamsız
Georges, yine boncuk atıyorsun))) anlamsız
Belki.
Ama sensin, yarı zamanlı Casanova... Ve ben yarı zamanlı bir öğretmenim. "Müşterinin kaybolmadığını" görüyorum. Buna göre açıklamaya devam ediyorum. "Profesyonel deformasyon" yazın.
Belki.
Ama sensin, yarı zamanlı Casanova... Ve ben yarı zamanlı bir öğretmenim. "Müşterinin kaybolmadığını" görüyorum. Buna göre açıklamaya devam ediyorum. "Profesyonel deformasyon" yazın.
Kazanlarla aldım. Bir peri masalı buldum ve kendime inandım) Noel Baba'daki bir çocuk gibi, golly)
Empoze etmek gerekli değildir, ancak prosedürel biçimde kodun mantığının gereksiz hareketler olmadan zaten görülebildiği açıktır ve işe alınan bir programcının her hareketi işverene paraya mal olur.
Değişiklik yapılması gerekiyorsa, yukarıdaki prosedür kodundaki hareket sayısı daha fazla olacaktır.
Fonksiyonlar (prosedürler) olmadan kod yazabilirsiniz. Ancak zamanla, kodlama "betonla dökme" yoluyla yazılmayı bıraktı, ancak "tuğlalardan" inşa edilmeye başlandı. Prosedürel programlamanın geldiği yer burasıdır.
OOP, genel çalışmayı daha basit bileşenlere ayırmanın bir başka adımıdır.
İşbölümü ve sonuç olarak, bir şeyin üretiminin taşınması, insanlığın sanayileşmesini gerektiren sanayi devrimini yarattı.
El yapımı "prosedürsüz kod yazmaktır".
Bir boru hattı, boru hattının birçok öğesinin geri kalanına bağlı olduğu "yordamsal kodlama"dır. Onlar. bir öğeyi değiştirmek, başka bir öğeyi değiştirmeyi gerektirebilir.
"OOP programlama", öğeler arasında azaltılmış bir bağımlılık boru hattıdır. Onlar. bir eleman diğeriyle değiştirilebilir ve boru hattının başarısız olma olasılığı daha düşüktür. Herhangi bir üretimi bağımsız parçalara ayırma, standartların getirilmesi vb. Nesneye Yönelik Üretimdir (programlama değil).
Programlamanın kendisi özel bir üretim durumudur. OOP yaklaşımı, herhangi bir şey üretmeye yönelik ilkeli bir yaklaşımdır. Bu nedenle, programlama hakkında konuşmak çok dar. OOP, programlamada görünmeden ÖNCE başarıyla uygulandı.
Kazanlarla aldım. Bir peri masalı buldum ve kendime inandım) Noel Baba'daki bir çocuk gibi, golly)
Evet, seni kıskanıyorum, Lech!
Oldukça ciddi. Pekala, bana biraz sanatsal abartma hakkı bırakın ...
Verilen prosedürdeki vücut hareketlerinin sayısı ...
Ö ! İyi dedin.
tamamen destekliyorum.
Değişiklik yapılması gerekiyorsa, yukarıdaki prosedür kodundaki hareket sayısı daha fazla olacaktır.
Evet, OOP ile yapılan hareketlerin sayısı prensipte daha az olamaz, çünkü tüm bu arayüzler genellikle mantığın kendisini yazma maliyetlerini aşan ek genel masraflardır. Ve bu, herhangi bir işlevin zaten bir arayüze sahip olmasına rağmen, yani, aslında anlamsız olan bir bahçeyi daha çitle çevirmeniz önerilir.
Aynı zamanda, hem arayüzdeki hem de işlevdeki koddaki herhangi bir değişiklik, biri diğerine bağlı olduğu için çok daha karmaşık hale gelir, yani, olası hata sayısında ve emek yoğunluğunda en azından ikinci dereceden bir artışa sahibiz. ... Açık görünüyor.