Müşteriniz nesne yönelimli programlama kullanmamanızı isterse ne yaparsınız?

Karıncaların çalışmalarını bir ızgarada simüle etmek için bir program yazıyorum (PDF). Karınca dolaşabilir, bir şeyler toplayabilir ve bir şeyleri bırakabilir.

Sorun şu ki, karıncaların hareketleri ve her karıncaların pozisyonları sınıf özellikleriyle kolayca izlenebilir (ve bu karıncaların pek çok örneğini kolayca yaratabiliriz) müşterim, işlevsel programlamada bir geçmişe sahip olduğundan, Fonksiyonel programlama kullanılarak yapılacak simülasyon.

Açıkçası, müşteriden gelen orijinal kelimeler sadece "sınıf" değil, "işlevsel programlama" dır. Bu yüzden işlevsel programlama demek istemediğini ve zorunlu olarak yapabilirim. Ayrıca, işlevsel programlama konusunda daha önce hiçbir tecrübem yok.

Bununla birlikte, bu sorunun sadece basitçe "zorunlu olarak yapmak" yerine işlevsel bir programlama gereksinimi ile ilgili olmasına odaklanmanın yararlı olduğunu düşünüyorum.

Bu durumu nasıl ele alırsınız? Müşterinizi, nesne yönelimli programlama kullanmanın daha temiz olduğuna ikna etmeye, neye ihtiyacı olduğunu takip etmeye ve ona düşük kaliteli kod vermeyi dener misiniz yoksa başka bir şey mi yaparsınız?

Nesneye yönelik kod tanım temizleyici değildir ve tersine OO dışı kod tanım gereği berbat değildir. Bu özel problem için oldukça belirgin bir nesne yönelimli haritalama görünmekle birlikte, yine de işlevsel programlama yaklaşımını denemenizi öneririm. En iyi atışını yap, problemi toplayabildiğin en iyi fonksiyonel programlama tarzında çözmeye çalış, ve ummadığın bir şey öğrenebilirsin.

Müşterinin işlevsel bir dilde programladığını, belki de kodu işlevsel bir tarzda yazmanızı istediğinin bir nedeni olduğunu söylüyorsunuz. Ona nedenini sormalısın .

Belki de daha sonra kodu saklamayı ve kendine saklamayı amaçlamaktadır.

Üstelik ben yok iki seçenek olduğunu düşünüyorum ya o OO-stili yapmak ya da bok kod yazmak Bahsettiğiniz gibi. Bunun gibi bir örnekte işlevsel kod yazmanın daha zor olacağından emin olabilirsiniz, özellikle de yalnızca nesne yönelimli dillerde deneyiminiz varsa, ancak istemci biraz daha fazla beklemeye istekliyse, işlevsel stilde hız kazanmanız Ona bunu sormak acı vermedi.

Ona kodu neden işlevsel bir tarzda istediğini sordum ve zaman çok fazla bir sorun değilse, fazladan günlerimi işlevsel programlama ile hızlandırmak için rica ediyorum. (öğrenmek için para aldığınız için yaşa!)

Diğerleri başarısız olursa, OO tarzında yapmanız daha az zaman alacağınızı açıklar.

İşlevsel programlamanın sadece "sınıfsız programlama" anlamına gelmediğinin farkında mısın?

Tam metin için Wikipedia makalesine bakın , ancak kısaca ...

Bilgisayar bilimlerinde fonksiyonel programlama, hesaplamayı matematiksel işlevlerin değerlendirilmesi olarak ele alan ve durum ve değişken verileri önleyen bir programlama paradigmasıdır. Durum değişikliklerini vurgulayan zorunlu programlama tarzının aksine, fonksiyonların uygulanmasını vurgulamaktadır.

Fonksiyonel programlama bir programlama paradigmasıdır, tıpkı OO'nun bir programlama paradigması olduğu gibi.

Eğer geçmişiniz OO'daysa, tüm karıncalarınızın nasıl nesne olmasını istediğinizi anlayabilirim. Öte yandan, milyonlarca karınca olan bir karınca çiftliğini simüle ediyorsanız, OO ve mesaj geçişi verimsiz olabilir.

Neyse ki, sizin için, Python, işlevsel programlama için mükemmel araçlara sahiptir (işlevlerin en önemlisi birinci sınıf nesneler olmasıdır).

Python fonksiyonel programlama NASIL

Müşterinize, işlevsel programlama yapmak istiyorsa, bu konuda uzmanlaşmış birini işe alması gerektiğini açıklayın. İşlevsel programlama, OOP'den çok farklıdır ve kolayca seçip yüksek kalitede karmaşık bir çözüm sunabileceğinizi düşünüyorsanız, yanılıyorsunuz.

“OO” nun “işlevsel” ile tamamen aykırı olduğu yönünde yaygın bir yanılgı bulunmaktadır. Bu şeyler el ele çok iyi gidebilir. Örnekte, bir "Karınca", sınıflar ve nesneler kullanılarak doğrudan uygulanabilecek soyut bir veri türü olarak modellenebilir. "Ant devletler" arasındaki geçişler, "Ant" sınıfınız değişmez bir tür olduğu sürece sizi işlevsel bir yaklaşıma götürecek olan işlevler kullanılarak doğal olarak modellenebilir.

Ve "nesnelerin" bir kapanışın işlevsel konseptiyle değiştirilebileceğinin farkında olun, çünkü nesneler fakir adamın kapanışlarıdır zavallı adamın objeleri ... ;-):

https://stackoverflow.com/questions/2497801/closures-are-poor-mans-objects-and-vice-versa-what-does-this-mean

https://stackoverflow.com/questions/501023/closures-and-objects

Müşteri ile konuştuktan sonra, hala onun yolunu istiyorsa, ya profesyonel bir iş yapıyorsunuz ya da o zaman yapamıyorsanız ya sözleşmeyi kabul etmiyorsunuz ya da bir çıkış yolu bulamıyorsunuz.

"Crappy code" üretmek sadece aynı fikirde olmadığınız için profesyonelce olmaz.

1. Neden hepimiz müşterinin işlevsel ve zorunlu programlama arasındaki farkı bildiğini varsayıyoruz? Pek çok insan, OO programlama paradigmalarının isimlerini veya özelliklerini bilmez ve "prosedürel" "zorunlu" ve "işlevsel" gibi terimleri kolayca değiştirir.

2. Bu şekilde yürümesi gerektiğine inanmadığınız sürece, başkalarının size nasıl yürümenizi söylediğini yürümeyin. Bu nedenle, işlevsel programlamanın uygun olduğunu düşünmüyorsanız, başarısız olmaya ya da yarı yürekten bir projeye başlamaya kendinizi hazırlamayın.

3. İstemci Spec sonra, spesifikasyonları uygulamak yazıyor aksi takdirde spesifikasyonları yazmak ve uygulamak için spec.

4. Müşterilerin kararlarını etkilemek için en iyi strateji, istenmeyen seçeneği önemli ölçüde daha pahalı hale getirmektir. Her zaman işe yarıyor.

5. Eğer uzmansanız (müşteriye göre), o zaman onları ikna edebilmelisiniz.

6. Müşterinin geçerli bir noktaya sahip olup olmadığını gerçekten bilmek için, işlevsel programlama konusunda daha fazla tecrübe kazanmanız gerekir, böylece ya güvenle aşağı çekebilir ya da OO'ya olan önyargınızın deneyiminizden dolayı olduğunu fark edebilirsiniz.

7. Neden her iki şekilde de yapmıyoruz, sonra müşterinin her iki uygulamayı görmesine ve hangisinin daha kolay kullanılacağına karar vermesine izin verin. Tüm bunları projenizin tahminlerine dahil edin, böylece size ödeme yapılırken öğrenme eğrisinin tadını çıkarabilirsiniz.

Daha fazla rahatsız etmeden önce, ikinizin de aynı şey hakkında konuştuğundan emin olurdum. Yazılımın kendisine ne zaman 'nesne yönelimli' olduğunu sorabilirsiniz. Sine, asıl uzmanlığının kendisi olmadığını, biraz çarpık bir fikre sahip olabileceğini söyledi.

Örneğin, birçok insan düşünebilir

class C {
public:
  C();
  void f( int );
  void g();
};

klasik nesne yönelimli bir yaklaşım olmak, ancak

struct C;
void construct( C ** );
void f( C *obj, int arg);
void g( C *obj );

(klasik ikisinde "üzerinde çalışan fonksiyonlarla birlikte veri" tanımlaması olduğu sürece, her ikisi de eşit olarak nesneye yönelik olsa bile).

Müşterinizi, nesne yönelimli programlama kullanmanın daha temiz olduğuna ikna etmeye çalışır mısınız?

Kendinizi programlama paradigmaları konusunda daha fazla eğitmeniz gerektiğini düşünüyorum. Nesneye yönelik programlanmış kod mutlaka temizleyici değildir ve aslında evrensel olarak uygulanabilir değildir. Ayrıca, iyi bir nesne yönelimli kodlayıcı bir yordamsal / modüler kullanarak nasıl iyi bir iş yapılacağını bilir (İşlevsel ve Bildirimsel paradigmalarla biraz zor, ancak iyi bir programcının gelmesi çok zor olmamalıdır - okuma ve kesinti ile) - kabul edilebilir bir FP / Beyanname çözümüne.)

Neredeyse asla yapamazsınız, tekrar ediyorum, neredeyse prosedürel ve modüler programlamayı iyi bir şekilde anlamadan Nesne Yönelimini ne zaman ve nasıl kullanacağınızı iyi anlayamazsınız. OO sadece sınıfları ve miras hiyerarşilerini ilan etmekten çok daha fazlasıdır.

Yoksa istediğini takip etmeye çalışıp ona berbat bir kod mu vermeye çalışırsın?

Prosedürel olarak iyi kod yazamazsanız, nesne yönelimli bir şekilde iyi kod yazabileceğinizden şüpheliyim. Dönemi. Burada yargılamaya çalışmıyorum, ama bunun iddia edilmesi gerekiyor.

Nesne Oryantasyonu, prosedürel ve modüler programlamanın bir uzantısıdır. Nesne Yönelimi, uygun bir şekilde kullanıldığında, kapsülleme, birleştirme, uyum ve kod yeniden kullanım / genişletilebilirlik sorunlarını ele almanız için size daha iyi mekanizmalar sağlayan araçlar sunar.

Ancak tüm bu meseleler doğası gereği değildir ve OO'ya özgü değildir. Prosedürel / modüler kodda (ve bu konuda diğer paradigmalarda) varlar. Bu, özünde paradigmadan bağımsız olan karmaşıklık meseleleri türüdür. Onları OO yapıştırıcısı olmadan kaldıramazsanız, onlarla başa çıkmanız pek mümkün değildir.

=========

Müvekkilinizi ikna etmeye çalışacağınız konusundaki asıl sorunuza geri dönün. Değişir. Poster Sean McMillan'ın dediği gibi, müşteri yalnızca bir gündem için (okuma, ofis politikaları) geliştirme çabalarını mikro-yönetmeye çalışıyorsa, uzaklaşın. Bunu yapan insanlar başkasını suçlamak ya da belirli bir gündemi zorlamak için projeler sabote ediyorlar. Buna dahil olmak istemezsin.

OTH, böyle bir gereksinimin başka nedenleri olabilir. Pek çok gömülü mağaza, doğru ya da yanlış olarak, C ++ ile yapabilecekleriniz hakkında çok fazla kısıtlama koymayı tercih ediyor (sanal yöntemler yok, istisnalar yok, örneğin.) Bazı zamanlar diz üstü sarsıntılı bir şekilde yapılır. Diğer bazı zamanlarda, bunu yapmak için geçerli teknik nedenler vardır.

Bu nedenle, müşterinin neden OO kodundan kaçınmak istediğini anlamanız gerekir. Politik bir gündem olmadığını (kırmızı bayraklar olmadığını) tahmin ederseniz, o zaman yapacakları profesyonel bir şey yapmalısınız, bu sadece prosedürel / modüler kodları yerine getirir ve iyi bir iş çıkarır.

Programlama paradigmasından bağımsız olarak, berbat bir kod sunmak için gerçekten hiçbir bahane yoktur. Bir paradigma ile kabul edilebilir kod üretemezseniz, kesinlikle genel olarak kabul edilebilir kod üretemezsiniz.

Veri yapılarını ve nesne yönelimli programlamayı karıştırıyorsunuz (bu OO istilasına uğramış dünyada ortak bir karışıklık)

Yapmanız gereken tek şey bir veri yapısındaki "veri niteliklerini izlemek" ve bunları değiştirmek ise, 70'lerden sonra yapılan hemen hemen her dil, bunun için iyi bir desteğe sahip olacak, OO veya değil.

OO'da yapılması daha kolay şeyler kabaca

• Sınıf temelli miras (eski gibi davranan yeni bir sınıf yaratmak kolaydır)
• Sınıf bazlı polimorfizm (daha sonra simülasyona yeni tür karıncalar eklemek kolaydır)

Bunlardan birine acil ihtiyaç duymazsanız, temelde herhangi bir programlama paradigması çok fazla sorun olmadan çözmelidir.

Müşterim, işlevsel programlamada bir geçmişi olduğundan, simülasyonun işlevsel programlama kullanılarak yapılmasını istediğini söyledi.

(Bu, bir teknik / tasarım sorunu ile karıştırılmakta olan bir sosyal sorunun başka bir örneğidir.)

Burada iki olasılık var:

1. Müşteriniz yazdığınız şifreyi alabilmeyi ve yazmayı tamamladıktan sonra kendinize ait bir şifre alabilmeyi bekliyor. Eğer öyleyse, "ev stili" hakkında daha çok şey bilmelisin - fonksiyonel vs OO buzdağının sadece görünen kısmı. Kendinizi müşterinizin anlayacağı bir programlama stili ile sınırlandırmanız veya müşterinizi tercih ettiğiniz stillerde eğitmeniz gerekecektir. (Bir keresinde, müşteriden değişiklik yapmak isteyebileceği için şablon oluşturmadan veya kütüphaneler kullanmadan CGI ile bir web uygulaması yapmam istendi.)

2. Müşteriniz, gündemden dolayı gelişmeyi kontrol etmeye çalışıyor. Bu, seninle hiçbir şey yapmak istemediğin, delice dolu bir çanta. Eğer gerçekten "anahtar teslimi" bir yazılım sağlıyorsanız, müşteri, işi güvenilir bir şekilde yaptığı sürece, tekerlekler üzerinde çalışan hamsterlerden oluşmasını önemsememelidir. Kendinizi bu şekilde mikro yönetmeye izin vermek, sadece acı istemektir.

Hangi durumda olduğunuza karar vermek ve buna göre hareket etmek size kalmıştır.

Umm ... "Bu açıkça bir test işi / ödevidir" diye düşünen tek kişi ben miyim ? .

İlk olarak - bu ödevin kendisi doğada bir tür "akademik" dır (karıncaların davranışlarının bir yönünü simüle eder).

İkincisi - çok özel bir programlama paradigması kullanarak (ya da kaçınarak) gereksinimlerin yerine getirilmesi için bir talep, kodu okuyabilen ve bu tür iddialar yapabilen "müşteriden" kokuyor.

Böyle bir durumda, sizin için gerekli olanı yapsanız iyi edersiniz - oldukça iyi bir öğrenme deneyimi olacaktır ve eğer yapabilirseniz, süreçte çok şey öğreneceksiniz ...

Durum böyle değilse, gerçekten de kendinize ve / veya müşteriye, görevlendirme için gerekçeyi sormalısınız. Eğer akıl yürütme sağlamsa, o zaman yapın - öğreneceksiniz ve deneyim için bir programcı olarak daha iyi olacaksınız. Kim bilir - hatta OO üzerinden işlevsel bir tarzı sevmeyi öğrenebilirsin.

Eğer açıklama eksikse, o zaman tüm bahisler kapalıdır. Ne yapmanız gerektiğini tavsiye edemem.

Gereklilikleri işlevsel bir dilde / tarzda uygulamaya bakmaksızın denemek isteyebilirsiniz veya balıklı bir şey hissederseniz teklifi kibarca reddedebilirsiniz.

Önemli olan - gereksinimlerin ardındaki motivasyonu bir kez anladıktan sonra, uygun eylem süreci belirginleşir.

DÜZENLEME: Referans verilen PDF'ye çapraz bir bakış attıktan sonra, orada açıklanan algoritmalar kesinlikle OO yerine işlevsel stil için uygun gibi görünüyor

İşlevsel programlama kullanma isteklerinde birkaç iyi yön vardır:

1. Bir müşterin var, her zaman iyi bir işaret
2. Müşteri, yaptığınız işte çok iyi olmanızı bekler. Bu yüzden fonksiyonel programlama soruyorlar. Yani satış organizasyonunuz iyi bir iş yapıyor ya da hizmetleriniz için çok yüksek bir fiyat mı istiyorsunuz?
3. Müşteri organizasyonunun fonksiyonel programlamanın iyi bir şey olduğunu ve gelecekte büyük olacağını bilen bazı insanları var.

Ancak bazı endişe verici işaretler de var:

1. İşlevsel programlamada uygulamaya hazır görünmüyorsunuz. Zaten becerilerinizde biraz modası geçmişsiniz ve değişikliklere ayak uyduramıyorsunuz.
2. Ya da müşteri sizden daha iyi bir programcı olmasını bekliyor. Bu, uygun şekilde yapana kadar gereksinimlerini düşürmeniz gerekebileceği anlamına gelir.

Yukarıdakilere verilen yanıtlar, belki de OO'nun müşterinin bir anlamı olabileceği en iyi çözüm olmadığı yanıtlarını verir.

Soruda ayrıntılı olarak verilen davranışların bir kısmını modelleyen AI Mücadelesine bir göz atın http://aichallenge.org ve ardından başlangıç ​​paketlerinin çeşitliliğine bir göz atın - http://aichallenge.org/starter_packages.php/ en OO paradigması içine yerleştirmediğim dillerdir.

Programlama dili hakkında hiçbir şey yazmadınız, buradaki en önemli şey. OOP ve fonksiyonel programlama arasındaki fark, sadece kodun düzenlenme şekli değil dilin kendisidir. Yüksek eşzamanlılık söz konusu olduğunda, işlevsel dil Erlang kullanımdadır ve örneğin Java'ya göre çok yüksek bir avantaja sahiptir (örneğin, Facebook sohbeti tarafından kullanılır). OOP çözümü performans sorunları nedeniyle kolayca başarısız olabilir.

Buradaki müşteri üniversitedir, bu nedenle dil sadece performans / yapılandırma sorunu değildir, kod öğrencilerle veya kendi araştırmalarıyla didaktik çalışma için de kullanılabilir. Dolayısıyla, müşteriyi diğer paradigmayı seçmeye ikna etmek bence burada geçerli değil. Bu ya görevle başa çıkabilirsiniz ya da yapamazsınız (ve bu yüzden o projeyi almamalısınız).

Müşteri "atla" diyor, cevabınız: __ _ ?

Benim için mantıklı gelse (yeni proje) ikna etmeye çalışacağım, ancak 10 yıllık VB6 uygulamasına sahip bir müşterim var, çünkü zaman zaman yükseltme yaptığım ... onları ikna etmeyecek

Müşterinizi biraz 'Çapraz İnceleyin' (yüzleşmeyecek şekilde):

Müşteri aslında OOP ile işlevsel programlama arasındaki farkı biliyor mu? Müşterinin endişeleri / istekleri meşru mudur?

Eğer 'Evet' ise: Nitelikli iseniz, ne isterseniz yapın ve paranızı alın. Nitelikli değilseniz, onlara söyleyin ve ne yapacaklarına karar vermelerine izin verin.

Başka: merhaba oradan!

double dist(Point p1, Point p2) 
{
  //return distance
}

Bu işlev, işlev dışında hiçbir şey okumadığı / yazmadığı sürece işlevseldir. İşlev bir sınıf değişkenine dokunduğunda, artık "işlevsel" olmaz. İşlevsel stilin avantajı değişen veya geçersiz durumdan başka hata olmamasıdır. Çok sayıda fonksiyon sadece matematiksel formüllerdir. Özetle fonksiyonel programlama.

BTW, işlevsel bir stili nesne tabanlı veya yönlendirilmiş bir tasarımda birleştirebilirsiniz. Örneğin, iki "Nokta" değişkeni, durumu olan nesnelerdir. Ve fonksiyon hala işlevsel! Yuppi!!