Bu gönderi en son 2017-09-27 15:32 tarihinde Summer tarafından düzenlenmiştir
Bu makale, soru-cevap taklitini yapan kısa bir hikayedir ve yazar, mimarların yaptığı işleri kısaca analiz etmek için mizahi bir tarz kullanır: Yazılım mimarı olmak istiyorum. Bu, genç yazılım geliştiricileri için harika bir seçenektir. Ekibi yönetmek ve veritabanları ve çerçeveler, web sunucuları vb. hakkında önemli kararlar almak istiyorum. O zaman hiç yazılım mimarı olmak istemezsin. Tabii ki önemli kararların vericisi olmak istedim. Bu sorun değil, ama listenize önemli kararları dahil etmiyorsunuz, ki bunlar alakasız kararlardır. Ne demek istiyorsun? Veritabanlarının önemli kararlar olmadığını mı söylüyorsunuz, onlara ne kadar harcadığımızı biliyor musunuz? Belki de çok pahalı. Ancak, veritabanları önemli kararlardan biri değildir. Bunu nasıl söyleyebilirsin? Veritabanı, tüm verilerin sistematik hale getirildiği, sınıflandırıldığı, indekslendiği ve erişildiği sistemin çekirdeği oluşturur. Bir veritabanı olmasaydı, sistem olmazdı. Veritabanı sadece sınıflandırma, sorgulama ve bilgi raporlama için bazı faydalı araçlar sağlayan bir Sİ cihazıdır, ancak bunlar sistem mimarisinin sadece yardımcı işlevleridir. Yardım? Bu gerçekten saçmalık. Evet, yardımcı bir sistem. Sistemin iş kuralları bu araçların bazılarından faydalanabilir, ancak bu araçlar ilgili iş kurallarına özgü değildir. Gerekirse, mevcut olanları farklı araçlarla değiştirebilirsiniz; Ve iş kuralları değişmeyecek. Evet, ama yeniden kodlanması gerekiyordu çünkü bu araçlar orijinal veritabanında kullanılmıştı. Sorunun bu. Ne demek istiyorsun? Sorununuz, iş kurallarının veritabanı araçlarına bağlı olduğunu düşünmeniz ama aslında öyle değil. Ya da en azından, iyi bir mimari sağlanana kadar böyle olmamalı. Gerçekten çılgınca. Bu araçları kullanmayan iş kuralları nasıl oluşturulur? Veritabanı araçları kullanmadıklarını söylemiyorum ama buna bağlı değiller. İş kuralları hangi veritabanını kullandığını bilmesi gerekmez. Peki hangi araçları kullanacağınızı bilmeden iş kurallarını nasıl elde edersiniz? Bağımlılıkları tersine çevirin ve veritabanı iş kurallarına bağlı olsun. İş kurallarının veritabanına bağlı olmadığından emin olun. Saçmalıyorsun. Aksine, yazılım mimarisi dilini kullanıyorum. Bu, bağımlılık tersine çevirme ilkesidir: düşük seviyeli standartlar yüksek seviyeli standartlara dayanmalıdır. Saçmalık! Yüksek seviyeli kriterler (iş kurallarına atıfta bulunmak) Düşük seviyeli kriterler çağrısı (veritabanlarına atıfta bulunmak varsayımı). Bu nedenle, yüksek seviye kriter, arayan kişinin aranan kişiye bağlı olduğu ilkesine göre düşük seviyeli kritere dayanacaktır. Herkes bunu biliyor! Bu, çalışma zamanında geçerli. Ama derlerken, istediğimiz şey bağımlılığın tersine çevrilmesi. Yüksek seviyeli yönergelerin kaynak kodu, düşük seviyeli yönergelerin kaynak kodundan bahsetmemelidir. Hadi! Bir aramayı bahsetmeden nasıl yapabilirsin? Tabii ki sorun değil. Nesne yönelimli olmak işte işte bu. Nesne yönelimliliği, gerçek dünya model oluşturma, veri, işlevsellik ve uyumlu nesneleri birleştirmektir. Kodu sezgisel bir yapıya düzenlemekle ilgili. Öyle mi diyorlar? Hepimizin bildiği gibi, bu açık gerçek. Evet, bu durum var, ancak nesne yönelimli yönergeler kullanıldığında, gerçekten de bahsetmeden çağırmak mümkündür. Peki bunu nasıl yapacağım? Nesne yönelimli tasarımda, nesneler birbirlerine mesaj gönderir. Tabii ki doğru. Bir gönderici mesaj gönderdiğinde, alıcının türünü bilmez. Kullanılan dile bağlı. Java'da gönderici en azından alıcının temel tipini bilir. Ruby'de, gönderen en azından alıcının alınan mesajları işleyebildiğini bilir. Doğru. Her durumda, gönderen alıcının spesifik türünü bilmiyor. Evet, öyle. Bu nedenle, bir gönderici, belirli bir alıcı türünü belirtmeden bir fonksiyonu yerine getirecek şekilde tasarlayabilir. Doğru, doğru. Anlıyorum. Ancak gönderici yine de alıcıya bağlıdır. Bu, çalışma zamanında geçerli. Ancak, derlendiğinde farklıdır. Göndericinin kaynak kodu, alıcının kaynak kodundan bahsetmez veya ona bağlı değildir. Aslında, alıcının kaynak kodu göndericinin kaynak koduna bağlıdır. Olmaz! Gönderici yine de gönderdiği sınıfa bağlıdır. Belki bazı kaynak kodlarından daha net olur. Aşağıdaki paragraf Java ile yazılmıştır. İlk olarak gönderen: paket gönderici; public class Sender { özel Alıcı alıcı; public Gönderici (Alıcı r) { alıcı = r; } public void doSomething () { receiver.receiveThis (); } genel arayüz Alıcı { void receiveThis (); } }İşte alıcı: paket alıcısı; Gönderici içe aktarıyor. Gönderen; public class SpecificReceiver Sender.Receiver { public void receiveThis () { //ilginç bir şey yapar. } }Not: Alıcı göndericiye, SpecificReceiver göndericiye bağlıdır ve göndericide alıcı ile ilgili bilgi yoktur. Evet, ama yalan söylüyorsun, alıcının arayüzünü gönderici sınıfına koydun. Anlamaya başlıyorsun. Ne biliyorsun ki? Elbette, mimari ilke de budur. Gönderici, alıcının uygulaması gereken arayüze sahiptir. Eğer bu, iç içe sınıflar kullanmak zorunda olduğum anlamına geliyorsa, ...... İç içe sınıflar bir amaca ulaşmanın sadece bir yoludur, başka yollar da vardır. Bir dakika. Bunun veritabanlarıyla ne ilgisi var? Veritabanları hakkında konuşmaya başladık. Kodu biraz daha inceleyelim. İlki basit bir iş kuralıdır: paket işKuralları; ithalat kuruluşları. Bir şey; public class BusinessRule { private BusinessRuleGateway gateway; public BusinessRule (BusinessRuleGateway gateway) { this.gateway = gateway; } public void execute (String id) { gateway.startTransaction (); Bir şey şey = gateway.getSomething (id); thing.makeChanges (); gateway.saveSomething (şey); gateway.endTransaction (); } }İş kurallarının çok önemi yok. Bu sadece bir örnek. Birçok farklı iş kuralını uygulayan daha fazla böyle sınıf olabilir. Peki, Gateway tam olarak nedir? Tüm veri erişim yöntemlerini iş kuralları aracılığıyla sağlar. Bunu şu şekilde uygulayın: paket işKuralları; ithalat kuruluşları. Bir şey; public interface BusinessRuleGateway { Something getSomething (String id); void startTransaction (); void kaydetmeBir Şey (Bir şey şeyi); void endTransaction (); }Not: Bu businessRules bölümünde yer alıyor. Peki, Something sınıfı nedir? Basit bir iş nesnesini temsil eder. Varlıklara koydum. paket varlıkları; public class Bir şey { public void makeChanges () { //... } }Nihayetinde BusinessRuleGateway uygulaması, bu sınıf gerçek veritabanını bilir: paket veritabanı; businessRules.BusinessRuleGateway içe aktar; ithalat kuruluşları. Bir şey; public class MySqlBusinessRuleGateway implements BusinessRuleGateway { public Something getSomething (String id) { // MySql kullanarak bir şey elde eder. } public void startTransaction () { // start MySql transaction } public void saveSomething (Something thing) { // save thing in MySql } public void endTransaction () { // end MySql işlemi } }Ayrıca, iş kurallarının veritabanını çalışma zamanında çağırdığını unutmayın; Ancak, derleme sırasında veritabanı businessRules'u içerir ve onlara bağlıdır. Sanırım anladım. Sadece polimorfizmi kullanarak veritabanının iş kurallarından uygulandığını gizliyorsun. Ancak, tüm veritabanı araçlarını iş kurallarına sunmak için hâlâ bir arayüze ihtiyaç vardır. Hayır, hiç de hayır. İş kurallarına veritabanı araçları sağlamaya çalışmadık. Bunun yerine, ihtiyaç duydukları arayüzler oluşturmak için iş kuralları kullanıyorlar. Bu arayüzleri uygulamak, doğru araçları çağırmanızı sağlar. Evet, ama tüm iş kuralları için her aracı kullanmanız gerekiyorsa, aracı gateway arayüzüne koyun. Ah, sanırım hâlâ anlamıyorsun. Neyi anlamalıyım? Bu zaten açık. Her iş kuralı, ihtiyaç duyduğu veri erişim araçları için yalnızca bir arayüz tanımlar. Bir dakika, ne dersin? Bu, Arayüz Ayrımcılığı İlkesi'dir. Her iş kuralı sınıfı, veritabanının yalnızca belirli olanaklarını kullanır. Bu nedenle, her iş kuralı tarafından sağlanan arayüzler yalnızca ilgili tesislere erişebilir. Ancak bu, birçok arayüz ve diğer veritabanı sınıflarını çağıran birçok küçük uygulama sınıfı olduğu anlamına gelir. Harika, anlamaya başlıyorsun. Ama çok dağınık ve zaman kaybı. Neden bunu yapıyorsun? Bu düzenli ve zaman kazandırıyor. Hadi, kod için bolca kod al. Aksine, önemli mimari kararlar nedeniyle alakasız kararlar gecikebilir. Bu ne demek? Başta yazılım mimarı olmak istediğini söylemiştin, değil mi? Gerçekten önemli olan tüm kararları vermek istersin. Evet, ben de öyle düşünmüştüm. Veritabanları, web sunucuları ve çerçeveler hakkında karar vermek istiyorsunuz, değil mi? Evet, bunların hiçbirinin önemli olmadığını söylüyorsun. Sadece alakasız içerikler. Doğru. Hepsi bu. Yazılım mimarlarının verdiği önemli kararlar, veritabanları, web sunucuları ve çerçeveler hakkında karar vermenizi sağlayan kararlardır. Ama önce hangilerine karar vermeniz gerekiyor! Hayır, işe yaramıyor. Aslında, bunlar geliştirme döngüsünde, bilginin daha bol olduğu daha ilerleyen dönemlerde karar verilebilir. Mimarların çerçeveleri önceden belirledikten sonra gerekli performansı sağlamadığını veya dayanılmaz kısıtlamalar getirdiğini görmeleri büyük bir felakettir. Mimar kararı ertelemeye karar verdiğinde, yeterli bilgi olduğunda karar verir; Yavaş ve kaynak yoğun işlem cihazları ve çerçeveleri kullanmayan ekipler, mimarların takdirine göre hızlı ve hafif test ortamları oluşturabilir. Sadece mimarları gerçekten önemli olanı önemsiyor, önemsemeyenleri geciktiriyor ve böyle bir ekip şanslı olanıdır. Saçmalık, ne demek istediğini hiç anlamıyorum. Bu makaleye iyi bir göz atın, yoksa bunu anlamak için 10 yıl daha beklemeniz gerekecek.
| 
Yayınlandı 27.09.2017 15:29:46
|
|
|
Yayınlandı 28.09.2017 15:00:37
|
Ev sahibi|
Yayınlandı 29.09.2017 08:34:23
|
Yayınlandı 27.11.2018 11:12:17
|
