OOP vs prosedürel programlama - sayfa 36
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
1. Ne kadar değil. Karlılık OOP'ye bağlı değildir.
2. Bence, büyüklük sırasına göre (on kez). Ancak OOP'nin ana yararı kod bakımıdır. Şimdi bir yıl veya daha önce yazdığım kodu çok çabuk anlıyorum. İlk ANSI C programlarımı nasıl anladığımı çok iyi hatırlıyorum - tamamen prosedürel bir tarzda. Çok daha zordu.
1. Bu, OOP ihtiyacına verilen ana cevaptır.
2. Bu bir ekip deneyimi meselesidir. 2008-2009'da ihtiyacınız olan her şeyi yazdım. Birkaç yıl önce daha fazla yazmaya karar verdim - her şey okunabilir, sorun yok.
Cevaplarınızdan bir şeyi anladım: OOP, bir programlama disiplini tanıtan, tekdüzelik getiren bir tür standarttır ve bu temelde başlangıçta daha az hata vardır ve en önemlisi ve en önemlisi, değişiklik sırasındaki sorunlar temelde azalır. Ancak aynı sonuç, GOST'lerin, geliştirme aşamalarının, belgelerin dikkatle gözlenmesiyle elde edildi.
İşimde neden HİÇ böyle bir şey görmediğimi anlayamıyorum. Çok büyük olmayan bir programda BİR geliştiricide değişkenlere erişimin farklılaşması sorunları nereden geliyor? Her biri 100 özellik yazan 100 geliştirici olacaktır. Teorik olarak, olabilir. Ama pratikte, programlama neredeyse 40 yıldır OOP'a dönüştü, dağlarca kod yazıldı ve ben hiç böyle bir şey duymadım.
Yani başlangıçta programlar kodlarla yazıldı.
OOP, daha karmaşık programları daha hızlı yazmanıza ve ardından bunları daha verimli bir şekilde korumanıza izin veren bir teknolojidir.
Ancak bu, OOP'nin tüm hastalıklar için her derde deva olduğu anlamına gelmez. Diyorum ki - Peter'ınki gibi bir hafızanız varsa, o zaman hiçbir şey için OOP'ye ihtiyacınız yok - her şeyi küresel olarak ilan edin ve hepsi bu, çünkü tüm bunları hatırlıyorsunuz ve çarpışmalara veya değişkenlerin karışıklığına kolayca izin vermeyeceksiniz. . Ama hafızam çok daha kötü. Ve ayrım - çok yaygın olarak kullanıyorum. Son yıllarda - const değiştirici çok takdir edildi - nadiren kullanırdı. Şimdi - sık sık. Sadece ihtiyacım olana erişimim olması için değil, daha fazlası değil. Böylece, bu erişim, değiştirilmek istenmediği durumlarda salt okunurdur.
George Merts :
Evet, gerçekten de, Aniden gerekli verileri elde etmenin neredeyse imkansız olduğu ortaya çıkan durumlar var. Birkaç sanal arabirimin arkasına gizlenirler. Ancak bu durum, sistemin orijinal olarak yanlış tasarlandığını, bu verilerin transferini sağlamadığını açıkça göstermektedir. Bu durum gerçekten çok kötü. Kişi ya aceleyle "koltuk değneklerini" ek arayüzler şeklinde şekillendirmeli ya da tüm sistemi basitçe yeniden yapılandırmalıdır. Bu, programcıyı sistemin mimarisi hakkında daha dikkatli düşünmeye motive eder.
Bir programcı, ana fikri uygulamak için tüm olası seçenekler için gerekli veri yapısını önceden ve tüm ayrıntılarıyla gören bir kahin ve bir kahin ise, muhtemelen sizin yolunuzu takip etmesi mantıklıdır. Veya son aşamada, her şey zaten çalışıyorken ve bu eklentiler kullanılmadan kod hata ayıklanırken, ancak daha sonra hiçbir şeyi değiştirmenize veya yeniden çizmenize gerek kalmaması koşuluyla yapın ...
1. Bu, OOP ihtiyacına verilen ana cevaptır.
2. Bu bir ekip deneyimi meselesidir. 2008-2009'da ihtiyacınız olan her şeyi yazdım. Birkaç yıl önce daha fazla yazmaya karar verdim - her şey okunabilir, sorun yok.
Cevaplarınızdan bir şeyi anladım: OOP, bir programlama disiplini tanıtan, tekdüzelik getiren bir tür standarttır ve bu temelde başlangıçta daha az hata vardır ve en önemlisi ve en önemlisi, değişiklik sırasındaki sorunlar temelde azalır. Ancak aynı sonuç, GOST'lerin, geliştirme aşamalarının, belgelerin dikkatle gözlenmesiyle elde edildi.
1. Hayır. OOP bir karlılık aracı değildir. Ve karlılığa bakarak OOP ihtiyacından bahsetmek imkansız. OOP, kodun geliştirilmesini ve bakımını basitleştiren bir araçtır.
2. On yaşında bir aracın hala çalışıyor olması harika. Böyle yaşayamam, benim için düzenli olarak çalışmayı bırakırlar, sürekli onları değiştirmek zorunda kalıyorum. Ve OOP - bu bana çok yardımcı oluyor.
Ve OOP hakkında, belirli bir standart, evet, bu doğru. Ve evreleme ve belgelere uyulursa aynı sonucun alınabileceği doğrudur. Ama bana öyle geliyor ki, OOP durumundan daha fazla çaba harcanıyor.
Yani başlangıçta programlar kodlarla yazıldı.
OOP, daha karmaşık programları daha hızlı yazmanıza ve ardından bunları daha verimli bir şekilde korumanıza izin veren bir teknolojidir.
Ancak bu, OOP'nin tüm hastalıklar için her derde deva olduğu anlamına gelmez. Diyorum ki - Peter'ınki gibi bir hafızanız varsa, o zaman hiçbir şey için OOP'ye ihtiyacınız yok - her şeyi küresel olarak ilan edin ve hepsi bu, çünkü tüm bunları hatırlıyorsunuz ve çarpışmalara veya değişkenlerin karışıklığına kolayca izin vermeyeceksiniz. . Ama hafızam çok daha kötü. Ve ayrım - çok yaygın olarak kullanıyorum. Son yıllarda - const değiştirici çok takdir edildi - nadiren kullanırdı. Şimdi - sık sık. Sadece ihtiyacım olana erişimim olması için değil, daha fazlası değil. Böylece, bu erişim, değiştirilmek istenmediği durumlarda salt okunurdur.
Yani başlangıçta programlar kodlarla yazıldı.
Aşırıya kaçmayalım, tamam mı?
OOP, daha karmaşık programları daha hızlı yazmanıza ve ardından bunları daha verimli bir şekilde korumanıza izin veren bir teknolojidir.
Bu çok, çok şüpheli.
İyi proje belgelerine sahip programlar daha hızlı yazılır ve verimli bir şekilde korunur. Bu sorunun yankıları, REFERANS ŞARTLARINA çok dikkat edilen piyasada bulunabilir. TK berbatsa, hiçbir OOP yardımcı olmaz.
İyi proje belgelerine sahip programlar daha hızlı yazılır ve verimli bir şekilde korunur. Bu sorunun yankıları, TEKNİK GÖREVE çok dikkat edilen piyasada bulunabilir. TK berbatsa, hiçbir OOP yardımcı olmaz.
Bir programcı, ana fikri uygulamak için tüm olası seçenekler için gerekli veri yapısını önceden ve tüm ayrıntılarıyla gören bir kahin ve bir kahin ise, muhtemelen sizin yolunuzu takip etmesi mantıklıdır. Veya son aşamada, her şey zaten çalışıyorken ve bu eklentiler kullanılmadan kod hata ayıklandığında, ancak daha sonra hiçbir şeyi değiştirmenize veya yeniden çizmenize gerek kalmaması koşuluyla yapın...
OOP, daha karmaşık programları daha hızlı yazmanıza ve ardından bunları daha verimli bir şekilde korumanıza izin veren bir teknolojidir.
Yukarıda açıklandığı gibi, OOP, birçok ek paketleyiciler, ara eklentiler ve adaptörler nedeniyle başlangıçta kodun hızlı yazılması ve hatalarının giderilmesi için tasarlanmamıştır ... Her şey zaten çalıştığında ve hata ayıklandığında ve veriler yalnızca son aşamada anlamlıdır. yapı bitmiş bir görünüm kazandı .. Yani, bu, sonraki depolama için bitmiş kodu paketlemek için tamamen kozmetik bir prosedürdür ...
Ama benim için başka bir şey daha önemli - Igor yukarıda doğru bir şekilde söyledi - her sınıf sadece kendi değişkenlerinden sorumludur, ondan başkalarına "uymak" imkansızdır. Sonuç olarak, sorunların çoğu derleme aşamasında kesilir.
Bir sınıfın sadece iç değişkenleri vardır ve hiçbir girdisi veya çıktısı yoktur... Dış dünyayla teması olmayan, kendi suyunda kaynayan böyle bir nesnenin programlanmasındaki kullanımını nerede gördünüz?
.... Modern programlar pratik olarak belgelemeye ihtiyaç duymaz - her şey sınıf arayüzlerinde açıkça sunulur.
Bunu meta alıntılara açıklayın: neden terminalde, dilde ve genel olarak yazılım ürünleri için belge dağlarının nereden geldiğini, örneğin Cpp'de büyük kılavuzlar yazdılar. Ve genel olarak, yazılım ürünleri var mı? belge olmadan? Bunu fark etmemeniz çok garip.