Hiçbir şeyi temsil etmeyen sınıf - doğru mu?

Uygulamamı tasarlıyorum ve SOLID ve OOP'yi doğru bir şekilde anladığımdan emin değilim. Sınıflar 1 şeyi yapmalı ve iyi yapmalı ancak diğer taraftan birlikte çalıştığımız gerçek nesneleri temsil etmelidir.

Benim durumumda veri setinde bir özellik çıkarımı yapıyorum ve ardından makine öğrenimi analizi yapıyorum. Üç sınıf oluşturabileceğimi farz ediyorum

1. FeatureExtractor
2. DataSet
3. analizör

Ancak FeatureExtractor sınıfı hiçbir şeyi temsil etmez, onu bir sınıftan daha rutin hale getiren bir şey yapar. Kullanılacak tek bir işleve sahip olacaktır: extract_features ()

Bir şeyi temsil etmeyen, bir şeyi yapan sınıflar oluşturmak doğru mu?

EDIT: önemli olup olmadığından emin değilim ama Python kullanıyorum

Eğer extract_features () şöyle görünürse: bu metoda sahip olmak için özel bir sınıf oluşturmaya değer mi?

def extract_features(df):
    extr = PhrasesExtractor()
    extr.build_vocabulary(df["Text"].tolist())

    sent = SentimentAnalyser()
    sent.load()

    df = add_features(df, extr.features)
    df = mark_features(df, extr.extract_features)
    df = drop_infrequent_features(df)
    df = another_processing1(df)
    df = another_processing2(df)
    df = another_processing3(df)
    df = set_sentiment(df, sent.get_sentiment)
    return df

Sınıflar 1 şey yapmalı ve iyi yapmalı

Evet, bu genellikle iyi bir yaklaşımdır.

fakat diğer taraftan birlikte çalıştığımız gerçek nesneyi temsil etmelidirler.

Hayır, bu bir IMHO ortak yanlış anlaşılmasıdır. OOP'a iyi bir başlangıç ​​yapmak çoğu zaman “gerçek dünyadan şeyleri temsil eden nesnelerle başlamak” şeklindedir , bu doğrudur.

Ancak bununla bitmemelisin !

Programlarınızı çeşitli şekillerde yapılandırmak için sınıflar kullanılabilir (ve gerekir). Nesneleri gerçek dünyadan modellemek bunun bir yönüdür, ancak tek değildir. Belirli bir görev için modüller veya bileşenler oluşturmak, sınıflar için başka bir mantıklı kullanım durumudur. Bir "özellik çıkarıcısı" muhtemelen böyle bir modüldür ve hatta yalnızca bir genel yöntem içeriyorsa extract_features(), eğer çok fazla özel yöntem ve belki de ortak bir durum içermiyorsa şaşırırım. Bu yüzden bir sınıfa sahip olmak FeatureExtractor, bu özel yöntemler için doğal bir yer getirecektir.

Not: Ayrı bir modül kavramını destekleyen Python gibi dillerde de bunun için bir modül kullanılabilir FeatureExtractor, ancak bu soru bağlamında bu IMHO'nun ihmal edilebilir bir farkıdır.

Ayrıca, bir "özellik çıkarıcısı", "özellikleri çıkartan bir kişi veya bot" olarak hayal edilebilir. Bu soyut bir "şeydir", belki de gerçek dünyada bulacağınız bir şey değil, ama ismin kendisi, herkese o sınıfın sorumluluğunun ne olduğu hakkında bir fikir veren yararlı bir soyutlamadır. Bu yüzden bu sınıfın "hiçbir şeyi temsil etmediğini" kabul etmiyorum.

Doktor Brown açık: sınıfların gerçek dünyadaki nesneleri temsil etmesi gerekmez. Sadece faydalı olmaları gerekiyor . Sınıflar temel olarak yalnızca ek türlerdir ve gerçek dünyada neye intya da neye stringkarşılık gelir? Bunlar somut değil, somut şeyler olan soyut açıklamalardır.

Bu, davanızın özel olduğunu söyledi. Açıklamanıza göre:

Eğer extract_features () şöyle görünürse: bu metoda sahip olmak için özel bir sınıf oluşturmaya değer mi?

Kesinlikle haklısın: Eğer kodun gösterildiği gibi ise, onu bir sınıfa dönüştürmenin faydası yoktur. Orada ünlü bir konuşma Python sınıfların böyle kullanımları kod koku olduğunu savunuyor ve bu basit işlevleri genellikle yeterlidir. Davanız buna mükemmel bir örnek.

Sınıfların aşırı kullanımı, OOP’un 1990’larda Java ile ana akım haline gelmesinden kaynaklanmaktadır. Ne yazık ki, o zamanlar Java, bazı modern dil özelliklerinden (kapanışlar gibi) yoksundu; Örneğin, Java'da yakın zamana kadar durum taşıyan yöntemlere sahip olmak imkansızdı. Bunun yerine, devleti taşımak için tek bir yöntem ortaya çıkaran (buna benzer bir şey denilen invoke) bir sınıf yazmanız gerekiyordu .

Ne yazık ki bu programlama stili Java'nın ötesinde popüler oldu (kısmen aksi takdirde çok yararlı olan etkili bir yazılım mühendisliği kitabı nedeniyle ), bu tür geçici çözümler gerektirmeyen dillerde bile.

Python'da sınıflar çok önemli bir araçtır ve liberal olarak kullanılmalıdır. Ama onlar tek araç değiller ve onları anlam ifade etmeyen yerlerde kullanmak için hiçbir sebep yok. OOP'de serbest fonksiyonların yeri olmadığı yaygın bir yanılgıdır.

Uygulamamı tasarlıyorum ve SOLID ve OOP'yi doğru bir şekilde anladığımdan emin değilim.

20 yıldır bu işteyim ve ben de emin değilim.

Sınıflar 1 şey yapmalı ve iyi yapmalı

Burada yanlış gitmek zor.

Çalıştığımız gerçek nesneleri temsil etmelidirler.

Gerçekten? Beni her zaman tek ve en popüler ve başarılı sınıfa tanıştırayım: String. Metin için kullanıyoruz. Ve temsil ettiği gerçek dünya nesnesi şudur:

Neden hayır, tüm programcılar balık avına takılmaz. Burada metafor denilen bir şey kullanıyoruz. Gerçekten var olmayan şeylerin modellerini yapmak sorun değil. Net olması gereken fikir bu. Okuyucularınızın kafasında görüntüler yaratıyorsunuz. Bu görüntüler gerçek olmak zorunda değil. Sadece kolayca anladım.

İyi bir OOP tasarımı, mesajların etrafındaki mesajları (yöntemleri) kümeler (bu durum), böylece bu mesajlara verilen reaksiyonlar o verilere bağlı olarak değişebilir. Eğer bu gerçek dünyayı modelliyorsa, huysuz olun. Eğer değilse, oh iyi. Okuyucuya mantıklı geldiği sürece sorun değil.

Şimdi elbette, böyle düşünebilirsin:

ancak bunun metafordan yararlanmadan önce gerçek dünyada olması gerektiğini düşünüyorsanız, programlama kariyeriniz birçok sanat ve zanaat içerecektir.

Dikkat! SOLID hiçbir yerde bir sınıfın sadece "bir şey yapması" gerektiğini söylemez. Durum böyle olsaydı, sınıfların yalnızca tek bir metodu olurdu ve sınıflar ve fonksiyonlar arasında gerçekten bir fark olmazdı.

SOLID, bir sınıfın tek bir sorumluluğu temsil etmesi gerektiğini söylüyor . Bunlar bir takımdaki kişilerin sorumlulukları gibidir: Sürücü, avukat, yankesici, grafik tasarımcı vb.

Bunun amacı şudur: Gereksinimlerde bir değişiklik olursa, ideal olarak sadece tek bir sınıfı değiştirmeniz gerekir. Bu sadece kodu daha kolay anlaşılmasını, değiştirilmesini kolaylaştırır ve riski azaltır.

Bir nesnenin "gerçek bir şeyi" temsil etmesi gerektiği konusunda hiçbir kural yoktur. Bu sadece kargo kültüdür çünkü OO başlangıçta simülasyonlarda kullanılmak üzere icat edilmiştir. Ancak programınız bir simülasyon değil (birkaç modern OO uygulaması), bu nedenle bu kural geçerli değildir. Her sınıfın iyi tanımlanmış bir sorumluluğu olduğu sürece, iyi olmalısın.

Bir sınıf gerçekten sadece tek bir metoda sahipse ve sınıfın herhangi bir durumu yoksa, onu bağımsız bir fonksiyon haline getirmeyi düşünebilirsiniz. Bu kesinlikle gayet iyi ve KISS ve YAGNI ilkelerini takip ediyor - eğer bir işlevle çözebiliyorsanız bir sınıf oluşturmanıza gerek yok. Öte yandan, içsel duruma ya da çoklu uygulamalara ihtiyaç duyacağınıza inanmak için bir nedeniniz varsa, bunu bir sınıf önünden de yapabilirsiniz. Burada en iyi kararınızı kullanmanız gerekecek.

Bir şeyi temsil etmeyen, bir şeyi yapan sınıflar oluşturmak doğru mu?

Genel olarak bu tamam.

Biraz daha spesifik bir açıklama olmadan, FeatureExtractorsınıfın tam olarak ne yapması gerektiğini açıklamak zor.

Her neyse, FeatureExtractorsadece kamuya açık bir extract_features()işlev ortaya çıkarsa bile Strategy, bir çıkarımın tam olarak nasıl yapılması gerektiğini belirleyen bir sınıfla yapılandırmayı düşünebilirdim .

Başka bir örnek, Template işlevine sahip bir sınıftır .

Ve sınıf modellerine dayanan daha fazla Davranışsal Tasarım Örüntüsü var .

Açıklama için bazı kodlar eklediğiniz gibi.

Eğer extract_features () şöyle görünürse: bu metoda sahip olmak için özel bir sınıf oluşturmaya değer mi?

Çizgi

 sent = SentimentAnalyser()

tam olarak ne demek istediğimi, bir stratejiyi içeren bir sınıfı yapılandırabileceğinizi içerir .

Bu SentimentAnalysersınıf için bir arabiriminiz varsa FeatureExtractor, işlevinizdeki belirli bir uygulamaya doğrudan bağlanmak yerine, onu yapım aşamasında sınıfa aktarabilirsiniz .

Desenler ve tüm fantezi dili / kavramları bir kenara bırakın: Tökezlediğiniz şey bir İş veya Toplu İşlemdir .

Günün sonunda, saf bir OOP programının bile bir şekilde bir şey tarafından yönlendirilmesi gerekiyor, aslında iş yapmak; bir şekilde bir giriş noktası olmalı. Örneğin, MVC düzeninde "C" denetleyicisi GUI'den click etc. olaylarını alır ve ardından diğer bileşenleri düzenler. Klasik komut satırı araçlarında "main" işlevi aynı şeyi yapar.

Bir şeyi temsil etmeyen, bir şeyi yapan sınıflar oluşturmak doğru mu?

Sınıfınız bir varlık temsil yapar başka bir şey ve yönetir herşeyi. Sen bunu adlandırabilirsiniz Kontrolör , Job , Main ya da her türlü akla gelir.

Eğer extract_features () şöyle görünürse: bu metoda sahip olmak için özel bir sınıf oluşturmaya değer mi?

Bu şartlara bağlıdır (ve bunun Python'da olduğu gibi normal şekilde aşina değilim). Bu sadece küçük bir tek satırlık komut satırı aracıysa, sınıf yerine bir yöntem iyi olmalıdır. Programınızın ilk sürümü, kesinlikle bir yöntemle kurtulabilir. Daha sonra, belki de karışık olan küresel değişkenlerle bile onlarca yöntemle sonuçlandığını anlarsanız, o zaman sınıflara yeniden ateşleme zamanı gelmiştir.

OOP'yi bir sistemin davranışını modellemek olarak düşünebiliriz . Sistemin 'gerçek dünyada' olması gerekmediğine dikkat edin , ancak gerçek dünya metaforları bazen yararlı olabilir (örneğin, "boru hatları", "fabrikalar" vb.).

İstenilen sistem bir kerede hepsini modellemek için çok karmaşıksa, onu daha küçük parçalara bölebiliriz ve daha fazla parçalanmayı içerebilecek olanları ("sorun alanı") modelleyebiliriz; (az ya da çok) sayı, dize, liste vb. gibi bazı yerleşik dil nesnesininki

Bu basit parçalara sahip olduktan sonra, daha büyük parçalarda bir araya getirebileceğimiz daha büyük parçaların davranışını tanımlamak için onları bir araya getirebiliriz ve böylece, bir alan için ihtiyaç duyulan tüm alan bileşenlerini tanımlayana kadar devam edebiliriz. sistemi.

Bazı sınıfları yazabileceğimiz bu “bir araya getirme” aşamasıdır. İstediğimiz şekilde davranan varolan bir nesne olmadığında sınıfları yazarız. Örneğin, etki alanımızda "foos", "bar" adı verilen foos koleksiyonları ve "bazs" adı verilen bar koleksiyonları bulunabilir. Fooların stringlerle modellenecek kadar basit olduğunu fark edebiliriz, o yüzden bunu yaparız. Çubukların, içeriklerinin Python'un sağladığı hiçbir şeyle uyuşmayan belirli bir kısıtlamaya uymalarını gerektirdiğini buluyoruz, bu durumda bu kısıtlamayı uygulamak için yeni bir sınıf yazabiliriz. Belki bazların böyle bir özelliği yoktur, bu yüzden onları bir liste ile temsil edebiliriz.

Biz o Not olabilir bu bileşenlerin (Foo'larınız, barlar ve bazs) her biri için yeni bir sınıf yazmak, ama biz değil gerek zaten doğru davranışlarla bir şey varsa için. Özellikle, bir sınıfın yararlı olması için 'bir şeyler sağlaması gerekir (veri, yöntemler, sabitler, alt sınıflar vb.), Bu nedenle birçok özel sınıf katmanımız olsa bile , en sonunda bazı yerleşik özellikleri kullanmalıyız; Örneğin, foos için yeni bir sınıf yazarsak, muhtemelen sadece bir dize içerecektir, öyleyse neden foo sınıfını unutmuyorsunuz ve bar sınıfının bunun yerine bu dizeleri içermesi gerekiyor? Sınıfların aynı zamanda yerleşik bir nesne olduğunu unutmayın, sadece esnek bir yapıya sahipler.

Etki alanı modelimize sahip olduktan sonra , bu parçaların bazı özel örneklerini alabilir ve onları modellemek istediğimiz belirli bir sistemin "simülasyonuna" düzenleyebiliriz (örneğin, "için bir makine öğrenme sistemi ...").

Bu simülasyona sahip olduktan sonra, onu çalıştırabiliriz ve hey presto'ya göre ... (veya modellemekte olduğumuz herhangi bir şey) için bir makine öğrenme sistemi çalışıyor.

Şimdi, sizin özel durumunuzda bir "özellik çıkarıcı" bileşeninin davranışını modellemeye çalışıyorsunuz. Sorun şu ki, bir "özellik çıkarıcısı" gibi davranan yerleşik nesneler var mı, yoksa daha basit şeylere bölmeniz mi gerekecek? Özellik çıkarıcıları işlev nesnelerine çok benzer davranıyor gibi görünüyor, bu yüzden bunları modeliniz olarak kullanmanız iyi olur.

Bu tür kavramları öğrenirken akılda tutulması gereken bir şey, farklı dillerin farklı yerleşik özellikler ve nesneler sunabileceğidir (ve elbette bazıları "nesneler" gibi terminolojiyi bile kullanmazlar!). Bu nedenle, bir dilde anlam ifade eden çözümler başka bir dilde daha az faydalı olabilir (bu aynı dilin farklı sürümleri için de geçerli olabilir!).

Tarihsel olarak, birçok OOP literatürü (özellikle "tasarım desenleri") Python'dan oldukça farklı olan Java'ya odaklandı. Örneğin, Java sınıfları nesne değildir, Java çok yakın zamana kadar işlev nesnelerine sahip değildi, Java, katı tip denetime sahip (arayüzleri ve alt sınıfları teşvik ediyor), Python ördek tipini yazmayı teşvik ederken, Java modül nesnelerine sahip değil, Java tamsayıları / yüzer / vb. Nesneler değildir, Java'daki meta-programlama / içe dönüklük "yansıma" vb. gerektirir.

Java'yı seçmeye çalışmıyorum (başka bir örnek olarak, çok sayıda OOP teorisi, Python'dan yine çok farklı olan Smalltalk etrafında döner), sadece bağlam hakkında çok dikkatli düşünmemiz gerektiğine işaret etmeye çalışıyorum. çözümlerin geliştirildiği kısıtlamalar ve bunun içinde bulunduğumuz duruma uygun olup olmadığı.

Senin durumunda, bir işlev nesnesi iyi bir seçim gibi görünüyor. Bazı "en iyi uygulamalar" kılavuzunun neden fonksiyon nesnelerinden olası bir çözüm olarak bahsetmediğini merak ediyorsanız, bu kılavuzların eski Java sürümleri için yazılmış olması olabilir.

Pragmatik olarak konuşursak, "önemli bir şey yapan ve ayrı olması gereken çeşitli şeylere" sahip olduğumda ve net bir eve sahip olmadığımda, onu bir Utilitiesbölüme koyup adlandırma sözleşmem olarak kullanırım. yani. FeatureExtractionUtility.

Bir sınıftaki yöntemlerin sayısını unut; Bugün tek bir yöntemin yarın beş yönteme geçmesi gerekebilir. Önemli olan, çeşitli işlev koleksiyonları için bir yardımcı program alanı gibi açık ve tutarlı bir organizasyonel yapıdır.