Mutable dan Immutable DateTime di PHP, Ini Perbedaanya

Chronos Code Example

Tanggal yang dapat diubah dapat menjadi sumber kebingungan dan bug tak terduga dalam aplikasi. Tujuan saya bukan untuk memberi tahu bahwa objek DateTime jahat karena bisa berubah, tetapi untuk mempertimbangkan untung dan rugi menggunakan objek DateTime yang bisa Mutable dan Immutable, atau dapat berubah dan tidak dapat berubah. Pendekatan yang baik dalam menggunakan mutable dan immutable DateTime di PHP akan menjamin uji coba aplikasi yang bagus dan memunculkan kesadaran tentang bagaimana metode pengubah dapat mempengaruhi objek tanggal di aplikasi Anda.

Sampai saat ini, saya bahkan tidak menyadari bahwa PHP menawarkan kelas untuk DateTime yaitu DateTimeImmutable. Kelas DateTimeImmutable bekerja seperti kelas DateTime, kecuali objek tersebut tidak pernah memodifikasi dirinya sendiri, tetapi mengembalikan sebuah objek baru sebagai gantinya. Jadi, jika Anda paham cara kerja DateTime, Anda dapat segera menggunakan DateTimeImmutable dengan tenang. Berdasarkan artikel yang dihimpun dari https://laravel-news.com, mari kita pahami perbedaan dan cara penggunaanya secara seksama.

Bekerja dengan Objek DateTime Mutable

Untungnya bagi kita manusia biasa, kita dapat lebih jauh memisahkan kelas-kelas ini dan bekerja dengan library seperti Carbon. Saya akan memperkenalkan Anda library DateTimeImmutable yang terkenal setelah bagian ini.

Carbon mengextend berbagai variasi DateTime DateTimeImmutable yang berarti ketika menerapkan sebuah instance Carbon, setiap pemodifikasi yang memanggilnya (yaitu addDay()) akan menghasilkan perubahan:

Dalam konteks model Eloquent, ini masuk akal. Jika tidak, ini akan menghasilkan output yang aneh saat ingin memperbarui tanggal menggunakan pendekatan yang immutable :

Jika Anda bermaksud melakukan pengecekan perbandingan yang membutuhkan modifikasi, Anda perlu membuat salinan tanggal untuk menghindari mutasi atribut asli. Misalnya, dalam kode ini akan memutasi atribut model:

Hal lain yang menarik di sini adalah bahwa jika kode Anda mem-mutasi tanggal, tetapi Anda tidak save()memiliki model, Anda mungkin memiliki bug edge-case yang aneh yang sulit dilacak. Pengambilan besar di sini adalah menyadari bagaimana kode mem-mutasi tanggal Anda, dan mengirimkan salinan tanggal daripada seluruh model ke metode yang perlu melakukan modifikasi pada tanggal.

Saya tidak mencoba untuk berdebat bahwa menggunakan perpustakaan yang bisa berubah seperti Carbon itu salah ; Saya berfokus untuk menunjukkan bagaimana gaya objek ini berperilaku dan teknik pertahanan yang harus Anda terapkan untuk menghindari mutasi tak terduga.

Bekerja dengan Objek DateTime Immutable

Jika Anda suka bekerja dengan Karbon, dan Anda ingin bereksperimen dengan versi tak berubah yang memiliki API serupa, Anda mungkin tertarik dengan pustaka Chronos oleh yayasan CakePHP. Chronos awalnya didasarkan dari Karbon, dan merupakan perpustakaan yang berdiri sendiri tanpa ketergantungan eksternal di luar versi PHP ^5.5.9|^7.

Selain itu, Chronos berisi variasi tanggal / waktu yang bisa berubah, total dalam lima kelas :

  • Cake\Chronos\Chronos adalah objek tanggal dan waktu yang tidak berubah.
  • Cake\Chronos\Date adalah objek tanggal yang tidak berubah.
  • Cake\Chronos\MutableDateTime adalah objek tanggal dan waktu yang bisa berubah.
  • Cake\Chronos\MutableDate adalah objek tanggal yang bisa berubah.
  • Cake\Chronos\ChronosInterval adalah ekstensi ke objek DateInterval.

Menggunakan Chronos dalam contoh kode sebelumnya, objek tanggal tidak berkaitan dengan mutasi karena perubahan apa pun mengembalikan objek baru:

Setiap kali Anda memodifikasi suatu objek, salinan baru dikembalikan, membuat kode Anda bebas dari masalah ketergantungan berbasis pesanan. Ambil contoh berikut:

Untuk bekerja dengan tanggal yang tidak berubah, Anda perlu mengganti variabel saat bekerja dengan pengubah:

Bahkan jika Anda ingin mengatur ulang tanggal ke awal hari, Anda harus melakukan hal yang sama, atau menghubungkannya ke tugas asli:

Kekekalan membuat Anda memaksakan perubahan yang disengaja dengan secara eksplisit menetapkan ulang objek tanggal, dan Anda tidak perlu takut berkeliling objek asli.

Pelajari Lebih Lanjut

Meskipun perbedaannya terasa halus, menggunakan objek tanggal immutable dapat memberi Anda keyakinan bahwa melewati tanggal tidak akan menyebabkan mutasi ke objek asli, kecuali secara eksplisit menetapkan ulang.

Saya tidak mencoba untuk mengatakan bahwa satu gaya lebih baik dari yang lain, saya menunjukkan bahwa saya percaya belajar tentang PHP DateTimeImmutabledapat membantu memperjelas beberapa teknik defensif yang tanggal tak berubah memberikan kode Anda.

Dengan itu dalam pikiran, menggunakan Karbon, Anda perlu menyadari setiap tanggal yang ingin Anda keluarkan ke metode lain untuk perbandingan atau logika lainnya. Saya akan menyarankan untuk selalu menyalin contoh DateTime untuk menghindari mutasi, dan menyadari poin potensial dari perubahan dalam tanggal Anda yang dapat menciptakan hasil yang tidak diharapkan.

Jika Anda ingin bereksperimen lebih banyak dengan perpustakaan DateTime abadi dengan API bagus seperti Carbon’s, periksa dokumentasi Chronos.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.