Benim yaklaşımım. Çekirdek - Motor. - sayfa 18

 
jdjahfkahjf :
Dur tahmin edeyim, OOP hakkında başka bir argüman.

hayır, gündelik programlama hakkında bir tartışma varken, ben tüm konuyu OOP'ye sürüklemek üzereyim, konu başlatıcı hala devam ediyor! her şeyi kafanızda tutabileceğinizi yazıyor - peki, bu sıradan programlama)))

 

çekirdek motor

 
Igor Makanu :

gelişigüzel programlama

Sıradan programlama :)

 
jdjahfkahjf :

Sıradan programlama :)

belki haklısın, böyle bir terimi hatırladım - birkaç ay önce başka bir forumda bir kişi kendine şöyle dedi: gündelik programcı, hatta bunun ne anlama gelebileceğini açıklamaya çalıştım, bildiğim kadarıyla, gündelik kelimesi yalnızca Android oyunu - "Zuma", bunun rastgele programlayan bir programcı olduğunu gördüğünüz ortaya çıktı - durumdan duruma)))

 
Vasiliy Sokolov :

OOP çok esnek bir metodolojidir, bu nedenle "çekirdek" kavramı gibi apriori fikirleri yoktur. Ancak, OOP kullanarak, burada tartışılan çekirdeğin modelini çok iyi oluşturabilirsiniz. Bu nedenle, ifade tamamen doğru değildir.

Hayır, hiç OOP yok. Çekirdek Unix, her şeyi çekirdek etrafında topluyoruz; kabuk - Windows'a benzeyen her şey - gereksiz olanı kaldırırız, geri kalanıyla çalışırız. Genel olarak, bu işletim sistemi ile ilgilidir.

 
jdjahfkahjf :

Sıradan programlama :)

Rahat, endişelenme.

 
Реter Konow :

Kod yazmanın katı formatı beni OOP'ta itiyor. Gördüğünüz gibi, büyük veri tabloları oluşturma eğilimindeyim ve bunu çok pratik buluyorum. OOP'de, kişisel olarak beni çok fazla kısıtlayan bir dizi kurala uymak zorundayım.

Kısacası, farklı bir OOP ile programlama yapıyorum. Onun. Birkaç kural ve çok fazla özgürlük var. İşlevselliğin kendisi büyük bloklar halinde oluşturulur ve veriler çekirdeklerde düzenlenir. Yapılarını kasten düşünmüyorum bile. Her şey kendi kendine gelişir. Sezgisel düzeyde.

Peter, bu kurallar senin ihtiyacın olan şey. Tam da sizi "zincirlemek" için. Böylece yanlışlıkla hiçbir şeyi bozmazsınız ve olmaması gereken bir yere sığmazsınız. Aslında, OOP tarzı "yolun kurallarıdır" - elbette sürücüyü kısıtlarlar. Ve üç yardalı bir köyde - kimse onlara bakmaz, daha kolay ve daha hızlıdır (daha verimli). Ancak, büyük bir şehirde bunun tersi doğrudur - en verimli ulaşım iletişimini mümkün kılan trafik kurallarıdır. OOP ile aynı. Bunlar, büyük karmaşık sistemleri en verimli şekilde oluşturmanıza izin veren kurallardır.

Sisteminiz - sadece henüz herhangi bir değişiklik olmadı, çok sınırlı bir şekilde kullanılıyor ve değiştirilmesi gerekmiyor. Bu yüzden kafanızda tutabilirsiniz. Hiçbir şey, eğer sistem kullanıcıları olacaksa ve iyileştirmeler gerekiyorsa - kontrol ve kapsülleme eksikliği - çok stresli olacaktır.

Diğer her şey - fark yok, OOP ve stiliniz (daha önce de belirtildiği gibi, prosedür stiliniz de aynı dezavantajlardan muzdarip - global değişkenler , tip kontrolünün olmaması vb.) Aksi takdirde yakındır.

Tarzınızı savunmak için kanıtlamanız gereken tek şey, tüm sistemi büyük bir küresel rastgele erişim dizisinde tutmanın, programı polimorfik kalıtım zincirlerinde yuvalanmış ve kapsülleme ile gizlenmiş bir grup küçük parçaya bölmekten daha iyi olduğudur.

Bu arada, forumda mirası sevmeyen insanlar var - sanırım size destek olabilirler.

 

Peter'ın yönteminin aksine OOP kullanmanın bir başka avantajı. OOP'de programcı, temel sınıfın kaynak koduna ihtiyaç duymaz ve nasıl çalıştığını anlaması gerekmez. Temel sınıfın işlevselliğini genişletmek veya değiştirmek için bu sınıfın bir mirasçısını oluşturmak yeterlidir.

Peter'ın yöntemini kullanırsanız, programcının uzun kod ayak örtüsünün tamamını anlaması gerekecek ve bu kod için kaynak kodu yoksa, tekrar yazılması gerekecektir.

 
Georgiy Merts :

Diğer her şey - fark yok, OOP ve stiliniz (daha önce de belirtildiği gibi, prosedür stiliniz de aynı dezavantajlardan muzdarip - global değişkenler , tip kontrolünün olmaması vb.) Aksi takdirde yakındır.

Tabii ki, yanılıyor olabilirim ve google için çok tembelim, ancak prosedür stili, prosedürün (işlev) mantıksal eksiksizliğini ima ediyor - kaynaktan “çıkarıldı” ve başka bir kodda kullanın, yani. yerleşik MQL işlevlerinin verileri nasıl parametre olarak alıp sonucu döndürdüğü .... ve burada Peter için her iki pençede de her şey topal ))) - küresel olarak bildirilen değişkenler aracılığıyla yapılan alışveriş, kodun taşınabilirliğini azaltır ve görünümüne izin verir. izlemesi zor hatalar ;)

 

İyi. Bırak ikna olayım.

  1. OOP, bir programcı ekibinin büyük bir proje üzerinde çalışması için gereklidir.
  2. OOP programı düzenler ve yapılandırır.
  3. OOP, programlama olanaklarını genişletmek için birçok araç sağlar.

Prensip olarak, tüm bunları uzun zamandır anlıyorum. Ve buna katılıyorum. Ancak aynı zamanda yaklaşımımı tercih ederim. Niye ya?

Belirli bir nedeni var:

PROGRAM GELİŞTİRME.

//--------------------------------------

Program, OOP ve benim yaklaşımımla ne kadar hızlı gelişecek? Mekanizmaların büyümesi ve karmaşıklığı için hangi yaklaşım daha uygundur?

Benim yaklaşımımın + koddaki anadilin (%60 Rusça ve %40 İngilizce) programın en hızlı büyümesini sağladığı sonucuna vardım.

Bu hızlı büyüme tam da ihtiyacım olan şey. Ayrıntılara girme. Her kod satırının üzerine gelmemek. Profesyonel bir yaklaşım değil.

Programın hızla gelişmesine ve daha karmaşık hale gelmesine ihtiyacım vardı. Kendilerine atanan işlevleri uygulayan mekanizmalar oluşturmak. Çabuk ve kolay.

Böylece birkaç satır kodla yeni özellikler ekleyebilirsiniz.

Yaklaşımım, bu özel sorunu çözmede OOP'den daha üstün.