Hocam emeğinize sağlık. Sürekli araştırıp bi türlü kavrayamadığım dependency injectionı çok derli toplu sunmuşsunuz. İzlediğim en faydalı unity anlatımlarından biriydi. İlk projemde deneyeceğim 🙂
Singleton deseninin en büyük sorunu bence metodlara doğrudan erişim sağlanabilmesi. Projede birden fazla developer çalıştığında kimin neye ulaşabileceğini yönetmek zorlaşıyor. Dependency inversion prensibini ihlal etmek kolaylaşıyor. Referanslar üzerinden bir mimari kurulduğunda ise metodlara erişim için araya yeni bir katman koymuş oluyoruz ve developerın şu soruyu sormasını zorunlu tutmuş oluyoruz: Buna erişmeme gerçekten gerek var mı? Elbette singleton da kurallara uymaya azami özen gösterdiğimizde bir sorun teşkil etmez bu açıdan.
Hocam henüz bugün istemiştim anında aksiyon almışsınız çok teşekkür ederim emeğiniz için. Unity MVC architecture de bizler için çok faydalı olabilir nacizane hocam 🙏🏻
hakikaten bir cok cok fazla yabanci meshur kanallardan cok daha iyi. bu anlatim mukemmel soz bulanadim yazmaya Zenjectin github sayfasinda reference olarak verdiyi tutorialdan kat kat daha iyi bir video tebrik ederim deneyim bu olsa gerek
Ağzınıza sağlık video için teşekkürler çok güzel olmuş. Kısaca singleton ile ilgili düşüncelerimi paylaşmak istiyorum. Küçük çaplı projelerde singleton çok daha kolay ve anlaşılabilir olabilir ama proje çapı büyüdükçe DI daha anlaşılabilir ve geliştirilebilir bir kod yapısı ortaya koyuyor. Örneklendirmek gerekirse, Singleton birden fazla instance ihtiyacımıza cevap vermiyor. Örneğin input manager classımız var ve farklı parametrelerle farklı gameobjectleri kontrol etmemiz gerekiyorsa 2 instance ihtiyacımız oluşacak bu durumda DI büyük kolaylık sağlıyor. Bir diğer büyük artısı da zannımca dataları da inject edebiliyor olmamız. Örnek olarak farklı tip enemy datalarını bulunduran bi SO enemy containerımız olsun. Bunu zenjectde bind etmek istediğimizde SO Installer ile kolayca bind edebiliriz. Sonrasında da enemylere ilgili dataları inject edebilir ve set edebiliriz. Veya tamamen bağımsız olarak UI da display etmek istediğimiz statları UI Manager hatta direkt olarak Displayer classına inject edebilir ve ilgili datayı display edebiliriz. Bunu singleton ile yapmak istediğimizde şu işlemleri yapmamız gerekecek. Bir enemy manager classı oluşturup sahneye atmamız içerisinde de enemyleri tutan bir container gerekecek. Diğer classlar da bu instance üzerinden ulaşmaya çalışacak. Sahnede ve kodda kalabalık oluşturmuş olacağız. Instancelar üzerinden classlar birbirine bağımlı olmak zorunda olacak. Okunabilirlik düşecek. halbuki zenject'de bind ettikten sonra tek yapmamız gereken "[Inject] EnemyData[] m_EnemyData;" veya "[Inject] EnemyContainer m_EnemyContainer".
Mehmet Bey katkınız için çok teşekkür ederim. Ülkemizin sizin gibi insanlara ihtiyacı var. Tüm bilgilerinizi ve görüşlerinizi sizden sonra gelenlere aktarabileceğiniz bir platform isterseniz Discord sunucuma beklerim: discord.gg/jccwZcSeZc
Burada anlamadığım bir nokta var, zaten SO datası oluşturduysak, bu so datayı direkt olarak Displayer'da da tanımlayamaz mıyız veya Enemylere direkt olarak datayı define edebiliriz bind etmek yerine, Concrete bi implementasyon olmuyor SO kullanımıyla böylece direkt olarak tightly couple olmasından da kurtulmuş oluyoruz. Özellikle resource/economy sistemlerini vs. bu şekilde kullanıyorum ve hiçbir şekilde zorluk çekmiyorum. Burada DI ne gibi bir avantaj sağlıyor tam olarak anlamıyorum. DI kullanırken hem third-party oluşundan tüm kod mimarisini bu third-party üzerine kurmak korkutuyor, olası versiyon güncellemelerinde vb. Ayrıca Unity ile savaşıyor gibi hissediyorum. Zaten, SO kullanımı, serialize etme ve GetComponent Unitynin kendi içerisinde IoC pattern kullanmamızı sağlıyor. Yine third-party konusuna gelecek olursak, o zaman DoTween vb. kullanma diyebilirsiniz, ama burada bahsettiğim, tüm kod-base'ini bu mimaride oluşturmak ile, belli başlı noktalarda, helper olarak kullanmakta fark var. DI her daim bir seçenek olmalı diye düşünüyorum. Şirketlerin çoğu DI frameworkler üzerinden ölçümleme yapıyor sanki tüm scaleable & modüler kod sadece DI ile yapılıyor gibi. Bir türlü DI kullanımına, yaklaşık 6 ay boyunca kullanmama rağmen ikna olamadım. Fakat ikna olmak isterim. Yani bir framework kullanmadan SOLID'in D'sini de implement etmek mümkün, basic bi şekilde kullanım sağlayabiliyoruz. Örneğin kapıyı ISwitchable olarak define edip, ona trigger vb. interact olduğumuzda ISwitchable olarak ulaştığımızda hem Open-Closed, hem de Dependency Inversion prensipine de uymuş bulunuyoruz. Hatta unity'nin design pattern e-bookunda buna da değiniliyor. Yukarıda bahsettiğim Resource UI kullanımına örnek şu kod parçacığın gösterebilirim. Kısaca oyundaki currencyimiz, SO datasında, ve bu data her değiştiğinde UI da para texti güncelleniyor. Direkt olarak SO datası implementasyonuyla hem modüler, hem de temiz bir kullanıma sahip oluyoruz. Başka bir currency göstermek istediğimizde de datayı değiştirmemiz yeterli oluyor. Singleton üzerinden vs. dataya da ulaşmamıza gerek yok pastecode.io/s/4uuyki64 Daha somut vb. örneklerle ikna olmak istiyorum. DI olmadan da modüler, scaleable sistemler kurulacağına inanıyorum. blog.unity.com/games/level-up-your-code-with-game-programming-patterns Aynı şekilde IoC ve Dependency "Inversion" için şöyle bir makale bırakabilirim: giannisakritidis.com/blog/The-Dependency-Inversion-Principle/
@TheKr0ckeR Öncelikle tabiki solid kod di ile yazılır gibi bir durum söz konusu değil. Bu bir tercihtir. Proje ihtiyaçlarına göre kullanmamak daha avantajlı olabilir. Third party konusunda şunu söyleyeceğim. Zenject özelinde konuştuk. Çok kapsamlı, içerisinde birçok feature bulunan bir di framework. Çoğu projede çoğu özelliğini kullanmayacağız. Bu yüzden kendi ihtiyacınıza yönelik basit bir DI manager yazabilirsiniz, codebase'inizi bozmamış olursunuz. Third party mecburiyeti yok. Serialize ve getcompenent konusunda da basit bir display işlemi için baya bir külfet altına girmiş oluyoruz evet dediğiniz doğru ama ben sadece bir örnek vermiştim. Başta da belirttiğim gibi basit projelerde DI gerekli değil hatta ekstra iş yükü. Fakat proje çapı büyüdükçe aynı dataya birçok yerden erişmemiz gerekecek non-monobehaviour classlarımız dahil. -Bence büyük artılarından biri çoğu manager classım mono değil. Sahnede tutmuyorum- Yine örnek üzerinden gideceğim. Üzerinde çalıştığım bir tower defense oyunu var. Enemy managerim var. Ansiklopedim var. Achievements var ve enemy datalarına erişmesi gerekiyor. Enemy statlarını gösterdiğim bir panel var, ayrı olarak worldspace'de bir hp , armor bar var , wave list panelim var burada enemylerimin bütün statları gözüküyor. oyunda bir rün ve perk sistemi var ve her bir rün ve perk enemy datalarını manupule edebiliyor. yani kısaca her bir enemy datasını en az 10 yere inject ediyorum. Editorle işim yok sadece inject ediyorum ve geçiyorum. Referans cehenneminden kurtuluyorum. Kaldı ki unity'nin refaransları kaybetmesi çokça yaşanan bir durum. Class ismi değişse, field ismi veya type'ı değişse direkt referansı kaybediyor. Verdiğiniz örneğin aynısını bende paylaşıyorum. benim projemde 4 çeşit resource var. Resuorcelarım da bir data containerda. Hepsini tek bir class display ediyor. Editorde sadece text'i serialize ediyorum. Kendisi ilgili datayı çekip display ediyor. Hatta displayerım da bir prefab ve runtime da spawn ediliyor. Kaç tane olacağı data lenght'ine göre type'ını zaten datan çekiyor. Yani ben ileride 5. bir resource'u yaratmak istersem tek yapmam gereken datasını oluşturmak. Sahnede veya prefabde herhangi bir işim yok. Diğer bütün ihtiyaç olunan yerlere de otomatik inject olmuş olacak. Siz sadece editorden datayı değiştirmem gerekiyor diyorsunuz ama benim durumumda o displayerı duplicate alıp editorden tekrar yeni datayı refere etmem gerekecek ve bu iş displayerla bitmiyor diğer ihtiyaç olunan her yere o 5. resource datasını elle tek tek atıyor olmam lazım. prnt.sc/ZtPs4OCN1Sfo Özellikle data oriented ilerlemek istediğimizde DI şart diye düşünüyorum.
Hocam bence, Singleton classtan 1 tane olması için daha pratik ve kullanışlı. Bu yöntemdeki AsTrasient çok ilgimi çekti, baya kullanışlı olabilir. Ama kafama performans ile alaklı bir şey takıldı. AsTrasient'ı 10 kere de kullansak 10 tane farklı Class açıcak dediniz ya, bu performans için sorun olmaz mı? (Performans açısından bunun yerine klasik Serilizifield ile yapsak performans açısından ne fark olur ?) (= new Class demekle aynı işlevi yapıyorsa bunu kullanmakta pek mantıklı degil sanki)
Scriptableobject kullanımını singleton da , zenjecten de daha faydalı buluyorum fakat trdeki stüdyolar zenject kullanmamızı bekliyorlar sanırım alışkanlık ötürü olduğunu düşünüyorum. SO lar değişken ve ya metod tutabiliyor doğrudan atama da yapabilirisiniz. en büyük olayı çeşitlilik sağlaması bir şeyi farklı yapmak istiyorsan SO'yu değiştir hemen kullan
Hocam emeğinize sağlık, zenject için neredeyse hiçbir kaynak yok ve ben öğrenirken çok sıkıntı çekmiştim, dokümentasyon her ne kadar detaylı olsa bile dokumentasyonda bile yazılmamış çok fonksiyonalite var, özellikle subcontainerlar ve poollar kısmında Hocam fakat kısmi bir yanlışınız var sanırım, 20:46 da FromComponentInNewPrefab() methodunu önermişsiniz installerdan editor referansı vermek için, bu method bir bu dependencye sahip bir önceden kaydedlimiş prefabı sahnede instantiateleyip onun ustundeki bir componenti bindliyor containera(eğer o component yoksa o prefabda onu o noktana instantiateliyor), verdiğiniz örnek için onun yerine .FromInstance() methodu daha uygun gibi geldi bana Emeğiniz için teşekkürler, vidyolarınızın devamını bekliyoruz, özellikle UniRx librarysini ve reactive programming hakkında bir vidyo çekerseniz çok mutlu olurum, UniRx de Zenject gibi neredeyse internette hiçbir kaynak bulunamayan ama çok değerli bir kavram olan async datastreamlerle ugraşıyor, coroutinelerden return value almak için pass in delegate işiyle uğraşmamızı engelliyor ve reactive propertylerle data observelama olanağı sağlıyor
İkazınız için çok teşekkür ederim. Müsait zamanda buna tekrardan bir bakayım, gerekirse videoyu editler tekrardan yayınlarım. Tüm videolarda gördüğünüz hataları lütfen yorumlarda dile getirin, dikkatli izleyicileri severim.
Tolga hocam size bir sorum olacak ben kendimi unity de geliştirmek istiyorum da sizce ders videoları izliyerek mi gitmem lazım yoksa unity de oyun yaparak mı
Proje yapmadan bir şey öğrenebileceğinizi sanmam. Unity ile sıfırdan başlayıp başlangıç seviyesi bir oyun yaptığım video serimi izlemenizi öneririm: ua-cam.com/play/PLU6MuhHWo-4wqjDfC46JahFhHEMoFVUDc.html Ayrıca tüm sorularınızı canlı cevaplamaktan mutlu olurum, bunun için sizi Discord sunucuma beklerim: discord.gg/jccwZcSeZc
Hocam ağzınıza sağlık cok sağolun,bir sorum olucaktı eger mimari acısında tüm delegatleri bir arada tutucak bir mimari yapmaya kalsak nasıl bir yol izliycez eventlerimizi onenable ondiasble da cagırmaktansa zenject buna uygun bir yontem sunuyor mu
Size önerim "Unity ile Oyun Mimarisi" videomu izlemeniz. Oradaki 3 katmanlı yapıya dikkat edin, First sahnesinde bu eventleri bir script içinde toplayıp o scripti topluca DontDestroyOnLoad yapılan GameObject'in child'larından birine ekleyin. Sonra FromComponentInHierarchy ile Zenject üzerinden inject'e müsait hale getirebilirsiniz. Eğer daha detaylı konuşmak veya 1300'den fazla arkadaştan ilgilenenlerin fikrini almak isterseniz Discord sunucuma beklerim: discord.gg/jccwZcSeZc
hocam ilkinde tam anlayamadım 2. de tekrar izleyince daha iyi anladım dependency injectionla basit bir oyun yapar mısınız topa vurup geri gitmesi gibi anladığım kadarıyla çokça kullanılan elzem bir konu
@@ismailyou Evet Zenject kodlarımızı kısaltmıyor, geliştirme süresini de kısaltmıyor o konuda haklısınız fakat temiz kod her zaman kısa kod demek değildir. Singleton'lar global bir değişken işlevi gördüğü için clean code kurallarına uymuyor. Zenject ile sınıfları mock edebileceğiniz için kodunuza unit test yazmayı kolaylaştırıyor. Hata yönetimi, test edilebilirlik ve temiz koddan ötürü Zenject tercih ediliyor.
Hocam ağzınıza sağlık, temiz ve anlaşılır bir anlatım olmuş
Hocam emeğinize sağlık. Sürekli araştırıp bi türlü kavrayamadığım dependency injectionı çok derli toplu sunmuşsunuz. İzlediğim en faydalı unity anlatımlarından biriydi. İlk projemde deneyeceğim 🙂
🚀🚀🚀
Çok açıklayıcı ve güzel olmuş 👍
Bence çok faydalı bir video olmuş. Şu ana kadar zenject' ile hiç ilgilenmemiştim ama bence bu işi harika yapıyor. Teşekkürler.
Singleton deseninin en büyük sorunu bence metodlara doğrudan erişim sağlanabilmesi. Projede birden fazla developer çalıştığında kimin neye ulaşabileceğini yönetmek zorlaşıyor. Dependency inversion prensibini ihlal etmek kolaylaşıyor. Referanslar üzerinden bir mimari kurulduğunda ise metodlara erişim için araya yeni bir katman koymuş oluyoruz ve developerın şu soruyu sormasını zorunlu tutmuş oluyoruz: Buna erişmeme gerçekten gerek var mı?
Elbette singleton da kurallara uymaya azami özen gösterdiğimizde bir sorun teşkil etmez bu açıdan.
Hocam henüz bugün istemiştim anında aksiyon almışsınız çok teşekkür ederim emeğiniz için. Unity MVC architecture de bizler için çok faydalı olabilir nacizane hocam 🙏🏻
MVC çekilecek videolar listemize eklendi kardeşim, fakat liste biraz uzun, ne zaman gelir bilmiyorum ama ilk fırsatta söz diyelim.
Faydalı bir video olmuş elinize sağlık
hakikaten bir cok cok fazla yabanci meshur kanallardan cok daha iyi. bu anlatim mukemmel soz bulanadim yazmaya Zenjectin github sayfasinda reference olarak verdiyi tutorialdan kat kat daha iyi bir video tebrik ederim deneyim bu olsa gerek
Hocam bence bu serinin burada bitmesi yerine devam ettirebilirsiniz. Sadece field inject üzrinde durmuşsunuz, bu konuda türkçe kaynak yok.
Hay hay, devamını getirelim. Aldık notlarımıza
hocam inşallah nazar değmez bu hızınıza
Artarak devam edecek kardeşim, 21 video var şu anda çekilecek videolar listemde ve her gün artıyor
Ağzınıza sağlık video için teşekkürler çok güzel olmuş. Kısaca singleton ile ilgili düşüncelerimi paylaşmak istiyorum.
Küçük çaplı projelerde singleton çok daha kolay ve anlaşılabilir olabilir ama proje çapı büyüdükçe DI daha anlaşılabilir ve geliştirilebilir bir kod yapısı ortaya koyuyor. Örneklendirmek gerekirse,
Singleton birden fazla instance ihtiyacımıza cevap vermiyor. Örneğin input manager classımız var ve farklı parametrelerle farklı gameobjectleri kontrol etmemiz gerekiyorsa 2 instance ihtiyacımız oluşacak bu durumda DI büyük kolaylık sağlıyor.
Bir diğer büyük artısı da zannımca dataları da inject edebiliyor olmamız. Örnek olarak farklı tip enemy datalarını bulunduran bi SO enemy containerımız olsun. Bunu zenjectde bind etmek istediğimizde SO Installer ile kolayca bind edebiliriz. Sonrasında da enemylere ilgili dataları inject edebilir ve set edebiliriz. Veya tamamen bağımsız olarak UI da display etmek istediğimiz statları UI Manager hatta direkt olarak Displayer classına inject edebilir ve ilgili datayı display edebiliriz. Bunu singleton ile yapmak istediğimizde şu işlemleri yapmamız gerekecek. Bir enemy manager classı oluşturup sahneye atmamız içerisinde de enemyleri tutan bir container gerekecek. Diğer classlar da bu instance üzerinden ulaşmaya çalışacak. Sahnede ve kodda kalabalık oluşturmuş olacağız. Instancelar üzerinden classlar birbirine bağımlı olmak zorunda olacak. Okunabilirlik düşecek. halbuki zenject'de bind ettikten sonra tek yapmamız gereken "[Inject] EnemyData[] m_EnemyData;" veya "[Inject] EnemyContainer m_EnemyContainer".
Mehmet Bey katkınız için çok teşekkür ederim. Ülkemizin sizin gibi insanlara ihtiyacı var. Tüm bilgilerinizi ve görüşlerinizi sizden sonra gelenlere aktarabileceğiniz bir platform isterseniz Discord sunucuma beklerim: discord.gg/jccwZcSeZc
Burada anlamadığım bir nokta var, zaten SO datası oluşturduysak, bu so datayı direkt olarak Displayer'da da tanımlayamaz mıyız veya Enemylere direkt olarak datayı define edebiliriz bind etmek yerine, Concrete bi implementasyon olmuyor SO kullanımıyla böylece direkt olarak tightly couple olmasından da kurtulmuş oluyoruz. Özellikle resource/economy sistemlerini vs. bu şekilde kullanıyorum ve hiçbir şekilde zorluk çekmiyorum. Burada DI ne gibi bir avantaj sağlıyor tam olarak anlamıyorum. DI kullanırken hem third-party oluşundan tüm kod mimarisini bu third-party üzerine kurmak korkutuyor, olası versiyon güncellemelerinde vb. Ayrıca Unity ile savaşıyor gibi hissediyorum. Zaten, SO kullanımı, serialize etme ve GetComponent Unitynin kendi içerisinde IoC pattern kullanmamızı sağlıyor. Yine third-party konusuna gelecek olursak, o zaman DoTween vb. kullanma diyebilirsiniz, ama burada bahsettiğim, tüm kod-base'ini bu mimaride oluşturmak ile, belli başlı noktalarda, helper olarak kullanmakta fark var. DI her daim bir seçenek olmalı diye düşünüyorum. Şirketlerin çoğu DI frameworkler üzerinden ölçümleme yapıyor sanki tüm scaleable & modüler kod sadece DI ile yapılıyor gibi. Bir türlü DI kullanımına, yaklaşık 6 ay boyunca kullanmama rağmen ikna olamadım. Fakat ikna olmak isterim. Yani bir framework kullanmadan SOLID'in D'sini de implement etmek mümkün, basic bi şekilde kullanım sağlayabiliyoruz. Örneğin kapıyı ISwitchable olarak define edip, ona trigger vb. interact olduğumuzda ISwitchable olarak ulaştığımızda hem Open-Closed, hem de Dependency Inversion prensipine de uymuş bulunuyoruz. Hatta unity'nin design pattern e-bookunda buna da değiniliyor.
Yukarıda bahsettiğim Resource UI kullanımına örnek şu kod parçacığın gösterebilirim. Kısaca oyundaki currencyimiz, SO datasında, ve bu data her değiştiğinde UI da para texti güncelleniyor. Direkt olarak SO datası implementasyonuyla hem modüler, hem de temiz bir kullanıma sahip oluyoruz. Başka bir currency göstermek istediğimizde de datayı değiştirmemiz yeterli oluyor. Singleton üzerinden vs. dataya da ulaşmamıza gerek yok
pastecode.io/s/4uuyki64
Daha somut vb. örneklerle ikna olmak istiyorum. DI olmadan da modüler, scaleable sistemler kurulacağına inanıyorum.
blog.unity.com/games/level-up-your-code-with-game-programming-patterns
Aynı şekilde IoC ve Dependency "Inversion" için şöyle bir makale bırakabilirim:
giannisakritidis.com/blog/The-Dependency-Inversion-Principle/
@TheKr0ckeR Öncelikle tabiki solid kod di ile yazılır gibi bir durum söz konusu değil. Bu bir tercihtir. Proje ihtiyaçlarına göre kullanmamak daha avantajlı olabilir.
Third party konusunda şunu söyleyeceğim. Zenject özelinde konuştuk. Çok kapsamlı, içerisinde birçok feature bulunan bir di framework. Çoğu projede çoğu özelliğini kullanmayacağız. Bu yüzden kendi ihtiyacınıza yönelik basit bir DI manager yazabilirsiniz, codebase'inizi bozmamış olursunuz. Third party mecburiyeti yok.
Serialize ve getcompenent konusunda da basit bir display işlemi için baya bir külfet altına girmiş oluyoruz evet dediğiniz doğru ama ben sadece bir örnek vermiştim. Başta da belirttiğim gibi basit projelerde DI gerekli değil hatta ekstra iş yükü. Fakat proje çapı büyüdükçe aynı dataya birçok yerden erişmemiz gerekecek non-monobehaviour classlarımız dahil. -Bence büyük artılarından biri çoğu manager classım mono değil. Sahnede tutmuyorum-
Yine örnek üzerinden gideceğim. Üzerinde çalıştığım bir tower defense oyunu var. Enemy managerim var. Ansiklopedim var. Achievements var ve enemy datalarına erişmesi gerekiyor. Enemy statlarını gösterdiğim bir panel var, ayrı olarak worldspace'de bir hp , armor bar var , wave list panelim var burada enemylerimin bütün statları gözüküyor. oyunda bir rün ve perk sistemi var ve her bir rün ve perk enemy datalarını manupule edebiliyor. yani kısaca her bir enemy datasını en az 10 yere inject ediyorum. Editorle işim yok sadece inject ediyorum ve geçiyorum. Referans cehenneminden kurtuluyorum. Kaldı ki unity'nin refaransları kaybetmesi çokça yaşanan bir durum. Class ismi değişse, field ismi veya type'ı değişse direkt referansı kaybediyor.
Verdiğiniz örneğin aynısını bende paylaşıyorum. benim projemde 4 çeşit resource var. Resuorcelarım da bir data containerda. Hepsini tek bir class display ediyor. Editorde sadece text'i serialize ediyorum. Kendisi ilgili datayı çekip display ediyor. Hatta displayerım da bir prefab ve runtime da spawn ediliyor. Kaç tane olacağı data lenght'ine göre type'ını zaten datan çekiyor. Yani ben ileride 5. bir resource'u yaratmak istersem tek yapmam gereken datasını oluşturmak. Sahnede veya prefabde herhangi bir işim yok. Diğer bütün ihtiyaç olunan yerlere de otomatik inject olmuş olacak. Siz sadece editorden datayı değiştirmem gerekiyor diyorsunuz ama benim durumumda o displayerı duplicate alıp editorden tekrar yeni datayı refere etmem gerekecek ve bu iş displayerla bitmiyor diğer ihtiyaç olunan her yere o 5. resource datasını elle tek tek atıyor olmam lazım.
prnt.sc/ZtPs4OCN1Sfo
Özellikle data oriented ilerlemek istediğimizde DI şart diye düşünüyorum.
Hocam bence, Singleton classtan 1 tane olması için daha pratik ve kullanışlı. Bu yöntemdeki AsTrasient çok ilgimi çekti, baya kullanışlı olabilir.
Ama kafama performans ile alaklı bir şey takıldı. AsTrasient'ı 10 kere de kullansak 10 tane farklı Class açıcak dediniz ya, bu performans için sorun olmaz mı?
(Performans açısından bunun yerine klasik Serilizifield ile yapsak performans açısından ne fark olur ?)
(= new Class demekle aynı işlevi yapıyorsa bunu kullanmakta pek mantıklı degil sanki)
Scriptableobject kullanımını singleton da , zenjecten de daha faydalı buluyorum fakat trdeki stüdyolar zenject kullanmamızı bekliyorlar sanırım alışkanlık ötürü olduğunu düşünüyorum. SO lar değişken ve ya metod tutabiliyor doğrudan atama da yapabilirisiniz. en büyük olayı çeşitlilik sağlaması bir şeyi farklı yapmak istiyorsan SO'yu değiştir hemen kullan
Video içinde ayrıca teşekkürler
Hocam emeğinize sağlık, zenject için neredeyse hiçbir kaynak yok ve ben öğrenirken çok sıkıntı çekmiştim, dokümentasyon her ne kadar detaylı olsa bile dokumentasyonda bile yazılmamış çok fonksiyonalite var, özellikle subcontainerlar ve poollar kısmında
Hocam fakat kısmi bir yanlışınız var sanırım, 20:46 da FromComponentInNewPrefab() methodunu önermişsiniz installerdan editor referansı vermek için, bu method bir bu dependencye sahip bir önceden kaydedlimiş prefabı sahnede instantiateleyip onun ustundeki bir componenti bindliyor containera(eğer o component yoksa o prefabda onu o noktana instantiateliyor), verdiğiniz örnek için onun yerine .FromInstance() methodu daha uygun gibi geldi bana
Emeğiniz için teşekkürler, vidyolarınızın devamını bekliyoruz, özellikle UniRx librarysini ve reactive programming hakkında bir vidyo çekerseniz çok mutlu olurum, UniRx de Zenject gibi neredeyse internette hiçbir kaynak bulunamayan ama çok değerli bir kavram olan async datastreamlerle ugraşıyor, coroutinelerden return value almak için pass in delegate işiyle uğraşmamızı engelliyor ve reactive propertylerle data observelama olanağı sağlıyor
İkazınız için çok teşekkür ederim. Müsait zamanda buna tekrardan bir bakayım, gerekirse videoyu editler tekrardan yayınlarım. Tüm videolarda gördüğünüz hataları lütfen yorumlarda dile getirin, dikkatli izleyicileri severim.
Tolga hocam size bir sorum olacak ben kendimi unity de geliştirmek istiyorum da sizce ders videoları izliyerek mi gitmem lazım yoksa unity de oyun yaparak mı
Proje yapmadan bir şey öğrenebileceğinizi sanmam. Unity ile sıfırdan başlayıp başlangıç seviyesi bir oyun yaptığım video serimi izlemenizi öneririm: ua-cam.com/play/PLU6MuhHWo-4wqjDfC46JahFhHEMoFVUDc.html
Ayrıca tüm sorularınızı canlı cevaplamaktan mutlu olurum, bunun için sizi Discord sunucuma beklerim: discord.gg/jccwZcSeZc
@@tolgakaranlik tamam hocam çok teşekkür ederim
Hocam ağzınıza sağlık cok sağolun,bir sorum olucaktı eger mimari acısında tüm delegatleri bir arada tutucak bir mimari yapmaya kalsak nasıl bir yol izliycez eventlerimizi onenable ondiasble da cagırmaktansa zenject buna uygun bir yontem sunuyor mu
Size önerim "Unity ile Oyun Mimarisi" videomu izlemeniz. Oradaki 3 katmanlı yapıya dikkat edin, First sahnesinde bu eventleri bir script içinde toplayıp o scripti topluca DontDestroyOnLoad yapılan GameObject'in child'larından birine ekleyin. Sonra FromComponentInHierarchy ile Zenject üzerinden inject'e müsait hale getirebilirsiniz. Eğer daha detaylı konuşmak veya 1300'den fazla arkadaştan ilgilenenlerin fikrini almak isterseniz Discord sunucuma beklerim: discord.gg/jccwZcSeZc
👍👍👍
hocam ilkinde tam anlayamadım 2. de tekrar izleyince daha iyi anladım dependency injectionla basit bir oyun yapar mısınız topa vurup geri gitmesi gibi anladığım kadarıyla çokça kullanılan elzem bir konu
Listemize alalım, teşekkürler katkı için
ECS ile ilgili bir video gelecek mi
Komple video serisi gelecek
Bence reference pisliginden kurtarmiyo. Aksine her klasa yeni bi reference eklemek zorunda birakiyo. Singleton bile daha mantikli bence.
Referans denen şeyin ne olduğunu tam olarak anladığınızdan emin değilim
kullanacağın her manager icin fazladan ıki satır ekliyorsun klasa. Yazılan yoruma ergen tepkiler vermezsen sevinirim.
@@ismailyou Evet Zenject kodlarımızı kısaltmıyor, geliştirme süresini de kısaltmıyor o konuda haklısınız fakat temiz kod her zaman kısa kod demek değildir. Singleton'lar global bir değişken işlevi gördüğü için clean code kurallarına uymuyor. Zenject ile sınıfları mock edebileceğiniz için kodunuza unit test yazmayı kolaylaştırıyor. Hata yönetimi, test edilebilirlik ve temiz koddan ötürü Zenject tercih ediliyor.