DonanımHaber

design pattern etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
design pattern etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

Software Architecture (SOLID) & Design Patterns in Java - Udemy - İnglizce - Holczer Balazs - Udemy

 Holczer Balzacs'ın SOLID ve Design Patternlerı kısa ve yeterince açıklayıcı şekilde, Java kodlarıyla anlattığı kursa buradan ulaşabilirsiniz.




Software Architecture (SOLID) & Design Patterns in Java





understand SOLID principles
understand the core of design patterns
undertand object oriented design
understand the single responsibility principle
understand the open / closed principle
understand the Liskov substitution principle
understand the interface segregation principle
understand the dependency inversion principle
understand creational design patterns (singleton pattern, factory pattern, builder pattern and prototype pattern)
understand behavioral design patterns (strategy pattern, command pattern, visitor pattern and template pattern)
understand structural design patterns (adapter pattern, facade pattern and decorator pattern)

(GRASP) Genel Sorumluluk Atama Yazılım Kalıpları (veya Prensipleri), Wikipedia Çevirisi

Merhaba, bu yazımda sizlere bilgisayar bilimcisi Craig Larman tarafından Applying UML and Patterns kitabında yayınladığı GRASP prensiplerinin Wikipedia'da yayınlanan halinin Türkçe çevirisini yapacağım. Umarım faydalı bir yazı olur.



GRASP(General Responsibility Assignment Software Patterns (or Principles))

Genel Sorumluluk Atama Yazılım Kalıpları (veya Prensipleri), kısaltılmış haliyle GRSAP, nesneye yönelik tasarımdaki sınıflara ve nesnelere sorumluluk atamak için kurallardan oluşur. SOLID tasarım prensibi ile ilgili değildir.

GRASP'ta kullanılan farklı pattern ve prensipler controller, creator, indirection, information expert, high cohesion, low coupling, polymorphism, protected variations, ve pure fabrication'dır. Tüm bu modeller bazı yazılım problemlerini cevaplar ve bu problemler hemen hemen her yazılım geliştirme projesinde ortaktır. Bu teknikler yeni çalışma yolları yaratmak için değil, nesne yönelimli tasarımda eski, denenmiş ve test edilmiş programlama ilkelerini daha iyi belgelemek ve standartlaştırmak için icat edilmiştir.

Bilgisayar bilimcisi Craig Larman, "yazılım geliştirme için kritik tasarım aracının tasarım ilkeleri konusunda iyi eğitimli bir zihin olduğunu, UML veya başka bir teknoloji olmadığını" belirtiyor. Böylece, GRASP gerçekten zihinsel bir araç seti, nesne yönelimli yazılımın tasarımında yardımcı olacak bir öğrenme yardımcısıdır.

PATTERNS
(Yazılım Desenleri)

OO tasarımında, yazılım deseni, yeni bağlamlarda uygulanabilecek bir sorunun ve çözümün adlandırılmış bir tanımıdır; ideal olarak bir yazılım deseni, çözümünün değişen koşullarda nasıl uygulanacağı konusunda tavsiyede bulunur ve engelleri ve değişimleri dikkate alır. Belirli bir sorun kategorisi verilen birçok desen, nesnelere sorumlulukların atanmasına rehberlik eder.

Controller
(Denetleyici)

Controller pattern, genel sistemi veya bir kullanım senaryosunu temsil eden UI olmayan bir sınıfa sistem olaylarıyla ilgilenme sorumluluğunu atar. Controller nesnesi, bir sistem olayını almak veya işlemekten sorumlu olan kullanıcısız bir arabirim nesnesidir.

Bir kullanım senaryosunun tüm sistem olaylarıyla ilgilenmek için bir veya birden fazla kullanım senaryosu controller'ı kullanılmalıdır. Örneğin, Kullanıcı Yarat ve Kullanıcıyı Sil gibi durumlarda, iki ayrı kullanım senaryosu denetleyicisi yerine UserController adlı tek bir sınıf bulunabilir.

Controller, bir UI katmanının gerisinde bir sistem olayını alan ve koordine eden ("kontrol eden") ilk nesne olarak tanımlanır. Controller, yapılması gereken işi başka nesnelere devretmelidir; etkinliği koordine eder veya kontrol eder. Çok fazla iş yapmamalıdır.  GRASP Controller'ın , bir bilgi sistemi mantıksal mimarisinde ortak katmanları olan nesne yönelimli bir sistemdeki uygulama / hizmet katmanının (uygulamanın uygulama / hizmet katmanı ve etki alanı katmanı arasında açık bir ayrım yaptığını varsayarak) bir parçası olduğu düşünülebilir.


Creator
(Yaratıcı)

Ayrıca bakınız: Factory Pattern

Nesnelerin oluşturulması, nesne yönelimli bir sistemdeki en yaygın etkinliklerden biridir. Hangi sınıfın nesnelerin yaratılmasından sorumlu olduğu, belirli sınıfların nesneleri arasındaki ilişkinin temel bir özelliğidir.

Genel olarak, B sınıfı aşağıdakilerden biri veya tercihen daha fazlası geçerli olduğunda A sınıfı örnekleri oluşturmaktan sorumlu olmalıdır:

-B'nin nesneleri , A nesnelerini içerir ya da bir araya getirir.
-B'nin nesneleri, A'nın nesnelerini kaydeder
-B'nin nesneleri, A nesnelerini yakından kullanır.
-B nesneleri, A nesneleri için başlangıç bilgisine sahiptir ve onu yaratıma aktarır.


Indirection
(Dolaylı)

Indirection pattern, ara elemanlara arabuluculuk sorumluluğunu atayarak iki eleman arasındaki düşük bağlantı ve yeniden kullanım potansiyelini destekler. Buna bir örnek MVC pattern'ında veriler(model) ile verilerin gösterimin sağlayan(view) arasında aracılık yapan controllerlar'dır. Bu, aralarındaki bağların düşük kalmasını sağlar.


Information Expert
(Bilgi Uzmanı)

Ayrıca bakınız: Information Hiding

Information Expert (aynı zamanda uzman ya da uzman ilkesi), metodlar, hesaplanan field'lar vb. Gibi sorumlulukların nereye delege edileceğini belirlemek için kullanılan bir ilkedir.

Information Expert prensibini kullanarak, sorumlulukların atanmasına yönelik genel bir yaklaşım, verilen bir sorumluluğa bakmak, yerine getirmek için gerekli bilgileri belirlemek ve daha sonra bu bilgilerin nerede saklandığını belirlemektir.

Bu, sorumluluğu yerine getirmek için gereken en fazla bilgi ile ilgili sınıfa yerleştirmeyi sağlayacaktır.

High Cohession
(Yüksek Uyum)

Yüksek uyum, nesneleri uygun şekilde odaklanmış, yönetilebilir ve anlaşılır tutmaya çalışan bir değerlendirme örüntüsüdür. Yüksek kohezyon genellikle düşük bağlantıyı desteklemek için kullanılır. Yüksek uyum, belirli bir öğenin sorumluluklarının güçlü bir şekilde ilişkili ve yüksek derecede odaklanmış olduğu anlamına gelir. Programları sınıflara ve alt sistemlere bölmek, sistemin tutarlı özelliklerini artıran etkinliklere bir örnektir. Alternatif olarak, düşük uyum, belirli bir elementin çok fazla ilgisiz sorumluluğa sahip olduğu bir durumdur. Düşük kohezyona sahip elementler genellikle kavranması, tekrar kullanılması, bakımı ve değiştirilmesi zor olmaktan muzdariptir.

Low coupling

(Düşük Bağlantı)

Coupling, bir elemanın diğer elemanlara ne kadar güçlü bir şekilde bağlandığını, bilgisine sahip olduğunu veya bunlara dayandığını gösterir. Düşük bağlantı, aşağıdaki faydalar için sorumlulukların nasıl atanacağını belirleyen bir değerlendirme modelidir:

sınıflar arasında daha düşük bağımlılık,
bir sınıfta diğer sınıflar üzerinde daha az etkisi olan değişim,
daha yüksek yeniden kullanım potansiyeli.

Polymorphism
Ayrıca Bakınız : Nesneye yönelik programlamada polimorfizm

Polimorfizm ilkesine göre, davranışa göre davranış çeşitliliğini tanımlama sorumluluğu bu değişimin gerçekleştiği alt türe verilir. Bu, polimorfik işlemler kullanılarak elde edilir. Türün kullanıcısı, türe dayalı dallanmalar yerine polimorfik işlemleri kullanmalıdır.

Protected variations
(Korumalı Varyasyonlar)

Korumalı varyasyon modeli, kararsızlığın odağını bir arayüzle sararak ve bu arayüzün çeşitli uygulamalarını oluşturmak için polimorfizm kullanarak elemanları diğer elemanlardaki (nesneler, sistemler, alt sistemler) varyasyonlardan korur.

Pure Fabrication

Bir pure fabrication sınıfı, özellikle düşük bağlantı, yüksek uyum ve türetilmiş yeniden kullanım potansiyeline (bilgi uzmanı modeli tarafından sunulan bir çözüm sunmadığında) ulaşmak için özel olarak oluşturulmuş, problem alanında bir kavramı temsil etmeyen bir sınıftır. Bu tür sınıfa, domain driven design'da  "service" adı verilir.




Facade (Cephe) Design Pattern

TDK'ya göre cephe : Bir şeyin veya yapının ön tarafta bulunan bölümü Facade design pattern alt sistemlerden oluşmuş bir sistemde kullanıcının (client)'ın bu alt sistemleri bilmeden herbirini yalnız başına veya ortak olarak kullanabileceği arayüzü sağlar. Bir örnekle açıklayalım. Bir bilgisayar ram, hdd, cpu gibi alt sistemlerden oluşur. Bir bilgisayarı başlattığımız zaman bu alt sistemleri harekete geçirirp belli işlemleri yerine getirmesini bekleriz. Fakat kullanıcı bu alt sistemleri tek tek harekete geçirmek yerine kasada var olan start tuşuyla bu alt sistemlerin sırasıyla hepsinin harekete geçmesini bekler. Client bunların sırasını ve neler yaptığını pek bilmek istemez. Burada kasa'ya facade sınıfı diyebiliriz. Kod olarak gösterecek olursak.




/* Facade */

class ComputerFacade {
    private CPU processor;
    private Memory ram;
    private HardDrive hd;

    public ComputerFacade() {
        this.processor = new CPU();
        this.ram = new Memory();
        this.hd = new HardDrive();
    }

    public void start() {
        processor.freeze();
        ram.load(BOOT_ADDRESS, hd.read(BOOT_SECTOR, SECTOR_SIZE));
        processor.jump(BOOT_ADDRESS);
        processor.execute();
    }
}

/* Client */

class You {
    public static void main(String[] args) {
        ComputerFacade computer = new ComputerFacade();
        computer.start();
    }
}
Alt sistemler kendi başlarına sırayla çalışabildiği gibi, birbirleri ile etkileşim halinde olup belli işleri yerine de getirebilirler.

Rastgele İçerik

© tüm hakları saklıdır
made with by templateszoo