Java'da ne zaman kullanımdan kaldırılacağı ve ne zaman silineceği


11

Yeniden düzenleme çabasının veya sadece devam eden gelişimin bir parçası olarak, belirli bir yöntem veya belki de tüm sınıf bir anlamda eski olabilir. Java, söz @Deprecatedkonusu işlevselliği ele almanın daha iyi bir yolu olduğunu belirtmek için ek açıklamayı destekler . Bunun, bir API'nin parçalarını kaldırmanın etkilerinin bilinmeyebileceği genel API'lerde özellikle yararlı olduğunu düşünüyorum. Herkese açık olmayan bir API ve revizyon kontrol sistemleri kullanan bir proje için (bu nedenle silme bir anlamda geri alınabilir), kullanılmayan öğeleri silmek yerine ne zaman kullanımdan kaldırılması uygun olur?

Yanıtlar:


18

API'nız herkese açık bir API mı? Bu, kullanımdan kaldırmanız veya kaldırmanız gerekip gerekmediğini belirler. API kesinlikle sizin yararınız içinse (yani yalnızca şirketinizde kullanılırsa), rahatsız edici kodu kaldırmak en iyisidir. Çok daha temiz ve uzun vadede daha az bakım baş ağrısına neden olacaktır.

Ancak, API herkese açık bir yöntemle karşı karşıya kalıyorsa, bir yöntemi kaldırmak kütüphanenizin eski sürümleriyle çalışan kodun çalışmasının durmasına neden olabilir. İşte işler dağınık. Aşağıda bazı yönergeler verilmiştir:

  • Dahili API: kullanımdan kaldırmak yerine kaldır. Herhangi bir istemci dahili bir sınıf veya yöntem kullanıyorsa, araç bozulursa bu onların hatasıdır.
  • Harici API: önce kullanımdan kaldırın, daha sonra kaldırın. Kullanımdan kaldırma, bir şeyin daha sonra kaldırılacağı bir bayraktır. Daha sonra makul olduğuna inandığınız şeye bağlıdır. En azından kullanımdan kaldırılmış kodu kaldırmadan önce 2-3 sürüm verin.

6

Bir sınıfı veya yöntemi tanımlarken bir hatırlatıcı ayarlamak muhtemelen iyi bir fikirdir. Bunu eskimesini teşvik etmek için yapıyorsunuz. Bu nedenle, tüm referansları ortadan kaldırmak için boş zaman olarak, işe yarar bir görev olarak ne kadar süreceğini tahmin edin. @Deprecated olarak işaretleyin ve takviminize bir hatırlatıcı ekleyin. Hatırlatıcıyı aldığınızda kontrol edin. Artık kullanılmıyorsa silin. Hızla güncellenebilen birkaç referans kalırsa, bunu yapın ve öğeyi silin. Daha önemli çalışmalar devam ederse hatırlatıcınızı biraz öne doğru itin.

Bunu yeterince kez yapın, projelerinizde bir sınıftan veya yöntemden kurtulmanın ne kadar sürdüğünü hissedeceksiniz.


1
+1 ama takviminizden ziyade, takım teknik borç geri ödeme takvimi daha uygun olur mu?
Gary Rowe

5

IMHO, hiç kimsenin kullanmadığından emin olursanız ve asla çıkarmazsanız, kaldırın. (Bu, yansıma varlığında zor olabilir veya Velocity makroları gibi harici bileşenler olabilir - IntelliJ gibi modern IDE'ler, örneğin JSP'de referanslar bulabilir, ancak yansıma veya Velocity'de bulunamaz.)

Daha iyi bir alternatif varsa ancak eskisi hala birçok yerde kullanılıyorsa ve şu anda tüm müşteri kodunu yeniden düzenlemek için zamanınız yoksa, eski sınıfı / yöntemi @ tanımlamak için yeterli (hakkında yeterli bir yorum ile) tercih edilen alternatif).

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.