OO programlama gerçekten işe alım şirketleri tarafından yerleştirilenler kadar önemli mi? [kapalı]

Sadece yüksek lisansımı bitirdim (hesaplamada) ve iş başvurusunda bulunuyorum. Pek çok şirketin özellikle nesne yönelimini anlamalarını istediğini fark ettim. Popüler röportaj soruları miras, polimorfizm, erişimciler vb.

OO gerçekten bu kadar önemli mi? C'deki bir programlama işi için röportaj bile yaptım ve röportajın yarısı OO idi.

Gerçek dünyada, gerçek uygulamaları geliştirmek, nesne yönelimi neredeyse her zaman kullanılır mı? Polimorfizm gibi temel özellikler A LOT kullanılıyor mu?

Sanırım sorum zayıf yanlarımdan biri. OO'yu bilmeme rağmen, programları programıma çok dahil edemiyor gibiyim.

OOP, programınızın sürdürülmesi / anlaşılması imkansız olmadan büyümesini sağlayan bir paradigmadır. Bu, öğrencilerin neredeyse hiç almadıkları bir nokta çünkü en fazla iki haftadan iki aya kadar süren küçük projeler yapıyorlar.

Bu kısa süre, özellikle projedeki insanlar yeni başlayanlarsa, OOP'un hedefini netleştirmek için yeterli değildir. Ancak bazı modellenmelere bağlı kalmak büyük projeler için çok önemlidir, diyebilirim ki 50.000'den fazla kod satırı. Bunun için tek çözüm OOP değil, sektörde en yaygın kullanılanı budur.

Bu yüzden insanlar OOP'yi bilmenizi istiyor.

Kısacası, neredeyse bütün genç programcıların modellizasyon ve OOP konusunda ciddi kusurları olduğunu eklerdim. Birçoğu sınıfları nasıl yazacaklarını, onlardan miras kaldıklarını ve bunun gibi temel şeyleri biliyorlar, ancak “OOP” da düşünmüyorlar ve yanlış kullanmaya başlıyorlar. Bu nedenle, herhangi bir ciddi işe alım uzmanının OOP alanındaki yeterliliklerinizin neler olduğuna daima dikkat etmesi gerekir.

Bu şeyler okulda öğrenilmediğinden, farklı adaylar arasında basit bir bilgi çeşitliliği var. Ve dürüst olalım: OOP'de zayıf bilgisi olan birinin herhangi bir büyük projede çalışabileceğini sanmıyorum, çünkü liderlerin bu insanları yönetmesi için kodları kendisinin yazmasından daha fazla zaman gerektirecektir.

Henüz "OOP" düşünmüyorsanız, bu konuda bazı kitaplar okumanızı ve gerçekten büyük projeleri olmayan şirkete başvurmanızı öneririm; işvereniniz için yararlı işler yapmaya devam etmek için OOP'a alışmak (ve size maaşınızı verdiği sürece, bu sizin için de yararlı olacaktır).

EDIT: ha ve C'nin en yaygın kullanımı olmasa bile, C ile OOP kodunu zaten yazdığımı eklerdim, bu güçlü bilgi ile mümkündür. Sadece el ile vtables oluşturmak zorunda.

Ve OOP tekniğinin arkasında bir şey gizlenir: yazılım tasarımı. Yazılım tasarımı, diğer dillerde olduğu gibi C’de de gerçekten yararlıdır. İşe alım yapan birçok kişi yazılım tasarım becerilerinizi test edecek ve OOP sorusu bunun için iyi, ancak OOP burada test edilen en önemli şey değil. Bu yüzden bir C işi için bile bu sorularınız var.

Bilgisayar programcılığındaki büyük problem karmaşıklığı ele almaktır ve modern programlar gerçekten de çok karmaşık olabilir ve bu sadece artmaktadır.

Önemsiz bilgisayar programlarının yazılım mühendisliğinde yapılan çalışmaların çoğu karmaşıklığı dolaştırmaya odaklanır ve ilk önce bir yaşam boyu öğrenmeye ayrılmadan mümkün olduğu kadar erişilebilir olmasını sağlar.

Örnekler:

• Modülerleştirme: Her modülün sadece diğer modüller hakkında çok az şey bildiği (örneğin, ağ kartı tamponlarını doğrudan manipüle etmesine izin verilen bir fare ikonu çizim yerine) kod modüllerini kullanarak programları kavramsal olarak basitleştirirsiniz.
• API'ler: API'lerin arkasındaki karmaşık programlara basit bir kullanım yolu sunarlar. Bir dosyayı açtığınızda, ağ paylaşımlarının bir USB diskten farklı şekilde ele alınması umrumda değildir. API aynı.
• Nesne yönlendirme Bu, mevcut kodu tekrar kullanmanıza ve eklediğiniz yeni kodla şeffaf bir şekilde çalışmasına ve aynı zamanda tüm karmaşıklığı gizlemenize izin verir.

Başka bir deyişle, önemsiz olmayan yazılım parçaları üzerinde tek başınıza veya (muhtemelen büyük olasılıkla) başkalarıyla çalışmak istiyorsanız, birçok püf noktası bilmek gereklidir.

Evet, öncelikle ticari gelişimde (Java ve .NET) kullanılan en popüler iki geliştirme platformu nesne yönelimli olduğundan ve yani evet anlamına gelir, OO çok kullanılır (polimorfizm, kalıtım ve her şey dahil).

Şirketler özellikle bir teknoloji olarak nesne yönelimini önemsemiyor - bu bir ideoloji meselesi değil, sorunlarına BT stratejileriyle uyumlu şekilde çözümler geliştirebilecek insanları önemsiyorlar.

Fakat bunun bir zayıflık hissetme konusunda fazla endişelenmem. Eğitiminize saygısızlık etmeden, ticari dünyadaki çoğu insan üniversiteden ayrılan programcıları (herhangi bir düzeyde) bitmiş makale olarak görmüyor. Hala öğrenecek çok şeyiniz var ve bu anlaşıldı (şirketler tarafından öğrencilerden daha iyi olabilir).

Gerçek hayatta olduğu gibi, gerçek hayatta programlama da teoride olduğundan farklıdır.

Evet, OO paradigmasını cilalı tutar ve her zaman aklınızın arkasında tutarsanız, yönetilebilir, anlaşılabilir ve kolayca genişletilebilir kod yazarken daha iyisini yapabilirsiniz.

Ne yazık ki, gerçek dünyada bu var:

• proje zaman basınçları
• usule dayalı ekip üyeleri
• çapraz konumlu ekipler, birden çok satıcı
• eski kod hiçbir yönelime sahip değil
• İşe yaradığı sürece, kodun nasıl yazıldığı ile ilgili birkaç özen
• Kod çalışmıyor olsa bile, motivasyon "OO" değil, onu düzeltmektir.
• modüller, platform sınırlamaları, basitçe iyi OO yapmanıza izin vermeyen çerçeveler

Gerçek bir işte, yukarıdaki konularla çalışmak zorundasınız. Bu moral bozucu geliyor. Ancak, bunu bir kafa başı olarak ele alın. İşe alım şirketleri, işe alım sürecinde OO'ya çok büyük önem vermektedir. Nedenini görmek kolaydır. Adayı test edebilmelerinin tek yolu OO anlayışı hakkında sormak. Ve ne yazık ki, pek çok aday bir röportaj için başvurmadan önce bu soruları tazelemekteler.

Gerçek hayattaki OO yavaş geliyor. Okumaya devam etmenize ve zaman içinde gelişmeye devam etmenize yardımcı olur.

Lisans derecemi bitirdiğimde de aynı hissi yaşadım ve OOP'un gerçek dünyadaki uygulamalar için neden ve ne kadar önemli olduğunu gösteren harika bir kitap Baş İlk: Tasarım Desenleri . Bir göz atmanızı içtenlikle öneririm, gerçekten eğlenceli bir şekilde yazılmıştır ve daha büyük ölçekli, sürekli değişen sistemler ile çalışırken bir OOP yaklaşımının neden istendiği konusunda birçok geçerli noktaya değinir.

C'deki bazı işler için bile, Linux çekirdeğindeki nesne yönelimli tasarım üzerine bir dizi makale tarafından kanıtlandığı gibi, nesne yönelimli tasarımı (belki de derleyicinizin sizin için yapmasından daha iyi) bilmeniz gerekebilir. ( Bölüm 1 , Bölüm 2 )

GTK + ayrıca çok sayıda nesne yönelimli tasarım deseni kullanır.

OO'nun her şey olduğu fikrine katılmıyorum - biri OO'nun şehirler kurmanıza izin verdiğini söyleyebilir, ancak prosedür programları tuğladır.

Ben bir benzetme şeklinde cevabımı vermek için, genel bir nesneye ihtiyaç duyar, asker prosedürlere ihtiyaç duyar. OO'da yeterince ayrıntıya indiğinizde prosedürleri bulacaksınız ve bu sizin uzmanlığınızsa ve yeterince iyiyseniz, OO için endişelenmeyin, birisinin bu OO satranç oyun kodunu yazması yeterince kolay çünkü:

-findBestMove
-makeBestMove
-waitForPlayerInput

ama sonra birinin kodunu arkasında -findBestMove yazması gerekir ve bunun sadece bu olmadığından emin olabilirsiniz:

foreach $move (@moves){
    $bestMove = ($move > $bestMove ? $move : $bestMove)
}
return $bestMove

Öte yandan, OO kodunu nasıl okuyacağınızı bilmiyorsanız, endişe edin. Çünkü (neredeyse) kodunuzun bir tür nesnelerle karışacağından emin olabilirsiniz. 12000 Global vars ve Fortran Mirası üzerinde çalışmadığınız sürece şu an bakımını yaptığım 1200 hat "modül".

Jon Hopkins yazdı:

Evet, öncelikle ticari gelişimde (Java ve .NET) kullanılan en popüler iki geliştirme platformu nesne yönelimli olduğundan ve yani evet anlamına gelir, OO çok kullanılır (polimorfizm, kalıtım ve her şey dahil).

Söyleyeceğim şey buydu, ama sadece Java değil. Net, C ++ her yerde, Objective-C OSX'in her yerinde, tüm havalı çocuklar Ruby ya da Python yapıyor ve tüm bu şeyler ve çok daha fazlasının nesne yönelimi üzerine odaklanması. Yeni dillerin çoğu çoklu paradigmadır, bu nedenle F # gibi bir şey öncelikle işlevsel bir dildir, ancak aynı zamanda nesne yönelimini de destekler. Her yerde ve en azından bir anlayışa sahip olmak çok yararlı. Yine de fazla üzülmeyin, henüz yeni üniversite derslerini tamamlamanız, gerçek dünyada kod geliştirmeyi öğrenmeye hazır olduğunuz anlamına gelir :)

Uzun zamandır programlama yaptım ve OO kavramlarını C de programlamada bile faydalı buluyorum - test edilse bile, muhtemelen her küçük ayrıntıda bu kavramları tanımlayamayacağım. Bir noktada, fikirlerin başında kafamı yakalamak ve OO'da yeni bir açıyla zevk bulmak için ilkel olsa da bir OO dili bile oluşturdum.

BTW, C ++ büyük ve çirkin bir OO karmaşası oluştururken, Objective C doğru yapar.

Görüşmeler hakkında, masanın her iki tarafından bir korku gösterisi haline geldiler. Görüşülen kişilerin çoğu onlar tarafından çok korktu. İşe alım yöneticilerinin çoğu, çok temel programlama testlerinde bile kaç kişinin başarısız olduğu konusunda hayretler içindedir.

Bununla birlikte, yazılım endüstrisinde çalışan ve şu anda HİÇBİR ŞEYİ tanıyan, ancak dünyayı potansiyel çalışanlardan bekleyen çok büyük bir douche çantası var.

Öğrenme OOP'si öğrenme yazılımı geliştirme kadar faydalı değildir. Git Kod tamamlandı 2'yi oku .

Elbette faydalı bir araç ama OOP'un kendisi gerçekten küçük. Genel olarak şirketler ve işverenler “OOP” derken “Yazılım geliştirme” anlamına geliyorlar. Genel bir terim olarak kullanılıyor.

Gerçek işe alım uzmanları, yazılımın nasıl geliştirileceğini bilmeniz ve "OOP'ta 3 yıl var" kutucuğuyla eşleştirme arasındaki farkı söyleyecektir.

Cevap evet, bazılarının da belirttiği gibi.

AMA, OO olmayan prosedür spagetti kodu yığınları üzerinde çalışmak istiyorsanız, orada da bulabilirsiniz. OO çalışmasını tercih edeceğini düşünüyorum.

EDIT: Gunslinger alaycılığını ve mizah anlayışını bağışlayın. Raynos'un dediği gibi, sadece bir şeyler olması OO'nun iyi olduğu anlamına gelmez. OO'nun doğru uygulanması gerçek iş ve düşünce gerektirir; sadece bunun örnekleri olması otomatik olarak bir uygulamanın iyi yapıldığı anlamına gelmez. Ve tam tersi, orada iyi yazılmış bir prosedür kodu olduğuna eminim. 90'lı yılların ve 2000'lerin kurumsal bilişim mağazalarındaki deneyimim, pek çok kötü kodun yazıldığını ve muhtemelen hala var olduğunu gösteriyor. Ancak OP'nin sorusuna daha yakın, daha akıllı geliştiricilerin şans verildiğinde daha fazla OO sistemine geçtiklerini fark ettim.

OO, diğer tekniklerin inşa edildiği temel bir temeldir. Bir anahtar nokta, öncelikle bir tür (sınıf) ile o tür bir örnek arasındaki farkı tam olarak anlamaktır. Bunu tam olarak anlamadan okumaya çalışmayın (daha sonra netleşeceğini düşünün), çünkü vizyonu yakaladığınızda gerisini tekrar okumak zorunda kalacaksınız.

Bir kere asıldığın zaman, onsuz asla yapmak istemeyeceksin. Kapsülleme, kalıplar, çerçeveler ya da her neyse, ben saf değilim. İş başında, çeşitli görüşlere ve kavramlara uyum sağlamak zorunda kalacaksınız. Bazı önceki iş deneyimlerini kendim listeleyeceğim:

Bir şirkette meslektaşlarım mümkün olduğunca tembel yükleme yapmak istediler (boş inşaatçılar, her yerde boş değerler olup olmadığını kontrol etmek için hantal özellikler). Kısa ömürlü web tabanlı sunucu tarafı nesneler inşa ediyorlardı.

Bir sonraki iş tamamen tersti. Nesneler bir masaüstü (Excel tabanlı) uygulamasında yaşadı. Yapıcıda mümkün olduğu kadar ilk kullanıma hazırlama (veya birçok aşırı yükleniciden biri) olmalıdır. Boş nesnelerin varolma hakkı olmadığı için boş inşaatçılara izin verilmedi (kalıcılık oldukça zordu). Ek olarak “kodlama stili standartlarına” (parantez açmak, yorumlardan sonra boşluk eklemek vb.) Uyarlamak zorunda kaldım, çünkü kodum stil polisinden geçemediğinde kontrol edilemedi.

Şu anda geliştiricilerin hiçbirinin OO'yu anlamaya çalışmadığı bir şirkette çalışıyorum. Bunun ne kadar sinir bozucu olduğunu açıklamak zor. Grep becerilerimi geliştirmek zorunda kaldım, aslında F12 anahtarıma atanmış bir HotScripts makrosu var. Diğer hayal kırıklıklarını gidereceğim ...

OO becerilerini edindikten sonra, spagetti'ye neredeyse alerjik olacaksınız! Ancak tüm durumlarda, OO veya değil, sabırlı olun ve uyum sağlayın. "Atıp atmaya" isteksiz olun. Patronun dışarı atmaya gelince seni seçecek. Ne yazık ki "para kazanmak" şık kodlardan daha önemlidir.

Uzun cevap için özür dilerim ama sorunuzun kapsamının çoğunu ele almaya çalıştım :-)

OOP kendisi nedeniyle değil, onunla ne yaptığından dolayı önemlidir. Soyutlama ve soyutlama kabiliyeti ile ilgilenen bir şey, birlikte grup şeyleri sadece birlikte etkileşim için gerekli olan parçaları ortaya çıkarır.

Bu, "modülerleştirme" adı verilen ve daha basit olanların bir araya getirilmesi için karmaşık sistemler oluşturmaya izin veren, her bir ayrıntıya yüksek seviyede bakmadan izin veren ve bileşenlerin tam olarak olmaları gerekmeden bile değiştirilebilmelerini gerektiren ortak bir tekniktir. aynı.

Bu "mühendislik kavramları", yazılım ürününün kendisinin, "tek geliştirici özelliğinden" daha büyük hale gelmesinden bu yana, yazılım geliştiricilerin bağımsız parçalar üzerinde çalışabilmesi için bir yol gerektirmesi ve bu parçaların çalışmasına izin vermesi gerektiği için yazılım geliştirmede tutulmaya çalışılmıştır. birlikte etkileşime gir.

Bununla birlikte, bu ilkelerin mutlaka sadece OOP'da bulunmadığı söylenebilir (hesaplama teorisi geçerlidir, bu sonuçlara ulaşmak için sonsuz olası yöntemler vardır).

OOP sadece bu tanımların (kalıplar) üzerinde daha kesin tanımları ve ayrıntılı kavramsallaştırma (modüllerin, kapsülleme, ikame gibi) bu genel şartlara vererek birlikte bu şeyleri koymak için başarılı bir girişimdir olabilir programlama dillerine uygun.

OOP'yi ilk önce bir " dil özelliği " olarak değil , yazılım mühendislerinin yazılım tasarımına yaklaşmasını sağlayan " ortak bir sözlük " olarak düşünün .

Belirli bir dilin, örneğin bir "kapsülün" OOP tasarımının ikincil bir yönü olduğu kimsenin istememesiyle yanlışlıkla açılmamasını sağlayan sözlüğün doğrudan uygulanmasını sağlayan ilkellerin olması veya bulunmaması. Bu nedenle, büyük C projeleri bile, dilin kendisi doğrudan bir destek sunmasa bile OOP'yi “yönetiyor”.

Bir proje büyüklüğü, geliştirdiği her şeyi anlama ve takip etme (aslında, bu durumda "tepegöz" olarak bile görülebilir) veya bir şey geliştiren küçük bir grupta tek bir geliştirici yeteneğine girinceye kadar tanınmayan her şeyin avantajı kısa bir süre Ve bu, “dil özelliği” terimiyle OOP okuyan gençlerin, kötü tasarlanmış kodlar üretmesini çoğunlukla yanlış yorumluyorlar.

OOP'nin dillere nasıl uyduğu, dil tasarımcılarının OOP ilkesini kendi yapılarında nasıl yorumladıklarına bağlıdır.

Böylece, C ++ 'da "kapsülleme", "özel üyeler" (ve bir "kapsül" bir sınıf haline gelir), "ikame", sanal fonksiyonlar yerine geçer veya şablon parametrelendirme / uzmanlaşma vb. Olur; D'de bir kapsül "modül" olur (ve ikame, sınıflar vs. yoluyla), böylece belirli bir paradigma veya örüntüyü belirli bir dilde ve başka bir dilde değil, doğrudan kullanılabilir duruma getirmek.

İşverenlerin OOP sorusu sormak istediği şey, gelecekteki büyük projeler ve gelişim için yazılım tasarımını soyutlama ve tasarlama yeteneğinizi kontrol etmektir. OOP, çünkü onlar sadece sizin ve sizin bildiğiniz farz edilen bir "sözlüktür", böylece daha genel şeyler hakkında konuşabilir veya belirli bir uygulamaya somutlaşabilirsiniz.

Nesne yönelimli bir dil, kodunuzda iyi bir nesne yönelimli tasarım tutmanıza yardımcı olur. Ancak böyle bir tasarımın başka herhangi bir paradigma diliyle de elde edilebileceği de doğrudur: OO dillerinin popülerliğinin nedeni (özellikle şirketler arasında) java ve c # 'nın ticari başarısında büyük olasılıkla durmaktadır.

Bay Gates, şirketini doğru şekilde başlatmış olsaydı, muhtemelen bir işe başvurmadan önce ŞEMA okuyorduk.

Kısa cevap Evet

Neden önemli olduğunu düşündüğünüzde veya bir ikilemde hissettiğiniz uzun versiyon, sadece bir amaca hizmet eden herhangi bir proje veya uygulama üzerinde çalışmamış olmanızdan kaynaklanmaktadır. Otomobillerde örneklere sahip olmak için sınıfta mükemmel şekilde geçerli, daha sonra Car, Trucks ... Şimdi OOolmasaydı, herkesin kod tabanına benzer kodlar yazmasını isterdik ya daher gün tekerlekleri yeniden icat etmek. Birinin bir şeyi düzeltmek için böyle bir kod tabanına dalması durumunda ne kadar karışıklık olacağını hayal edin. Sınıf örnekleri, neden / neden yapıldığının belirsiz bir tanımı veya temsili içindir. Uygulamanızı oluşturmaya başladığınızda gerçek bir test ortaya çıkıyor, korkunç bir şekilde kullanılabileceğinden şüphe yok ama net ve özlü kullanımı nedeniyle aklı başında bir şey yok. Bu yüzden bu zayıf alan üzerinde çalışmaya başlamanız en iyisi en az kabus kodlarını dağıtmaktır.

Değişir. OO'yu bilmeniz gereken nedenlerden biri, çünkü programlama dünyasının lingua franca'sı. Başka bir cevabın işaret ettiği gibi, neredeyse her ana dil bir şekilde OO'dur; bu, temelde sizi işe alabilecek herhangi bir şirketin bir OO dili kullandığı anlamına gelir. Hiç OCaml programcılarını işe almayı denediniz mi? Bu imkansız; yetenek havuzu çok küçük. Firmanızı OCaml kullanarak başlattıysanız ve şirketiniz başarılı olursa, programcıları yeterince hızlı işe alamazsınız ve işsiz kalırsınız. Bu nedenle, 3'ten fazla programcıya sahip hemen hemen her şirket bir OO dili kullanır ve iş arkadaşlarınızla iletişim kurmak ve platformunuzun kütüphanelerini kullanmak için bir OO anlayışına sahip olmanız gerekir.

Şirketin kullandığı belirli bir dile bağlı olarak, kalıtım ve polimorfizm ya son derece önemlidir ya da sadece orta derecede önemlidir. 10 GoF tasarım modelini ve bir bağımlılık enjeksiyon çerçevesini bozmadan Java'da hiçbir şey yapamazsınız. Java, en yaygın kullanılan dillerden biridir, bu nedenle OO prensipleri, Java kullanan birçok şirket için gerçekten önemlidir.

Eğer şirket, Scala veya C # gibi, lambda ve fonksiyon göstergelerine sahip modern bir karma OO / fonksiyonel dil kullanıyorsa, miras aniden daha az önem kazanır, çünkü aksi halde çok şey gerektiren çok basit şeylerin üstesinden gelmek için daha yüksek dereceli işlevlere sahipsiniz. töreni. Bununla birlikte, hala OO işleri ile çalışabilmeniz gerekir, çünkü kullandığınız kütüphanelerin çoğu OO biçiminde yazılır.

Kalıtım ve polimorfizm şirket için önemli değilse , OO ile ilgili sorularınız olması muhtemeldir, çünkü:

• Programlama hakkında hiçbir şey bilmeyen ve bir kontrol listesinden sorular soran bir İK kişisi ile röportaj yapıyorsunuz. 3 yıl süren X, çoklu görev vb. Var mı?
• Bir kayanın altında yaşamadığınızdan emin olmak isteyen bir mühendis ile röportaj yapıyorsunuz. OO lingua franca'dır, bu yüzden size bu konuda bazı ipucu sorular sorulacak.
• Röportaj konusunda çok yetenekli olmayan bir mühendis ile röportaj yapıyorsunuz. Genel olarak, mühendisler önemsizliği ve karmaşıklığı sever, bu nedenle polimorfizm, kalıtım ve GoF tasarım kalıpları hakkında birçok soru alırsınız, çünkü bunlar sizi görüşen kişi için ilginçtir.

"Evet" kelimesiyle.

Teoriyi bildiğinizi düşünebilirsiniz, ancak bir kod yazmanız ve uygulamaya koymanız gerekir. Kelimenin tam anlamıyla - çevrimiçi olarak binlerce örnek ve alıştırma var.