Codefiction - Yazılım Mimarı Ne iş Yapar?

 Codefiction tarafından canlı yayınlanan, yazılım mimarı ne iş yapar konulu video.

Videoda global şirketlerde yazılım mimarlığı tecrübesi olan katılımcılar, yazılım dünyasındaki architect kavramını ele alıyor. 

Yazılım şirketlerindeki çeşitli yöneticilik pozisyonlarının ne anlama geldiğini, günümüz dünyasında kavramların nasıl değiştiği konuşuluyor.

Atlassian, Amazon, SpaceX gibi firmalarda işlerin nasıl ilerlediği, rollerin nasıl paylaşıldığı anlatılıyor.

"Özellikle kurumsal firmalarda duyduğunuz yazılım mimarı rolü ne iş yapar? Kod yazar mı? Yazmalı mı? Yoksa sadece toplantılara mı girer? Gelin hep beraber iyi yazılım mimarı ve kötü yazılım mimarı arasındaki farkları tartışalım.

Bu sefer konuğumuz Atlassian firmasinda Principle Tech Evangelist olarak çalışan Serhat Can (https://twitter.com/srhtcn). Katılımcılar: Deniz İrgin (https://twitter.com/denizirgin) Deniz Özgen (https://twitter.com/_denolk) 

Mert Susur (https://twitter.com/MertSusur)" - Codefiction

Codefiction Nasıl Yapılır: Twitter

 Codefiction ekibinin 2 bölümlük Twitter nasıl yapılır serisi.

Video 1 : 

Video 2 :

Akın Kaldıroğlu Hocamızla Yaptığımız Röportaj

Bize biraz kendinizden bahseder misiniz? ( Aslen nerelisiniz? Nerelerde eğitim aldınız? Evli misiniz? )

Öncelikle geç cevap verebildiğim için özür dilerim.

Ben Ayvalık'lıyım. Lise sonrasında 1990 yılında İTÜ'den mezun oldum. İTÜ'de Elektronik okumama rağmen MEB bursuyla gittiğim ABD'de Bilgisayar Mühendisliği'nde (BM) master yapmaya karar verdim. Nitekim önce BM sonra da çalışırken Yazılım Mühendisliği yüksek lisans eğitimleri aldım. Evliyim, 3 çocuğum var.

Amerika'ya gidiş sebebiniz neydi? O yıllarla bu yılları karşılaştırdığınızda ABD'ye gitmek ve orada tecrübe kazanmak hala mantıklı mı?

Aslında taa lisede bile yurt dışında bulunmayı, özellikle orada eğitim almayı çok istiyordum. Aileden zengin değilseniz, okulda da çok başarılı olamamışsanız, geriye sadece devletin bursu kalıyordu o zamanlar, seçenek olarak. Tabi 90lı yılların başından bahsediyorum.  Sadece ABD değil, iyi eğitim veren yurt dışındaki okullarda lisans olmasa bile yüksek lisans eğitimi almak hala çok güzel bir imkan bence. Mesele sadece yabancı dil ya da iyi bir okul diploması değil, dünya görüşünü geliştirmek, envai çeşit tecrübeyi kazanmak; hala benim önem verdiğim şeyler bunlar. Üstüme vazife olmayan bir konuda çıkarım olacak ama toplum olarak bence bu türden tecrübelere çok ihtiyacımız var.

İlk işinizden bahseder misiniz? (İşe giriş hikayeniz, sizden beklentiler..)

Hahaha, ne zamandır ilk işimi pek düşünmemiştim. İlk işim Unix üzerinde firewall geliştiren bir yazılım evindeydi. 40-50 kişilik, çok odaklı iş yapan, ufak bir şirketti. Önce Maryland Rockwille'deydi sonra  Virgina'da Alenxandria'ya taşınmıştık. Yöneticimizi hatırlıyorum, George. İlk işe başladığım gün masamın üzerini mendille silerken koşup tuvaletten bir tomar kağıt havlu getirmişti bana. Bir keresinde de sanırım öğle yemeğinden sonra uyurken masamda yakalamıştı beni 🙂 Bir de yılbaşı yemeğine ben katılmayayım dediğimde, "bak, seni anlıyorum, ben de bu toplumun kıyısındanım, Mormon bir aileden geliyorum, yemek için önceden istediğini ısmarla, yemekte istediğini yap istemediğini yapma, ama birlikte olalım, eğlenelim" dediğini hatırlıyorum. Muhteşem bir adamıdı. Açıkçası böyle tecrübeleri yaşamak, sahip olduğu bilinç ve özellikle de toplumsal alışkanlıklar açısından insana kargadan başka kuş da olduğunu öğretiyor ki bu tecrübenin, yukarıda da bahsettiğim gibi ne yabancı dille ne de yüksek lisans ya da doktora ile kıyaslanması mümkün değil.

Bu işte benden beklenti Java tarafına geçiş ile ilgili alınmış stratejik bir karar doğrultusunda çalışmaktı. Tabi her zaman öyle olmadı, C ile yazılmış devasa firewall kodu üzerinde de çalıştım bayağı. İşe girince ilk öğrendiğim şeyin "firewall" olduğunu hatırlıyorum.

İlk kullandığınız programlama dili neydi? Bu dilin zorlukları nelerdi?

C, biraz da C++'dı. Firewall kodlarında yer yer C++ ile yazılmış kısımlarda vardı ama temelde C koduydu.  Java'nın da ilk günleriydi, yeni release olmuştu. Okuldan çıkıp, üç-beş bin satırlık codebeaselerinden milyonlarca satırlık devasa bir codebasee girmek çok korkutucu. Ufak takımlarda işi biraz da kendin halletmen gerekiyor, yardım almak zorlaşıyor vs.

ABD'de çalıştığınız farklı işlerden bahseder misiniz? Oradaki işler size neler kattı?

Benim çalıştığım yıllar DotCom patlamasının yaşandığı zamanlardı, dolayısıyla ilk işimden sonraki işlerde daha çok web arayüzleri olan projelerde çalıştım ve hep Java kullandım. Mesela satır satır servlet yazdım 😞, ya da Microsoft'un kendine göre değiştirdiği API'ye sahip JDK'sıyla, Visual J++ üzerinde geliştirme yaptım, Swing ile GUI geliştirdim vs. Teknolojik katkılardan ziyade daha organziasyonel ve kişisel ilişkiler bence daha fazla şey katmıştır bana, eğer hakikatten faydalanabilmişsem. 300-400 kişilik orası için küçük teknoloji şirketlerinde de çalıştım, GE'de de çalıştım. Her milletten insanla tnaışmak güzel bir şey. Taa GE'den bir Hintli arkadaş geçenlerde İstanbul'a geldi ve tekrar görüştük mesela.

Java ilk çıktığında Dünya'da nasıl bir etki yarattı? Java ile ilk ne zaman tanıştınız? O zaman java öğrenmek ve sertifika almak şimdiden daha mı kolaydı?

O zamanlar Java hakkında, "hiç bir başka teknoloji bu kadar büyük bir beklenti ve sahiplenme ile hayatına başlamadı" şeklinde yorumlar okuyordum. Muhtemelen sonrasında Android gibi mobil bir teknoloji benzer tecrübeyi yaşa(t)mıştır. Burada teknolojiyi sahiplenmenin hızından bahsediyorum daha çok. Tabi Java'da, web dalgasıyla üst üste gelince, doğru zamanda doğru yerde olmak denen o, Batılıların chance bizim ise nasip dediğimiz şey gerçekleşiyor. Aslında Java, iki ucunda VB ve C/C++ olan uygulama geliştirme dili spekturumunda, daha optimal bir noktaya konumlandı. Yani daha küçük ve basit bir syntax ve gramer ile yeterince güçlü bir dil oluşturmak, çalışma zamanını güçlü tutmak ve tabi ki platformdan bağımsız olmak gibi faktörlerin üzerine bina edildiğinden, bu işin pratiğini yapan geliştiriciler nezninde devrimsel özelliklere sahip olarak algılandı.

Çalıştığım iş yeri sertifika almayı destekliyordu, ücretini veriyordu, ben de hatırlıyorum Bruce Eckels'in Thinking in Java kitabını alıp, satır satır çizerek, örnek kodlarını yazarak, kendi örneklerimi yaparak çalışmıştım. Ben sertifikamı sanırım 1998'de aldım, o zaman konular daha azdı, sınav içeriği açısından ama test kitabı da yoktu tabi olarak.

Türkiye'ye dönüş sebebiniz neydi? Döndüğünüzde Türkiye yazılım sektörünü nasıl buldunuz? Bir hayal kırıklığı yaşadınız mı?

Ailevi sebeplerden döndüm ülkeme. Açıkçası hayal kırıklığım hala geçmedi, çünkü sektörün durumuna hala alışamadım. Tamamen ithalata, lisansa dayalı, derme çatma, esnaf vari sistem geliştirme teknikleri ve insan kaynağına "eleman" bakışı, aradan onca geçen seneye rağmen temelde çok da değişmedi.

Selsoft'u ne zaman kurdunuz ve şirketin kuruluş amacı neydi?

Selsoft 2011'de kuruldu. Sektör, koskoca Amerika görmüş adamsın, programcı mı olacaksın diye beni yönetici olmaya ittirdi ve ben de denedim. Ama açıkçası sektörün istediği gibi bir yönetici de olamadım; bundan 10 küsür sene önce de hemen her şeyin belirleyicisi kısa vadeli mali hesaplardı. Mimari, kalite, temiz kod vs. mesela, pek kolay şeyler değildi bu şekilde yazılım mühendisliği pratiklerini uygulamak. Dolayısıyla yönetici olarak da başarılı olamayacağımı anlayınca, kendimce çıkış yolunun tek başına ya da çok geniş olmayan bir çerçevede, tamamen uyum sağlayabildiğim kişilerle çalışmak olduğunu düşündüm. Selsoft bu düşüncenin ürünü.

MBA ve Felsefe yüksek lisansı size neler kattı? Türkiye ve ABD'yi kıyasladığınızda yüksek lisansa verilen değer farklı mı? Lisans mezunlarına yüksek lisansı öneriyor musunuz?

Ben 1990'da İTÜ'den mezun olunca pek çok arkadaşım doğrudan MBA benzeri yüksek lisans programlarına başlamıştı. Ben ise MBA ihtiyacını ancak yönetici olunca, İK, finans, satış vb. birimlerden insanlarla daha yakın çalışmaya başlayınca hissettim ve onlarla aynı dili konuşabilmek adına, sahayı bir görmek, tanımak istedim. Dolayısıyla terimleri anlamak, temel ayrımları bilmek ve özellikle de sahanın önde gelen teorisyenlerini ve düşüncelerini öğrenmek, kitap ve makalelerini okumak önemli hale geldi. İyi bir MBA eğitimi, eskiden bu yana önem verdiğim entelektüel gelişim için de iyi bir imkan sunar bence.

Felsefe, tamamen entelektüel amaçlı benim için. Uzun süredir kendi kendimce, amatörce okumaktaydım, ABD'deyken Edward Said, Syed Hüseyin Nasr ya da Quine gibi, bir programcıdan pek beklenmeyecek şekilde bazı ünlü entelektüelleri, filozofları dinleme, onlarla aynı çatı altında bulunma fırsatı da bulmuştum. Hep istemiştim, daha formal bir felsefe eğitimi almayı. Sonunda nasip oldu.

Bence, hayatı sorgulamayı geçtim, işini iyi yapmaya çalışan herkes bir şekilde işi üzerinden bazı felsefi soru(n)lara ulaşır. Örneğin programlama. Programlama dillerinin tabiatı, type sistemleri üzerine düşünen,  biraz makale vs. okuyan kişi muhtemelen kendini modern mantık içinde bulur. Yeter ki ilerleyebilecek temel eğitime, temel nosyonlara sahip olsun ve e önemlisi de meraka. Dahası bence düşünmemek, kişisel, toplumsal, teknolojik vs. her konuda her türlü kötülüğün temelidir. Ama gerek temel eğitimimiz, gerek yüksek öğrenimimiz genelde merakı törpülemek üzerine kurulu, bir de bunun üstüne sektör gelince, merak lüks hale geliyor.

ABD'de master yaparken defalarca hocanın sınıfa gelip soruları dağıtıp, 50 dakika sonra odama getirin ya da haftaya şu saate kadar gönderin deyip gittiğini hatırlıyorum. Ülkemizdeki özellikle MBA eğitimindeki derslerde genelde ilk sorulan sorunun sınavın klasik mi test mi olacağını duymuşluğum çoktur. Bence ülkemizdeki eğitim ile ABD'deki eğitim arasındaki esas fark bu, benim gözlemime göre, temelde ahlaki yani.

Lisans okuyan herkese tabi tavsiye ederim, master sonrasında da imkan varsa doktora yaparak formal bilgilenmelerini sürdürmelerini. Ama sektörümüzünün formal bilgi birikimine uzak oluşu, aşırı problem çözme odaklı çalışması ve bunu da "çözüm odaklı olmak" gibi bir meziyetle, bence aslen ideolojik bir sloganla, ifade etmesi, genelde master ve doktora çalışmalarının, kişinin kariyerinde etkili bir noktada olmasına engel oluyor. Bu tutum da aynı "Üniversite okumayıp bir işe girseydim, şimdi yeni mezun olarak kazandığımdan daha çok kazanırdım" sözü gibi aslında, eğitime bakışımızın ciddi bir şekilde araçsal, faydacı olduğunu da gösteriyor, bence.

Kendinizi amatör filozof olarak tanımlıyorsunuz. Biz de verdiğiniz eğitimlerde felsefe konuşmalarınızdan büyük keyif aldık, ayrıca Twitter'daki paylaşımlarınız da çok keyifli ve bilgi verici. Felsefe size hayatta ve yazılım kariyerinizde nasıl bir etki yarattı?

Hahaha, yok artık! Bakın şu açık: Ben, koyunun olmadığı yerde kendisine Abdurrahman Çelebi denen keçiyim. Maalesef hem toplum olarak hem sektör olarak o kadar sığız ki felsefede temel bir kaç soruyu farketmiş olmak ki temelde felsefe cevaplamak değil soru sorma sanatıdır, soruyu farketme gayretidir, Ekşi sözlükte bir yazarın, sağolsun, yazdığı kadarıyla beni "baya bir filozof eğitmen" kılıyor. Senelerdir object-oriented ya da nesne-merkezli/nesne-yönelimli programlama yapıp da "nesne de neymiş, bu kavramı ortaya atanları bir okuyayım baklalım" demeyen kişilere Aristo'nun nesne tanımından bahsedince filozof gibi görünmem normal. Böyle düşünen arkadaşların hüsnü zanlarının farkındayım ve buna minnettarım da ama asıl sebep, aşırı sığ ve araçsal bir dünya anlayışına sahip olmamız.

Felsefe eğer soru sorma sanatı ya da bilimiyse, kabaca konuşursak, soru sorabilme, soru(n)ları görebilme yetkinliğimi arttırmış, dolayısıyla da eğitim, danışmanlık ve daha önceki yöneticilik tecrübelerimde beni daha temelci/fundamentalist, anlama ve anlatma odaklı yapmış olabilir. Teknolojiden ziyade süreç odaklı biriyim ben mesela ya da Java anlatmaktan çok OOP, OOAD, Design Patterns, Domain-Driven Design anlatma ve uygulamayı daha keyifli bulurum. Teknik hiç bir ortaklığımız olmayan bir arkadaş bana bir seferinde, "farkında mısın, bana en sık sorduğun soru 'anlıyor musun'" demişti.

Selsoft olarak eğitimler veriyorusunuz? Bazıları Udemy platformunda yayınlandı. Bu eğitimler devam edecek mi?

Sanırım devam edecek. Udemy kısmı daha çok kitleye ulaşma ile ilgiliydi; bence iyi de oldu. Ama devam edecek eğitimlerin yeri Udemy mi olur pek emin değilim.

Kurumsal eğitimler veriyor musunuz?

Evet, tabi ki. Esas işim kurumlarla çalışmak, eğitim ve danışmanlık vermek. Online eğitimleri salgın öncesinde Oracle eğitmeni olarak Hindistan'dan İngiltere'ye kadarki zaman diliminde Live Virtual Class olarak çok defa vermiştim. Zaman zaman freelancer olarak ülke dışına da online eğitimler verdim. Ama bahsettiğiniz ve bireysel eğitim ve öğretim dünyasında daha çok tanınmamı sağlayan şey, açık sınıf, online eğitimler, salgınla birlikte , kurumların duruma uyum sağlama sürecide ortaya çıkan boşluğu doldurma gayretinin bir sonucudur.

Yeni yazılım öğrenmek isteyenler için eğitimleri sırayla izlemeleri gerekse nasıl bir sıralama yapardınız?

Yani yazılım öğrenmek demeyelim de programlama öğrenmek diyelim ona. Java özelinde Java ile Nesne-Merkezli Programlamaya Giriş ve Java ile Nesne-Merkezli ve Fonksiyonel Programlama eğitimleriyle temel Java SE bilgisi belli bir noktaya getirilebilir. Tabi bu eğitimlere JDBC, threading, IO gibi konuları da eklemek lazım. Advanced Java eğitimi içerisinde düşündüğüm konular. Sonrasında tabi Java EE tarafı geliyor, dolayısıyla web teknolojileri ile başlamak, örneğin Java ile RESTful 
Web Servisi Geliştirme ile devam etmek mantıklıdır. Tabi OOP'ye hakimiyet arttıkça Design Patterns öğrenmek, belki daha öncesinde Clean Code ile olabildiğince daha anlaşılır kod yazmayı alışkanlık haline getirmek önemli. EE tarafından Spring olmadan olmaz, dolayısıyla bir şekilde Spring'e de giriş yapılmalı. Bu konuda daha detaylı bir yazım var benim blogumda, oraya bakılabilir:  http://www.javaturk.org/udemy-egitimlerim-uzerine/

Bonus:

Bir yazılımcı olarak, şahıs şirketi kurarak yurtdışına remote olarak hizmet vermek.

 Yurtdışına şahıs şirketi üzerinden remote iş yapıyorsanız :

- KDV ödemiyorsunuz,
- 6322 sayılı kanun gereği, gelirinizin %50'si üzerinden gelir vergisinden muafsınız.
- Örnek olarak 4000 Euro fatura kestiğinizde ve 400 Euro masrafınız olduğunu düşünürsek(Kira,ısınma,elektrik,yemek), 1800 Euro'su vergi muhafiyetine giriyor ve kalan 1800 Euro'nun yaklaşık %32'si ni gelir vergisi olarak ödüyorsunuz. Size kalan tutar 3000 Euro ve harcadığınız 400 Euro oluyor.

Not : Tutarlar yaklaşık değerlerdir. Şahıs şirketi gelir vergisi oranlarına ayrıca internetten bakabilirsiniz.

Not:  Ayrıca 29 yaş altına artı olarak gelir vergisi ve bağkur destekleri de mevcut.

TalendGrid'in ilgili videosu :

Yazılım Geliştiricileri İçin Yazılım Mimarlığı - Simon Brown

Yazılım mimarı olmak isteyen yazılım geliştiricileri için Simon Brown tarafından yazılmış kitap. Dili sade ve akıcı.

Yazarın visualising software architecture kitabı da mevcut fakat ilk kitap benim için yeterli oldu.

Kitaptan alıntılar :

"Teknik liderlik, bir rütbe değil bir roldür."

"Most of the best software architects I know have a software development background, but for some reason many organisations don’t see this as a part of the software architecture role. Being a “hands-on software architect” doesn’t necessarily mean that you need to get involved in the day-to-day coding tasks, but it does mean that you’re continuously engaged in the delivery, actively helping to lead and shape it. Having said that, why shouldn’t the day-to-day coding activities be a part of the software architecture role?

Many software architects are master builders, so it makes sense to keep those skills up to date. In addition, coding provides a way for the architect(s) to share the software development experience with the rest of the team, which in turn helps them better understand how the architecture is viewed from a development perspective. Many companies have policies that prevent software architects from engaging in coding activities because their architects are “too valuable to undertake commodity coding work”. Clearly this is the wrong attitude. Why let your software architects put all that effort into designing software if you’re not going to let them contribute to its successful delivery?

Of course, there are situations where it’s not practical to get involved at the code level. For example, a large project generally means a bigger “big picture” to take care of and there may be times when you just don’t have the time for coding. But, generally speaking, a software architect who codes is a more effective and happier architect. You shouldn’t necessarily rule out coding just because “you’re an architect”."

https://leanpub.com/software-architecture-for-developers

İlgili web sitesi :

https://softwarearchitecturefordevelopers.com/

Akıllı Şehirler Bugün Daha İyi Bir İş Yaklaşımına Nasıl Yardımcı Oluyor? - smartcity.press çevirisi

Eski iş dünyasının geleceğine her zaman konum ve coğrafya karar verdi. İşletmeler için mükemmel coğrafyanın yanı sıra, bir şehir, vatandaşların ve işletmelerin verimli çalışmasına ve sağlam ve sürdürülebilir bir büyüme sergilemesine yardımcı olan teknolojiyi uygulamaya ve daha iyi bir yarın için kendini hazırlamaya başladığında, akıllı bir şehir haline gelir.

Akıllı bir şehir, işletmelerin ve vatandaşların rahat bir çalışma ortamına erişmelerine yardımcı olur ve bu da daha iyi bir yarın için yaşamları değiştirmeye yol açar. Akıllı şehirler, bilim ve yaşam tarzını gelişimin merkezinde tutarak kavramsallaştırılır.

Akıllı şehirler için altyapı yatırımının önümüzdeki yirmi yılda kümülatif olarak 40 trilyon dolar olacağı tahmin ediliyor. Bu yatırım, yaklaşık 40 küresel şehri akıllı şehirler haline getirecek.

Bir şehri 'akıllı' yapan nedir!

Akıllı şehirler dört sütun üzerine kuruludur: operasyonlar, altyapı, insanlar ve teknoloji. Dördüncü sütun olan teknoloji, zeka ile aşılanmıştır. Daha da önemlisi, sütunlar, kaynakların kullanılabilirliğini ve sürdürülebilirliğini sağlamak için entegre ve birbirine bağlı bir şekilde çalışır.

Örneğin, akıllı bir şehrin güç dağıtım sistemi, yerel güç talep kalıpları, şebeke tedarik varyasyonları ve en iyi üretim ve tüketimi sağlayan iyi organize edilmiş bir işletim ve dağıtım süreci ile entegre olan akıllı şebekelere dayanabilir.

Elektrik sağlayıcı, üretim, tüketim ve depolama için üretilen verileri kullanarak, ne kadar elektrik tedarik edilmesi gerektiğini tahmin edebilir. Dağıtım bölgeleri oluşturabilir, tüketim modelini analiz edebilir ve buna göre depolayabilirler.

Peki işletmeler akıllı şehirlerden nasıl faydalanıyor?

İşletmeler yalnızca akıllı bir şehrin temel gelişiminin yarattığı gelirden faydalanmakla kalmaz; teknoloji ve gelişmiş tahmine dayalı analiz kullanımı ile faydalar katlanarak artar. İşletmelerin akıllı şehirlerden elde ettiği bazı önemli avantajlara bir göz atalım.

Artan Sürdürülebilirlik

Nüfus artışının hızla arttığı bir dünyada, sürdürülebilirlik akıllı şehirlerin gelişiminin merkezinde yer alıyor. Bir şehrin mevcut kaynaklarının çevre üzerinde önemli bir etkisi vardır ve akıllı bir şehir her zaman bunu azaltmayı ve sıfır karbon ayak izine yaklaşmayı amaçlar.

Bu nedenle, akıllı bir şehir geliştirmek, şehrin karşılaştığı zorluklara her zaman sürdürülebilir çözümler aramak anlamına gelir.

Akıllı bir şehirde faaliyet gösteren bir işletme bu sürdürülebilir modele uymalıdır. Bu, esas olarak, atıkların sorumlu bir şekilde bertaraf edilmesi, enerji tasarrufuna daha fazla odaklanma, çalışanlara etik muamele yöntemlerine odaklanma ve teknik ve doğal kaynakların daha iyi kullanılması gibi zorluklara sürdürülebilir bir yaklaşım anlamına gelir.

Neilson tarafından 2015 yılında yürütülen bir araştırma, şirketin olumlu sosyal ve çevresel değişikliklere ciddi şekilde bağlı olması durumunda, katılımcıların %66'sının bir ürün veya hizmet için daha fazla ödemeye istekli olduğunu gösterdi. Müşterilerin sürdürülebilirlik talebi bugün artıyor, bu nedenle akıllı şehir modelinde faaliyet gösteren işletmeler, iyileştirilmiş müşteri ilişkileri ve bunun sonucunda artan karlar gözlemliyor.

İnovasyonu Sürdürmek

Yaşam Standartlarını İyileştirmek İçin Akıllı Şehirlerde İş İnovasyonu

Akıllı bir şehrin en sürdürülebilir, verimli ve etkili halinde kalması için, stratejiler ve teknolojiler sürekli iyileştirme görmeli ve zamanında güncellemelere sahip olmalıdır.

Teknolojinin gelişimini ve daha iyi çalışma koşulları sağlama yeteneğini yönlendiren güç, inovasyondur.

Evlerin ve işyerlerinin, herkes için hayatı kolaylaştıran Nesnelerin İnterneti cihazlarıyla donatıldığını şimdiden görebiliyoruz. Bu, teknolojik bağımlılık için artan talebe yanıt verir. Teknolojideki gelişmelerle, işletmelerin erişimi ve büyümesi kesin bir artış görüyor.

Küresel ve Yerel Ekonomide Artış

Akıllı şehirlere değer katmak için yaratılan teknolojik gelişmeler ve girişimler, şüphesiz ekonomiye büyük katkı sağlayacaktır.

İşletmeler ayrıca, akıllı şehirlerde kullanılan cihaz ve ekipmanlar tarafından toplanan verilerden yararlanarak hedef demografik alanı daha iyi anlamalarına ve daha iyi hizmetler sunmalarına yardımcı olacak.

Örneğin, Transport for London (TFL), verilerini City Mapper'a (bir ulaşım yardımcı programı uygulaması) sağlar. Bu, yolcuların Londra şehri boyunca en hızlı rotayı bulmasını kolaylaştırır.

Londra'nın turizm endüstrisi, City Mapper kullanımıyla toplu taşıma kullanımında önemli bir artış kaydetti. Navigant tarafından yapılan bir araştırmaya göre, akıllı hizmetler ve çözümler için küresel pazarın 2026 yılına kadar 40,1 milyar dolardan 97,9 dolara büyük bir büyüme göstermesi bekleniyor.

Gelişmiş Yönetim

Bugünün vatandaşları günlük yaşamlarını sağlam, kullanıcı dostu dijital çözümlere dayandırmayı bekliyor. İşbirliği araçları, modern bilişsel web siteleri, self servis portallar, mobil uygulamalar ve kullanışlı çevrimiçi bankacılık hayatın birçok alanında bir standart haline geldi ve akıllı vatandaşlar bir şehirden bundan daha azını beklemiyor. Dijital hizmetleri topluluklara genişletmek, şehirleri daha akıllı hale getirir ve işletmeler için giderek daha fazla fırsat sunar.

Akıllı yönetişimin parlak bir örneğine bir göz atalım. Hindistan hükümeti, 2016 yılında Birleşik Ödemeler Arayüzü (UPI) adlı bir hizmet başlattı. UPI, nakitsiz bir ödeme yöntemidir. Hindistan Merkez Bankası, tüm bankaların, geçerli bir banka hesabı olan ve çevrimiçi ödemeler için daha iyi bir güvenlik ölçümü sağlayan Müşterini Tanı (KYC) sürecini tamamlayan herhangi bir Hint vatandaşına UPI hizmetleri sunmaya başlaması için bir yetki verdi.

Yüzlerce yıldır bu mirası sürdürmekte olan inanılmaz derecede eski bir ekonomide bu ani geçişe ne gerek vardı? UPI, hükümet tarafından bir gecede açıklanan tedavülden kaldırmanın bir sonucuydu.

Bu ani hareket, kara paranın banka hesaplarına yatırılmasını zorunlu kılmaktı, böylece hükümet bu hesaptan ödenmesi gereken vergiyi alacak ve paralel ekonomiye tasma takacaktı. Peki, bu hareket iş dünyasına nasıl yardımcı oldu? UPI, her bir banka hesabının artık dijital olmasını sağladı.

Böyle bir hareketle, en küçük esnaf artık yüzlerce UPI özellikli mobil uygulama kullanarak para kabul edebildi. Bu, milyonlarca esnaf için daha fazla işlem ve daha fazla iş anlamına geliyordu. Bu hareket, Hindistan'da iş yapma şeklini sonsuza dek değiştirdi.

Yeni Ekonomik Kalkınma Fırsatları

Yatırımcılar artık paralarını akıllı şehirlerin gelişimine yatırmak istiyorlar. Sebep? Basit – daha iyi getiriler. Bu oluyor çünkü akıllı şehirlerin sunduğu konfor, lüks ve kolaylık, ev satın alan veya iş kurmak isteyen biri için en iyi değer olduğunu kanıtlıyor.

Akıllı şehir yatırımları, yeni sakinleri, işletmeleri ve fırsatları cezbetmek için şehirlerin bölgesel ve küresel rekabet gücünü artırmada hayati bir rol oynuyor. Dahası, işletmelerin verilerine güvenli bir ortamda erişim sağlayan akıllı şehirler, sonunda işletmelerin daha akıllı kararlar almasına yardımcı oluyor.

Artan İş Gücü Katılımı

'İnsan kaynağı en iyi kaynaktır' - dedikleri gibi! Yüksek verimli bir iş gücü, herhangi bir işletme için önemli bir faktördür. Akıllı teknolojilerin kullanılması, herhangi bir şehir profesyonelini rahatsız eden manuel iş yükünün azaltılmasına yardımcı olur.

Teknik yükselme, şehir çalışanlarının iş/kişisel yaşamlarının daha az önemli yönü hakkında endişelenmeden doğru yöne gitmelerini sağlar. Günümüzde gadget'lar o kadar yeteneklidir ki, günlük işlemlerin çoğunu halledebilirler.

Bir şehirde bu tür teknoloji ve tesisler mevcut olduğunda, değerli ve zeki insanlar bu şehirlere taşınmaya başlar ve şehrin teknik olanaklarına uygun organizasyonlara katılırlar. İşletmeler bu mega düşünürlerden ve verimli çalışanlardan yararlanır.

Akıllı şehirler, akıllı bölgeler yaratır ve akıllı ulusların oluşmasına öncülük eder. Yaşam kolaylığı, ekonomideki canlanma ve çalışma ortamının canlanması, günümüzde her modern işletmenin arzusudur. Bir işi akıllı şehre taşımak artık bir hayal değil; Etrafına bak, zaten oluyor.

Birleşmiş Milletler Sürdürülebilir 2030 Kalkınma Hedefleri (SKH)

1. Yoksulluğu tüm biçimleriyle her yerde sonlandırın.
2. Açlığı sonlandırın, gıda güvenliğini ve gelişmiş beslenmeyi sağlayın ve sürdürülebilir tarımı teşvik edin.
3. Sağlıklı yaşamlar sağlayın ve her yaştan herkes için refahı teşvik edin.
4. Kapsayıcı ve eşitlikçi kaliteli eğitim sağlayın ve herkes için yaşam boyu öğrenme fırsatlarını teşvik edin.
5. Cinsiyet eşitliğini sağlayın ve tüm kadınları ve kızları güçlendirin.
6. Herkes için su ve sanitasyonun mevcudiyetini ve sürdürülebilir yönetimini sağlayın.
7. Herkes için uygun fiyatlı, güvenilir, sürdürülebilir ve modern enerjiye erişim sağlayın.
8. Herkes için sürdürülebilir, kapsayıcı ve sürdürülebilir ekonomik büyümeyi, tam ve üretken istihdamı ve insana yakışır işi teşvik edin.
9. Dayanıklı altyapı oluşturun, kapsayıcı ve sürdürülebilir sanayileşmeyi teşvik edin ve yeniliği teşvik edin.
10. Ülkeler içinde ve arasında eşitsizliği azaltın.
11. Şehirleri ve insan yerleşimlerini kapsayıcı, güvenli, dayanıklı ve sürdürülebilir hale getirin.
12. Sürdürülebilir tüketim ve üretim kalıpları sağlayın.
13. İklim değişikliği ve etkileriyle mücadele etmek için acilen harekete geçin.
14. Sürdürülebilir kalkınma için okyanusları, denizleri ve deniz kaynaklarını koruyun ve sürdürülebilir şekilde kullanın.
15. Karasal ekosistemlerin sürdürülebilir kullanımını koruyun, restore edin ve teşvik edin, ormanları sürdürülebilir bir şekilde yönetin, çölleşmeyle mücadele edin ve arazi bozulmasını durdurun ve tersine çevirin ve biyolojik çeşitlilik kaybını durdurun.
16. Sürdürülebilir kalkınma için barışçıl ve kapsayıcı toplumları teşvik edin, herkes için adalete erişim sağlayın ve her düzeyde etkili, hesap verebilir ve kapsayıcı kurumlar inşa edin.
17. Sürdürülebilir kalkınma için uygulama araçlarını güçlendirin ve küresel ortaklığı canlandırın.

SOLID Prensipleri -The Liskov Substitution Principle - Uncle Bob Çevirisi

Merhaba, bu seride sizlere Uncele Bob'un (Robert C. Martin) SOILD presnipleri için yazdığı makaleleri Türkçe'ye çevireceğim. Umarım yararlı bir yazı dizisi olur.

Seri'nin diğer yazıları :

The Single Responsibility Principle

Open Closed Principle

3- The Liskov Substitution Principle

GİRİŞ

Bu ilke, sürdürülebilir ve tekrar kullanılabilir kod oluşturma temelidir. İyi tasarlanmış kodun değiştirilmeden genişletilebileceğini belirtir; iyi tasarlanmış bir programda eski, halihazırda çalışan kodu değiştirmek yerine yeni kod eklenerek yeni özellikler eklenmesini amaç edinir.

Açık-Kapalı prensibinin ardındaki birincil mekanizmalar soyutlama ve polimorfizmdir. C ++ gibi statik olarak yazılmış dillerde, soyutlama ve polimorfizmi destekleyen temel mekanizmalardan biri kalıtımdır. Soyut temel sınıflarda saf sanal fonksiyonlar tarafından tanımlanan soyut polimorfik arayüzlere uyan türetilmiş sınıflar oluşturabiliriz.

Bu özel miras kullanımını yöneten tasarım kuralları nelerdir? En iyi miras hiyerarşilerinin özellikleri nelerdir? Açık-Kapalı prensibine uymayan hiyerarşiler yaratmamıza neden olacak tuzaklar nelerdir? Bunlar bu makalenin ele alacağı sorular olacak.

PRENSİP

POINTERLARI VEYA TEMEL SINIFLARIN REFERANSLARINI  KULLANAN FONKSİYONLAR, TÜREDİKLERİ SINIFLARIN NESNELERİNİ TİPLERİNİ BİLMEDEN KULLANABİLMELİDİRLER.

Yukarıdaki, Liskov İkame Prensibi'nin (LSP) bir açıklamasıdır. Barbara Liskov ilk olarak yaklaşık 8 yıl önce şunu yazmıştır:

Burada istenen şu ikame özelliğine benzer bir şeydir: S tipindeki her bir o1 nesnesi için T tipinde bir O2 nesnesi varsa, T olarak tanımlanan tüm P programları için, o1 o2 yerine ikame edildiğinde P'nin davranışı değişmiyorsa, o zaman S, T'nin bir alt tipidir.

Bu ilkenin önemi, ihlal etmenin sonuçlarını düşündüğünüzde belirginleşir. LSP'ye uymayan bir metod varsa, bu metod bir temel sınıfa bir işaretçi veya başvuru kullanır, ancak bu temel sınıfın tüm alt sınıflarını bilmelidir. Böyle bir işlev Açık-Kapalı ilkesini ihlal eder, çünkü temel sınıfın yeni bir alt sınıfı oluşturulduğunda değiştirilmesi gerekir.

LSP İhlaline Basit Bir Örnek

Bu ilkenin en göze çarpan ihlallerinden biri, bir nesnenin tipine dayalı bir metod seçmek için C ++ Çalışma Zamanı Türü Bilgilerinin (RTTI) kullanılmasıdır. yani .:

void DrawShape(const Shape& s)
{
if (typeid(s) == typeid(Square))
  DrawSquare(static_cast < square > (s)); 
else if (typeid(s) == typeid(Circle))
  DrawCircle(static_cast < circle > (s));
}

[Not: static_cast yeni cast operatörlerinden biridir. Bu örnekte normal bir cast gibi çalışır. yani DrawSquare ((Square &) s); Bununla birlikte, yeni sözdiziminin kullanımı daha güvenli ve grep gibi araçlarla bulunması daha katı kurallara sahiptir. Bu nedenle tercih edilir.]

Açıkçası DrawShape metodu kötü bir şekilde oluşturulmuştur. Shape sınıfının her olası alt sınıfı bilmeli ve yeni Shape alt sınıfları her oluşturulduğunda değiştirilmelidir. Gerçekten de birçoğu bu metodun yapısını Nesneye Dayalı Tasarıma lanetli olarak görmektedir.

Kare ve Dikdörtgen, Daha İnce Bir İhlal.

Ancak, LSP'yi ihlal etmenin çok daha incelikli başka yolları da vardır. Aşağıda açıklandığı gibi Rectangle sınıfını kullanan bir uygulama düşünün:

class Rectangle
{
	public:
		void SetWidth(double w) {itsWidth=w;}
		void SetHeight(double h) {itsHeight=w;}
		double GetHeight() const {return itsHeight;}
		double GetWidth() const {return itsWidth;}
	private:
		double itsWidth;
		double itsHeight;
};

Bu uygulamanın iyi çalıştığını ve birçok sitede kurulu olduğunu hayal edin. Tüm başarılı yazılımlarda olduğu gibi, kullanıcılarının ihtiyaçları değiştikçe yeni fonksiyonlara ihtiyaç duyulmaktadır. Bir gün kullanıcıların dikdörtgenlere ek olarak kareleri de işleme yeteneği talep ettiğini hayal edin.

C++'da kalıtımın ISA ilişkisi olduğu sıklıkla söylenir. Başka bir deyişle, yeni bir tür nesnenin eski tür bir nesneyle ISA ilişkisini yerine getirdiği söylenebilirse, o zaman yeni nesnenin sınıfı eski nesnenin sınıfından türetilmelidir.

Açıkça, bir kare, tüm normal niyet ve amaçlar için bir dikdörtgendir. ISA ilişkisi geçerli olduğundan, Square sınıfını Rectangle'dan türetilmiş olarak modellemek mantıklıdır.

ISA ilişkisinin bu kullanımı birçok kişi tarafından Nesne Yönelimli Analizin temel tekniklerinden biri olarak kabul edilir. Bir kare bir dikdörtgendir ve bu nedenle Square sınıfı, Rectangle sınıfından türetilmelidir. Bununla birlikte, bu tür bir düşünce, bazı ince, ancak önemli sorunlara yol açabilir. Genellikle bu sorun, biz uygulamayı gerçekten kodlamaya çalışana kadar öngörülemez. İlk ipucumuz, bir Square'in hem ItsHeight hem de itsWidth üye değişkenlerine ihtiyaç duymadığı gerçeği olabilir. Yine de onları yine de miras alacak. Açıkçası bu israf. Ayrıca, yüz binlerce Square nesnesi oluşturacaksak (örneğin, karmaşık bir devrenin her bileşeninin her pininin bir kare olarak çizildiği bir CAD/CAE programı), bu israf son derece önemli olabilir.

Ancak, bellek verimliliğiyle pek ilgilenmediğimizi varsayalım. Başka sorunlar var mı? Aslında! Square, SetWidth ve SetHeight işlevlerini devralır. Bir karenin genişliği ve yüksekliği aynı olduğundan, bu işlevler bir Kare için kesinlikle uygun değildir. Bu, tasarımda bir sorun olduğuna dair önemli bir ipucu olmalıdır. Ancak, sorunu ortadan kaldırmanın bir yolu var. Set-Width ve SetHeight'ı aşağıdaki gibi geçersiz kılabiliriz:

void Square::SetWidth(double w)
{
	Rectangle::SetWidth(w);
	Rectangle::SetHeight(w);
}
void Square::SetHeight(double h)
{
	Rectangle::SetHeight(h);
	Rectangle::SetWidth(h);
}

Şimdi, birisi bir Square nesnesinin genişliğini ayarladığında, yüksekliği de buna bağlı olarak değişecektir. Ve birisi yüksekliğini ayarladığında genişlik de onunla birlikte değişecektir. Böylece, Karenin değişmezleri bozulmadan kalır. Square nesnesi matematiksel olarak uygun bir kare olarak kalacaktır.

 
  Square s;
s.SetWidth(1); // Fortunately sets the height to 1 too.
s,SetHeight(2); // sets width and heigt to 2, good thing.

Ama aşağıdaki fonksiyonu bir düşünün

void f(Rectangle r)
{
r.SetWidth(32); // calls Rectangle::SetWidth
}

Bu fonksiyona bir Square nesnesine bir referans iletirsek, yükseklik değişmeyeceği için Square nesnesi bozulacaktır. Bu, LSP'nin açık bir ihlalidir. f işlevi, bağımsız değişkenlerinin türevleri için çalışmaz. Başarısızlığın nedeni, SetWidth ve SetHeight'ın Rectangle'da virtual olarak bildirilmemesidir.

Bunu kolayca düzeltebiliriz. Ancak, türetilmiş bir sınıfın oluşturulması, temel sınıfta değişiklik yapmamıza neden olduğunda, genellikle tasarımın hatalı olduğu anlamına gelir. Gerçekten de Açık-Kapalı ilkesini ihlal ediyor. Buna, SetWidth ve SetHeight'ı sanal yapmayı unutmanın gerçek tasarım hatası olduğu ve şu anda onu düzelttiğimiz iddiasıyla karşı çıkabiliriz. Ancak, bir dikdörtgenin yüksekliğini ve genişliğini ayarlamak son derece ilkel işlemler olduğundan, bunu haklı çıkarmak zordur. Square'in varlığını tahmin etmeseydik, hangi akıl yürütmeyle onları sanal hale getirirdik.

Yine de, argümanı kabul ettiğimizi ve sınıfları düzelttiğimizi varsayalım. Aşağıdaki kodla tamamlıyoruz:

 
   class Rectangle
	{
	public:
		virtual void SetWidth(double w) {itsWidth=w;}
		virtual void SetHeight(double h) {itsHeight=h;}
		double GetHeight() const {return itsHeight;}
		double GetWidth() const {return itsWidth;}
    private:
		double itsHeight;
	double itsWidth;
	};
	class Square : public Rectangle
	{
	public:
		virtual void SetWidth(double w);
		virtual void SetHeight(double h);
	};
	void Square::SetWidth(double w)
	{
		Rectangle::SetWidth(w);
		Rectangle::SetHeight(w);
	}
	void Square::SetHeight(double h)
	{
		Rectangle::SetHeight(h);
		Rectangle::SetWidth(h);
	}
   
   

Gerçek Sorun

Bu noktada, işe yarıyor gibi görünen Kare ve Dikdörtgen olmak üzere iki sınıfımız var. Bir Square nesnesine ne yaparsanız yapın, matematiksel bir kare ile tutarlı kalacaktır. Ve bir Rectangle nesnesine ne yaparsanız yapın, o matematiksel bir dikdörtgen olarak kalacaktır. Ayrıca, bir Dikdörtgen'e bir işaretçi veya referans kabul eden bir fonksiyona bir Kare iletebilirsiniz ve Kare yine bir kare gibi davranacak ve tutarlı kalacaktır.

Böylece, modelin artık kendi içinde tutarlı ve doğru olduğu sonucuna varabiliriz. Ancak bu sonuç yanlış olacaktır. Kendinden tutarlı bir model, tüm kullanıcıları ile mutlaka tutarlı olmak zorunda değildir! Aşağıdaki g fonksiyonunu düşünün.

void g(Rectangle& r)
{
	r.SetWidth(5);
	r.SetHeight(4);
	assert(r.GetWidth() * r.GetHeight()) == 20);
}

Bu işlev, bir Dikdörtgen olduğuna inandığı şeyin SetWidth ve SetHeight üyelerini çağırır. İşlev, bir Dikdörtgen için gayet iyi çalışır, ancak bir Kare iletilirse bir onaylama hatası bildirir. İşte asıl sorun şu: Bu işlevi yazan programcı, bir Dikdörtgenin genişliğini değiştirmenin yüksekliğini değiştirmediğini varsaymakta haklı mıydı?

Açıkçası, g programcısı bu çok makul varsayımı yaptı. Programcıları bu varsayımı yapan fonksiyonlara bir Kare iletmek problemlere yol açacaktır. Bu nedenle, Rectangle nesnelerine işaretçiler veya referanslar alan, ancak Square nesneleri üzerinde düzgün çalışamayan işlevler vardır. Bu işlevler, LSP'nin ihlal edildiğini ortaya çıkarır. Dikdörtgen'in Kare türevinin eklenmesi bu işlevi bozmuştur; ve böylece Açık-Kapalı ilkesi ihlal edilmiştir.

Geçerlilik İçsel Değildir

Bu bizi çok önemli bir sonuca götürüyor. Tek başına bakıldığında bir model anlamlı bir şekilde doğrulanamaz. Bir modelin geçerliliği ancak müşterileri açısından ifade edilebilir. Örneğin Square ve Rectangle sınıflarının son halini ayrı ayrı incelediğimizde kendi içinde tutarlı ve geçerli olduklarını gördük. Ancak onlara temel sınıf hakkında makul varsayımlarda bulunan bir programcının bakış açısından baktığımızda model bozuldu.

Bu nedenle, belirli bir tasarımın uygun olup olmadığı değerlendirilirken, çözüme tek başına bakmamak gerekir. Bu tasarımın kullanıcıları tarafından yapılacak makul varsayımlar açısından değerlendirilmelidir.

Ne yanlış gitti?

Peki ne oldu? Görünüşe göre makul olan Kare ve Dikdörtgen modeli neden kötü gitti? Sonuçta, Kare Dikdörtgen değil mi? ISA ilişkisi devam etmiyor mu?

Hayır! Bir kare bir dikdörtgen olabilir, ancak bir Square nesnesi kesinlikle bir Rectangle nesnesi değildir. Niye? Çünkü bir Square nesnesinin davranışı, bir Rectangle nesnesinin davranışıyla tutarlı değildir. Davranışsal olarak, Kare Dikdörtgen değildir! Ve yazılımın gerçekten ilgili olduğu şey davranıştır.

LSP, OOD'de ISA ilişkisinin davranışla ilgili olduğunu açıkça ortaya koymaktadır. İçsel özel davranış değil, dışsal kamusal davranış; clientlerın bağlı olduğu davranış. Örneğin, yukarıdaki g fonksiyonunun yazarı, Dikdörtgenlerin yükseklikleri ve genişlikleri birbirinden bağımsız olarak değişecek şekilde davranmasına bağlıydı. İki değişkenin bu bağımsızlığı, diğer programcıların muhtemelen bağımlı olduğu dışsal bir genel davranıştır.

LSP'nin ve onunla birlikte Açık-Kapalı ilkesini tutması için, tüm türevlerin, müşterilerin kullandıkları temel sınıflardan beklediği davranışa uyması gerekir.

Sözleşmeye Göre Tasarım (Design By Contract)

LSP ile Bertrand Meyer2 tarafından açıklandığı üzere Sözleşmeye Göre Tasarım kavramı arasında güçlü bir ilişki vardır. Bu şemayı kullanarak, sınıf metotları önkoşulları ve sonkoşulları bildirir. Yöntemin uygulanabilmesi için ön koşulların doğru olması gerekir. Tamamlandığında, yöntem, son koşulun doğru olacağını garanti eder.

Rectangle::SetWidth(double w) öğesinin son durumunu şu şekilde görebiliriz:

assert((itsWidth == w) && (itsHeight == old.itsHeight)); Şimdi, Meyer3 tarafından belirtildiği gibi, türevler için ön koşullar ve son koşullar için kural şudur:

...bir rutini [türevde] yeniden tanımlarken, yalnızca ön koşulunu daha zayıf olanla ve son koşulunu daha güçlü olanla değiştirebilirsiniz.

Başka bir deyişle, bir nesneyi temel sınıf arabirimi aracılığıyla kullanırken, kullanıcı yalnızca temel sınıfın ön koşullarını ve son koşullarını bilir. Bu nedenle, türetilmiş nesneler, bu tür kullanıcıların, temel sınıfın gerektirdiğinden daha güçlü olan ön koşullara uymasını beklememelidir. Yani, temel sınıfın kabul edebileceği her şeyi kabul etmeleri gerekir. Ayrıca, türetilmiş sınıflar, tabanın tüm son koşullarına uygun olmalıdır. Yani, davranışları ve çıktıları, temel sınıf için belirlenen kısıtlamaların hiçbirini ihlal etmemelidir. Temel sınıfın kullanıcıları, türetilmiş sınıfın çıktısıyla karıştırılmamalıdır.

Açıkça, Square::SetWidth(double w) öğesinin son koşulu, “(itsHeight == old.itsHeight)” temel sınıf yan tümcesine uymadığından, yukarıdaki Rectangle::SetWidth(double w) öğesinin son koşulundan daha zayıftır. Bu nedenle, Square::SetWidth(double w) temel sınıfın sözleşmesini ihlal eder.

Eiffel gibi bazı diller, ön koşullar ve son koşullar için doğrudan desteğe sahiptir. Bunları gerçekten bildirebilir ve çalışma zamanı sisteminin bunları sizin için doğrulamasını sağlayabilirsiniz. C++'ın böyle bir özelliği yoktur. Yine de C++'da bile her yöntemin ön koşullarını ve son koşullarını manuel olarak değerlendirebilir ve Meyer kuralının ihlal edilmediğinden emin olabiliriz. Ayrıca, bu ön koşulları ve son koşulları her bir yöntem için yorumlarda belgelemek çok yardımcı olabilir.

A real Example Kısmını çevirmedim. Orjinal makaleden gözatabilirsiniz.

ÖZET SONUÇ

Açık-Kapalı prensibi, OOD için yapılan iddiaların çoğunun kalbinde yer alır. Bu ilke yürürlükte olduğunda, uygulamalar daha sürdürülebilir, tekrar kullanılabilir ve sağlamdır. Liskov İkame İlkesi (Diğer adıyla Sözleşmeli Tasarım (Design by Contract)), Açık-Kapalı prensibine uyan tüm programların önemli bir özelliğidir. Sadece alt sınıflar temel tipleri için tamamen ikame edildiğinde, bu temel sınıfları kullanan metodlar cezasızlıkla yeniden kullanılabilir ve alt tipler cezasızlıkla değiştirilebilir.

Metnin Orjinali :

LSP Orjinal Makale

Learn English with Alex

Bundan 2 ay öncesi kadar İngilizce özel ders almaya karar vermiştim.
Sonra Alex ile tanıştım. 2 ay boyunca 40 akademik saat ders yaptık.
Kendisi az Türkçe biliyor. Hemen hemen hiç Türkçe konuşmadık.
Her konuda konuştuk, bolca pratik yaptık. Her ders öncesi Extra English sitcom dizisinden bir bölüm izleyip kendisine reported speech yaptım. Ayrıca bir ödevim de McMillian'ın Destination B1 Grammar & Vocabulary kitabından bir ünite bitirmekti. Bir dönem IELTS Academic sınavına da hazırladı beni, fakat çok vakit bulamadığımdan bunu ileri bir tarihe erteledik.
Genel olarak İngilizcem farkedilir derecede iyileşti. Konuşurken özgüvenim arttı ve iyi bir arkadaş edinmiş oldum.
Kendisi anne tarafından İngiliz, baba tarafından Rus ve eşi Türk. Hindistan'da eğitim görmüş. Yani birçok kültürden sizinle sohbet etmek için tecrübesi var.
Siz de kendisinden ders almak isterseniz, bu grup dersi de olabilir, kendisine aşağıdaki numaradan ulaşabilirsiniz.

530 238 71 17

Açık Kaynak Tanımı ile Özgür Yazılım Tanımı Karşılaştırma

Açık Kaynak Tanımı ile Karşılaştırma

Özgür yazılım hareketi ve açık kaynaklı yazılım hareketi arasındaki felsefi farklılıklara rağmen, FSF tarafından ücretsiz yazılım ve OSI tarafından açık kaynaklı yazılımın resmi tanımları, birkaç küçük istisna dışında, temelde aynı yazılım lisanslarına atıfta bulunur. . Özgür Yazılım Vakfı, felsefi farklılıkları vurgularken şu yorumu yapıyor:

"Açık kaynaklı" yazılım terimi, bazı kişiler tarafından özgür yazılımla aşağı yukarı aynı kategoriyi ifade etmek için kullanılır. Tam olarak aynı yazılım sınıfı değildir: çok kısıtlayıcı olduğunu düşündüğümüz bazı lisansları kabul ederler ve kabul etmedikleri özgür yazılım lisansları vardır. Ancak, kategorinin genişletilmesindeki farklılıklar küçüktür: neredeyse tüm özgür yazılımlar açık kaynaklıdır ve neredeyse tüm açık kaynaklı yazılımlar özgürdür.

— Özgür Yazılım Vakfı

Özgür Yazılımın Dört Temel Özgürlüğü - wikipedia.org ÇEVİRSİ

 Özgür Yazılımın Dört Temel Özgürlüğü

FSF tarafından Şubat 1986'da yayınlanan tanımda iki nokta vardı:

Adımızdaki "FREE" kelimesi fiyat anlamına gelmez; özgürlüğe atıfta bulunur. Birincisi, bir programı kopyalama ve komşularınıza yeniden dağıtma özgürlüğü, böylece onlar da sizin kadar iyi kullanabilirler. İkincisi, programın sizi kontrol etmesi yerine sizin kontrol edebilmeniz için bir programı değiştirme özgürlüğü; bunun için kaynak kodun size sunulması gerekir.

1996'da, gnu.org web sitesi başlatıldığında, "özgür yazılım", yazılımı inceleme özgürlüğünden (iki noktalı tanımda şu şekilde okunabilir) açık bir söz eklenerek "üç özgürlük düzeyine" atıfta bulunularak tanımlandı. Stallman daha sonra "seviye" kelimesinden kaçınarak tüm özgürlüklerin gerekli olduğunu, dolayısıyla seviyeler açısından düşünmenin yanıltıcı olduğunu söyledi.

Son olarak, kullanıcıların programı çalıştırabilmesi gerektiğini açıkça söylemek için başka bir özgürlük eklendi. Mevcut özgürlükler zaten birden üçe numaralandırılmıştı, ancak bu özgürlük diğerlerinden önce gelmeliydi, bu yüzden "özgürlük sıfır" olarak eklendi.

Modern tanım, özgür yazılımı, alıcının aşağıdaki dört özgürlüğe sahip olup olmadığına göre tanımlar:

Programı istediğiniz gibi, herhangi bir amaç için çalıştırma özgürlüğü (özgürlük 0).

Programın nasıl çalıştığını inceleme ve bilgisayarınızı istediğiniz gibi yapması için değiştirme özgürlüğü (özgürlük 1). Kaynak koduna erişim bunun için bir ön koşuldur.

Komşunuza yardım edebilmeniz için kopyaları yeniden dağıtma özgürlüğü (özgürlük 2).

Değiştirilmiş sürümlerinizin kopyalarını başkalarına dağıtma özgürlüğü (özgürlük 3). Bunu yaparak, tüm topluluğa değişikliklerinizden yararlanma şansı verebilirsiniz. Kaynak koduna erişim bunun için bir ön koşuldur.

Richard Stallman tarafından yazılan ve Özgür Yazılım Vakfı (FSF) tarafından yayınlanan Özgür Yazılım Tanımı, özgür yazılımı, son kullanıcıların bu yazılımı kullanma, inceleme, paylaşma ve değiştirme özgürlüğüne sahip olmasını sağlayan yazılım olarak tanımlar. "Özgür" terimi, "ücretsiz" değil, "özgür konuşma" anlamında kullanılır. Tanımın bilinen en eski yayını, FSF tarafından artık durdurulan GNU's Bulletin yayınının Şubat 1986 baskısındaydı. Belgenin kanonik kaynağı, GNU Projesi web sitesinin felsefe bölümündedir. Nisan 2008 itibariyle burada 39 dilde yayınlanmaktadır. FSF, bu tanıma uyan lisansların bir listesini yayınlar.

Açık Kaynak Tanımı (The Open Source Definition) - opensource.org çevirisi

 Açık Kaynak Tanımı

Tanıtım

Açık kaynak sadece kaynak koduna erişim anlamına gelmez. Açık kaynaklı yazılımın dağıtım koşulları aşağıdaki kriterlere uygun olmalıdır:

1. Ücretsiz Yeniden Dağıtım

Lisans, herhangi bir tarafı, yazılımı birkaç farklı kaynaktan programları içeren toplu bir yazılım dağıtımının bir bileşeni olarak satmasını veya başka birine vermesini kısıtlamaz. Lisans, bu tür bir satış için telif hakkı veya başka bir ücret gerektirmez.

2. Kaynak Kodu

Program kaynak kodu içermeli ve kaynak kodun yanı sıra derlenmiş formda dağıtıma izin vermelidir. Bir ürünün herhangi bir biçiminin kaynak koduyla dağıtılmadığı durumlarda, kaynak kodunu makul bir çoğaltma maliyetinden fazla olmayan, tercihen İnternet üzerinden ücretsiz olarak indirerek elde etmenin iyi tanıtılmış bir yolu olmalıdır. Kaynak kodu, bir programcının programı değiştireceği tercih edilen form olmalıdır. Kasıtlı olarak karıştırılmış kaynak koduna izin verilmez. Bir önişlemcinin veya çevirmenin çıktısı gibi ara formlara izin verilmez.

3. Türetilmiş İşler

Lisans, değişikliklere ve türetilmiş çalışmalara izin vermeli ve bunların orijinal yazılımın lisansı ile aynı koşullar altında dağıtılmasına izin vermelidir.

4. Yazarın Kaynak Kodunun Bütünlüğü

Lisans, kaynak kodunun değiştirilmiş biçimde dağıtılmasını ancak lisans, "yama dosyalarının" kaynak kodla birlikte, derleme sırasında programı değiştirmek amacıyla dağıtılmasına izin veriyorsa kısıtlayabilir. Lisans, değiştirilmiş kaynak koddan oluşturulan yazılımın dağıtımına açıkça izin vermelidir. Lisans, türetilmiş çalışmaların orijinal yazılımdan farklı bir ad veya sürüm numarası taşımasını gerektirebilir.

5. Kişi ve Gruplara Karşı Ayrımcılık Yapılmaması

Lisans, herhangi bir kişi veya kişi grubuna karşı ayrımcılık yapmamalıdır.

6. Çalışma Alanlarına Karşı Ayrımcılık Yapılmaması

Lisans, hiç kimsenin programı belirli bir çalışma alanında kullanmasını kısıtlamamalıdır. Örneğin, programın bir işletmede kullanılmasını veya genetik araştırmalar için kullanılmasını kısıtlayamaz.

7. Lisansın Dağılımı

Programa bağlı haklar, bu taraflarca ek bir lisans yürütülmesine gerek kalmadan programın yeniden dağıtıldığı herkese uygulanmalıdır.

8. Lisans Bir Ürüne Özel Olmamalıdır

Programa eklenen haklar, programın belirli bir yazılım dağıtımının parçası olmasına bağlı olmamalıdır. Program bu dağıtımdan çıkarılırsa ve programın lisans koşulları dahilinde kullanılır veya dağıtılırsa, programın yeniden dağıtıldığı tüm taraflar, orijinal yazılım dağıtımıyla bağlantılı olarak verilenlerle aynı haklara sahip olmalıdır.

9. Lisans Diğer Yazılımları Kısıtlamamalıdır

Lisans, lisanslı yazılımla birlikte dağıtılan diğer yazılımlara kısıtlama getirmemelidir. Örneğin, lisans aynı ortamda dağıtılan diğer tüm programların açık kaynaklı yazılım olması konusunda ısrar etmemelidir.

10. Lisans Teknolojiden Tarafsız Olmalıdır

Lisansın hiçbir hükmü, herhangi bir bireysel teknolojiye veya arayüz stiline dayandırılamaz.