İÇİNDEKİLER

1.​ Clean Code

a.​ Clean Code Önemi
b.​ Clean Code ve Teknik Borç
2.​ Clean Code Yazılım Prensipleri
a.​ Single Responsibility Principle (SRP)
b.​ Open/Closed Principle (OCP)
c.​ Liskov Substitution Principle (LSP)
d.​ Interface Segregation Principle (ISP)
e.​ Dependency Inversion Principle (DIP)
f.​ Don’t Repeat Yourself (DRY)
g.​ Keep It Simple, Stupid (KISS)
h.​ You Ain’t Gonna Need (YAGNI)
i.​ Principle of Least Astonishment (POLA)
j.​ Tell, Don’t Ask (TDA)
k.​ Law of Demeter (LoD)
3.​ Clean Code Yazarken Dikkat Edilmesi Gerekenler
a.​ Anlamlı ve Açıklayıcı İsimlendirme
b.​ Tek Sorumluluk
c.​ Fonksiyonlar Küçük ve Odaklı Olmalıdır
d.​ Magic Number Kullanımından Kaçının
e.​ Test Edilebilirlik
f.​ Hataları İşleme
g.​ Yorum Satırları
h.​ Düzenli Kodlar
4.​ Yazılım Mülakatına Hazırlık
 Clean Code
Clean Code (Temiz Kod), yazılım geliştirme sürecinde kodun anlaşılır, bakımı kolay ve
sürdürülebilir olmasını sağlayan bir yazım ve tasarım felsefesidir. İlk olarak Robert C. Martin
(Uncle Bob) tarafından "Clean Code: A Handbook of Agile Software Craftsmanship"
kitabında detaylı ele alınmıştır. Temiz kod, sadece çalışır durumda olan bir koddan
fazlasını ifade eder; okunabilir, modüler, genişletilebilir ve hataya karşı dayanıklı bir kod
yazmayı amaçlar.

Clean Code Önemi

Bir yazılım projesinde kodun çalışması yeterli değildir, aynı zamanda bakımının kolay ve
geliştirilmeye açık olması da gereklidir. İşte temiz kodun neden önemli olduğuna dair bazı
nedenler:

1.​ Okunabilirlik: Kodun daha anlaşılır olması, geliştiricilerin projeyi daha hızlı
kavramasına yardımcı olur.
2.​ Bakım Kolaylığı: İlerleyen süreçte hataları gidermek veya yeni özellikler eklemek
daha az zaman alır.
3.​ İşbirliği: Takım içinde kodu paylaşmayı ve birlikte çalışmayı kolaylaştırır.
4.​ Test Edilebilirlik: Temiz kod, daha az hata içerir ve test edilmesi daha kolaydır.
5.​ Verimlilik: Kötü kod, zaman içinde teknik borç oluşturur ve projenin gelişimini
yavaşlatır.
Clean Code ve Teknik Borç
Teknik borç (technical debt), yazılım geliştirme sürecinde kısa vadeli çözümler nedeniyle
biriken ve ilerleyen süreçte büyük maliyetlere yol açan problemlerdir.

Teknik Borç Neden Oluşur?

●​ Erken aşama geliştirme süreçlerinde hızlı ilerleme adına yapılan geçici çözümler,
düzensiz ve sürdürülemez kodlara yol açabilir.
●​ Altyapıda dokümantasyon eksikliği olduğunda, kodun hangi işlevi yerine getirdiği
anlaşılamaz ve bu durum zaman kaybına yol açar. Yapılan her değişiklik mutlaka
dokümantasyona eklenmeli, süreç şeffaf bir şekilde yönetilmelidir. "Kodu yazdım,
sadece benim bilmem yeterli" anlayışı yanlıştır ve profesyonel yazılım
geliştirme etiğine aykırıdır.
●​ Yeterince test edilmemiş kodlar gelecekte ciddi sorunlara neden olabilir. Kodun
sürdürülebilir, güvenilir ve hatasız olması için kapsamlı test süreçleri uygulanmalıdır.
●​ Duplicate kodların yazılması ve DRY prensibine uyulmaması, kod tekrarını artırarak
bakım maliyetini yükseltir.
●​ Ekip üyelerinin farklı kodlama standartlarına sahip olması, kod bütünlüğünü bozar ve
okunabilirliği zorlaştırır.
●​ Uygulamanın küçük, bağımsız ve tekrar kullanılabilir parçalara bölünmemesi, teknik
borcun büyümesine neden olur.

Teknik Borç Sonuçları

●​ Bakım maliyeti artar, eski kodların düzeltilmesi ve optimize edilmesi ciddi zamanlar
alabilir.
●​ Düzensiz kod yapısı, yeni özellikler eklerken zaman kaybına neden olur ve
deadline'lara yetişmeyi zorlaştırır.
●​ Teknik borç arttıkça, kodun yeniden düzenlenmesi (refactoring) kaçınılmaz hale
gelir ve bu süreç ek kaynak gerektirir.
●​ Karmaşık ve bakımı zor kodlarla çalışmak, uzun vadede ekip motivasyonunu
olumsuz etkileyebilir.
●​ Teknik borç yönetilmezse, yazılımın bakımı giderek zorlaşır ve belirli bir
noktadan sonra sistemi yeniden yazmak kaçınılmaz hale gelebilir.

Teknik Borç Çözümlerinden Bazıları

●​ Clean Code prensiplerine bağlı kalınmalıdır.
●​ Review süreçleri geliştirilmelidir.
●​ Otomatik Test ve CI/CD kullanılmalıdır.
●​ Modüler ve esnek yapı tercih edilmelidir.
●​ Kod ve altyapı dokümantasyonu eksiksiz tutulmalıdır. Olası bir sorun durumunda
ekip içinde bilgi paylaşımı yapılmalıdır.
 Clean Code Yazılım Prensipleri
Temiz kod yazmak, bir dizi prensibe dayanır. Bu prensipler, sadece kodun verimli çalışmasını
değil, aynı zamanda bakımının kolay, okunabilirliğinin yüksek ve anlaşılabilirliğinin sağlam
olmasını hedefler.

Single Responsibility Principle (SRP)

Single Responsibility, her sınıfın, fonksiyonun veya modülün yalnızca bir sorumluluğu olması
gerektiğini söyler. Yani, bir sınıf yalnızca tek bir görevi yerine getirmeli ve yalnızca bu
görevi değiştiren sebeplerle değiştirilebilir olmalıdır.

SRP’ye Aykırı Kod Örneği:

public class Student {​
String name;​
int studentNo;​
​
public Student(String name, int studentNo) {​
[Link] = name;​
[Link] = studentNo;​
}​
​
public void save() {​
[Link]("Saved.");​
}​
​
public void information() {​
[Link]("Student: " + name);​
}​
​
}

SRP’ye Uygun Kod Örneği:

public class Student {​
String name;​
int studentNo;​
​
​
public Student(String name, int studentNo) {​
[Link] = name;​
[Link] = studentNo;​
}​
​
}
Open/Closed Principle (OCP)
OCP'nin temel fikri, bir yazılım varlığı (sınıf, fonksiyon, modül vb.) genişlemeye açık olmalı,
ancak değişikliğe kapalı olmalıdır şeklinde özetlenebilir. Bu prensip, yazılımda mevcut
işlevselliğe zarar vermeden yeni özellikler eklemeyi sağlar.

OCP’ye Aykırı Kod Örneği: VIP ve gold gibi fatura türleri ekleneceği zaman discount’a
müdahele edilirse ilke çiğnenir.

public class Invoice {​

private double amount;​
private String invoiceType;​
​
public Invoice(double amount, String invoiceType) {​
[Link] = amount;​
[Link] = invoiceType;​
}​
​
public double calculateDiscount() {​
if ([Link]("regular")) {​
return amount * 0.1;​
} else if ([Link]("premium")) {​
return amount * 0.2;​
} else {​
return 0;​
}​
}​
}
OCP’ye Uygun Kod Örneği:
public abstract class Discount {​
public abstract double calculate(double amount);​
}​
​
​
public class RegularDiscount extends Discount {​
@Override​
public double calculate(double amount) {​
return amount * 0.1; // Regular indirim oranı​
}​
}​
​
​
public class PremiumDiscount extends Discount {​
@Override​
public double calculate(double amount) {​
return amount * 0.2; // Premium indirim oranı​
}​
}​
​
​
public class Invoice {​
private double amount;​
private Discount discountStrategy;​
​
public Invoice(double amount, Discount discountStrategy) {​
[Link] = amount;​
[Link] = discountStrategy;​
}​
​
public double calculateDiscount() {​
return [Link](amount);​
}​
}​
​
public class Main {​
public static void main(String[] args) {​
Invoice regularInvoice = new Invoice(1000, new RegularDiscount());​
[Link]("Regular Invoice Discount: " +
[Link]()); // 100.0​
​
Invoice premiumInvoice = new Invoice(1000, new PremiumDiscount());​
[Link]("Premium Invoice Discount: " +
[Link]()); // 200.0​
}​
}
Liskov Substitution Principle (LSP)
Liskov Substitution, bir sınıfın türetilmiş sınıflarının, üst sınıfının yerine kullanılabilir olmasını
ifade eder. Yani, alt sınıflar, üst sınıfın beklenen davranışını bozmadan onun yerine
geçebilmelidir.

LSP’ye Aykırı Kullanım Örneği:

class Bird {​
public void fly() {​
[Link]("Bird is flying");​
}​
}​
​
class Penguin extends Bird {​
@Override​
public void fly() {​
// Penguenler uçamaz, ancak fly() metodunu override ediyoruz​
throw new UnsupportedOperationException("Penguins can't fly");​
}​
}

LSP’ye Uygun Kullanım Örneği:

// Soyut Kuş sınıfı​
abstract class Bird {​
public abstract void move();​
}​
​
// Uçabilen Kuş sınıfı​
class FlyingBird extends Bird {​
@Override​
public void move() {​
[Link]("Flying bird is flying");​
}​
}​
​
// Penguin sınıfı​
class Penguin extends NonFlyingBird {​
@Override​
public void move() {​
[Link]("Penguin is swimming");​
}​
}
Interface Segregation Principle (ISP)
Interface Segregation, bir sınıfın sadece ihtiyacı olan metodları içeren arayüzleri kullanması
gerektiğini söyler. Kapsamlı ve çok sayıda metodu içeren büyük arayüzler yerine, daha
küçük ve spesifik arayüzlerin tercih edilmesi gerektiğini ifade eder. Bu, gereksiz
bağımlılıkları azaltır ve sınıfların sadece ihtiyaç duydukları işlevselliği almasını sağlar.

ISP’ye Aykırı Kod Örneği:

public interface CrudRepository {​
void create();​
void read();​
void update();​
void delete();​
}

ISP’ye Uygun Kod Örneği:

public interface Creatable {​
void create();​
}​
​
public interface Readable {​
void read();​
}​
​
public interface Updatable {​
void update();​
}​
public interface Deletable {​
void delete();​
}​
​
public interface CrudRepository extends
Creatable,Readable,Updatable,Deletable{​
}
Dependency Inversion Principle (DIP)
Üst seviyedeki modüller, alt seviyedeki modüllere doğrudan bağımlı olmamalıdır.
Bunun yerine, her iki seviyedeki modüller de soyutlamalara (arayüz veya abstract class gibi)
bağımlı olmalıdır.

DIP’e Aykırı Kod Örneği:

package [Link].dependency_inversion.against;​
​
public class EmailService {​
public void sendEmail(String message) {​
[Link]("Sending email: " + message);​
}​
}​
​
package [Link].dependency_inversion.against;​
​
public class OrderService {​
private EmailService emailService;​
​
public OrderService() {​
[Link] = new EmailService();​
}​
​
public void placeOrder(String orderDetails) {​
// Sipariş Mantığı​
[Link]("Order placed: " + orderDetails);​
​
// Sipariş verildikten sonra mail at​
[Link]("Order placed: " + orderDetails);​
}​
DIP’e Uygun Kod Örneği:
package [Link].dependency_inversion.suitable;​
// Soyutlama: EmailSender interface​
public interface EmailService {​
void sendEmail(String email, String content);​
}

package [Link].dependency_inversion.suitable;​
​
​
/**​
* Daha önce üst seviye modüller doğrudan alt seviyedeki sınıfa
bağımlıydı,​
* bu da Dependency Inversion Principle (DIP) ilkesine aykırıydı.​
* Bu bağımlılığı bir arayüz (EmailService) kullanarak ortadan
kaldırdık.​
* Artık üst seviye modüller, doğrudan bir somut sınıfa bağımlı olmak
yerine,​
* soyut bir arayüze (EmailService) bağımlı hale getirildi.​
*/​
public class EmailServiceImpl implements EmailService {​
@Override​
public void sendEmail(String email, String content) {​
[Link]("Mail Gönderildi");​
}​
}​
public class OrderService {​
private EmailService emailService;​
​
public OrderService(EmailService emailService) {​
[Link] = emailService;​
}​
​
public void placeOrder(String orderDetails) {​
[Link]("Order placed: " + orderDetails);​
​
[Link]("customer@[Link]", "Order placed: "
+ orderDetails);​
}​
}
Don’t Repeat Yourself (DRY)
Don’t Repeat Yourself, tekrarlayan kodun önlenmesi gerektiğini savunur. Kod tekrarını
önlemek için metotlar, sınıflar ve modüller kullanılmalıdır.

DRY'ye Aykırı Kod Örneği:

package [Link].dont_repeat_yourself.against;​
​
public class Employee {​
private long id;​
private String fullName;​
private String department;​
​
/**​
* DRY prensibine aykırı kullanımdır.​
* @return​
*/​
@Deprecated​
public String getDetails(){​
return [Link]("%s %s %s",id,fullName,department);​
}​
}​
​
​
public class Employer {​
private long id;​
private String fullName;​
private String department;​
​
/**​
* DRY prensibine aykırı kullanımdır.​
* @return​
*/​
@Deprecated​
public String getDetails(){​
return [Link]("%s %s %s",id,fullName,department);​
}​
}
DRY’ye Uygun Kod Örneği:
public class Employee extends Person{​
}
​
public class Employer extends Person{​
}
​
public class Person {​
private long id;​
private String fullName;​
private String department;​
​
/**​
* DRY prensibine uygun bir kullanım sağlanmıştır.​
* Tekrarlayan kodların önüne geçmek için ortak işlevler base class
içinde tanımlanmalıdır.​
*​
* @return Kişi bilgilerini içeren metin​
*/​
​
public String getDetails() {​
return [Link]("%s %s %s", id, fullName, department);​
}​
}
Keep It Simple, Stupid (KISS)
KISS, kodun basit ve anlaşılır olması gerektiğini vurgular. Ne kadar kompleks kod varsa
hata yapma ihtimali bir o kadar yüksektir.

KISS’e Aykırı Kod Örneği:

public class Calculator {​
public static double calculateArea(String shape, double... params) {​
if ("rectangle".equals(shape) && [Link] == 2) {​
return params[0] * params[1];​
} else if ("triangle".equals(shape) && [Link] == 2) {​
return 0.5 * params[0] * params[1];
} else {​
throw new IllegalArgumentException("Invalid shape or
parameters");​
}​
}​
}
KISS’e Uygun Kod Örneği:
public interface Shape {​
double calculateArea();​
}​
public class Rectangle implements Shape {​
​
private double width;​
private double height;​
​
public Rectangle(double width, double height) {​
[Link] = width;​
[Link] = height;​
}​
​
@Override​
public double calculateArea() {​
return width * height;​
}​
}​
public class Triangle implements Shape {​
​
private double base;​
private double height;​
​
public Triangle(double base, double height) {​
[Link] = base;​
[Link] = height;​
}​
​
@Override​
public double calculateArea() {​
return 0.5 * base * height; ​
}​
}
You Ain’t Gonna Need It (YAGNI)
You Ain’t Gonna Need It, ihtiyaç olmadıkça bir özellik geliştirilmesi gerekmediğini
söyler.

YAGNI’ye Aykırı Kod Örneği:

class OrderService {​
private boolean isDiscountAvailable;​
private boolean isFreeShippingAvailable;​
​
public OrderService() {​
isDiscountAvailable = true; // Şu anda kullanılmıyor​
isFreeShippingAvailable = false; // Şu anda kullanılmıyor​
}​
​
public void placeOrder(String orderDetails) {​
// Order logic​
[Link]("Order placed: " + orderDetails);​
​
// Gereksiz özelliklerin kontrolü​
if (isDiscountAvailable) {​
// Discount işlemi eklenebilir, ancak şu anda gereksiz​
[Link]("Discount applied");​
}​
​
if (isFreeShippingAvailable) {​
// Free shipping işlemi eklenebilir, ancak şu anda gereksiz​
[Link]("Free shipping applied");​
}​
}​
}
YAGNI’ye Uygun Kod Örneği: Kullanılmayan gereksiz özellikleri kaldırmamız doğru ve
uygun olacaktır.
Principle of Least Astonishment (POLA)
Principle of Least Astonishment, kodun beklenildiği gibi çalışması gerektiğini söyler.
Ayrıca, bir metot veya fonksiyon ismi amacını doğru yansıtması gerektiğini vurgular.
Türkçede En az şaşırtma ilkesi olarak çevirebiliriz.

POLA’ya Aykırı Kod Örneği:

public class BankAccount {​
private double balance;​
​
/**​
* Banka Müşterisi bakiye öğrenmek isterken bakiyenin azalmasını
istemez.​
* Principle of Least Astonishment'e aykırı kullanımdır.​
* @return Bakiye azalarak döner.​
*/​
public double getBalance() {​
[Link] -= 10; // Beklenmeyen bir yan etki var!​
return balance;​
}​
}
POLA’ya Uygun Kod Örneği:
public class BankAccount {​
private double balance;​
​
public double getBalance() {​
return balance;​
}​
​
public void drawMoney(double amount) {​
if (balance >= amount) {​
balance -= amount;​
}​
}​
}
Tell, Don’t Ask (TDA)
Tell, Don’t Ask (TDA), bir nesneye verilerini sorgulatmak yerine, ona ne yapması
gerektiğini söylememiz gerektiğini belirten bir prensiptir. Yani, bir nesneden iç
durumunu sorgulamak ve dışarıda bu verilerle kararlar almak yerine, nesneye belirli bir
eylemi yapmasını söylemeli ve nesnenin bunu kendi içinde nasıl yapacağını belirlemesine
izin vermeliyiz. Bu yaklaşım, daha kapsüllenmiş ve uyumlu bir tasarım sağlar; çünkü
nesneler kendi davranışlarından ve iç durumlarından sorumludur.

TDA'ya Aykırı Kod Örneği:

class Order {​
private boolean isPaid;​
​
public boolean isPaid() {​
return isPaid;​
}​
​
public void setPaid(boolean paid) {​
[Link] = paid;​
}​
}​
​
class OrderService {​
public void processOrder(Order order) {​
if (![Link]()) { // Nesnenin verisi sorgulanıyor​
[Link]("Payment required before processing.");​
} else {​
[Link]("Order processed.");​
}​
}​
}
TDA’ya Uygun Kod Örneği:
class Order {​
private boolean isPaid;​
​
public void pay() {​
[Link] = true;​
}​
​
public void process() {​
if (!isPaid) {​
[Link]("Payment required before processing.");​
return;​
}​
[Link]("Order processed.");​
}​
}​
​
class OrderService {​
public void handleOrder(Order order) {​
[Link](); // Order nesnesine işlem yapması söyleniyor​
}​
}
Law Of Demeter (LoD)
Law of Demeter, bir nesnenin yalnızca doğrudan ilişkili olduğu nesnelerle iletişim
kurmasını ve dolaylı erişimden kaçınmasını önerir.

LoD’a Aykırı Kod Örneği:

public class Address {​
private String city;​
​
public Address(String city) {​
[Link] = city;​
}​
​
public String getCity() {​
return city;​
}​
}​
public class Person {​
private Address address;​
​
public Person(Address address) {​
[Link] = address;​
}​
​
public Address getAddress() {​
return address;​
}​
}​
​
public class OrderService {​
/**​
* Bu metot, Demeter Yasası'nı ihlal etmektedir çünkü zincirleme
metod çağrıları yapmaktadır.​
* Nesneler arasındaki iç içe verilere doğrudan erişim, kapsüllemeyi
azaltır ve bağlılık (coupling) yaratır.​
* Bunun yerine, Person sınıfı, şehri doğrudan döndüren bir metod
sağlamalıdır.​
* @param person​
*/​
public void printCity(Person person) {​
[Link]([Link]().getCity()); // zincirleme
metot çağrısı yapılıyor​
}​
}
LoD’a Uygun Kod Örneği:
public class Address {​
private String city;​
​
public Address(String city) {​
[Link] = city;​
}​
​
public String getCity() {​
return city;​
}​
}​
public class Person {​
private Address address;​
​
public Person(Address address) {​
[Link] = address;​
}​
​
public String getCity() { // Doğrudan şehir bilgisini döndürüyor​
return [Link]();​
}​
}​
​
public class OrderService {​
public void printCity(Person person) {​
[Link]([Link]()); // Chain erişim yok​
}​
}
 Clean Code Yazarken Dikkat
Edilmesi Gerekenler

Anlamlı ve Açıklayıcı İsimlendirme

Kod yazarken, değişkenler, fonksiyonlar, sınıflar ve metodlar için açık ve anlamlı isimler
kullanılmalıdır. Değişken isimleri, yapılan işi açıkça belirtmelidir. Ayrıca, yazılım geliştirme
sürecinde uluslararası ekiplerle çalışabileceğimiz için, yazılımda Türkçe terimler
kullanmamaya özen gösterilmelidir.

Yanlış:
int b; // Bu değişkenin ne anlama geldiği belli değil.
Doğru:
int balance; // Değişkenin neyi ifade ettiği açıkça belirtiliyor.

Tek Sorumluluk
Bir fonksiyon veya sınıf yalnızca tek bir sorumluluğa sahip olmalıdır. Eğer bir fonksiyon
birden fazla iş yapıyorsa, anlaşılması ve değiştirilmesi zor hale gelir.

Fonksiyonlar Küçük ve Odaklı Olmalıdır

Fonksiyonlar mümkün olduğunca kısa olmalı ve gereksiz karmaşıklıktan kaçınılmalıdır.

Yanlış:
public void processEmployeeData() {​
// Çalışan verilerini oku​
// Verileri doğrula​
// Maaş hesapla​
// Sonuçları yazdır​
// Veritabanına kaydet​
}
Doğru:
public void processEmployeeData() {​
Employee employee = readEmployeeData();​
validateEmployeeData(employee);​
double salary = calculateSalary(employee);​
printEmployeeData(employee, salary);​
saveToDatabase(employee, salary);​
}
Magic Number Kullanımından Kaçının
Enum sabitlerini kullanırken sıfır veya bir gibi sayısal ifadelere yer vermeyin. Bu numaralar
yerine anlamlı sabitler tanımlayın.

Yanlış:
if (userType == 1) {​
// Admin işlemleri​
} else if (userType == 2) {​
// Kullanıcı işlemleri​
}
Doğru:
public enum UserType {​
ADMIN, USER;​
}​
​
if (userType == [Link]) {​
// Admin işlemleri​
} else if (userType == [Link]) {​
// Kullanıcı işlemleri​
}

Test Edilebilirlik
Kodun test edilebilir olması önemlidir. Fonksiyonlar bağımlılıklardan arındırılmalı ve test
yazmaya uygun olmalıdır.

Yanlış:
public double calculateTotalPrice(double price) {​
double tax = price * 0.18;​
[Link]("Vergi hesaplandı: " + tax);​
return price + tax;​
}
Doğru:
public double calculateTotalPrice(double price, double taxRate) {​
return price + (price * taxRate);​
}
Hataları İşleme
Hataları işleme, kodun sağlıklı çalışmasını sağlar. Hata durumlarının belirlenmesi, kodun
güvenilirliğini artırır ve kullanıcı deneyimini iyileştirir.

Yorum Satırları
Kodun anlaşılması için yorum satırları eklenmelidir. Ancak kodun kendisi kadar önemli olan
yorum satırları, mümkün olduğunca az kullanılmalıdır.

Düzenli Kodlar
Kod, belirli bir düzen içinde yazılmalıdır. Kod, boşluklar, girintiler ve diğer kodlama
standartlarına uygun olarak yazılmalıdır. Böylece kodun okunması ve anlaşılması daha kolay
hale gelir.

Clean Code yazarken dikkat edilmesi gerekenler buraya kadardı. Artık Yazılım
Mülakatına Hazırlık sayfasına geçebilirsiniz.
 Yazılım Mülakatına Hazırlık
Yazılım mülakatlarına hazırlanırken karşınıza çıkabilecek soruları ve bu sorulara nasıl yanıt
vereceğinizi keşfetmeye hazır olun. Bu bölümde, yazılım mülakatlarında sıkça karşılaşılan
soruları öğrenerek, deneyim kazanmış olacaksınız.

1) Open Closed Principle nedir ve sınıf tasarımıyla ne tür ilişkisi vardır?

●​ Polimorfizm ve soyutlama kullanılarak genişletilebilirlik sağlanır.

●​ Arayüzler ve soyut sınıflar ile yeni davranışlar eklenebilir.
●​ Bağımlılık enjeksiyonu (Dependency Injection) sayesinde değişiklik
yapmadan bileşenler değiştirilebilir.

2) Clean Code hakkında ne düşünüyorsun?

Kısa ve net özetlemek gerekirse, yazılım altyapısında yazılmış kodlarımızın daha

düzenli, test edilebilir ve verimli olmasını sağlamaktır.

3) S.O.L.I.D prensiplerine ne kadar hakimsin? Kısaca bahsedebilir misin.

SRP: Bir sınıfın yalnızca bir sorumluluğu olmalı.

OCP: Yeni özellik eklenebilir, mevcut kod değiştirilmemeli.
LSP: Alt sınıflar, üst sınıfın yerine geçebilir, beklenmedik davranışlar olmamalı.
ISP: Sınıflar, sadece kullandıkları metodları içeren arayüzleri implement etmeli.
DIP: Yüksek seviye modüller, soyutlamalara bağlı olmalı, somut sınıflara değil.

4) Uncle Bob kimdir?

Uncle Bob, özellikle SOLID prensipleri, temiz kod (Clean Code), yazılım tasarımı ve
yazılım mühendisliği konularındaki katkılarıyla bilinir.