AOP ile bazı problemler daha zarif bir şekilde çözülüyor mu?

Aspect Oriented Programming fikrine rastladım ve bununla ilgili bazı endişelerim var.

Temel fikir, nesne kullanılarak iyi modüle edilmemiş olan kesişen endişeleri ele almak ve onları modüle etmek istiyoruz gibi görünüyor. Hepsi çok iyi ve iyi.

Ancak AOP'nin uygulanması, kodun modülün dışından değiştirilmesi gibi görünüyor. Böylece, örneğin, belirli bir nesne bir işlevde parametre olarak iletildiğinde ne olacağını değiştiren bir yön yazılabilir. Bu doğrudan modüller fikrine aykırı görünüyor. Bir modülün davranışını bu modülün dışından değiştirememeliyim, aksi takdirde modüllerin tamamı bozulur. Ama bakış açıları tam olarak bunu yapıyor gibi görünüyor!

Temel olarak, yönler bir tür kod düzeltme eki gibi görünmektedir. Bazı hızlı saldırılar için yararlı olabilir; ama genel bir ilke olarak belki de yapmak istediğiniz bir şey değildir. En Boy Odaklı Programlama bana kötü bir uygulama uyguluyor ve genel bir tasarım prensibini yükseltiyor gibi geliyor.

AOP iyi bir uygulama mı? AOP ile bazı programlama problemleri daha zarif bir şekilde çözülüyor mu?

En Boy Odaklı Programlama, uygulamanızın veya kitaplığınızın kodunun, yazılımınızın birincil işlevleriyle ilgisi olmayan (örn. Çapraz kesimler) gereksiz yere dağılmadan yapılması zor olan belirli programlama türlerinin yapılmasını mümkün kılar. Örnekler:

1. Kayıt ve İzleme
2. Performans analizi
3. Hata Ayıklama ve İzleme
4. İşlevi Geri Al
5. Giriş ve çıkışların doğrulanması
6. Mevcut nesnelerin davranışını dönüştürme
7. Nesne Filtreleri
8. Güvenlik Uygulaması
9. İşlemleri yönetme

Bu tür kesişen endişeleri uygulamanın tek bir kısmıyla sınırlayarak ve daha sonra koddaki bu özellikleri öznitelikler, yöntem çağrısı kesmesi veya dinamik proxy'ler aracılığıyla referans alarak, kesişen davranışın kapsüllenmesine izin verirsiniz; bu, uygulamanızın başka herhangi bir yerinde sağlayabileceği tüm avantajlara (yani tek bir değişiklik noktası) sahiptir.

Buradaki kilit nokta, AOP'nin 1) uygulama boyunca yaygın olan ve 2) uygulamanın birincil işlevselliği için çevresel olan davranışı kapsadığıdır.

Oyunun sonlarına geliyorum, ama bunu bu soruya rastlayabilecek daha sonraki geliştiriciler için sağlıyorum.

Uygulamanızın düzgün çalışmasına bağlıysa AOP'ye karşı şiddetle tavsiye ederim . Unsurlar şu şekilde çalışır:

• Tavsiye (ek davranış) uygulanır
• Birleştirme noktaları (ekstra kodun eklenebileceği yerler, böyle bir yöntem başlangıç ​​veya bitiş veya belirli bir olay tetiklendiğinde)
• ... nokta kesimi (belirli bir birleşme noktasının eşleşip eşleşmediğini tespit eden bir desen) desenlerinin eşleştiği

Bilgisayarları uzun zamandır yapan herkes için, desenlerin kullanılması gerçeği yakından bakmak bir şey olabilir. Burada set, bağımsız değişkenlerden bağımsız olarak adlandırılan herhangi bir yöntemle eşleşen bir nokta kesimine örnek verilmiştir :

call(* set(..))

Bu oldukça süpürücü bir nokta ve bunu dikkatli bir şekilde kullanmanız tavsiye edilir (cinayet amaçlı değildir) çünkü birçok şeye tavsiye uyguluyorsunuz.

Ya da heck, adından veya imzasından bağımsız olarak her şeye tavsiye uygulayalım !

execution(* *(..))

Açıkça dikkatli olmalıyız çünkü burada çok fazla güç var, ancak bu yönlere karşı bir argüman değil - bu bir uyarı argümanı çünkü burada çok fazla güç var ve desen eşleştirme kolayca ters gidebilir (sadece en sevdiğiniz arama motoruna çarpın aop böcek ve eğlenin).

İşte nispeten güvenli bir nokta gibi görünüyor:

pointcut setter(): target(Point) &&
                   ( call(void setX(int)) ||
                     call(void setY(int)) );

Bu, adlandırılmış setXveya setYbir Pointnesne üzerinde yöntemler bulunursa açıkça tavsiye sağlar . Yöntemler sadece ints alabilir ve olmalıdır void. Oldukça güvenli görünüyor, değil mi? Bu yöntemler varsa ve doğru tavsiyeyi uyguladıysanız, bu güvenlidir. Değilse, çok kötü; sessizce başarısız olur.

Bir örnek vermek gerekirse, bir arkadaşım herkesin bir zamanlar yanlış bir veri döndüreceği bir Java uygulamasında hata ayıklamaya çalışıyordu. Nadir görülen bir başarısızlıktı ve herhangi bir özel olay veya veri ile ilişkili görünmüyordu. Test etmek veya tespit etmek çok zor olan bir iş parçacığı hatasıydı. Anlaşıldığı gibi, yöntemleri kilitlemek ve bunları "iş parçacığı güvenli" yapmak için yönleri kullanıyorlardı, ancak bir programcı bir yöntemi yeniden adlandırdı ve bir nokta kesimi, eşleşemedi ve böylece uygulamanın sessiz bir şekilde kırılmasına neden oldu.

Böylece, insanlara, AOP kullanmaları gerekiyorsa, istisnalar gibi yönleri tedavi etmek için söylüyorum: iyi tasarlanmış bir sistemde ve hiçbir şey yanlış gitmezse, kaldırılabileceklerini ve yazılımın hala düzgün çalıştığını söyleyebilirim . Ancak, programın işlevselliği AOP'ye bağlıysa, programınıza garanti edilmeyen bir kırılganlık sağlarsınız.

Bu nedenle, günlüğe kaydetme, hata ayıklama ve izleme, yönler için mükemmel olan, ancak güvenlik için mükemmel davranış örneklerinden biridir? Hayır! İplik güvenliği? Hayır!

AOP'ye sağlam bir alternatif için özelliklere bakın . Dile cıvatalanmak yerine, doğrudan dile entegre edilirler, "özellikli" bir IDE'ye ihtiyaç duymazlar (yardımcı olabilir) ve ihtiyaç duyduğunuz yöntemler mevcut değilse derleme zamanı arızalarına sahip olurlar. Sorunlar başlangıçtan itibaren daha iyi tanımlandığından, özellikler endişelerin ayrılmasını ele almak için çok daha temiz bir iş yapar. Onları çok kullanıyorum ve harikalar.

AOP'nin tek iyi ve pratik çözüm olabileceği bir durum , kaynak koduna erişiminizin olmamasıdır . Günlüğe kaydetme çapraz kesişme endişesinin eski yorgun örneğini kullanmak için:

Diyelim ki kontrol akışını, kullandığınız bir üçüncü taraf kütüphanesine kaydetmek istiyorsunuz. Günlüğe kaydetme ifadeleriyle tam olarak kendi kodunuz var Ancak, bu kütüphane için kaynağınız yok, bu da günlük ifadelerinizi eklemeyi imkansız hale getiriyor. Eğer bu yana yapmak bayt kodu var, AOP enstrüman üçüncü parti kütüphane zaten yapmanızı sağlar.

Yine de bir Günlük kaydı özelliği oluşturuyorsanız, AOP ile Günlük Kaydı'nı kendi kodunuz boyunca da uygulamayı düşünebilirsiniz.