Höyükte OOP hakkında konuşun - sayfa 19

Yeni yorum
 

Volchansky ve kendinize başka bir holivar teması için "Gitmeye ihtiyacım var mı?"

 
Andrei :
verilog

Eh, yakaladın)) O da elektronik devrelerin geliştirilmesi için.

 
o_o :

Volchansky ve kendinize başka bir holivar teması için "Gitmeye ihtiyacım var mı?"


Negatif duygulara sahip olduğunuzu doğru anlıyor muyum? Niye ya?

 
Комбинатор :

Kimin umrunda?

İfadenizi tartışmanız gerekiyor (OOP atstoy) - Google'a gidin, "OOP" ve birkaç olumsuz nitelikle sürün, bir sel gibi bir makale alın ve okumadan foruma atın.

Doğru ya da doğru değil, önemli değil. Uygulanır veya uygulanmaz - önemli değil. Sizin gibi dikkatli okuyup kontrol eden varsa bir yazı daha atabilirsiniz.

OOP'de yeniyim, bu yüzden ciddi bir OOP eksi fark etmediğimi yüksek bir olasılıkla kabul ediyorum. Ve makaleyi ilk sıraya aldı, çünkü. Habr'ın ciddi bir programlama kaynağı olduğunu düşündüm. Bunun böyle olmaması mümkündür, ancak ben de bir programcı değilim.

Sonuç olarak, muhtemelen, toplumun bir bölümünde (bireyde) herhangi bir şeye karşı istikrarlı, neredeyse agresif ve inatçı reddetmelerin hangi nedenle geliştiğini, sosyolojik (veya psikolojik) bir çalışma yapmak gerekir.
 
George Merts :

Yani kadınlar da benden hoşlanmıyor ... Ve daha pek çoğu ... Yaygın bir şey, Alexei, hepsi hayvan, herkes onları eğitmeyi başaramıyor, bu yüzden çok kıskanç insanınız olacak.

Ama bana söylesen iyi olur - rotan nerede? ben de bir bakayım...


Evet, ona ihtiyacın yok, kişisel olarak attı

 
fxsaber :

OOP'nin ciddi bir eksi, karmaşık bir şeyin tasarlanmasının zor olmasıdır, yani. Kusursuz bir şekilde verimli çalışan ve koltuk değneği olmadan birbirine uyan bir mimari yapmak çok zordur, bu nedenle gerçek yeniden düzenleme uygulaması çok, çok yaygındır. Tasarımda ne kadar az deneyim olursa, o kadar çok şey yapabilirsiniz. Gerçek şu ki, genellikle OOP'de normal olarak tasarlanmış bir nesne modelinin yapısının gerçek nesnelerle (biz onları temsil ettiğimiz gibi) çok az ilgisi vardır.

Ayrıca, "iyi/kötü", "uygulanabilir/uygulanamaz" hakkında konuşabilmemiz için zaten belirli paradigmaların belirli diller tarafından desteklenmesine bağlıdır.

Örneğin yukarıda bahsedilen muz goriller bir OOP problemi değil, paket yöneticilerini bağımlılıkları takip etmeden akılsızca kullanma problemidir. Özellikle şu anda internette

 
fxsaber :

Makale yalan söylüyor!

Bu açıklamayı okuduğumda çok fazla şüpheye düştüm. Kafamın dağınık olmadığını kontrol etmek için hızla fırladım:

Makalenin yazarının değiştirmeyi önerdiği satırları vurguladım. Bunların değiştirilmesi sonucu etkilemez. Yazıyı daha okumadım. Büyük olasılıkla, yazarın bu saçmalığı hemen yorumlarda belirtildi.


Makale yalan söylemez. Sanal işlevler vardır, bu nedenle her şey yazarın yazdığı gibi çalışır.

Ama umarım bunu OOP'ye karşı ciddi bir argüman olarak görmüyorsunuzdur.

Temel sınıfta yapılan değişiklikler istediğiniz kadar büyük olabilir ve bunların türetilmiş sınıfların nasıl çalıştığını etkilememesini beklemek aptalca olur.

 
Koldun Zloy :

Yazı yalan söylemez. Sanal işlevler vardır, bu nedenle her şey yazarın yazdığı gibi çalışır.

Ama umarım bunu OOP'ye karşı ciddi bir argüman olarak görmüyorsunuzdur.

Temel sınıfta yapılan değişiklikler istediğiniz kadar büyük olabilir ve bunların türetilmiş sınıfların nasıl çalıştığını etkilememesini beklemek aptalca olur.

Sanal ise, o zaman her şey mantıklıdır ve yazar, sanal işlevlerin soru ve görevlerinde basitçe yetersizdir.

Ayrıca, bağımsızlığını kazanması gerekiyorsa, bunu yapmak zorundaydı.

 virtual void Array::addAll( const int &elements[] )
{
   for ( int i = 0 ; i < ArraySize (elements); i++)
//      this.a.add(elements[i]);
     Array:: add(elements[i]);
}
Ancak yeni başlayanlar için örneğin kendisini iyi buluyorum. Ne yaptığınızı anlamanız gerekir.
 
Комбинатор :

OOP'nin ciddi bir eksi, karmaşık bir şeyin tasarlanmasının zor olmasıdır, yani. Kusursuz bir şekilde verimli çalışan ve koltuk değneği olmadan birbirine uyan bir mimari yapmak çok zordur, bu nedenle gerçek yeniden düzenleme uygulaması çok, çok yaygındır. Tasarımda ne kadar az deneyim olursa, o kadar çok şey yapabilirsiniz. Gerçek şu ki, genellikle OOP'de normal olarak tasarlanmış bir nesne modelinin yapısının gerçek nesnelerle (biz onları temsil ettiğimiz gibi) çok az ilgisi vardır.

Ayrıca, "iyi/kötü", "uygulanabilir/uygulanamaz" hakkında konuşabilmemiz için zaten belirli paradigmaların belirli diller tarafından desteklenmesine bağlıdır.

Örneğin yukarıda bahsedilen muz goriller bir OOP problemi değil, paket yöneticilerini bağımlılıkları takip etmeden akılsızca kullanma problemidir. Özellikle şu anda internette

Evet, mimarinin başarısız seçildiği durumlarla birkaç kez karşılaştım. Bazen yeniden yazmak, düzenlemekten daha kolaydı.

Prosedürel kodlamada, kodu yazarken neredeyse her zaman programın mimarisini düşünebilirsiniz. Çünkü esneklik ve özgürlük tamamlandı, ancak çöp çok büyük.

OOP'de, ilk kod satırını tahtaya yazmadan ÖNCE tüm mimariyi boyamak istenir. Hazır olduğunda, kod çok kolay yazılır. Peki, başarılı bir mimari de varsa (burada sadece deneyim ve bireysel yetenekler yardımcı olur), o zaman proje hakkında her şey çoktan unutulmuş olsa bile, aynı şekilde kolayca sonuçlandırılır / genişletilir.

 
Alexey Volchanskiy :

Eh, yakaladın)) O da elektronik devrelerin geliştirilmesi için.

Sadece değil.
1...121314151617181920212223
Yeni yorum