SOLID prensibleri yazılım geliştiren hemen hemen herkesin en azından bir defa duymuş olduğu bir kısaltmadır. İnternette araştırıldığı zaman bu SOLID prensipleriyle ilgili binlerce içerik bulmanız mümkün. O sebeple ben bu yazıda detaya girmeden, yüzeysel olarak, ilk defa okuyacak kişinin bile kolaylıkla anlayabileceği tarzda özetler geçeceğim. 



SOLID prensipleriyle amaçlanan şey özetle, kodların yeniden kullanılabilirliliğini sağlamak ve projeye yeni bir özellik eklenecek olması durumunda, proje kodlarının okunurluluğunu koruyacak esnekliği projeye kazandırmaktır.

SOLID kısaltması, 5 temel prensibin baş harflerinden oluşmaktadır.

S – Single-Responsibility Principle (Her sınıf/fonksiyonun bir tek görevi olmalı)
O – Open-Closed Principle (Geliştirmeye açık değiştirmeye kapalılık prensibi)
L – Liskov Substitution Principle (Liskov yerine geçme prensibi)
I – Interface Segregation Principle (Interface ayrımı prensibi)
D - Dependency Inversion Principle (Dependency Injection uygulamak)

Single-Responsibility Prensibi

Bir Sınıfın ya da fonksiyonun, metodun tek bir görevi ve sorumluluğu olmalıdır. Başka sınıfların görevlerini gerçekleştirmemelidir. Fonksiyon bazında bir örnek vermek gerekirse, bir fonksiyon toplama işlemi yapmakla yükümlü ise, bu fonksiyona bölme işlemi yaptırmamak gerek. Daha somut bir örnekle bir fonksiyon bir kullanıcıya ait parola güncelleme işini üstlenmişse eğer, o fonksiyon sadece parola bilgisi güncellemesi gerekiyor, kullanıcıya ait başka verilerin güncellenmesi işlemini üstlenmemeli. Sınıf üzerinden bir örnek verecek olursam. Eğer Kullanıcı adında bir sınıfımız varsa bu sınıf, sadece kullanıcıya ait sorumlulukları üstlenmeli. Mesela kullanıcının adı, soyadı gibi kullanıcıya has değişkenler içermeli ve bu doğrultuda fonksiyonlar içermelidir. Mesela kullanıcı adını güncellemek, bu sınıfa ait bir fonksiyon olacaktır. Kullanıcıya ait adres bilgisini güncellemek gibi bir fonksiyona ihtiyaç duyarsak yada kullanıcının yaşadığı şehir, sokak, mahalle gibi değişkenlere ihtiyaç duyarsak, bu tarz bilgileri ve işlemleri Kullanıcı sınıfı üzerinden yapmak yerine Adres adında yeni bir sınıf oluşturup oradan gerçekleştirmek, tek bir sınıfa çok fazla sorumluluk yüklemeyi azaltacaktır. Bu da sınıfların daha temiz, anlaşılır yapıda olmasını sağlayacaktır.

Open-Closed Prensibi

Bir uygulamanın, objelerin yada entitylerin geliştirilmeye açık ancak değiştirmeye kapalı olduğunu belirtir. Örneğin elimizde televizyon adında bir sınıf yada interface var. Bu sınıfa ait tvAc() adında bir fonksiyonumuz var. Bir gün dedik ki bu televizyonu açıyoruz bir de buna televizyonu kapatma fonksiyonu ekleyelim. Böyle bir durumda tvAc(); fonksiyonunu editlemek zorunda kalıyorsak, Open-Closed prensibine aykırı bir iş yapıyoruz demektir. Kuracağınız yazılım mimarisini öyle bir dizayn etmeliyiz ki,  bir gün televizyonu kapatmak şeklinde bir implementasyona ihtiyaç dıuyarsak, tvAc(); fonksiyonuna hiç dokunmadan, Televizyon adlı sınıfımıza sadece tvKapat(); adında bir fonksiyon ekleyerek projeye televizyonu kapatma fonksiyonunu kolaylıkla implemente edebilmeliyiz.  Konuyu iyi anlattığını düşündüğüm şu yazıyı incelemenizi tavsiye ederim : https://www.gokhan-gokalp.com/open-closed-principle-ocp-acik-kapali-prensibi/  

Liskov Prensibi

Bir  abstract class yada interface içerisinde kullanılan yada tanımlanan fonksiyonlar, alt sınıflar tarafından override edilerek kullanılamıyorsa, Liskov prensibine aykırı bir kod yazmışız demektir. Çok beğendiğim ve her zaman verdiğim klima örneği vardır. Eminim bu örnekten sonra siz de bu prensibin asıl amacını kolaylıkla anlayacaksınız. Diyelim ki elimizde araba diye bir interface var. Bu interface içerisinde bir arabada olması gereken bazı fonksiyonları tanımladım. Mesela bu fonksiyonlardan bir tanesi klimaAc(); fonksiyonu olsun. Ben bu interface'i Ferrari ve Şahin adında 2 tane sınıfa implemente ederek kullanmak istedim diyelim. Ferrari'de klima olduğu için ben bu fonksiyonu Ferrari sınıfımda kolaylıkla implemente edebileceğim fakat Şahin sınıfında klima adında bir fonksiyon olması gerektiği halde, gerçek hayatta Şahin'in kliması olmadığını düşündüğünüz zaman, klimaAc(); fonksiyonu Şahin sınıfı içerisinde ya NULL bir response dönecek yada Exception fırlatan bir fonksiyon olacaktır. Bu da Liskov prensibine aykırı bir davranıştır. 

Interface Segregation Prensibi

Bir interface içerisinde tanımlı olan fonksiyon, implement edilecek class’lardan birinde bile kullanılmıyorsa, o interface sınıfını ikiye böl veya farklı interface yaz. Kısacası, bir class içerisinde hiçbir zaman kullanılmayacak bir interface fonksiyonu yer almamalı. Örneğin Liskov başlığı altında araba - klima örneğini verdim. Eğer klima özelliği her araçta yoksa, LüksAraclar şeklinde yeni bir interface oluşturabiliriz. Tabii ki günümüzde artık bir aracın klimalı olması lüks değil ama ben konuyu daha anlaşılabilir kılmak için böyle bir örnek vermek istedim.

Dependency Inversion Prensibi

Sınıflar arası bağımlılığı en azaltan bir prensiptir. Bu prensibin implementasyonuna ise Dependency Injection denmektedir.  Bu prensip, üst sınıfı doğrudan alt sınıfa bağlamak yerine, üst sınıfa ait nesneyi alt sınıfa enjekte etmeyi tavsiye eder. Bunu yapmak için ise üst sınıfa ait nesne, alt sınıfta parametre olarak kullanılır. Eğer Spring Boot kullanıyorsanız, bunu @Autowired notasyonu ile defalarca farkında olmadan yapmışsınıdır. Notasyon kullanmadan, getter ve setter metodlarla veya doğrudan constructor sınıflar aracılığıyla üst sınıf nesnesini, başka bir sınıfa parametre olarak verebilirsiniz. Aslında @Autowired notasyonu da bunu yapıyor. Böylece üst sınıfa ait implementasyonları istediğimiz sınıfın içerisinde kullanabiliyoruz. Bu prensip, sınıflar arası"decoupling" yapıyor. Bu sayede sınıfları birbirinden soyutlayarak ayrıştırmış oluyoruz. Bu sayede proje büyüdükçe ortaya çıkabilecek kod karmaşasını önleyerek, projeye esneklik kazandırmış oluyoruz. Bu konuyla ilgili internette binlerce içerik ve örnek var. Ufak bir aramayla bir sürü örneğe ulaşabilir ve bu konuyu daha da pekiştirebilirsiniz. Bana göre yazılım geliştirme alanında mutlaka bilinmesi, hakim olunması gereken bir konu.

• Spring Anotasyonlarının Çalışma Mantığı ve Temel Anotasyonlar

• PHP'nin sizce geleceği var mı?
• İyi bir PHP programcısı ne kadar para kazanır?
• Mobilleşme gittikçe artarken PHP değer kaybetmez mi?
• Sizce hangi programlama dilinin geleceği var?

"Sen ilerde ne yapmak istiyorsun?" 

• JAVA + JSP
• ASP.NET
• PHP

• Gittigidiyor
• Sporx
• Facebook
• Sahibinden.com
• Wordpress

PHP'nin geleceği var. Özellikle son zamanlarda Laravel gibi PHP çatılarıyla beraber artık PHP'ye de nesne yönelimli bir özellik kazandırıldı. Laravel tarzı PHP çatıları sayesinde PHP'nin kullanımına olan ilginin daha da artacağı düşüncesindeyim.

Konu içerisinde bunu açıkladım ve kazanç olarak asp ve jsp'ye göre daha az kazanç sağlar gibime geliyor. Orta ölçekli firmalarda asgari ücret ile başlanır Büyük şirketlerde ise bu ücret asgarinin üzerinde olmak üzere, değişkenlik gösterebilir. Elbette ki, kişi kendini geliştirdikçe elde edeceği kazança da artacaktır.

Mobil ile beraber web programlama popülerliği artan iki alan. Bu durumun PHP'yi olumsuz etkileyeceğini düşünmüyorum şahsen.

Yapacağın işe göre, takım arkadaşlarının veya bulunduğun şirketin kullanacağı programlama diline göre bu değişiklik gösterir. O yüzden herhangi bir programalama dilinin fanatiği olmamak gerek. Programlama dili ismi vermeyi çok doğru bulmasam da, kullanım olarak son zamanlarda Java'nın ciddi bir yükselişte olduğunu söyleyebilirim.

['icerik'=>"Hoşgeldiniz"]

 multiDexEnabled true

compile 'com.android.support:multidex:1.0.0'

Bu örnek gösterim developer.android.com sitesiden alınmıştır.

android:name="android.support.multidex.MultiDexApplication"

$kontrol = "/\S*((?=\S{8,})(?=\S*[A-Z]))\S*/"; 

mysqli_query() Nasıl Kullanılır?

• 1 tane webBrowser
• 1 tane textbox
• 1 tane buton

int dizi[5] = {3,5,8,9,7};

int *p;
p = dizi;

cout << *p;

p++;
cout << *p;

int p;

int *p;

p = &a;

Resmi büyütmek için üzerine tıklayınız.

Liste İçinde Gezmek / Listedeki Tüm Verileri Konsolda Listelemek