Yaz\u0131l\u0131m geli\u015ftirme d\u00fcnyas\u0131nda Nesne Y\u00f6nelimli Programlama (OOP), modern uygulamalar\u0131n temelini olu\u015fturan, en yayg\u0131n ve g\u00fc\u00e7l\u00fc paradigmalar\u0131ndan biridir. Bir\u00e7ok pop\u00fcler programlama dili (Java, C#, Python, C++, PHP, Ruby vb.) OOP prensiplerini benimser. Bu nedenle, bir yaz\u0131l\u0131m m\u00fchendisi veya geli\u015ftirici aday\u0131 olarak, OOP kavramlar\u0131na hakim olmak, m\u00fclakatlarda ba\u015far\u0131l\u0131 olman\u0131n ve kariyerinizde ilerlemenin anahtar\u0131d\u0131r. OOP, karma\u015f\u0131k sistemleri y\u00f6netilebilir, esnek ve yeniden kullan\u0131labilir par\u00e7alara ay\u0131rarak geli\u015ftirme s\u00fcrecini kolayla\u015ft\u0131r\u0131r. Bu makale, OOP ile ilgili m\u00fclakatlarda s\u0131k\u00e7a sorulan sorular\u0131 ve bu sorulara verilebilecek detayl\u0131, a\u00e7\u0131klay\u0131c\u0131 yan\u0131tlar\u0131 derinlemesine inceleyecektir. Amac\u0131m\u0131z, sadece tan\u0131mlar\u0131 ezberlemek yerine, her bir kavram\u0131n alt\u0131nda yatan mant\u0131\u011f\u0131, faydalar\u0131n\u0131 ve ger\u00e7ek d\u00fcnya uygulamalar\u0131n\u0131 anlaman\u0131za yard\u0131mc\u0131 olmakt\u0131r.<\/p>\n
OOP’nin derinliklerine dalmadan \u00f6nce, temel yap\u0131 ta\u015flar\u0131n\u0131 net bir \u015fekilde anlamak \u00f6nemlidir. M\u00fclakatlarda genellikle ilk olarak bu temel tan\u0131mlar sorgulan\u0131r.<\/p>\n
Nesne Y\u00f6nelimli Programlama (OOP), programlar\u0131 “nesneler” etraf\u0131nda d\u00fczenleyen bir programlama paradigmas\u0131d\u0131r. Bu yakla\u015f\u0131m, ger\u00e7ek d\u00fcnyadaki varl\u0131klar\u0131 (\u00f6rne\u011fin, bir araba, bir insan, bir banka hesab\u0131) yaz\u0131l\u0131m i\u00e7inde nesneler olarak modellemeyi hedefler. Her nesne, kendi verilerine (niteliklerine veya \u00f6zelliklerine) ve bu veriler \u00fczerinde i\u015flem yapabilen i\u015flevlere (metotlar\u0131na veya davran\u0131\u015flar\u0131na) sahiptir. OOP’nin temel amac\u0131, kodun okunabilirli\u011fini, bak\u0131m\u0131n\u0131, esnekli\u011fini ve yeniden kullan\u0131labilirli\u011fini art\u0131rarak karma\u015f\u0131k sistemlerin geli\u015ftirilmesini kolayla\u015ft\u0131rmakt\u0131r. Geleneksel prosed\u00fcrel programlaman\u0131n aksine, veriler ve bu verileri i\u015fleyen fonksiyonlar ayr\u0131 tutulmak yerine, tek bir birim (nesne) i\u00e7inde bir araya getirilir. Bu entegrasyon, program\u0131n yap\u0131s\u0131n\u0131 daha mod\u00fcler ve anla\u015f\u0131l\u0131r hale getirir.<\/p>\n
Bir nesne, bir s\u0131n\u0131f\u0131n (class) somut bir \u00f6rne\u011fidir. Ger\u00e7ek d\u00fcnyadaki bir varl\u0131\u011f\u0131 veya kavram\u0131 temsil eder. \u00d6rne\u011fin, bir “Araba” s\u0131n\u0131f\u0131n\u0131z varsa, “Ford Fiesta” veya “BMW X5” birer araba nesnesidir. Her nesnenin kendine \u00f6zg\u00fc bir durumu (state) ve davran\u0131\u015f\u0131 (behavior) vard\u0131r. Bir s\u0131n\u0131f, nesnelerin nas\u0131l olu\u015fturulaca\u011f\u0131n\u0131 tan\u0131mlayan bir \u015fablondur veya plan (blueprint) gibidir. Nesnelerin sahip olaca\u011f\u0131 ortak \u00f6zellikleri (veri \u00fcyeleri\/de\u011fi\u015fkenler) ve davran\u0131\u015flar\u0131 (metotlar) belirler. Bir s\u0131n\u0131f\u0131n kendisi bir veri de\u011fildir; bir veri tipidir. Bir s\u0131n\u0131f tan\u0131mlad\u0131\u011f\u0131n\u0131zda, hen\u00fcz bellekte bir yer kaplamaz veya somut bir varl\u0131k olu\u015fturmazs\u0131n\u0131z. Sadece, bu s\u0131n\u0131ftan olu\u015fturulacak nesnelerin hangi \u00f6zelliklere sahip olaca\u011f\u0131n\u0131 ve hangi i\u015flemleri yapabilece\u011fini belirtmi\u015f olursunuz. \u00d6rne\u011fin, “Araba” s\u0131n\u0131f\u0131, t\u00fcm arabalar\u0131n ortak \u00f6zellikleri olan “marka”, “model”, “renk” ve ortak davran\u0131\u015flar\u0131 olan “h\u0131zlan”, “fren yap” gibi metotlar\u0131 tan\u0131mlar. Bu s\u0131n\u0131ftan istedi\u011finiz kadar araba nesnesi (\u00f6rne\u011fin, OOP’nin g\u00fcc\u00fc ve esnekli\u011fi, d\u00f6rt temel prensibe dayan\u0131r: Kaps\u00fclleme (Encapsulation), Kal\u0131t\u0131m (Inheritance), \u00c7ok Bi\u00e7imlilik (Polymorphism) ve Soyutlama (Abstraction). M\u00fclakatlarda bu d\u00f6rt prensip, genellikle en \u00e7ok sorgulanan ve derinlemesine a\u00e7\u0131klanmas\u0131 beklenen konulard\u0131r.<\/p>\n Kaps\u00fclleme, bir nesnenin verilerini (\u00f6zelliklerini) ve bu veriler \u00fczerinde i\u015flem yapan metotlar\u0131n\u0131 tek bir birim (s\u0131n\u0131f) i\u00e7inde bir araya getirme ve d\u0131\u015f d\u00fcnyadan gizleme prensibidir. Bu, bir s\u0131n\u0131f\u0131n i\u00e7 \u00e7al\u0131\u015fma detaylar\u0131n\u0131n d\u0131\u015far\u0131ya a\u00e7\u0131lmamas\u0131n\u0131, b\u00f6ylece d\u0131\u015far\u0131dan do\u011frudan eri\u015fimin engellenmesini ve verilerin yanl\u0131\u015fl\u0131kla de\u011fi\u015ftirilmesini \u00f6nlemeyi sa\u011flar. Kaps\u00fclleme genellikle eri\u015fim belirleyiciler (public, private, protected) ve getter\/setter metotlar\u0131 (eri\u015fimci\/de\u011fi\u015ftirici metotlar) kullan\u0131larak uygulan\u0131r.<\/p>\n * Veri Gizleme (Information Hiding):<\/strong> S\u0131n\u0131f\u0131n i\u00e7indeki verilerin do\u011frudan d\u0131\u015far\u0131dan eri\u015filemez hale getirilmesi anlam\u0131na gelir. Veriler genellikle Neden \u00d6nemlidir?<\/strong> \u00d6rnek:<\/strong> Bir Kal\u0131t\u0131m, bir s\u0131n\u0131f\u0131n (alt s\u0131n\u0131f veya t\u00fcretilmi\u015f s\u0131n\u0131f) ba\u015fka bir s\u0131n\u0131f\u0131n (\u00fcst s\u0131n\u0131f veya temel s\u0131n\u0131f) \u00f6zelliklerini (veri \u00fcyelerini) ve davran\u0131\u015flar\u0131n\u0131 (metotlar\u0131n\u0131) miras almas\u0131 prensibidir. Bu, “bir … d\u0131r” (is-a) ili\u015fkisini ifade eder. \u00d6rne\u011fin, “Araba bir Ara\u00e7t\u0131r”, “K\u00f6pek bir Hayvand\u0131r”. Kal\u0131t\u0131m, kodun yeniden kullan\u0131labilirli\u011fini art\u0131r\u0131r ve hiyerar\u015fik bir yap\u0131 olu\u015fturarak kodun organizasyonunu iyile\u015ftirir.<\/p>\n * \u00dcst S\u0131n\u0131f (Parent\/Base\/Super Class):<\/strong> \u00d6zellikleri ve davran\u0131\u015flar\u0131 miras veren s\u0131n\u0131ft\u0131r. Ne Ama\u00e7la Kullan\u0131l\u0131r?<\/strong> K\u0131s\u0131tlamalar\/Dezavantajlar:<\/strong> \u00c7ok bi\u00e7imlilik, “bir\u00e7ok \u015fekil” anlam\u0131na gelir ve farkl\u0131 s\u0131n\u0131flardan gelen nesnelerin ayn\u0131 aray\u00fcz \u00fczerinden farkl\u0131 \u015fekillerde davranabilme yetene\u011fidir. Ba\u015fka bir deyi\u015fle, ayn\u0131 metot \u00e7a\u011fr\u0131s\u0131n\u0131n, \u00e7a\u011fr\u0131ld\u0131\u011f\u0131 nesnenin tipine g\u00f6re farkl\u0131 davran\u0131\u015flar sergilemesidir. Bu, kodun daha esnek, geni\u015fletilebilir ve mod\u00fcler olmas\u0131n\u0131 sa\u011flar.<\/p>\n \u00c7ok bi\u00e7imlilik genellikle iki ana \u015fekilde ortaya \u00e7\u0131kar: Nas\u0131l Uygulan\u0131r?<\/strong> Neden \u00d6nemlidir?<\/strong> \u00d6rnek:<\/strong> Bir Soyutlama, karma\u015f\u0131kl\u0131\u011f\u0131 y\u00f6netmek i\u00e7in gerekli olan bilgileri g\u00f6sterme ve gereksiz detaylar\u0131 gizleme prensibidir. Bir nesnenin d\u0131\u015f d\u00fcnyaya sadece \u00f6nemli \u00f6zelliklerini ve davran\u0131\u015flar\u0131n\u0131 sunarak, i\u00e7 \u00e7al\u0131\u015fma mekanizmalar\u0131n\u0131 gizlemesidir. Kullan\u0131c\u0131n\u0131n bir \u015feyin nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 bilmesine gerek kalmadan onu kullanmas\u0131n\u0131 sa\u011flar. Soyutlama, genellikle soyut s\u0131n\u0131flar (abstract classes) ve aray\u00fczler (interfaces) arac\u0131l\u0131\u011f\u0131yla uygulan\u0131r.<\/p>\n * Odaklanma:<\/strong> Kullan\u0131c\u0131n\u0131n veya ba\u015fka bir geli\u015ftiricinin, sadece bir nesnenin ne yapt\u0131\u011f\u0131n\u0131 bilmesi yeterlidir, nas\u0131l yapt\u0131\u011f\u0131n\u0131 bilmesine gerek yoktur. Nas\u0131l Uygulan\u0131r?<\/strong> Neden Kullan\u0131l\u0131r?<\/strong> \u00d6rnek:<\/strong> Bir OOP sadece d\u00f6rt prensiple s\u0131n\u0131rl\u0131 de\u011fildir. M\u00fclakatlarda bu temel prensiplerin yan\u0131 s\u0131ra, daha ileri seviye kavramlar ve pratik uygulamalar da sorgulanabilir.<\/p>\n Bu, m\u00fclakatlarda en s\u0131k sorulan sorulardan biridir ve OOP bilgisinin derinli\u011fini \u00f6l\u00e7mek i\u00e7in kullan\u0131l\u0131r.<\/p>\n | \u00d6zellik | Soyut S\u0131n\u0131f (Abstract Class) | Aray\u00fcz (Interface) | Bu, iyi bir OOP tasar\u0131mc\u0131s\u0131 olman\u0131n \u00f6nemli bir g\u00f6stergesidir. “Favor composition over inheritance” (kal\u0131t\u0131m yerine kompozisyonu tercih et) prensibi, sa\u011flam ve esnek yaz\u0131l\u0131m tasar\u0131mlar\u0131 i\u00e7in yayg\u0131n olarak kabul g\u00f6rm\u00fc\u015f bir yakla\u015f\u0131md\u0131r.<\/p>\n * Kal\u0131t\u0131m (Inheritance):<\/strong> “is-a” (bir … d\u0131r) ili\u015fkisini ifade eder. \u00d6rne\u011fin, Kompozisyon Ne Zaman Tercih Edilmelidir?<\/strong> \u00d6zetle, genel kural \u015fudur: E\u011fer iki s\u0131n\u0131f aras\u0131nda g\u00fc\u00e7l\u00fc bir “is-a” ili\u015fkisi varsa (\u00f6rne\u011fin, SOLID, Nesne Y\u00f6nelimli Tasar\u0131mda (OOD) daha anla\u015f\u0131l\u0131r, esnek ve bak\u0131m\u0131 kolay sistemler olu\u015fturmak i\u00e7in kullan\u0131lan be\u015f temel prensibin k\u0131saltmas\u0131d\u0131r. Bu prensipler, Robert C. Martin (Uncle Bob) taraf\u0131ndan pop\u00fclerle\u015ftirilmi\u015ftir.<\/p>\n 1. S – Single Responsibility Principle (Tek Sorumluluk Prensibi):<\/strong> Bir s\u0131n\u0131f\u0131n veya mod\u00fcl\u00fcn yaln\u0131zca bir sorumlulu\u011fu olmal\u0131d\u0131r. Yani, bir s\u0131n\u0131f\u0131n de\u011fi\u015fmesi i\u00e7in yaln\u0131zca tek bir nedeni olmal\u0131d\u0131r. Bu, kodun daha mod\u00fcler ve hataya daha az e\u011filimli olmas\u0131n\u0131 sa\u011flar. Neden \u00d6nemlidir?<\/strong> Tasar\u0131m desenleri, yaz\u0131l\u0131m geli\u015ftirmede s\u0131k kar\u015f\u0131la\u015f\u0131lan problemlere kan\u0131tlanm\u0131\u015f, genel ve yeniden kullan\u0131labilir \u00e7\u00f6z\u00fcmlerdir. Bunlar, belirli bir programlama diline veya platforma \u00f6zg\u00fc de\u011fildir; daha ziyade, belirli bir ba\u011flamda nas\u0131l tasar\u0131m yap\u0131lmas\u0131 gerekti\u011fine dair soyut \u015fablonlard\u0131r. “Gang of Four” (GoF) taraf\u0131ndan yaz\u0131lan “Design Patterns: Elements of Reusable Object-Oriented Software” kitab\u0131, 23 temel tasar\u0131m desenini s\u0131n\u0131fland\u0131rm\u0131\u015ft\u0131r.<\/p>\n Tasar\u0131m Desenlerinin Kategorileri:<\/strong> Neden Kullan\u0131l\u0131r?<\/strong> M\u00fclakatlarda genellikle adaylardan belirli bir deseni a\u00e7\u0131klamalar\u0131 veya bir senaryoya uygun bir desen \u00f6nermeleri istenir (\u00f6rne\u011fin, “Bir s\u0131n\u0131f\u0131n sadece bir \u00f6rne\u011finin olmas\u0131n\u0131 nas\u0131l sa\u011flars\u0131n\u0131z?” cevab\u0131 Singleton deseni olacakt\u0131r).<\/p>\n Bu b\u00f6l\u00fcmde, OOP prensiplerinin yan\u0131 s\u0131ra, genel olarak nesne y\u00f6nelimli d\u00fc\u015f\u00fcnme bi\u00e7imi ve pratik uygulamalarla ilgili sorulara odaklanaca\u011f\u0131z.<\/p>\n Avantajlar\u0131:<\/strong> Dezavantajlar\u0131:<\/strong> Bu kavram, \u00f6zellikle C++ ve C# gibi dillerde polimorfizmin \u00e7al\u0131\u015fma zaman\u0131nda nas\u0131l sa\u011fland\u0131\u011f\u0131n\u0131 anlamak i\u00e7in \u00f6nemlidir.<\/p>\n * Sanal Metot (Virtual Method):<\/strong> Bir \u00fcst s\u0131n\u0131fta Neden \u00d6nemlidir?<\/strong> * Statik De\u011fi\u015fkenler (Static Variables \/ Class Variables):<\/strong> Bir s\u0131n\u0131fa ait tek bir kopyas\u0131 vard\u0131r ve t\u00fcm nesneler taraf\u0131ndan payla\u015f\u0131l\u0131r. Bir nesne olu\u015fturulsa da olu\u015fturulmasa da var olurlar. Genellikle t\u00fcm nesneler i\u00e7in ortak olan verileri (\u00f6rne\u011fin, bir nesne sayac\u0131) saklamak i\u00e7in kullan\u0131l\u0131r. Neden Kullan\u0131l\u0131r?<\/strong> OOP Ba\u011flam\u0131ndaki Anlam\u0131:<\/strong> Statik \u00fcyeler, OOP’nin nesne tabanl\u0131 do\u011fas\u0131ndan biraz farkl\u0131d\u0131r. Onlar daha \u00e7ok “s\u0131n\u0131f\u0131n” kendisiyle ili\u015fkilidir, belirli bir “nesne” ile de\u011fil. Bu nedenle, a\u015f\u0131r\u0131 statik kullan\u0131m, nesne y\u00f6nelimli tasar\u0131m\u0131n esnekli\u011fini ve test edilebilirli\u011fini azaltabilir. Singleton deseni gibi baz\u0131 tasar\u0131m desenleri statik \u00fcyeleri kullan\u0131r.<\/p>\n Nesne Y\u00f6nelimli Programlama (OOP), modern yaz\u0131l\u0131m geli\u015ftirmenin temel ta\u015f\u0131d\u0131r ve bu prensiplere hakim olmak, her yaz\u0131l\u0131m profesyoneli i\u00e7in vazge\u00e7ilmezdir. M\u00fclakatlarda bu kavramlar\u0131n sadece tan\u0131mlar\u0131n\u0131 bilmek yeterli de\u011fildir; alt\u0131nda yatan mant\u0131\u011f\u0131, ne zaman ve neden kullan\u0131ld\u0131klar\u0131n\u0131, avantajlar\u0131n\u0131 ve dezavantajlar\u0131n\u0131 derinlemesine anlamak beklenir. Kaps\u00fclleme, Kal\u0131t\u0131m, \u00c7ok Bi\u00e7imlilik ve Soyutlama gibi temel prensiplerin yan\u0131 s\u0131ra, SOLID prensipleri ve tasar\u0131m desenleri gibi daha ileri konular da, iyi bir OOP tasar\u0131mc\u0131s\u0131 olman\u0131n g\u00f6stergeleridir.<\/p>\n Bu makalede ele al\u0131nan sorular ve detayl\u0131 yan\u0131tlar, OOP m\u00fclakatlar\u0131na haz\u0131rlan\u0131rken size sa\u011flam bir temel sunmay\u0131 ama\u00e7lamaktad\u0131r. Ancak unutmay\u0131n ki teorik bilginin yan\u0131 s\u0131ra pratik deneyim de \u00e7ok \u00f6nemlidir. Farkl\u0131 projelerde OOP prensiplerini uygulayarak, kod yazarak ve mevcut kodlar\u0131 analiz ederek bilginizi peki\u015ftirin. S\u00fcrekli \u00f6\u011frenme ve pratik yapma, OOP ustal\u0131\u011f\u0131na giden yolda size rehberlik edecektir. Ba\u015far\u0131l\u0131 bir m\u00fclakat s\u00fcreci ve parlak bir yaz\u0131l\u0131m kariyeri dileriz!<\/p>\n <\/body><\/p>\n","protected":false},"excerpt":{"rendered":"Nesne Y\u00f6nelimli Programlama (OOP) M\u00fclakat Sorular\u0131 ve Detayl\u0131 Yan\u0131tlar\u0131\nGiri\u015f: Neden Nesne Y\u00f6nelimli Programlama (OOP)?\nYaz\u0131l\u0131m geli\u015fti","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1],"tags":[],"class_list":{"0":"post-36659","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-genel","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\n
\n* Durum (State):<\/strong> Nesnenin \u00f6zelliklerini veya niteliklerini tan\u0131mlayan verilerdir. \u00d6rne\u011fin, bir araba nesnesinin rengi, markas\u0131, modeli gibi \u00f6zellikleri durumu olu\u015fturur. Bunlar genellikle s\u0131n\u0131f i\u00e7inde de\u011fi\u015fkenler (fields veya attributes) olarak tan\u0131mlan\u0131r.
\n* Davran\u0131\u015f (Behavior):<\/strong> Nesnenin yapabilece\u011fi eylemler veya di\u011fer nesnelerle nas\u0131l etkile\u015fim kurdu\u011funu tan\u0131mlayan i\u015flevlerdir. \u00d6rne\u011fin, bir araba nesnesinin h\u0131zlanmas\u0131, fren yapmas\u0131, vites de\u011fi\u015ftirmesi gibi eylemler davran\u0131\u015flar\u0131 olu\u015fturur. Bunlar genellikle s\u0131n\u0131f i\u00e7inde metotlar (methods) olarak tan\u0131mlan\u0131r.
\nNesneler, birbirleriyle mesajlar g\u00f6ndererek ileti\u015fim kurarlar ve bu sayede karma\u015f\u0131k sistemler olu\u015fturulabilir.<\/p>\nS\u0131n\u0131f (Class) Nedir?<\/h3>\n
araba1 = new Araba(\"Ford\", \"Fiesta\", \"Mavi\")<\/code>) olu\u015fturabilirsiniz. Her olu\u015fturulan nesne, s\u0131n\u0131f\u0131n tan\u0131mlad\u0131\u011f\u0131 yap\u0131ya uygun olacakt\u0131r, ancak kendi benzersiz veri de\u011ferlerine sahip olacakt\u0131r.<\/p>\nOOP’nin D\u00f6rt Temel Prensibi<\/h2>\n
1. Kaps\u00fclleme (Encapsulation) Nedir ve Neden \u00d6nemlidir?<\/h3>\n
private<\/code> olarak tan\u0131mlan\u0131r.
\n* Arabirim Sa\u011flama:<\/strong> Bu verilere eri\u015fim ve de\u011fi\u015ftirme, public<\/code> olarak tan\u0131mlanm\u0131\u015f metotlar (getter\/setter) arac\u0131l\u0131\u011f\u0131yla yap\u0131l\u0131r. Bu metotlar, veriye eri\u015fim veya de\u011fi\u015fiklik \u00f6ncesinde do\u011frulama veya ek i\u015flemler yap\u0131lmas\u0131na olanak tan\u0131r.<\/p>\n
\n* Veri B\u00fct\u00fcnl\u00fc\u011f\u00fc:<\/strong> Kaps\u00fclleme, nesnenin i\u00e7 durumunun tutarl\u0131 kalmas\u0131n\u0131 sa\u011flar. Setter metotlar\u0131 arac\u0131l\u0131\u011f\u0131yla veri giri\u015fi kontrol edilebilir ve ge\u00e7ersiz de\u011ferlerin atanmas\u0131 engellenebilir.
\n* Mod\u00fclerlik:<\/strong> Her nesne kendi sorumlulu\u011funu \u00fcstlenir ve i\u00e7 detaylar\u0131n\u0131 d\u0131\u015f d\u00fcnyadan gizler. Bu, kodun daha mod\u00fcler olmas\u0131n\u0131 sa\u011flar.
\n* Esneklik ve Bak\u0131m Kolayl\u0131\u011f\u0131:<\/strong> Bir s\u0131n\u0131f\u0131n i\u00e7 yap\u0131s\u0131n\u0131 de\u011fi\u015ftirdi\u011finizde (\u00f6rne\u011fin, bir de\u011fi\u015fkenin ad\u0131n\u0131 veya veri tipini de\u011fi\u015ftirdi\u011finizde), d\u0131\u015far\u0131daki kodu etkilemeden bu de\u011fi\u015fiklikleri yapabilirsiniz, yeter ki public aray\u00fcz (getter\/setter metotlar\u0131) ayn\u0131 kals\u0131n. Bu, kodun bak\u0131m\u0131n\u0131 ve geli\u015ftirilmesini \u00e7ok daha kolay hale getirir.
\n* G\u00fcvenlik:<\/strong> Hassas verilere yetkisiz eri\u015fimi veya manip\u00fclasyonu \u00f6nler.<\/p>\nHesap<\/code> s\u0131n\u0131f\u0131nda bakiye<\/code> de\u011fi\u015fkeninin private<\/code> olmas\u0131 ve sadece paraYatir()<\/code> veya paraCek()<\/code> gibi metotlar arac\u0131l\u0131\u011f\u0131yla de\u011fi\u015ftirilebilmesi kaps\u00fcllemeye bir \u00f6rnektir. Bu sayede, bakiyenin negatif olmas\u0131n\u0131 veya ge\u00e7ersiz bir i\u015flem yap\u0131lmas\u0131n\u0131 engelleyebilirsiniz.<\/p>\n2. Kal\u0131t\u0131m (Inheritance) Nedir ve Ne Ama\u00e7la Kullan\u0131l\u0131r?<\/h3>\n
\n* Alt S\u0131n\u0131f (Child\/Derived\/Sub Class):<\/strong> \u00d6zellikleri ve davran\u0131\u015flar\u0131 miras alan s\u0131n\u0131ft\u0131r. Alt s\u0131n\u0131f, \u00fcst s\u0131n\u0131f\u0131n t\u00fcm public<\/code> ve protected<\/code> \u00fcyelerine eri\u015febilir. Ayr\u0131ca kendi benzersiz \u00f6zelliklerini ve metotlar\u0131n\u0131 da ekleyebilir veya \u00fcst s\u0131n\u0131ftan miras ald\u0131\u011f\u0131 metotlar\u0131 ge\u00e7ersiz k\u0131labilir (override).<\/p>\n
\n* Kod Tekrar\u0131n\u0131 Azaltma:<\/strong> Ortak \u00f6zellikler ve metotlar bir \u00fcst s\u0131n\u0131fta tan\u0131mlan\u0131r ve birden fazla alt s\u0131n\u0131f taraf\u0131ndan yeniden kullan\u0131l\u0131r. Bu, kod tekrar\u0131n\u0131 \u00f6nler ve daha temiz bir kod taban\u0131 sa\u011flar.
\n* Hiyerar\u015fi Olu\u015fturma:<\/strong> Ger\u00e7ek d\u00fcnyadaki varl\u0131klar aras\u0131ndaki “is-a” ili\u015fkilerini modellemek i\u00e7in do\u011fal bir yol sunar. \u00d6rne\u011fin, Hayvan<\/code> s\u0131n\u0131f\u0131ndan K\u00f6pek<\/code>, Kedi<\/code> s\u0131n\u0131flar\u0131n\u0131 t\u00fcretebiliriz.
\n* Geni\u015fletilebilirlik:<\/strong> Mevcut bir s\u0131n\u0131f\u0131n davran\u0131\u015f\u0131n\u0131 de\u011fi\u015ftirmeden veya ona dokunmadan yeni i\u015flevsellikler eklemeyi sa\u011flar.
\n* Polimorfizm \u0130\u00e7in Temel:<\/strong> Kal\u0131t\u0131m, polimorfizmin uygulanabilmesi i\u00e7in gerekli bir \u00f6n ko\u015fuldur.<\/p>\n
\n* S\u0131k\u0131 Ba\u011fl\u0131l\u0131k (Tight Coupling):<\/strong> Alt s\u0131n\u0131f, \u00fcst s\u0131n\u0131fa s\u0131k\u0131ca ba\u011fl\u0131d\u0131r. \u00dcst s\u0131n\u0131fta yap\u0131lan de\u011fi\u015fiklikler alt s\u0131n\u0131flar\u0131 etkileyebilir.
\n* Tasar\u0131m Karma\u015f\u0131kl\u0131\u011f\u0131:<\/strong> Derin kal\u0131t\u0131m hiyerar\u015fileri bazen anla\u015f\u0131lmas\u0131 ve y\u00f6netilmesi zor olabilir.
\n* “Elmas Problemi” (Diamond Problem):<\/strong> Baz\u0131 dillerde (C++ gibi), birden fazla kal\u0131t\u0131m kullan\u0131ld\u0131\u011f\u0131nda ortaya \u00e7\u0131kan bir problemdir. Bir s\u0131n\u0131f iki farkl\u0131 \u00fcst s\u0131n\u0131ftan miras ald\u0131\u011f\u0131nda ve bu \u00fcst s\u0131n\u0131flar\u0131n ortak bir \u00fcst s\u0131n\u0131f\u0131 oldu\u011funda, hangi miras al\u0131nan metodun kullan\u0131laca\u011f\u0131 belirsizle\u015febilir. Java gibi dillerde bu, tekli kal\u0131t\u0131m (bir s\u0131n\u0131f sadece bir s\u0131n\u0131ftan miras alabilir) ve aray\u00fczler (interfaces) kullan\u0131larak \u00e7\u00f6z\u00fclm\u00fc\u015ft\u00fcr.<\/p>\n3. \u00c7ok Bi\u00e7imlilik (Polymorphism) Nedir ve Nas\u0131l Uygulan\u0131r?<\/h3>\n
\n* Derleme Zaman\u0131 Polimorfizmi (Compile-time Polymorphism \/ Metot A\u015f\u0131r\u0131 Y\u00fckleme – Method Overloading):<\/strong> Ayn\u0131 s\u0131n\u0131f i\u00e7inde veya kal\u0131t\u0131m ili\u015fkisi olmayan s\u0131n\u0131flarda, ayn\u0131 ada sahip ancak farkl\u0131 parametre listelerine (farkl\u0131 say\u0131da parametre, farkl\u0131 tipte parametreler veya parametrelerin farkl\u0131 s\u0131ras\u0131) sahip birden fazla metot tan\u0131mlanmas\u0131d\u0131r. Derleyici, hangi metodun \u00e7a\u011fr\u0131laca\u011f\u0131n\u0131 parametre listesine bakarak derleme zaman\u0131nda belirler.
\n* \u00c7al\u0131\u015fma Zaman\u0131 Polimorfizmi (Runtime Polymorphism \/ Metot Ge\u00e7ersiz K\u0131lma – Method Overriding):<\/strong> \u00dcst s\u0131n\u0131fta tan\u0131mlanm\u0131\u015f bir metodun, alt s\u0131n\u0131f taraf\u0131ndan kendi \u00f6zel implementasyonu ile yeniden tan\u0131mlanmas\u0131d\u0131r. Bir \u00fcst s\u0131n\u0131f referans de\u011fi\u015fkeni, bir alt s\u0131n\u0131f nesnesini i\u015faret etti\u011finde ve bu metot \u00e7a\u011fr\u0131ld\u0131\u011f\u0131nda, \u00e7al\u0131\u015fma zaman\u0131nda nesnenin ger\u00e7ek tipine g\u00f6re alt s\u0131n\u0131ftaki metot \u00e7a\u011fr\u0131l\u0131r. Bu, genellikle kal\u0131t\u0131m ve soyut s\u0131n\u0131flar\/aray\u00fczler ile birlikte kullan\u0131l\u0131r.<\/p>\n
\n* Metot A\u015f\u0131r\u0131 Y\u00fckleme (Overloading):<\/strong> Ayn\u0131 s\u0131n\u0131fta farkl\u0131 imzalarla metotlar tan\u0131mlayarak.
\n* Metot Ge\u00e7ersiz K\u0131lma (Overriding):<\/strong> \u00dcst s\u0131n\u0131ftaki bir metodu alt s\u0131n\u0131fta virtual<\/code> (C#) veya sadece ayn\u0131 imza ile (Java) tan\u0131mlayarak yeniden implemente etmek. \u00dcst s\u0131n\u0131f referans\u0131yla alt s\u0131n\u0131f nesnesine eri\u015fim sa\u011fland\u0131\u011f\u0131nda, alt s\u0131n\u0131f\u0131n override etti\u011fi metot \u00e7al\u0131\u015f\u0131r.<\/p>\n
\n* Esneklik:<\/strong> Yeni alt s\u0131n\u0131flar ekleyerek mevcut kodu de\u011fi\u015ftirmeden yeni davran\u0131\u015flar tan\u0131mlayabilirsiniz.
\n* Geni\u015fletilebilirlik:<\/strong> Sisteme yeni t\u00fcrler eklemek kolayla\u015f\u0131r, \u00e7\u00fcnk\u00fc mevcut kod bu yeni t\u00fcrleri genel bir aray\u00fcz \u00fczerinden i\u015fleyebilir.
\n* Okunabilirlik ve Bak\u0131m:<\/strong> Daha genel kod yaz\u0131lmas\u0131n\u0131 sa\u011flar. \u00d6rne\u011fin, bir Hayvan<\/code> dizisi \u00fczerinde d\u00f6ng\u00fc yap\u0131p her hayvan\u0131n sesCikar()<\/code> metodunu \u00e7a\u011f\u0131rd\u0131\u011f\u0131n\u0131zda, her hayvan t\u00fcr\u00fc kendi \u00f6zel sesini \u00e7\u0131kar\u0131r. Bu, her hayvan t\u00fcr\u00fc i\u00e7in ayr\u0131 ayr\u0131 kod yazmaktan daha temizdir.<\/p>\nSekil<\/code> s\u0131n\u0131f\u0131 ve ondan t\u00fcremi\u015f Daire<\/code>, Kare<\/code> s\u0131n\u0131flar\u0131 olsun. Sekil<\/code> s\u0131n\u0131f\u0131nda alanHesapla()<\/code> metodu tan\u0131mlan\u0131r. Daire<\/code> ve Kare<\/code> s\u0131n\u0131flar\u0131 bu metodu kendi \u015fekillerine \u00f6zel alan hesaplamalar\u0131yla ge\u00e7ersiz k\u0131lar. Bir Sekil<\/code> referans\u0131na Daire<\/code> veya Kare<\/code> nesnesi atay\u0131p alanHesapla()<\/code> metodunu \u00e7a\u011f\u0131rd\u0131\u011f\u0131n\u0131zda, \u00e7al\u0131\u015fma zaman\u0131nda do\u011fru hesaplama yap\u0131l\u0131r.<\/p>\n4. Soyutlama (Abstraction) Nedir ve Neden Kullan\u0131l\u0131r?<\/h3>\n
\n* Basitlik:<\/strong> Karma\u015f\u0131k sistemleri daha basit ve anla\u015f\u0131l\u0131r hale getirir.
\n* De\u011fi\u015fkenli\u011fi Y\u00f6netme:<\/strong> \u0130\u00e7 implementasyon detaylar\u0131 gizlendi\u011fi i\u00e7in, bu detaylar de\u011fi\u015fti\u011finde d\u0131\u015far\u0131daki kodu etkilemez.<\/p>\n
\n* Soyut S\u0131n\u0131flar (Abstract Classes):<\/strong> En az bir soyut metot i\u00e7eren s\u0131n\u0131flard\u0131r (yani, g\u00f6vdesi olmayan metotlar). Soyut s\u0131n\u0131flardan do\u011frudan nesne olu\u015fturulamaz; mutlaka alt s\u0131n\u0131flar taraf\u0131ndan miras al\u0131nmal\u0131 ve soyut metotlar\u0131 implemente edilmelidir. Ortak davran\u0131\u015flar\u0131 ve \u00f6zellikleri tan\u0131mlamak i\u00e7in kullan\u0131l\u0131rlar, ancak baz\u0131 davran\u0131\u015flar\u0131n alt s\u0131n\u0131flar taraf\u0131ndan \u00f6zelle\u015ftirilmesini beklerler.
\n* Aray\u00fczler (Interfaces):<\/strong> Sadece metot imzalar\u0131n\u0131 (ve baz\u0131 dillerde sabitleri) i\u00e7eren, hi\u00e7bir implementasyonu olmayan yap\u0131lard\u0131r. Bir s\u0131n\u0131f bir aray\u00fcz\u00fc implemente etti\u011finde, aray\u00fczdeki t\u00fcm metotlar\u0131 kendi i\u00e7inde tan\u0131mlamak zorundad\u0131r. Aray\u00fczler, s\u0131n\u0131flar aras\u0131nda “yapabilir” (can-do) ili\u015fkisini veya bir kontrat\u0131 tan\u0131mlamak i\u00e7in kullan\u0131l\u0131r. \u00c7oklu kal\u0131t\u0131m\u0131n olmad\u0131\u011f\u0131 dillerde (Java, C#), bir s\u0131n\u0131f birden fazla aray\u00fcz\u00fc implemente edebilir, bu da esnekli\u011fi art\u0131r\u0131r.<\/p>\n
\n* Karma\u015f\u0131kl\u0131\u011f\u0131 Azaltma:<\/strong> Kullan\u0131c\u0131n\u0131n sadece \u00f6nemli bilgilere odaklanmas\u0131n\u0131 sa\u011flayarak sistemi daha basit g\u00f6sterir.
\n* Geni\u015fletilebilirlik:<\/strong> Sistemin temel yap\u0131s\u0131n\u0131 tan\u0131mlar ve bu yap\u0131ya uyacak yeni bile\u015fenlerin kolayca eklenmesini sa\u011flar.
\n* Ba\u011fl\u0131l\u0131\u011f\u0131 Azaltma:<\/strong> Kodun farkl\u0131 b\u00f6l\u00fcmlerini birbirinden ba\u011f\u0131ms\u0131z hale getirir. Bir mod\u00fcl, di\u011fer bir mod\u00fcl\u00fcn sadece soyut aray\u00fcz\u00fcn\u00fc bilir, i\u00e7 implementasyon detaylar\u0131n\u0131 de\u011fil. Bu, mod\u00fcller aras\u0131 ba\u011f\u0131ml\u0131l\u0131\u011f\u0131 azalt\u0131r ve daha esnek bir tasar\u0131m sa\u011flar.
\n* Tasar\u0131m Kontrat\u0131:<\/strong> Aray\u00fczler, bir s\u0131n\u0131f\u0131n belirli bir davran\u0131\u015f\u0131 sergileyece\u011fine dair bir kontrat g\u00f6revi g\u00f6r\u00fcr. Bu, b\u00fcy\u00fck projelerde tak\u0131m \u00e7al\u0131\u015fmas\u0131n\u0131 ve mod\u00fcller aras\u0131 entegrasyonu kolayla\u015ft\u0131r\u0131r.<\/p>\nUzaktanKumanda<\/code> s\u0131n\u0131f\u0131, farkl\u0131 marka televizyonlar\u0131 (Samsung, LG) kontrol etmek i\u00e7in kullan\u0131labilir. UzaktanKumanda<\/code> s\u0131n\u0131f\u0131, kanalDegistir()<\/code>, sesAc()<\/code> gibi soyut metotlar\u0131 olan bir aray\u00fcz veya soyut bir s\u0131n\u0131f olabilir. Her televizyon markas\u0131 kendi \u00f6zel implementasyonunu sa\u011flar. Kullan\u0131c\u0131, uzaktan kumanday\u0131 kullan\u0131rken televizyonun dahili devrelerinin nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 bilmek zorunda de\u011fildir, sadece hangi tu\u015fa basmas\u0131 gerekti\u011fini bilir.<\/p>\nEk OOP Kavramlar\u0131 ve Tasar\u0131m Desenleri<\/h2>\n
Soyut S\u0131n\u0131f (Abstract Class) ile Aray\u00fcz (Interface) Aras\u0131ndaki Farklar Nelerdir?<\/h3>\n
\n| :—————- | :———————————————————- | :———————————————————— |
\n| Ama\u00e7<\/strong> | Ortak davran\u0131\u015flar\u0131 ve \u00f6zellikleri payla\u015fan s\u0131n\u0131flar i\u00e7in bir temel s\u0131n\u0131f sa\u011flar, baz\u0131 metotlar\u0131n alt s\u0131n\u0131flarca uygulanmas\u0131n\u0131 bekler. “is-a” ili\u015fkisi. | Bir kontrat veya yetenek tan\u0131mlar. Bir s\u0131n\u0131f\u0131n belirli bir davran\u0131\u015f\u0131 sergileyece\u011fini taahh\u00fct eder. “can-do” ili\u015fkisi. |
\n| Metotlar<\/strong> | Hem soyut (implementasyonu olmayan) hem de somut (implementasyonu olan) metotlar i\u00e7erebilir. | Java 8 \u00f6ncesi sadece soyut metotlar i\u00e7erirken, Java 8’den itibaren default<\/code> ve static<\/code> metotlar da i\u00e7erebilir. C# 8’den itibaren varsay\u0131lan metotlar ve statik soyut metotlar i\u00e7erebilir. |
\n| De\u011fi\u015fkenler<\/strong> | Normal de\u011fi\u015fkenler (static, final, non-final) i\u00e7erebilir. | Java’da sadece public static final<\/code> de\u011fi\u015fkenler (sabitler) i\u00e7erebilir. C#’ta sadece static<\/code> ve const<\/code> de\u011fi\u015fkenler i\u00e7erebilir. |
\n| Yap\u0131c\u0131 (Constructor)<\/strong> | Yap\u0131c\u0131 metotlar\u0131 olabilir, ancak do\u011frudan nesnesi olu\u015fturulamaz (yine de alt s\u0131n\u0131flar taraf\u0131ndan \u00e7a\u011fr\u0131l\u0131r). | Yap\u0131c\u0131 metotlar\u0131 olamaz. |
\n| Kal\u0131t\u0131m<\/strong> | Tek bir s\u0131n\u0131ftan miras al\u0131nabilir (Java, C#). | Bir s\u0131n\u0131f birden fazla aray\u00fcz\u00fc implemente edebilir (\u00e7oklu kal\u0131t\u0131m benzeri yetenek). |
\n| Eri\u015fim Belirleyiciler<\/strong> | Metotlar ve de\u011fi\u015fkenler i\u00e7in public<\/code>, protected<\/code>, private<\/code> kullanabilir. | Java’da t\u00fcm metotlar \u00f6rt\u00fck olarak public abstract<\/code>‘t\u0131r. C#’ta da genellikle public<\/code>‘tir. |
\n| Kullan\u0131m Senaryosu<\/strong> | Bir grup ilgili s\u0131n\u0131f\u0131n ortak davran\u0131\u015flar\u0131n\u0131 payla\u015fmas\u0131 gerekti\u011finde ve bu s\u0131n\u0131flar aras\u0131nda g\u00fc\u00e7l\u00fc bir “is-a” ili\u015fkisi oldu\u011funda. | Tamamen farkl\u0131 s\u0131n\u0131flar\u0131n belirli bir yetene\u011fi payla\u015fmas\u0131 veya bir kontrat\u0131 yerine getirmesi gerekti\u011finde. |<\/p>\nKal\u0131t\u0131m (Inheritance) yerine Kompozisyon (Composition) Ne Zaman Tercih Edilmelidir?<\/h3>\n
Araba<\/code> bir Ara\u00e7<\/code>t\u0131r. S\u0131k\u0131 ba\u011fl\u0131l\u0131k (tight coupling) yarat\u0131r. \u00dcst s\u0131n\u0131ftaki bir de\u011fi\u015fiklik, t\u00fcm alt s\u0131n\u0131flar\u0131 etkileyebilir.
\n* Kompozisyon (Composition):<\/strong> “has-a” (bir …’e sahiptir) ili\u015fkisini ifade eder. Bir s\u0131n\u0131f\u0131n ba\u015fka bir s\u0131n\u0131f\u0131n nesnesini kendi i\u00e7inde bir \u00fcye olarak i\u00e7ermesi anlam\u0131na gelir. \u00d6rne\u011fin, Araba<\/code> bir Motor<\/code>a sahiptir. Gev\u015fek ba\u011fl\u0131l\u0131k (loose coupling) sa\u011flar.<\/p>\n
\n1. “is-a” ili\u015fkisi g\u00fc\u00e7l\u00fc de\u011filse:<\/strong> E\u011fer s\u0131n\u0131flar aras\u0131nda mant\u0131ksal olarak g\u00fc\u00e7l\u00fc bir “is-a” ili\u015fkisi yoksa, kal\u0131t\u0131mdan ka\u00e7\u0131n\u0131lmal\u0131d\u0131r. \u00d6rne\u011fin, bir Yazar<\/code> s\u0131n\u0131f\u0131n\u0131n bir Kitap<\/code> s\u0131n\u0131f\u0131n\u0131 miras almas\u0131 anlams\u0131zd\u0131r; Yazar<\/code>\u0131n Kitap<\/code>lar\u0131 olabilir (kompozisyon).
\n2. S\u0131k\u0131 Ba\u011fl\u0131l\u0131ktan Ka\u00e7\u0131nmak \u0130stendi\u011finde:<\/strong> Kal\u0131t\u0131m, alt s\u0131n\u0131f\u0131 \u00fcst s\u0131n\u0131fa s\u0131k\u0131ca ba\u011flar. \u00dcst s\u0131n\u0131fta yap\u0131lan de\u011fi\u015fiklikler alt s\u0131n\u0131flar\u0131 bozabilir. Kompozisyon, nesnelerin ba\u011f\u0131ms\u0131z olarak de\u011fi\u015ftirilmesine veya yeni nesnelerle de\u011fi\u015ftirilmesine olanak tan\u0131r, bu da daha esnek bir tasar\u0131m sa\u011flar.
\n3. \u00c7oklu Kal\u0131t\u0131m Problemlerinden Ka\u00e7\u0131nmak \u0130\u00e7in:<\/strong> Java gibi dillerde \u00e7oklu kal\u0131t\u0131m desteklenmezken (aray\u00fczler hari\u00e7), C++ gibi dillerde “elmas problemi” gibi sorunlara yol a\u00e7abilir. Kompozisyon, bu t\u00fcr karma\u015f\u0131kl\u0131klardan ka\u00e7\u0131nman\u0131n bir yoludur.
\n4. Daha Fazla Esneklik ve Dinamik Davran\u0131\u015f Gerekti\u011finde:<\/strong> Kompozisyon, \u00e7al\u0131\u015fma zaman\u0131nda nesnelerin davran\u0131\u015flar\u0131n\u0131 de\u011fi\u015ftirmeye olanak tan\u0131r. \u00d6rne\u011fin, bir S\u00fcr\u00fcc\u00fc<\/code> s\u0131n\u0131f\u0131 farkl\u0131 Araba<\/code> nesneleriyle ili\u015fkilendirilebilir veya bir Araba<\/code> nesnesinin Motor<\/code>u \u00e7al\u0131\u015fma zaman\u0131nda de\u011fi\u015ftirilebilir. Kal\u0131t\u0131mda bu daha zordur, \u00e7\u00fcnk\u00fc davran\u0131\u015flar derleme zaman\u0131nda belirlenir.
\n5. K\u00fc\u00e7\u00fck, Odaklanm\u0131\u015f S\u0131n\u0131flar Olu\u015fturmak \u0130\u00e7in:<\/strong> Kompozisyon, her bir s\u0131n\u0131f\u0131n tek bir sorumlulu\u011fu olmas\u0131na yard\u0131mc\u0131 olur (Tek Sorumluluk Prensibi – Single Responsibility Principle).<\/p>\nKedi<\/code> ger\u00e7ekten bir Hayvan<\/code> ise), kal\u0131t\u0131m kullan\u0131n. Aksi takdirde, genellikle kompozisyon daha iyi bir se\u00e7imdir.<\/p>\nSOLID Prensipleri Nelerdir ve Neden \u00d6nemlidir?<\/h3>\n
\n2. O – Open\/Closed Principle (A\u00e7\u0131k\/Kapal\u0131 Prensibi):<\/strong> Yaz\u0131l\u0131m varl\u0131klar\u0131 (s\u0131n\u0131flar, mod\u00fcller, fonksiyonlar vb.) geli\u015ftirmeye a\u00e7\u0131k, ancak de\u011fi\u015ftirmeye kapal\u0131 olmal\u0131d\u0131r. Yani, yeni i\u015flevsellikler eklemek i\u00e7in mevcut kodu de\u011fi\u015ftirmek yerine, onu geni\u015fletmelisiniz. Kal\u0131t\u0131m ve polimorfizm bu prensibi uygulamak i\u00e7in yayg\u0131n olarak kullan\u0131l\u0131r.
\n3. L – Liskov Substitution Principle (Liskov Yerine Ge\u00e7me Prensibi):<\/strong> Alt s\u0131n\u0131flar, \u00fcst s\u0131n\u0131flar\u0131n\u0131n yerine ge\u00e7ebilmelidir. Yani, bir programda \u00fcst s\u0131n\u0131f tipinde bir nesne beklenen her yerde, bu \u00fcst s\u0131n\u0131f\u0131n herhangi bir alt s\u0131n\u0131f\u0131n\u0131n nesnesi de kullan\u0131labilmelidir ve program\u0131n do\u011frulu\u011funu bozmamal\u0131d\u0131r.
\n4. I – Interface Segregation Principle (Aray\u00fcz Ay\u0131rma Prensibi):<\/strong> \u0130stemciler kullanmad\u0131klar\u0131 metotlara ba\u011f\u0131ml\u0131 olmaya zorlanmamal\u0131d\u0131r. B\u00fcy\u00fck, genel ama\u00e7l\u0131 aray\u00fczler yerine, daha k\u00fc\u00e7\u00fck ve spesifik aray\u00fczler tercih edilmelidir.
\n5. D – Dependency Inversion Principle (Ba\u011f\u0131ml\u0131l\u0131k Tersine \u00c7evirme Prensibi):<\/strong> Y\u00fcksek seviyeli mod\u00fcller, d\u00fc\u015f\u00fck seviyeli mod\u00fcllere ba\u011f\u0131ml\u0131 olmamal\u0131d\u0131r. Her ikisi de soyutlamalara (aray\u00fczler veya soyut s\u0131n\u0131flar) ba\u011f\u0131ml\u0131 olmal\u0131d\u0131r. Soyutlamalar detaylara ba\u011f\u0131ml\u0131 olmamal\u0131d\u0131r; detaylar soyutlamalara ba\u011f\u0131ml\u0131 olmal\u0131d\u0131r. Bu, gev\u015fek ba\u011fl\u0131l\u0131\u011f\u0131 te\u015fvik eder ve test edilebilirli\u011fi art\u0131r\u0131r.<\/p>\n
\nSOLID prensipleri, yaz\u0131l\u0131m\u0131n karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 azaltarak, daha s\u00fcrd\u00fcr\u00fclebilir, esnek, test edilebilir ve yeniden kullan\u0131labilir kod yazmaya yard\u0131mc\u0131 olur. Bu prensiplere uymak, uzun vadede projenin bak\u0131m maliyetlerini d\u00fc\u015f\u00fcr\u00fcr ve yeni \u00f6zelliklerin eklenmesini kolayla\u015ft\u0131r\u0131r.<\/p>\nTasar\u0131m Desenleri (Design Patterns) Nedir ve Neden Kullan\u0131l\u0131r?<\/h3>\n
\n* Yarat\u0131msal Desenler (Creational Patterns):<\/strong> Nesne yaratma mekanizmalar\u0131n\u0131 soyutlar ve bu s\u00fcreci esnek ve kontrol edilebilir hale getirir (\u00f6rne\u011fin, Singleton, Factory Method, Abstract Factory, Builder, Prototype).
\n* Yap\u0131sal Desenler (Structural Patterns):<\/strong> Nesnelerin ve s\u0131n\u0131flar\u0131n nas\u0131l bir araya getirilece\u011fini ve daha b\u00fcy\u00fck yap\u0131lar olu\u015fturulaca\u011f\u0131n\u0131 ele al\u0131r (\u00f6rne\u011fin, Adapter, Decorator, Facade, Bridge, Composite, Proxy, Flyweight).
\n* Davran\u0131\u015fsal Desenler (Behavioral Patterns):<\/strong> Nesneler aras\u0131ndaki ileti\u015fimi ve sorumluluk da\u011f\u0131l\u0131m\u0131n\u0131 ele al\u0131r (\u00f6rne\u011fin, Observer, Strategy, Command, Iterator, Mediator, Memento, State, Template Method, Visitor, Chain of Responsibility).<\/p>\n
\n* Kan\u0131tlanm\u0131\u015f \u00c7\u00f6z\u00fcmler:<\/strong> S\u0131k kar\u015f\u0131la\u015f\u0131lan sorunlara end\u00fcstri taraf\u0131ndan kabul g\u00f6rm\u00fc\u015f, test edilmi\u015f \u00e7\u00f6z\u00fcmler sunar.
\n* Ortak Dil:<\/strong> Geli\u015ftiricilerin tasar\u0131m kararlar\u0131 hakk\u0131nda daha kolay ileti\u015fim kurmas\u0131n\u0131 sa\u011flar. Bir desenin ad\u0131n\u0131 s\u00f6ylemek, karma\u015f\u0131k bir tasar\u0131m fikrini h\u0131zl\u0131ca aktar\u0131r.
\n* Kod Kalitesi ve Bak\u0131m Kolayl\u0131\u011f\u0131:<\/strong> \u0130yi tasarlanm\u0131\u015f desenler, kodun daha esnek, geni\u015fletilebilir ve bak\u0131m\u0131 kolay olmas\u0131n\u0131 sa\u011flar.
\n* Yeniden Kullan\u0131labilirlik:<\/strong> Desenler, farkl\u0131 projelerde ve ba\u011flamlarda yeniden kullan\u0131labilir soyut \u00e7\u00f6z\u00fcmler sunar.
\n* En \u0130yi Uygulamalar (Best Practices):<\/strong> Tasar\u0131m desenleri, yaz\u0131l\u0131m mimarisinde iyi uygulamalar\u0131n bir derlemesidir.<\/p>\nOOP M\u00fclakatlar\u0131nda S\u0131k\u00e7a Sorulan Di\u011fer Sorular<\/h2>\n
OOP’nin Avantajlar\u0131 ve Dezavantajlar\u0131 Nelerdir?<\/h3>\n
\n* Yeniden Kullan\u0131labilirlik:<\/strong> S\u0131n\u0131flar ve nesneler, farkl\u0131 projelerde veya ayn\u0131 projenin farkl\u0131 yerlerinde yeniden kullan\u0131labilir, bu da geli\u015ftirme s\u00fcresini k\u0131salt\u0131r ve maliyetleri d\u00fc\u015f\u00fcr\u00fcr.
\n* Bak\u0131m Kolayl\u0131\u011f\u0131:<\/strong> Mod\u00fcler yap\u0131 sayesinde, bir nesnedeki de\u011fi\u015fiklikler genellikle di\u011fer nesneleri etkilemez, bu da hatalar\u0131 bulmay\u0131 ve d\u00fczeltmeyi kolayla\u015ft\u0131r\u0131r.
\n* Esneklik ve Geni\u015fletilebilirlik:<\/strong> Yeni \u00f6zellikler eklemek veya mevcut \u00f6zellikleri de\u011fi\u015ftirmek, OOP prensipleri sayesinde daha kolayd\u0131r. Polimorfizm ve kal\u0131t\u0131m, sistemi mevcut kodu de\u011fi\u015ftirmeden geni\u015fletme olana\u011f\u0131 sunar.
\n* Karma\u015f\u0131kl\u0131k Y\u00f6netimi:<\/strong> Ger\u00e7ek d\u00fcnyadaki karma\u015f\u0131k sistemleri, anla\u015f\u0131l\u0131r ve y\u00f6netilebilir nesnelere b\u00f6lerek modellemeyi kolayla\u015ft\u0131r\u0131r.
\n* Daha \u0130yi Organizasyon:<\/strong> Kodun daha iyi organize edilmesini ve anla\u015f\u0131lmas\u0131n\u0131 sa\u011flar.
\n* G\u00fcvenlik:<\/strong> Kaps\u00fclleme sayesinde verilerin d\u0131\u015far\u0131dan eri\u015fimi kontrol alt\u0131na al\u0131n\u0131r ve veri b\u00fct\u00fcnl\u00fc\u011f\u00fc korunur.
\n* Tak\u0131m \u00c7al\u0131\u015fmas\u0131:<\/strong> Mod\u00fcler yap\u0131, b\u00fcy\u00fck projelerde farkl\u0131 ekiplerin ayn\u0131 anda farkl\u0131 mod\u00fcller \u00fczerinde \u00e7al\u0131\u015fmas\u0131n\u0131 kolayla\u015ft\u0131r\u0131r.<\/p>\n
\n* \u00d6\u011frenme E\u011frisi:<\/strong> OOP kavramlar\u0131 (\u00f6zellikle kal\u0131t\u0131m, polimorfizm, soyutlama) yeni ba\u015flayanlar i\u00e7in karma\u015f\u0131k olabilir ve \u00f6\u011frenme s\u00fcreci zaman alabilir.
\n* Performans Overhead:<\/strong> Nesne olu\u015fturma, metot \u00e7a\u011f\u0131rma gibi i\u015flemler, prosed\u00fcrel programlamaya g\u00f6re hafif bir performans y\u00fck\u00fc getirebilir (\u00e7o\u011fu modern sistemde bu ihmal edilebilir d\u00fczeydedir).
\n* Tasar\u0131m Karma\u015f\u0131kl\u0131\u011f\u0131:<\/strong> \u0130yi bir OOP tasar\u0131m\u0131 yapmak, \u00f6zellikle b\u00fcy\u00fck sistemlerde, zaman ve deneyim gerektirir. Yanl\u0131\u015f tasar\u0131m kararlar\u0131, kodu daha karma\u015f\u0131k ve y\u00f6netilemez hale getirebilir.
\n* Kaynak T\u00fcketimi:<\/strong> Nesneler, prosed\u00fcrel yap\u0131lara g\u00f6re daha fazla bellek t\u00fcketebilir (yine de \u00e7o\u011fu modern sistemde bu bir sorun te\u015fkil etmez).
\n* A\u015f\u0131r\u0131 M\u00fchendislik (Over-engineering):<\/strong> Basit problemler i\u00e7in a\u015f\u0131r\u0131 karma\u015f\u0131k OOP \u00e7\u00f6z\u00fcmleri uygulamak, gereksiz karma\u015f\u0131kl\u0131k ve maliyet art\u0131\u015f\u0131na yol a\u00e7abilir.<\/p>\nSanal Metotlar (Virtual Methods) ve Sanal Fonksiyonlar (Virtual Functions) Nedir?<\/h3>\n
virtual<\/code> anahtar kelimesiyle i\u015faretlenmi\u015f bir metottur. Bu, alt s\u0131n\u0131flar\u0131n bu metodu kendi \u00f6zel implementasyonlar\u0131yla ge\u00e7ersiz k\u0131labilece\u011fi (override edebilece\u011fi) anlam\u0131na gelir. Bir \u00fcst s\u0131n\u0131f referans\u0131 arac\u0131l\u0131\u011f\u0131yla \u00e7a\u011fr\u0131ld\u0131\u011f\u0131nda, \u00e7al\u0131\u015fma zaman\u0131nda (runtime) nesnenin ger\u00e7ek tipine g\u00f6re do\u011fru metot \u00e7a\u011fr\u0131l\u0131r. Bu, \u00e7al\u0131\u015fma zaman\u0131 polimorfizmini sa\u011flar.
\n* Sanal Fonksiyon Tablosu (V-Table):<\/strong> Sanal metotlar kullan\u0131ld\u0131\u011f\u0131nda, derleyici her s\u0131n\u0131f i\u00e7in bir sanal fonksiyon tablosu (v-table) olu\u015fturur. Bu tablo, s\u0131n\u0131f\u0131n sanal metotlar\u0131n\u0131n adreslerini i\u00e7erir. Bir nesne olu\u015fturuldu\u011funda, bu nesnenin bir i\u015faret\u00e7isi (v-pointer) v-table’a y\u00f6nlendirilir. Bir sanal metot \u00e7a\u011fr\u0131ld\u0131\u011f\u0131nda, sistem v-pointer arac\u0131l\u0131\u011f\u0131yla v-table’a bakar ve nesnenin ger\u00e7ek tipine kar\u015f\u0131l\u0131k gelen metodu \u00e7a\u011f\u0131r\u0131r.<\/p>\n
\nSanal metotlar, bir dizi farkl\u0131 nesne \u00fczerinde tek tip bir aray\u00fcz kullanarak i\u015flem yapman\u0131z\u0131 sa\u011flar. Bu, kodun daha esnek, geni\u015fletilebilir ve bak\u0131m\u0131 kolay olmas\u0131n\u0131 sa\u011flar. \u00d6rne\u011fin, bir Animal<\/code> s\u0131n\u0131f\u0131nda MakeSound()<\/code> sanal metodu varsa, Dog<\/code> ve Cat<\/code> s\u0131n\u0131flar\u0131 bunu kendi sesleriyle ge\u00e7ersiz k\u0131labilir. Bir Animal<\/code> referans\u0131 \u00fczerinden MakeSound()<\/code> \u00e7a\u011fr\u0131ld\u0131\u011f\u0131nda, do\u011fru ses \u00e7al\u0131\u015fma zaman\u0131nda belirlenir.<\/p>\nStatik (Static) Anahtar Kelimesi OOP’de Ne Anlama Gelir?<\/h3>\n
static<\/code> anahtar kelimesi, bir s\u0131n\u0131f \u00fcyesinin (de\u011fi\u015fken veya metot) s\u0131n\u0131fa ait oldu\u011funu, belirli bir nesneye ait olmad\u0131\u011f\u0131n\u0131 belirtir.<\/p>\n
\n* Statik Metotlar (Static Methods \/ Class Methods):<\/strong> Bir s\u0131n\u0131fa aittir ve bir nesne \u00f6rne\u011fi olu\u015fturulmadan do\u011frudan s\u0131n\u0131f ad\u0131 \u00fczerinden \u00e7a\u011fr\u0131labilirler (\u00f6rne\u011fin, Math.sqrt(x)<\/code>). Statik metotlar, s\u0131n\u0131f\u0131n statik de\u011fi\u015fkenlerine eri\u015febilirler ancak s\u0131n\u0131f\u0131n \u00f6rnek de\u011fi\u015fkenlerine (non-static<\/code>) do\u011frudan eri\u015femezler, \u00e7\u00fcnk\u00fc bir nesne \u00f6rne\u011fiyle ili\u015fkili de\u011fildirler.<\/p>\n
\n* Ortak Veri\/Davran\u0131\u015f:<\/strong> T\u00fcm nesneler taraf\u0131ndan payla\u015f\u0131lmas\u0131 gereken veri veya davran\u0131\u015flar i\u00e7in kullan\u0131l\u0131r.
\n* Yard\u0131mc\u0131 Fonksiyonlar:<\/strong> Belirli bir nesne durumu gerektirmeyen yard\u0131mc\u0131 fonksiyonlar veya matematiksel i\u015flemler i\u00e7in idealdir.
\n* Performans:<\/strong> Nesne olu\u015fturma maliyetinden ka\u00e7\u0131nmak i\u00e7in kullan\u0131labilir (ancak bu, genellikle birincil neden de\u011fildir).<\/p>\nSonu\u00e7: OOP Ustal\u0131\u011f\u0131na Giden Yol<\/h2>\n