Bazı OO tasarım tavsiyeleri arıyorum

Endüstriyel bir ortamda vanaları açmak ve kapatmak için kullanılacak bir uygulama geliştiriyorum ve böyle basit bir şey düşünüyordum: -

public static void ValveController
{
    public static void OpenValve(string valveName)
    {
        // Implementation to open the valve
    }

    public static void CloseValve(string valveName)
    {
        // Implementation to close the valve
    }
}

(Uygulama, vanayı kontrol etmek için seri porta birkaç bayt veri yazacaktır - vana adından türetilen bir "adres" ve vanayı açmak veya kapatmak için "1" veya "0").

Başka bir geliştirici, her bir fiziksel valf için düzinelerce olan ayrı bir sınıf oluşturup oluşturmamamız gerektiğini sordu. Bunun PlasmaValve.Open()yerine kod yazmak daha hoş olacağını kabul ediyorum ValveController.OpenValve("plasma"), ama bu aşırı mı?

Ayrıca, akıldaki gelecekteki birkaç gereksinim ile tasarımın en iyi nasıl çözüleceğini merak ediyordum:

Açmak ve kapatmak için farklı değerler gerektiren yeni bir vanayı desteklememiz istenir (0 ve 1 değil).
Sadece "açık" veya "kapalı" yerine 0-100 arasında herhangi bir konuma ayarlanabilen bir valfi desteklememiz istenir.

Normalde bu tür bir şey için kalıtım kullanırdım, ama son zamanlarda kafamı "kalıtım üzerinde kompozisyon" etrafında toplamaya başladım ve kompozisyon kullanarak daha ince bir çözüm olup olmadığını merak ettim?

design design-patterns object-oriented

— Andrew Stephens
kaynak

Belirli bir vana (bir dize, belki bir enum değil) için bir tanımlayıcı ve OpenValve / CloseValve yöntemleri içinde kontrol akışı için gerekli herhangi bir bilgi olan genel bir vana sınıfı oluşturmak. Alternatif olarak, valv sınıfını soyut yapabilir ve her biri için ayrı uygulamalar yapabilirsiniz, burada açma / kapama vanası, farklı vanaların farklı açma / kapama mekanizmalarına sahip olması için verilen vana sınıfının içindeki mantığı çağırır. Ortak mekanizma temel sınıfta tanımlanacaktır.

— Jimmy Hoffa

Gelecekteki varsayımsal gereksinimler için endişelenmeyin. YAGNI.

— pdr

@pdr YAGNI çift kenarlı bir bıçaktır, genel olarak takip etmeye değer olduğuna katılıyorum, ancak gelecekteki sürdürülebilirlik veya okunabilirliğin YAGNI'yi ihlal etmesine yardımcı olmak için herhangi bir şey yapmayı söyleyebiliriz, çünkü YAGNI'nın kapsamını çok belirsiz buluyorum birçok. Bununla birlikte, birçok insan YAGNI'nın nerede kullanılacağını ve nereye atılacağını biliyor çünkü geleceği hesaba katmak size ciddi acı kazandıracak. Ben sadece bu spektrum üzerinde nereye inecek bilmiyorsanız millet YAGNI takip önermek dikkatli olmalıdır düşünüyorum.

— Jimmy Hoffa

Dostum, 'kalıtım üzerine kompozisyon' abartılıyor. Valve soyut sınıfını / arayüzünü yapardım ve sonra bunları PlasmaValve'e alt sınıflandırırdım. Ve sonra ValveController'ımın tam olarak hangi alt sınıf olduklarını umursamadan Valve (lar) ile çalışacağından emin olurum.

— MrFox

@suslik: Kesinlikle. Ayrıca SOLID ilkelerini anlamayan insanlar tarafından spagetti adı verilen mükemmel bir kod gördüm. Bununla sonsuza kadar devam edebiliriz. Demek istediğim, yerleşik ilkelerin (uzun yılların tecrübesinden doğan) elden çıkarılmasının, aşırı bağlılığın nedenini gördüğümden daha fazla sorun gördüğümdür. Ama her iki ucun da tehlikeli olduğunu kabul ediyorum.

— pdr

Yanıtlar:

Valve nesnesinin her bir örneği bu ValveController ile aynı kodu çalıştırırsa, o zaman tek bir sınıfın birden fazla örneği doğru yol olacaktır. Bu durumda, sadece vana nesnesinin yapıcısında hangi vanayı kontrol ettiğini (ve nasıl) yapılandırın.

Ancak, her bir vana kontrolünün çalışması için farklı bir kod gerekiyorsa ve mevcut ValveController, vana tipine bağlı olarak farklı şeyler yapan dev bir anahtar ifadesi çalıştırıyorsa, polimorfizmi kötü bir şekilde yeniden uyguladınız. Bu durumda, ortak bir tabana (eğer mantıklıysa) birden fazla sınıfa yeniden yazın ve tek sorumluluk ilkesinin tasarım kılavuzunuz olmasını sağlayın.

— stonemetal
kaynak

Kod kokusu olarak tip tabanlı anahtar ifadelerinden bahsetmek için +1. Geliştiricinin sadece KISS'i takip ettiğini iddia ettiği bu tür anahtar ifadelerini sık sık görüyorum. Tasarım ilkelerinin nasıl saptılacağına dair mükemmel bir örnek heh

— Jimmy Hoffa

Birden fazla örnek, vanaları sırayla bağlamayı kolaylaştırabilir ve gerçek tesis borularını kodunuzda yönlendirilmiş bir grafik olarak modellemenizi sağlar. Daha sonra, basınç birikmesini önlemek için bir başkası kapandığında bir vana açmak gibi bir şey yapmanız ya da bir "su darbesi" etkisi elde etmemeniz için tüm akış aşağı vanalarını kapatmak gibi derslere iş mantığı da ekleyebilirsiniz. vana tekrar açıldığında.

— TMN

Benim büyük sancı vanayı tanımlayan parametre için dizeler kullanmaktır.

En azından temel uygulama gereksinimlerini Valveiçeren bir sınıf oluşturun ve bunları bir sınıfa getAddressaktarın ve ValveControllervar olmayan vanalar oluşturamayacağınızdan emin olun. Bu şekilde, açma ve kapatma yöntemlerinin her birinde yanlış dizeleri işlemek zorunda kalmazsınız.

Eğer açık ve yakın çağrı çağıran kolaylık yöntemleri oluşturmak olsun ValveController, ama dürüst olmak gerekirse, diğer sınıflar gerektiğinde arayacak tek bir sınıfta seri bağlantı noktası (kodlama dahil) tüm iletişim tutmak istiyorum. Bu, yeni bir denetleyiciye geçiş yapmanız gerektiğinde yalnızca bir sınıfı değiştirmeniz gerektiği anlamına gelir.

Test etmeyi ValveControllerseviyorsanız, alay edebilmeniz için tek bir ton da yapmalısınız (veya operatörler için bir eğitim makinesi oluşturun).

— mandal ucube
kaynak

Hiç kimsenin daha önce test etmek için bir single önerdiğini hiç görmedim - genellikle başka şekilde gider.

— Kazark

dürüst olmak gerekirse singleton statik önlemek için daha fazla ve böylece iletişim senkronize edilebilir

— cırcır ucube