OOP vs prosedürel programlama - sayfa 26
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
Evet, düşünecek bir şey yok.
OOP, kontrollerin ve onayların büyük bir kısmını derleyiciye kaydırmanıza izin veren bir mekanizmadır. Ancak, onu kullanmak ekstra çaba gerektirir.
Ama tüm bu kontrollere ve onaylara ihtiyacımız yoksa OOP'nin bir anlamı yok.
Diyelim ki, çok boyutlu bir grafik çekirdeği dizisiyle çalışmaktan korktum - çünkü şu anda ihtiyaç duyulmayan çok fazla ekstra varlığa sahip. Dikkat dağıtırlar ve hesaplanması zor hatalara neden olurlar. Basit kompakt arayüzler tarafından erişilebilecek bir dizi nesneyle değiştirirdim. Arayüzü aldıktan sonra - hiçbir şey hatırlamama gerek yok - arayüzün kendisi beni sınırlandırıyor ve örneğin yanlış alana veya nesneye başvurmama izin vermiyor. Bir dizi grafik çekirdeği durumunda, böyle bir çekicilik çok olasıdır.
Yani, blok bir arayüz aldığında, derleyicinin kendisi gereksiz tüm varlıkları "keser" ve kullanıcının hata yapmasına izin vermez. Aynı grafik çekirdeğinden oluşan bir dizi ile - kullanıcı, kolayca hata yapabileceğiniz bir sürü ekstra bilgiye sahiptir.
Kendi deneyimlerimden biliyorum ki, derleyicinin kendisi beni izlediğinde, mevcut bloktan sığmamam gereken yere sığmamam benim için çok daha iyi. Ve grafik çekirdek dizisiyle - bunu hatırlamam gerekiyor. Sistemimin eksisi, artının devamıdır. Blokta aniden mevcut görevin kapsamı dışında bir şeye ihtiyaç duyulursa, grafik çekirdeği dizisi ile her şey basittir - gerekli verileri alır ve onunla çalışırız. Ancak OOP arayüzleri ile, ya ek bir arayüzde gerekli verileri talep etmeniz veya (ki bu çok daha tatsız) mevcut arayüzü değiştirmeniz gerekecektir.
Evet, düşünecek bir şey yok.
OOP, kontrollerin ve onayların büyük bir kısmını derleyiciye kaydırmanıza izin veren bir mekanizmadır. Ancak, onu kullanmak ekstra çaba gerektirir.
Ama tüm bu kontrollere ve onaylara ihtiyacımız yoksa OOP'nin bir anlamı yok.
Öyleyse neden bu kadar kolay olsun. Görünürlük ve okunabilirlik ne durumda? Ve hataların tespiti ve düzeltilmesinin basitleştirilmesi? Peki ya taşınabilirlik? Ve modernleşmenin basitleştirilmesi? vb. vb. ....
O halde tema kulağa farklı gelmeli. Şuna benzer bir şey: "Programlamada yeni araçlar" veya "Yeni programlama paradigması"...
OOP'den daha havalı bir şey yarattığın doğruysa, ünlü olduğunda seninkini imzalayacak mısın?
Sorun yok! Arkadaşlar için imza üzücü değil.))))
Şaka yapıyorsun ama benim hayalimde "anne ağlama" yaklaşımıyla böyle bakış açıları çiziliyor. Görünüşe göre zamanla sistemin kendini geliştirme mekanizmasını başlatabileceğim. Mantıksal bir çekirdek oluşturur ve onu rastgele çeşitli mekanizmalar oluşturmaya zorlarsanız. Ardından seçimi yapın ve doğru olanları seçin. Sonra onları biraz parlatın... çekirdek sayesinde inanılmaz şeyler yapabilirsiniz.
Öyleyse neden bu kadar kolay olsun. Görünürlük ve okunabilirlik ne durumda? Ve hataların tespiti ve düzeltilmesinin basitleştirilmesi? Peki ya taşınabilirlik? Ve modernleşmenin basitleştirilmesi? vb. vb. ....
asil reklam afişi :-) "fillerimizi satın alın"
yukarıdaki tüm tezler, OOP ve OOP ve FP ile değil ve genel olarak herhangi bir yerde OOP ile eşit derecede ilgilidir.
Evet, düşünecek bir şey yok.
OOP, kontrollerin ve onayların büyük bir kısmını derleyiciye kaydırmanıza izin veren bir mekanizmadır. Ancak, onu kullanmak ekstra çaba gerektirir.
Ama tüm bu kontrollere ve onaylara ihtiyacımız yoksa OOP'nin bir anlamı yok.
Diyelim ki, çok boyutlu bir grafik çekirdeği dizisiyle çalışmaktan korktum - çünkü şu anda ihtiyaç duyulmayan çok fazla ekstra varlığa sahip. Dikkat dağıtırlar ve hesaplanması zor hatalara neden olurlar. Basit kompakt arayüzler tarafından erişilebilecek bir dizi nesneyle değiştirirdim. Arayüzü aldıktan sonra - hiçbir şey hatırlamama gerek yok - arayüzün kendisi beni sınırlandırıyor ve örneğin yanlış alana veya nesneye başvurmama izin vermiyor. Bir dizi grafik çekirdeği durumunda, böyle bir çekicilik çok olasıdır.
Yani, blok bir arayüz aldığında, derleyicinin kendisi gereksiz tüm varlıkları "keser" ve kullanıcının hata yapmasına izin vermez. Aynı grafik çekirdeğinden oluşan bir dizi ile - kullanıcı, kolayca hata yapabileceğiniz bir sürü ekstra bilgiye sahiptir.
Kendi deneyimlerimden biliyorum ki, derleyicinin kendisi beni izlediğinde, mevcut bloktan sığmamam gereken yere sığmamam benim için çok daha iyi. Ve grafik çekirdek dizisiyle - bunu hatırlamam gerekiyor. Sistemimin eksisi, artının devamıdır. Blokta aniden mevcut görevin kapsamı dışında bir şeye ihtiyaç duyulursa, grafik çekirdeği dizisi ile her şey basittir - gerekli verileri alır ve onunla çalışırız. Ancak OOP arayüzleri ile, ya ek bir arayüzde gerekli verileri talep etmeniz veya (ki bu çok daha tatsız) mevcut arayüzü değiştirmeniz gerekecektir.
Çekirdekte gereksiz bir şey olduğunu düşünmekle tamamen yanılıyorsunuz. Ve özlerini ezberlemek çok kolaydır, çünkü tanımlar aracılığıyla insan sözcükleri giydirilirler. Her şey orada toplanır ama bu içeriğin açık ve değişmez bir düzeni vardır. Nesnelerin, pencerelerin, öğelerin özelliklerine programın herhangi bir noktasından doğrudan erişilebilir. Ve döngülerdeki çekirdek sayesinde ne gibi mucizeler yapılabilir...
Çekirdekte gereksiz bir şey olduğunu düşünmekle tamamen yanılıyorsunuz. Ve özlerini ezberlemek çok kolaydır, çünkü tanımlar aracılığıyla insan sözcükleri giydirilirler. Her şey orada toplanır ama bu içeriğin açık ve değişmez bir düzeni vardır. Nesnelerin, pencerelerin, öğelerin özelliklerine programın herhangi bir noktasından doğrudan erişilebilir. Ve döngülerdeki çekirdek sayesinde ne gibi mucizeler yapılabilir...
"Çekirdekte gereksiz bir şey var" demedim, "şu anda gereksiz" dedim. Bir grafik çizgisiyle çalışıyorsam, pencere özelliklerine erişemem.
Tüm bu özelliklere programın herhangi bir noktasında doğrudan erişilebilir olması, yaklaşımınızın ana dezavantajıdır. Programın herhangi bir yerinde, yalnızca şu anda bu belirli yerde ihtiyaç duyulan öğelere erişim olmalıdır. Diğer her şey kullanılamaz olmalıdır. Bu, birçok hatayı otomatik olarak önlemenizi sağlar.
Tüm "çekirdeğin kullanılabilirliği nedeniyle yapılabilecek tüm mucizeler", bence, bulunması zor hatalar ve kod anlama sorunları için potansiyel bir kaynaktır. Tüm bu hilelerden kaçınmaya çalışmalıyız.
Bu yaklaşım bana, işaretçiler, artışlar, bağlantılar vahşi bir karışımda bir satırda yazıldığında, belki de dil açısından doğru, ancak tamamen okunamayan aptal bulmacaları hatırlatıyor. Evet yukarıda kendi fonksiyonumu verdim, bu da tamamen çılgınca görünüyor, sadece bu durumda kompaktlığın daha önemli olduğunu düşündüm.
Öyleyse neden bu kadar kolay olsun. Görünürlük ve okunabilirlik ne durumda? Ve hataların tespiti ve düzeltilmesinin basitleştirilmesi? Peki ya taşınabilirlik? Ve modernleşmenin basitleştirilmesi? vb. vb. ....
Fantezi!
1. OOP'den önce, her şeyi işe yaramaz bileşenlerden son derece karmaşık araçlarla oluşturduk.
2. OOP'den önce, programlar son derece iyi harmanlanmış kompostolardı
3. OOP'den önce, veri ve kodun yerelleştirilmesi hakkında bir şey duymadık ve bu dehşetten bakım sırasında nasıl acı çektiğimizi
4. Aynı programın farklı bölümleri arasındaki verileri korumak sadece pipetlerdir!
5. OOP'den önce hiç kimse sistemleri genişletmedi.
Sadece tam bir çıkış.
Burada oturuyorum ve bu OOP'nin benden büyümüş olabileceğini düşünüyorum, çünkü tüm bunları 70'lerin sonlarında ve programlama kültürüyle ilgili çok daha fazlasını kullandım.
"Çekirdekte gereksiz bir şey var" demedim, "şu anda gereksiz" dedim. Bir grafik çizgisiyle çalışıyorsam, pencere özelliklerine erişemem.
Tüm bu özelliklere programın herhangi bir noktasında doğrudan erişilebilir olması, yaklaşımınızın ana dezavantajıdır. Programın herhangi bir yerinde, yalnızca şu anda bu belirli yerde ihtiyaç duyulan öğelere erişim olmalıdır. Diğer her şey kullanılamaz olmalıdır. Bu, birçok hatayı otomatik olarak önlemenizi sağlar.
Tüm "çekirdeğin kullanılabilirliği nedeniyle yapılabilecek tüm mucizeler", bence, bulunması zor hatalar ve kod anlama sorunları için potansiyel bir kaynaktır. Tüm bu hilelerden kaçınmaya çalışmalıyız.
Bu yaklaşım bana, işaretçiler, artışlar, bağlantılar vahşi bir karışımda bir satırda yazıldığında, belki de dil açısından doğru, ancak tamamen okunamayan aptal bulmacaları hatırlatıyor. Evet yukarıda kendi fonksiyonumu verdim, bu da tamamen çılgınca görünüyor, sadece bu durumda kompaktlığın daha önemli olduğunu düşündüm.
Bahsettiğiniz teknoloji ile ilgili olmayan, deneyiminize dayanan anlık teorik fikirlere dayalı çekirdek hakkında konuşuyorsunuz. Dolayısıyla erişim, varlıkların ezberlenmesi ile ilgili bazı sorunlar var ...
Bu teknolojiyle ilgili pratik deneyime dayanarak tartışıyorum ve erişim veya kısıtlama ile ilgili böyle bir sorun olmadığını söylüyorum. Dürüst olmak gerekirse, ne tür erişim sorunlarından bahsettiğinizi anlamıyorum. Böyle bir sorun yoktur ve olmamıştır.
Bize hangi erişim sorunlarını kastettiğiniz hakkında daha fazla bilgi verin.
Neden erişimin sınırlandırılması gerektiğine karar verdiniz, aksi takdirde hatalara neden olur? Benim için bu yeni bir şey.
Prosedürel koddaki global diziye doğrudan erişim, kendi içinde bulması zor hatalara neden olabilir mi?
Bahsettiğiniz teknoloji ile ilgili olmayan, deneyiminize dayanan anlık teorik fikirlere dayalı çekirdek hakkında konuşuyorsunuz. Buradan erişim, varlıkların ezberlenmesi ile ilgili bazı sorunlar var ...
Bu teknolojiyle ilgili pratik deneyime dayanarak tartışıyorum ve erişim veya kısıtlama ile ilgili böyle bir sorun olmadığını söylüyorum. Dürüst olmak gerekirse, ne tür erişim sorunlarından bahsettiğinizi anlamıyorum. Böyle bir sorun yoktur ve olmamıştır.
Ama "her şey her yerden temin edilebilir" dersen nasıl "hiçbir sorun olmaz"?
Asıl sorun bu! mevcut olmamalıdır!
Sonuç olarak, erişim denetimi görevini derleyiciye kaydırmak yeterlidir. Ve siz - her şey açık ve erişim kontrolü programcı tarafından gerçekleştirilir.
Zorluk yoktu çünkü her şeyi hatırlıyorsun. Zaten alışmıştı. Hiçbir şey, zamanla belleğin bozulmaya başladığını göreceksiniz - o zaman derleyicinin erişim kontrol yeteneklerini değerlendireceksiniz. İşte hatırlamıyorum. Ayrıca, çoğunluğun aylar önce yazılanların nasıl çalıştığını da periyodik olarak unuttuğundan şüpheleniyorum. Bu koşullar altında erişim kontrolü bir nimet haline gelir.
Diyelim ki, sipariş vermekten sorumlu blok içindeyseniz, yalnızca sipariş verebilirsiniz. Ve bir grafik çizme yeteneğiniz yok. Grafiği çizmekten sorumlu bloktaysanız, oradan sipariş veremezsiniz. Bu, işi büyük ölçüde basitleştirir. Ve çizelge çizme fonksiyonunda Aniden bir sipariş verme talebi gördüğünüzde, bunu neden yaptığınızı uzun süre hatırlamanız gerekecek. Böyle bir kararın neden verildiğini açıklayan ayrıntılı bir yorum varsa iyi olur... Ama siparişler bu amaç için özel olarak tasarlanmış tek bir blokta verildiğinde daha iyidir.
Ama "her şey her yerden temin edilebilir" dersen nasıl "hiçbir sorun olmaz"?
Asıl sorun bu! mevcut olmamalıdır!
Sonuç olarak, erişim denetimi görevini derleyiciye kaydırmak yeterlidir. Ve siz - her şey açık ve erişim kontrolü programcı tarafından gerçekleştirilir.
Zorluk yoktu çünkü her şeyi hatırlıyorsun. Zaten alışmıştı. Hiçbir şey, zamanla belleğin bozulmaya başladığını göreceksiniz - o zaman derleyicinin erişim kontrol yeteneklerini değerlendireceksiniz. İşte hatırlamıyorum. Ayrıca, çoğunluğun aylar önce yazılanların nasıl çalıştığını da periyodik olarak unuttuğundan şüpheleniyorum. Bu koşullar altında erişim kontrolü bir nimet haline gelir.
Diyelim ki, sipariş vermekten sorumlu blok içindeyseniz, yalnızca sipariş verebilirsiniz. Ve bir grafik çizme yeteneğiniz yok. Grafiği çizmekten sorumlu bloktaysanız, oradan sipariş veremezsiniz. Bu, işi büyük ölçüde basitleştirir. Ve çizelge çizme fonksiyonunda Aniden bir sipariş verme talebi gördüğünüzde, bunu neden yaptığınızı uzun süre hatırlamanız gerekecek. Böyle bir kararın neden verildiğini açıklayan ayrıntılı bir yorum varsa iyi olur... Ama siparişler bu amaç için özel olarak tasarlanmış tek bir blokta verildiğinde daha iyidir.