Dijkstra, endişelerin ayrılması hakkında yazarken kod modülerleştirmeyi planladı mı?

İlk olarak, Edsger W. Dijkstra'nın 1974 tarihli "Bilimsel düşüncenin rolü hakkında" bir alıntı okudum:

Size açıklamaya çalışayım, zevkimin ne olduğu tüm zeki düşünme için karakteristiktir. Kişi her zaman kişinin sadece bir yönüyle meşgul olduğunu bilerek, kendi tutarlılığının uğruna tek başına bir konunun bir yönünü derinlemesine incelemeye isteklidir. Bir programın doğru olması gerektiğini biliyoruz ve programı yalnızca bu bakış açısından inceleyebiliriz; bunun da verimli olması gerektiğini biliyoruz ve tabiri caizse verimliliğini başka bir günde inceleyebiliriz. Başka bir ruh halinde kendimize, programın istenip istenmediğini ve neden olup olmadığını sorabiliriz. Ancak, bu çeşitli yönleri aynı anda ele alarak hiçbir şey - tam tersine! Bazen "endişelerin ayrılması" dediğim şeydir, ki bu mükemmel bir şekilde mümkün olmasa bile, bildiğim kişinin düşüncelerini etkili bir şekilde sıralamak için mevcut tek teknik. "Birinin dikkatini bir veçhesine odaklamak" ile kastettiğim budur: bu, diğer veçheleri görmezden gelmek anlamına gelmez, sadece bu veçhenin bakış açısından diğerinin alakasız olduğu gerçeğine adalet yapmaktır. Aynı anda tek ve çok kanallı düşünülmektedir.

Endişelerin modern bir şekilde ayrılmasının kodunuzu modülerleştirmek hakkında konuştuğunu görüyorum. Bununla birlikte, yukarıdaki alıntıyı okurken, bunu zihninizi bir anda belirli bir göreve odaklarken, diğer yönlere odaklanma olarak anlıyorum. Bu benim için kodun modüler parçalara ayrılması gerektiği anlamına gelmez.

Yani, önünüzde bir dosyada tek bir dosyada görünüm, depo, denetleyici, olay işleme, fabrika vb.

Kısa bir örnek için, veri erişimi ve görünümü (çıktı) olan bazı kodlar aşağıdadır:

$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>

Modern OO'yu kullanarak Havuz desenini kullanarak veri erişimine kendi dosyasına yerleştirebilirim, Görünüm kodu kendi dosya şablonuna girebilir ve bunları bir denetleyici (veya Eylem veya İstek İşleyici) aracılığıyla iletişim kurmak için birbirine bağlayabilirim ve çeşitli bağımlılıklar oluşturmak ve bağlamak için bir fabrika ekleyin. Ve bu fabrikaları tanımlayan bir konfigürasyon dosyasına sahip olabilirim. Elbette tek dosyadan her şeyden bir adım uzaktadır.

Endişelerin ayrılması ile ilgili sorum şu şekildedir: Dijkstra'nın sözünü okurken, belki de endişelerin "kodun modüler olarak ayrılması (dosyalara veya kendi işlevlerine / yöntemlerine / vb.)" Olması gerektiği anlamına gelmediğini, ve fiziksel olarak kod içinde ayrılıp ayrılmadığına bakılmaksızın, kendinizi başka önemli ve şu anda dikkate alınamayan diğer yönlere odaklanmaksızın, zihnini programın bir yönüne odaklamak anlamına geliyordu.

O zaman neden kendimizi fiziksel modüler kod ayırma ve tasarım kalıpları ile yüklüyoruz? Kodunuzun nasıl yapılandırıldığından bağımsız olarak, yalnızca bir yönüne odaklanmak yeterli olmayacak mı?

En korkunç spagetti kodunu yazmaktan bahsetmiyorum ve sonra sadece bir yönünü göz önünde bulundurarak, bu muhtemelen bir yük olacaktır. Ama nihayetinde, gidiyorum, neden fiziksel kod ayırma gerçekleştirin, neden zihinsel olarak bir yönüne odaklanmak için gerekli olmadığında, kodu ayrı dosyalara veya parçalara (yöntemlere) ayırın?

Endişelerin ayrılması fiziksel değil zihinsel bir egzersiz olarak mı kalmalı?
Başka bir deyişle, programlamanın zihinsel (odaklanma) ve fiziksel (kağıt üzerindeki kod) yönleri arasında bir bağlantı olmalı mıdır?

Dijkstra nasıl düşünüleceği konusunda açık bir açıklama yapıyor. Program (ve süreç) modülerizasyonu - ve istenirliği - belki de bu düşüncenin bir sonucudur, ancak yaptığı kilit nokta bir sorunun nasıl değerlendirileceğidir. Program tipik olarak bir soruna çözümdür ve “endişelerin ayrılması” nı savunarak akıllıca önerilerde bulunur. Bunun en iyi örneği belki de "optimizasyon" tur. Şaka şuydu: "Bir programı optimize etmeyi planlarken, ilk stratejiniz: Yapmayın." Başka bir deyişle, önce programı düzeltmeye odaklanmak istiyorsunuz. Hızlı ve süslü hale getirilmesi, ayrılması gereken bir sorundur - aynı zamanda tamamen kaldırılmamalıdır.

Endişelerin ayrılması, ilgili olması gerekmeyen şeyleri ayrı ayrı düşünmeyi içeren soyut bir düşünme şeklidir.

Modülerleştirme (ilgisiz fonksiyon grubunu modüllere ayırma), kapsülleme (modüllerin iç detaylarını gizleme) ve soyutlama (genel olanı spesifikten ve fikri uygulamadan ayırma), bu düşünce biçimini etki alanında uygulamak için kullanılan araçlardır. yazılım tasarımı.

Makalenin tarihi bir ilgisi olsa da, 40 yıl önce Dijkstra'nın "endişelerin ayrılması" terimi ile ne kastettiğinin bugün özellikle önemli olmadığını öneririm. Günümüzde, modulizasyona atıfla yaygın olarak kullanılmaktadır.

Modülizasyonun son derece yararlı olduğuna ve bu faydaların bize yüklediği “yüklerden” ağır bastığına dair çok sayıda kanıt bulunmaktadır. Dijkstra ne demek isterse, her biri sadece bir şeye odaklanan küçük kod parçalarının, yazılması, okunması, anlaşılması, sürdürülmesi ve test edilmesi daha kolay olan koda yol açtığı gerçeğini değiştirmez.

Dijkstra'nın kavramlarıyla karşılaştırılabilir olduğunu düşündüğüm endişelerin ayrılmasına dair kişisel bir örnek verebilirim. Yazılımda belirli bir konuyu analiz ettiğimde üç görüş oluşturuyorum.

1. İlk olarak verileri göz önünde bulunduruyorum. Veriler sorunun mantıksal tahminlerini temsil eder. Sınıflar, öznitelikleri soyutlamanın parametreleri olan gerçek dünyadaki soyut varlıklara inşa edilir. Sınıflar arasındaki ilişkiler, sınıf örnekleri arasındaki işlevsel eşlemeleri temsil eder. Bu noktada düşünceye dahil olan bir kod yoktur ve herhangi bir işleme nosyonu yoktur. Konuyla ilgili mantığın sadece statik bir görünümü.
2. İkinci olarak dinamikleri düşünüyorum. Önemsiz bir yaşam döngüsüne sahip herhangi bir sınıf, sonlu durum makinesi olarak modellenmiştir. Bu, sıralama yürütme ve senkronizasyon hususlarını içerir. Yine, hiçbir kod sadece şeylerin nasıl etkileşime girdiğini ve sıralandığını çalışmaz.
3. Üçüncüsü, işlemi düşünürüm. Burada, durum geçişleri veya diğer senkron işlemlerde yapılması gereken gerçek algoritmik çalışma.

Sonunda, konunun üç yönlü bir görünümü elde edilir; bu daha sonra kodun kendisi ve bakımı için uygun olan gruplamalarda kod olarak formüle edilebilir. Üç yönü sadece zihinsel bir egzersiz değildir. Tüm yönleriyle ilgili yazılı açıklamalar hazırlıyorum. Neden? Çünkü eğer konu yeterince büyükse, kısa süreli bellekte tam bir yüzü bile tutamam. Konu küçükse, hemen hemen her yaklaşım işe yarayacaktır, çünkü her şeyi kafanızda tutabilirsiniz.

Endişeleri ayırmak için motivasyon, insanların kısa süreli hafıza sınırlamalarına uyum sağlamaktır. Bilgisayar programcıları, kısa süreli belleklerinde manipüle edebilecekleri kavram sayısı kadar diğer insanlardan daha yetenekli olma eğiliminde olmalarına rağmen, kafamızdaki her şeyi aynı anda taşıyamayız. Etkili olabilmek için endişeleri sistematik olarak ayırmak gerekirbaşka bir belirli özelliğe odaklanmak için sorunun bir veya daha fazla yönünü hariç tutun. Tabii ki, bir yönü hariç tutmak onu gözden kaybolmaz. Bir çözüm elde etmek için tüm sorunlu yönleri birleştirmenin bir yolu olmalıdır. Deneyimler, genellikle ayırma ve rekombinasyonun nihai sonucunun, birçok yönün birbirine karışabileceği tek bir dev sıçramadan daha anlaşılır bir çözüm verdiğini göstermektedir. Bu, özellikle sorunun boyutu büyük veya karmaşık olduğunda geçerlidir.

Endişelerin ayrılması, nasıl uygularsanız uygulansın, kod organizasyon modelinize yayılacak mantıklı bir kavramdır. Bir kod dosyasının sadece teknik bir ayrıntı olduğu ve sizi yazılımın yönetilebilir tutmasının bir yolu olduğu doğrudur. Bölgelerin genişlemesinin daraltılmasına izin veren iyi bir düzenleyiciye sahip tek bir dosya da sizin için çalışabilir (bir süre). Veya sınıfları ve yöntemleri ayrı tablolarda bir üst-alt biçiminde depolayan ilişkisel bir veritabanı bir depolama ortamı olarak çalışabilir. Ancak metin dosyalarının kaynak kodunun olması gereken bir dünyada yenilmesi zor

• taşınabilir
• birçok farklı harici araçla erişilebilir
• birden fazla programcı tarafından erişilebilir
• versiyonlanabilir ve karşılaştırılabilir
• Dosya işlemede çok iyi olan işletim sistemleriyle iyi ölçeklendirin

Sonuç olarak, insanlar aynı anda farklı şeyleri düşünmek veya bunlarla başa çıkmak konusunda çok iyi değiliz. Bu nedenle, o zaman dikkate almadığımız başka bir parçayı mahvetme tehlikesi olmadan, her seferinde bir şey hakkında düşünmeye ve üzerinde çalışmaya izin veren bir modele ihtiyacımız var. Bu nedenle, daha önce döşediğimiz tuğlaların daha sonra döşenen tuğlalara müdahale etmeyeceğinden emin olmak için bir kerede bir tuğla döşiyoruz. Ve daha sonra bir tuğlayı değiştirmek istiyorsak, işler çökmemelidir. Tek parça zihinlerimiz için çalışan bir model.

Bu mantar veya alglerin nasıl büyüdüğü değil ... Bu alçakgönüllü bir gerçek için nasıl?

Ancak Dijkstra'nın sözlerine verilen özel cevabın ele alındığına inanıyorum, ancak "Modern OO'yu kullanarak kendi dosyalarına veri erişimini yerleştirebilirim" ifadesini söyleyin ve "Endişelerin ayrılması fiziksel değil zihinsel bir egzersiz olarak kalmalı mı?" dikkatinizi modern OO müdürlerinin bizi yönlendirdiği yere çekmeme izin verin.

OO kullanarak geliştirmede SOLID ilkelerine uyulmalıdır. İşte onlar için güzel bir bağlantı , ancak "endişelerin ayrılması" ile ilgili TLDR çoğunlukla SOLID: S Tek Sorumluluk Prensibi veya SRP'deki S'de .

Bu, kesinlikle, zihinsel değil fiziksel bir egzersizdir. Özel örneğiniz için, MVC (veya MVVM ve MVP kardeşleri) birini Model, View ve Controller / Presenter / ViewModel konserlerini fiziksel olarak ayrı dosyalara ayırmaya yönlendirir. Ben bunların "kavramları karıştırmak" eğilimini daha da kısıtlamak için ayrı montajlara uygulandığı bazı MVVM uygulamaları gördüm.

Fakat. Bob Amca'nın bu konudaki görüşünü izlerseniz, bu sadece "bu bir görünüm ve bu bir model" in ötesine geçer .

Ayrıca, belirli bir OO elemanı için gereksinimlerin kaynağını da göz önünde bulundurmak gerekir . Mesela Müşterinin Operasyon Personeli'nin istediği şeyi karıştırıyorsanız, SRP'yi de ihlal ediyorsunuz demektir. Ya da Bob Amca'nın yaptığı gibi koymak için: Bir Sınıfın değiştirmek için bir ve sadece bir nedeni olmalıdır.

Sağlanan bağlantıları kullanarak bunu daha fazla araştırmanızı veya "sağlam ilkeler" için bir web araması yapmanızı şiddetle tavsiye ederim.