Nesne Yönelimli Programlama – 6 Access Modifiers

Merhaba dostlarım… Nesne yönelimli programlama serimize devam ediyoruz. Bu yazımda size, erişim düzenleyicilerden (Access modifiers) bahsedeceğim. Aslına bakarsanız, bu yazıyı yazarken içimden bir ses; “şişman adam bak bu makale çok kısa olacak, hem zaten heryerden öğrenilebilecek bir konu, ayrıca çok kolay niye yazıyorsun ki?” diye soruyor. Benim düşüncem ise şöyle yanıt veriyor; “evet basit bir…

03/12/2012 by turkayurkmez

Merhaba dostlarım…

Nesne yönelimli programlama serimize devam ediyoruz. Bu yazımda size, erişim düzenleyicilerden (Access modifiers) bahsedeceğim. Aslına bakarsanız, bu yazıyı yazarken içimden bir ses; “şişman adam bak bu makale çok kısa olacak, hem zaten heryerden öğrenilebilecek bir konu, ayrıca çok kolay niye yazıyorsun ki?” diye soruyor. Benim düşüncem ise şöyle yanıt veriyor; “evet basit bir konu olabilir ama, nesne yönelimli programlamanın en temel noktalarından biri. Ayrıca, ben bu nesne yönelimli programlama serisinde, kavramın tüm ayrıntılarını anlatmak istiyorum”. Eğer, şu an bu yazıyı okuyorsanız, bu söz düellosunu ben kazanmışım demektir.

İşte ben, böyle şizofrenik bir durumdayken (gecenin 02.53’ünde normal tabii), farkında olmadan makaleyi biraz daha uzatmış oluyorum (kim demiş, makale ciddi olmalı diye?)…

Öncelikle erişim düzenleyici dediğimiz anahtar kelimelerin ne işe yaradığı hakkında genel bir tanım yapalım. Bir tipin kendisine veya o tipe ait üyelere (metod, özellik ya da olay) nasıl erişileceğini daha doğrusu, nereden (hangi kod bloğundan) erişelebileceğini belirleyen kelimelere “erişim düzenleyiciler” diyoruz. İşte şimdi bu kelimeleri, tek tek anlatmaya sıra geldi.

private

En minik erişim düzenleyicisidir. Tipin üyelerinde kullanılır. Üyenin (bu üye metod veya global değişken –alan- olabilir), yalnızca o tipin içerisinden erişilmesine izin verir. Yani üyenin o tipe “özel” olmasını sağlar. Adı üzerinde! Başka bir değişle, private anahtar kelimesi ile tanımlanmış bir üyeye, tip dışından ulaşamazsınız. Ha unutmadan: private üyeler miras yoluyla türetilmiş sınıflara aktarılamazlar. Bir şey daha, eğer bir üyenin önüne hiçbir erişim düzenleyici anahtar kelimesi belirtmezseniz, o üye derleyici tarafından private olarak algılanır. Yani private, üyeler için varsayılan erişim düzenleyicisidir.

public

En genel ve sınırsız erişim düzenleyicisidir. Hem tip için hem de, tip üyeleri için kullanılabilir. Elbette her ikisi için de farklı anlamları vardır. Önce tipler için konuşalım. Örneğin, bir sınıfın erişim düzenleyicisi public ise bu, o sınıfın, bulunduğu assembly dışından (referans olarak alındığı başka bir assembly’den) her türlü erişilebileceği anlamına gelir. Peki, tipin üyeleri public ise ne olur? Yine adı üzerinde. public, “genel” demektir. Yani, o üyeye her yerden erişilebilir.Doğal olarak kalıtım yolu ile türetilmiş sınıflara aktarılırlar.

Şimdiye dek anlattığım erişim düzenleyicileri hakkında zaten az çok birşeyler duymuşsunuzdur. Sınıflarımda bu konuyu anlatırken, öğrencilerimin yüz ifadelerinin en çok değiştiği erişim düzenleyicelere geldi sıra (bu ifade değişimi genellikle şöyle yorumlanır; “ee nerede kullanacağız lan bunu?” ya da “anlamadım ki!”).

protected

Korunan” anlamına geldiği aşikar. Peki ama kim kimden korunuyor (“şşşt!! Değiştirmeyin yüz ifadenizi hemen”)? Peki, sadece tipin üyelerinde (metod veya alan) kullanılabilir (aynı private gibi). Bu üyeye yalnızca ait olduğu tip içinden ulaşılabilir (aa! Bu da private gibi). E o zaman, private’den farkı nedir? İşte tek fark: protected olarak tanımlanmış alan ya da metodlar, miras olarak aktarılabiliriler. Yani, “bu üyeye kesinlikle dışardan ulaşılamasın, ama miras bırakılabilsin” diyorsanız, o üye protected olmalı.

Peki ne zaman, nasıl bir modelde buna ihtiyaç duyarsınız? Şöyle hayal edelim; “personel” isminde bir sınıfınız var ve bu sınıfın da “maasHesapla” isminde bir metodu var. Metod basitçe, mesai saati ve saat ücretlerini alıp çarpıyor. Şimdi, bu sınıfın temel sınıf olmasına karar verdiniz. Muhendis ve Muhasebeci sınıflarını buradan türeteceksiniz. E onlarda da maasHesapla metodu olacak (yani kalıtım yoluyla aktarılacak – private olamaz). Ama siz, bu sınıfların dışından (yani sınıfın örneğinden) maasHesapla metoduna erişmek istemiyorsunuz (o zaman public olma şansı yok). İşte bu durumda maasHesapla metodu, protected olmalı.

Örneklerle bakalım:

Yukarıda mevzu bahis Personel isimli sınıfımı görüyorsunuz.

Burada ise, türetilmiş sınıfım olan Muhendis içinde, “Ornek” isimli metodda, this anahtar kelimesiyle; Personel sınıfından kalıtım aldığım “maasHesapla” metoduna ulaşabiliyorum. Burada bir hatırlatma yapalım; this anahtar sözcüğü, yalnızca o sınıfın (örneğimizde Personel sınıfı) üyelerine ulaşmak için kullanılır. Böylece, kabaca “miras bırakılabilen, fakat dışarıdan ulaşılamayan alanlar protected erişim düzenleyicisi ile belirlenir” diyebilir miyiz? Bence deriz güzel de olur!

internal

“Dahili” anlamına gelmektedir. Yalnızca bulunduğu assembly’den erişilebilir. Burada assembly ifadesinden kasıt, projenin kendisidir. Yani, bir kütüphane (.dll) oluşturuyorsanız, internal bir sınıfa sadece o kütüphaneden ulaşabilirsiniz. Bu erişim düzenleyicisi, sınıf üyelerinde de kullanılabilir. Onda da etkisi aynıdır. Bir sınıfın erişim düzenleyicisi belirtilmezse, varsayılan olarak internal kabul edilir.

protected internal

Yalnızca sınıf üyelerine uygulanır. Kelimelerin arasına “ya da” konulunca anlaşılması daha kolay olacaktır. Erişim yapılan yere göre “internal” ya da “protected” davranır. Doğal olarak assembly dışından erişilmeye çalışıldığında internal, aynı assembly’den erişilmeye çalışıldığında ise proyected davranır.

İşte sevgili dostlarım. Bu noktadan bakıldığında bile, bu nesne yönelimli programlama kavramında, “nesne modellemenin” ne kadar büyük bir okyanus olduğunu gösteriyor. Bu okyanus ki, bir sorunun sonsuz çözümünü ihtiva ediyor.

Bu konuda bir yazımızın daha sonuna geliyor ve yazılım isimli puzzle’ın bir parçasını daha yerine koymuş oluyoruz.

Sağlıcakla kalın.

 

Leave a Reply

9 Comments

  • Kurstayken bu internal’i nerede kullanacağımı bir türlü kestiremiyordum , dll kodlamaya başlayınca gördüm ki en çok internal gerekiyor.. ama protected internal’in kullanıldıgı bir senaryoyla karşılaşamadım malesef : ))

  • Çok teşekkürler hocam bu güzel paylaşım için

  • Hocam blogunuzu takip etmenin faydalarını gördüğüm için ayrıca teşekkür ederim

  • Harika. Ellerinize sağlık çok güzel anlatıyorsunuz.

    Özellikle protected’da ki "şşşt!! Değiştirmeyin yüz ifadenizi hemen" e sağlam bir kahkaha attım.

    dip not: protected örneğinde geçen "this anahtar sözcüğü, yalnızca o sınıfın (örneğimizde Personel sınıfı)" demişsiniz. Burada o sınıf diye bahsettiğiniz Muhendis ise this de Muhendis’e işaret edecektir ? Diye düşünmekteyim

    Selamlar

    Burç

  • [b]@Burç[/b]
    Burç orada hocamızın bahsettiği, "this" ‘i temsil eden sınıf mühendis sınıfı.. 🙂 Ufak bir karışıklık olmuş.. :)) Eğer "base" deseydi, o zaman personel sınıfını kullanıyor olacaktı.

    Hocam bi de Modifiers ‘lar hakkında bir makale görünüyor gibi ufukta 🙂 Aslında o konuda bir makalenizi okumak süper olur.. 🙂

    Sevgiler..
    Saygılar..

  • @Burç, Kadir’in de dediği gibi bir karışıklık olmuş. Dediğin gibi oradaki this kelimesi Muhendis sınıfını kast ediyor 🙂

  • Serkan Saygılı

    Türkay Ürkmez’den yeni makaleler istiyoruuzzzz

  • Mehmet

    Faydalandık sağolasın. Güzel anlaşılır olmuş.

  • Zeynep

    Hocam selam,
    Öncelikle anlatımınız için teşekkürler. Bir sorum olacak:
    "aynı assembly'den erişilmeye çalışıldığında ise protected davranır."
    demişssiniz, yanlışmı algılıyorum bilmiyorum ama şöyleki:
    public class alt:Ust
    {
    public int Public { get { return MyProperty3; } set { } }
    internal int Internal { get; set; }
    protected int Protected { get; set; }
    protected internal int ProtectedInternal{ get; set; }
    }

    instance aldığımda Protected gelmiyor. ProtectedInternal geliyor. Onun da gelmemesi gerekmiyormu