Yaygın modülerleştirme kalıpları

Tüm projelere uyan tek bir modülerleştirme stratejisi yoktur. Kaynak: esnek bir yapıya sahip olduğundan, Gradle'ın esnek bazı önemli belgeler vardır. Bu sayfada bazı genel kurallar ve yaygın olarak kullanılan geliştirirken kullanabileceğiniz bazı kalıplar var.

Yüksek tutarlılık ve düşük bağlantı ilkesi

Modüler bir kod tabanını tanımlamanın bir yolu da kuplaj ve cohesion özelliklerini içerir. Bağlantı, modüllerin hangi birbirine bağımlıdır. Bu bağlamda tutarlılık, bir kurumun öğelerinin tek bir modülle ilişkilendirilmesi gerekir. Genel kural olarak, en iyi uygulamaları düşük bağlantı ve yüksek tutarlılık:

  • Düşük bağlantı, modüllerin değişiklik gösterir. Böylece, bir modülde yapılan değişikliklerin modül üzerindeki etkisi hiç ya da diğer modüllerin üzerine konuşalım. Modüller, yapay zekanın iç işleyişi hakkında diğer modülleri de inceleyin.
  • Yüksek tutarlılık, modüllerin bir dizi koddan oluşması gerektiği anlamına gelir. bir sistem gibi işlev görür. Sorumlulukları açıkça tanımlanmış olmalı ve projenin belirli alan bilgilerinin sınırları içinde olmalıdır. Örnek bir e-kitabı inceleyin bir uygulamadır. Kitap ve ödemeyle ilgili kodları birlikte kullanmak uygun olmayabilir işlevsel alandır. Bu nedenle, aynı modülde
ziyaret edin.

Modül türleri

Modüllerinizi düzenleme şekliniz büyük ölçüde uygulama mimarinize bağlıdır. Şunun altında: aşağıdaki adımları takip ederken uygulamanızda kullanabileceğiniz bazı yaygın modül türleridir: önerilen uygulama mimarimiz.

göz atın.

Veri modülleri

Veri modülleri genellikle depo, veri kaynakları ve model sınıfları içerir. İlgili içeriği oluşturmak için kullanılan veri modülünün üç temel sorumluluğu şunlardır:

  1. Belirli bir alandaki tüm verileri ve iş mantığını kapsülle: Her veri modülünün belirli bir görevi temsil eden verilerin işlenmesinden alan. Birbirleriyle alakalı oldukları sürece birçok veri türünü işleyebilir.
  2. Depoyu harici bir API olarak kullanıma sunma: Verilerin herkese açık API'si modülün bir depo olması gerektiğini ve uygulamanın geri kalanı.
  3. Tüm uygulama ayrıntılarını ve veri kaynaklarını dışarıdan gizleyin: Veri kaynaklarına yalnızca aynı modüldeki depolar tarafından erişilebilir. Dışarıdan gizli kalırlar. Kotlin'in private veya internal görünürlük anahtar kelimesi.
ziyaret edin.
Şekil 1. Örnek veri modülleri ve içerikleri.

Özellik modülleri

Özellik, bir uygulamanın işlevselliğinin izole bir parçasıdır. Bu işlev genellikle kaydolma veya ödeme işlemleri gibi birbiriyle yakından alakalı ekranlardan oluşan bir ekran ya da dizi akışı sağlar. Uygulamanızın alt kısmında gezinme çubuğu varsa her bir hedef bir özelliktir.

Şekil 2. Bu uygulamanın her sekmesi bir özellik olarak tanımlanabilir.

Özellikler, uygulamanızdaki ekranlarla veya hedeflerle ilişkilendirilir. Dolayısıyla, mantıklarını yönetmek için ilişkilendirilmiş bir kullanıcı arayüzü ve ViewModel belirtin. Tek bir özelliğin tek bir görünüm veya navigasyon hedefi. Özellik modülleri veri modüllerine bağlıdır.

Şekil 3. Örnek özellik modülleri ve içerikleri.

Uygulama modülleri

Uygulama modülleri, uygulamanın giriş noktalarıdır. Özelliklere göre değişir. modüllerin kullanılabilmesini sağlar ve genellikle kök gezinme sağlar. Tek bir uygulama modülü derlenebilir derleme varyantları sayesinde bir dizi farklı ikili programa bağlanabilir.

Şekil 4. *Demo* ve *Tam* ürün çeşidi modüllerinin bağımlılık grafiği.

Uygulamanız otomatik, Wear veya TV gibi birden fazla cihaz türünü hedefliyorsa her biri için bir uygulama modülü tanımlayın. Bu sayede, platforma özgü ve bildirmeyi konuştuk.

Şekil 5. Wear uygulaması bağımlılık grafiği.

Ortak modüller

Temel modüller olarak da bilinen yaygın modüller, diğer modüllerin yaygın olarak kullanılan bir üründür. Gereksizliği azaltırlar ve proje planında belirli bir katmanı kullanır. Aşağıda yaygın modüllere örnekler verilmiştir:

  • Kullanıcı arayüzü modülü: Reklam öğenizde özel kullanıcı arayüzü öğeleri veya ayrıntılı marka kullanımı uygulamanız varsa widget koleksiyonunuzu bir modüle yeniden kullanılması gereken tüm özellikler. Böylece, kullanıcı arayüzünüz farklı özellikler. Örneğin temanız merkeziyse Yeniden markalama gerçekleştiğinde sıkıntılı bir yeniden düzenleme sürecidir.
  • Analytics modülü: İzleme, çoğu zaman işletme gereksinimlerine göre yazılım mimarisine çok az kafa yorabilir. Analytics izleyiciler genelde alakasız pek çok bileşende kullanılır. Bu sizin için de geçerliyse, ayrı bir analiz modülüne sahip olmak iyi bir fikirdir.
  • Ağ modülü: Birçok modül ağ bağlantısı gerektirdiğinde bir http istemcisi sağlamak için özel olarak tasarlanmış bir modül oluşturabilirsiniz. Evet Özellikle istemciniz özel yapılandırmaya ihtiyaç duyduğunda kullanışlıdır.
  • Yardımcı program modülü: Yardımcı olarak da bilinen yardımcı programlar genellikle küçük parçalardır uygulamada yeniden kullanılan bir kod grubudur. Yardımcı programlara örnek olarak şunlar verilebilir: test yardımcıları, para birimi biçimlendirme işlevi, e-posta doğrulayıcı veya operatörümüzü kullanabilirsiniz.

Test modülleri

Test modülleri, yalnızca test amaçlı kullanılan Android modülleridir. Modüller, yalnızca test amaçlı kullanılan test kodunu, test kaynaklarını ve testlerin çalıştırılması için gereklidir ve uygulamanın çalışma zamanı boyunca gerekli değildir. Test modülleri, teste özgü kodu ana makineden ayırmak için oluşturulur Bu da modül kodunun yönetilmesini ve bakımını kolaylaştırır.

Test modüllerinin kullanım alanları

Aşağıdaki örneklerde, test modüllerinin uygulandığı durumlar gösterilmektedir çok faydalı olabilir:

  • Paylaşılan test kodu: Projenizde birden fazla modül varsa ve bunlardan bazıları test kodu birden fazla modül için geçerliyse, test etmek istediğiniz modülünü kullanabilirsiniz. Bu, yinelemeleri azaltmanıza ve testinizi yapmanıza yardımcı olabilir. bakımını kolaylaştırır. Paylaşılan test kodu, yardımcı program sınıflarını veya işlevlerinin yanı sıra simüle edilmiş JSON yanıtları.

  • Temiz Derleme Yapılandırmaları: Test modüllerini kullanarak kendi build.gradle dosyalarına sahip olabilirler. Hayır uygulama modülünüzün build.gradle dosyasını yalnızca testlerle ilgilidir.

  • Entegrasyon Testleri: Test modülleri, entegrasyonu depolamak için kullanılabilir uygulamanızın farklı bölümleri arasındaki etkileşimleri test etmek için kullanılan testler kullanıcı arayüzü, iş mantığı, ağ istekleri ve veritabanı sorguları dahil.

  • Büyük ölçekli uygulamalar: Test modülleri özellikle karmaşık kod tabanlarına ve birden çok modüle sahip büyük ölçekli uygulamalar. Böyle bir durumda durumlarda, test modülleri kodun düzenini ve sürdürülebilirliğini iyileştirmeye yardımcı olabilir.

ziyaret edin.
Şekil 6. Normalde birbirine bağımlı olacak modülleri izole etmek için test modülleri kullanılabilir.

Modülden modüle iletişime

Modüller nadiren toplam ayrımda bulunur ve genellikle diğer modülleri ve iyi bir fırsattır. Modüller etkinken bile bağlantıyı düşük tutmak önemlidir. ve sık sık bilgi alışverişinde bulunur. Bazen doğrudan olduğu gibi iki modül arasındaki iletişimin mimari kısıtlamaları ekleyin. Bunu yapmak, örneğin döngüsel bir ve bildirmeyi konuştuk.

Şekil 7. Döngüsel bağımlılıklar nedeniyle modüller arasında doğrudan, iki yönlü bir iletişim kurmak mümkün değildir. Diğer iki bağımsız modül arasındaki veri akışını koordine etmek için uyumlulaştırma modülü gereklidir.

Bu sorunun üstesinden gelmek için, uyumlulaştırma arasında geçiş yapıyor. Arabulucu modülü hem ve gerektiği şekilde iletmeniz gerekir. Örnek uygulamamızda ödeme ekranın, etkinliğin kaynağı olsa da hangi kitabı satın alacağını bilmesi gerekir farklı bir özelliğin parçası olan ayrı bir ekran. Bu durumda, aracı, gezinme grafiğine sahip olan modüldür (genellikle bir uygulama modülü). Bu örnekte, verileri ana sayfa özelliğinden ödeme özelliğini kullanmak için Gezinme bileşenini kullanın.

navController.navigate("checkout/$bookId")

Ödeme hedefi, bir kitap kimliğini bağımsız değişken olarak alır ve ve kitapla ilgili bilgileri getirir. Şu işlemler için kayıt durumu işleyicisini kullanabilirsiniz: bir hedef özelliğinin ViewModel içindeki gezinme bağımsız değişkenlerini alma.

class CheckoutViewModel(savedStateHandle: SavedStateHandle, …) : ViewModel() {

   val uiState: StateFlow<CheckoutUiState> =
      savedStateHandle.getStateFlow<String>("bookId", "").map { bookId ->
          // produce UI state calling bookRepository.getBook(bookId)
      }
      …
}

Nesneleri, gezinme bağımsız değişkenleri olarak iletmemeniz gerekir. Bunun yerine basit kimlikler kullanın . Bu şekilde bağıntıyı düşük tutarak tek doğru kaynağı da ihlal etmemiş olursunuz. gösteriyoruz.

Aşağıdaki örnekte her iki özellik modülü de aynı veri modülüne dayanır. Bu Arabulucu modülünün ihtiyaç duyduğu veri miktarını en aza indirmeyi mümkün kılar ve modüller arasındaki bağı düşük tutuyor. Tüm bu bilgileri modüllerin, temel kimlikler değişimi ile kaynakları bir paylaşılan veri modülü.

8. Şekil. Paylaşılan veri modülüne dayanan iki özellik modülü.

Bağımlılığı ters çevirme

Bağımlılığı ters çevirme, kodunuzu soyutlamanın tam anlamıyla somut bir uygulamadan ayrıdır.

  • Soyutlama: Hesabınızdaki bileşenlerin veya modüllerin birbirleriyle etkileşime girdiğini gösterir. Soyutlama modülleri bir projenin arayüzler ve modeller içerir.
  • Beton uygulama: Soyutlama modülüne bağlı modüller ve bir soyutlama davranışını uygulamaktır.

Soyutlama modülünde tanımlanan davranışa dayanan modüller yalnızca soyutlamanın kendisine bağlıdır.

9. Şekil. Doğrudan alt seviye modüllere bağlı olan üst seviye modüller yerine üst seviye ve uygulama modülleri soyutlama modülüne bağlı.

Örnek

Çalışması için veritabanına ihtiyaç duyan bir özellik modülü düşünün. Özellik modülü veri tabanının uygulanma şekliyle ilgili olan; yerel oda veritabanı veya uzak Firestore örneğidir. Yalnızca uygulama verilerini saklayıp okuması gerekir.

Bunu başarmak için özellik modülü, yerine soyutlama modülüne kıyaslandığında daha doğru sonuçlar elde eder. Bu soyutlama, uygulamanın veritabanı API'sidir. Diğer bir deyişle, bir web sitesi geliştirmek için Böylece özellik modülünün temel uygulama ayrıntılarını öğrenin.

Somut uygulama modülü, Özetleme modülünde tanımlanan API'ler. Bunu yapabilmemiz için de modülü de soyutlama modülüne bağlıdır.

Bağımlılık yerleştirme

Şimdiye kadar, özellik modülünün Google Etiket Yöneticisi'yle modülünü kullanabilirsiniz. Bu soruya cevap Bağımlılık Yerleştirme şeklindedir. Özellik modülü, gerekli veritabanı örneğini doğrudan oluşturmaz. Bunun yerine hangi bağımlılıklara ihtiyacı olduğunu belirler. Bu bağımlılıklar daha sonra projenin harici olarak, genellikle uygulama modülü içinde bulunur. 

releaseImplementation(project(":database:impl:firestore"))

debugImplementation(project(":database:impl:room"))

androidTestImplementation(project(":database:impl:mock"))

Avantajlar

API'lerinizi ve uygulamalarını ayırmanın avantajları şunlardır:

  • Değiştirilebilirlik: API ve uygulamanın birbirinden net bir şekilde ayrıldığını gösterir. modüllerinde, aynı API için birden fazla uygulama geliştirebilir ve bunlar arasında API'yı kullanan kodu değiştirmeden. Bu özellik, özellikle de farklı türde bir e-posta bağlamlardaki kapasiteleri veya davranışları ifade eder. Örneğin, gerçek bir üretim uygulamasına kıyasla test amaçlı olarak uygulanmasını sağlar.
  • Ayrıştırma: Ayırma, soyutlama kullanan modüllerin herhangi bir teknolojiye bağlı olabilir. Veritabanınızı daha sonra Firestore'a ayırmak daha kolaydır, çünkü değişiklikler yalnızca işlemi yapan belirli modülde (uygulama modülünde) gerçekleştiğinde veritabanınızın API'sini kullanarak diğer modülleri etkileyebilir.
  • Test edilebilirlik: API'leri uygulamalarından ayırmak, kolaylaştırır. API sözleşmelerine karşı test durumları yazabilirsiniz. Şunları yapabilirsiniz: çeşitli senaryoları ve uç durumları test etmek için farklı uygulamalar da kullanır. örnek uygulamalar dahil.
  • İyileştirilmiş derleme performansı: Bir API ile uygulamadaki değişiklikler, uygulama sürecinin modülün özelliklerine bağlı olarak derleme sistemini, API modülü. Bu da derleme sürelerinin daha hızlı olmasını ve üretkenliğin artmasını sağlar. Özellikle derleme sürelerinin önemli olabileceği büyük projelerde bunun yardımı dokunur.

Ne zaman ayrılmalı?

API'lerinizi şu durumlardan biridir:

  • Çeşitli özellikler: Sisteminizin bazı bölümlerini farklı dillerde uygulayabiliyorsanız şekilde, net bir API, farklı öğelerin birbirinin yerine hakkında bilgi edindiniz. Örneğin, OpenGL kullanan bir oluşturma sisteminiz ya da Vulkan, Play veya şirket içi faturalandırmanız ile çalışan bir faturalandırma sistemi API'ye gidin.
  • Birden çok uygulama: Google Haritalar'ı kullanarak birden fazla uygulama özellikleri tanımlamak için, ortak API'ler tanımlayabilir ve uygulamalar geliştirebilir.
  • Bağımsız ekipler: Bu ayrım, farklı geliştiricilerin veya ekiplerin kod tabanının farklı bölümlerinde aynı anda çalışmanızı sağlar. Geliştiricilerin API sözleşmelerini anlama ve doğru kullanma konusunda bilgi sahibi olacaksınız. Google'ın diğer modüllerin uygulama ayrıntılarıyla ilgilenmek zorunda kalmazsınız.
  • Büyük kod tabanı: Kod tabanı büyük veya karmaşık olduğunda, API'yi ayırmak kodu daha yönetilebilir hale getirir. Hedeflerinize ulaşmanız için daha ayrıntılı, anlaşılabilir ve bakımı yapılabilir birimlere ayırmanızı sağlar.

Nasıl uygulanır?

Bağımlılığı ters çevirmeyi uygulamak için aşağıdaki adımları izleyin:

  1. Özet modülü oluştur: Bu modülde API'ler (arayüzler) özelliğinizin davranışını tanımlayan).
  2. Uygulama modülleri oluşturun: Uygulama modüllerinde ve bir soyutlama davranışını uygulayın.
    Doğrudan alt seviye modüllere bağlı olan üst seviye modüller yerine üst seviye ve uygulama modülleri soyutlama modülüne bağlıdır.
    Şekil 10. Uygulama modülleri soyutlama modülüne bağlı.
    'nı inceleyin.
  3. Üst seviye modülleri soyutlama modüllerine bağımlı hale getir: bağlı olarak, modüllerinizi soyutlama modüllerini kullanır. Üst seviye modüllerin uygulamayı bilmesi gerekmez yalnızca sözleşmeye (API) ihtiyaçları vardır.
    Üst düzey modüller uygulamaya değil soyutlamalara bağlıdır.
    Şekil 11. Üst düzey modüller uygulamaya değil soyutlamalara bağlıdır.
    'nı inceleyin.
  4. Uygulama modülünü sağlama: Son olarak, nasıl uygulayacağınızı öğreneceksiniz. Özel uygulama, proje yöneticisinin ancak uygulama modülü bunu yapmak için genellikle iyi bir yerdir. Uygulamayı sağlamak amacıyla, bunu seçtiğiniz metrik için bir bağımlılık derleme varyantı veya test kaynağı grubu olabilir.
    Uygulama modülü gerçek uygulama sürecini gösterir.
    Şekil 12. Uygulama modülü, gerçek uygulamaları mümkün kılar.
    'nı inceleyin.

Genel en iyi uygulamalar

Başta da belirttiğimiz gibi, başarılı bir proje için planlama yapmanın çok modüllü bir uygulamadır. Birçok yazılım mimarisi gibi bir uygulamayı modülerleştirmenin birçok yolu var. Bununla birlikte, aşağıdaki genel bilgiler önerileri, kodunuzu daha okunabilir, bakımını yapabilir ve test edilebilir.

Yapılandırmanızın tutarlı olmasını sağlayın

Her modül yapılandırma ek yükü getirir. Modüllerinizin sayısı belirli bir eşiğe ulaştığında tutarlı yapılandırma yönetimi, isteyebilirsiniz. Örneğin, modüllerin aynı bağımlılığı kullanması önemlidir. sürümünü değil. Sadece bir teste giriş yapmak için çok sayıda modülü güncellemeniz bu, yalnızca bir çaba değil, aynı zamanda potansiyel riskler için değildir. Bu sorunu çözmek için gradle'ın araçlarından birini kullanarak yapılandırmanızı merkezileştirin:

  • Sürüm katalogları, tür güvenli bir bağımlılık listesidir senkronizasyon sırasında Gradle tarafından oluşturulur. Burası tüm ticari marka bilgilerinizi beyan edebileceğiniz ve projedeki tüm modüllerde kullanılabilir olduğundan emin olmalısınız.
  • Modüller arasında derleme mantığını paylaşmak için kural eklentileri kullanın.

Mümkün olduğunca az kullanıma sunun

Bir modülün herkese açık arayüzü minimum düzeyde olmalı ve yalnızca en iyi uygulamalar. Uygulama ayrıntılarını dışarı sızdırmamalıdır. Kapsam ele almaya çalışıyoruz. Kotlin private veya internal özelliğini kullanın görünürlük kapsamını ayarlayabilirsiniz. Bildirimde bağımlılıklarını api yerine implementation olarak tercih edin. İkincisi Modülünüzün tüketicilerine geçişli bağımlılıklar sunar. Kullanım modüllerin sayısını azalttığı için uygulama, derleme süresini iyileştirebilir gerekiyor.

Kotlin ve Java modülleri

Android Studio'nun desteklediği üç temel modül türü vardır:

  • Uygulama modülleri, uygulamanızın giriş noktalarıdır. Şunları içerebilir: kaynak kodu, kaynaklar ve öğeler ile bir AndroidManifest.xml. Çıktı uygulama modülü bir Android App Bundle (AAB) veya Android Uygulama Paketiyse (APK).
  • Kitaplık modülleri, uygulama modülleriyle aynı içeriğe sahiptir. Bunlar: diğer Android modülleri tarafından bağımlılık olarak kullanıldığını görüyoruz. Bir kitaplık modülünün çıkışı Android Arşivi (AAR), yapısal olarak uygulama modülleriyle aynıdır, ancak daha sonra diğer kullanıcılar tarafından kullanılabilecek bir Android Arşivi (AAR) dosyasına modüllerini bağımlılık olarak görebiliriz. Kitaplık modülü sayesinde birçok uygulama modülünde aynı mantığı ve kaynakları kapsülleyip yeniden kullanabilirsiniz.
  • Kotlin ve Java kitaplıkları herhangi bir Android kaynağı, öğesi veya manifest dosyalarında belirtilen dosyalar.

Android modüllerin ek yük getirmesi tercih edilir; bu nedenle, Olabildiğince çok Kotlin veya Java türünü.