Bir nesne bir varlığı temsil etmek zorunda mı?

Bir varlık olarakProduct , yani Motor, ParkingLotvb. Gibi bir şeyi , fiziksel, hatta kesin bir fiziksel olmayan kavramsal nesneyi kastediyorum - iyi tanımlanmış, net bir şekilde nesneye ait bazı temel veriler ve bazı işlevler / yöntemler. açıkça çekirdek veriler üzerinde çalışır.

Mesela, kendimde Demonbir varlık, belki de hayali bir nesneye sahip olabilirim, ancak fiziksel değil, yine de bir varlık olabilir.

Bir nesne sadece bir yöntemler topluluğu olabilir mi, ortak bir hedefle bağlanan ortak bir prosedürler dizisi olabilir mi?

Örnek: Bir sınıf çağrılabilir MotorOperationsmi MotorActions, yoksa varlığın olmadığı yerlerde, sınıf içindeki yöntemler gibi şeyler yapar.

• getMotorDataFromHTMLForm ()
• getMotorManufacturers ()
• selectMotorFromUserRequirements ($ gereksinimleri)
• canMotorCanHandleOperatingConditions ($ koşullar)
• computePowerConsumptionForMotor ($ id)

Bir sınıf tipik olarak, verilerdeki nesne + işlemlerinin merkezinde bulunan veriler olarak tanımlanır. Bu nedenle Motor, motor özelliklerine ilişkin bazı motor değişkenleri olabilir ve bir şey üretmek için bu verileri birleştiren işlemler olabilir.

Benim durumumda , sınıf içinden geçen data + verileri üzerinde işlem yapan bir sınıfım olması gibi , sınıf içi geçici veriler dışında, "Motor İşlemleri" için merkezli bir veri bulunmuyor.

Soru

Sınıflar varlıksız nesneleri temsil edebilir mi? Eğer değilse, neden kötü / eksik / OOP merkezli değiller? OOP ile uyumlu olması için kavramsal olarak değiştirilmesi / iyileştirilmesi gereken yollar var mı?

Hayır , bir nesnenin bir varlığı temsil etmesi gerekmez.

Aslında, nesneler hakkında fiziksel varlıklar olarak düşünmeyi bıraktığınızda, OOP'nin vaat ettiği faydaları elde ettiğiniz zaman olduğunu iddia edeceğim.

Bu en iyi örnek değil, ama Kahve Makinesi tasarımı muhtemelen ışığın benim için gelmeye başladığı yer.

Nesneler mesajlarla ilgilidir. Sorumluluklar hakkında. Arabalar, Kullanıcılar veya Siparişler ile ilgili değiller.

OO'ya bu şekilde öğrettiğimizi biliyorum, ancak birkaç denemeden sonra, MVC, MVVM veya MVWhatever'i denediğinizde işlerin nereye gittiğini anlamanın ne kadar temelden sinir bozucu olduğunu görünce ortaya çıkıyor. Ya modellerin gülünç şişkinleşir ya da kontrolörlerin yapar. Gezinme özelliği için, Araçlara dokunan herhangi bir şeyin Vehicle.ext dosyasında olduğunu bilmek harika, ancak uygulamanız Araçlar hakkında olduğunda, kaçınılmaz olarak o dosyada 3000 satırlık spagetti kalıyor.

Gönderilecek yeni bir mesajınız olduğunda, en az bir tane yeni nesneniz ve belki bir çiftiniz olur. Bu nedenle, bir yöntem demeti hakkındaki sorunuzda, potansiyel olarak bir mesaj demeti hakkında konuştuğunuzu iddia ediyorum. Ve her biri kendi nesnesi olabilir, yapacak işi de vardır. Ve bu tamam. Her şeyi birbirinden ayırdığınızda, gerçekten bir arada olması gerekenler ortaya çıkacak. Ve onları bir araya getirdin. Ancak, OO'nun tadını çıkarmak istiyorsanız, kolaylık olması için her yöntemi belirsizce uygun bir çekmeceye hemen düşürmeyin.

Fonksiyon çantalarından bahsedelim

Bir nesne sadece bir yöntem koleksiyonu olabilir ve yine de OO olabilir, ancak benim "kurallarım" oldukça katı.

1. Tahsilatın tek bir sorumluluğu olmalı ve bu sorumluluk "Motorlara iş yapar" kadar genel olamaz. Hizmet katmanı cephesi gibi bir şey yapabilirim, ancak gezinme / keşif nedenlerinden dolayı tembel olduğumun farkındayım, OO kodu yazmaya çalışıyorum.

2. Tüm yöntemler tutarlı bir soyutlama katmanında olmalıdır. Bir yöntem Motor nesnelerini alırken, diğeri Beygir gücü döndürürse, bu muhtemelen birbirinden çok uzaktır.

3. Nesne aynı "tür" veri üzerinde çalışmalıdır. Bu nesne motorlara bir şey yapar (başlat / durdur), bu krank uzunluğu olan şeyleri yapar, bu bir ateşleme sekansını işler, bu bir html formu alır. Bu veriler makul bir şekilde nesnenin üzerindeki alanlar olabilir ve uyumlu görünebilir.

Genelde bu tür nesneler yapıyorum; dönüşümler, kompozisyonlar yaparken ya da sadece değişkenlik konusunda endişelenmek istemiyorum.

Nesne sorumluluklarına odaklanmanın beni uyuma götürdüğünü biliyorum. Bir nesne olmak için bir miktar uyum olması gerekir, ancak bir nesne olması için herhangi bir alan veya çok fazla davranış olması gerekmez. Bu 5 motor yöntemine ihtiyaç duyan bir sistem inşa ediyor olsaydım, bunları yapan 5 farklı nesne ile başlardım. Ortak bulduğum gibi, ya bir şeyleri birleştirmeye başlar ya da ortak "yardımcı" nesneleri kullanırdım. Bu beni açık / kapalı kaygılara sürüklüyor - bu işlevsellik parçasını nasıl çıkarabilirim, böylece belirli bir dosyayı bir daha asla değiştirmek zorunda kalmayabilirim ama yine de gerektiğinde kullanabilirim?

Nesneler mesajlarla ilgilidir.

Alanlar bir nesneye zar zor gelir - kayıtları almak ve ayarlamak, program dışındaki dünyayı değiştirmez. Diğer nesnelerle işbirliği yapmak işi halleder. Bununla birlikte, OO'nun gücü soyutlamalar yaratabildiğimiz için tüm bireysel ayrıntıları bir kerede düşünmek zorunda kalmayız. Sızan veya anlam ifade etmeyen soyutlamalar problemlidir, bu yüzden zihinsel modellerimizle eşleşen nesneler yaratma konusunda derinden (çok, belki de) düşünüyoruz.

Anahtar soru: Bu iki nesnenin neden birbiriyle konuşması gerekiyor?

Nesneyi bir insandaki organ olarak düşünün - varsayılan bir amacı vardır ve yalnızca ilgilendiği belirli bir mesajı aldığında davranışını değiştirir.

Yaya geçidinde olduğunuz ve bir arabanın hızlı bir şekilde geldiği bir senaryo düşünün. Beyin nesnesi olarak bir stres etkeni tespit ediyorum. Hipotalamusa kortikotrofin salgılayan hormon göndermesini söylüyorum. Hipofiz bezi bu mesajı alır ve adrenal kortikotrofik hormonu serbest bırakır. Adrenal bezler bu mesajı alır ve adrenalin oluşturur. Kas nesnesi bu adrenalin mesajını aldığında büzülür. Kalp aynı mesajı aldığında, daha hızlı atıyor. Caddenin karşısındaki sprint yapma davranışını başlatmaya dahil olan bütün bir oyuncu zinciri var ve önemli olan mesajlar. Beyin nesnesi, hipotalamusun uyarıyı göndermesini nasıl sağlayacağını bilir, ancak sonunda davranışı gerçekleştirecek olan nesneler zincirini bilmiyor. Aynı şekilde, kalp, adrenalinin nereden geldiği hakkında hiçbir fikri yok.

Dolayısıyla bu ( basitleştirilmiş ) örnekte, böbreküstü bezi nesnesinin yalnızca ACTH'yi nasıl alacağını ve adrenalini nasıl yapacağını bilmesi gerekir. Bunu yapmak için herhangi bir alana ihtiyacı yok, ancak yine de bana bir nesne gibi görünüyor.

Şimdi eğer uygulamamız sadece caddeye sıçramak için tasarlandıysa, hipofiz bezine ve böbreküstü bez nesnelerine ihtiyacım olmayabilir. Ya da sadece kavramsal olarak "hipofiz bezi modeli" olarak görebileceklerimizin sadece küçük bir kısmını yapan hipofiz bezi nesnesine ihtiyacım var. Bu kavramların tümü kavramsal varlıklar olarak mevcuttur, ancak bu bir yazılımdır ve AdrenalineSender veya MuscleContractor'ı yapabiliriz veya ne olursa olsun, modelimizin "eksikliği" hakkında endişelenmeyin.

Sınıflar varlıksız nesneleri temsil edebilir mi? Eğer değilse, neden kötü / eksik / OOP merkezli değiller? Değiştirilmeleri / iyileştirilmeleri gereken yollar var mı?

Kısacası, her şeyi yapabilirsiniz, ancak bu özel senaryo OOP ilkelerine aykırı olabilir :)

Tarif ettiğiniz şey bazen "yarar" sınıfı olarak adlandırılır - genellikle kod kokusunun bir işareti. Bazı yöntemleri bir arada tutmak için sınıf oluşturmaktan kaçınmak istiyorsunuz.

Uygulamanızdaki her nesnenin bir motor veya araba gibi gerçek hayattaki bir varlık ile bağlantılı olması gerekmez; bunlar iş objeleri. Başvurunuzda, işletme nesnelerinizin çoğunu kullanmanız olasıdır, ancak listeledikleriniz gibi, işletme varlıklarının parçası olmayan diğer işlemler için de biraz daha ayrılmaya ihtiyacınız olacak.

Ortak mimari kalıplara bir göz atmalısınız - bunlardan biri MVC (Model-View-Controller) .

MVC kullanarak listelediğiniz yöntemleri dağıtıyor olsaydım, yaptığım şey şu:

Sınıfı Görüntüle:

• GetMotorDataFromHTMLForm ()

Model Sınıfı (Esasen Motorlu):

• GetMotorManufacturer ()
• CanMotorHandleOperationConditions ()
• CalculatePowerConsumption ()

Denetleyici Sınıfı (MotorsController):

• GetAllMotors ()
• GetMotorById ()
• GetMotorByUserRequirements ()

PHP kullanıyor gibisiniz; bakmak için iyi bir MVC çerçevesi Laravel'dir . Örneklerinde hangi yöntemlerin ait olduğunu iyi gösterirler.

Bir başka, daha genel bilgi kaynağı, yöntemlerin nereye ait olduğuna karar vermenin nasıl GRASP ve SOLID ilkeleri olduğuna karar verir .

Sınıflar varlıksız nesneleri temsil edebilir mi?

Yapabilmek? Evet. Meli? Muhtemelen hayır - ya da en azından bir şeyi nasıl ifade ettiğinizi.

Nesneler, fiziksel bir nesneyi doğrudan temsil etmediklerinde en iyisidir, çünkü gerçeklik çok nadiren kodlamaya çok uygundur. Ancak, uyumlu bir kavramı veya kod nesnesini temsil etmeleri gerekir. Tek bir yapışkan sorumluluğu temsil etmeleri gerekir.

Sadece teğetsel olarak ilgili fonksiyonların bir demetini bir araya getirmek, bir isim alanı veya bir modül - OOP parlance içindeki bir nesne değil. Bunlar faydalı olabilir, ancak aynı değillerdir ve etkili bir şekilde çalışmak için farklı bir kullanım / düşünce tarzı gerektirir.

Bir sınıf bir şeyi modellemelidir - aksi takdirde anlamsızdır. Bununla birlikte, modellenen fiziksel bir "şey" olmayabilir; bunun yerine, 'gerçek' olmayan, ancak modellenmekte olan sistemi kontrol etmek için gereken bir şeyin temsili olabilir. Örneğin, trafik ışığı kontrol sisteminde, bazı işlemlerin yapılması gerektiğini belirtmek için sistemin bir kısmından diğerine gönderilen bir sinyali temsil eden bir tür ControlSignal sınıfına sahip olabilirsiniz. "Gerçek dünyada", bu sinyaller bir kutudan diğerine teller arasında iletilen elektriksel darbelerden oluşabilir. Somut bir nesne olarak "gerçek" olmayan bir şeyi modelleme sürecine "yeniden birleşme" denir.

İyi şanslar.

Hayır. (Başlık tam tersini sormak için düzenlendi!)

Örneğin:

Public class MyRepository
{
    public MyObject GetObject(string id)
    {
        //get data from the DB and build an object
    }
}

veya

Public class MyService
{
    public MyObject3 ProcessData(MyObject1 obj1, MyObject2 obj2)
    {
         //perform a process which is not a sole responsiblity of obj1 or obj2
    }
}

Ancak, genel olarak, OOP'un ardındaki ideal

public struct Car
{
    public Wheel[] Wheels;
}

public int CountWheelsOnCar(MyCarStruct car)
{
   return car.Wheels.Length;
}

için

public class Car
{
    private Wheel[] wheels;
    Public int CountWheels()
    {
        return this.wheels.Length;
    }
}

Sınıfları kodlarken gerçek dünyada bir şeyi görselleştirmenin yararlı olduğunu düşünüyorum ama gerekli değil.

Aslında, ne kadar gerçek olmak istediğinize bağlı olarak, birlikte çalıştığımız birçok nesnenin fiziksel temsili yoktur. Örneğin - MVC mimarisini düşünün. Gerçek dünyada, genellikle sınıflarla temsil edilmelerine rağmen, Model veya Kontrolör yoktur. Üçü birlikte genellikle bir şeyi temsil eder, ancak her zaman değil - ama söylediğim gibi muhtemelen gerçekten bir şeye uyum sağlayabileceksiniz (ve SOMETHING'in yardımcı olduğunu hayal edebilmek! sen gerçek dünyada göreceksin).

Çoğunlukla OO hakkında öğreneceğiniz bu “Kurallar” sadece OO'da günlük olarak kodlamak için kullandığınızda bir kez endişelenmeniz gereken şeyleri düşünmemeye yönlendirmenizi amaçlayan kılavuzlardır.

Bu arada, OO'nun kendisi bir derde deva değil ve bazı çözümleri kodlamadaki ilk geçişiniz boyunca size pek yardımcı olmuyor, ancak doğru yapılırsa kod düzenlemenin gerçekten harika bir yol olduğunu düşünüyorum. sonradan kolayca anlaşıldı. Bakım yapılabilir kod yazmak, muhtemelen yazılım geliştirmedeki en zor görevlerden biridir ve çoğu durumda (devam eden hata ayıklama / bakım gerektiren herhangi bir şey) en önemli olanıdır.

Bir nesne bir varlığı temsil etmek zorunda mı?

Soru: Hangi varlığı Loggertemsil eder?

Mecazi değil - kelimenin tam anlamıyla.

OOP'yi öğrencilere açıklarken, fiziksel dünyaya benzeyen nesneleri açıklamakta fayda var.

Alan Kay - babalarından biri OOP - Aşağıdaki yazdı:

[...]

Orijinal anlayışı aşağıdaki bölümleri vardı.

• Nesnelerin biyolojik hücreler ve / veya bir ağdaki ayrı bilgisayarlar gibi olduklarını, yalnızca mesajlarla iletişim kurabildiklerini düşündüm.
• Verilerden kurtulmak istedim.

[...]

OOP bana sadece mesajlaşma, yerel tutma ve koruma anlamına gelir ve

devlet sürecinin gizlenmesi ve her şeyin aşırı geç bağlanması.

neredeyse inanılmaz HW mimarisi. Farkettim ki

hücre / tüm bilgisayar metaforu verilerden kurtulur

kaynak

Bundan nesneler en iyisi olarak anlaşılır

• verileri kapsayan / gizleyen otarkiç nesneler

• mesajlar yoluyla diğer nesnelerle iletişim kurmak

Sınıflar varlıksız nesneleri temsil edebilir mi?

Kesinlikle: Düşün Math

Örneğinizle ilgili olarak:

Örnek: Bir sınıfa MotorOperations veya MotorActions adı verilebilir, burada varlık yoktur, ancak sınıf içindeki yöntemler gibi şeyler yapar

• getMotorDataFromHTMLForm ()

• getMotorManufacturers ()

• selectMotorFromUserRequirements ($ gereksinimleri)

• canMotorCanHandleOperatingConditions ($ koşullar)

• computePowerConsumptionForMotor ($ id)

Bu yöntemleri nereye koyacağınıza karar vermek için şunlara bir göz atmanız gerekir responsibilities: kimin neye karşı sorumlu olduğu .

getMotorDataFromHTMLForm ()

Bu tür bir yöntemin bağlamında olacaktır bir motorlu bir nesne oluşturmak . Bir form aracılığıyla alınan Veriden kendisini oluşturmak motorun sorumluluğunda değildir . En az iki nesne var; biri motor, diğeri ise motorun yaratıcısı .

getMotorManufacturers ()

İçinde böyle bir yöntem yazdığı tipik bağlam a service.

selectMotorFromUserRequirements ($ gereksinimleri)

Bu aynı zamanda bir servicebağlamda kullanılacaktır

canMotorCanHandleOperatingConditions ($ koşullar)

Bu bir motorhedef için bir soru

computePowerConsumptionForMotor ($ id)

Bu da en iyi sorulan bir motorun kendisi.

tl; Dr.

Fiziksel nesnelerobjects olarak metafor, yardımcı olmaktan daha rahatsız edicidir.

Evet, bunu yapabilirsiniz. Ancak, esasen bir prosedür kütüphanesiyle aynı işlevselliği sağlamak için bir sınıf yaratıyorsunuz. Bunu yapmanın tek nedeni, dilinizin prosedür modüllerinden (örneğin, Java veya Ruby) yok olmasıdır.

Prosedürel modülleri olan bir dilde (PHP'nin prosedür modülleri olduğunu düşünüyorum), sadece prosedür modülünü kullanmayı düşünebilirsiniz.

Ayrıca, sınıfınızı yeniden tasarlamayı düşünebilirsiniz, böylece sınıfın bir örneği tutarlı bir nesneyi temsil eder.

Ancak, yalnızca OO olma uğruna değil, size ekstra güç verirken yalnızca OO gösterimini kullanın!

Layman'ın sözleriyle

• Tanımladığınız şeye yardımcı sınıf denir.
• Hiçbir devleti yoktur, yani bunun birkaç örneğine gerçekten ihtiyacınız olmayacak demektir.
• Tüm yöntemler statiktir, yani her şeyi parametre olarak iletmeniz gerekir

Bu tür sınıflar mevcuttur; örneğin, Java SDK, yalnızca koleksiyonlarda çalışan veya geri dönen statik yöntemlerden oluşan Koleksiyonlar sınıfına sahiptir.

Dolayısıyla cevap hayır olacaktır, tüm sınıfların bir etki alanı öğesinden modellenmesi gerekmez.

Öte yandan, bu sınıflar sadece birkaçıdır veya bir OOP dilinde yapılan bir programda sadece birkaçıdır, çünkü OOP'un gerçek gücü polimorfizm ve kapsüllemedir.

Bir yerden diğerine gitmek için uçağı kullanarak değil de otoyollarda sürerek bir uçak kullanmak gibi olur. Uçakların arabaları gibi tekerlekleri vardır, ancak uçmaları amaçlanmıştır.

Hayır, bir sınıf sadece somutlaştırılabilecek, üyeleri olan ve miras alınabilecek bir şeyi temsil eder.

Aslında, dilinizde birden fazla kez başlatılmayan statik sınıflar olabilir.

.NETMath , varlığı temsil etmeyen (matematiğin ne olduğu hakkında felsefi olmak istemediğiniz sürece ...) "profesyonel" bir sınıfa harika bir örnektir ve aynı zamanda böyle bir sınıfın meşru bir kullanım durumunu göstermektedir. Yalnızca yöntemleri ve 2 alanı vardır (her ikisi de bireysel sabitleri temsil eder).

Benzer bir kütüphanenin sınıf hiyerarşisi, Math.Netmatematiksel / sayısal yöntemleri türlerine göre sınıflara ayırır. Burada sınıflar bir varlığı değil, mantıklı bir kategoriyi temsil eder.

Ben kendimi sık sık ilgili (statik) işlevler çantasından başka bir şey olmayan (statik) sınıflar ya da tek bir merkezi yerde uygun bir şekilde gruplanmış bir grup sabitler oluşturabilirim. Bunun iyi bir tasarım olduğunu iddia etmem ama bazen en basit çözüm.

Sorularınızın cevapları nihayetinde “sınıf” ve “varlık” gibi terimlerin tam olarak nasıl tanımlandığına bağlıdır. Hem fiziksel hem de kavramsal varlıklara izin vererek, ikincisini tanımlamak için iyi bir iş çıkardınız. Fakat "sınıf" için "saflaştırıcılar" her zaman "belirli bir iç temsili olan nesnelerin somutlaştırılması için bir fabrika" olacak ve pragmatistler için bu terim, puristler tarafından aşağılanan Java veya C ++ şeylerini kapsayacaktır. Pragmatistler Java ve C ++ 'ın söyleyebileceği, ancak hangilerinin Alan Kay' nın "Kayıtsız nesne yönelimini icat ettim ve sana söylemedim" akılda C ++ var "] ( Öyleyse * Alan Kay gerçekten" nesne yönelimli "terimi ile ne demek istedi? ).

Pragmatik görünümüne bakarsanız, örnek niteliğindeki yarar sınıflarınızı kabul edebilirsiniz. Ancak saf görüş daha ilginç. Kay'a göre OOP her zaman sınıflardan ziyade mesajlarla ilgili olmuştur . Yani sorularınız için:

Sınıflar varlıksız nesneleri temsil edebilir mi?

Hayır. Sınıflar nesneleri sınıflandırır . Sınıflar, tanım gereği new, nesne üretmek gibi bir mesaj gönderdiğiniz varlıklardır . Bir nesne, bir sınıftan yapılmış bir varlıktır. Nesneleri üretmek ve sınıflandırmak için sınıflar mevcuttur. Sınıfların yaptığı budur. Sınıflar nesneler oluşturur. Nesneleri sınıflandırmak için sınıfları kullanıyoruz. Bu nedenle eğer C, yalnızca başlatmaya veya alt sınıfa izin vermeyen bir yöntem demetiyse, C tarafından sınıflandırılan herhangi bir nesne olamaz, bu nedenle C bir sınıf değildir.

Eğer değilse, neden kötü / eksik / OOP merkezli değiller?

Fena değiller. Sadece onlara sınıf deme. Yöntemlerin bir paket olan şey bir yöntemi çağırmak için bir mesaj gönderebilir, ancak bir nesne örneğini sürece bu bir sınıf değil: OOPable. Ruby'yi tanıyor musun? Ruby'de bir modül bir yöntemler grubudur. Bir sınıf nesneleri örneğini bir modüldür. Bir modül hakkında kötü bir şey yok . Fakat bir sınıfı bir modülden farklı kılan şey (saf OOP terimleriyle) bir sınıfın örnekleri olabileceğidir. Bir modül sadece bazı yöntemlerdir. Karışıklık, C ++ ve Java ile diğer dillerin hem sınıf hem de modül için "sınıf" terimini kullanmasıdır .

Şimdi, belirli örneklerden birine bakmak için MotorOperations, mesajı computePowerConsumptionForMotorargümanla gönderebileceğiniz bir sınıf hakkında soru sorabilirsiniz id. Kötümü? En azından, Soru Sorma İlkesini ihlal etmiyor . Biz Do sahip bir motorlu sınıfını yapmak ve ona gönderme powerConsumptionmesajı? Belki de zamanın% 100'ü değil, ama belki de böyle şeyler yapmaya çalışmak kodunuz hakkında bazı güzel içgörülere yol açacaktır. Veya, kötü olabilecek küçük sınıfların patlamasına yol açabilir.

OOP ile uyumlu olması için kavramsal olarak değiştirilmesi / iyileştirilmesi gereken yollar var mı?

"OOP yapmak" sizin için önemliyse, bir sistemi birbirine mesaj göndererek iletişim kuran bileşenlere dönüştürmenin yollarını aramak istersiniz. Bu sadece OOP'nin ne olduğu veya en azından terimin belirleyicisinin aklında olan şeydir. Yardımcı program sınıfları bu görünümde OOP değildir. Ancak bazı insanlar için olabilir.

Tamamı sınıflardan örneklenen milyonlarca canlı, nefes alan, nesneden büyük bir sistem yapmaya çalışmak bazı projeler için işe yarayabilir. Ancak, kendinizi yapay, yanlış ses veren sınıflar oluştururken bulursanız, modüller tanıtılmalıdır. Sınıfları vurgulamaya çalışın ve başlatılabilir sınıfların saçma olduğu durumlarda modülleri kullanın.

TL; DR - yöntem paketleri her zaman kötü değildir. İlk önce somutlaştırılabilir sınıfları kullanmaya çalışın. Sadece gerektiğinde "modüllere" geri dönün.

Verilen örneklerin alınması:

getMotorDataFromHTMLForm()
selectMotorFromUserRequirements($requirements)

Bunlar “fabrika” yöntemlerine benziyor, bu da Motornesneyi geri getirecek . İkincisi, ya gereksinimleri karşılayacak yeni bir nesne yarattığınızı ya da incelemekte olduğunuz bir veritabanına ya da bellekte bir koleksiyona sahip olduğunuz anlamına gelir. Bu durumda bu konuda bir yöntem olmalı. Veya gereksinimler nesnesindeki bir yöntem olabilir.

getMotorManufacturers()

Onları nereden alıyorsun? Bunun bir yöntemi olmalıydı.

canMotorCanHandleOperatingConditions($conditions)
computePowerConsumptionForMotor($id)

Bunlar üzerinde yöntem olması gerektiği gibi görünüyor Motor.

Bir nesne, yüksek uyumu olan bir yöntem ve veri topluluğudur. Onlar bir sınıfa mensupturlar çünkü birbirleriyle çok ilişkili ve devletleri koruyorlar.

Bu, büyük ön tasarım kullanıyorsanız ve her şeyi modelleme girişiminde bulunuyorsanız ya da nesneyi o andaki sistemin gereksinimlerine uyan her şeye yineleyen ve geliştiren ortaya çıkan tasarımı tasarlarsanız geçerlidir.

Devleti korumak için bir nedeniniz yoksa, muhtemelen bir nesneyi somutlaştırmak için hiçbir nedeniniz yoktur, yani bir sınıfa sahip olmak için muhtemelen bir neden yoktur. Aksi takdirde, kullandığınız dil, sınıf kullanmaktan başka bir ad alanı tanımlayamaz. Hangi sınıf kullanmak iyi olmalı çünkü deyimsel olurdu.

Sınıfları normalden başka bu şekilde kullanmanın olumsuz yönlerini düşünemiyorum. Bir "ad alanı" nı başlatmak zorunda kalarak, gereksiz maliyet ve karmaşıklığı davet etmek. Bu kodu destekleyen herkes, verilerin nereden bilişsel yüke mal olduğunu merak edecektir (büyük olasılıkla kişi başına bir kerelik maliyet). Herhangi bir ek değer olmadan sıradışı bir kullanımdır.