Pertama, saya membaca kutipan makalah Edsger W. Dijkstra tahun 1974 "Tentang peran pemikiran ilmiah":
Biarkan saya mencoba menjelaskan kepada Anda, apa yang menurut selera saya adalah karakteristik untuk semua pemikiran cerdas. Yaitu, bahwa seseorang bersedia untuk mempelajari secara mendalam suatu aspek materi pelajaran seseorang secara terpisah demi konsistensinya sendiri, sepanjang waktu mengetahui bahwa ia hanya menempati diri sendiri dengan salah satu aspek saja. Kita tahu bahwa suatu program harus benar dan kita dapat mempelajarinya hanya dari sudut pandang itu; kita juga tahu bahwa itu harus efisien dan kita dapat mempelajari efisiensinya di lain hari, jadi untuk berbicara. Dalam suasana hati lain kita mungkin bertanya pada diri sendiri apakah, dan jika demikian: mengapa, program itu diinginkan. Tetapi tidak ada yang diperoleh - sebaliknya! - dengan menangani berbagai aspek ini secara bersamaan. Inilah yang kadang-kadang saya sebut "pemisahan kekhawatiran", yang, bahkan jika tidak sepenuhnya mungkin, adalah satu-satunya teknik yang tersedia untuk memesan pemikiran seseorang secara efektif, yang saya tahu. Inilah yang saya maksudkan dengan "memusatkan perhatian seseorang pada beberapa aspek": itu tidak berarti mengabaikan aspek-aspek lain, itu hanya berlaku adil terhadap kenyataan bahwa dari sudut pandang aspek ini, yang lain tidak relevan. Ia sedang berpikiran satu dan banyak jalur secara bersamaan.
Saya melihat pemisahan kekhawatiran modern berbicara tentang modularisasi kode Anda. Namun, membaca kutipan di atas, saya memahami ini sebagai memfokuskan pikiran Anda pada satu tugas tertentu pada satu waktu, sementara tidak fokus pada aspek lain. Bagi saya ini tidak berarti bahwa kode perlu dipisahkan menjadi potongan modular.
Maksudnya, katakan ada kode di depan Anda yang dalam satu file memiliki konsep view, repository, controller, event handling, factory, dll. Semuanya dalam satu file.
Untuk contoh singkat, inilah beberapa kode yang memiliki akses data, dan lihat (keluaran):
$sql = "SELECT * FROM product WHERE id = " . db_input($id);
$row = db_fetch_array(db_query($sql));
<option value="<?=$row['id']?>"<?= $row['ver'] == $row['ver'] ? ' selected="selected"' : '' ?>>Version <?=$row['ver']?></option>
Dengan menggunakan OO modern saya dapat menempatkan akses data dalam file sendiri menggunakan pola Repositori, kode View dapat masuk ke templat file sendiri, dan saya bisa menghubungkan mereka bersama untuk berkomunikasi melalui controller (atau Action atau Request Handler), dan saya bisa tambahkan pabrik untuk membuat dan memasang berbagai dependensi. Dan saya dapat memiliki file konfigurasi yang mendefinisikan pabrik-pabrik itu. Tentunya itu adalah langkah menjauh dari file tunggal segalanya.
Pertanyaan saya tentang pemisahan masalah adalah seperti ini: membaca kutipan Dijkstra, saya mendapat ide bahwa mungkin dia tidak bermaksud bahwa pemisahan kekhawatiran menjadi "pemisahan kode secara modular (ke dalam file atau fungsi / metode / dll mereka sendiri"), dan yang ia maksudkan adalah lebih memfokuskan pikiran seseorang pada aspek program, tanpa membebani diri Anda berfokus pada aspek penting lainnya yang belum dipertimbangkan saat ini, terlepas dari apakah mereka secara fisik dipisahkan dalam kode, atau tidak.
Lalu mengapa kita membebani diri kita sendiri dengan pemisahan kode modular fisik dan pola desain? Apakah tidak cukup hanya dengan memfokuskan diri pada suatu aspek, terlepas dari bagaimana kode Anda disusun?
Saya tidak berbicara tentang menulis kode spageti paling mengerikan dan kemudian hanya mempertimbangkan aspek itu, yang mungkin akan menjadi beban. Tetapi pada akhirnya, apa yang akan saya tuju adalah, mengapa melakukan pemisahan kode fisik, mengapa membagi kode menjadi file atau bongkahan terpisah (metode), ketika tidak perlu secara mental memfokuskan diri Anda pada suatu aspek?
Haruskah pemisahan kekhawatiran tetap menjadi latihan mental, bukan fisik?
Dengan kata lain, haruskah ada keterputusan antara aspek pemrograman mental (fokus pada) dan fisik (kode pada kertas)?
IF, WHILE, FORbukan GOTO. Modular = modul dengan API publik yang terdefinisi dengan ketat dipisahkan dari implementasi dan representasi internal yang tersembunyi. (Misalnya, Modula, Mesa, Modula-2, Modula-3, kemudian dialek Pascal ( UNIT).)