In this tutorial, you’ll find out how to deal with multiple datasources in your Spring Boot project.

I published an example project with two datasources (PostgreSQL and MSSQL) on Github => It’s here!

I will code an example with EntityManagerFactory and a transaction query (an insert operation) in the next tutorial.

1. Add the secondary datasource’s connection information to application.properties.

2)Create two packages for each datasource that has nested packages named “model”, “repository”, “controller”, “dbconfig” .

You have already know what include entity, controller and repository packages. Therefore we can skip to dbconfig package. Spring Boot automatically create the datasource bean for us thanks to spring-boot-starter-data-jpa. In this case we will create our own configuration classes.(One for PostgreSQL and one for MSSQL)

There are three part basically in this configuration.

As the name suggests DataSource builder create a datasource. We mark one of our databases config as @Primary. We will do the same for LocalContainerEntityManagerFactory and PlatformTransactionManager.

We can easily set up a shared JPA EntityManagerFactory in application context. The EntityManagerFactory can be passed to our repository by this way. I will code an example with EntityManagerFactory and a transaction query in the next tutorial.

Then, you should create an another @Configuration class for other data source. The same things will set up for secondary data source. But there is no @Primary annotation.

You can examine other packages from github repository. Actually there is no big differences from a Spring project that has got one data source. Therefore, I will not explain their includes.

Thanks for reading…

Let’s start with a simpler question. How to pass data as parameters from one React component to the other? As you guessed, we can send our data from one to the other via props. They flow one way in React => from parent to child…

If data needed to be sent from parent to grandchild (Child B), you can use prop drilling, even though it’s not recommended. Actually, the reason why not recommended prop drilling is the component that don’t need the props have to has the props.

By the way, you can use a better alternative: useContext. It would make sense to use useContext especially if there is more than one level.

Anyway, let’s get to the point. So far, we talk about to one way flows. What if i wanted to pass data from child component to the parent? It sounds weird, doesn’t it? I was very surprised when i hear it can be possible. This can be better illustrated with an example.

1) Firstly, let’s create our components.

2) Import the child component in the parent component.

3) Pass event (sendData) as props to Child component.

4) Assign sendData to onClick event in Child component.

5) Then, define a state in the parent component.

6) Define a method (callBackFunction) in the parent component. This method set the data using the useState.

This was a simple example of how to send data from the child to the parent component.

I hope you find this article is helpful…

Now let’s put Spring aside and think. Why do we need frameworks? Is it possible to build a website without any frameworks? Of course, it is possible but there would be too many codes. Because although your application is unique, it has common issues like database connectivity, authentication, or logger like all other applications. In other words, we can produce a solution for every need without using frameworks. However, these solutions also covered the common needs of each project. If so, let’s keep in mind the fact that frameworks increase development speed. We will come back to the topic of speed later.

Let’s downcasting and come to the world of Java from frameworks. Perhaps the first suggested solution for the common needs I just said was Java EE (Jakarta EE). It also pursued solutions to similar problems. How do we ensure security, cache, scalability, and performance… However, it was not easy to create such an inclusive structure. Therefore, various mistakes made it difficult to use (like EJBs). One of the developers who had trouble with these difficulties was Rod Johnson. His goal was to make what Java EE offers simpler way. It’s also faster, as we just talked about.

I am aware that we still haven’t answered the question in the title. So let’s talk a little bit about that. Let’s imagine a typical Java application. There are classes, classes have fields and behaviors, and classes have relationships with each other. “Is a” and “Has a” can be given as examples of relationship types that express this network.

In addition, objects can be dependent on each other. Assume that two classes that use each other. Most likely if there is a modification on one object have to require modification on the other. This relationship is called dependency. We can say that this is the most fundamental issue that Spring aims to produce a solution to: Dependency Injection.

To be honest, earlier in my career, I thought dependency is a bad thing. But in the world of our application, objects must communicate with each other. When some objects throw an error, someone has to catch it. Some classes must provide an instance for other objects to use. Dependency is a natural process of software. We will not try to escape from dependency, we will manage them well. How to better manage them will not be answered in this article. Still, we have a few things to say.

Firstly, the dependency type I’m mentioning here is the “usage” type. I mean the object of class A is needed in another class. Like this:

Although this code sample is very short, it has a huge mistake. There is no need to create an instance of the supplier in the customer to be able to use the supplier. The client should not be responsible for creating the object that it will use. It is enough to know the interface of the supplier. “Program to an interface, not an implementation…”

Anyway, there are even better ways to solve this. Better yet, Spring does it for us.

In brief, when a Spring application ran, Spring doesn’t just create objects. It adds dependencies to the project with XML configurations or annotations (like @Autowired). It creates objects, it manages dependencies, it throws exceptions, it initiates transactions… In this way, we do not have to do dependency management.

Happy coding …

Two different memory spaces are used in runtime by programming languages. Heap is used to creating an object by JVM. It is also known as “dynamic memory”. Instance variables are located in the heap while local variables are located in the stack. I still haven’t mentioned primitive types or complex types. Because data types don’t matter when discussing this issue.

There is a general belief that primitive types are in the stack, and complex types are in the heap. But this isn’t a correct belief because object variables are stored in heap regardless of their types.

Firstly, stack memory contains values that specific to methods. Therefore, these values’ lifetime is ended as soon as their method finishes running. When a method is called, space is allocated for this method in the stack. Let’s think about our Java application… Which is the first method called when Java executes a program? As you guessed, it is the main method. In that case, the stack starts to fill up with the main method. Then the other method calls take their place in the stack with their local variables.

Secondly, when a new object is created, this object is stored in the heap. The reference of that object is in the stack.

In short, methods, local variables, and reference variables of the objects stored in the stack. Objects and instance variables (regardless of their types) are stored in the heap. Garbage Collector removes the object that has no reference from the heap.

Let’s understand with the help of an example.

Both the midtermGrade and the passingGrade are also primitive types. But midtermGrade is stored in the heap because it is an instance variable. passingGrade is a local variable and it is stored in the stack. As you can see the data type is not related to where the object will be stored.

Looking at the last two lines, there is no variable pointing to the first created student object. This means that the garbage collector will collect the first student object.

I hope it works for you, happy coding…

Inheritance is an important part of OOP. It allows to use fields and behaviors of the parent class when the child class extends from parent class. Therefore reuse is possible thanks to inheritance.
We can also add new fields and methods to child class while inheriting parent class’s fields and behaviors. This usage is an instance of “is-a relationship”. Because child class also is a parent class.

Let’s say Employee is parent class of Programmer class. Programmer class can inherit all the properties and behaviors, this means that programmers are a type of employee. In addition, there can be new fields and methods that make a programmer a programmer.

What makes a programmer a programmer?

Getting a salary? Well, it seems as if behavior of getting a salary is common for all employees. In that case, there is no need to define this method for each class. The method of getSalary() already is inherited from Employee class. But behavior of writeCode() is special for the programmer. Therefore we have to describe writeCode’s implementation in programmer class.

There are three types of inheritance that can be used in Java: single, multilevel and hierarchical. Single inheritance is define that a class inherits another class. Single’s example is that relation of between the programmer and the employee class. Let’s assume in this example employee inherits person class. Also in this situation, we can talk about a chain of inheritance. Secondly, relation of between programmer and person classes are called “multilevel inheritance”. And for the third kind of the inheritance let’s say there is a new class that has a name: “Psychologist”, both of child classes (Psychologist and Programmer) inherits Employee. That means this relation is hierarchical inheritance.

We cannot use multiple inheritance in Java. For instance, Programmer can’t inherit also Manager while inheriting Employee. But we can implement multiple interfaces.

Embedded Id oluşturmak için öncelikle id’ye karşılık gelecek olan fieldlardan oluşan bir class oluşturulması gerekiyor. Bu classımızın özelliği ise elbette Embeddable olması olacak.

Örneğin elimizde öğretmenlerin bilgilerinin tutulduğu bir teacher tablosu olsun. Tabloda region id, grade id, school id, class id, name, lastname ve birthyear kolonları mevcut. Region id, grade id, school id, class id alanlarından oluşan bir composite id olduğunu da varsayalım. Bunu entity katmanına taşımak için öncelikle dört alandan oluşan bir class oluşturacağız. Daha sonra bu class, teacher classının içine id fieldı olarak gömülecek.

Öncelikle tablo yapısını inceleyelim.

Teacher classında kullanmak için oluşturduğumuz Embeddable class (Id classı):

Göze çarpan ifadelerden ilki @Embeddable anotasyonu, bir diğeri ise classımızın Serializable interfacesinin kullanılması. Embeddable anotasyonu adından da belli olduğu gibi ilgili classın farklı bir class içine gömülebilir bir yapıda olduğunu belirtmekteyken Serializable interfacesi ise oluşturulan nesnenin ihtiyaç halinde tekrar tekrar kullanılabilmesine olanak sağlamaktadır.

Embeddable class oluşturulduktan sonra @Embedded anotasyonu ile istediğimiz yere yerleştirebiliriz. Örnekte hedefimiz Embedded Id oluşturmak olduğu için Embeddable classı gömeceğimiz classın içinde id fieldının anotasyonu @EmbeddedId şeklinde olacak.

Teacher classı:

Böylece veritabanında PK tanımlansın ya da tanımlanmasın biz JPA’nın işine yarayacak bir id fieldı oluşturmuş oluyoruz. Ancak bunu yapmadan önce Java Persistence’da da önerildiği gibi eğer veritabanına müdahale şansımız varsa önceliğimiz gerçekten de bir PK alanı oluşturmak olmalıdır.

JSON çıktısında da id alanını oluşturan fieldlar aşağıdaki şekilde bir arada gösterilir.

Tahmin ettiğiniz gibi Embeddable Class sadece Embedded Id oluşturmak için kullanılmıyor. Birden çok yerde tekrar eden kolonları bu şekilde gömülebilir hale getirip, birden çok kez kullanabiliriz. Örneğin on farklı kullanıcı tipinin olduğu bir senaryo düşünelim. On kullanıcı için on ayrı tablo kurgulanmış olsun ve hepsinde de adres bilgilerinin tutulduğu üç kolon tekrar ediyor. (Burada normalizasyon kurallarına bağlı kalınarak adres tablosunun ayrı tutulması gerektiği ve one to many ilişkisinin kurulması gerekliliği göz ardı edilmiştir. Bu senaryoda da elinizde ideal şekilde kurgulanmamış ve müdahale edemediğiniz bir tablo olduğunu düşünün.) Her classta adres bilgilerini tekrarlamaktansa bir defa Embeddable bir class oluşturarak onu tekrar tekrar kullanabiliriz. Üstelik birden fazla satır yazmak yerine tek satırda adres bilgilerini tanımlamış oluyoruz.

Ayrıca birden çok kolonu PK olarak tanımlama (Composite Primary Key) konusunda @IdClass anotasyonunun kullanımına da bakabilirsiniz.

Programlamaya yeni başlayanlar için Nesne Yönelimli Programlama (Object-Oriented Programming (OOP)) mantığının, class, inheritance, encapsulation gibi temel kavramların oldukça kafa karıştırıcı olabildiğinin farkındayım. En azından benim için durum böyleydi bu yüzden ben de anlatabildiğim en yalın haliyle bu konuları anlatmak istedim. Bu yazıda programlama yaklaşımlarını, nesne yönelimli programlamanın felsefesini ve dört temel kavramının açıklamasını bulacaksın.

Programlamanın kelime anlamına baktığımızda bir problemin çözümüne ilişkin komutlar, kelimeler, matematiksel işlemlerin bilgisayara tanıtılması gibi bir karşılık buluruz. Bu noktada matematik öğretmenlerimizin “bir problemin tek bir çözümü olmak zorunda değil, birden fazla çözüm olabilir” öğretisini hatırlamanızı istiyorum. Çünkü tıpkı matematikteki gibi yazılım geliştirmede de karşılaştığımız bu problemlerin birden çok çözüm yöntemi genellikle vardır ve biz bu yöntemler arasından en iyisini seçmeye çalışırız. Burada kastedilen en iyi elbette bizim en sevdiğimiz, en gözümüze hoş gelen anlamında değildir. O işin çözümü için en optimize yol, en doğru yaklaşım hangisiyse ve hangi programlama dili uygunsa en iyi de odur. Bunların OOP ile ilgisi yok gibi görünebilir ama konuya buradan girmeyi tercih etmemin sebebi Java, C, C#, Dart gibi birbirine alternatif olan programlama dilleri olduğu gibi OOP’nin de alternatifi olan yaklaşımların mevcut olduğunu anlatmak.

OOP her ne kadar şu an en fazla kullanılan yaklaşımlardan biri olsa da programlama için kullanılan tek yaklaşım değildir. Fonksiyonel programlama, prosedürel programlama, mantıksal programlama gibi farklı yaklaşımlar da mevcuttur. Örneğin prosedürel programlamanın amacı problemi parçalara bölmek daha sonra da adım adım bu parçaları birleştirmektir. Bu mantığı kullanan dillere örnek olarak C verilebilir. Bu noktada programlamaya benim gibi Deitel’in C kitabındaki örneklerle başlayanlar ne demeye çalıştığımı hemen anlayacaktır. O örneklerde neler yaptığımızı kısaca hatırlamakta fayda var. Örneğin sayfa 193, 5.26 numaralı örneği inceleyelim.

5.26 Eğer bir sayının kendisi hariç, bütün çarpanlarının toplamı yine o sayıya eşitse bu sayıya MÜKEMMEL SAYI denir. Örneğin, 6 bir mükemmel sayıdır. Çünkü 6 = 1 + 2 + 3. mukemmel isminde, sayi parametresinin mükemmel bir sayı olup olmadığını tespit eden bir fonksiyon yazınız. Bu fonksiyonu 1–1000 arasındaki tamsayılardan mükemmel olanlarını bulmak için bir program içinde kullanınız. Program sayının mükemmel olduğunu göstermek için mükemmel sayınının çarpanlarını ekrana yazdırsın. 1000‘den daha büyük sayıları test ederek bilgisayarınızın gücünü deneyebilirsiniz.

Şimdi bu problemi prosedürel programlamaya göre nasıl çözdüğümüze odaklanalım:

1) Araştırdığımız şey 1000’e kadar olan sayılar arasında bir mükemmel sayı varsa onu bulmak. Haliyle ilk adımda 1’den 1000’e kadar olan tüm sayıları gezen bir döngü kurmalıyız.

2) Tüm sayıları gezme kısmını döngü ile çözmüş gibi görünüyoruz. Peki bu sayıların çarpanlarının toplamlarının, sayının kendisine eşit olup olmadığının kontrolünü nasıl sağlayacağız? İşte bu noktada bir döngüye daha ihtiyacımız var. İkinci yani içteki döngümüz yine 1’den başlayacak ama bu sefer kontrol edilen sayının bir eksiğine kadar artması gerekecek ve bu sayılar kontrol ettiğimiz sayının bir çarpanı mı bunu tespit edecek. Çarpanları bulduktan sonra ise tüm çarpanları toplayarak toplam isimli bir değişkene atayacağız.

3) Üçüncü adıma geldiğimizde ise toplam isimli değişkenimiz ve kontrol ettiğimiz sayı birbirlerine eşit mi bunun kontrolünü sağlayacağız. Eğer eşitse bu sayıyı ekrana yazdırabiliriz çünkü sayı mükemmeldir. Eşitlik yoksa sayı mükemmel değil demektir.

4) Son adımda ise dıştaki döngü her yeni sayıya geçerken çarpanların toplamını sıfıra eşitleyeceğiz.

Gördüğünüz gibi mükemmel sayıyı bulan programı yazmak için adım adım ilerlenecek bir yol haritası çıkardık ve kodlarımızı da gerçekten bu adımlara uygun şekilde yazdık. Ya da fonksiyonel programlamaya baktığımızda programlamanın matematiksel fonksiyonlar şeklinde ele alındığını, yazılan her satırın fonksiyon tanımlar gibi olduğunu görürüz. Burada hedef yan etkileri azaltmak yani fonksiyonun her seferinde aynı şekilde çalıştığından emin olmaktır, veriler değişmez olarak kabul edilir. Esnek bir yapının olmayışı ilk bakışta dezavantaj gibi görünüyor olsa da big data ile çalışıyorsanız fonksiyonel programlama oldukça iyidir.

Bu örnekler uzatılabilir, farklı yaklaşımlarla programlanmış projeleri sizler de inceleyebilirsiniz. Fark etmenizi istediğim şey aslında OOP’nin yazılım geliştirirken kullanılan bir felsefe olduğu. Bu felsefenin, mantalitenin amacını doğru bir şekilde anladığınızda ise o çok karıştırdığımız interface, inheritance, polymorphism kavramlarının o kadar da zor olmadığını fark ediyorsunuz. Ayrıca bu yaklaşımlardan birini tercih ettiğinizde diğerlerini asla kullanamazsınız diye bir şey de yok tabi ki. Örneğin prosedürel programlama her zaman cebimizde bulunur. İş kurallarını tanımlarken oldukça da işe yarardır. Ama tüm sistemi sadece prosedürel yaklaşımla programlamak biraz zor olacaktır. Yani gerektiği yerde gereken yaklaşımı elbette kullanacağız.

OOP özelinde konuşacak olursam bunun bir felsefe olduğundan bahsettim. Bana göre böyle bir felsefeye ihtiyaç duyulmasının sebebi ise az önce bahsettiğim esneklik kavramını OOP ile projenize çok rahat entegre edebiliyor oluşunuz. Esnek ve değiştirilebilir projeler üretmenin önemini açıklamaya gerek dahi yok diye düşünüyorum çünkü içinde bulunduğumuz çağda her şey çok hızlı değişirken, ihtiyaçlar sürekli artarken statik ve değişmez parçalardan oluşan yazılımlar geliştirmek hiç mantıklı olmayacaktır 😊

OOP bize aradığımız bu esnekliği, program içinde kullanılacak her yapıyı ayrı ayrı birer nesne olarak tasarlayarak sunar. Yani OOP mantığına göre yazılan bir programda veriye dokunan her şey bir nesnedir. Örneğin bir banka uygulamasında uygulamayı kullanacak olan banka görevlileri, müşteriler, çekler, taksitler, ödemelerin hepsi birer nesnedir. Bu nesnelerin temelde iki kısmı vardır.

· Nitelikleri (özellikler)

· Yapabildikleri (davranışlar)

Bir otomobil düşünelim. Otomobili otomobil yapan özellikler neler olabilir? Tekerlekler, motor gücü, vites tipi, yakıt tipi bu özellikler arasında sayılabilir. Bu otomobil nesnesinin yapabildiği çeşitli davranışlar da vardır. En basit ve kesin haliyle hareket etmek bu davranışlardan biridir. Otomobil nesnesini otomobil yapan şeyleri sıraladık. Bunları programlama diliyle bilgisayara anlatmamız gerektiğinde ise class yapıları bizim imdadımıza yetişiyor. Classlar ile aslında gerçek dünyadaki nesneyi bilgisayarın anlaması için tanımlamış oluyoruz.

Nesnelerin temelde iki kısmı vardır demiştik. Yaptığımız bu tanıma göre nesnemizin niteliklerine artık properties, yapabildiklerine yani davranışlarına ise metot diyeceğiz. (Java’da metot olarak tanımlanan yapılar C’de fonksiyon olarak tanımlanır. Her ikisi de aynı yapıya karşılık gelir.)

O halde OOP ile modelleme yaparken ilk çıkış noktamız classlar. Programda ihtiyaç duyacağımız her şeyi class şeklinde oluşturup şablonlarını oluşturuyoruz. Şablon oluşturuyorsak eğer oluşturduğumuz bu classlar nesnemizin mümkün olan en soyut halini karşılıyor olması gerekir. Çünkü adı üstünde oluşturduğumuz şey o nesne için bir şablon, çerçeve, o nesneyi o nesne haline getiren temel özellikler…

OOP’nin 4 özelliğinden biri olan abstraction ile classları biraz daha yakından inceleyelim.

1) Abstraction (Soyutlama)

Nesnenin en soyut hali derken aslında içinde sadece temel özelliklerinin bulunduğu bir class oluşturmaktan bahsedilir. Otomobili otomobil yapan özelliklerden az önce bahsetmiştik. Tekerlekleri, motoru olmayan ya da hareket edemeyen bir otomobil bu nesneyi karşılayamaz. Tüm otomobillerde olmasını beklediğimiz en temel özellikler bunlardır diyebiliriz. Örneğin motorları üzerinden yola çıkalım. Tüm otomobillerin motorlarında illa turbo güç modu olmak zorunda mıdır? Elbette hayır. Turbo modu olmasa da bir motora sahip olması yeterlidir. Yani propertyleri bu şekilde detaylandırmadan aklımıza gelen ilk ve temel özellikleriyle bir classı oluşturabilme abstraction özelliğiyle uyumludur ve kesinlikle uygulanması gereken bir özelliktir. Çünkü o nesneye dair oluşturduğumuz ilk class sadece bir şablondur, temel özelliklerini barındırır ve aslında gerçek hayatta da somut bir varlığa denk gelmez.

Bu noktada programlamadan biraz uzaklaşalım. Yeni bir araba aldığını söyleyen bir arkadaşınızla konuştuğunuzu hayal edin. Arkadaşınız bu haberi size “Geçen gün yeni bir araba aldım” şeklinde bildirdi. Sadece bu cümleyi duyduğunuzda hangi marka, modelde hangi özelliklere sahip bir araba aldığını bilmeniz mümkün mü? Elbette değil çünkü aslında size soyut bir classtan bahsetmiş oldu. Şu an için bildiğiniz arkadaşınızın tekerlekleri, motoru, vitesi olan ve hareket edebilen bir şeye sahip olduğu. O arabanın markasını, modelini söylediğinde ise siz o classtan hangi nesnenin üretildiğini öğrenmiş oldunuz. Yani soyut araba classını somutlaştırıp gerçek bir nesne oluşturmuş oldunuz. Örneğin arkadaşınız Ford/Fiesta aldığını belirtti. Aldığı araç manuel vites, 1.4 motor gücünde ve beyaz renk olsun. Şu anda gözünüzün önüne daha net bir görsel geliyor değil mi? Çünkü bir nesne oluşturduk ve o nesne soyut olan araba classının somut bir örneği. Farklı bir örnek daha verecek olursak bir pastaneye girdiğinizi ve satıcıya sadece “Tatlı alabilir miyim?” diye sorduğunuzu varsayın. Muhtemelen sorunuza karşılık yeni bir soru alacaksınız çünkü pastanede onlarca çeşit tatlı olabilir. Pastalar, kekler, şerbetli tatlılar, kekler, kurabiyeler… Hangisinden istediğinizin bilinmesinin mümkün olmama sebebi satıcıya sadece soyut olan classı belirtmiş olmanız. Tatlı classı pastanedeki tüm çeşitleri karşılar ama o soyut bir tanımdır. Onu göremeyiz, koklayamayız ya da ona dokunamayız. Ama havuçlu kek dediğinizde artık o soyut tanım somut hale gelmiş olur.

Ford/Fiesta ya da havuçlu kek örnekleri nasıl gerçek hayatta bir yer kaplıyorsa, classlardan oluşturduğumuz nesneler de aslında bilgisayarımızın RAM ’inde gerçekten yer kaplamaya ve haliyle yaşamaya başlıyorlar.

Bir nesneye dair oluşturduğumuz bu ilk classa (sadece araba, tatlı dediğimizde kastettiğimiz şeye) “süper class, base class ya da parent class” denmektedir. OOP bu süper classtan yeni alt classlar türetmeye izin verir. Yani classlarımız arasında bir hiyerarşi olabilir. Hatta birbirlerine miras aktarır gibi özelliklerini aktarabilirler. O halde ikinci temel özelliğimiz olan inheritance kavramına geçelim.

2) Inheritance

İstediğimiz şey en başından beri yeni ihtiyaçlar ortaya çıktığında esnekçe değişim yapabilmekti, doğru ama bu esnekliği abstraction tek başına sağlayamıyor. Süper classımız sadece temel özellikleri barındırır demiştik çünkü olası yeni ihtiyaçlara göre süper classın özelliklerini barındıran ama fazladan başka özelliklere de sahip olabilecek sınıflar üretmemiz gerekebilir. Bunu örneklemek için otomobil classımıza geri dönelim. Otomobil sınıfının temel özellikleri arasında yakıt tipi, tekerlek, motor gücü, vites tipi ve hareket etme davranışı vardı. Farz edelim ki programa yeni bir otomobil dahil edilmesi gerekiyor. Bu yeni otomobil tekerlekler, yakıt tipi, vites tipi, motor özelliklerine sahip ve hareket etme kabiliyeti de olan ancak içerisinde bir yatak ve mutfak da barındırmak zorunda olan yeni bir tür yani karavan olsun. Karavan classı otomobil classının sahip olduğu tüm property ve metotlara sahip olmakla beraber bunun fazlasına da sahiptir. Ama benim karavan classını oluştururken otomobil classına yazdığım her şeyi tekrar karavan classında da yazmam gereksiz kod tekrarına düşmem anlamına gelmektedir. Bunun yerine classların inheritance özelliğini kullanarak “Karavan da bir otomobildir” diyebiliyorum. Böylece otomobildeki tüm özellik ve metotları karavan classına da tek satırla aktarmış oluyorum. Karavan classına yazdığım şey sadece karavanın yatak ve mutfağa sahip olma özelliği olmuş oluyor.

Inheritance sayesinde bir kez tanımladığım otomobil classının özelliklerini tekrar tekrar kullanabiliyor oldum. Çünkü ekleyeceğim her yeni tür, base classın temel otomobil özelliklerini zaten miras almış oldu.

3) Encapsulation

Ekim 2022-Not: Bu bölüme olan bakış açım Akın Kaldıroğlu’ndan aldığım eğitimden sonra oldukça değişti. “Tamam da private yaptıktan sonra set metotlarıyla dışarıya tekrar açınca ne değişti ki?” diye kendi kendime sorduğum bir iki soruya gayet tatmin edici yanıtlar buldum. Bu kısmı ve polimorfizmi de en kısa zamanda güncelleyeceğim. Eski yazdıklarımı şimdilik kaldırmıyorum ancak encapsulation hiç bildiğimiz gibi değilmiş :)

Paketleme, sarmalama anlamlarına gelen encapsulation özelliği sayesinde oluşturduğumuz classları dışarıdan gelecek değişikliklere karşı korumaya almış oluyoruz. Bu korumanın önemi ise aslında en başta söylediğim “veriye dokunan her şey nesnedir” cümlesinde saklı. Nesneler hafızaları olan, içinde veri saklayan yapılardır. Ama bu veriyi kontrolsüzce sakladığımızda ya da herkesin müdahalesine açık hale getirdiğimizde programımız için hiç iyi sonuçlar doğurmayacağı da ortadadır. Otomobil classımızı hatırlayalım. Motor gücü şeklinde bir property tanımlamıştık bu property 90 hp değerini alabilir, mümkündür. Ancak -90 hp değerinde bir motor gücü tanımı istediğimiz bir şey değildir. Ya da kullanıcı tiplerini tanımladığın bir classta kişinin yaşının 320, kilosunun -45 girilebilmesine olanak tanımamalıyız.

Bu korumayı sağlamak içinse temelde iki araç kullanılır. İlki erişim belirleyici dediğimiz public, private anahtar kelimeleri. İkincisi ise “getter” ve “setter” metotları. Erişim belirleyicisi olarak public değer verdiğimiz bir yapıya programın her yerinden ulaşabiliyorken, private değer alan yapıya doğrudan erişimimiz mümkün değildir. Getter metodu ise o değerin sadece okunabilir olduğu anlamına gelirken, setter metodu sayesinde o değerde değişiklik yapabiliriz.

Ayrıca bu konu için ilk paragraftaki notu göz önünde bulundurduğumuzda şunları da eklemem gerekir. Encapsulation ile sadece teknik anlamda (get/set-access modifier) veriyi saklamanın ötesinde soyutladığımız fieldlarımızı ve davranışlarımızı ete kemiğe bürünür hale getiriyoruz. Classlar aracılığıyla ise bu sarmaladığımız şeyleri bir arada topluyoruz. Oluşturduğumuz classlar herhangi bir yerden çağrıldığında kimse içeride tam olarak ne olduğunu/neler yapıldığını bilmiyor. Sadece bir interface ile talep ettiği işi yaptırmış oluyor. Ama implementasyonu ile ilgili bilgi sahibi olamıyor ki olmamalı da zaten. İstemcinin implementasyon hakkında bilgi sahibi olması couplingi arttıracaktır.

4) Polymorphism

Inheritance sayesinde base classı miras alan ama kendine has farklı property ve metotları da olan yeni alt türler türetebildiğimizi söylemiştim. Polymorpism ile ise base classtan alınan metotun adını değiştirmeden yeni oluşturulan alt tür için o metotu modifiye edebilmekteyiz. Modifiye etmenin de override ve overload olmak üzere iki yolu vardır. Override edilmiş bir metotun içi miras alan sınıfa uygun olacak şekilde yeniden yazılmıştır. Overload edilen bir metot ise farklı parametreler kullanır.

OOP’nin dört temel özelliğini çok fazla kod karmaşasına girmeden, mantıklarını vererek açıklamaya çalıştım. Bundan sonraki yazılarda ise bu kavramların gerçek programlarda nasıl kullanıldığından bahsedeceğim.

Kaynaklar:

1. Java Tutorials. ORACLE. https://docs.oracle.com/javase/tutorial/
2. Gorsel-1 ve görsel ile ilgili sorulan “Hangi kadın daha başarılı bir programcı olur?” sorusu Marmara Üniversitesi-Bilgisayar Programcılığı Öğretim Üyesi Zehra Aysun ALTIKARDEŞ’in ders sunumlarından alınmıştır.

Bu yazıda benim için yeni bir deneyim olan Vue ile ilgili iki işlemi açıklamaya çalışacağım. Bunların ilki route işleminin nasıl yapılacağı olacak. İkinci işlem ise oluşturduğumuz bir componenti farklı bir sayfaya dahil etmekle ilgili.

Route güzergah, rota anlamına gelirken web programlama dünyası için serverlara gelen isteklerin yönlendirilmesi şeklinde düşünülebilir. Haliyle birçok teknolojide route işlemi yapılmaktadır. Örneğin ASP.NET’in routing yapısında gelen istekler Controller ile karşılanır. Ve isteğe dönülecek yanıt ya da yapılacak işlemler bu sayede belirlenmiş olur.

Vue.js’in ise route işlemi için Vue Router adında resmi bir eklentisi bulunmaktadır. Kendi sitelerinde Vue Router’ın kolaylıkla Single Page Application (SPA) oluşturabileceğinden bahsedilmiştir. SPA, Multiple Pages Application yaklaşımıyla karşılaştırıldığında bu yönlendirme işlemini JavaScript kullanarak client tarafında gerçekleştirmeyi ve böylece yeni gelen her istek için tüm sayfayı yeniden yüklememeyi hedefler.

Router kullanabilmek için yapılması gereken işlemleri sırasıyla inceleyelim. Ancak öncelikle pratik amacıyla çalıştığım proje ait kısa videoyu izlemenizi öneririm. Senaryonun somutlaşması daha kolay olacaktır. Videoya buradan ulaşabilirsin.

1. 1) Vue Router’ı kullanabilmek için öncelikle az önce bahsettiğimiz eklentiyi kurmamız gerekiyor. Bunun için terminale npm install vue-router komutunu giriyoruz.

2. Kurulum tamamlandıktan sonra package.json dosyanızın dependencies bölümünden kontrolünü sağlayabilirsiniz.

3. Diğer sayfaların içeriğini göstermeden önce her iki işlem sırasında App.vue içeriğini göstermek istiyorum. App.vue’ yi uygulamanın giriş noktası, kökü gibi düşünebilirsiniz. Aşağıda yapacağımız işlemler olurken App.vue componentinizin içinde sadece bunlar olmalıdır. Ve router-view etiketini kesinlikle buraya vermeniz gerekmektedir ki verdiğimiz routelar kendilerini sergileyecekleri bir alan bulabilsinler. Ancak bu componente başka bir sayfa import etmemeye, template kodları arasına bir şeyler yazmamaya özen gösterin yoksa benim gibi saatlerce neden App.vue’ye yazılanlar tüm sayfalarda tekrar ediyor diye düşünmek zorunda kalırsınız 😊

4. Daha sonra main.js dosyasına;

import VueRouter from ‘vue-router’

Vue.use(VueRouter) ve

new Vue({

el: ‘#app’,

render: h => h(App),

router: router

})

satırlarını ve ekliyoruz.

5. Artık VueRouter kullanıma hazır halde. Bu aşamadan sonra componentlerinizin import edilmesi ve pathlerinin verilmesi gerekmekte. Videoda gördüğümüz her bir ekran aslında kod tarafında bir componenti temsil ediyor.

Görselin sol tarafında görüldüğü gibi menüdeki her başlığa ait bir component mevcut. Main.js dosyasında ise sayfaları import edip path tanımları yapılmış. Bu işlemler için ayrı bir route.js sayfası da açabilirdiniz. Ancak benim projem çok büyük olmadığı için main.js’e eklemekle yetindim. (Dosya yolları verilirken “ ./ ” kısmı src dosyasına denk gelmekte. )

Örnek:

import Kayit from ‘./Pages/Kayit.vue’

const router = new VueRouter({

routes: [{path: ‘/kayit, component: Kayit}],

mode:’history’

})

6. Örneğimize kayıt formundan devam edelim. Kayıt formuna yönlenebilmek için link verebileceğiniz bir elementiniz olmalı. Bu noktada dikkat edersek sunucumuz ilk çalıştığında Home sayfasını açıyor. Ve sağ üst köşede ÜCRETSİZ KULLAN yazılı butona tıkladığımızda ‘localhost:8080/kayit’ sayfasına yönleniyor. O halde Home.vue componentine ilgili butonu ekleyelim. Template ve script kodları bu şekilde olmalı.

<template>

<router-link to=”/kayit” >

<b-button class=”btn-free” variant=”primary”>ÜCRETSİZ KULLAN</b-button>

</router-link>

</template>

<script>

export default {name: ‘Home’}

</script>

7. Kayit.vue componentine geldiğimizde ise script kodlarına

<script>

export default{

name: “Kayit”,

}; </script>

Satırlarını eklemelisiniz. Bu aşamadan sonra template ve style kodları ile yönlendirilecek sayfayı oluşturmaya hazırsınız.

Bu şekilde route tanımlamanızı basitçe yapabilirsiniz. Başta karmaşık gelse de aslında oldukça kolay.

Açıklanacak olan ikinci konunun component dahil etme olduğundan bahsetmiştim. Bu kavramla aslında şunu demeye çalışıyorum. Örneğin videoda her sayfada tekrarlanan bir navbar ve sidebar mevcuttu. Bazen bu şekilde tüm sayfalara dahil olması gereken alanlarımız olabilir. Bu işlem içinse yapmamız gereken şey oldukça basit. Ben bu proje için NavSide.vue isminde bir component oluşturdum. Yukarıdaki dosya dizinin görüldüğü görselde de mevcut. Bu componente sadece navbar ve sidebar alanlarını kodladım. Daha sonra ilgili componentlere NavSide.vue componentini işte şu şekilde dahil ettim. (Ancak bunu yapmadan önce NavSide’ın yine main.js’e import edildiğini ve routes kısmına dahil olduğunu unutma.)

<template>

<div><NavSide/></div>

</template>

<script>

import NavSide from “./NavSide.vue”

export default ({name: ‘Raporlar’,components: {NavSide,},})

</script>

Ve böylece navbar/sidebar alanlarını istediğiniz tüm sayfalara aktarmış oldunuz.

Umarım faydalı bir yazı olmuştur. Okuduğunuz için teşekkürler.

Kaynakça

1. Vue.js Web Sitesi, https://vuejs.org/

1. MS-SQL’i açtığında “Object Explorer” sekmesinden Database>Restore Database sekmesine tıkla.

2) Açılan ekranda default olarak Database: seçeneği seçili geliyor. Device’ı işaretle ve sağındaki üç noktaya tıkla.

3) Select backup devices ekranından Add dedikten sonra dosyanı seçeceksin. Ben direkt C’ye kopyalamıştım. O yüzden en üstteki C:’ ya bastığımda sağda çıktı. Farklı bir klasör açtıysan o klasörün içine girerek dosyanı seçmelisin.

4) Bundan sonrasında OK diyerek kurulumu başlatabilirsin. Kurulum bittiğinde başarılı bir şekilde kurulduğunu belirtiyor.

5) “Database ‘NORTHWIND’ restored successfully” bildirimini gördüysen Object Explorer’ı yenilediğinde databasein oluştuğunu göreceksin.

Sorgulara başlamadan önce soruların hepsini sırayla yazacağım. Eğer SQL ile ilgili temel düzeyde bilgin var ama pratik yapmak istiyorsan sana tavsiyem sorguları sadece gözle incelemektense önce kendin yazmaya çalışıp daha sonra benim yazdıklarımı okuman. Çünkü bu iş biraz matematik öğrenmek gibi. Soruyu önce kendin çözmeye uğraşmadan direkt cevabı incelersen “Öğretmen anlattığında anlıyorum ama kendim çözemiyorum” klasiğine düşmüş olursun. Bunu yaşamamak adına tüm sorguları kolay, zor demeden önce senin yazman çok daha etkili olacak.

1) Employees tablosundaki toplam çalışan sayısı kaçtır?

2) Ünvanı ‘Dr.’ olan kayıtları kolon adı ‘Manager’ olacak şekilde getirin.

3) Kadın çalışanları listeleyin.

4) Erkek çalışanları listeleyin.

5) Kaç kadın çalışan vardır?

6) Çalışanların kaç farklı şehri var?

7) Adresinde ‘House’ ifadesi geçen çalışanları listeleyin.

8) Extension değeri 3 haneli olan çalışanların ad, soyad ve extension kolonlarını listeleyin.

9) Çalışanların yaşlarını listeleyin.

10) Ürünlerin isimlerini, fiyatlarını ve KDV’li fiyatlarını listeleyin.

11) KDV’si 10 liradan düşük olan ürünleri listeleyin.

12) En pahalı beş ürünü ürün fiyatına göre listeleyin.

13) En ucuz beş ürünün fiyat ortalaması nedir?

14) Stok sayısı 20’den çok 50’den az olan ürünleri listeleyin.

15) En pahalı ürünün adı nedir?

16) Kaç farklı çeşit kategori tipi var?

17) Ülkelere ait müşteri sayısı nedir?

18) Kategorilere ait ürün sayısı nedir?

19) Her çalışanın yaptığı satış miktarını listeleyin. (3 Tablo joinlemeye ihtiyacın var)

20) Her bir siparişin işletmeye getirdiği kazancı listeleyin. (Bir siparişte satılan ürünün fiyatı 10 TL ve satış adedi 15 adet ise toplam kazanç 10 * 15 = 150 TL olacaktır)

21) 50’den fazla satış yapan çalışanları listeleyin.

22) Müşteri adı en uzun olan müşteriyi ve adının karakter sayısını listeleyin.

23) Hangi üründen kaç adet satılmış?

24) Ortalama fiyatın altında kalan ürünler hangileridir?

25) Kategori adı ‘Beverages’ olan ürünleri listeleyin.

1. Employees tablosundaki toplam çalışan sayısı kaçtır?

2. Ünvanı ‘Dr.’ olan kayıtları kolon adı ‘Manager’ olacak şekilde getirin.

3. Kadın çalışanları listeleyin.

4. Erkek çalışanları listeleyin.

5. Kaç kadın çalışan vardır?

6. Çalışanların kaç farklı şehri vardır?

7. Adresinde ‘House’ ifadesi geçen çalışanları listeleyin.

8. Extension değeri 3 haneli olan çalışanların ad, soyad ve extension kolonlarını listeleyin.

9. Çalışanların yaşlarını listeleyin.

10. Ürünlerin isimlerini, fiyatlarını ve KDV’li fiyatlarını listeleyin.

11. KDV’si 10 liradan düşük olan ürünleri listeleyin.

12. En pahalı beş ürünü ürün fiyatına göre listeleyin.

13. En ucuz beş ürünün fiyat ortalaması nedir?

14. Stok sayısı 20’den çok 50’den az olan ürünleri listeleyin.

15. En pahalı ürünün adı nedir?

16. Kaç farklı çeşit kategori tipi var?

17. Ülkelere ait müşteri sayısı nedir?

18. Kategorilere ait ürün sayısı nedir?

19. Her çalışanın yaptığı satış miktarını listeleyin.

20. Her bir siparişin işletmeye getirdiği kazancı listeleyin. (Bir siparişte satılan ürünün fiyatı 10 TL ve satış adedi 15 adet ise toplam kazanç 10 * 15 = 150 TL olacaktır)

21. 50’den fazla satış yapan çalışanları listeleyin.

22. Müşteri adı en uzun olan müşteriyi ve adının karakter sayısını listeleyin.

23. Hangi üründen kaç adet satılmış?

24. Ortalama fiyatın altında kalan ürünler hangileridir?

25. Kategori adı ‘Beverages’ olan ürünleri listeleyin.

Kaynaklar:

1. SQL Server’da Northwind Sorgusu Örnekleri. Yavuz Selim KART. https://www.youtube.com/watch?v=kOI4n4j7uuw&list=PLiXHPMfTR_eXNzDaOwMnz0i9jAUXjzsjh

Normalizasyon kurallarına göre bir veritabanı kurgulamaya çalışırken ilk hedefimiz tekrarlı verilerin önüne geçmek. Tekrarlı verinin ne olduğunu bir tablo üzerinden inceleyelim.

Tabloyu incelediğimizde ders seçimi yapan öğrencilerin ad-soyad, bölüm, sınıf ve seçtikleri ders bilgilerini görüyoruz. İlk bakışta göze çarpan sıkıntı ise Tesla’nın birden fazla ders seçmesi sonucu ilk üç kolonun gereksiz tekrar etmesi. İki değil de 10 ders seçmiş olsaydı bu bilgileri on kez mi tekrarlayacaktık? İşte ilk hedefimiz bu tarz tekrarları engellemek. Böylece veritabanının fiziksel maliyetini de azaltmış olacağız.

Tekrarları ortadan kaldırdıktan sonra ikinci aşamada iyi yapılandırılmış ilişkiler kurmayı hedefliyoruz. Aslında elindeki tüm bilgileri bir tabloya yazıp yanlış da olsa sadece bir tablo ile işini görebilirsin. İlk tabloda tekrarlı veriler olsa da kimin hangi dersi aldığını görebiliyorsun. Tekrarların ya da hem öğrenci bilgilerinin hem ders bilgilerinin tek tabloda olmasının kimseye bir zararı yok gibi görünüyor. O halde şöyle bir senaryodaki veri kaybımızı düşün. Freud aniden “Analitik Psikoloji” dersini almaktan vazgeçiyor. Bu durumda Freud’un olduğu satırın silinmesi gerekmekte çünkü bu bilgiye artık ihtiyacımız yok. Ancak o satırı sildiğimizde sadece öğrenciye ait bilgileri değil ders bilgisini de silmiş olacağız. Sonuç olarak o ders gerçekten verilmiyor mu yoksa tercih eden kimse mi olmadı sorularının cevaplarına asla ulaşamayacağız. Bu gibi problemlere “Veritabanı Anomalileri” deniyor. Ve Freud’un senaryosu bir “Silme Anomalisi” örneğidir. Benzer olarak ekleme ve güncelleme anomalileri de var ve hepsi kolonlar arası ilişkilerin iyi yapılandırılmamış olmasından kaynaklanıyor.

Bu sorunların önüne geçmek içinse normalizasyon kurallarına uygun tablolar kurgulamak gerekiyor. Normal form isimleri şu şekilde;

1. 1.Normal Form
2. 2.Normal Form
3. 3.Normal Form
4. Boyce-Codd Normal Form
5. 4.Normal Form
6. 5.Normal Form

BİRİNCİ NORMAL FORM

Tablo incelendiğinde müşteri bilgileri ve ürün bilgilerinin tutulduğunu görüyoruz. Birinci normal forma göre hücreler içinde sadece bir veri tutulmalıdır. Yani virgülle ayırarak yazmış olduğumuz Urun kolonundaki veriler ilk sorunumuz. Ayrıca Sirket ve SirketTel kolonlarındaki “İkisi de” ifadesinin de hatalı olduğu son derece açık çünkü ilerleyen zamanlarda veritabanına yeni şirketler eklense elimizde sadece “Hangi ikisi?” sorusu kalacak. Son olarak her bir satırı tek başına tanımlayabilecek eşsiz bir kolonun da olmadığını görüyoruz. O halde bu üç kurala uyarak tablomuzu ilk normal forma uygun hale getirelim.

İKİNCİ NORMAL FORM

Tabloyu ikinci normal forma uygun hale getirmek için öncelikle birinci normal forma uyuyor olması gerekiyor ki tablomuz son haliyle buna uygun. Bu aşamaya kadar tekrarları engellemiş, tabloya bir adet Primary Key (PK) atamıştık. Şimdiyse tablodaki kolonları mantıksal olarak gruplandıracağız. Bu gruplandırma için tablodaki her kolonun PK (MusteriID) ile ilişkisi olması gerekiyor. Bu durumda tabloya döndüğümüzde MusteriAdi ve MusteriAdresi kolonlarının doğrudan müşteriyle ilişkili olduğu ve MusteriID’ye göbekten bağlı olduğu görülüyor. Ancak Urun, Sirket, SirketTel ve Fiyat kolonlarının bir müşteri tanımıyla ilgisi yoktur. Bu da bize tablonun ikiye bölünmesi gerektiğini ve tabloların birinde müşteri bilgilerinin, ötekisinde ise ürün bilgilerinin tutulması gerektiğini söylüyor.

ÜÇÜNCÜ NORMAL FORM

Üçüncü normal forma geldiğimizdeyse incelenmesi gereken nokta tabloda gerçekten de sadece bir tane PK olabilecek kolonun olması. Önce müşteriler tablosuna bakalım. MusteriID kolonu, MusteriAdi ve MusteriAdresi kolonlarını tek başına tanımlayabilecek özellikte. Yani her müşterinin MusteriID’si o müşteriye özel olduğu için -Tıpkı T.C. Kimlik Numarası gibi- MusteriID kolonunu ayırt edici kolon yani PK olarak kullanabiliriz. Müşteriler tablosunda üçüncü normal form için yanlış bir durum yok gibi görünüyor. Öte yandan Ürünler tablosuna baktığımızda UrunId kolonunun tıpkı MusteriID gibi her bir ürünü tek başına tanımlayabileceğini görüyoruz ancak Sirket ve SirketTel kolonları arasında garip bir ilişki söz konusu. Şöyle ki eğer şirketin ismini biliyorsak telefon numarasına ya da numarayı biliyorsak şirket ismine ulaşabiliyoruz. Bu durumda tabloda UrunId’ye ihtiyaç duymadan birbirini tanımlayabilen kolonlarımız olmuş oluyor. Oysa tablomuzda yalnızca bir adet PK olmalıydı. Bu şartı yerine getirebilmek için ürünler tablomuzu da bölmemiz gerekiyor. Sirket ve SirketTel kolonlarından oluşan ayrı bir şirketler tablosu veritabanımızı üçüncü normal forma uygun hale getirecek. Bu tabloyu oluşturduktan sonra ise Ürünler tablosundan SirketTel kolonunu sileceğiz çünkü bu bilgi şirketler tablosunda tutuluyor olacak. İhtiyaç dahilinde join işlemi yaparak telefon numarası bilgisine erişebiliriz.

Sonuç olarak elimizde üç adet tablomuz oldu. Bunu yaparken ilk tablodaki kolonları mantıksal olarak gruplandırdık. Yeni oluşan her tabloya bir adet PK atadık. Verilerin tekrarını engelledik.

Umarım anlaşılır bir yazı olmuştur. Düzeltilmesi gereken noktalar varsa yorumlarda bildirmeniz beni çok mutlu eder.

Kaynaklar

1. Şadi Evren ŞEKER. Veri Tabanları Eğitim Serisi. https://www.youtube.com/watch?v=pHKZw5EyTi4&list=PLh9ECzBB8tJOS7WQKdeUaAa5fmPLYAouD
2. Geeks For Geeks. Normal Forms in DBMS. https://www.geeksforgeeks.org/normal-forms-in-dbms/
3. M.Mutlu YAPICI. Veritabanı ve Yönetim Sistemleri. https://acikders.ankara.edu.tr/pluginfile.php/59400/mod_resource/content/0/Veritaban%C4%B1%20ve%20Y%C3%B6netim%20Sistemleri%20Sunum%202.pdf