OOP uzmanları için soru. - sayfa 15

 
Alexey Navoykov :
Bu nedenle, "kung fu"nuza OOP'ye karşı çıkmak için hiçbir neden göremiyorum.

o ciddi!

Peter Konow'un fotoğrafı.
Şimdi konseptimin patentini alacağım. Yatırımcılar var. Yani her şey ciddi.

dün gece bir rüyanın gelmesi için bir konu okudum .... nedense, uzun bir Windows geliştiricileri listesi sundum - yani, Star Wars kredilerinde olduğu gibi!

ve listenin sonunda - büyük harflerle Peter Konow!


@Peter Konow böyle bir metin hareketli grafiği yapabilir misiniz? ;)
 
Alexey Navoykov :
Şu anda üzerinde çalıştığınız projedeki her şeyi hatırlıyorsunuz. Peki ya geçmiş kodlar? Bir yıl önce ne yazdığını tam olarak hatırlıyor musun? Nerede değişiyor vs. İşte eski kodunuzu biraz değiştirme veya düzeltme görevi.

Ve tüm bunların OOP ile ilgisi yok. Kodunuz genel değişkenlere genel erişim üzerine kuruluysa, buna ne prosedürel olarak ne de OOP'de ve hatta daha fazla işlevsel olarak hiçbir paradigmada izin verilmez. Bu nedenle, "kung fu"nuza OOP'ye karşı çıkmak için hiçbir neden göremiyorum.

Her şey Peter'ın olağanüstü hafızasına dayanıyor.

Ve katılıyorum, proje boyunca kullandığınız tüm değişkenleri, ne zaman ve nerede değiştirildiğini hatırlarsanız, hatalı değişiklik için yerleri kolayca bulabilirsiniz - o zaman, aslında, bu OOP'nin anlamı kaybolur. Peter aslında "montajcı düzeyinde" çalışıyor. OOP fırfırları ve tasarım desenleri ne olursa olsun, sonuçta, herhangi bir veri erişimi sıradan bellek adresleridir ve sürece tahsis edilen adres alanı içinde tüm bellek adreslerine tamamen erişilebilir. İşlemcinin kendisi herhangi bir kapsülleme hakkında hiçbir şey bilmiyor.

Pekala, Peter'ın yaptığı tam olarak bu. Montajcıya düşkün olduğum bir zaman vardı.

Tek soru, hatırlama yeteneğinde işlemciyle rekabet etmeyi nasıl başardığı.

 
Georgiy Merts :

Her şey Peter'ın olağanüstü hafızasına dayanıyor

...

Tek soru, hatırlama yeteneğinde işlemciyle rekabet etmeyi nasıl başardığı.

Peki, her zaman üzerinde çalıştığı aynı proje söz konusu olduğunda fenomen nedir? Doğal olarak, herhangi bir programcının kafasında her zaman tüm bunlar olacaktır.
Şimdi, bir süre sonra bu kodu açıkça hatırlayabilseydi, o zaman başka bir konuşma.
 
Alexey Navoykov :
Peki, sürekli üzerinde çalıştığı aynı proje söz konusu olduğunda fenomen nedir? Doğal olarak, herhangi bir programcının kafasında her zaman tüm bunlar olacaktır.
Şimdi, bir süre sonra bu kodu açıkça hatırlayabilseydi, o zaman başka bir konuşma.

O halde ben kimse değilim. Ben de çoğunlukla bir proje üzerinde çalışıyorum, ancak sadece ana özü hatırlıyorum. Neyin ve hangi prosedürün değiştirildiği gibi incelikler - sadece doğrudan geliştirme zamanında görüyorum. Ve sonra, bu bölüme dönersem, neden burada olduğunu anlamaya çalışmak için oldukça fazla zaman harcıyorum, başka türlü değil. Sonuç olarak, ben çok yönlü "hakların sünnet edilmesi" taraftarıyım, bu nedenle ideal olarak, programın herhangi bir yerinde, sadece bu yerde yapmanız gereken şey sizin için kullanılabilir.

 
Alexey Navoykov :
Şu anda üzerinde çalıştığınız projedeki her şeyi hatırlıyorsunuz. Peki ya geçmiş kodlar? Bir yıl önce ne yazdığını tam olarak hatırlıyor musun? Nerede değişiyor vs. İşte eski kodunuzu biraz değiştirme veya düzeltme görevi.

Ve tüm bunların OOP ile ilgisi yok. Kodunuz genel değişkenlere genel erişim üzerine kuruluysa, buna ne prosedürel olarak ne de OOP'de ve hatta daha fazla işlevsel olarak hiçbir paradigmada izin verilmez. Bu nedenle, "kung fu"nuza OOP'ye karşı çıkmak için hiçbir neden göremiyorum.
Evet, eski kodları çok çabuk hatırlıyorum ve anlıyorum. Proje o kadar büyük ki bazı kısımlar aylarca hatta yıllarca değişmiyor ve bir şeyi iyileştirme zamanı geldiğinde (örneğin eski bir liste), tüm detayları kısa sürede anlıyorum, nasıl olduğuna dair hafızamı tazeliyorum. kaynaklarda neredeyse bulunmayan, yorumsuz eserler. Çıplak koda baktığımı hatırlıyorum. Ve nedense bana öyle geliyor ki herkes yapabilir.
 

Alexey Navoykov :

...

Ve tüm bunların OOP ile ilgisi yok. Kodunuz genel değişkenlere genel erişim üzerine kuruluysa, buna ne prosedürel olarak ne de OOP'de ve hatta daha fazla işlevsel olarak hiçbir paradigmada izin verilmez. Bu nedenle, "kung fu"nuza OOP'ye karşı çıkmak için hiçbir neden göremiyorum.

Hayır, kung fu burada OOP. Aralarında %10'luk bir dövüşte işe yarayacak bir dizi hamle ve püf noktası. Ama ne güzel stiller! Ve bir ejderha, bir maymun ve bir kurbağalı bir flamingo ... Belirli bir sambom var. Rubanul ve sonucu aldım.

 
Реter Konow :

Hayır, kung fu burada OOP. Aralarında %10'luk bir dövüşte işe yarayacak bir dizi hamle ve püf noktası. Ama ne güzel stiller! Ve bir ejderha, bir maymun ve bir kurbağalı bir flamingo ... Belirli bir sambom var. Rubanul ve sonucu aldım.

Bu doğru değil.

Kapsüllemenin faydası ve hakların kısıtlanması hakkında - zaten yüzlerce kez söyledim.

Ortak bir sanal arabirime sahip öğe listeleriyle çalışmanın olduğu yerde, kalıtımın ve polimorfizmin kullanışlılığı açıkça görülebilir, ancak uygulama önemli ölçüde farklıdır.

İşte bu hafta tam anlamıyla karşılaştığım en basit durum, alanlarından biri çift değer olan yapıların bir listesi. LSM yardımıyla bu değerlere yaklaşma fikri ortaya çıktı.

OOP olmadan, ilgili SLAE'yi oluşturacak ve çözecek eksiksiz prosedürler yazmam gerekiyor. Veya, bir dizi değerle çalışmak için zaten böyle bir programım varsa, böyle bir dizi oluşturacak ve onu bir kitaplık işlevine iletecek prosedürler yazın.

OOP ile - CLSMCore sınıfından miras alıyorum ve nokta değerlerini döndüren sanal işlevleri aşırı yüklüyorum. Yaklaşım polinomunun katsayılarını hemen alabilirim.

Yani, eşit koşullar altında (bir kitaplık işlevimiz veya sınıfımız olduğunda) - OOP olmadan, fazladan bir ara diziye sahip olarak kaybederim. Tam olarak nasıl dolduracağınızı bulmanız gerektiği gerçeğinden bahsetmiyorum bile. (Hem OOP ile hem de olmadan - değer elde etme fonksiyonlarının yazılması gerekir). Bence en önemli artı, destek ve modifikasyonun basitliğidir. OOP ile - daha az anlamak için. Ayrıca, başlangıçta, OOP kullanmadan kütüphane yaklaşım işlevine harcadığım kadar, kesinlikle CLSMCore sınıfını yazmak için harcadım.

 
Georgiy Merts :

Bu doğru değil.

Kapsüllemenin faydası ve hakların kısıtlanması hakkında - zaten yüzlerce kez söyledim.

Ortak bir sanal arabirime sahip öğe listeleriyle çalışmanın olduğu yerde, kalıtımın ve polimorfizmin kullanışlılığı açıkça görülebilir, ancak uygulama önemli ölçüde farklıdır.

İşte bu hafta tam anlamıyla karşılaştığım en basit durum, alanlarından biri çift değer olan yapıların bir listesi. LSM yardımıyla bu değerlere yaklaşma fikri ortaya çıktı.

OOP olmadan, ilgili SLAE'yi oluşturacak ve çözecek eksiksiz prosedürler yazmam gerekiyor. Veya, bir dizi değerle çalışmak için zaten böyle bir programım varsa, böyle bir dizi oluşturacak ve onu bir kitaplık işlevine iletecek prosedürler yazın.

OOP ile - CLSMCore sınıfından miras alıyorum ve nokta değerlerini döndüren sanal işlevleri aşırı yüklüyorum. Yaklaşım polinomunun katsayılarını hemen alabilirim.

Yani, eşit koşullar altında (bir kitaplık işlevimiz veya sınıfımız olduğunda) - OOP olmadan, fazladan bir ara diziye sahip olarak kaybederim. Tam olarak nasıl dolduracağınızı bulmanız gerektiği gerçeğinden bahsetmiyorum bile. (Hem OOP ile hem de olmadan - değer elde etme fonksiyonlarının yazılması gerekir). Bence en önemli artı, destek ve modifikasyonun basitliğidir. OOP ile - daha az anlamak için. Ayrıca, başlangıçta, OOP kullanmadan kütüphane yaklaşım işlevine harcadığım kadar, kesinlikle CLSMCore sınıfını yazmak için harcadım.

Örneğin, işlev aşırı yüklemesinin neden gerekli olduğunu hiç anlamadım. Sonuçta, bu bir tür saçmalık ... Parametresiz bir fonksiyon yapıyoruz, aşırı yüklenmiş fonksiyonların tüm hesaplamalarını içimize yazıyoruz, değişkenleri global yapıyoruz ve diğer herhangi bir fonksiyondan sonuçlara erişebiliyoruz. Bu bir güzellik!

Ama hayır! Tüm hesaplamaları aynı ada sahip ancak farklı parametrelere sahip fonksiyonlara böleceğiz. Ve her fonksiyon için bir grup girdi parametresi yapacağız. Numara. Bu yeterli değil. Parametrelerin isimlerini de okunamaz hale getirelim. Ve böylece, aralarına serpiştirilmiş olarak, her türlü dizi aktarıldı. Ve her biri hakkında daha uzun düşünmek için bir düzine fonksiyon yapacağız. Ve onlara erişim şifreliydi. Sözdizimini daha gösterişli hale getirmek için. İşte profesyonellik!

Üzgünüm George. Haşlanmış.


not. 10 aşırı yüklenmiş işlevin sonuçları için yalnızca bir global dizi ve işini yapan bir parametresiz işlev. Daha kötü olan ne? 10 kat daha az sözdizimi.

 
Реter Konow :

Örneğin, işlev aşırı yüklemesinin neden gerekli olduğunu hiç anlamadım. Sonuçta, bu bir tür saçmalık ... Parametresiz bir fonksiyon yapıyoruz, aşırı yüklenmiş fonksiyonların tüm hesaplamalarını içimize yazıyoruz, değişkenleri global yapıyoruz ve diğer herhangi bir fonksiyondan sonuçlara erişebiliyoruz. Bu bir güzellik!

Ama hayır! Tüm hesaplamaları aynı ada sahip ancak farklı parametrelere sahip fonksiyonlara böleceğiz. Ve her fonksiyon için bir grup girdi parametresi yapacağız. Numara. Bu yeterli değil. Parametrelerin isimlerini de okunamaz hale getirelim. Ve böylece, onlarla karıştırılarak her türlü dizi aktarıldı. Ve her biri hakkında daha uzun düşünmek için bir düzine fonksiyon yapacağız. Ve onlara erişim şifreliydi. Sözdizimini daha gösterişli hale getirmek için. İşte profesyonellik!

Üzgünüm George. Haşlanmış.


not. 10 aşırı yüklenmiş işlevin sonuçları için yalnızca bir global dizi ve işini yapan bir parametresiz işlev. Daha kötü olan ne? 10 kat daha az sözdizimi.

Burada, bu işlev hakkında daha ayrıntılı olarak. Elinizde on gerekli işlevden birini seçen canavarca boyut anahtarı var. Böyle bir anahtarda, yanlışlıkla şubelerden biri ile ilgili kodu yanlış yere yazarak hata yapmak çok kolaydır.

Aşırı yük ile - her şey çok daha kolay. On farklı torunumuz var ve her seferinde BİR sınıfla çalışıyoruz ve aşırı yüklenmiş BİR işlevi var. Yanlışlıkla farklı bir sınıfa yazamayız çünkü bu tamamen farklı bir dosyanın açılmasını gerektirir.

Artı - bu çok büyük geçişte denemenin kendisi - bence, gerekli bir sınıfı açmaktan çok daha stresli ve ardından sadece bir işlevle deneme.

Aslında, montajcı kodunda, tüm bu aşırı yüklenme, bu işaretçiye bağlı olarak her durumda aynı anahtara gelir. Ancak OOP durumunda, tüm bunlar programcıdan gizlenir ve çalışmasına müdahale etmez. OOP olmadan - bununla başa çıkmak zorundasınız.

Kabaca söylemek gerekirse, yürürken kaslarınıza belirli bir sırayla onları hareket ettiren sinyaller gönderirsiniz. Ancak, bilinç düzeyinde - sadece hangi hareketi yapmanız gerektiğini hatırlarsınız. Burada, OOP tam da böyle bir "hafıza, hangi hareketin yapılması gerekiyor". "Onlara bağlı bir sürü kas ve sinirimiz varsa, hareketi neden hatırladığınızı anlamıyorsunuz." Şey... Hafızanın devleri için zaten birçok kez söyledim ve gerçekten, yürümek için hangi kasları hangi sırayla zorlamanız gerektiğini hatırlamak oldukça yeterli. Bu hareketi bir bütün olarak hatırlamanın bir anlamı yok - hayır, hayır. Çok fazla hatırlayamayan geri kalanı için, tüm hareketi ve kasların ne olduğunu, hangi sırayla sıkıldıklarını ve ne kadar sıkıldığını tam olarak hatırlamak çok daha makul - bilinçten saklanmak daha makul.

 

Реter Konow :

Örneğin, işlev aşırı yüklemesinin neden gerekli olduğunu hiç anlamadım. Sonuçta, bu bir tür saçmalık ... Parametresiz bir fonksiyon yapıyoruz, aşırı yüklenmiş fonksiyonların tüm hesaplamalarını içimize yazıyoruz, değişkenleri global yapıyoruz ve diğer herhangi bir fonksiyondan sonuçlara erişebiliyoruz. Bu bir güzellik!


Tin, genel kabul görmüş yaklaşımı uygun şekilde incelemeden bir tür bisiklet inşa ediyor. Piotr, iyi bir kitap bul, belki Stroustrup, bir metin editörü yazdığı bir kitapta, gerçek bir problem üzerine bir şeyler çizebilirsin, içeriğini hatırlamıyorum, ama kötü şeyler öğretmesi pek mümkün değil.

Neden: