Merhaba arkadaşlar. Bu yazımda Java Serialization (Serileştirme) konusuna değineceğim.

Bir klişe olacak ama Java bilindiği üzerine nesneye yönelik bir dil. Primitive tipler (int, char, boolean … gibi) hariç neredeyse herşey nesne ve bu nesneleri sürekli ve sürekli kullanırız. Ancak nesneleri bazen JVM dışında kullanmak gerekebiliyor. Fakat dışarıda kullandığımız bir nesnemizi tekrar içeride kullanmak istediğimizde nesne içinde kullanılan değerlerin hangi tipte olduğunu öğrenemiyoruz. Yani herhangi bir sınıftan bir nesne üretip, bunu bir dosyaya yazdırıp onu tekrar dosyadan okuduğumuzda değerlerin tip bilgisini bilememe problemimiz var. İşte tam bu durumda Java Serialization API yardımımıza koşuyor.

Bu durumu basit bir örnekle anlatarak durumun daha iyi pekişeceğine inanıyorum.

Araba bilgilerini tutan Car diye bir sınıfımız olsun ve bu bilgileri bir dosyaya kaydedip, tekrar okuma işlemi yapalım.

Serileştirme işlemi için Serializable arayüzünü implement etmek gerekiyor.

Araba sınıfımız

Nesnemizi dosyaya yazdırdığımız test sınıfımız

Nesnemizi dosyaya yazdığımız zaman dosyamızın çıktısı şu şekilde.

¨ÌsrCarÇ«5xÕçLbrandtLjava/lang/String;Lmodelq~xptSeattLeon

Şimdi gelin bu nesneyi dosyadan tekrar okuyalım.

Çıktımız :

Marka : Seat Model : Leon

 

Görüldüğü gibi dosyaya yazdırdığımız nesneyi tekrar okuyup, başarılı bir şekilde konsolumuza yazdırabildik.

Lütfen yorumlarınızı esirgemeyiniz. Bir dahaki yazımda görüşmek üzere, hoşçakalın.

Merhaba arkadaşlar, bu yazımda özellikle web uygulamalarımızda oldukça sık kullandığımız REST (Representational State Transfer) mimarisinden bahsetmek istiyorum.

REST mimamisi HTTP üzerinde çalışan bir yapıya sahiptir. Diğer mimarilere göre daha basit ve hızlı olduğunu söyleyebiliriz. Sunucu ve istemci arasında verileri JSON yada XML formatında taşıyarak uygulamaların birbirleriyle haberleşebilmelerini sağlar. REST mimarisi ile uyumlu olan servislere RESTful servisler denmektedir.

REST mimarisi stateless  olup, herhangi bir durum bilgisi saklamaz. Dolayısıyla istemci-sunucu arasında taşınan verilerde istemciye ait herhangi bir veri bulunmaz.

REST mimarisini diğer bir popüler olan SOAP mimarisiyle karşılaştırırsak şunları rahatlıkla söyleyebiliriz.

  • SOAP servisleri RPC (Remote Process Call) yöntemini kullanır. Güvenlik protokollerini içinde barındırır, state bilgisini request ve response larda tutar. Fakat bu durum REST mimarisinde daha farklıdır. RESTful servislere direkt bir URL üzerinden erişilir. Arada herhangi bir güvenlik protokolü, bileşen vs… yoktur.
  • SOAP olan bir servisi kullanabilmeniz için servisin WSDL bilgisine ihtiyaç duyarsınız. Proxy sınıfları ve bileşenler gerekmektedir. Kısaca bir istemci SOAP ile ilgili neredeyse tüm detayları bilmek zorundadır. Aksi halde bu servisi istemcinin kullanması mümkün değildir. REST mimarisinde ise herhangi bir servisi çağırmak için sadece URL bilgisini bilmeniz yeterlidir. Kısaca bir istemcinin REST mimarisine ait bir servisin yapısını ve detaylarını bilmesine gerek yoktur. Son derece esnek bir yapıya sahiptir.

RESTful servisleri üzerinden CRUD (Create, Read, Update, Delete) işlemlerinin gerçekleştirilebilmesi için HTTP metotları kullanılır. Popüler olan HTTP metotları şunlardır;

  • GET (okuma işlemleri için)
  • POST (kayıt ekleme işlemleri için)
  • PUT (güncelleme işlemleri için)
  • DELETE (silme işlemleri için)

REST mimarisinin basit yapısı, kolay uygulanabilmesi, hızlı çalışması gibi olumlu özellikleri olsa da önemli bir dezavantajı vardır. Bunlardan biri güvenlikle ilgilidir. SOAP REST mimarisine göre güvenlik konusunda kendi standartları gereği daha avantajlıdır. Fakat REST mimarisinde güvenlik konusu işin geri kalan kısmıdır.

Lütfen yorumlarınızı esirgemeyiniz. Bir dahaki yazımda görüşmek üzere, sevgiyle kalın..

 

 

Merhaba arkadaşlar. Bu yazımda Java 8 ile birlikte hayatımıza giren en önemli özelliklerden biri olan Optional sınıfını anlatmak istiyorum.

Bu sınıf; null referanslar yerine isteğe bağlı değerleri göstermek için iyi bir çözüm sunmaktadır.

Optional sınıfı  java.util paketine aittir.

import java.util.Optional;

Şimdi basitçe bir optional nesnesi nasıl oluşturulur ona bakalım.

Optional empty = Optional.empty();

Yukarıda gördüğünüz üzere basitçe Optional sınıfının empty() metodunu kullanarak boş bir Optional nesnesi oluşturmuş olduk.

Bir Optional nesnesi üzerinde herhangi bir değer olup, olmadığını nasıl kontrol ediyoruz ona bakalım.

empty.isPresent()

Yukarıdaki blokta olduğu gibi isPresent() metodunu kullanarak herhangi bir Optional nesnesi üzerinde bir değer olup, olmadığını kontrol edebiliriz. Sonuç olarak üzerinde henüz herhangi bir değer olmadığı için bize false dönecektir.

Ayrıca Optional tipinde olmayan bir nesneyi Optional tipine çevirebilmemiz mümkün.

String name = "The Coders"; 
Optional<String> var = Optional.of(name);

Fakat bazı durumlarda null olan nesnelere de bu işlemi uygulayabilmemiz gerekiyor. Bunun için Optional.ofNullable() metodunu kullanabiliriz. Aksi halde NullPointerException hatasıyla karşılaşabiliriz.

String name = null; 
Optional<String> var = Optional.ofNullable(name);

Optional sınıfının en önemli özelliklerinden biri de ifPresent metodudur. Bu metod; Optional nesnesinin üzerinde herhangi bir değer tutulduğu zaman istenilen işlemlerin yapılmasına olanak sağlar.

String name = "The Coders"; 
Optional<String> var = Optional.ofNullable(name); 
var.ifPresent(v -> System.out::println);

Bazen Optional nesnesi üzerinde herhangi bir değerin tutulup, tutulmadığının kontrolü yapılırken tutulmadığı durumdaki senaryoları tasarlayabilmemiz gerekiyor. Bunun için Optional sınıfının bize sunduğu çözümlere bakalım. Bunlar; orElse(), orElseGet(), orElseThrow()

orElse() kullanımı

Eğer Optional nesnesi üzerinde herhangi bir değer tanımlı değilse bu durumda istediğimiz değeri dönebiliriz.

String name = null; 
Optional\<String\> optionalName = Optional.ofNullable(name); 
String result = optionalName.orElse("The Coders");

orElseGet() kullanımı

orElseGet(); orElse() metoduna benzerdir. Eğer Optional nesnesi üzerinde herhangi bir değer tanımlı değilse bu durumda istediğimiz değeri orElse() deki gibi direk dönmek yerine functional interface kullanabiliriz.

String name = null; 
Optional<String> optionalName = Optional.ofNullable(name); 
String result = optionalName.orElseGet(() -> "The Coders");

orElseThrow() kullanımı

Eğer Optional nesnesi üzerinde herhangi bir değer tanımlı değilse bu durumda hata fırlatabiliriz.

String name = null; 
Optional<String> optionalName = Optional.ofNullable(name); 
String result = optionalName.orElseThrow(IllegalArgumentException::new);

Optional nesnesi içindeki değeri almak için kullanılan diğer bir yöntem ise get() metodudur.

Optional<String> optionalName = Optional.ofNullable("The Coders"); 
String name = optionalName.get();

Fakat bu yöntemin bir dezavantajı vardır. Eğer Optional nesnesi üzerinde herhangi bir değer yoksa ve direkt olarak get() metodunu kullanırsak NoSuchElementException() hatasını alırız.

Lütfen yorumlarınızı esirgemeyiniz. Bir dahaki yazımda görüşmek üzere, hoşçakalın.

Merhaba arkadaşlar. Bu yazımda size DI (Dependency Injection) kavramından kısaca en basit haliyle bahsetmek istiyorum.

DI (Dependency Injection), IoC (Inversion of Control)’un en önemli implementasyonlarından biridir. Peki IoC (Inversion of Control) neydi, bunu bir hatırlayalım. IoC (Inversion of Control); uygulamamızda nesne oluşturma işinin geliştiriciden alınarak ilgili çatının sorumluluğuna devredilmesidir.

SOLID prensiplerindeki son harfi temsil etmektedir.

Uygulama katmanımızda bir A sınıfı olsun ve bu A sınıfımızın bir üyesi başka bir sınıf olan B sınıfına ait olsun. Bu ilişkiyi A sınıfımızın içinde new operatörü ile yaptığımızı düşünelim. Böylece A sınıfımız, B sınıfımızın özelliklerine ve davranışlarına daha ortada hiçbirşey yokken bağlı hale getirmiş olduk. Peki bu istenilen bir durum mu, tabiki hayır. İşte DI (Dependency Injection) kavramı burada devreye giriyor. Bu prensip sayesinde nesne atamalarını çatımızın sorumluluğuna bırakıyoruz ve bunu bizim yerimize sadece gerektiği durumlarda atamaları gerçekleştirerek dinamik hale getiriyor. Bunu başka bir cümleyle açıklamak gerekirse; uygulamamızın çalışırken o an kullanması gereken nesneler çatı tarafından enjekte edilecektir. Böylece sonraki süreçlerde herhangi bir düzenleme yada değişiklik olması durumunda sadece belirli kısımların değiştirilmesi yeterli olacaktır.

Şimdi bu prensibi artılarıyla ve eksileriyle beraber değenlendirelim.

Artıları

  • Uygulamamızı oluşturan yapılan birbirleri ile bağımlılıkları azaldığı için uygulamamızda değişiklik yapmak daha kolay hale gelmesi. (Bunu  loosely coupled  olarak da tanımlıyabiliriz.)
  •  Çok rahat bir şekilde Unit testler yazmamızı sağlayabilmesi. İstediğimiz sınıfı rahatlıkla mock edip, kolayca test edebilmemiz.

Eksileri

  • Oluşturduğumuz sınıf sayısının fazla olması
  • Gereksiz interface lerin fazlalığı

Lütfen yorumlarınızı esirgemeyiniz :) Bir sonraki yazımda görüşmek üzere, hoşçakalın.

Merhaba arkadaşlar. Bu yazımda oldukça popüler ve işlevi büyük olan Builder tasarım deseninden bahsetmek istiyorum.

Yapı olarak farklı olsa da Abstract Factory desenine benzerlikleri vardır.

Bazen projelerimizde nesnelerimize ait birçok özellik olabilir ve bu nesnelerimizi farklı farklı özellikler ile oluşturmak isteriz. Dolayısıyla bazen çalıştığımız sınıflar içerisinde çok fazla parametre alan metodlar ve yapılandırıcılar kullanabiliyoruz. Bu kullanılabilirliği ve okunabilirliği oldukça zorlaştıran bir durum. Bazen aynı methodu çok fazla kez overload edip, kendimize iş yükü doğurabiliyoruz. İşte bu kısımda yardımımıza Builder Design Pattern yetişiyor.

Şimdi bu konuyu daha iyi anlamak adına basit kod parçacıklarını paylaşalım.

Nesne sınıfımız

Builder sınıfımız

Test sınıfımız

İşte bir yazının daha sonuna geldik, lütfen yorumunuzu esirgemeyin :) Bir sonraki yazımda görüşmek üzere, hoşçakalın..