9 Mayıs 2020 Cumartesi

SOLID Prensipleri -The Open-Closed Principle- Uncle Bob Çevirisi

Merhaba, bu seride sizlere Uncele Bob'un (Robert C. Martin) SOILD presnipleri için yazdığı makaleleri Türkçe'ye çevireceğim. Umarım yararlı bir yazı dizisi olur.

Seri'nin diğer yazıları :

The Single Responsibility Principle




2- The Open-Closed Principle


Ivar Jacobson'un dediği gibi: “Tüm sistemler yaşam döngüleri boyunca değişir. İlk sürümden daha uzun sürmesi beklenen sistemler geliştirilirken bu akılda tutulmalıdır. ” Değişim karşısında, kararlı ve ilk sürümden daha uzun sürecek tasarımlar nasıl oluşturabiliriz? Bertrand Meyer, ünlü open-closed prensibini icat ettiği 1988'den beri bize rehberlik etti. Onu yeniden ifade etmek için:

SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICATION.
(Yazılım varlıkları (SINIFLAR, MODÜLLER, FONKSİYONLAR, VB.) gelişime açık, ancak değişikliğe kapalı olmalıdır.) 

Bir programda yapılan tek bir değişiklik, bağımlı modüllerde kademeli bir değişiklikle sonuçlandığında, bu program “kötü” tasarımla ilişkilendirdiğimiz istenmeyen nitelikleri sergiler. Program kırılgan, katı, öngörülemez ve kullanılamaz hale gelir. Açık kapalı prensibi bunu çok basit bir şekilde engeller. Asla değişmeyen modüller tasarlamanız gerektiğini söylüyen bu prensip, gereksinimler değiştiğinde, bu tür modüllerin davranışlarını, zaten çalışan eski kodu değiştirerek değil, yeni kod ekleyerek genişletmeyi önerir.

TANIM

Açık-kapalı prensibine uyan modüllerin iki temel özelliği vardır.

1.  “Genişlemeye Açık” dır.
Bu, modülün davranışının genişletilebileceği anlamına gelir. Uygulamanın gereksinimleri değiştikçe veya yeni uygulamaların gereksinimlerini karşılamak için modülün yeni ve farklı şekillerde davranmasını sağlayabiliriz.

2. “Değişikliğe Kapalıdır”.
Böyle bir modülün kaynak kodu dokunulmazdır. Hiç kimsenin kaynak kodda değişiklik yapmasına izin verilmez.

Bu iki özelliğin birbiriyle çeliştiği anlaşılıyor. Bir modülün davranışını genişletmenin normal yolu, o modülde değişiklik yapmaktır. Değiştirilemeyen bir modülün normalde sabit bir davranışı olduğu düşünülmektedir. Bu iki karşıt özellik nasıl çözülebilir?


Abstraction is the Key
(Soyutlama burada kilit anahtardır)

C ++ 'da, nesne yönelimli tasarım ilkelerini kullanarak, sabit ve sınırsız olası davranış grubunu temsil eden soyutlamalar oluşturmak mümkündür. Soyutlamalar soyut temel sınıflardır ve sınırsız olası davranış grubu tüm olası alt sınıfları tarafından temsil edilir. Bir modülün bir soyutlamayı manipüle etmesi mümkündür. Böyle bir modül, düzeltilmiş bir soyutlamaya bağlı olduğu için modifikasyon için kapatılabilir. Yine de bu modülün davranışı, soyutlamanın yeni alt sınıfları yaratılarak genişletilebilir.

Şekil 1, açık-kapalı prensibine uymayan basit bir tasarımı göstermektedir. Hem Client hem de Server sınıfları somuttur. Server sınıfının üye metodlarının abstract olduğuna dair bir garanti yoktur. Client sınıfı Server sınıfını kullanır. Bir Client nesnesinin farklı bir sunucu nesnesi kullanmasını istiyorsak, yeni sunucu sınıfını adlandırmak için Client sınıfının değiştirilmesi gerekir.


Şekil 2, açık-kapalı prensibine uyan ilgili tasarımı göstermektedir. Bu durumda, AbstractServer sınıfı saf abstract üye metodlarına sahip soyut bir sınıftır. Client sınıfı bu soyutlamayı kullanır. Ancak Client sınıfının nesneleri, alt sınıf Server sınıfının nesnelerini kullanacaktır. Client nesnelerinin farklı bir sunucu sınıfı kullanmasını istiyorsak, AbstractServer sınıfının yeni bir alt sınıfı oluşturulabilir. Client sınıfı değişmeden kalabilir.



The Shape Abstraction
(Şekil Soyutlaması)


Aşağıdaki örneği ele alalım. Standart bir GUI üzerine daireler ve kareler çizebilmemiz gereken bir uygulamamız var. Daireler ve kareler belirli bir sırada çizilmelidir. Dairelerin ve karelerin bir listesi uygun sırayla oluşturulacaktır ve program listeyi bu sırayla yürütmeli ve her daireyi veya kareyi çizmelidir.

C'de, açık-kapalı prensibine uymayan prosedürel teknikler kullanarak, bu problemi aşağıdai kodda gösterildiği gibi çözebiliriz. Burada aynı ilk öğeye sahip olan ancak bunun ötesinde farklı bir veri yapıları kümesi görüyoruz. Her birinin ilk öğesi, veri yapısını daire veya kare olarak tanımlayan bir tür kodudur. DrawAllShapes metodu, bu veri yapılarına bir dizi işaretçi yürütür, tür kodunu inceler ve sonra uygun fonksiyonu çağırır (DrawCircle veya DrawSquare).
Procedural Solution to the Square/Circle Problem
enum ShapeType {circle, square};
struct Shape
{
 ShapeType itsType;
};
struct Circle
{
 ShapeType itsType;
 double itsRadius;
 Point itsCenter;
};
struct Square
{
 ShapeType itsType;
 double itsSide;
 Point itsTopLeft;
};
//
// These functions are implemented elsewhere
//
void DrawSquare(struct Square*)
void DrawCircle(struct Circle*);
typedef struct Shape *ShapePointer;
void DrawAllShapes(ShapePointer list[], int n)
{
 int i;
 for (i=0; iitsType)
 {
 case square:
 DrawSquare((struct Square*)s);
 break;
 case circle:
 DrawCircle((struct Circle*)s);
 break;
 }
 }
}

DrawAllShapes metodu, yeni şekil türlerine karşı kapatılamadığından açık-kapalı prensibine uymaz. Üçgenleri içeren şekiller listesi çizebilmek için bu fonksiyonu genişletmek isteseydim, fonksiyonu değiştirmek zorunda kalırdım. Aslında, çizmem gereken herhangi bir yeni şekil için fonksiyonu değiştirmem gerekirdi.

Elbette bu program sadece basit bir örnektir. Gerçek hayatta DrawAllShapes fonksiyonundaki switch deyimi, uygulamanın her yerindeki çeşitli fonksiyonlarda tekrar tekrar tekrarlanır; her biri biraz farklı bir şey yapar. Böyle bir uygulamaya yeni bir şekil eklemek, bu tür anahtar ifadelerin (veya if / else zincirlerinin) bulunduğu her yer için her birine yeni şekil ekleme anlamına gelir. Ayrıca, tüm switch deyimlerinin ve if / else zincirlerinin DrawAllShapes'deki kadar güzel yapılandırılmış olması pek olası değildir.

İf ifadelerinin tahminlerinin mantıksal işleçlerle birleştirilecek ya da
switch statementlarının case'leri yerel karar almayı “basitleştirmek” için birleştirilecektir. Bu nedenle, yeni şeklin eklenmesi gereken tüm yerleri bulma ve anlama problemi önemsiz olabilir.

Aşağıdaki kod bloğu, açık-kapalı prensibine uyan kare / daire problemine bir çözüm kodunu gösterir. Bu durumda soyut bir Shape sınıfı oluşturulur. Bu soyut sınıf, Draw adında tek bir saf sanal metoda sahiptir. Daire ve Kare, Shape sınıfının alt sınıflarıdır.


Square/Circle problemine OOD Çözümü.
class Shape
{
 public:
 virtual void Draw() const = 0;
};
class Square : public Shape
{
 public:
 virtual void Draw() const;
};
class Circle : public Shape
{
 public:
 virtual void Draw() const;
};
void DrawAllShapes(Set& list)
{
 for (Iteratori(list); i; i++)
 (*i)->Draw();
}

Yeni bir şekil çizmek için yukarıdaki kodda DrawAllShapes metodunun davranışını genişletmek istiyorsak, tek yapmamız gereken Shape sınıfının yeni bir alt sınıfı eklemektir. DrawAllShapes metodunun değiştirilmesi gerekmez. Böylece DrawAllShapes açık kapalı prensibine uygundur. Davranışı değiştirilmeden genişletilebilir.

Gerçek dünyada Shape sınıfının çok daha fazla methodu olacaktır. Yine de uygulamaya yeni bir şekil eklemek hala oldukça basittir, çünkü gerekli olan tek şey yeni alt sınıfı oluşturmak ve tüm metodlarını uygulamaktır. Değişiklik gerektiren yerleri arayan tüm uygulamada arayarak avlanmaya gerek yoktur.

Açık-kapalı prensibine uyan programlar, mevcut kodu değiştirmek yerine yeni kod ekleyerek değiştirildiğinden, bu presibe uymayan programlar tarafından sergilenen değişikliklerin sıkıntısını yaşamazlar.

STRATEJİK KAPATMA

Hiçbir programın% 100 kapatılamayacağı açık olmalıdır. Örneğin, tüm Circle'ların herhangi bir Square'den önce çizilmesi gerektiğine karar verirsek, yukarıdaki koddaki DrawAllShapes metoduna ne olacağını düşünün. DrawAllShapes metodu böyle bir değişikliğe karşı kapalı değildir. Genel olarak, bir modül ne kadar “kapalı” olursa olsun, her zaman kapalı olmadığı bir tür değişiklik olacaktır.

Kapanış tamamlanamayacağı için stratejik olmalı. Yani, tasarımcı tasarımını kapatmak için hangi tür değişiklikleri yapması gerektiğini seçmelidir. Bu, deneyimden elde edilen belli bir miktar önseziyi gerektirir. Deneyimli tasarımcı, kullanıcıları ve sektörü farklı türdeki değişikliklerin olasılığını değerlendirecek kadar iyi tanır. Daha sonra açık-kapalı prensibinin en olası değişiklikler için çağrıldığından emin olur.

Using Abstraction to Gain Explicit Closure.
(Açık Kapatma Kazanmak için Soyutlama Kullanma.)

Çizim sırasındaki değişikliklere karşı DrawAllShapes metodunu nasıl kapatabiliriz? Kapamanın soyutlamaya dayandığını unutmayın. Bu nedenle, DrawAllShapes'i sıralamaya karşı kapatmak için bir çeşit “sıralama soyutlaması” na ihtiyacımız var. Yukarıdaki özel sıralama durumu, diğer şekil türlerinden önce belirli şekil türlerinin çizilmesiyle ilgilidir.

Bir sıralama politikası, herhangi iki nesne göz önüne alındığında, hangisinin önce çizilmesi gerektiğini keşfetmenin mümkün olduğunu gösterir. Böylece, başka bir Şekli bağımsız değişken olarak alan ve bir bool sonucu döndüren Precedes adlı bir Shape yöntemi tanımlayabiliriz. İletiyi alan Shape nesnesinin, Shape nesnesi bağımsız değişken olarak geçmeden önce sıralanması gerekmesi sonucunu doğrudur.

C ++ 'da bu metod aşırı yüklenmiş bir operatör <fonksiyonu ile temsil edilebilir.
Liste 3, yerinde sıralama yöntemleriyle Shape sınıfının nasıl görünebileceğini göstermektedir. Artık iki Shape nesnesinin göreceli sırasını belirlemenin bir yoluna sahip olduğumuza göre, bunları sıralayabilir ve sonra sırayla çizebiliriz. Liste 4, bunu yapan C ++ kodunu gösterir.

Bu bize Shape nesnelerini sıralamak ve bunları uygun sırada çizmek için bir araç sağlar. Ama hala iyi bir sıralama soyutlamamız yok. Haliyle, her bir Shape nesnesinin sıralamasını belirtmek için Precedes yöntemini geçersiz kılması gerekecektir. Bu nasıl olurdu? Karelerin Liste 5'ten önce çizildiğinden emin olmak için, Circle :: Preedes'de ne tür bir kod yazardık?


Listing 3
Shape with ordering methods.
class Shape
{
 public:
 virtual void Draw() const = 0;
 virtual bool Precedes(const Shape&) const = 0;
 bool operator<(const Shape& s) {return Precedes(s);}
};
Listing 4
DrawAllShapes with Ordering
void DrawAllShapes(Set& list)
{
 // copy elements into OrderedSet and then sort.
 OrderedSet orderedList = list;
 orderedList.Sort();
 for (Iterator i(orderedList); i; i++)
 (*i)->Draw();
}

}
Listing 5
Ordering a Circle
bool Circle::Precedes(const Shape& s) const
{
 if (dynamic_cast(s))
 return true;
 else
 return false;
}
<
Bu metodun açık-kapalı prensibine uymadığı çok açık olmalıdır. Yeni Shape alt sınıflarına karşı kapatmanın bir yolu yoktur. Her yeni bir Shape alt sınıfı oluşturulduğunda, bu metodun değiştirilmesi gerekir.


Using a “Data Driven” Approach to Achieve Closure.
(Kapanışı Gerçekleştirmek için “Veriye Dayalı” Bir Yaklaşım Kullanmak.)

Shape alt sınıflarının kapatılması, türetilmiş her sınıftaki değişiklikleri zorlamayan tablo güdümlü bir yaklaşım kullanılarak elde edilebilir. Liste 6'da bir olasılık gösterilmektedir.
Bu yaklaşımı kullanarak, genel olarak sıralama sorunlarına karşı DrawAllShapes metodunu ve yeni Shape alt sınıflarının oluşturulmasına veya Shape nesnelerini türlerine göre yeniden sıralayan politikadaki bir değişikliğe karşı Shape alt sınıflarının her birini başarıyla kapattık. (örneğin, önce Kareler çizilecek şekilde sıralamayı değiştirme.)

Listing 6
Tabloya dayalı sıralama mekanizması
#include 
#include 
enum {false, true};
typedef int bool;
class Shape
{
 public:
 virtual void Draw() const = 0;
 virtual bool Precedes(const Shape&) const;
 bool operator<(const Shape& s) const
 {return Precedes(s);}
 private:
 static char* typeOrderTable[];
};
char* Shape::typeOrderTable[] =
{
 “Circle”,
 “Square”,
 0
};
// Bu fonksiyon sınıf isimlerine göre tabloda arama yapar
// Tablo hangi şeklin çizileceğikonusunda sıralama bilgisi verir
// Bulunamayan şekiller
// her zaman bulunan şekillerden önce gelir.

bool Shape::Precedes(const Shape& s) const
{
 const char* thisType = typeid(*this).name();
 const char* argType = typeid(s).name();
 bool done = false;
 int thisOrd = -1;
 int argOrd = -1;
 for (int i=0; !done; i++)
 {
 const char* tableEntry = typeOrderTable[i];
 if (tableEntry != 0)
 {
 if (strcmp(tableEntry, thisType) == 0)
 thisOrd = i;
 if (strcmp(tableEntry, argType) == 0)
 argOrd = i;
 if ((argOrd > 0) && (thisOrd > 0))
 done = true;
 }
 else // table entry == 0
 done = true;
 }
 return thisOrd < argOrd;
}

Çeşitli Şekillerin sırasına karşı kapalı olmayan tek öğe tablonun kendisidir. Ve bu tablo, diğer modüllerden ayrı olarak kendi modülüne yerleştirilebilir, böylece tabloda yapılan değişiklikler diğer modüllerin hiçbirini etkilemez.


Heuristics and Conventions
(Buluşsal Yöntemler ve Sözleşmeler)

Bu makalenin başında belirtildiği gibi, açık-kapalı prensibi, yıllar boyunca OOD ile ilgili olarak yayınlanan birçok buluşsal yöntem ve sözleşmenin arkasındaki temel motivasyondur. İşte bunların en önemlilerinden bazıları.

Make all Member Variables Private.
(Tüm Üye Değişkenlerini Private Yap.)

Bu, OOD'nin tüm sözleşmelerinde en yaygın olarak tutulanlardan biridir. Sınıfların üye değişkenleri, yalnızca sınıfın tanımlayan yöntemleri tarafından bilinmelidir. Üye değişkenler, türetilmiş sınıflar da dahil olmak üzere hiçbir zaman başka bir sınıf tarafından bilinmemelidir. Bu nedenle, public ya da protected yerine private ilan edilmelidir. Açık kapalı prensibi ışığında, bu sözleşmenin nedeni açık olmalıdır. Bir sınıfın üye değişkenleri değiştiğinde, bu değişkenlere bağlı her metod değiştirilmelidir. Böylece, bir değişkene bağlı hiçbir fonksiyon, bu değişkene göre kapatılamaz.

OOD'de, bir sınıfın metodlarının, o sınıfın üye değişkenlerindeki değişikliklere kapalı olmamasını bekliyoruz. Ancak, alt sınıflar da dahil olmak üzere diğer sınıfların bu değişkenlerdeki değişikliklere karşı kapalı olmasını bekliyoruz. Bu beklenti için bir ismimiz var, buna encapsulation (kapsülleme) diyoruz. Peki ya asla değişmeyeceğini bildiğiniz bir üye değişkeniniz olsaydı? Özel yapmak için herhangi bir neden var mı? Örneğin, Liste 7'de bool durum değişkeni olan bir sınıf Device gösterilmektedir. Bu değişken son işlemin durumunu içerir. Bu işlem başarılı olursa, durum true, aksi halde false olur.

Listing 7
non-const public variable
class Device
{
 public:
 bool status;
};

Bu değişkenin türü veya anlamının asla değişmeyeceğini biliyoruz. Öyleyse neden herkese açık hale getirmiyor ve istemci kodunun içeriğini incelemesine izin vermiyoruz? Bu değişken gerçekten hiç değişmezse ve diğer tüm istemciler kurallara uyarsa ve yalnızca durumun içeriğini sorgularsa, değişkenin herkese açık olması hiçbir zarar vermez. Bununla birlikte, bir istemci bile status değişkenin yazılabilir doğasından yararlanırsa ve değerini değiştirirse ne olacağını düşünün. Aniden, bu bir istemci diğer tüm istemcileri etkileyebilir. Bu, herhangi bir Device istemcisini bu hatalı davranış modülündeki değişikliklere karşı kapatmanın imkansız olduğu anlamına gelir. Bu muhtemelen alınamayacak kadar büyük bir risktir.


Öte yandan, Liste 8'de gösterildiği gibi Time sınıfına sahip olduğumuzu varsayalım. Bu sınıftaki public üye değişkenlerin verdiği zarar nedir? Elbette değişmeleri pek olası değildir. Ayrıca, istemci modüllerinden herhangi birinin değişkenlerde değişiklik yapması önemli değildir, değişkenlerin istemciler tarafından değiştirilmesi gerekir. Ayrıca, türetilmiş bir sınıfın belirli bir üye değişkenin ayarını değiştirmek istemesi pek olası değildir. Peki bu durumun herhangi bir zarar var mı?


Listing 8
class Time
{
 public:
 int hours, minutes, seconds;
 Time& operator-=(int seconds);
 Time& operator+=(int seconds);
 bool operator< (const Time&);
 bool operator> (const Time&);
 bool operator==(const Time&);
 bool operator!=(const Time&);
};

Liste 8 ile ilgili yapabileceğim bir şikayet, zamanın değiştirilmesinin atomik olmamasıdır. Yani, istemci hours değişkenini hours değişkenini değiştirmeden değiştirebilir. Bu bir Time nesnesi için tutarsız değerlere neden olabilir. Üç argüman alıp zamanı atomik olarak ayarlayan tek bir fonksiyonu tercih ederdim. Fakat bu çok zayıf bir argüman.


Bu değişkenlerin public doğasının bazı sorunlara neden olduğu diğer koşulları düşünmek zor olmayacaktır. Bununla birlikte, uzun vadede, bu değişkenleri private yapmak için baskın bir neden yoktur. Hala public hale getirmenin kötü bir tarzı olduğunu düşünüyorum, ancak muhtemelen kötü bir tasarım değil. Kötü tarz olarak görüyorum çünkü uygun satır içi üye moetdları oluşturmak çok ucuz ve ucuz maliyet kesinlikle kapama sorunlarının ortaya çıkması riskine karşı korumaya değer.

Bu nedenle, açık-kapalı prensibinin ihlal edilmediği nadir durumlarda, public ve protected değişkenlerin yasaklanması, sağlamlılıktan ziyade stile bağlıdır.

No Global Variables -- Ever.
(Hiçbir zaman için Global Değişken kullanılmamalı)

Global değişkenlere karşı argüman, public değişkenlere karşı olan argümana benzer. Global değişkene bağlı hiçbir modül, bu değişkene yazabilecek diğer modüllere karşı kapatılamaz. Değişkeni diğer modüllerin beklemediği şekilde kullanan herhangi bir modül, diğer modülleri kıracaktır. Birçok modülün kötü davranmış bir modülün kaprisine maruz kalması çok risklidir.

Diğer taraftan, global bir değişkenin çok az bağımlısı olduğu veya tutarsız bir şekilde kullanılamadığı durumlarda, diğer moduller çok az zarar verirler. Tasarımcı, bir global için ne kadar kapatmanın feda edildiğini değerlendirmeli ve global değişken tarafından sunulan kolaylığın maliyete değip değmediğini belirlemelidir.

Yine, ortaya çıkan stil sorunları var. Globalleri kullanmanın alternatifleri genellikle çok ucuzdur. Bu gibi durumlarda, böyle bir risk taşımayan yöntemlere karşı çok az miktarda kapanma riski taşıyan bir teknik kullanmak kötü bir stildir. Bununla birlikte, global bir rahatlığın önemli olduğu durumlar vardır. Global değişkenler için cout ve cin yaygın örneklerdir. Bu gibi durumlarda, açık-kapalı prensibi ihlal edilmezse, kolaylık stil ihlaline değebilir.


RTTI is Dangerous.
(RTTI tehlikelidir)

Bir diğer çok yaygın yasak, dynamic_cast'e karşıdır. Genellikle dynamic_cast veya herhangi bir run time türü tanımlamasının (RTTI) kendiliğinden tehlikeli olduğu ve bundan kaçınılması gerektiği iddia edilir. Genellikle atıfta bulunulan durum, açık-kapalı prensibini açıkça ihlal eden Liste 9'a benzer. Ancak Liste 10, dynamic_cast kullanan ancak açık-kapalı ilkesini ihlal etmeyen benzer bir programı gösterir.

Bu ikisi arasındaki fark, yeni bir Shape türü elde edildiğinde  Liste 9'un değiştirilmesi gerektiğidir. (Sadece düpedüz saçma olduğunu söylememe gerek yok). Ancak, yeni bir Shape alt sınıfı oluşturulduğunda Liste 10'da hiçbir şey değişmez. Bu nedenle, Liste 10 açık-kapalı prensibini ihlal etmez. Genel bir kural olarak, RTTI kullanımı açık-kapalı prensibini ihlal etmiyorsa, güvenlidir.

Listing 9
RTTI violating the open-closed principle.
class Shape {};
class Square : public Shape
{
 private:
 Point itsTopLeft;
 double itsSide;
 friend DrawSquare(Square*);
};
class Circle : public Shape
{
 private:
 Point itsCenter;
 double itsRadius;
 friend DrawCircle(Circle*);
};
void DrawAllShapes(Set& ss)
{
 for (Iteratori(ss); i; i++)
 {
 Circle* c = dynamic_cast(*i);
 Square* s = dynamic_cast(*i);
 if (c)
 DrawCircle(c);
 else if (s)
 DrawSquare(s);
 }
}
Listing 10
RTTI that does not violate the open-closed Principle.
class Shape
{
 public:
 virtual void Draw() cont = 0;
};
class Square : public Shape
{
 // as expected.
};
void DrawSquaresOnly(Set& ss)
{
 for (Iteratori(ss); i; i++)
 {
 Square* s = dynamic_cast(*i);
 if (s)
 s->Draw();
 }
}

SONUÇ

Açık-kapalı prensibi hakkında söylenebilecek çok şey var. Birçok yönden bu ilke nesne yönelimli tasarımın merkezindedir. Bu prensibe uygunluk, nesne yönelimli teknoloji için talep edilen en büyük faydaları mevcuttur; ör: tekrar kullanılabilirlik ve sürdürülebilirlik. Ancak bu ilkeye uyum basitçe nesne yönelimli bir programlama dili kullanılarak elde edilemez. Aksine, tasarımcının, değişikliğe tabi olacağını düşündüğü programlara soyutlama uygulaması için bir özveri gerekmektedir.








Bonus :




0 yorum: