Sadece üzerinde bir yöntem çağırmak için sık sık bir nesne oluşturuyorsanız bir kod kokusu mu

Ben böyle bir şey gider kod çok olduğu bir kod tabanı miras:

SomeDataAdapter sda = new SomeDataAdapter();
sda.UpdateData(DataTable updateData);

Ve sonra sda bir daha asla kullanılmaz.

Bu yöntemlerin aslında statik sınıf yöntemleri olması gerektiğini gösteren bir kod kokusu mu?

UpdateData muhtemelen bir 'service' sınıfına ait olması gereken bir mimari kokusu olduğunu düşünürdüm.

Verilerin bir elma olduğu yerler. AppleAdapter hizmet / iş zekası sınıfıdır. AppleService, geçerli yöntemin dışında bulunan bir AppleAdapter için bir Singleton başvurusudur.

private static volatile AppleAdapter _appleService = null;
private static object _appleServiceLock = new object();
private AppleAdapter AppleService
{
    get
    {
        if (_appleService == null)
        {
            lock (_appleServiceLock)
            {
                if (_appleService == null)
                    _appleService = new AppleAdapter();
            }
        }
        return _appleService;
    }
}

public SomeAppleRelatedMethod(Apple apple)
{
    AppleService.UpdateData(apple);
}

Yaptığınız şeyin mutlaka yanlış olduğunu düşünmüyorum, ancak SomeDataAdapter gerçekten bir tür vatansız iş hizmetini temsil ediyorsa, o zaman bir singleton bunun için en iyi yöntem olacaktır. Umarım yardımcı olur! Sağlanan örnek, hem boş hem de tam olarak aynı anda iki veya daha fazla iş parçacığına erişilirse, _appleService ile ilgili hiçbir tartışmayı sağlamanın süslü bir yoludur.

Biliyor musun? SomeDataAdapter bir ADO IDbDataAdapter (ki neredeyse kesinlikle), tüm bu yanıt dikkate almayın!

: P

Orijinal soruya yorum ekleme iznim yok, ancak bu kodun bulunduğu yeri belirtebiliyorsanız.

Bu kod özel bir IDbDataAdapter uygulamasını temsil ediyorsa ve UpdateData bir IDbConnection, IDbCommand oluşturuyor ve hepsini sahnelerin arkasına bağlıyorsa, o zaman hayır bir kod kokusu olarak düşünmüyorum çünkü şimdi akışlar ve diğer bunları kullanmayı bitirdiğimizde bertaraf edilmesi gereken şeyler.

Bence bu problem bundan daha derine iniyor. Statik bir yönteme refactor yapsanız bile, o zaman her yerde tek bir statik yöntem çağırdığınız kodu alırsınız. Bence kendi içinde kod kokusu. Bazı önemli soyutlamaları kaçırdığınızı gösterebilir. Belki aralarında neler olduğunu değiştirmenize izin verirken, bazı ön ve son işlemler yapacak bir kod oluşturmak istersiniz. Bu ön ve son işlem, ortak çağrıları içerecekken, aradaki somut uygulamaya bağlı olacaktır.

Türü. Bu genellikle bir işlevi iletmek istediğiniz anlamına gelir ve seçtiğiniz dil size izin vermez. Bu biraz beceriksiz ve beceriksiz, ancak birinci sınıf işlevleri olmayan bir dilde sıkışırsanız, yapabileceğiniz çok şey yoktur.

Bu nesnelerin hiçbiri diğer işlevlere argüman olarak geçirilmezse, bunları statik yöntemlere dönüştürebilirsiniz ve hiçbir şey değişmez.

Eğer devleti tutmak belirli bir sınıfı daha faydalı, işlevsel… yeniden kullanılabilir hale getirirse hayır. Herhangi bir nedenle komut tasarım deseni akla geliyor; bu sebep kesinlikle Robert Harvey'nin boğulma arzusu değildir.

"Sıklıkla" tanımlayın. Nesneyi ne sıklıkla somutlaştırıyorsunuz? Çok - muhtemelen değil?

Sisteminizde endişelenmeniz gereken daha büyük sorunlar olabilir. Statik hale gelmek, programcıya nesnenin dahili durumunun değişmediği daha açık bir şekilde iletişim kuracaktır - harika.

Durum yine de dağınıksa ve ilk şeyi statik hale getirmek için başka şeyleri statik hale getirmeye başlamanız gerekiyorsa, hangi parçaların statik olması ve hangi parçaların gerekmediğini sormanız gerekir.

Evet bu bir kod kokusu, sadece küçük bir koku.

Statik bir yöntem haline getirin ve devam edin. Statik yöntemlerle ilgili yanlış bir şey yoktur. Bir kullanım modeli ortaya çıktığında, deseni soyutlama konusunda endişelenebilirsiniz.

Buradaki koku, bunun nesnelere sarılmış (minimum) prosedürel kod olmasıdır.

Bu işlemi veri tablosunda gerçekleştirmek istemeniz için bir neden olmalı , ancak bu işlemi bazı anlambilimi paylaşan (yani ortak bir anlamı olan) diğer ilgili işlemlerle modellemek yerine, yeni bir prosedür içinde yeni bir prosedür başlattı. sınıf ve denir.

İşlevsel bir dilde, işleri böyle yaparsınız;) ancak OO paradigmasında, bu işlemi içeren bazı soyutlamaları modellemek istersiniz . Ardından, bu modeli temizlemek ve bazı anlambilimi koruyan bir dizi ilgili işlem sağlamak için OO tekniklerini kullanırsınız.

Buradaki ana koku, yazarın sınıfları kullanıyor olması, muhtemelen derleyici gerektirdiği için, işlemleri kavramsal bir modelde organize etmeden.

Sorunlu alan yerine programın modellenmesini gördüğünüzde BTW dikkat edin . Tasarımın daha fazla düşünmeden yararlanabileceğinin bir işaretidir. Diğer bir deyişle, sınıfların hepsinin "xAdaptor" ve "xHandler" ve "xUtility" olduğuna dikkat edin ve genellikle bir anemik etki alanı modeline bağlı olun . Bu, aslında uygulamak istedikleri kavramları modellemenin aksine, kodun kolaylık sağlamak için toplandığı anlamına gelir.