Neden OOP'ye ihtiyacımız var?

1. Şirket geçmişi

Size OOP'nin büyük sistemlerin karmaşıklığıyla mücadeleye nasıl yardımcı olduğunu gösteren bir hikaye anlatmak istiyorum . Bu, OOP'nin amacını anlamanız için gereklidir .

Bir zamanlar galaksiler arası nakliye hizmeti veren küçük bir şirket varmış...

Buna Galaxy Rush diyelim. 5 kişiyi istihdam etmiştir. Biri finans sektöründe, ikincisi bir depoda, üçüncüsü teslimatlarda, dördüncüsü reklamcılıkta ve beşincisi tüm işletmeyi yönetiyordu.

Çok çalışkandılar ve her şeyde başarılı oldular. Şirketin iyi bir itibarı vardı ve çok para kazandı. Ancak her yıl daha fazla sipariş vardı, bu yüzden patron ek çalışanlar kiralamak zorunda kaldı. Depo için birkaç tane daha, teslimatlar için birkaç tane daha, finans için bir tane daha ve şirketin pazar payını genişletmek için ek bir reklam uzmanı.

Ve sorunlar o zaman başladı. Daha fazla insan vardı ve birbirlerinin yoluna çıkmaya başladılar.

Pazarlamacı, banka hesabını yeni bir reklam kampanyasına harcıyor, bu nedenle acilen gönderilmesi gereken ürünleri satın alacak para yok.

Depo, bir müşteriye ayda bir gönderilen 10 adet yepyeni hiper sürücüye sahiptir. Bir kurye geldi ve farklı bir müşteri için bir hiper disk aldı ve 10 hiper disk için normal siparişin bir ay gecikmesine neden oldu. İlk kurye, diğer siparişin ikinci kurye tarafından doldurulduğunu bilmiyordu.

Yeni müdür yardımcısı, daha fazla mal satın alması için bir uzay gemisiyle bir kurye gönderir. Bu arada, herkes müsait bir uzay gemisinin görünmesini bekler. Tonlarca acil teslimat var, ancak bu asistan yalnızca satın alma işlemlerini denetliyor ve işini iyi yapmaya çalışıyor. Bir çalışan görevini ne kadar iyi yaparsa, başkalarının işine o kadar çok müdahale eder.

Durumu analiz eden patron, uzay gemisi, nakit para ve ürünler gibi önemli kaynakların optimum şekilde kullanılmadığını fark eder. Bunun yerine, "uyursan kaybedersin" kuralına tabidirler. Herhangi bir çalışan, herkesin kendi işi için ihtiyaç duyduğu bir kaynağı alabilir ve böylece diğer çalışanları ve bir bütün olarak şirketi tehlikeye atabilir.

Bir şeyler yapılması gerekiyordu, bu yüzden patron yekpare şirketi birkaç departmana ayırmaya karar verdi. Bir nakliye departmanı, bir pazarlama departmanı, bir satın alma departmanı, bir finans departmanı ve bir envanter departmanı oluşturdu. Artık kimse uzay gemisini öylece alamazdı. Sevkiyat departmanı başkanı teslimatlarla ilgili tüm bilgileri aldı ve gemiyi en karlı siparişle kuryeye verdi. Ayrıca depo, kuryelerin istedikleri herhangi bir ürünü almalarına izin vermiyordu. Bunun yerine, ürünlerin depodan alınması kontrollü bir süreç haline geldi. Finans departmanı, yakında bir satın alma olacağını bilseydi, bir pazarlama kampanyası için fon sağlamazdı. Her departmanın halka açık bir yüzü vardı - departman başkanı.Her departmanın iç yapısı kendi işiydi. Bir kurye ürün almak isterse depoya değil depo müdürüne giderdi. public-facing representativeYeni bir sipariş geldiyse, bir kurye ( ) tarafından değil, nakliye departmanı başkanı ( ) tarafından alındı someone not authorized to interact with the other departments.

Başka bir deyişle, patron, kaynakları ve kaynakları içeren eylemleri gruplar (bölümler) içinde birleştirdi ve ayrıca başkalarının bölümlerin iç yapılarına müdahale etmesini yasakladı. Departmanlar arası etkileşimler belirli bir kişiden geçmek zorundaydı.

OOP açısından bu, programı nesnelere bölmekten başka bir şey değildir . Yöntemlerden ve değişkenlerden oluşan yekpare bir program, nesnelerden oluşan bir program haline gelir. Ve nesnelerin değişkenleri ve yöntemleri vardır.

Sorun, herhangi bir çalışanın herhangi bir kaynakla çalışabilmesi ve diğer herhangi bir çalışana gözetim veya kontrol olmaksızın komutlar verebilmesiydi. Küçük bir kısıtlama getirdik ama daha fazla düzen sağladık. Ayrıca her şeyi daha iyi kontrol edebildik.

Bu, en saf haliyle böl ve fethet oyunudur.

2. Programlar nasıl oluşturulur?

OOP'nin bir başka avantajını ortaya çıkaran önemli bir noktaya daha değinmek istiyorum . Programların binalardan çok hayvanlara benzediğini görüyor musunuz? İnşa edilmediler. Büyüdüler. Gelişim sürekli değişimdir. İnşaatta iyi bir planınız olabilir ve onu hassasiyetle takip edebilirsiniz. Yazılım geliştirmede durum böyle değil.

Programlamada çok sık olarak, başlangıçta planladığınız gibi bir şey yapamazsınız ve çok fazla yeniden çalışmanız gerekir. Müşteri gereksinimleri daha da sık değişir.

Peki ya müşteri çok kesin bir özellik sağladıysa? Bu, işleri daha da kötüleştirir. Zaman içinde ürüne neler olduğuna bir göz atın.

Ürünün başarısı, müşterinin yeni bir sürüm yayınlamak istemesine ve ardından bir başkasının ve bir başkasının piyasaya sürülmesine yol açacaktır. Ve tabii ki yapmanız gereken tek şey mevcut ürüne "küçük değişiklikler" eklemek. Gördüğünüz gibi, ürün geliştirme bir dizi sürekli değişikliktir. Sadece zaman ölçeği farklıdır. Yeni bir sürüm haftada bir, ayda bir veya altı ayda bir yayınlanabilir.

Ve tüm bunlardan hangi sonucu çıkarabiliriz? Ürünün iç yapısının, minimum yeniden çalışma ile önemli (ve küçük) değişikliklerin yapılmasına izin verecek şekilde muhafaza edilmesi gerekir.

nesne uyumu

Ancak bunu yapmak, yapmaya karar vermekten daha zordur. Bir programın birbiriyle etkileşen nesnelerden oluştuğunu daha önce söylemiştik. Programımızın tüm nesnelerini tahtaya noktalarla temsil ederek çizelim. Ve her nesneden (noktadan) etkileştiği diğer tüm nesnelere (noktalara) oklar çizelim.

Şimdi nesneleri (noktaları) gruplar halinde birleştireceğiz. Aralarındaki bağlantılar diğer noktalara göre çok daha yoğunsa noktalar gruplandırılmalıdır. Bir noktadan çıkan okların çoğu kendi grubundaki diğer noktalara gidiyorsa, gruplar doğru oluşturulmuştur. Bir grup içindeki noktaların yüksek uyuma sahipken , farklı gruplardaki noktaların daha düşük uyuma sahip olduğunu söylüyoruz .

Gevşek bağlantı prensibi

Bir "gevşek bağlantı ilkesi" vardır. Bir program, genellikle katmanlar olan birkaç bölüme ayrılmıştır. Bu katmanların/parçaların mantığı, iç yapılarına sıkı bir şekilde bağlanmıştır ve diğer katmanlara/parçalara çok gevşek bir şekilde bağlanmıştır. Katmanlar arasındaki etkileşimler genellikle çok düzenlidir. Bir katman, ikinci katmana atıfta bulunabilir ve sınıflarının yalnızca küçük bir alt kümesini kullanabilir. Bu, daha önce gördüğümüz, ancak daha geniş ölçekte "şirketi bölümlere ayırma" ilkesidir.

Sonuç olarak, etkinliğini artırmak için bir departmanı gerektiği gibi yeniden düzenleyebiliriz ve departman için daha da fazla insanı işe alabiliriz ve diğer departmanlarımızla etkileşim protokolünü değiştirmediğimiz sürece, yapılan tüm değişiklikler yerel kal. Kimse bir şeyi yeniden öğrenmek zorunda değil. Tüm sistemi yeniden çalışmak zorunda değilsiniz. Departmanlar arası etkileşim mekanizmaları iyi seçilirse, her departman bu tür dahili optimizasyonu yapabilir.

İyi seçilmiş. Peki ya iyi seçilmezlerse? O zaman değişim kapasitesi hızla tükenir ve tüm sistemi yeniden yapmanız gerekir. Bu zaman zaman yapılmalıdır. Geleceği tahmin edemezsiniz, ancak yineleme sayısını minimumda tutabilirsiniz.

soyutlama ilkesi

Departmanların nasıl yapılandırılacağını ve nasıl etkileşimde bulunacaklarını seçmek " soyutlama ilkesi "dir. Programlamada, bir programı bileşenlerine ayırmanın en iyi yolunu ve bu bölümlerin nasıl etkileşime girmesi gerektiğini belirlemek için kullanılır. Programı bireysel sınıflara bölene kadar ortaya çıkan parçaları parçalara ayırarak prensibi yeniden uygulayabiliriz.

Bu parçaların iç yapısını gizlemek ve diğer parçalarla olan etkileşimleri kesinlikle sınırlandırmak kapsüllemedir . Kapsülleme ve soyutlama, OOP'nin temel taşlarıdır . İyi bir program bu iki ilkeyi takip etmelidir. Gelecekte, ilkelerin geri kalanına bakacağız ve sağladıkları faydaları keşfedeceğiz.