Skip to content

Commit

Permalink
OOP Principles TR translation
Browse files Browse the repository at this point in the history
  • Loading branch information
yunusolcar committed Mar 6, 2024
1 parent caafe5e commit 453f220
Showing 1 changed file with 36 additions and 32 deletions.
Original file line number Diff line number Diff line change
@@ -1,28 +1,32 @@
### Introduction
---
title: 'OOP Prensipleri'
---

By this point, you will have learned and had a chance to practice the most common object-creation and organization patterns in JavaScript. But that is just the _tip_ of the iceberg. More important than learning the syntax for factory functions or modules is figuring out how to use them effectively.
### Giriş

This whole series of lessons has been about the "Object Oriented Programming" paradigm (OOP). The basics of creating objects and classes are relatively straightforward. But it is not straightforward to decide what to put in each object, or when to make a new object, or when to let an object 'inherit' from another one.
Bu noktaya kadar, JavaScript'teki en yaygın nesne oluşturma ve düzenleme modellerini öğrenmiş ve uygulama şansı bulmuş olacaksınız. Ancak bu sadece buzdağının görünen kısmıdır. Nesne üretici fonksiyonları(factory functions) ya da modüller için sözdizimini öğrenmekten daha önemlisi, bunları nasıl etkili bir şekilde kullanacağınızı bulmaktır.

### Lesson overview
Tüm bu ders dizisi "Nesne Yönelimli Programlama" paradigması (OOP) ile ilgilidir. Nesneler ve sınıflar yaratmanın temelleri nispeten basittir. Ancak her bir nesneye ne koyacağınıza, ne zaman yeni bir nesne oluşturacağınıza ya da bir nesnenin başka bir nesneden ne zaman 'miras' alacağına karar vermek kolay değildir.

This section contains a general overview of topics that you will learn in this lesson.
### Derse Genel Bakış

- Explain the "Single Responsibility Principle".
- Briefly explain the additional SOLID principles.
- Explain what "tightly coupled" objects are and why we want to avoid them.
Bu bölüm, bu derste öğreneceğiniz konuların genel bir özetini içerir.

Luckily there are several concepts and principles that can guide us into making good decisions when it comes to our objects. This lesson is an introduction to the most important of those concepts. Keep in mind that there is not usually a very clear answer to your application design questions. Some patterns and ideas are obviously better than others, but there is often some trade-off when deciding where to put a specific function. In other words... these principles are not _rules_- they're helpful guidelines.  
- "Tek Sorumluluk İlkesi" ni açıklayınız.
- Ek SOLID ilkelerini kısaca açıklayınız.
- "Sıkı bağlı" nesnelerin ne olduğunu ve neden bunlardan kaçınmak istediğimizi açıklayın.

As you read these resources, it might help to go back to some projects you've already done and think about how what you've written measures up to the examples you see. And of course, as you move on, keep these things in mind when crafting new projects.
Neyse ki, nesnelerimiz söz konusu olduğunda iyi kararlar vermemize rehberlik edebilecek birkaç kavram ve ilke vardır. Bu ders, bu kavramların en önemlilerine bir giriş niteliğindedir. Uygulama tasarımı sorularınıza genellikle çok net bir yanıt olmadığını unutmayın. Bazı kalıplar ve fikirlerin diğerlerinden daha iyi olduğu açıktır, ancak belirli bir işlevi nereye koyacağınıza karar verirken genellikle bazı takaslar söz konusudur. Başka bir deyişle... bu ilkeler _kural_ değildir - yardımcı kılavuzlardır.

### Single responsibility
Bu kaynakları okurken, daha önce yaptığınız bazı projelere geri dönmek ve yazdıklarınızın gördüğünüz örneklerle ne kadar örtüştüğünü düşünmek size yardımcı olabilir. Ve tabii ki, yolunuza devam ederken, yeni projeler hazırlarken bunları aklınızda tutun.

As you craft your objects, one of the most important things to remember is the __Single Responsibility Principle__ which states that a class (or object or module... you get the point) should only have _one_ responsibility. This doesn't mean that an object can only do one thing, but it does mean that everything an object does should be part of one responsibility.
### Tek sorumluluk

Here's a really common example. Most of our code has functions to update and write things to the DOM in addition to our application logic. It's a _really_ good idea to separate your DOM stuff from the application logic.
Nesnelerinizi oluştururken, hatırlamanız gereken en önemli şeylerden biri, bir sınıfın (veya nesnenin veya modülün... anladınız siz onu) yalnızca _bir_ sorumluluğu olması gerektiğini belirten __Tek Sorumluluk İlkesi__'dir. Bu, bir nesnenin yalnızca bir şey yapabileceği anlamına gelmez, ancak bir nesnenin yaptığı her şeyin tek bir sorumluluğun parçası olması gerektiği anlamına gelir.

Here we have a function that should check if a game over condition has been met. There are two issues with this:
İşte gerçekten yaygın bir örnek. Kodumuzun çoğunda, uygulama mantığımıza ek olarak DOM'u güncellemek ve DOM'a bir şeyler yazmak için işlevler bulunur. DOM işlerinizi uygulama mantığından ayırmak _gerçekten_ iyi bir fikirdir.

Burada, bir oyun bitti koşulunun karşılanıp karşılanmadığını kontrol etmesi gereken bir fonksiyonumuz var. Bununla ilgili iki sorun var:

```javascript
function isGameOver() {
Expand All @@ -38,7 +42,7 @@ function isGameOver() {
}
```

The first issue is that the function (and the module it's in) should not directly be the one to manipulate the DOM. You should extract all the DOM manipulation into its own module and use it like so:
İlk sorun, fonksiyonun (ve içinde bulunduğu modülün) doğrudan DOM'u manipüle etmemesi gerektiğidir. Tüm DOM manipülasyonunu kendi modülüne çıkarmalı ve bu şekilde kullanmalısınız:

```javascript
function isGameOver() {
Expand All @@ -51,44 +55,44 @@ function isGameOver() {
}
```

The second issue remaining is that the `isGameOver` function should only be responsible for checking if the `gameOver` condition is met. Based on `isGameOver` return value, the function that handles the game loop should be responsible for deciding whether to call `DOMStuff.gameOver(this.winner)` or not.
Geriye kalan ikinci sorun ise `isGameOver` fonksiyonunun yalnızca `gameOver` koşulunun karşılanıp karşılanmadığını kontrol etmekten sorumlu olması gerektiğidir. isGameOver` dönüş değerine bağlı olarak, oyun döngüsünü yöneten fonksiyon `DOMStuff.gameOver(this.winner)` çağrısının yapılıp yapılmayacağına karar vermekten sorumlu olmalıdır.

Another way to think about the Single Responsibility Principle is that a given method/class/component should have a single reason to change. Otherwise, if an object is trying to have multiple responsibilities, changing one aspect might affect another.
Tek Sorumluluk İlkesi hakkında düşünmenin bir başka yolu da, belirli bir yöntemin/sınıfın/bileşenin değiştirilmesi için tek bir neden olması gerektiğidir. Aksi takdirde, bir nesne birden fazla sorumluluğa sahip olmaya çalışıyorsa, bir özelliğin değiştirilmesi diğerini etkileyebilir.

The Single Responsibility Principle is the first of a commonly found set of 5 design principles called the __SOLID__ principles. You will read more about these principles in the assignment articles below.
Tek Sorumluluk İlkesi, yaygın olarak bulunan ve __SOLID__ ilkeleri olarak adlandırılan 5 tasarım ilkesinden ilkidir. Bu ilkeler hakkında daha fazlasını aşağıdaki ödev makalelerinde okuyacaksınız.


### Loosely coupled objects
### Gevşek bağlı nesneler(Loosely coupled objects)

Obviously, all of our objects are intended to work together to form our final application. You should take care, however, to make sure that your individual objects can stand alone as much as possible. __Tightly coupled__ objects are objects that rely so heavily on each other that removing or changing one will mean that you have to completely change another one - a real bummer.
Açıkçası, tüm nesnelerimizin nihai uygulamamızı oluşturmak için birlikte çalışması amaçlanmıştır. Bununla birlikte, tek tek nesnelerinizin mümkün olduğunca tek başına durabilmesine dikkat etmelisiniz. Birbirine __sıkı sıkıya bağlı__ nesneler birbirlerine o kadar çok bağlı nesnelerdir ki birini kaldırmak ya da değiştirmek diğerini de tamamen değiştirmek zorunda kalmanıza neden olur.

This one is related pretty strongly to 'Single Responsibility' but takes a different angle. As an example, if we were writing a game and wanted to completely change how the User Interface worked, we should be able to do that without completely reworking the game logic. So we should be able to start off writing our game using primarily `console.log()`s and then add in a bunch of `DOM` functions later without touching the game logic.
Bu, 'Tek Sorumluluk' ile oldukça yakından ilişkilidir ancak farklı bir açıdan ele alınmaktadır. Örnek olarak, bir oyun yazıyor olsaydık ve Kullanıcı Arayüzünün nasıl çalıştığını tamamen değiştirmek isteseydik, bunu oyun mantığını tamamen yeniden işlemeden yapabilmeliydik. Yani oyunumuzu yazmaya öncelikle `console.log()` kullanarak başlayabilmeli ve daha sonra oyun mantığına dokunmadan bir grup `DOM` fonksiyonu ekleyebilmeliyiz.


### Assignment
### Ödev

<div class="lesson-content__panel" markdown="1">

1. The following article mentions the acronym __SOLID__ before going on to talk about Single Responsibility. Single Responsibility is definitely the most relevant of the 5. Feel free to dig into the rest of the SOLID principles if you like, but pay special attention to Single Responsibility.
1. Aşağıdaki makale Tek Sorumluluk hakkında konuşmaya başlamadan önce __SOLID__ kısaltmasından bahsetmektedir. Tek Sorumluluk kesinlikle 5 ilke arasında en alakalı olanıdır. İsterseniz SOLID ilkelerinin geri kalanını incelemekten çekinmeyin, ancak Tek Sorumluluğa özellikle dikkat edin.
1. [SOLID principle #1: Single responsibility (JavaScript)](https://duncan-mcardle.medium.com/solid-principle-1-single-responsibility-javascript-5d9ce2c6f4a5) has links to other very brief articles that cover the rest of 'SOLID'. They're optional, but recommended nonetheless. __Note__: this article riffs off what the SOLID videos in the next link goes in-depth on.
2. Watch [The SOLID Design Principles by WDS](https://www.youtube.com/playlist?list=PLZlA0Gpn_vH9kocFX7R7BAe_CvvOCO_p9) to see code examples for each principle.
2. [How to Write Highly Scalable and Maintainable JavaScript: Coupling](https://web.archive.org/web/20200810210808/https://medium.com/@alexcastrounis/how-to-write-highly-scalable-and-maintainable-javascript-coupling-c860787dbdd4) explains loosely coupled objects pretty well.
2. Her bir ilkeye ilişkin kod örneklerini görmek için [The SOLID Design Principles by WDS](https://www.youtube.com/playlist?list=PLZlA0Gpn_vH9kocFX7R7BAe_CvvOCO_p9) adresini izleyin.
2. [How to Write Highly Scalable and Maintainable JavaScript: Coupling](https://web.archive.org/web/20200810210808/https://medium.com/@alexcastrounis/how-to-write-highly-scalable-and-maintainable-javascript-coupling-c860787dbdd4) gevşek bağlı nesneleri oldukça iyi açıklıyor.
</div>

### Knowledge check
### Bilgi ölçme

This section contains questions for you to check your understanding of this lesson. If you’re having trouble answering the questions below on your own, review the material above to find the answer.
Bu bölüm, bu dersi anladığınızı kontrol etmeniz için sorular içermektedir. Aşağıdaki soruları kendi başınıza yanıtlamakta zorlanıyorsanız, yanıtı bulmak için yukarıdaki materyali gözden geçirin.

- [Explain the "Single Responsibility Principle".](#single-responsibility)
- [Briefly explain the additional SOLID principles.](https://medium.com/@cramirez92/s-o-l-i-d-the-first-5-priciples-of-object-oriented-design-with-javascript-790f6ac9b9fa)
- [Explain what "tightly coupled" objects are and why we want to avoid them.](https://web.archive.org/web/20200810210808/https://medium.com/@alexcastrounis/how-to-write-highly-scalable-and-maintainable-javascript-coupling-c860787dbdd4)

### Additional resources
### Ek kaynaklar

This section contains helpful links to other content. It isn't required, so consider it supplemental.
Bu alanda içerikle alakalı faydalı linkler bulunmaktadır. Zorunlu değildir, ek olarak düşünülmelidir.

- The best book we've ever read on the subject of loose coupling is [Practical Object-Oriented Design In Ruby](http://www.poodr.com/). Unfortunately, it is not free... and not JavaScript. We feel confident in recommending it anyway. If you don't know Ruby, it is a clear enough language that you don't really need to learn it to follow the examples and the content of the book is sincerely fantastic. Alternatively, [99 Bottles of OOP](https://sandimetz.com/products) is written in both JavaScript and Ruby. It is written by the same author and may be a better option if you are brand new to OOP (it is not free either).
- Gevşek bağlantı konusunda şimdiye kadar okuduğumuz en iyi kitap [Practical Object-Oriented Design In Ruby](http://www.poodr.com/). Ne yazık ki ücretsiz değil... ve JavaScript de değil. Yine de tavsiye etmekte kendimize güveniyoruz. Ruby bilmiyorsanız, örnekleri takip etmek için öğrenmenize gerek kalmayacak kadar açık bir dildir ve kitabın içeriği gerçekten harikadır. Alternatif olarak, [99 Bottles of OOP](https://sandimetz.com/products) hem JavaScript hem de Ruby dilinde yazılmıştır. Aynı yazar tarafından yazılmıştır ve OOP konusunda yeniyseniz daha iyi bir seçenek olabilir (ücretsiz de değildir).

- [Building a house from the inside out](https://www.ayweb.dev/blog/building-a-house-from-the-inside-out) will walk you through the process of separating your core logic and DOM logic.
- [Building a house from the inside out](https://www.ayweb.dev/blog/building-a-house-from-the-inside-out) temel mantığınızı ve DOM mantığınızı ayırma sürecinde size yol gösterecektir.

- This [brief video by Coderized](https://www.youtube.com/watch?v=q1qKv5TBaOA) covers the SOLID programming principles and more, within the context of embracing clean coding practices and establishing a maintainable code structure. You may find it helpful if you are still confused about why these principles exist and how they can work together to improve your code, code architecture, and your skills as a programmer!
- Coderized tarafından hazırlanan bu [brief video by Coderized](https://www.youtube.com/watch?v=q1qKv5TBaOA), temiz kodlama uygulamalarını benimseme ve sürdürülebilir bir kod yapısı oluşturma bağlamında SOLID programlama ilkelerini ve daha fazlasını kapsamaktadır. Bu ilkelerin neden var olduğu ve kodunuzu, kod mimarinizi ve bir programcı olarak becerilerinizi geliştirmek için birlikte nasıl çalışabilecekleri konusunda hala kafanız karışıksa, bunu yararlı bulabilirsiniz!

0 comments on commit 453f220

Please sign in to comment.