Mengapa kita tidak harus menggunakan statis yang dilindungi di java

Saya sedang melalui pertanyaan ini Apakah ada cara untuk mengganti variabel kelas di Jawa? Komentar pertama dengan 36 suara positif adalah:

Jika Anda pernah melihat protected static, jalankan.

Adakah yang bisa menjelaskan mengapa protected staticdisukai?

Ini lebih merupakan masalah gaya daripada masalah langsung. Ini menunjukkan bahwa Anda belum memikirkan dengan baik apa yang terjadi dengan kelas.

Pikirkan tentang apa staticartinya:

Variabel ini ada di tingkat kelas, tidak ada secara terpisah untuk setiap contoh dan tidak memiliki keberadaan independen di kelas yang memperpanjang saya .

Pikirkan tentang apa protectedartinya:

Variabel ini dapat dilihat oleh kelas ini, kelas dalam paket yang sama, dan kelas yang memperpanjang saya .

Kedua arti itu tidak sepenuhnya eksklusif tetapi cukup dekat.

Satu-satunya kasus yang dapat saya lihat di mana Anda dapat menggunakan keduanya bersama-sama adalah jika Anda memiliki kelas abstrak yang dirancang untuk diperpanjang dan kelas yang diperluas kemudian dapat mengubah perilaku menggunakan konstanta yang ditentukan dalam aslinya. Pengaturan semacam itu kemungkinan besar akan berakhir sangat berantakan dan menunjukkan kelemahan dalam desain kelas.

Dalam kebanyakan kasus, akan lebih baik untuk memiliki konstanta sebagai publik karena itu hanya membuat semuanya lebih bersih dan memungkinkan orang-orang untuk membuat sub-klasifikasi lebih fleksibel. Terlepas dari hal lain dalam banyak kasus, komposisi lebih disukai daripada pewarisan, sementara kelas abstrak memaksakan pewarisan.

Untuk melihat satu contoh bagaimana ini dapat merusak sesuatu dan untuk menggambarkan apa yang saya maksud dengan variabel yang tidak memiliki keberadaan independen coba kode contoh ini:

public class Program {
    public static void main (String[] args) throws java.lang.Exception {
        System.out.println(new Test2().getTest());
        Test.test = "changed";
        System.out.println(new Test2().getTest());
    }
}

abstract class Test {
    protected static String test = "test";
}

class Test2 extends Test {
    public String getTest() {
        return test;
    }
}

Anda akan melihat hasilnya:

test
changed

Coba sendiri di: https://ideone.com/KM8u8O

Kelas Test2dapat mengakses anggota statis testdari Testtanpa perlu mengkualifikasikan nama - tetapi tidak mewarisi atau mendapatkan salinannya sendiri. Ia melihat objek yang sama persis dalam memori.

Ini disukai karena kontradiktif.

Membuat variabel protected menyiratkan itu akan digunakan dalam paket atau akan diwarisi dalam subkelas .

Membuat variabel staticmenjadikannya anggota kelas, menghilangkan niat untuk mewarisinya . Ini hanya menyisakan niat untuk digunakan dalam sebuah paket , dan kami memiliki package-privateuntuk itu (tanpa pengubah).

Satu-satunya situasi yang saya anggap berguna ini adalah jika Anda mendeklarasikan kelas yang harus digunakan untuk meluncurkan aplikasi (seperti JavaFX's Application#launch , dan hanya ingin dapat meluncurkan dari subkelas. Jika melakukannya, pastikan metodenya juga finaluntuk disallow menyembunyikan . Tapi ini bukan "norma", dan mungkin diterapkan untuk mencegah penambahan lebih banyak kerumitan dengan menambahkan cara baru untuk meluncurkan aplikasi.

Untuk melihat tingkat akses setiap pengubah, lihat ini: Tutorial Java - Mengontrol Akses ke Anggota Kelas

Saya tidak melihat alasan khusus mengapa hal ini tidak disukai. Mungkin selalu ada alternatif untuk mencapai perilaku yang sama, dan itu akan tergantung pada arsitektur sebenarnya apakah alternatif ini "lebih baik" daripada metode statis yang dilindungi atau tidak. Tetapi satu contoh di mana metode statis yang dilindungi akan masuk akal, setidaknya, adalah sebagai berikut:

(Diedit untuk dipecah menjadi paket terpisah, agar penggunaan protectedlebih jelas)

package a;
import java.util.List;

public abstract class BaseClass
{
    public Integer compute(List<Integer> list)
    {
        return computeDefaultA(list)+computeDefaultB(list);
    }

    protected static Integer computeDefaultA(List<Integer> list)
    {
        return 12;
    }
    protected static Integer computeDefaultB(List<Integer> list)
    {
        return 34;
    }
}

Berasal dari itu:

package a.b;

import java.util.List;

import a.BaseClass;

abstract class ExtendingClassA extends BaseClass
{
    @Override
    public Integer compute(List<Integer> list)
    {
        return computeDefaultA(list)+computeOwnB(list);
    }

    private static Integer computeOwnB(List<Integer> list)
    {
        return 56;
    }
}

Kelas turunan lainnya:

package a.b;

import java.util.List;

import a.BaseClass;

abstract class ExtendingClassB extends BaseClass
{
    @Override
    public Integer compute(List<Integer> list)
    {
        return computeOwnA(list)+computeDefaultB(list);
    }

    private static Integer computeOwnA(List<Integer> list)
    {
        return 78;
    }
}

The protected staticpengubah tentu dapat dibenarkan di sini:

• Metodenya bisa static, karena tidak bergantung pada variabel instan. Mereka tidak dimaksudkan untuk digunakan secara langsung sebagai metode polimorfik, melainkan metode "utilitas" yang menawarkan implementasi default yang merupakan bagian dari komputasi yang lebih kompleks, dan berfungsi sebagai "blok bangunan" dari implementasi yang sebenarnya.
• Metode tidak boleh public, karena merupakan detail implementasi. Dan mereka tidak bisa privatekarena mereka harus dipanggil oleh kelas tambahan. Mereka juga tidak bisa memiliki visibilitas "default", karena mereka tidak akan bisa diakses oleh kelas-kelas yang diperluas di paket lain.

(EDIT: Orang dapat berasumsi bahwa komentar asli hanya mengacu pada bidang , dan bukan metode - maka, bagaimanapun, itu terlalu umum)

Anggota statis tidak diwariskan, dan anggota yang dilindungi hanya dapat dilihat oleh subkelas (dan tentu saja kelas yang memuatnya), jadi a protected staticmemiliki visibilitas yang sama dengan static, menunjukkan kesalahpahaman oleh pembuat kode.

Sebenarnya tidak ada yang salah secara fundamental protected static. Jika Anda benar-benar menginginkan variabel atau metode statis yang terlihat untuk paket dan semua subclass dari kelas yang mendeklarasikan, lanjutkan dan buatprotected static .

Beberapa orang umumnya menghindari penggunaan protectedkarena berbagai alasan dan beberapa orang berpikir staticvariabel non-final harus dihindari dengan segala cara (saya pribadi bersimpati dengan yang terakhir sampai taraf tertentu), jadi saya kira kombinasi protecteddan staticharus terlihat buruk ^ 2 untuk yang milik kedua kelompok.

Protected digunakan sehingga bisa digunakan di subclass. Tidak ada logika dalam mendefinisikan statis yang dilindungi saat menggunakan dalam konteks kelas konkret karena Anda dapat mengakses variabel yang sama dengan cara statis. Namun pemohon akan memberikan peringatan untuk mengakses variabel statis kelas super dengan cara statis.

Nah, seperti yang sebagian besar orang jawab:

• protectedberarti - ' paket-privat + visibilitas ke subkelas - properti / perilaku DIBERIKAN '
• staticberarti - ' kebalikan dari instance - ini adalah properti / perilaku CLASS, yaitu TIDAK DIWARISKAN '

Oleh karena itu, mereka sedikit kontradiktif dan tidak cocok.

Namun, baru-baru ini saya menemukan kasus penggunaan di mana mungkin masuk akal untuk menggunakan keduanya secara bersamaan. Bayangkan Anda ingin membuat abstractkelas yang merupakan induk untuk tipe yang tidak dapat diubah dan memiliki sekumpulan properti yang sama untuk subtipe. Untuk mengimplementasikan keabadian dengan benar dan menjaga keterbacaan, seseorang mungkin memutuskan untuk menggunakan pola Builder .

package X;
public abstract class AbstractType {
    protected Object field1;
    protected Object field2;
    ...
    protected Object fieldN;

    protected static abstract class BaseBuilder<T extends BaseBuilder<T>> {
        private Object field1; // = some default value here
        private Object field2; // = some default value here
        ...
        private Object fieldN; // = some default value here

        public T field1(Object value) { this.field1 = value; return self();}
        public T field2(Object value) { this.field2 = value; return self();}
        ...
        public T fieldN(Object value) { this.fieldN = value; return self();}
        protected abstract T self(); // should always return this;
        public abstract AbstractType build();
    }

    private AbstractType(BaseBuilder<?> b) {
        this.field1 = b.field1;
        this.field2 = b.field2;
        ...
        this.fieldN = b.fieldN;
    }
}

Dan kenapa protected static? Karena saya ingin subtipe non-abstrak AbstactTypeyang mengimplementasikan Builder non-abstraknya sendiri dan terletak di luar package Xagar dapat mengakses dan menggunakan kembali BaseBuilder.

package Y;
public MyType1 extends AbstractType {
    private Object filedN1;

    public static class Builder extends AbstractType.BaseBuilder<Builder> {
        private Object fieldN1; // = some default value here

        public Builder fieldN1(Object value) { this.fieldN1 = value; return self();}
        @Override protected Builder self() { return this; }
        @Override public MyType build() { return new MyType(this); }
    }

    private MyType(Builder b) {
        super(b);
        this.fieldN1 = b.fieldN1;
    }
}

Tentu saja kita dapat BaseBuildermempublikasikannya tetapi kemudian kita sampai pada pernyataan kontradiktif lainnya:

• Kami memiliki kelas non-instantiatable (abstrak)
• Kami menyediakan pembangun publik untuk itu

Jadi dalam kedua kasus dengan protected staticdan publicpembangun fileabstract class kami menggabungkan pernyataan yang kontradiktif. Ini adalah masalah preferensi pribadi.

Namun, saya masih lebih memilih publicbuilderabstract class karena protected staticbagi saya terasa lebih tidak wajar di dunia OOD dan OOP!

Tidak ada salahnya memiliki protected static. Satu hal yang diabaikan oleh banyak orang adalah Anda mungkin ingin menulis kasus uji untuk metode statis yang tidak ingin Anda ungkapkan dalam keadaan normal. Saya perhatikan ini sangat berguna untuk menulis tes untuk metode statis di kelas utilitas.