30 Aralık 2019 Pazartesi

SOLID - D : Dependency Inversion Principle

Butun projelerde maalesef ust sinif nesneler ve alt sinif nesneler birbiri ile bagimlidir , ve biz alt sinif nesnede bir degisiklige gittigimizde bu buna bagimli olan ust sinif nesnelerimizi de  etkiler.Bu basimiza buyuk sorunlar acabilir.Iste bagimliliklarin terslenmesi ile bu soruna cozum bulunmaya calisilmistir.Ust sinif ile alt sinif arayuzler yardimiyla baglandiginda cok daha iyi bir yapi kurulabilir.
























Goruldugu gibi burada Phone sinifi veritabanindan bilgi ceken sinifa bagimli bir durumda bunu nasil DIP prensibine uygun hale getirebiliriz?










































Arayuz olusturulup bunu PhoneDatabase sinifina implement edildi.Bu arayuz kullanildi.Phone sinifinin son hali yukaridaki gibidir.

27 Aralık 2019 Cuma

SOLID - I : Interface Segregation Principle

Bir sinifa arayuzu implement ettigimizde o arayuzun tum metotlarini da implement etmis oluyoruz ve bu o sinifin bazi fonksiyonlara ihtiyaci yoksada orada olmak zorunda.Iste burada bizim tasarimimizda o arayuzu parcalara bolerek gereksiz kullanimin onune gecmis oluruz.


Soyle bir muzik baglanti arayuzu olsun.












Bir Hoparlor sinifimiz bunu implement ettiginde tum baglantilari yapabiliyor.














 Yeni bir BluetoothHoparlor geldi ve baglanti gerekiyor.Buna da arayuzu implemet ediyoruz ama bir sorun var; bu hoparlorde rca girisi olmadigindan o metodu bos birakmak zorundayiz.









Hersey cok iyiyken MuzikSeti sinifi geldi MuzikSeti sadece rca ile baglanabiliyor.Diger iki metot bos kaldi.Hal boyle olunca arayuzde bir degisiklige gitmeliyiz .Arayuzu ayirmak.
Uc farkli arayuz olusturalim.











Uc ayri arayuze bolduk.













Siniflarin son hali asagidaki gibi olmustur.
































SOLID - L : Liskov Substitution Principle

Bu prensipte alt siniftan olusan nesnelerin ust siniftaki ile yer degistirildiginde ayni tepkiyi vermesi beklenmektedir.Asagidaki gibi siniflar olsun;



Soyut sinif









Ev telefonunun fotograf cekme ozelligi olmadigindan hata firlatiyor.















Burada t2 icin hersey sorunsuz ama t1 nesnesi icin isler pek iyi gitmiyor.Cunku bize hata firlatacak bu istemedigimiz birsey.Ust sinifiyla ayni tepkiyi veremedi.








Fotograf cekmeyi interface ile ayirip, soyut siniftan da metodu kaldirip  AkilliTelefon sinifina arayuzu ipmlement etmeliyiz.







26 Aralık 2019 Perşembe

SOLID - O : Open Closed Principle

Open Closed Principle`nin amaci sistemin degisime kapali ama gelismeye acik olmasidir.Nedir bu?
Yazilimin surekli sabit kalmasi pek olasi birsey olmayabilir, iste bu sebeple yeni eklentiler yeni ozellikler eklenmek istenebilir , ama eklerken onceden yazdigimiz yerlerin degismesini istemeyiz burdaki degisim budur.OPC`nin dedigi gelisme; yeni ekledigimiz kisimlar oyle olmali ki yerine direk oturmalidir eski siniflarimizda degisiklik olmadan yeni ozellikler icin yeni kodlar ekleyerek gelisimi saglamamiz.Bir ornekle durumu anlasir kilalim.




Burdaki gibi bir yapimiz olsun market, ogrenci olanlara bir indirim uygulasin.Bir sure sonra ogretmen olanlara da bir indirim uygulanmak istensin.







Yeni ekleyecegimiz Ogretmen sinifini olusturduk buraya kadar bir problem yok.






Ama burada indirim hesalayan eski sinifimizi da degistirmek zorunda kaldik.Bu degisime kapali gelisime acik prensibine uymayan, bizimde istemedigimiz birsey.



Bunun icin soyut Profil sinifini olusturduk ve diger siniflarimizi buradan turettik.

















Indirim sinifimizdaki metodun parametresinide Profil tipinde kullandigimizda , artik her yeni gelen durum icin , ornegin doktor icin bir indirimde bu sinif etkilenmeyecek sadece yeni ekledigimiz sinifi soyut siniftan turetip metodunu doldurmamiz yeterli olacaktir.
Not :Interface ile de bunu uygulayabilirdik.







SOLID - S : Single Responsibility Principle

Bu prensipte amac yazilimimizdaki bilesenlerimizin sadece bir tane sorumlulugu yerine getirmesi.Bilesenler;  siniflar, metotlar olabilir.Yani ornegin ogrenci bilgileri icin bir sinifimiz olsun burada veri kaydetme islemi yapmak tek sorumluluk prensibine aykiridir, Ogrenci sinifiyla yuksek bagliligi olmayan durumlarda bunu baska siniflar halletmelidir.


































Yapiyi su sekilde degistirirsek;

















Ogrenci sinifinin son hali boyle olacaktir.

13 Mart 2017 Pazartesi

Orm(Object Relational Mapping) nedir?

Orm nedir?

Normalde veritabanı sistemleri uygulama ve bir veritabanı ile birlikte çalışıyordu.Aşağıdaki gibi:
Burda uygulamamız direk olarak database ile bağlantılı ve gerekli işlemleri yapmak için sql bilmek zorundayız.
İşte bu sistemin bazı dezavantajları var veritabanı yönetim sistemi değiştiğinde bazı değişiklikler yapmak,tablolardaki bazı değişiklikleri yapmak için uzun sql kodarı ve diğer işlemler için zaman problemi gibi.
İşte bunları daha hızlı ve kolay yapabilmek için orm teknolojisi geliştirilmiş bu yapıda aşağıdaki resimde:

Orm (Object Relational Mapping) kısaca veritabanımızdaki tabloları sınıflara kolonları özelliklere ve kayıtlarıda nesnelere dönüştüren ve artık veritabanını bunlarla konrtol etmemizi sağlayan teknolojidir.Bizim yazdığımız kodlar uygulama tarafından sql kodlarına dönüştürülüyor.

Bu teknolojininde bazı dezavantajları var bunlar ;
Performans olarak daha yavaş.
Kontrol tamamen bizde değil.

İlişkisel Veritabanı nedir?

İlişkisel Veritabanı

Veritabanı konusunda bahsettiğimiz veri giriş yöntemlerinden olan tabloların belli kısıtlamalar ve anahtarlar ile aralarında bağ kurarak oluşturulan yönetim sistemidir.Şimdi biz eğer iki adet tablo oluşturduğumuzda bu tablolara veri ekleyip silebilir ve güncelleyebiliriz.Sonrasında oluşturduğumuz bu tablolar arasında bir bağ oluşturarak artık bir bilgi bulmak istediğimizde veya herhangi bir sql sorgusunda istediğimiz şeylere daha kolay ulaşabileceğiz.Tabiki tablo oluştururken de dikkat edilmesi gereken bir durum var oda normalizasyon şimdi ona bakalım;

Normalizasyon
Tablolar olabildiğince tek bir işi yapmalı karışık olmamalı eğer ortada iki tane olay varsa bunlar ayrı ayrı tablo halinde tutulmalı sonrasında bunları bir bağ ile bağlayıp kullanmalıyız işte bu olaya normalizasyon denir.
Bağ kurarken de anahtarlar kullanılır.

Primery key
Tablolarımızda birden fazla aynı isimde kayıt veya bir kayıdın birden fazla yerde olması gibi durumlarda çok fazla karışıklık olacaktır işte bu karışıklığı önlemek için primery key kullanıyoruz bu sayede herbir kayıt kendine has bilgi bir sayı tutuyor bunlar primery key oluyor.
Foreign key
Primery keylerimizi oluşturduk artık tablolar arası primery keyler arasında bağlantı kurabiliriz bu kurduğumuz bağlantıya ilişki denir.Bu kurduğumuz ilişkide ikinci anahtar foreign key oluyor.