Dynamic_cast kullanımını önlemek için uygun tasarım?

Bazı araştırmalar yaptıktan sonra sık karşılaştığım bir sorunu çözen basit bir örnek bulamıyorum.

Diyelim ki Square, s, Circles ve diğer şekilleri oluşturabildiğim, bir ekranda görüntüleyebildiğim, seçtikten sonra özelliklerini değiştirebildiğim ve ardından tüm çevrelerini hesaplayabildiğim küçük bir uygulama oluşturmak istiyorum .

Model sınıfını şöyle yaparım:

class AbstractShape
{
public :
    typedef enum{
        SQUARE = 0,
        CIRCLE,
    } SHAPE_TYPE;

    AbstractShape(SHAPE_TYPE type):m_type(type){}
    virtual ~AbstractShape();

    virtual float computePerimeter() const = 0;

    SHAPE_TYPE getType() const{return m_type;}
protected :
    const SHAPE_TYPE  m_type;
};

class Square : public AbstractShape
{
public:
    Square():AbstractShape(SQUARE){}
    ~Square();

    void setWidth(float w){m_width = w;}
    float getWidth() const{return m_width;}

    float computePerimeter() const{
        return m_width*4;
    }

private :
    float m_width;
};

class Circle : public AbstractShape
{
public:
    Circle():AbstractShape(CIRCLE){}
    ~Circle();

    void setRadius(float w){m_radius = w;}
    float getRadius() const{return m_radius;}

    float computePerimeter() const{
        return 2*M_PI*m_radius;
    }

private :
    float m_radius;
};

(Daha fazla şekil sınıfım olduğunu düşünün: üçgenler, altıgenler, her seferinde proprers değişkenleri ve ilişkili alıcılar ve ayarlayıcılar. Karşılaştığım problemlerin 8 alt sınıfı vardı ama 2'de durduğum örnek için)

Şimdi ShapeManagerbir dizi, tüm şekiller bir dizi depolama ve depolama var:

class ShapeManager
{
public:
    ShapeManager();
    ~ShapeManager();

    void addShape(AbstractShape* shape){
        m_shapes.push_back(shape);
    }

    float computeShapePerimeter(int shapeIndex){
        return m_shapes[shapeIndex]->computePerimeter();
    }


private :
    std::vector<AbstractShape*> m_shapes;
};

Son olarak, her şekil türü için her parametreyi değiştirmek için spinboxes ile bir görünüm var. Örneğin, ekranda bir kare seçtiğimde, parametre widget'ı yalnızca Squareilgili parametreleri (sayesinde AbstractShape::getType()) görüntüler ve karenin genişliğini değiştirmeyi önerir. Bunu yapmak için bana genişliği değiştirmek için izin veren bir işleve ihtiyacım var ShapeManagerve ben bunu nasıl yaparım:

void ShapeManager::changeSquareWidth(int shapeIndex, float width){
   Square* square = dynamic_cast<Square*>(m_shapes[shapeIndex]);
   assert(square);
   square->setWidth(width);
}

Sahip olabileceğim her alt sınıf değişkeni için dynamic_castalıcı / ayarlayıcı çiftini kullanmamı ve uygulamamı ShapeManagerengelleyen daha iyi bir tasarım var mı? Zaten şablonu kullanmaya çalıştım ama başarısız oldum .

Yüzleştiğim sorun Şekiller ile ancak gerçekten değil farklı Jobs : 3D yazıcı için (örn PrintPatternInZoneJob, TakePhotoOfZoneile, vs.) AbstractJobonların temel sınıf olarak. Sanal yöntem execute()değil getPerimeter(). Somut kullanımı kullanmam gereken tek zaman, bir işin ihtiyaç duyduğu belirli bilgileri doldurmaktır :

• PrintPatternInZone yazdırmak için nokta listesine, bölgenin konumuna, sıcaklık gibi bazı baskı parametrelerine ihtiyaç duyar

• TakePhotoOfZone fotoğrafın hangi bölgeye, fotoğrafın kaydedileceği yola, boyutlara vb. ihtiyaç duyar.

Daha sonra arayacağımda execute(), İşler yapmaları gereken eylemi gerçekleştirmek için ihtiyaç duydukları bilgileri kullanacaklar.

Bir İşin somut tipini kullanmam gereken tek zaman, bu bilgileri doldururken veya görüntülerken (a TakePhotoOfZone Jobseçilirse, bölge, yol ve boyut parametrelerini görüntüleyen ve değiştiren bir widget gösterilecektir).

Daha Jobsonra Jobs, ilk işi alan, yürüten (çağırarak AbstractJob::execute()), bir sonrakine gider, listenin sonuna kadar devam eden s listesine eklenir . (Bu yüzden miras kullanıyorum).

Farklı parametre türlerini saklamak için aşağıdakileri kullanıyorum JsonObject:

• avantajları: herhangi bir iş için aynı yapı, parametreleri ayarlarken veya okurken dynamic_cast yok

• Sorun: İşaretçileri saklayamıyor ( Patternveya veya Zone)

Veri depolamanın daha iyi bir yolu var mı?

O zaman bu tipin belirli parametrelerini değiştirmek zorunda kaldığım beton tipini nasıl saklarsınızJob ? JobManagersadece bir listesi var AbstractJob*.

Emerson Cardoso'nun "diğer önerisi" ni genişletmek istiyorum, çünkü genel durum için doğru yaklaşım olduğuna inanıyorum - tabii ki herhangi bir soruna daha uygun başka çözümler de bulabilirsiniz.

Sorun

Örneğin, AbstractShapesınıfta getType()temel olarak somut türü tanımlayan bir yöntem vardır. Bu genellikle iyi bir soyutlamaya sahip olmadığınızın bir işaretidir. Sonuçta, soyutlamanın tüm noktası, beton tipinin ayrıntılarını önemsemek zorunda değildir.

Ayrıca, aşina değilseniz, Açık / Kapalı Prensibi'ni okumalısınız. Genellikle bir şekil örneği ile açıklanır, böylece kendinizi evinizde gibi hissedersiniz.

Yararlı Soyutlamalar

Sanırım AbstractShapebunu bir şey için yararlı bulduğunuz için tanıttınız. Büyük olasılıkla, uygulamanızın bir kısmının, şeklin ne olduğuna bakılmaksızın şekillerin çevresini bilmesi gerekir.

Burası soyutlamanın mantıklı olduğu yerdir. Bu modül kendisini somut şekillerle ilgilendirmediğinden, AbstractShapesadece buna bağlı olabilir . Aynı nedenden dolayı, getType()yönteme ihtiyaç duymaz - bu yüzden ondan kurtulmalısınız.

Uygulamanın diğer kısımları sadece belirli bir şekil ile çalışır, örn Rectangle. Bu alanlar bir AbstractShapesınıftan yararlanamayacaktır , bu yüzden orada kullanmamalısınız. Bu parçalara sadece doğru şekli geçirmek için, beton şekilleri ayrı ayrı saklamanız gerekir. (Bunları AbstractShapeek olarak saklayabilir veya anında birleştirebilirsiniz).

Beton Kullanımını En Aza İndirme

Etrafında bir yol yok: bazı yerlerde beton tiplerine ihtiyacınız var - en azından inşaat sırasında. Bununla birlikte, bazen beton tiplerinin kullanımını birkaç iyi tanımlanmış alanla sınırlı tutmak en iyisidir. Bu ayrı alanların tek amacı farklı türlerle uğraşmaktır - tüm uygulama mantığı bunlardan uzak tutulur.

Bunu nasıl başarıyorsunuz? Genellikle, daha fazla soyutlama getirerek - mevcut soyutlamaları yansıtabilir veya yansıtmayabilir. Örneğin, GUI'nizin ne tür bir şekil ile uğraştığını gerçekten bilmesine gerek yoktur . Ekranda, kullanıcının bir şekli düzenleyebileceği bir alan olduğunu bilmek yeterlidir.

Bir özet tanımlamak Böylece ShapeEditViewhangi sahip RectangleEditViewve CircleEditViewgenişlik / yükseklik veya yarıçap fiili metin kutuları tutmak uygulamalar.

İlk adımda, bir oluşturduğunuzda bir RectangleEditViewzaman oluşturabilir Rectangleve ardından bir std::map<AbstractShape*, AbstractShapeView*>. Görünümleri istediğiniz gibi oluşturmayı tercih ederseniz, aşağıdakileri yapabilirsiniz:

std::map<AbstractShape*, std::function<AbstractShapeView*()>> viewFactories;
// ...
auto rect = new Rectangle();
// ...
auto viewFactory = [rect]() { return new RectangleEditView(rect); }
viewFactories[rect] = viewFactory;

Her iki durumda da, bu yaratma mantığının dışındaki kodun somut şekillerle uğraşması gerekmeyecektir. Bir şeklin tahrip edilmesinin bir parçası olarak, açıkça fabrikayı kaldırmanız gerekir. Tabii ki, bu örnek aşırı basitleştirilmiş, ancak umarım fikir açıktır.

Doğru Seçeneği Seçme

Çok basit uygulamalarda, kirli (döküm) bir çözümün paranızın karşılığını en iyi şekilde verdiğini görebilirsiniz.

Her somut tür için ayrı ayrı listelerin açıkça tutulması, uygulamanız esas olarak somut şekillerle ilgileniyor, ancak evrensel olan bazı parçalara sahipse, muhtemelen gidilecek yoldur. Burada, sadece ortak işlevsellik gerektirdiği sürece soyutlamak mantıklıdır.

Şekiller üzerinde çalışan çok fazla mantığınız varsa ve yolun şekli gerçekten uygulamanız için bir ayrıntıysa, tüm yol boyunca gitmek genellikle ödeme yapar.

Bir yaklaşım, belirli türlere döküm yapılmasını önlemek için işleri daha genel hale getirmektir .

Temel sınıfta, özellik adı için belirli bir anahtara dayalı olarak haritadaki bir değeri ayarlayan " boyut " kayan nokta özelliklerinin temel alıcısını / ayarlayıcısını uygulayabilirsiniz . Aşağıdaki örnek:

class AbstractShape
{
public :
    typedef enum{
        SQUARE = 0,
        CIRCLE,
    } SHAPE_TYPE;

    AbstractShape(SHAPE_TYPE type):m_type(type){}
    virtual ~AbstractShape();

    virtual float computePerimeter() const = 0;

    void setDimension(const std::string& name, float v){ m_dimensions[name] = v; }
    float getDimension() const{ return m_dimensions[name]; }

    SHAPE_TYPE getType() const{return m_type;}

protected :
    const SHAPE_TYPE  m_type;
    std::map<std::string, float> m_dimensions;
};

Ardından, yönetici sınıfınızda aşağıdaki gibi yalnızca bir işlev uygulamanız gerekir:

void ShapeManager::changeShapeDimension(const int shapeIndex, const std::string& dimension, float value){
   m_shapes[shapeIndex]->setDimension(name, value);
}

Görünüm içinde kullanım örneği:

ShapeManager shapeManager;

shapeManager.addShape(new Circle());
shapeManager.changeShapeDimension(0, "RADIUS", 5.678f);
float circlePerimeter = shapeManager.computeShapePerimeter(0);

shapeManager.addShape(new Square());
shapeManager.changeShapeDimension(1, "WIDTH", 2.345f);
float squarePerimeter = shapeManager.computeShapePerimeter(1);

Başka bir öneri:

Yöneticiniz yalnızca ayarlayıcıyı ve çevre hesaplamasını (Şekil tarafından da gösterilmektedir) açığa çıkardığından, belirli bir Shape sınıfını başlatırken uygun bir Görünümü başlatabilirsiniz. ÖRNEĞİN:

• Bir Square ve SquareEditView oluştur;
• Square örneğini SquareEditView nesnesine iletin;
• (isteğe bağlı) Bir ShapeManager'a sahip olmak yerine, ana görünümünüzde bir Şekiller listesi tutabilirsiniz;
• SquareEditView içinde, bir Square'e referans tutarsınız; bu, nesneleri düzenlemek için döküm ihtiyacını ortadan kaldıracaktır.