Kode apa yang harus dimasukkan dalam kelas abstrak?

Saya bermasalah akhir-akhir ini tentang penggunaan kelas abstrak.

Terkadang kelas abstrak dibuat sebelumnya dan berfungsi sebagai templat bagaimana kelas turunan akan bekerja. Itu berarti, lebih atau kurang, bahwa mereka menyediakan beberapa fungsionalitas tingkat tinggi tetapi meninggalkan detail tertentu untuk diimplementasikan oleh kelas turunan. Kelas abstrak mendefinisikan perlunya rincian ini dengan menerapkan beberapa metode abstrak. Dalam kasus seperti itu, kelas abstrak berfungsi seperti cetak biru, deskripsi fungsi tingkat tinggi atau apa pun yang Anda ingin menyebutnya. Itu tidak dapat digunakan sendiri, tetapi harus khusus untuk mendefinisikan rincian yang telah ditinggalkan dari implementasi tingkat tinggi.

Kadang-kadang, kebetulan bahwa kelas abstrak dibuat setelah penciptaan beberapa kelas "turunan" (karena kelas induk / abstrak belum ada, mereka belum diturunkan, tetapi Anda tahu maksud saya). Dalam kasus ini, kelas abstrak biasanya digunakan sebagai tempat di mana Anda dapat meletakkan segala jenis kode umum yang berisi kelas turunan saat ini.

Setelah melakukan pengamatan di atas, saya bertanya-tanya yang mana dari dua kasus ini yang seharusnya menjadi aturan. Haruskah setiap jenis rincian digelembungkan ke kelas abstrak hanya karena mereka saat ini menjadi umum di semua kelas turunan? Haruskah kode umum yang bukan bagian dari fungsionalitas tingkat tinggi ada di sana?

Haruskah kode yang mungkin tidak memiliki makna untuk kelas abstrak itu sendiri ada di sana hanya karena kebetulan umum untuk kelas turunan?

Biarkan saya memberi contoh: Kelas abstrak A memiliki metode a () dan metode abstrak aq (). Metode aq (), di kedua kelas turunan AB dan AC, menggunakan metode b (). Haruskah b () dipindahkan ke A? Jika ya, maka jika seseorang hanya melihat A (mari kita berpura-pura AB dan AC tidak ada di sana), keberadaan b () tidak masuk akal! Apakah ini hal yang buruk? Haruskah seseorang dapat melihat kelas abstrak dan memahami apa yang terjadi tanpa mengunjungi kelas turunannya?

Sejujurnya, pada saat menanyakan ini, saya cenderung percaya bahwa menulis kelas abstrak yang masuk akal tanpa harus melihat di kelas turunannya adalah masalah kode bersih dan arsitektur bersih. Ι tidak terlalu menyukai ide kelas abstrak yang bertindak seperti dump untuk semua jenis kode yang biasa terjadi di semua kelas turunan.

Apa yang Anda pikirkan / praktikkan?

Biarkan saya memberi contoh: Kelas abstrak A memiliki metode a () dan metode abstrak aq (). Metode aq (), di kedua kelas turunan AB dan AC, menggunakan metode b (). Haruskah b () dipindahkan ke A? Jika ya, maka jika seseorang hanya melihat A (mari kita berpura-pura AB dan AC tidak ada di sana), keberadaan b () tidak masuk akal! Apakah ini hal yang buruk? Haruskah seseorang dapat melihat kelas abstrak dan memahami apa yang terjadi tanpa mengunjungi kelas turunannya?

Apa yang Anda tanyakan adalah di mana harus menempatkan b(), dan, dalam beberapa hal lain pertanyaan adalah apakah Apilihan terbaik sebagai kelas super langsung untuk ABdan AC.

Tampaknya ada tiga pilihan:

1. biarkan b()keduanya ABdanAC
2. membuat kelas menengah ABAC-Parentyang mewarisi dari Adan yang memperkenalkan b(), dan kemudian digunakan sebagai kelas super langsung untuk ABdanAC
3. menempatkan b()di A(tidak tahu apakah kelas masa lain ADakan ingin b()atau tidak)

1. menderita karena tidak KERING .
2. menderita YAGNI .
3. jadi, yang tersisa ini.

Sampai kelas lain ADyang tidak menginginkan b()hadiah itu sendiri, (3) sepertinya pilihan yang tepat.

Pada saat ADhadiah, maka kita dapat menolak untuk pendekatan dalam (2) - setelah semua itu adalah perangkat lunak!

Kelas abstrak tidak dimaksudkan sebagai tempat pembuangan untuk berbagai fungsi atau data yang dilemparkan ke kelas abstrak karena nyaman.

Satu aturan praktis yang tampaknya memberikan pendekatan berorientasi objek yang paling dapat diandalkan dan diperluas adalah " Lebih suka komposisi daripada warisan ." Kelas abstrak mungkin dianggap sebagai spesifikasi antarmuka yang tidak mengandung kode apa pun.

Jika Anda memiliki beberapa metode yang merupakan jenis metode pustaka yang sejalan dengan kelas abstrak, metode yang merupakan cara yang paling mungkin untuk mengekspresikan beberapa fungsionalitas atau perilaku yang biasanya diperlukan oleh kelas yang berasal dari kelas abstrak, maka masuk akal untuk membuat kelas di antara kelas abstrak dan kelas-kelas lain di mana metode ini tersedia. Kelas baru ini menyediakan contoh khusus dari kelas abstrak yang mendefinisikan alternatif atau jalur implementasi tertentu dengan menyediakan metode ini.

Gagasan kelas abstrak adalah untuk memiliki model abstrak tentang apa yang seharusnya diberikan oleh kelas turunan yang menerapkan kelas abstrak sejauh layanan atau perilaku. Warisan mudah digunakan secara berlebihan dan berkali-kali kelas yang paling berguna terdiri dari berbagai kelas menggunakan pola mixin .

Namun selalu ada pertanyaan perubahan, apa yang akan berubah dan bagaimana itu akan berubah dan mengapa itu akan berubah.

Warisan dapat menyebabkan tubuh sumber rapuh dan rapuh (lihat juga Warisan: cukup hentikan menggunakannya! ).

Masalah kelas dasar rapuh adalah masalah arsitektur mendasar dari sistem pemrograman berorientasi objek di mana kelas dasar (superclasses) dianggap "rapuh" karena modifikasi yang tampaknya aman untuk kelas dasar, ketika diwarisi oleh kelas turunan, dapat menyebabkan kelas turunan tidak berfungsi . Programmer tidak dapat menentukan apakah perubahan kelas dasar aman hanya dengan memeriksa metode kelas dasar secara terpisah.

Pertanyaan Anda menyarankan pendekatan atau ke kelas abstrak. Tapi saya pikir Anda harus menganggapnya sebagai alat lain di kotak alat Anda. Dan kemudian pertanyaannya menjadi: Untuk pekerjaan / masalah mana kelas abstrak merupakan alat yang tepat?

Satu kasus penggunaan yang sangat baik adalah menerapkan pola metode templat . Anda meletakkan semua logika invarian di kelas abstrak dan logika varian di subkelasnya. Perhatikan, bahwa logika bersama itu sendiri tidak lengkap dan tidak berfungsi. Sebagian besar waktu tentang penerapan algoritma, di mana beberapa langkah selalu sama, tetapi setidaknya satu langkah bervariasi. Letakkan satu langkah ini sebagai metode abstrak yang dipanggil dari salah satu fungsi di dalam kelas abstrak.

Terkadang kelas abstrak dibuat sebelumnya dan berfungsi sebagai templat bagaimana kelas turunan akan bekerja. Itu berarti, lebih atau kurang, bahwa mereka menyediakan beberapa fungsionalitas tingkat tinggi tetapi meninggalkan detail tertentu untuk diimplementasikan oleh kelas turunan. Kelas abstrak mendefinisikan perlunya rincian ini dengan menerapkan beberapa metode abstrak. Dalam kasus seperti itu, kelas abstrak berfungsi seperti cetak biru, deskripsi fungsi tingkat tinggi atau apa pun yang Anda ingin menyebutnya. Itu tidak dapat digunakan sendiri, tetapi harus khusus untuk mendefinisikan rincian yang telah ditinggalkan dari implementasi tingkat tinggi.

Saya pikir contoh pertama Anda pada dasarnya adalah deskripsi pola metode templat (koreksi saya jika saya salah), jadi saya akan menganggap ini sebagai kasus penggunaan yang benar-benar valid dari kelas abstrak.

Kadang-kadang, kebetulan bahwa kelas abstrak dibuat setelah penciptaan beberapa kelas "turunan" (karena kelas induk / abstrak belum ada, mereka belum diturunkan, tetapi Anda tahu maksud saya). Dalam kasus ini, kelas abstrak biasanya digunakan sebagai tempat di mana Anda dapat meletakkan segala jenis kode umum yang berisi kelas turunan saat ini.

Untuk contoh kedua Anda, saya pikir menggunakan kelas abstrak bukanlah pilihan yang optimal, karena ada metode unggul untuk menangani logika bersama dan kode duplikat. Katakanlah Anda memiliki kelas abstrak A, kelas turunan Bdan Cdan kedua kelas turunan berbagi beberapa logika dalam bentuk metode s(). Untuk memutuskan pendekatan yang benar untuk menghilangkan duplikasi, penting untuk diketahui, apakah metode s()merupakan bagian dari antarmuka publik atau tidak.

Jika tidak (seperti dalam contoh nyata Anda sendiri dengan metode b()), kasusnya cukup sederhana. Cukup buat kelas terpisah darinya, juga mengekstraksi konteks yang diperlukan untuk melakukan operasi. Ini adalah contoh klasik komposisi atas warisan . Jika ada sedikit atau tidak ada konteks yang dibutuhkan, fungsi pembantu sederhana mungkin sudah cukup seperti yang disarankan dalam beberapa komentar.

Jika s()merupakan bagian dari antarmuka publik, itu menjadi sedikit lebih rumit. Di bawah asumsi yang s()tidak ada hubungannya dengan Bdan Cterkait dengan A, Anda tidak boleh dimasukkan ke s()dalam A. Jadi di mana meletakkannya? Saya berpendapat untuk mendeklarasikan antarmuka terpisah I, yang mendefinisikan s(). Kemudian lagi, Anda harus membuat kelas terpisah yang berisi logika untuk mengimplementasikan s()dan keduanya Bdan Cbergantung padanya.

Terakhir, berikut adalah tautan ke jawaban yang sangat bagus dari pertanyaan menarik tentang SO yang mungkin membantu Anda memutuskan kapan harus menggunakan antarmuka dan kapan untuk kelas abstrak:

Kelas abstrak yang baik akan mengurangi jumlah kode yang harus ditulis ulang karena fungsionalitas atau statusnya dapat dibagikan.

Sepertinya saya Anda kehilangan titik orientasi objek, baik secara logis dan teknis. Anda menggambarkan dua skenario: pengelompokan perilaku umum jenis dalam kelas dasar dan polimorfisme. Keduanya adalah aplikasi yang sah dari kelas abstrak. Tetapi apakah Anda harus membuat abstrak kelas atau tidak tergantung pada model analitis Anda, bukan kemungkinan teknis.

Anda harus mengenali jenis yang tidak memiliki inkarnasi di dunia nyata, namun meletakkan dasar untuk jenis tertentu yang memang ada. Contoh: seekor binatang. Tidak ada yang namanya binatang. Itu selalu anjing atau kucing atau apa pun tetapi tidak ada binatang yang nyata. Namun Animal membingkai semuanya.

Kemudian Anda berbicara tentang level. Level bukan bagian dari kesepakatan ketika datang ke warisan. Juga tidak mengenali data umum atau perilaku umum, itu adalah pendekatan teknis yang kemungkinan tidak akan membantu. Anda harus mengenali stereotip dan kemudian memasukkan kelas dasar. Jika tidak ada stereotip seperti itu, Anda mungkin lebih baik menggunakan beberapa antarmuka yang diimplementasikan oleh beberapa kelas.

Nama kelas abstrak Anda bersama dengan anggotanya harus masuk akal. Itu harus independen dari setiap kelas turunan, baik secara teknis maupun logis. Seperti Hewan bisa memiliki metode abstrak Makan (yang akan menjadi polimorfik) dan sifat abstrak boolean IsPet dan IsLifestock, yang masuk akal tanpa mengetahui tentang kucing atau anjing atau babi. Setiap ketergantungan (teknis atau logis) harus berjalan satu arah saja: dari keturunan ke basis. Kelas-kelas dasar itu sendiri juga tidak harus memiliki pengetahuan tentang kelas-kelas yang menurun.

Kasus pertama , dari pertanyaan Anda:

Dalam kasus seperti itu, kelas abstrak berfungsi seperti cetak biru, deskripsi fungsi tingkat tinggi atau apa pun yang Anda ingin menyebutnya.

Kasus kedua:

Beberapa waktu lain ... kelas abstrak biasanya digunakan sebagai tempat di mana Anda dapat meletakkan segala jenis kode umum yang berisi kelas turunan saat ini.

Lalu, pertanyaan Anda :

Saya ingin tahu yang mana dari dua kasus ini yang seharusnya menjadi peraturan. ... Haruskah kode yang mungkin tidak memiliki makna untuk kelas abstrak itu sendiri ada di sana hanya karena kebetulan umum untuk kelas turunan?

IMO Anda memiliki dua skenario yang berbeda, karena itu Anda tidak dapat membuat aturan tunggal untuk memutuskan desain apa yang harus diterapkan.

Untuk kasus pertama, kami memiliki hal-hal seperti pola Metode Templat yang telah disebutkan dalam jawaban lain.

Untuk kasus kedua, Anda memberi contoh metode abstrak penerima A kelas ab (); IMO metode b () hanya boleh dipindahkan jika masuk akal untuk SEMUA kelas turunan lainnya. Dengan kata lain, jika Anda memindahkannya karena digunakan di dua tempat, mungkin ini bukan pilihan yang baik, karena besok mungkin ada kelas turunan beton baru di mana b () tidak masuk akal sama sekali. Juga, seperti yang Anda katakan, jika Anda melihat kelas A secara terpisah dan b () juga tidak masuk akal dalam konteks itu, maka mungkin itu petunjuk bahwa ini bukan pilihan desain yang baik juga.

Saya punya pertanyaan yang persis sama beberapa waktu lalu!

Apa yang saya temukan adalah setiap kali saya menemukan masalah ini saya menemukan bahwa ada beberapa konsep tersembunyi yang belum saya temukan. Dan konsep ini lebih mungkin daripada seharusnya diungkapkan dengan beberapa nilai-objek . Anda memiliki contoh yang sangat abstrak, jadi saya khawatir saya tidak dapat menunjukkan apa yang saya maksud dengan menggunakan kode Anda. Tetapi ini adalah kasus dari praktik saya sendiri. Saya memiliki dua kelas yang mewakili cara untuk mengirim permintaan ke sumber daya eksternal dan mengurai respons. Ada kesamaan dalam bagaimana permintaan dibentuk dan bagaimana tanggapan diuraikan. Jadi seperti itulah hierarki saya:

abstract class AbstractProtocol
{
    /**
     * @return array Registration params to send
     */
    abstract protected function assembleRegistrationPart();

    /**
     * @return array Payment params to send
     */
    abstract protected function assemblePaymentPart();

    protected function doSend(array $data)
    {
        return
            (new HttpClient(
                [
                    'timeout' => 60,
                    'encoding' => 'utf-8',
                    'language' => 'en',
                ]
            ))
                ->send($data);
    }

    protected function log(array $data)
    {
        $header = 'Here is a request to external system!';
        $body = implode(', ', $this->maskData($data));
        Logger::log($header . '. \n ' . $body);
    }
}

class ClassicProtocol extends AbstractProtocol
{
    public function send()
    {
        $registration = $this->assembleRegistrationPart();
        $payment = $this->assemblePaymentPart();
        $specificParams = $this->assembleClassicSpecificPart();

        $dataToSend =
            array_merge(
                $registration, $payment, $specificParams
            );

        $this->log($dataToSend);

        $this->doSend($dataToSend);
    }

    protected function assembleRegistrationPart()
    {
        return ['hello' => 'there'];
    }

    protected function assemblePaymentPart()
    {
        return ['pay' => 'yes'];
    }
}

Kode semacam itu menunjukkan bahwa saya hanya menyalahgunakan warisan. Begitulah cara itu bisa di refactored:

class ClassicProtocol
{
    private $request;
    private $logger;

    public function __construct(Request $request, Logger $logger, Client $client)
    {
        $this->request = $request;
        $this->client = $client;
        $this->logger = $logger;
    }

    public function send()
    {
        $this->logger->log($this->request->getData());
        $this->client->send($this->request->getData());
    }
}

$protocol =
    new ClassicProtocol(
        new PaymentRequest(
            new RegistrationData(),
            new PaymentData(),
            new ClassicSpecificData()
        ),
        new ClassicLogger(),
        new ClassicClient()
    );

class RegistrationData
{
    public function getData()
    {
        return ['hello' => 'there'];
    }
}

class PaymentData
{
    public function getData()
    {
        return ['pay' => 'yes'];
    }
}

class ClassicLogger
{
    public function log(array $data)
    {
        $header = 'Here is a request to external system!';
        $body = implode(', ', $this->maskData($data));
        Logger::log($header . '. \n ' . $body);
    }
}
class ClassicClient
{
    private $properties;

    public function __construct()
    {
        $this->properties =
            [
                'timeout' => 60,
                'encoding' => 'utf-8',
                'language' => 'en',
            ];
    }
}

Sejak itu saya memperlakukan warisan dengan sangat hati-hati karena saya sering kali terluka.

Sejak itu saya sampai pada kesimpulan lain tentang warisan. Saya sangat menentang warisan berdasarkan struktur internal . Ini memecah enkapsulasi, rapuh, ini prosedural. Dan ketika saya mendekomposisi domain saya dengan cara yang benar , pewarisan tidak sering terjadi.