Prosedürel programlama döneminin Tasarım Kalıpları neydi? [kapalı]

Benzer: Programlama 20 yıl önce nasıl yapıldı?

OOP , 1960'larda Simula 67'de kökleri bulunan ve daha sonra Smalltalk ve C ++ tarafından popüler hale getirilen kökler, bugünlerde oldukça moda . DRY, SOLID, nesne yönelimli dünyadaki tasarım kalıpları hakkında birçok kitabımız var.

Ancak, OOP paradigması çapında kabul edilmeden önce programlamadaki ana ilkeler nelerdi? Ve ana tasarım desenleri neydi?

Java'yı öğrenmeden önce bir Cobol geliştiricisiydim. 35 yıldan fazla bir süredir gelişiyorum.

Usul dilleri günlerinde, işlemlerin çoğu toplu olarak yapıldı. Tarihte yeterince geriye gidin ve program derlemesi bile toplu iş yumruk destesiyle yapıldı.

Kilian Foth'un iddiasının aksine , 1970'lerde ve 1980'lerde tasarım desenlerine sahibiz. Cobol'da çoklu dosya eşleşmesini / birleştirmeyi kodlamanın belirli bir yolu vardı. Cobol'da master (tape) dosyasına işlem ekleme kodunun belli bir yolu vardı. Cobol'da rapor üretimini kodlamanın belirli bir yolu vardı. Bu nedenle IBM'in Rapor Yazarı, pek çok Cobol mağazasında hiç çekiş yapmadı.

DRY ilkesinin erken bir uygulaması vardı. Çok sayıda paragraf oluşturun, böylece kendinizi tekrar etmeyin. 1970'lerde yapısal kodlama teknikleri geliştirildi ve Cobol, 1985'te dile yapısal kelimeler (fiiller) ekledi.

Genel olarak, yeni bir Cobol programı yazdığımızda, eski bir Cobol programını kopyaladık ve masum olanı korumak için isimleri değiştirdik. Bir Cobol programını neredeyse hiç boş bir sayfa veya boş ekrandan kodlamadık. Tüm programları kopyalayıp yapıştırabileceğiniz zaman bu büyük bir tasarım kalıbıdır.

Bir Cobol programcısının hepsini öğrenmesi yıllar alacağı kadar çok Cobol tasarım deseni vardı. Bu, günümüzde Cobol programcılarının çoğunlukla 1985 sözdizimini kullanıyor olmasının bir nedeni.

Yazılımda “tasarım kalıpları” bahsettiğiniz çağda yoktu, çünkü kavram icat edilmemişti. Bu bana küstah olma değil - aslında bir nedeni; tanınabilir bir ad olarak adlandırmak, bir Tasarım modelini, bir formda veya başka bir şekilde kullanmaya devam ettiğiniz bir koddan ziyade “Tasarım deseni” yapan şeydir (örneğin, “kullanmak yerine sevdiğim bir statik sınıf türü yerine” bir “Fabrika” yapıcıların çeşitliliği ") ve kavramın kendisi istisna değildir.

Tabii ki, uygulayıcıların çalışmalarında tasarım desenlerinin şimdi yaptığı gibi tam olarak aynı rolü üstlenen şeyler vardı. Ancak onlar hakkında duymakta hayal kırıklığına uğrayacaksınız: o günlerde tipik "guru hilesi" bizim için çok sıkıcı olan şeylerdi - örneğin, tek tek bağlı listeler, her yinelemede artmış bir indeks tarafından kontrol edilen döngüler "hiçbir şey yapmamış gibi görünen yöntemler, uygulama detaylarıyla ilgili fikrinizi daha sonra değiştirmenize yol gösterecek.

Bu doğru, şu anda kabul ettiğimiz şeyler - bazen kullandığımız dillerin bile bir parçası - yalnızca daha deneyimli kodlayıcılar tarafından bilinen ileri (bazen kıskançlıkla korunan) kavramlardı. Muhtemelen, bugün temel bir programlama kursunda öğrendiğiniz çok önemsiz olmayan hemen hemen her şey, bugünün uygulayıcıları için bir "Tasarım modeline" ahlaki olarak eşdeğer bir aşamadan geçti. Yazılım yapımı henüz titiz bir mühendislik disiplini olmayabilir, ancak 50'li ve 60'ların sanatının durumunu incelerseniz, başlangıçtan beri çok büyük bir yoldan geldiğini inkar edemezsiniz .

Önceki büyük paradigma yapısal programlamaydı . UML yerine, çeşitli farklı şemalar (akış şemaları, veri akış şemaları, yapı şemaları, vb.) Vardı. Gelişme çoğunlukla yukarıdan aşağıya doğru yapıldı ve işlevsel bir ayrışma sürecini takip etti. Temel fikirlerden biri, program yapınızın bir pırlantaya benzemesi gerektiği idi: Üstteki ana modül, alt seviye modüllerde rutinleri çağıran yüksek seviye kontrol modüllerine yayılıyor. Bu düşük seviyeli modüller hala düşük seviyeli modüller üzerine inşa edilmiştir, bunların hepsi (teorik olarak) sonunda bir avuç temel I / O rutini üzerinde birleşir. Yüksek seviye modüllerin program mantığını içermesi gerekiyordu, düşük seviye olanlar veri bütünlüğü ve hata yönetimi ile daha fazla ilgiliydi.

Bu süre zarfında sunulan önemli kavramlar bilgi gizleme, modülerlik ve yüksek uyum / düşük eşleşme idi. Bu konularla ilgili bazı seminal yazılar için Dave Parnas'ın eserlerine bakınız . Ayrıca Larry Constantine, Tom DeMarco ve Ed Yourdon'un çalışmalarını inceleyin.

Sanırım büyük bir tane (yapılandırılmış programlamanın yanı sıra) etrafta dolaşmak kavramıydı - OO'da bir nesneniz var ve durum ve işlevsellik içeriyor. OO'dan önce, bir çok bağımsız fonksiyona sahip olacaktınız ve aralarında bazı durumlara bir tutamaç verecektiniz - isterseniz bir kurabiye. Bu size gerçekten OO kullanmadan OO prensiplerini verdi.

Bunu çok fazla eski Win32 kodunda görebilirsiniz, Windows çekirdeğinde tahsis edilen bazı halleri temsil eden bir opak tip olan bir HANDLE'ye geçersiniz. Daha önce bu veriler üzerinde çalışan fonksiyonlara ilk parametre olarak tahsis ettiğiniz bir yapıya bir işaretçi vererek kendiniz yapabilirsiniz.

Henüz kimse bariz olandan bahsetmediğinden: prosedürel dönemde büyük bir tasarım deseni Nesne idi. Daha önceki (örneğin Altprogram) ve sonraki (örneğin, Iterator) birçok popüler tasarım deseni gibi, o kadar popüler hale geldi ki, dil desteği bile aldı.

Bir "sonlu durum makinesi" bir Patern olarak sayılabilir ve FSM'ler OO öncesi dilleri kullanarak yazılmıştır (örneğin iletişim protokolleri için).

Ayrıca "kesme işleyicileri" ve TSR'ler eskiden örneğin DOS'ta popülerdi.

"Spagetti Kodu" ve "Tek Çıkış Noktası" gibi terimler aslında o dönemin geri dönüşleridir. Bugünlerde kod çağırıyoruz "spagetti kodu" nu sevmiyoruz, ancak bu gerçekten GOTO'lar ve JMP'lerle birbirine bağlanmış (kötü) bir kod referansı.

(Bugün, kodun, bir grup mantı tabağı gibi, birbiriyle ilgisiz, sıkı bir şekilde paketlenmiş sınıflar gibi olduğu "mantı kodu" ile uğraşıyoruz. Ancak, bazı OO uzmanları haklı bir şekilde soruyorlar " gibi görünmek?")

"Tek Çıkış Noktası" bugün sadece sinir bozucu bir refactoring yol patlaması. Konuştuğum bir sürü cihaz daha duymadım ve açıkladığımda çok üzülüyorlar. Ancak eski günlerde bir kod bloğundan aniden çıkıp spagetti koduna atlanmadığı anlamına geliyordu. Mantığın sonuna ilerleyin, sonra dikkatlice çıkın.

Hafızamı esnetiyorum, geri döndüğümde, kodları prosedürlere yerleştirme fikrinin büyük bir adım olduğunu hatırlıyor gibiyim. İşlemleri birlikte çalışabilir, yeniden kullanılabilir Modüller halinde paketleyebileceğiniz düşüncesi, bir çeşit Kutsal Kase programlamadır.

EDIT: "Kendini değiştiren kod" aynı zamanda özellikle orijinal Doom'da kullanılan bir kalıptı. Programın, durumuna göre daha hızlı talimatlarla talimatlarının üzerine yazılacağı yer burasıdır. Bilim Müzesi'nde bir programlama kursuna girdiğimde, eğitmenim bizi sertçe uyardı, "Kendini değiştiren kod yazma!"

EDIT EDIT: Ancak, İnternetten önce, kelime çok daha yavaş gitti. Algoritma ve Veri Yapılarını uygulama fikri çok daha büyük bir anlaşma olarak kullanılıyordu. Bugün ne tür kullandığımı bile bilmeden her zaman sıralarım. Ama o zaman kendin kodlamak zorunda kaldın. Bugün yarım saat içinde ya da daha az sürede çaldığımız günler süren programlama zorluklarından bahseden bir makaleyi hatırlıyorum. Öyleyse gerçekten bilinçli "algoritmik" ve "veri yapıları" programlaması muhtemelen bugünden çok daha fazla listede olacak.