Up next in 10
Auzef Nesneye Yönelik Programlama 2025-2026 Final Soruları
https://lolonolo.com/2026/09/15/nesneye-yonelik-programlama-2025-2026-final-sorulari/
auzef, Bilgisayar Programcılığı, Nesneye Yönelik Programlama, Yönetim Bilişim Sistemleri
Show More Show Less View Video Transcript
0:00
Lolo Nolo platformuna hoş geldiniz. Bu
0:02
dersimizde 2025-2026 nesneye yönelik
0:05
programlama, OOP konularını, çıkmış
0:08
sorularını ve detaylı açıklamalarını
0:10
derinlemesini inceliyoruz. Hani hep
0:12
derler yazılımın asıl sihrini anlamak
0:14
istiyorsan kaputun altına bakmalısın
0:16
diye. İşte biz de tam olarak bunu
0:18
yapacağız. Hazırsanız yazılım dünyasının
0:20
temel mimarisi olan bu büyüleyici
0:22
yapıları tüm detaylarıyla çözmeye
0:23
başlayalım. Bugünkü haritamız oldukça
0:26
net. Önce Lolo, Nolo, OOP temelleri ile
0:28
başlıyoruz. Ardından sınıflararası
0:30
ilişkilere bakacağız. Sonra biraz daha
0:33
derinlere inip soyutlama ve çok
0:35
biçimlilik diyeceğiz. Ve son olarak da
0:37
C#arp bellek yönetimi ile işi
0:39
noktalayacağız. Mimariden belleğe tam
0:41
teşekküllü bir yolculuk bizi bekliyor.
0:44
Evet, birinci bölümümüz Lolo, Nolo, OOP
0:47
temelleri.
0:48
>> Nesneye yönelik programlama aslında
0:50
gerçek dünyayı alıp kodlara dökme
0:52
sanatıdır. Düşünün ki devasa bir mimari
0:54
projeniz var. Ortada bir sınıf yani
0:56
klass var. Bu aslında sadece bir şablon.
0:59
Mesela taşıt dediğimizde bu çok genel
1:01
bir kavram değil mi? Binip gidemezsiniz
1:03
çünkü ortada henüz fiziksel bir şey yok.
1:05
Ama o şablondan o sihirli new kelimesini
1:08
kullanarak kırmızı yepyeni bir otomobil
1:11
üretirseniz işte o artık somut bir
1:13
örnektir. Yani şablonun hayata geçmiş
1:15
fiziksel bir kopyası. Tamamen kullanıma
1:18
hazır kanlı canlı bir nesnedir. Peki bu
1:21
somut örnek tam olarak nasıl hayata
1:23
dönüyor dersiniz? İlk adım belli.
1:25
Şablonumuzu yani sınıfı tanımlıyoruz.
1:27
Sonrasında az önce bahsettiğim o new
1:29
anahtar kelimesi sahneye çıkıyor. Asıl
1:31
can alıcı nokta ise tam da bu andan
1:33
sonra yaşanıyor. Bellekte o nesneyi
1:35
oluşturduğunuz saniye sistemde otomatik
1:37
olarak bir şey tetikleniyor. Buna
1:39
constructor yani yapıcı metot diyoruz.
1:42
Constructor her zaman istisnasız olarak
1:44
ilk çalışan metottur. Nesnemize tabiri
1:46
caizse bu ilk nefesini veren tüm
1:49
başlangıç ayarlarını yükleyen mekanizma
1:51
tam olarak budur. İşte şimdi ya bu
1:53
özelle hazırladığımız verilere dışarıdan
1:56
biri ya da sistemdeki acemi bir kod
1:58
bloğu kazara müdahale ederse bunu
2:01
kesinlikle istemeyiz. İşte tam burada
2:04
encapsulation yani kapsülleme prensibi
2:06
adeta bir kalkan gibi imdadımıza
2:08
yetişiyor. Sınıfımızın özelliklerini
2:11
private gibi erişim belirleyicilerle
2:13
resmen koruma altına alıyoruz. Dış
2:15
dünyaya kapıları kilitliyor,
2:16
verilerimizi tamamen izole ediyoruz.
2:19
Böylece ufak bir dış müdahalenin bütün
2:21
sistemi çökertmesinin de önüne geçmiş
2:23
oluyoruz. Geldik ikinci bölümümüze.
2:25
Sınıflar arası ilişkiler. Bakalım bu
2:28
yapılar kendi aralarında nasıl
2:29
anlaşıyor. Tabii sınıfları böyle izole
2:32
ettik, kapıları kilitledik ama bu
2:33
sınıfların yalnız yaşaması yetmez.
2:36
Etkileşime girmeleri gerek. Kalıtım yani
2:38
inheritance olayı tıpkı ebeveyinden
2:40
çocuğa geçen genler gibidir. Zaten var
2:43
olan bir sınıfın o güzelim özelliklerini
2:45
alıp yepyeni bir alt sınıfa doğrudan
2:47
aktarırsınız ve kod tekrarını
2:49
bitirirsiniz. Bileşim yani compositionsa
2:52
biraz daha farklı işler. Ebeveyn çocuk
2:54
olmak yerine bir sınıfın özelliklerini
2:56
alıp başka bir sınıfın içinde sanki
2:59
devasa bir makinenin dişlisiymiş gibi
3:01
kullanırsınız. Bazen de bu miras olayına
3:04
bir sınır çekmek istersiniz. İşte o
3:06
zaman sınıfınızı sealed yani mühürlü
3:09
sınıf olarak işaretlersiniz. Bu sisteme
3:12
kocaman kırmızı bir dur tabelası asmak
3:14
gibidir. Mühürlü bir sınıftan asla ve
3:17
asla miras alınamaz. Mesela çok ilginç
3:20
bir bilgi vereyim. C#ARP'ta her gün
3:22
kullandığınız o string sınıfı var ya
3:25
aslında o da mühürlü bir sınıftır.
3:27
Düşünsenize birilerinin string'in o
3:29
temel yapısını değiştirmesini, o sağlam
3:31
yapıyı bozmasını kesinlikle
3:33
istemezsiniz, değil mi? 3üncü
3:35
bölümümüzde devam ediyoruz. Soyutlama ve
3:37
çok biçimlilik. Biliyorsunuz C#ar
3:40
dilinde çoklu kalıtım desteklenmez.
3:43
Kurallar katı bir sınıfın sadece ve
3:46
sadece tek bir ebeveyni olabilir. İyi de
3:49
biz bu katı sınırı nasıl aşacağız? İşte
3:51
burada abstraction yani soyutlama
3:54
devreye giriyor. Birden fazla
3:56
interface'i yani arayüzü sisteme dahil
3:59
ederek yapımızı bir anda inanılmaz
4:01
genişletebiliyoruz.
4:02
Arayüzler ve içi boş bırakılıp sırf
4:05
şablon olsun diye tasarlanan o abstrakt
4:07
yani soyut sınıflar, karmaşık projelerde
4:10
o aradığımız esnekliği ve
4:11
genişletilebilirliği sağlayan asıl sihir
4:14
işte bunlar. İşin en büyüleyici kısmı
4:17
ise çok biçimlilik, namı diğer
4:20
polimorfizm. Şöyle düşünün. Üst sınıftan
4:23
size miras kalan gövdesi standart
4:25
yazılmış virtual bir metot var. Alt
4:27
sınıf bunu alıyor, override kelimesiyle
4:29
ezip tamamen yepyeni, kendine has bir
4:32
davranış sergiliyor. Mesela ebeveyn
4:34
sınıfta çok standart bir nefes al metodu
4:36
olduğunu hayal edin. İnsan alt sınıfı
4:38
bunu alıp akciğer solunumuna çevirirken
4:41
balık sınıfı solugaçlara uyarlıyor.
4:43
İkisi de nefes al diyor ama durumuna
4:45
göre sonsuz farklı biçimde
4:47
çalışabiliyor. Gerçekten muazzam. Bu
4:50
muazzam esneklik burada da bitmiyor.
4:52
Operatör aşırı yükleme sayesinde artı,
4:55
eksi ya da eşittir gibi o en standart
4:58
işaretlerin kendi oluşturduğunuz özel
5:01
nesnelerde tam olarak nasıl
5:02
davranacağını baştan yazabiliyorsunuz.
5:05
Bu sayede o karmaşık matematiksel
5:07
objeleri kodun içinde çok daha sezgisel
5:10
ve rahatça okunabilir hale
5:11
getiriyorsunuz. Soyutlamalar, miraslar,
5:14
şablonlar hepsi mantıksal olarak harika
5:17
tasarımlar. Ama bu noktada çok temel ve
5:19
kritik bir soru sormamız gerekiyor. Peki
5:22
bu nesneler bellekte nerede yaşar?
5:24
Yazdığımız bu güzel kodlar çalıştığında
5:26
fiziksel olarak nereye gidiyor? İşte bu
5:28
sorunun cevabı 4. ve son bölümümüzde
5:31
gizli C#ARP bellek yönetimi. Hadi şimdi
5:34
biraz kaputun altına girelim. Belleğimiz
5:36
çalışma mantığı açısından temelde ikiye
5:38
ayrılıyor. Bir yanda stack yani yığın
5:42
var. Bu kısım int veya float gibi o
5:45
basit değer tiplerini tutuyor ve
5:47
doğrudan veriye ulaştığı için akıl almaz
5:49
derecede hızlı. Diğer yanda ise hep yani
5:53
öbek var. Burası referans tiplerinin
5:55
yuvası. Mesela o devasa string verisi
5:59
hep'te kocaman bir yer kaplarken
6:01
stack'te sadece o verinin hep'teki
6:03
konumuna işaret eden ufacık bir adres,
6:06
bir referans noktası tutuluyor. Peki
6:08
diyelim ki bir metoda bir değişkenin
6:10
sadece kopyasını değil de bellekteki o
6:13
orijinal ev adresini doğrudan göndermek
6:15
istedik. Ne yapacağız? İşte o a sahnede
6:18
ref ve out anahtar kelimeleri beliriyor.
6:20
Bu kelimeleri kullanarak metoda verinin
6:23
değerini değil bizzat adresini
6:24
veriyorsunuz. Dolayısıyla metot
6:26
içerisinde yaptığınız değişiklikler
6:28
orijinal veriyi doğrudan ve kalıcı
6:30
olarak etkilemiş oluyor. Konumuzu yavaş
6:32
yavaş toparlarken tüm bu yüzlerce
6:34
sınıfı, arayüzü ve bellek adreslerini
6:37
devasa projelerde nasıl yöneteceğiz?
6:40
İsim alanları yani nampaces ile. Bunlar
6:43
bizim tüm sınıflarımızı mantıksal olarak
6:46
gruplayan devasa konteynerlar. Bir
6:48
projenin içinde aynı isimde iki farklı
6:50
sınıf olmasını engelleyen o kod kaosunu
6:53
düzenleyip sınırları net bir şekilde
6:55
çizen görünmez kahramanlar. Ve işte
6:57
böylece temelden başladık. Belleğin
6:59
derinliklerine kadar tam bir tur yaptık.
7:02
Videoda incelediğimiz bu dersin ve yıla
7:04
ait çıkmış soruları kendiniz deneme
7:06
sınavı formatında çözmek, eksiklerinizi
7:08
kapatmak ve kendinizi detaylıca test
7:11
etmek için lolo.nolo.com
7:13
adresini ziyaret edebilir, videonun
7:15
altındaki açıklama kısmında yer alan
7:16
bağlantıya tıklayabilirsiniz. Unutmayın,
7:19
yapay zekanın bile saniyeler içinde kod
7:21
yazdığı bu çağda bu mimariyi
7:23
derinlemesini anlamak, sizi o sıradan
7:25
bir kod yazıcı olmaktan çıkarıp gerçek
7:27
bir yazılım mimari yapacak yegane
7:29
güçtür. Kendi sisteminizin mimarı olmaya
7:32
hazır mısınız? Yaklaşan finallerinizde
7:34
hepinize bol şans ve başarılar dilerim.
Jobs & Education