Höyükte OOP hakkında konuşun - sayfa 20
Alım-satım fırsatlarını kaçırıyorsunuz:
- Ücretsiz alım-satım 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
Makale yalan söylüyor!
Yazıyı daha okumadım. Büyük olasılıkla, yazarın bu saçmalığı hemen yorumlarda belirtildi.Okuyun, hepsi orada.
Prosedürel kodlamada, kodu yazarken neredeyse her zaman programın mimarisini düşünebilirsiniz. Çünkü esneklik ve özgürlük tamdır
+
Sadece bunun için, özellikle ticarette olduğu gibi hesaplama algoritmaları için OOP'yi unutabilirsiniz...
OOP mitleri hakkında - OOP'nin kalpsiz taraftarları için değil.
" 80'lerin ortalarından beri, OOP hakkında birkaç efsane var. Bunlardan biri , Yeniden Kullanım Efsanesi , OOP'nin geliştirmeyi daha üretken hale getirdiğini söylüyor çünkü mevcut kodu her seferinde yeniden yazmak yerine devralıp genişletmenize izin veriyor. Bir diğeri, analiz, tasarım ve uygulamanın birbirinden sorunsuz bir şekilde aktığını ima eden tasarım hakkındaki Mit, çünkü bunların hepsi nesnelerdir . Elbette, bu efsanelerin hiçbiri bir OOP paradigması olamaz."
Amca, akademik çevrenin çoğu gibi bir teorisyen ve balaboldur. Ve onun bir profesör (başlık uzun süredir şişirilmiş) ve kitap yazarı olması önemli değil.
Bu karmaşık ifadeler uzun süredir ortalıkta dolaşıyor ve yazılım ürünlerinin karmaşıklığındaki üstel büyümeyi tamamen görmezden geliyor. 30-20-10 yıl önce olanlar, mevcut projelerin ölçeği ve karmaşıklığı ile hiçbir şekilde karşılaştırılamaz. Ve hala kum havuzunda oynamayı tercih ediyorlar, onları modellere indirgiyorlar.
Kaynak, ekonomik ve rekabetçi olanlar da dahil olmak üzere birçok gereksinimi olan gerçek bir ürün yapması için onu yetiştirin. Mümkün olan her şeyi başarısızlığa uğratarak, mantığıyla anında birleşecek. Bunun yerine, bir çözüm üretme aşamasında çocukların kaptanlığına bile atılacaklar.
Dünya birçok gümüş mermi denedi, ancak hepsinin kullanılamaz olduğu ortaya çıktı ve uzun süredir hizmet dışı bırakıldı. Karmaşıklıkta sürekli bir artış var, kütüphanelerin büyümesi (ve oop var) ve çerçeveler (ve oop var), bu da karmaşıklığı bir şekilde kontrol etmenize izin veriyor.
Ve karmaşıklığın büyümesinden kaçış yok. Daha da zor olacak, bilgi kalitesi gereksinimlerine ayak uyduramayan okuma yazma bilmeyen geliştiriciler daha da fazla olacak.
Programcıların gitgide azalan kitle düzeyine uygun daha da basit diller bulmak için daha fazla girişim olacak. Gittikçe daha fazla yazılım şirketi kendilerini hiçbir şey olmadan bulacaklar, sadece yanlış teknolojiye inanacaklar ve rekabet yarışını kaybedecekler. Sadece rakipleri ürün sonuçları açısından daha ağır ama daha verimli teknolojiler kullanacaklar.
Uzun zamandır yazılım şirketlerine yatırım yapmak ölümcül bir şeydi. Ölüm oranı ve başarısızlıklar şaşırtıcı ve daha da kötüleşecek.
Niye ya? Evet, çünkü bu bir çok ekonomik gereksinimi olan bir iş ve bir teknisyen değil. Canlı ve ayakta duran bir yazılım şirketinin yüzde 80'i pazarlama ve satıştan oluşur. Ve yanlış seçilmiş bir teknoloji (ve burada çoğunluğun iddia edilen basitliğe göre önceliği vardır) sonraki satışları kolayca öldürür. Çünkü her zaman daha zor yoldan giden ve finalde daha iyi sonuçlar elde eden yarışmacılar vardır.
Şimdi yüz binlerce satıra kadar mikro projeler hakkında. Bu, bir kişinin kafasına sığma ve ondaki kontrol yanılsamasını sürdürme şansı olduğu için her şeyi yapmanıza izin verir. Ölçeklemeye çalışırken - acı, hayal kırıklığı ve ölüm.
Bulgular:
Ticaret, otomatik ticaret sistemleri ve ticaret stratejilerinin test edilmesi hakkında forum
Höyükte OOP hakkında konuşun
Renat Fatkhullin , 2018.01.17 09:17
Amca, akademik çevrenin çoğu gibi bir teorisyen ve balaboldur. Ve onun bir profesör (başlık uzun süredir şişirilmiş) ve kitap yazarı olması önemli değil.
Bu karmaşık ifadeler uzun süredir ortalıkta dolaşıyor ve yazılım ürünlerinin karmaşıklığındaki üstel büyümeyi tamamen görmezden geliyor. 30-20-10 yıl önce olanlar, mevcut projelerin ölçeği ve karmaşıklığı ile hiçbir şekilde karşılaştırılamaz. Ve hala kum havuzunda oynamayı tercih ediyorlar, onları modellere indirgiyorlar.
Kaynak, ekonomik ve rekabetçi olanlar da dahil olmak üzere birçok gereksinimi olan gerçek bir ürün yapması için onu yetiştirin. Mümkün olan her şeyi başarısızlığa uğratarak, mantığıyla anında birleşecek. Bunun yerine, bir çözüm üretme aşamasında çocukların kaptanlığına bile atılacaklar.
Dünya birçok gümüş mermi denedi, ancak hepsinin kullanılamaz olduğu ve uzun süredir hizmet dışı bırakıldığı ortaya çıktı. Karmaşıklıkta sürekli bir artış var, kütüphanelerin büyümesi (ve oop var) ve çerçeveler (ve oop var), bu da karmaşıklığı bir şekilde kontrol etmenize izin veriyor.
Ve karmaşıklığın büyümesinden kaçış yok. Daha da zor olacak, bilgi kalitesi gereksinimlerine ayak uyduramayan okuma yazma bilmeyen geliştiriciler daha da fazla olacak.
Programcıların gitgide azalan kitle düzeyine uygun daha da basit diller bulmak için daha fazla girişim olacak. Gittikçe daha fazla yazılım şirketi kendilerini hiçbir şey olmadan bulacaklar, sadece yanlış teknolojiye inanacaklar ve rekabet yarışını kaybedecekler. Sadece rakipleri ürün sonuçları açısından daha ağır ama daha verimli teknolojiler kullanacaklar.
Uzun zamandır yazılım şirketlerine yatırım yapmak ölümcül bir şeydi. Ölüm ve başarısızlıklar şaşırtıcı ve daha da kötüleşecek.
Niye ya? Evet, çünkü bu bir çok ekonomik gereksinimi olan bir iş ve bir teknisyen değil. Canlı ve ayakta duran bir yazılım şirketinin yüzde 80'i pazarlama ve satıştan oluşur. Ve yanlış seçilmiş bir teknoloji (ve burada çoğunluğun iddia edilen basitliğe göre önceliği vardır) sonraki satışları kolayca öldürür. Çünkü her zaman daha zor yoldan giden ve finalde daha iyi sonuçlar elde eden yarışmacılar vardır.
Şimdi yüz binlerce satıra kadar mikro projeler hakkında. Bu, bir kişinin kafasına sığma ve ondaki kontrol yanılsamasını sürdürme şansı olduğu için her şeyi yapmanıza izin verir. Ölçeklemeye çalışırken - acı, hayal kırıklığı ve ölüm.
Bulgular:
Ayın, belki de yılın en iyi gönderisi! Renat, neden sen ya da şirketin Habre üzerine yazılar yazmıyorsunuz ( şirket orada kayıtlı bile değil! )? Çok şey söyleyebilirsiniz, ancak deneyiminiz yalnızca gönderilerin küçük bölümlerinde öğrenilebilir. Cidden, çok güncel ve kesinlikle ortaya çıktı. Gönderiye örnek olarak: https://habrahabr.ru/post/344356/
Ayın, hatta belki de yılın en iyi gönderisi!
OOP konusu bağlamında bu yazıda özellikle neyi çok beğendiniz? Her durumda ticari şeyler hakkında genelleme yapmak muhtemelen tamamen doğru değil, sonuçta yatırımcılar aptal değil ve uzmanlarını projelerin riskini değerlendirmek için dahil ediyorlar ...
Bu makalede, hala bir profesör yok, tartışma için yeterli karşı argümanların sunulmadığı belirli mantıksal argümanlar var ..
Programlama kolaylığının projeler için her zaman kötü bir şey olmadığı da aşikar...
Ayın, belki de yılın en iyi gönderisi! Renat, neden sen ya da şirketin Habre üzerine yazılar yazmıyorsunuz ( şirket orada kayıtlı bile değil! )? Çok şey söyleyebilirsiniz, ancak deneyiminiz yalnızca gönderilerin küçük bölümlerinde öğrenilebilir. Cidden, çok güncel ve kesinlikle ortaya çıktı. Gönderiye örnek olarak: https://habrahabr.ru/post/344356/
Milyonlarca için çalışıyoruz ve Habré hakkındaki makalelerin genellikle kazandığı 1.000 - 5.000 okuyucu / görüş için değil.
Endüstri standardı haline getirdik ve tüm dünyayı etkileyen çözümler sunuyoruz. Neden bir çeşit Habr'a ihtiyacımız var ve hatta Rus segmentinin dar bir nişine sıkıştırılmış durumda.
OOP konusu bağlamında bu yazıda özellikle neyi çok beğendiniz? Tüm durumlar için ticari şeyler hakkında genelleme yapmak muhtemelen tamamen doğru değildir, sonuçta yatırımcılar aptal değildir ve proje riskini değerlendirmek için uzmanlarını çeker ...
Bu makalede, hala bir profesör yok, tartışma için yeterli karşı argümanların sunulmadığı belirli mantıksal argümanlar var ..
Programlama kolaylığının projeler için her zaman kötü bir şey olmadığı da aşikar...
Amatörce şakaları bırakın lütfen.
Teknik okuma yazma bilmediğiniz için yasaklanacaksınız. Forumumuzda militan cahillere ihtiyacımız yok.
...
Programlama kolaylığının projeler için her zaman kötü bir şey olmadığı da aşikar...
Bir aksiyom var: karmaşıklık hiçbir yerde kaybolmaz . Bu nedenle, kullanıcı için "programlamanın basitliği", karmaşıklığın derleyiciye kaydırılmasıdır. Karmaşıklık, derleyici tarafından perde arkasında işlenir ve o, derleyici, programcının herhangi bir sapkınlığını "en azından bir şekilde çalışmasına izin vermek hiç olmamasından daha iyidir" ilkesine göre zaten gizlemeye çalışıyor. " Proje sahibi artık programcı değil, derleyicidir. Kodu geliştirmek ve sürdürmek imkansız hale geliyor, çünkü artık ne olduğu net değil (derleyici bir şekilde toplar, tamam, tamam).
Ticaret, otomatik ticaret sistemleri ve ticaret stratejilerinin test edilmesi hakkında forum
Höyükte OOP hakkında konuşun
Renat Fatkhullin , 2018.01.17 09:17
...
Ve karmaşıklığın büyümesinden kaçış yok. Daha da zor olacak, bilgi kalitesi gereksinimlerine ayak uyduramayan okuma yazma bilmeyen geliştiriciler daha da fazla olacak.
Gittikçe azalan programcı kitle düzeyine uygun daha da basit diller bulmak için daha fazla girişim olacak. Gittikçe daha fazla yazılım şirketi kendilerini hiçbir şey olmadan bulacaklar, sadece yanlış teknolojiye inanacaklar ve rekabet yarışını kaybedecekler. Sadece rakipleri ürün sonuçları açısından daha ağır ama daha etkili teknolojiler kullanacaklar.
...
Amatörce şakaları bırakın lütfen.
Teknik okuma yazma bilmediğiniz için yasaklanacaksınız. Forumumuzda militan cahillere ihtiyacımız yok.