Lære Segmentering og Aggregering | Oversikt Over Innkapsling

Når du utvikler programvare som skal være vedlikeholdbar og fleksibel, er det mange faktorer å ta hensyn til i prosessen, spesielt innen objektorientert programmering. Komposisjon og aggregasjon er grunnleggende konsepter som muliggjør opprettelse av komplekse systemer fra enklere komponenter, og er deler av innkapslingsparadigmet.

Komposisjon

Komposisjon er en designteknikk der en class inneholder objects av andre classes som medlemsvariabler. Disse medlemmene er viktige komponenter i den omsluttende class og har et sterkt eierskapsforhold. Når det omsluttende object blir ødelagt, blir også de sammensatte delene ødelagt. For eksempel:

Car.h

Engine.h


              123456789101112
            
#include "Engine.h"

class Car {
public:
    void Start() 
    {
        engine.Start(); // Start the engine
        std::cout << "Car started" << std::endl;
    }
private:
    Engine engine; // Engine object composition
};

Car-klassen komponerer et Engine-objekt. Når et Car-objekt opprettes, opprettes automatisk en Engine-instans som en del av komposisjonen.

Aggregasjon

Aggregasjon er en annen form for object-komposisjon der en class inneholder object fra andre classes, men de inneholdte instansene har et svakere forhold sammenlignet med komposisjon. Ved aggregasjon kan de inneholdte medlems-classes eksistere uavhengig og kan deles mellom flere classes.

Car.h

Engine.h


              123456789101112131415
            
#include "Engine.h"

class Car {
public:
    Car(Engine* engine) 
        : engine(engine) {}

    void Start() 
	{
        engine->Start(); // Start the engine
        std::cout << "Car started" << std::endl;
    }
private:
    Engine* engine; // Engine object aggregation
};

Car-klassen aggregerer et Engine-objekt ved hjelp av en peker. Car-klassen eier ikke Engine-objektet; den holder kun en referanse til det. Dette gjør at Engine-instansen kan eksistere uavhengig av Car-objektet og deles mellom flere instanser om nødvendig.

Valg mellom komposisjon og aggregering

Ved utforming av programvaresystemer er det viktig å nøye vurdere om man skal bruke komposisjon eller aggregering, basert på forholdet mellom klasser og objekter.

I sammenheng med Car- og Engine-klassene vil bruk av komposisjon være mer hensiktsmessig. Hver bil har vanligvis sin egen motor, og motoren er en integrert del av selve bilen. I tillegg forhindrer dette at Engine deles eller gjenbrukes på tvers av flere bil-objects, noe som også er fornuftig.

Alt var klart?

Takk for tilbakemeldingene dine!

Seksjon 3. Kapittel 5

Spør AI

Spør om hva du vil, eller prøv ett av de foreslåtte spørsmålene for å starte chatten vår

Suggested prompts:

Can you give more examples of composition and aggregation in real-world scenarios?

What are the main advantages and disadvantages of using composition versus aggregation?

How do I decide which approach to use in my own software design?

Awesome!

Completion rate improved to 3.13

Sveip for å vise menyen

Komposisjon

Car.h

Engine.h


              123456789101112
            
#include "Engine.h"

class Car {
public:
    void Start() 
    {
        engine.Start(); // Start the engine
        std::cout << "Car started" << std::endl;
    }
private:
    Engine engine; // Engine object composition
};

Car-klassen komponerer et Engine-objekt. Når et Car-objekt opprettes, opprettes automatisk en Engine-instans som en del av komposisjonen.

Aggregasjon

Car.h

Engine.h


              123456789101112131415
            
#include "Engine.h"

class Car {
public:
    Car(Engine* engine) 
        : engine(engine) {}

    void Start() 
	{
        engine->Start(); // Start the engine
        std::cout << "Car started" << std::endl;
    }
private:
    Engine* engine; // Engine object aggregation
};

Valg mellom komposisjon og aggregering

Ved utforming av programvaresystemer er det viktig å nøye vurdere om man skal bruke komposisjon eller aggregering, basert på forholdet mellom klasser og objekter.

Alt var klart?

Takk for tilbakemeldingene dine!

Seksjon 3. Kapittel 5