Apakah salah menggunakan parameter boolean untuk menentukan perilaku?

Saya telah melihat latihan dari waktu ke waktu yang "terasa" salah, tetapi saya tidak bisa mengartikulasikan apa yang salah tentang itu. Atau mungkin itu hanya prasangka saya. Ini dia:

Pengembang mendefinisikan metode dengan boolean sebagai salah satu parameternya, dan metode itu memanggil yang lain, dan seterusnya, dan akhirnya boolean itu digunakan, semata-mata untuk menentukan apakah akan mengambil tindakan tertentu atau tidak. Ini dapat digunakan, misalnya, untuk memungkinkan tindakan hanya jika pengguna memiliki hak tertentu, atau mungkin jika kita (atau tidak) dalam mode uji atau mode batch atau mode hidup, atau mungkin hanya ketika sistem berada dalam negara tertentu.

Yah selalu ada cara lain untuk melakukannya, apakah dengan menanyakan kapan waktu untuk mengambil tindakan (daripada melewati parameter), atau dengan memiliki beberapa versi metode, atau beberapa implementasi dari kelas, dll. Pertanyaan saya bukan Begitu banyak cara untuk meningkatkan ini, tetapi lebih tepatnya apakah itu benar-benar salah (seperti yang saya duga), dan jika ya, apa yang salah tentang hal itu.

Ya, ini sepertinya bau kode, yang akan menyebabkan kode yang tidak dapat dipelihara yang sulit dipahami dan yang memiliki peluang lebih rendah untuk mudah digunakan kembali.

Seperti yang telah dicatat oleh poster, konteksnya adalah segalanya (jangan menyerah begitu saja jika itu salah satu atau jika praktiknya telah diakui sebagai utang teknis yang sengaja dikeluarkan untuk diperhitungkan kembali nanti) tetapi secara umum jika ada parameter yang lulus ke dalam fungsi yang memilih perilaku spesifik untuk dieksekusi maka penyempurnaan langkah-bijaksana lebih lanjut diperlukan; Memecah fungsi ini menjadi fungsi yang lebih kecil akan menghasilkan yang lebih kohesif.

Jadi apa fungsi yang sangat kohesif?

Ini adalah fungsi yang melakukan satu hal dan satu hal saja.

Masalah dengan parameter yang diteruskan seperti yang Anda gambarkan, adalah bahwa fungsinya melakukan lebih dari dua hal; mungkin atau mungkin tidak memeriksa hak akses pengguna tergantung pada status parameter Boolean, lalu tergantung pada pohon keputusan itu, ia akan melakukan fungsi.

Akan lebih baik untuk memisahkan masalah Kontrol Akses dari masalah Tugas, Tindakan atau Perintah.

Seperti yang telah Anda catat, jalinan masalah ini tampaknya tidak ada.

Jadi gagasan keterpaduan membantu kita mengidentifikasi bahwa fungsi yang dimaksud tidak sangat kohesif dan bahwa kita bisa memperbaiki kode untuk menghasilkan satu set fungsi yang lebih kohesif.

Jadi pertanyaannya bisa diajukan kembali; Mengingat bahwa kita semua sepakat untuk melewati parameter pemilihan perilaku sebaiknya dihindari bagaimana kita memperbaiki masalah?

Saya akan menyingkirkan parameter sepenuhnya. Memiliki kemampuan untuk mematikan kontrol akses bahkan untuk pengujian adalah risiko keamanan potensial. Untuk tujuan pengujian, matikan atau tiru cek akses untuk menguji baik akses yang diizinkan maupun skenario akses yang ditolak.

Ref: Kohesi (ilmu komputer)

Saya berhenti menggunakan pola ini sejak lama, karena alasan yang sangat sederhana; biaya perawatan. Beberapa kali saya menemukan bahwa saya memiliki beberapa fungsi mengatakan frobnicate(something, forwards_flag)yang dipanggil berkali-kali dalam kode saya, dan perlu menemukan semua tempat dalam kode di mana nilai falsedilewatkan sebagai nilai forwards_flag. Anda tidak dapat dengan mudah mencari itu, jadi ini menjadi sakit kepala pemeliharaan. Dan jika Anda perlu membuat perbaikan bug di masing-masing situs tersebut, Anda mungkin memiliki masalah yang tidak menguntungkan jika Anda melewatkannya.

Tetapi masalah khusus ini mudah diperbaiki tanpa mengubah pendekatan secara mendasar:

enum FrobnicationDirection {
  FrobnicateForwards,
  FrobnicateBackwards;
};

void frobnicate(Object what, FrobnicationDirection direction);

Dengan kode ini, seseorang hanya perlu mencari contoh FrobnicateBackwards. Meskipun mungkin ada beberapa kode yang memberikan ini ke variabel sehingga Anda harus mengikuti beberapa utas kontrol, saya menemukan dalam praktiknya bahwa ini cukup langka sehingga alternatif ini berfungsi dengan baik.

Namun, ada masalah lain dengan mengibarkan bendera dengan cara ini, setidaknya secara prinsip. Ini adalah bahwa beberapa (hanya beberapa) sistem yang memiliki desain ini mungkin mengekspos terlalu banyak pengetahuan tentang detail implementasi dari bagian-bagian kode yang bersarang (yang menggunakan bendera) ke lapisan luar (yang perlu mengetahui nilai yang harus dilewati di bendera ini). Untuk menggunakan terminologi Larry Constantine, desain ini mungkin memiliki kopling yang terlalu kuat antara penyetel dan pengguna bendera boolean. Franky meskipun sulit untuk mengatakan dengan tingkat kepastian pada pertanyaan ini tanpa mengetahui lebih lanjut tentang basis kode.

Untuk membahas contoh spesifik yang Anda berikan, saya akan memiliki beberapa tingkat kepedulian di masing-masing tetapi terutama karena alasan risiko / kebenaran. Yaitu, jika sistem Anda perlu membagikan flag-flag yang menunjukkan status sistem apa, Anda mungkin menemukan bahwa Anda memiliki kode yang seharusnya mempertimbangkan hal ini tetapi tidak memeriksa parameternya (karena tidak diteruskan ke fungsi ini). Jadi, Anda memiliki bug karena seseorang dihilangkan untuk melewati parameter.

Perlu juga diakui bahwa indikator keadaan sistem yang perlu diteruskan ke hampir setiap fungsi pada dasarnya adalah variabel global. Banyak kelemahan dari variabel global akan berlaku. Saya pikir dalam banyak kasus adalah praktik yang lebih baik untuk merangkum pengetahuan tentang kondisi sistem (atau kredensial pengguna, atau identitas sistem) dalam objek yang bertanggung jawab untuk bertindak dengan benar berdasarkan data tersebut. Kemudian Anda membagikan referensi ke objek itu sebagai lawan dari data mentah. Konsep kunci di sini adalah enkapsulasi .

Ini tidak selalu salah tetapi dapat mewakili bau kode .

Skenario dasar yang harus dihindari terkait parameter boolean adalah:

public void foo(boolean flag) {
    doThis();
    if (flag)
        doThat();
}

Kemudian ketika menelepon Anda biasanya akan menelepon foo(false)dan foo(true)tergantung pada perilaku yang Anda inginkan.

Ini benar-benar masalah karena ini adalah kasus kohesi yang buruk. Anda membuat ketergantungan antara metode yang tidak benar-benar diperlukan.

Apa yang harus Anda lakukan dalam kasus ini adalah meninggalkan doThisdan doThatsebagai metode terpisah dan publik kemudian lakukan:

doThis();
doThat();

atau

doThis();

Dengan begitu Anda menyerahkan keputusan yang benar kepada pemanggil (persis seperti jika Anda melewati parameter boolean) tanpa membuat kopling.

Tentu saja tidak semua parameter boolean digunakan dengan cara yang begitu buruk, tetapi itu pasti bau kode dan Anda benar untuk merasa curiga jika Anda melihat itu banyak dalam kode sumber.

Ini hanyalah salah satu contoh cara mengatasi masalah ini berdasarkan contoh yang saya tulis. Ada kasus-kasus lain di mana pendekatan yang berbeda akan diperlukan.

Ada artikel bagus dari Martin Fowler yang menjelaskan lebih lanjut ide yang sama.

PS: jika metode fooalih-alih memanggil dua metode sederhana memiliki implementasi yang lebih kompleks maka yang harus Anda lakukan adalah menerapkan metode ekstraksi refactoring kecil sehingga kode yang dihasilkan terlihat mirip dengan implementasi fooyang saya tulis.

Pertama: pemrograman bukanlah ilmu, tetapi seni. Jadi jarang ada cara "salah" dan "benar" untuk memprogram. Kebanyakan standar pengkodean hanyalah "preferensi" yang oleh beberapa programmer dianggap berguna; tetapi pada akhirnya mereka agak sewenang-wenang. Jadi saya tidak akan pernah label pilihan parameter menjadi "salah" dalam dan dari dirinya sendiri - dan tentu saja bukan sesuatu yang generik dan bermanfaat sebagai parameter boolean. Penggunaan a boolean(atau a int, dalam hal ini) untuk merangkum keadaan dibenarkan dalam banyak kasus.

Keputusan pengkodean, pada umumnya, harus didasarkan terutama pada kinerja dan pemeliharaan. Jika kinerja tidak dipertaruhkan (dan saya tidak bisa membayangkan bagaimana hal itu bisa terjadi dalam contoh Anda), maka pertimbangan Anda selanjutnya adalah: seberapa mudah ini bagi saya (atau redaktur masa depan) untuk dipertahankan? Apakah ini intuitif dan dapat dimengerti? Apakah ini terisolasi? Misalnya Anda panggilan fungsi dirantai sebenarnya tidak tampak berpotensi rapuh dalam hal ini: jika Anda memutuskan untuk mengubah Anda bIsUpuntuk bIsDown, berapa banyak tempat lain dalam kode akan perlu diubah juga? Juga, apakah daftar paramater Anda membengkak? Jika fungsi Anda memiliki 17 parameter, maka keterbacaan adalah masalah, dan Anda perlu mempertimbangkan kembali apakah Anda menghargai manfaat arsitektur berorientasi objek.

Saya pikir artikel kode Robert C Martins Clean menyatakan bahwa Anda harus menghilangkan argumen boolean di mana mungkin karena mereka menunjukkan metode melakukan lebih dari satu hal. Suatu metode harus melakukan satu hal dan satu hal saja yang saya pikir adalah salah satu motoya.

Saya pikir yang paling penting di sini adalah menjadi praktis.

Ketika boolean menentukan seluruh perilaku, buat saja metode kedua.

Ketika boolean hanya menentukan sedikit perilaku di tengah, Anda mungkin ingin menyimpannya dalam satu untuk mengurangi duplikasi kode. Jika memungkinkan, Anda bahkan dapat membagi metode menjadi tiga: Dua metode panggilan untuk opsi boolean, dan metode yang melakukan sebagian besar pekerjaan.

Sebagai contoh:

private void FooInternal(bool flag)
{
  //do work
}

public void Foo1()
{
  FooInternal(true);
}

public void Foo2()
{
  FooInternal(false);
}

Tentu saja, dalam praktiknya Anda akan selalu memiliki titik di antara kedua ekstrem ini. Biasanya saya hanya pergi dengan apa yang terasa benar, tetapi saya lebih suka untuk berbuat kesalahan di samping duplikasi kode kurang.

Saya suka pendekatan menyesuaikan perilaku melalui metode pembangun yang mengembalikan contoh tidak berubah. Begini cara JambuSplitter menggunakannya:

private static final Splitter MY_SPLITTER = Splitter.on(',')
       .trimResults()
       .omitEmptyStrings();

MY_SPLITTER.split("one,,,,  two,three");

Manfaat dari ini adalah:

• Readibility unggul
• Hapus pemisahan metode konfigurasi vs tindakan
• Mempromosikan keterpaduan dengan memaksa Anda berpikir tentang apa objeknya, apa yang seharusnya dan tidak boleh dilakukan. Dalam hal ini a Splitter. Anda tidak akan pernah memasukkan someVaguelyStringRelatedOperation(List<Entity> myEntities)kelas yang disebut Splitter, tetapi Anda akan berpikir untuk menempatkannya sebagai metode statis di StringUtilskelas.
• Mesin virtual tersebut sudah dikonfigurasikan terlebih dahulu oleh karena itu siap untuk diinjeksi dengan ketergantungan. Klien tidak perlu khawatir tentang apakah akan lulus trueatau falsemetode untuk mendapatkan perilaku yang benar.

Pasti bau kode . Jika tidak melanggar Prinsip Tanggung Jawab Tunggal maka mungkin melanggar Tell, Don't Ask . Mempertimbangkan:

• Bisakah Anda meringkas apa yang dilakukan metode Anda tanpa menggunakan kata hubung (dan, tapi, dll.)?
• Apakah ada bagian dari metode Anda yang dapat dengan mudah dikelompokkan ke dalam metode lain yang lebih kecil ? (Ini termasuk pembuatan variabel lokal yang kompleks .)
• Jika flag Anda menentukan metode mana yang memanggil parameter, apakah parameter Anda terlalu banyak ?
• Apakah metode ini termasuk dalam salah satu parameter Anda? (Anda mungkin memperhatikan jika ia mengambil variabel instan dalam parameter Anda menggunakan getter / setter .)

Jika ternyata tidak melanggar salah satu dari dua prinsip itu, Anda harus tetap menggunakan enum. Bendera Boolean adalah boolean yang setara dengan angka ajaib . foo(false)masuk akal sebanyak bar(42). Enum dapat berguna untuk Pola Strategi dan memiliki fleksibilitas untuk membiarkan Anda menambahkan strategi lain. (Ingatlah untuk memberi nama mereka dengan tepat .)

Contoh khusus Anda sangat mengganggu saya. Mengapa bendera ini melewati begitu banyak metode? Ini terdengar seperti Anda perlu membagi parameter Anda menjadi subclass .

TL; DR: jangan gunakan argumen boolean.

Lihat di bawah mengapa mereka buruk, dan bagaimana cara menggantinya (dalam huruf tebal).

Argumen Boolean sangat sulit dibaca, dan karenanya sulit dipertahankan. Masalah utama adalah bahwa tujuannya umumnya jelas ketika Anda membaca metode tanda tangan di mana argumen tersebut dinamai. Namun, penamaan parameter umumnya tidak diperlukan di sebagian besar bahasa. Jadi Anda akan memiliki anti-pola seperti di RSACryptoServiceProvider#encrypt(Byte[], Boolean)mana parameter boolean menentukan jenis enkripsi apa yang akan digunakan dalam fungsi tersebut.

Jadi, Anda akan menerima panggilan seperti:

rsaProvider.encrypt(data, true);

di mana pembaca harus mencari tanda tangan metode hanya untuk menentukan apa yang sebenarnya truebisa berarti. Melewati bilangan bulat tentu saja sama buruknya:

rsaProvider.encrypt(data, 1);

akan memberitahu Anda sama banyak - atau lebih tepatnya: sama sedikit. Bahkan jika Anda mendefinisikan konstanta yang digunakan untuk integer maka pengguna fungsi mungkin mengabaikannya dan tetap menggunakan nilai literal.

Cara terbaik untuk menyelesaikan ini adalah dengan menggunakan enumerasi . Jika Anda harus lulus enum RSAPaddingdengan dua nilai: OAEPatau PKCS1_V1_5Anda akan segera dapat membaca kode:

rsaProvider.encrypt(data, RSAPadding.OAEP);

Boolean hanya dapat memiliki dua nilai. Ini berarti bahwa jika Anda memiliki opsi ketiga, maka Anda harus memperbaiki tanda tangan Anda. Umumnya ini tidak dapat dengan mudah dilakukan jika kompatibilitas ke belakang merupakan masalah, jadi Anda harus memperluas kelas publik apa pun dengan metode publik lain. Inilah yang akhirnya dilakukan Microsoft ketika mereka memperkenalkan di RSACryptoServiceProvider#encrypt(Byte[], RSAEncryptionPadding)mana mereka menggunakan enumerasi (atau setidaknya kelas meniru enumerasi) alih-alih boolean.

Bahkan mungkin lebih mudah untuk menggunakan objek atau antarmuka penuh sebagai parameter, jika parameter itu sendiri perlu di-parameterkan. Dalam contoh di atas OAEP padding itu sendiri dapat diparameterisasi dengan nilai hash untuk digunakan secara internal. Perhatikan bahwa sekarang ada 6 algoritma hash SHA-2 dan 4 algoritma hash SHA-3, sehingga jumlah nilai enumerasi dapat meledak jika Anda hanya menggunakan enumerasi tunggal daripada parameter (ini mungkin hal berikutnya yang akan dicari tahu oleh Microsoft ).

Parameter Boolean juga dapat menunjukkan bahwa metode atau kelas tidak dirancang dengan baik. Seperti contoh di atas: pustaka kriptografis apa pun selain .NET tidak menggunakan flag padding dalam metode signature sama sekali.

Hampir semua guru perangkat lunak yang saya suka memperingatkan terhadap argumen boolean. Misalnya, Joshua Bloch memperingatkan mereka dalam buku yang sangat dihargai "Java Efektif". Secara umum mereka seharusnya tidak digunakan. Anda bisa berargumen bahwa mereka dapat digunakan jika ada satu parameter yang mudah dipahami. Tetapi meskipun demikian: Bit.set(boolean)mungkin lebih baik diimplementasikan menggunakan dua metode : Bit.set()dan Bit.unset().

Jika Anda tidak dapat langsung memperbaiki kode Anda dapat mendefinisikan konstanta untuk setidaknya membuatnya lebih mudah dibaca:

const boolean ENCRYPT = true;
const boolean DECRYPT = false;

...

cipher.init(key, ENCRYPT);

jauh lebih mudah dibaca daripada:

cipher.init(key, true);

bahkan jika Anda lebih suka:

cipher.initForEncryption(key);
cipher.initForDecryption(key);

sebagai gantinya.

Saya terkejut tidak ada yang menyebutkan parameter bernama .

Masalah yang saya lihat dengan boolean-flags adalah mereka merusak keterbacaan. Misalnya, apa yang ada truedi

myObject.UpdateTimestamps(true);

melakukan? Saya tidak punya ide. Tapi bagaimana dengan:

myObject.UpdateTimestamps(saveChanges: true);

Sekarang sudah jelas apa parameter yang kita lewati dimaksudkan untuk dilakukan: kita memberi tahu fungsi untuk menyimpan perubahannya. Dalam hal ini, jika kelasnya non-publik, saya pikir parameter boolean baik-baik saja.

Tentu saja, Anda tidak bisa memaksa pengguna kelas Anda untuk menggunakan parameter bernama. Untuk alasan ini, salah satu enumatau dua metode terpisah biasanya lebih disukai, tergantung pada seberapa umum kasus default Anda. Inilah yang dilakukan .Net:

//Enum used
double a = Math.Round(b, MidpointRounding.AwayFromZero);

//Two separate methods used
IEnumerable<Stuff> ascendingList = c.OrderBy(o => o.Key);
IEnumerable<Stuff> descendingList = c.OrderByDescending(o => o.Key); 

Saya tidak bisa mengartikulasikan apa yang salah tentang itu.

Jika terlihat seperti bau kode, terasa seperti bau kode dan - yah - bau seperti bau kode, itu mungkin bau kode.

Yang ingin Anda lakukan adalah:

1) Hindari metode dengan efek samping.

2) Tangani negara-negara yang diperlukan dengan mesin negara resmi pusat (seperti ini ).

Saya setuju dengan semua kekhawatiran menggunakan Parameter Boolean untuk tidak menentukan kinerja agar; meningkatkan, Keterbacaan, Kehandalan, menurunkan Kompleksitas, Menurunkan risiko dari Enkapsulasi & Kohesi yang buruk dan menurunkan Total Biaya Kepemilikan dengan Dapat Diurus.

Saya mulai merancang perangkat keras pada pertengahan 70-an yang sekarang kita sebut SCADA (kontrol pengawasan dan akuisisi data) dan ini adalah perangkat keras yang disesuaikan dengan kode mesin di EPROM yang menjalankan kontrol jarak jauh makro dan mengumpulkan data kecepatan tinggi.

Logika disebut mesin Mealey & Moore yang kita sebut sekarang Mesin Hingga Negara . Ini juga harus dilakukan dalam aturan yang sama seperti di atas, kecuali jika itu adalah mesin waktu nyata dengan waktu eksekusi yang terbatas dan kemudian pintasan harus dilakukan untuk memenuhi tujuan tersebut.

Data tersebut sinkron tetapi perintahnya asinkron dan logika perintah mengikuti logika Boolean tanpa memori tetapi dengan perintah berurutan berdasarkan memori dari kondisi sebelumnya, sekarang, dan yang diinginkan berikutnya. Agar hal itu berfungsi dalam bahasa mesin yang paling efisien (hanya 64 kB), kami sangat berhati-hati untuk mendefinisikan setiap proses dengan gaya IBM HIPO heuristik. Itu kadang-kadang berarti melewati variabel Boolean dan melakukan cabang yang diindeks.

Tetapi sekarang dengan banyak memori dan kemudahan OOK, Enkapsulasi adalah unsur penting hari ini tetapi hukuman ketika kode dihitung dalam byte untuk waktu nyata dan kode mesin SCADA ..

Ini tidak selalu salah, tetapi dalam contoh konkret Anda tentang tindakan tergantung pada beberapa atribut "pengguna" saya akan melewati referensi ke pengguna daripada bendera.

Ini mengklarifikasi dan membantu dalam beberapa cara.

Siapa pun yang membaca pernyataan memohon akan menyadari bahwa hasilnya akan berubah tergantung pada pengguna.

Dalam fungsi yang pada akhirnya disebut, Anda dapat dengan mudah menerapkan aturan bisnis yang lebih kompleks karena Anda dapat mengakses atribut pengguna.

Jika satu fungsi / metode dalam "rantai" melakukan sesuatu yang berbeda tergantung pada atribut pengguna, sangat mungkin bahwa ketergantungan yang sama pada atribut pengguna akan diperkenalkan ke beberapa metode lain dalam "rantai".

Sebagian besar waktu, saya akan mempertimbangkan pengkodean yang buruk ini. Saya bisa memikirkan dua kasus, di mana ini mungkin merupakan praktik yang baik. Karena sudah ada banyak jawaban yang mengatakan mengapa itu buruk, saya menawarkan dua kali padahal mungkin bagus:

Yang pertama adalah jika setiap panggilan dalam urutan masuk akal dengan sendirinya. Masuk akal jika kode panggilan mungkin diubah dari true ke false atau false ke true, atau jika metode yang dipanggil mungkin diubah untuk menggunakan parameter boolean secara langsung daripada meneruskannya. Kemungkinan sepuluh panggilan seperti itu berturut-turut kecil, tetapi itu bisa terjadi, dan jika itu dilakukan, itu akan menjadi praktik pemrograman yang baik.

Kasus kedua adalah sedikit peregangan mengingat bahwa kita sedang berhadapan dengan boolean. Tetapi jika program memiliki banyak utas atau peristiwa, melewati parameter adalah cara paling sederhana untuk melacak utas / data khusus acara. Misalnya, suatu program dapat memperoleh input dari dua soket atau lebih. Kode yang berjalan untuk satu soket mungkin perlu menghasilkan pesan peringatan, dan satu yang berjalan untuk yang lain mungkin tidak. Maka (semacam) masuk akal untuk set boolean pada tingkat yang sangat tinggi untuk melewati banyak panggilan metode ke tempat-tempat di mana pesan peringatan dapat dihasilkan. Data tidak dapat disimpan (kecuali dengan susah payah) dalam bentuk global apa pun karena beberapa utas atau acara yang saling terkait masing-masing akan membutuhkan nilainya sendiri.

Yang pasti, dalam kasus terakhir saya mungkin membuat kelas / struktur yang hanya konten adalah boolean dan lulus yang sekitar sebagai gantinya. Saya hampir pasti akan membutuhkan bidang lain sebelum terlalu lama - seperti di mana mengirim pesan peringatan, misalnya.

Konteks itu penting. Metode semacam itu sangat umum di iOS. Sebagai salah satu contoh yang sering digunakan, UINavigationController menyediakan metode -pushViewController:animated:, dan animatedparameternya adalah BOOL. Metode ini pada dasarnya menjalankan fungsi yang sama, tetapi menghidupkan transisi dari satu pengontrol tampilan ke yang lain jika Anda memasukkan YA, dan tidak jika Anda melewatkan TIDAK. Ini tampaknya sepenuhnya masuk akal; itu konyol untuk harus menyediakan dua metode di tempat ini hanya supaya Anda dapat menentukan apakah akan menggunakan animasi atau tidak.

Mungkin lebih mudah untuk membenarkan hal semacam ini di Objective-C, di mana sintaks penamaan metode memberikan lebih banyak konteks untuk setiap parameter daripada yang Anda dapatkan dalam bahasa seperti C dan Java. Namun demikian, saya akan berpikir bahwa metode yang menggunakan parameter tunggal dapat dengan mudah mengambil boolean dan masih masuk akal:

file.saveWithEncryption(false);    // is there any doubt about the meaning of 'false' here?