Alan Kay’in Smalltalk ve erken GUI’lerin ardındaki temel fikirlerini keşfedin—yazılımı nesnelerin etkileştiği sistemler olarak görmenin bugünümüzü nasıl şekillendirdiğini öğrenin.
Alan Kay sadece programlama tarihinden bir isim değil. Bilgisayarlar hakkında taşıdığımız birçok günlük varsayım—bir “pencere”nin ne olduğu, yazılımın neden etkileşimli olması gerektiği, programların işbirliği yapan parçalardan nasıl inşa edilebileceği—çoğunun şekillenmesinde onun ileri sürdüğü fikirlerin payı büyük (çoğu zaman Xerox PARC ekipleriyle birlikte).
Bu yazı magazinsel detaylardan çok kavramlar hakkında. Takip etmek için kod bilmenize gerek yok; gizli teknik ayrıntılardan oluşan bir tur da sunmuyoruz. Bunun yerine, araçlar ve ürünlerde hâlâ görünen birkaç zihinsel modele odaklanacağız: yazılımın nasıl anlaşılabileceği, değiştirilebileceği ve öğrenilebileceği.
İlk olarak, Smalltalk: yalnızca bir programlama dili değil, keşif ve öğrenmeyi teşvik eden tüm bir çalışma ortamı.
İkincisi, GUI'ler (grafiksel kullanıcı arayüzleri): pencereler, simgeler, menüler—etkileşimli yazılımın sadece komut verilerek değil, doğrudan elle tutulur şekilde yönetilebilmesi.
Üçüncüsü, sistem düşüncesi: yazılımı dosya yığınları olarak değil, geri besleme döngüleri olan etkileşen parçalar bütünü olarak görmek.
Kay'i yalnız bir dahî gibi göstermeyeceğiz ve tek bir “doğru” paradigmanın her şeyi çözdüğünü iddia etmeyeceğiz. Bazı fikirler parlak şekilde işe yaradı, bazıları yanlış anlaşıldı, bazıları ise gerektiği kadar yayılmadı.
Ama amaç pratik: sonunda modern uygulamalara ve kod tabanlarına bakarken neden böyle hissettiklerini daha net görmeli ve bir sonraki projede ödünç alabileceğiniz yaklaşımları fark etmelisiniz.
Alan Kay, güçlü ama pahalı ve sıradan insanlara kayıtsız kalan bir bilgisayar kültürüne girdi. Bilgisayarlar paylaşılan altyapı gibi davranıyordu: zaman ayırır, işi gönderir, sonuç için beklersiniz. Bu model her şeyi şekillendiriyordu—programların nasıl göründüğünü, kimlerin kullanabildiğini ve “başarının” ne anlama geldiğini.
Birçok kullanıcı için bilgisayar, makineye bir iş vermek (kartlarla ya da kuyruklu terminallerle) ve daha sonra çıktı almak demekti. Bir şey ters giderse, “kurcalayıp” öğrenemezdiniz—yeniden gönderir ve tekrar beklersiniz. Keşif yavaştı ve bilgisayar, düşünmek için kullandığınız bir araçtan çok uzaktan bir hizmet gibi hissettiriyordu.
Kay'in hedefi sadece "daha küçük bilgisayarlar" değildi. Farklı bir ilişkiydi: bir bilgisayarın, özellikle çocuklar ve uzman olmayanlar için öğrenme, yazma, simülasyon, çizim ve fikir inşa etme aracı olması. Bu, anındalık gerektiriyordu. Yaptıklarınızın ne yaptığını görmeli, hızlıca düzeltmeli ve yaratıcı akışı sürdürebilmeliydiniz.
Böyle bir değişikliği takip etmek için donanım, yazılım ve etkileşim tasarımını birlikte denemeye alan veren laboratuvarlara ihtiyaç vardı. Xerox PARC gibi araştırma laboratuvarları uzun vadeli bahisler finanse etti: yeni ekranlar, yeni giriş cihazları, yeni programlama modelleri ve bunları uyumlu bir deneyimde paketleme yolları. Amaç bir özelliği piyasaya sürmek değil—yeni bir bilgisayar kullanım türü icat etmekti.
Bilgisayar bir öğrenme ve üretim makinesi olacaksa kullanılabilirlik sonradan düşünülmeyecek kadar önemliydi. Arayüz keşfi, geri bildirimi ve anlaşılabilir eylemleri desteklemeliydi. Bu odak, Kay'i etkileşimin “hissi”nin—tıklayınca, düzenleyince ya da keşfederken ne olduğu—yazılımın kendi yapısıyla sıkı bağ içinde olduğu sistemlere yönlendirdi.
Alan Kay "Ofis işlerini nasıl hızlandırırız?" diye başlamadı. Farklı bir soru sordu: ya bir çocuk bir kitap gibi taşınabilir kişisel bir bilgisayara sahip olsaydı ve fikirleri keşfetmek, bir şeyler yapmak ve öğrenmek için onu kullansaydı? Bu fikir Dynabook oldu—bir ürün spesifikasyonu olmaktan çok kişisel bilişim için bir kuzey yıldızıydı.
Dynabook hafif, pil ile çalışan ve her zaman erişilebilir hayal edilmişti. Ama en önemli kelime "taşınabilir" değildi. "Kişisel"ydi. Bu bilgisayar, bir defter veya bir enstrüman gibi kullanıcısına ait olacaktı—zaman içinde şekillendirdiğiniz bir şey, sadece işletilen bir cihaz değil.
Aynı zamanda öğrenilebilir olmalıydı. Kay'in hedefi bilişimi menü duvarlarının arkasına saklamak değil; insanların tüketici değil yazar olmaya kademeli olarak geçmelerini sağlamaktı.
Dynabook'un "killer app"leri okuma, yazma, çizim, müzik besteleme, bilimsel deneyleri simüle etme ve etkileşimli hikayeler oluşturmaydı. Programlamayı profesyonellere ayrılmış özel bir işten ziyade bir ifade biçimi—okuryazarlık—olarak ele alıyordu.
Bu odak, "iyi yazılım"un ne olduğu algısını değiştirir. Bir öğrenme aracı teşvik edici olmalı, hızlı geri bildirim vermeli ve tekrar denemeyi güvenli kılmalı.
İşte Smalltalk ve erken grafiksel arayüzlerin burada devreye girdiği yer. İnsanların yaratması için doğrudan manipülasyon, anında sonuçlar ve denemeyi doğal hissettiren bir ortam gerekir. Smalltalk'un canlı, etkileşimli sistemi ve GUI'nin görsel metaforları aynı hedefi destekliyordu: bir fikir ile çalışan bir nesne arasındaki mesafeyi kısaltmak.
Dynabook "tableti tahmin etmiyordu"; hesaplama ile yeni bir ilişki öneriyordu: düşünce ve yaratım için bir ortam. Birçok cihaz buna yaklaşabilir, ama vizyon kullanıcıları güçlendirmekle ilgili—özellikle öğrenenleri—özel bir ekran boyutu veya donanım tasarımı değil.
“Smalltalk” denildiğinde insanlar genellikle bir programlama dili düşünür. Kay'in ekibi onu daha büyük bir şey olarak gördü: dil, araçlar ve kullanıcı deneyiminin bir arada tasarlandığı tam bir çalışma sistemi.
Basitçe söylemek gerekirse, Smalltalk her şeyin nesne olduğu bir sistemdir. Ekrandaki pencereler, yazdığınız metin, tıkladığınız düğmeler, yaptığınız hesaplamalar—her biri bir nesnedir ve onlara bir şeyler yapmaları için sorular sorabilirsiniz.
Smalltalk öğrenerek yapma için inşa edildi. Kod yazıp derleyip ummak yerine, sistemi çalışırken inceleyebilir, nesnelerin mevcut durumunu görebilir, onları değiştirebilir ve hemen yeni bir fikri deneyebilirsiniz.
Bu canlılık önemlidir çünkü programlamayı keşfetmeye dönüştürür. Sadece dosyalar üretmiyorsunuz; çalışan bir dünyayı şekillendiriyorsunuz. Bu merakı teşvik ediyor: "Bu şey nedir?" "İçinde ne var?" "Biraz değiştirirsem ne olur?"
Smalltalk'un geliştirme araçları ayrı eklentiler değildi. Tarayıcılar, inceleyiciler, hata ayıklayıcılar ve editörler aynı nesne tabanlı evrenin parçasıydı. Araçlar sistemin içini anlıyor çünkü aynı ortamda inşa edilmişlerdi.
Bu sıkı entegrasyon, "yazılım üzerinde çalışmak" hissini değiştirdi: uzak kaynak kodu yönetmek gibi değil, inşa ettiğiniz sistemle doğrudan etkileşimde bulunmak gibi.
Açık ve tepki veren bir belgeyi düzenlemeyi düşünün—formatlama anında değişir, arama, yeniden düzenleme ve geri alma belgenin yeniden "inşa" edilmesini gerektirmez. Smalltalk programlar için o tür bir anındalığı hedefliyordu: çalışan şeyi düzenlersiniz, sonucu hemen görürsünüz ve ilerlemeye devam edersiniz.
Kay'in en kullanışlı zihinsel modeli "sınıflar ve kalıtım" değil. Bir nesnenin küçük, kendi kendine yeten bir bilgisayar olduğu fikriydi: kendi durumu (şu an ne bildiği) vardır ve siz ona bir şey yapmasını istediğinizde nasıl yanıt vereceğine kendisi karar verir.
Her nesneyi şu şekilde düşünebilirsiniz:
Bu çerçeve pratik çünkü dikkatinizi "veri nerede saklanıyor?" sorusundan "bunun sorumluluğu kimde?" sorusuna kaydırır.
Yaygın bir karışıklık, nesneleri sadece alanları ve birkaç yardımcı fonksiyonu olan şık veri kayıtları gibi görmek. Bu görüşte diğer program parçaları içeri serbestçe bakıp içini değiştirir.
Kay'in görüşü ise aktörlere daha yakındır. Bir nesnenin içine el uzatıp çekmecelerini düzenlemezsiniz. Ona bir istek gönderir ve kendi durumunu yönetmesine izin verirsiniz. Bu ayrım temel noktadır.
Mesajlaşma basitçe istek/yanıt demektir.
Bir kafeyi düşünün: mutfağa girip yemeği kendiniz yapmazsınız. Sipariş verirsiniz ("bana bir sandviç yapın"), ve bir sonuç alırsınız ("işte sandviçiniz" veya "ekmek kalmadı"). Kafe isteği nasıl yerine getireceğine karar verir.
Yazılım nesneleri de aynı şekilde çalışır: bir mesaj gönderirsiniz ("toplamı hesapla", "kaydet", "kendini çiz"), ve nesne yanıt verir.
Sistem parçalarının yalnızca mesajlara bağlı olması, bir nesnenin iç işleyişini değiştirebilmenizi sağlar—algoritmayı değiştirmek, depolamayı değiştirmek, önbellek eklemek—diğer tarafları yeniden yazmadan.
Bu, sınırlarında sabit anlaşmalar, bileşenlerin içinde özgürlük sağlayarak sistemlerin büyümesini ve kırılmamasını sağlar.
İnsanlar genellikle "nesne yönelimli programlama"yı "sınıflar kullanmak" ile eşitler. Bu anlaşılabilir—çoğu dil OOP'yi sınıf diyagramları ve kalıtım ağaçlarıyla öğretir. Ama Kay'in asıl vurgusu farklıydı: iletişim kuran parçalar olarak düşünün.
Bir sınıf bir şablondur: bir şeyin ne bildiğini ve ne yapabildiğini tanımlar.
Bir örnek (veya nesne) o şablondan yapılmış somut şeydir—o spesifik "bir tane".
Bir metot bir nesnenin istek alındığında gerçekleştirebileceği işlemdir.
Durum nesnenin şu anki verisidir: zaman içinde değişebilen hafızası.
Smalltalk, her şeyin nesne olduğu tek tip bir modelin popülerleşmesine yardımcı oldu: nesnelerle tutarlı şekilde etkileşirdiniz. Ayrıca mesajlaşmaya ağırlık verdi—başka bir nesnenin içini kurcalamak yerine ona bir mesaj gönderir ve onun nasıl yanıtlayacağını beklersiniz.
Bu tarz, genellikle dinamik bağlama (çalışma zamanında hangi metodun mesajı işleyeceğini belirleme) ile eşleşir: pratik fayda esnekliktir—davranışları çağıranı yeniden yazmadan değiştirebilirsiniz.
Faydalı bir kestirme: tasarımı etkileşimler etrafında kurgulayın. "Hangi mesajlar olmalı?" ve "Bu durumda sorumluluk kimde olmalı?" diye sorun. Nesneler temiz bir şekilde işbirliği yaparsa, sınıf yapısı genellikle daha basit ve değişime daha uygun hale gelir.
Bir grafiksel kullanıcı arayüzü (GUI), "yazılım kullanmak" hissini değiştirdi. Komutları ezberlemek yerine, işaret eder, taşır, açar ve sonuçları hemen görürdünüz. Pencereler, menüler, kontroller ve sürükle-bırak, bilgisayarı fiziksel nesnelere dokunur gibi hissettirdi—doğrudan manipülasyon, soyut talimatların ötesinde.
Bu "şey-hissi" nesne modeline doğal olarak uyar. İyi tasarlanmış bir GUI'de görünen ve etkileşime girilebilen neredeyse her şey bir nesne gibi ele alınabilir:
Bu sadece programlama kolaylığı değil; kullanıcı için kavramsal bir köprü. Kullanıcı "bu pencereyi taşı" derken, yazılım gerçekten bu eylemi yapabilecek nesnelerden oluşur.
Tıkladığınızda, yazdığınızda veya sürüklediğinizde sistem bir olay üretir. Nesne-yönelimli bakışta bir olay temelde bir nesneye gönderilen bir mesajdır:
Nesneler sonra mesajları başka nesnelere iletebilir ("belgeye kaydetmesini söyle", "pencereye yeniden çizmesini söyle"), böylece anlaşılabilir etkileşim zincirleri oluşur.
Çünkü UI kalıcı durum sahibi görünen nesnelerden oluşur, bir çalışma ortamına giriyormuşsunuz gibi hissedersiniz. Pencereleri açık bırakabilir, araçları düzenleyebilir, belgeye geri dönüp kaldığınız yerden devam edebilirsiniz. GUI, eylemlerin gördüğünüz nesnelerle yapılan konuşmalar olduğu tutarlı bir çevre haline gelir.
Smalltalk'un ayırt edici fikirlerinden biri sözdizimi değil—image idi. Bir programı "derlenen kaynak kod" olarak görmek yerine, Smalltalk sistemi çalışan nesneler dünyası olarak ele aldı. Kaydettiğinizde tüm çalışan ortamı kaydedebilirdiniz: bellekteki nesneler, açık araçlar, UI durumu ve yaptığınız işin mevcut hali.
Image tabanlı bir sistem, bir filmi durdurup sadece senaryoyu değil, tam kareyi, seti ve her oyuncunun pozisyonunu kaydetmek gibidir. Devam ettiğinizde bıraktığınız yerde tekrar başlarsınız—araçlar açık, nesneler etrafta ve değişiklikler zaten hareket halinde.
Bu sıkı geri bildirim döngülerini destekler. Davranışı değiştirebilir, hemen deneyebilir, gözlemleyebilir ve iyileştirebilirsiniz—"yeniden derle, yeniden başlat, veriyi yeniden yükle, ekrana geri git" zihinsel sıfırlaması olmadan.
Bu ilke modern "vibe-coding" iş akışlarında da yankı bulur: bir değişikliği düz metinle tanımlayıp hemen uygulandığını görüp yineleyebiliyorsanız, sistemi daha hızlı öğrenir ve ivmeyi korursunuz. Platformlar gibi Koder.ai, sohbet tabanlı döngüyle uygulama inşa etmeyi—planla, ayarla, önizle—kod dışa aktarılabilir ve sürdürülebilir hâlde üretmeyi amaçlar.
Günümüzde image fikrinin izlerini şu özelliklerde görebilirsiniz:
Bunlar Smalltalk image'leriyle aynı değil, ama hedefleri ortak: fikir ile sonuç arasındaki mesafeyi olabildiğince kısaltmak.
Tüm çalışan dünyayı kaydetmek zor sorular getirir. "Gerçek" değişken bir durumda yaşıyorsa tekrar üretilebilirlik zedelenebilir. Dağıtım karmaşıklaşabilir: bir image göndermek uygulama, veri ve ortam arasındaki çizgiyi bulanıklaştırır. Hatalar, belirli etkileşim dizilerine ve birikmiş duruma bağlıysa hata ayıklamak daha karmaşık hâle gelebilir.
Smalltalk'un bahsi, daha hızlı öğrenme ve yineleme yapmanın bu komplikasyonlara değdiği yönündeydi—ve bu bahis hâlâ birçok ekibin geliştirici deneyimini düşünme biçimini etkiliyor.
Alan Kay yazılıma daha az tek bir bileşenle tanımlanan, daha çok ilişkilerle tanımlanan bir sistem gözüyle bakardı: kim kiminle konuşuyor, ne sorabilirler ve bu konuşmalar tekrarlandıkça ne oluyor.
Birkaç basit bileşen, tekrar ve geri bildirim eklediğinizde karmaşık davranışlar üretebilir. Bir zegger (zamanlayıcı) tıklar, bir model durumu günceller ve bir UI yeniden çizer—her biri basitse bile bir araya geldiğinde animasyonlar, geri al/yineleme, otomatik kaydetme, uyarılar ve "neden bu şimdi değişti?" anları ortaya çıkar.
Bu yüzden sistem düşüncesi pratiktir: "A değiştiğinde B ne tepki veriyor, bu C'yi nasıl tetikliyor" gibi döngülere ve zamana bakmanızı sağlar.
Bir sistemde, arayüzler uygulamadan daha önemli olabilir. Bir parça diğerine sadece net mesajlarla bağlanabiliyorsa ("sayacı artır", "çiz", "olayı kaydet"), iç mekanizmaları değiştirebilirsiniz ve diğerleri etkilenmez.
Bu, Kay'in mesajlaşma vurgusuna yakındır: diğer parçaları doğrudan kontrol etmezsiniz; istersiniz, onlar yanıt verir.
Üç nesne hayal edin:
Zaman içindeki akış:
clicked gönderir.increment gönderir SayaçModeline.changed(newValue) gönderir.changedi dinleyip yeniden çizer.record("increment", newValue) alır.Hiçbir bileşen diğerinin içine bakmak zorunda değil. Davranış, nesneler arasındaki konuşmadan ortaya çıkar.
Alan Kay basitçe şunu savundu: yazılım güçlülüğün ötesinde öğrenmesi kolay olmalı. "Zekice" tasarım genellikle yaratıcının memnuniyetini optimize eder—kısayollar, gizli numaralar, yoğun soyutlamalar—başlangıçtaki kullanıcıları ritüeller ezberlemeye mahkûm eder.
Kay, sadeliği önemsiyordu çünkü ölçekleniyor: bir başlangıç kavramını hızlıca kavrayabilen bir fikir, takımların öğretebileceği, paylaşabileceği ve üzerine inşa edebileceği bir şeydir.
Birçok yazılım kullanıcıyı işletici gibi ele alır: doğru düğmelere bas, çıktıyı al. Kay'in hedefi düşünme aracına yakın bir şeydi—keşfetmeye davet eden, deneme-yanılmayı destekleyen ve insanların zihinsel modeller kurmasına izin veren bir sistem.
Bu yüzden etkileşimli, hemen yanıt veren sistemlere değer verdi. Sistem hemen ve anlamlı tepki verince, öğrenme kullanmanın bir parçası hâline gelir.
Kay sık sık öğrenmeyi—bazen kullanıcıları çocuklar olarak hayal ederek—bir netlik zorlayıcısı olarak kullandı. Bir kavram doğrudan manipüle edilebiliyor, incelenebiliyor ve açıklanabiliyorsa, geniş kitleler için işe yarama olasılığı yüksek olur.
Bu, "sadece çocuklar için tasarla" demek değil. Ama öğretilebilirliği bir kalite testi olarak kullanmak demek: sistem kendi mantığını açığa çıkarabiliyor mu?
Öğrenilebilirlik bir ürün özelliğidir. Bunu şu yollarla tasarlayabilirsiniz:
Kazanç sadece daha mutlu yeni kullanıcılar değil; daha hızlı adaptasyon, daha az destek talebi ve kullanıcıların ürünü genişletme konusunda kendini daha yetkin hissetmesi—Kay'in yazılımın güçlendirmesini istediği türden sonuçlar.
Kay'in çalışmaları "şimdi kullandığımız her şeyi icat etti" demek doğru değil, ama insan odaklı yazılım inşasına nasıl yaklaşılacağını güçlü biçimde etkiledi—özellikle insanlar için tasarlanmış yazılımlarda.
Modern uygulamalarda birçok pratik yaklaşım Smalltalk ve Xerox PARC kültürünün somutlaştırdığı fikirleri yansıtıyor:
Orijinal vizyonun bazı parçaları tam olarak taşınmadı:
Biraz uzağa bakınca, güncel kalıpların çoğu mesajlaşma ile uyumlu: bileşen tabanlı UI'lar (React/Vue), olay güdümlü uygulamalar ve hatta mikroservisler HTTP veya kuyruğa dayalı iletişimle. Bunlar aynı şey değil ama Kay'in temel fikri—etkileşen parçalar olarak sistemler—modern kısıtlar altında yeniden yorumlanıyor.
Uygulamaya dönük köprü istiyorsanız, tarih ile pratik arasındaki bu etkileri doğrudan günlük tasarım alışkanlıklarına çeviren son bölüm (bkz. /blog/practical-takeaways) hemen kullanılabilir öneriler sunar.
Kay'in işleri felsefi gelebilir, ama çok pratik alışkanlıklara dönüşür. Smalltalk kullanmanıza gerek yok—hatta gerçekten OOP yapmanıza bile gerek yok—fayda alabilirsiniz. Amaç, büyüdükçe anlaşılır kalan yazılımlar inşa etmek.
Başlarken (veya refaktör ederken) sistemi birlikte çalışan roller seti olarak tanımlamayı deneyin:
Bu, sizi "sınıf kullanıyoruz çünkü sınıfa ihtiyacımız var" tuzağından uzak tutar.
Veritabanı tabloları veya sınıf hiyerarşileri hakkında tartışmadan önce mesajları tanımlayın—bir parçanın diğerine ne sorduğunu.
Faydalı bir egzersiz: bir kullanıcı eylemi için kısa bir "konuşma" yazın:
Sonra rollerin nasıl uygulanacağına karar verin (sınıflar, modüller, servisler). Bu Kay'in vurguladığı gibi önce davranış, sonra yapı yaklaşımıdır.
Kay canlı sistemleri ve değişikliklerin etkisini hızlı görmeyi önemsiyordu. Modern bir ekipte bu genellikle:
Bir değişikliğin ne yaptığını ya da yarayıp yaramadığını söyleyemiyorsanız kör uçuyorsunuz demektir.
Sohbet odaklı iş akışlarıyla çalışıyorsanız (ör. Koder.ai içinde), aynı tavsiyeler geçerlidir: istemler ve üretilen çıktılar yineleme hızınızı artırır, ama sınırları açık tutun ve anlık görüntüler/geri alma ile kaynak kodu dışa aktarma gibi koruyucular kullanarak sistemin anlaşılabilirliğini koruyun.
İlginizi çektiyse inceleyin:
Bu konular nostalji değil; öğrenilebilir, uyarlanabilir ve sistem olarak uyumlu yazılımlar inşa etme zevkini geliştirmekle ilgili bir zevk ve tad geliştirmektir.
Alan Kay, bilgisayarla ilişkiyi kökten değiştirmeyi savundu: kuyrukla işleyen toplu işlemler yerine etkileşimli, kişisel bir öğrenme ve üretim ortamı.
Bu zihniyet, bugün normal kabul ettiğimiz beklentileri doğrudan şekillendirdi—anında geri bildirim, keşfedilebilir arayüzler ve çalışırken keşfedilip değiştirilebilen yazılımlar.
Dynabook, taşınabilir ve kişisel bir bilgisayar vizyonuydu; önceliği öğrenme ve yaratıcılık idi (okuma, yazma, çizim, simülasyon).
Ama önemli olan "tabletleri öngördü" demek değil; asıl katkı, kullanıcıların operatör değil yazar olarak güçlendirilmesini tanımlamasıydı.
Smalltalk'ta dil, araçlar ve kullanıcı arayüzü tek bir tutarlı ortam olarak tasarlanmıştı.
Pratikte bu, çalışan nesneleri inceleyip davranışını değiştirebilmeniz, etkileşimli olarak hata ayıklamanız ve sürekli yeniden derleyip başlatmak zorunda kalmadan çalışmaya devam etmeniz demekti—fikir ile sonuca ulaşma arasındaki mesafeyi kısaltıyor.
Kay'in temel fikri "sınıflar ve kalıtım" değildi; nesnelerin bağımsız ajanlar olmasıydı ve bunlar arasındaki iletişim mesajlaşma ile olur.
Tasarım açısından bu, çağıranların bir nesnenin iç yapısına değil, kabul ettiği mesajlara güvenmesi gerektiğini vurgular.
Yaygın tuzak, OOP'yi bir tür taksonomisi gibi görmek: çok sayıda sınıf, derin kalıtım zincirleri ve paylaşılan değişken veri.
Kay'in perspektifinden daha iyi bir kural:
GUI'ler yazılımı 'nesnelere dokunur gibi' hissettirdi. Bu, arayüzde gördüğünüz öğelerin çoğunun durum ve davranışı olan nesneler gibi ele alınabileceği fikriyle doğal olarak örtüşür.
Kullanıcı eylemleri (tıklamalar, sürüklemeler, tuş vuruşları) olaylar olarak nesnelere gönderilen mesajlara dönüşür; nesneler de bu mesajları gerektiğinde başka nesnelere iletir.
Smalltalk image'i tüm çalışan dünyayı kaydetme fikridir: bellekteki nesneler, açık araçlar, UI durumu ve mevcut çalışma hali.
Faydaları:
Dezavantajları:
Sistem düşüncesi, yazılıma tekil bileşenler olarak değil, zaman içinde etkileşen parçalar bütünü olarak bakar: geri bildirim döngüleri, tekrarlar ve kim kime konuşuyor soruları öne çıkar.
Uygulamada bu, net arayüzler (mesajlar) ve gizli bağımlılıkları azaltan tasarımlar getirir.
Kay'in fikirlerini Smalltalk kullanmadan da uygulayabilirsiniz: mesaj-öncelikli bir tasarım izleyin.
getTotal, isAvailable, authorize).Sonra uygulama yollarını seçin (sınıflar, modüller, servisler). Ayrıca gönderideki kontrol listesi iyi bir başlangıçtır (see /blog/practical-takeaways).
Modern araçlar Kay'in hedefleriyle uyumlu özellikler sunuyor, ama farklı kısıtlar altında:
Bunlar Smalltalk image'leriyle aynı şey değil, ama aynı pratik hedefi paylaşırlar: değişimi ve öğrenmeyi ucuz hale getirmek.