Ekşi Duyuru

forum.ceviz.net

peki ben sunu anlayamadim bunun programciya ya da programa nasıl bi yarari olur? ne ozellik katar yani private larin kullanilmasi?kullanmazsak nolur? guvenlik acisindan dusundugum zaman biraz sacma geldi bilemedim. Cok soru sordum biliyorum ama öğrenme ışığı dogdu içime hehe

Item 20: Avoid data members in the public interface.

First, let's look at this issue from the point of view of consistency. If everything in the public interface is a function, clients of your class won't have to scratch their heads trying to remember whether to use parentheses when they want to access a member of your class. They'll just do it, because everything is a function. Over the course of a lifetime, that can save a lot of head scratching.

You don't buy the consistency argument? How about the fact that using functions gives you much more precise control over the accessibility of data members? If you make a data member public, everybody has read/write access to it, but if you use functions to get and set its value, you can implement no access, read-only access, and read-write access. Heck, you can even implement write-only access if you want to:

class AccessLevels {
public:
int getReadOnly() const{ return readOnly; }
void setReadWrite(int value) { readWrite = value; }
int getReadWrite() const { return readWrite; }
void setWriteOnly(int value) { writeOnly = value; }
private:
int noAccess; // no access to this int
int readOnly; // read-only access to
// this int
int readWrite; // read-write access to
// this int
int writeOnly; // write-only access to
// this int
};
Still not convinced? Then it's time to bring out the big gun: functional abstraction. If you implement access to a data member through a function, you can later replace the data member with a computation, and nobody using your class will be any the wiser.

For example, suppose you are writing an application in which some automated equipment is monitoring the speed of passing cars. As each car passes, its speed is computed, and the value is added to a collection of all the speed data collected so far:

class SpeedDataCollection {
public:
void addValue(int speed); // add a new data value
double averageSoFar() const; // return average speed
};
Now consider the implementation of the member function averageSoFar (see also Item M18). One way to implement it is to have a data member in the class that is a running average of all the speed data so far collected. Whenever averageSoFar is called, it just returns the value of that data member. A different approach is to have averageSoFar compute its value anew each time it's called, something it could do by examining each data value in the collection. (For a more general discussion of these two approaches, see Items M17 and M18.)

The first approach — keeping a running average — makes each SpeedDataCollection object bigger, because you have to allocate space for the data member holding the running average. However, averageSoFar can be implemented very efficiently; it's just an inline function (see Item 33) that returns the value of the data member. Conversely, computing the average whenever it's requested will make averageSoFar run slower, but each SpeedDataCollection object will be smaller.

Who's to say which is best? On a machine where memory is tight, and in an application where averages are needed only infrequently, computing the average each time is a better solution. In an application where averages are needed frequently, speed is of the essence, and memory is not an issue, keeping a running average is preferable. The important point is that by accessing the average through a member function, you can use either implementation, a valuable source of flexibility that you wouldn't have if you made a decision to include the running average data member in the public interface.

The upshot of all this is that you're just asking for trouble by putting data members in the public interface, so play it safe by hiding all your data members behind a wall of functional abstraction. If you do it now, we'll throw in consistency and fine-grained access control at no extra cost!

bu arada ilk linkte protected yanlis tanimlanmis, protected methodlar sadece o package içinde kullanılabiliyor.

Ingilizce metin oldukca aciklayici. Sadece kendin icin yazdigin ve basit kodlarda bu fark cok onemli degil. Cunku kullandigin sinifin detaylarini biliyorsun. Ama multi thread olarak calisan bir programi dusunursen sorunlar baslayabilir. Farkli threadler ayni anda ayni degiskeni okumaya ve yazmaya calisabilir. Ama ayni degiskene ulasimi fonksiyon araciligi ile yaparsan senkronizasyon sorunlarini rahatca cozebilirsin. Ayrica senin kodunun ayrintilarini kullanicidan saklamis olursun. Daha sonraki versiyonlarda senin bu fonksiyonun icinde yaptiklarin tamamen degisebilir ama kodu kullanan kullanici bu degisikligi hic bir sekilde farketmez. Ayni kodu kullanmaya devam edebilir.

Data abstraction ve encapsulation konularina bakmakda fayda olabilir.

şöyle bir sorum daha olacak: mesela ben blackbox (kapali source'lu) bir program yazdim. boyle bi programda zaten kullanicinin benim kodlarima ulasmasi imkansiz degil mi? neden bir de ayrica private yapayim ki? ayrica get set fonksiyonlariyla zaten kullanici bu degerleri gorup degistiremez mi?. inanilmaz kafam karisti yahu. ne bicim seymis hayret...

private protected public gibi şeyler başka kullanıcı için değildir. bunlar programındaki objelerin, yapmaması gereken şeyleri yapmasını engellemek içindir. bunları belirlemek ise programcının işi, herşeyi public yaparsan da herşey çalışır, ama dediğim gibi mesela Kedi class'ının yumakIleOyna() methodu gidip Kopek class'ının kuyruk property'sini değiştirebilir, basit oldu ama bu tarz sistematik bir mimari oluşturmak içindir bu özellikler. Onemsiz gerekebilir ama onemlidir.

Bence sakin bi kafayla düzgün bi kaynağı (tercihen kitap) yavaş yavaş oku kesin yerleşir hepsi :)

Bu arada ek bilgi, .class dosyaları decompiler'lar ile açılıp okunabilir.