Clean Architecture ja suunnittelumallit käytännössä · Oppitunti

Refaktorointi suunnittelumalleilla

Oppikaa refaktoroimaan olemassa olevia koodikantoja järjestelmällisesti soveltamalla sopivia suunnittelumalleja rakenteen ja ylläpidettävyyden parantamiseksi.

Oppitunti 3/411 vaihetta

Refaktorointi suunnittelumalleilla on ilmainen Clean Architecture ja suunnittelumallit käytännössä-oppitunti CoddyKitissä. Tämä on oppitunti 3/4. Voit lukea koko oppitunnin alta ilmaiseksi ja harjoitella sen jälkeen käytännössä selaimessa sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla. Oppitunti kuuluu Clean Architecture ja suunnittelumallit käytännössä-oppimispolkuun, ja edistymisesi synkronoituu verkon ja CoddyKit-sovelluksen välillä. Clean Architecture ja suunnittelumallit käytännössä-kurssilla on yhteensä 4 oppituntia.

Uudelleensuunnittelu suunnittelumallien avulla

Mitä uudelleensuunnittelu tarkoittaa? Olemassa olevan koodin rakennetta parannetaan muuttamatta sen ulkoista toimintaa. Miksi siihen kannattaa yhdistää suunnittelumalleja? Mallit tarjoavat hyväksi havaittuja ja uudelleenkäytettäviä ratkaisuja yleisiin suunnitteluongelmiin, joten uudelleensuunnittelusta tulee järjestelmällisempää ja tehokkaampaa. Tämä johtaa selkeämpään, helpommin ylläpidettävään ja laajennettavaan koodiin.

Koodihajujen tunnistaminen

Ennen uudelleensuunnittelua on tiedettävä, mitä pitäisi muuttaa. Koodihajut ovat merkkejä siitä, että koodin suunnittelussa saattaa olla jotain vialla. Ne eivät ole virheitä, mutta ne voivat johtaa virheisiin tai vaikeuttaa koodin muuttamista.

Liian pitkä metodi: Metodi, joka tekee liikaa.
Liian suuri luokka: Luokka, jolla on liian monta vastuuta.
Toistuva koodi: Sama koodilogiikka esiintyy useassa paikassa.
Ehdollinen monimutkaisuus: Liian monta if/else- tai switch-lausetta.

Uudelleensuunnittelun järjestelmälliset vaiheet

Uudelleensuunnittelun pitäisi olla kurinalainen prosessi, ei hätäisesti tehty uudelleenkirjoitus. Tässä on yksinkertainen työnkulku:

Tunnista koodihaju: Etsi koodista kohta, jota voisi parantaa.
Valitse suunnittelumalli: Valitse malli, joka ratkaisee tunnistetun ongelman.
Sovella mallia: Tee pieniä, vaiheittaisia muutoksia ja varmista jokaisessa vaiheessa, että testit menevät läpi.
Testaa perusteellisesti: Varmista, että ulkoinen toiminta säilyy muuttumattomana.

Muistakaa: ”Red, Green, Refactor” on tehokas muistisääntö!

Ehdollisen logiikan strategia

Käsitellään yleistä koodihajua: metodeja, joissa on laajaa ehdollista logiikkaa (paljon if/else- tai switch-lauseita). Tällainen koodi on vaikealukuista, vaikeasti testattavaa ja hankalasti laajennettavaa. Strategy Pattern auttaa kapseloimalla muuttuvat toimintatavat erillisiksi ja keskenään vaihdettaviksi olioiksi.

Tarkastellaan yksinkertaista laskinta:

public class SimpleCalculator {
  public int calculate(String operation, int a, int b) {
    if ("add".equals(operation)) {
      return a + b;
    } else if ("subtract".equals(operation)) {
      return a - b;
    } else if ("multiply".equals(operation)) {
      return a * b;
    }
    throw new IllegalArgumentException("Unknown operation");
  }

  public static void main(String[] args) {
    SimpleCalculator calc = new SimpleCalculator();
    System.out.println("Add: " + calc.calculate("add", 5, 3));
    System.out.println("Subtract: " + calc.calculate("subtract", 5, 3));
  }
}

Uudelleensuunnittelu Strategy-malliin

Laskimen uudelleensuunnittelua varten otamme käyttöön Operation-rajapinnan ja kullekin operaatiolle oman strategialuokan. Tämän jälkeen Calculator käyttää Operation-strategian ilmentymää. Uusia operaatioita on helppo lisätä muuttamatta Calculator-luokkaa.

interface Operation {
  int execute(int a, int b);
}

class AddOperation implements Operation {
  @Override
  public int execute(int a, int b) {
    return a + b;
  }
}

class SubtractOperation implements Operation {
  @Override
  public int execute(int a, int b) {
    return a - b;
  }
}

public class RefactoredCalculator {
  private Operation operation;

  public void setOperation(Operation operation) {
    this.operation = operation;
  }

  public int calculate(int a, int b) {
    if (operation == null) {
      throw new IllegalStateException("Operation not set");
    }
    return operation.execute(a, b);
  }

  public static void main(String[] args) {
    RefactoredCalculator calc = new RefactoredCalculator();
    
    calc.setOperation(new AddOperation());
    System.out.println("Add: " + calc.calculate(5, 3));
    
    calc.setOperation(new SubtractOperation());
    System.out.println("Subtract: " + calc.calculate(5, 3));
  }
}

State-malli käyttäytymisen muutoksiin

Toinen yleinen koodihaju on olio, jonka käyttäytyminen muuttuu sen sisäisen tilan perusteella. Tätä hallitaan usein monilla if/else- tai switch-lauseilla olion metodeissa. State Pattern antaa olion muuttaa käyttäytymistään sisäisen tilansa muuttuessa, jolloin näyttää siltä kuin olio olisi vaihtanut luokkaansa.

Tarkastellaan liikennevaloa:

public class SimpleTrafficLight {
  private String currentState;

  public SimpleTrafficLight() {
    this.currentState = "RED"; // Initial state
  }

  public void change() {
    if ("RED".equals(currentState)) {
      currentState = "GREEN";
      System.out.println("Traffic light is now GREEN.");
    } else if ("GREEN".equals(currentState)) {
      currentState = "YELLOW";
      System.out.println("Traffic light is now YELLOW.");
    } else if ("YELLOW".equals(currentState)) {
      currentState = "RED";
      System.out.println("Traffic light is now RED.");
    }
  }

  public static void main(String[] args) {
    SimpleTrafficLight light = new SimpleTrafficLight();
    light.change(); // GREEN
    light.change(); // YELLOW
    light.change(); // RED
  }
}

Uudelleensuunnittelu State-malliin

State-mallissa määrittelemme liikennevalon tilalle rajapinnan (TrafficLightState) sekä kullekin tilalle konkreettisen luokan (RedState, GreenState, YellowState). TrafficLight-luokka säilyttää viitteen nykyiseen tilaolioon ja delegoi käyttäytymisen sille. Näin tilakohtainen käyttäytyminen eriytetään selkeästi.

interface TrafficLightState {
  void change(TrafficLight context);
}

class RedState implements TrafficLightState {
  @Override
  public void change(TrafficLight context) {
    System.out.println("Traffic light is now GREEN.");
    context.setState(new GreenState());
  }
}

class GreenState implements TrafficLightState {
  @Override
  public void change(TrafficLight context) {
    System.out.println("Traffic light is now YELLOW.");
    context.setState(new YellowState());
  }
}

class YellowState implements TrafficLightState {
  @Override
  public void change(TrafficLight context) {
    System.out.println("Traffic light is now RED.");
    context.setState(new RedState());
  }
}

public class TrafficLight {
  private TrafficLightState currentState;

  public TrafficLight() {
    this.currentState = new RedState(); // Initial state
  }

  public void setState(TrafficLightState state) {
    this.currentState = state;
  }

  public void change() {
    currentState.change(this);
  }

  public static void main(String[] args) {
    TrafficLight light = new TrafficLight();
    light.change(); // GREEN
    light.change(); // YELLOW
    light.change(); // RED
  }
}

Oikean suunnittelumallin valitseminen

Sopivan suunnittelumallin valitseminen voi olla haastavaa. Tässä on yleisiä koodihajuja ja niihin sopivia malleja:

Ehtolauseiden monimutkaisuus (if/else, switch): Usein ratkaistavissa Strategy-, State- tai Command-mallilla.
Toistuva koodi: Usein ratkaistavissa Factory Method- tai Template Method -mallilla tai siirtämällä yhteinen logiikka yliluokkaan.
Tiukka kytkentä: Facade-, Mediator- ja Observer-mallit voivat vähentää riippuvuuksia.
Yhteensopimattomat rajapinnat: Adapter-malli sopii tähän erinomaisesti.
Toiminnallisuuden lisääminen dynaamisesti: Decorator-malli.

Miksi refaktoroida suunnittelumallien avulla?

Suunnittelumallien järjestelmällinen soveltaminen refaktoroinnin aikana tarjoaa merkittäviä etuja:

Luettavuuden paraneminen: Mallit tarjoavat yhteisen sanaston ja rakenteen.
Ylläpidettävyyden paraneminen: Muutokset kohdistuvat rajattuihin kohtiin, ja ne on helpompi toteuttaa.
Laajennettavuuden paraneminen: Uusia ominaisuuksia voidaan usein lisätä muuttamatta olemassa olevaa koodia (Open/Closed Principle).
Testattavuuden paraneminen: Löyhästi kytketyt komponentit on helpompi testata yksikkötesteillä.

Se muuttaa vaikeaselkoisen koodin hyvin jäsennellyksi ja vankaksi järjestelmäksi.

Refaktoroinnin tietovisa

Kuvittele, että luokkanne käsittelee eri raporttimuotojen (PDF, CSV, XML) luontia suuren switch-lauseen avulla. Haluatte, että uusia muotoja on helppo lisätä muuttamatta raporttigeneraattorin ydinkoodia.

Vastaa interaktiivisessa oppitunnissa

Kertaus: refaktorointi suunnittelumallien avulla

Tänään opitte lähestymään refaktorointia järjestelmällisesti suunnittelumallien avulla. Tutustuimme yleisiin koodihajuihin ja näimme, kuinka Strategy- ja State-mallien kaltaiset mallit voivat muuttaa monimutkaisen ehtologiikan selkeämmäksi ja helpommin laajennettavaksi rakenteeksi.

Muistakaa, että refaktorointi on jatkuva prosessi. Suunnittelumallien ohjaamana se parantaa koodikantanne laatua ja muuntautumiskykyä merkittävästi.

Aloita maksutta

Opi Clean Architecture ja suunnittelumallit käytännössä tekoälytuutorin avulla — ilmaiseksi

Kirjoita ja suorita oikeaa koodia selaimessa, saa välitöntä apua tekoälytuutorilta ympäri vuorokauden ja jatka siitä, mihin jäit, verkossa tai sovelluksessa.

Kurssit: 12
Oppitunnit: 48

Aloita opiskelu maksutta Näytä koko kurssi

Usein kysytyt kysymykset

Onko oppitunti ”Refaktorointi suunnittelumalleilla” ilmainen?

Kyllä – oppitunnin ”Refaktorointi suunnittelumalleilla” koko tekstin voi lukea täällä verkossa ilmaiseksi. Jos haluat harjoitella interaktiivisesti sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla sekä avata koko Clean Architecture ja suunnittelumallit käytännössä-kurssin, päivitä CoddyKit PROhon. Clean Architecture ja suunnittelumallit käytännössä-kurssilla on yhteensä 4 oppituntia.

Mitä opin oppitunnilla ”Refaktorointi suunnittelumalleilla”?

Oppikaa refaktoroimaan olemassa olevia koodikantoja järjestelmällisesti soveltamalla sopivia suunnittelumalleja rakenteen ja ylläpidettävyyden parantamiseksi. Harjoittelet Clean Architecture ja suunnittelumallit käytännössä-aihetta koodilla, jonka suoritat suoraan selaimessa. Ympäri vuorokauden käytettävissä oleva tekoälytuutori vastaa kysymyksiisi oppitunnin aikana.

Tarvitsenko kokemusta aloittaakseni Clean Architecture ja suunnittelumallit käytännössä-opiskelun?

Aiempi kokemus ei ole tarpeen. CoddyKitin Clean Architecture ja suunnittelumallit käytännössä-oppimispolku sopii vasta-alkajista edistyneisiin, joten voit aloittaa tästä tai alusta ja edetä omaan tahtiisi. Tämä on oppitunti 3/4.

Kuinka kauan ”Refaktorointi suunnittelumalleilla”-oppitunnin suorittaminen kestää?

Useimmat CoddyKitin oppitunnit kestävät noin 5–10 minuuttia. Jokainen oppitunti on lyhyt ja interaktiivinen, joten edistyt tasaisesti ja voit jatkaa siitä, mihin jäit – sekä verkossa että sovelluksessa.

Voinko kirjoittaa ja suorittaa koodia tällä Clean Architecture ja suunnittelumallit käytännössä-oppitunnilla?

Kyllä. Jokainen Clean Architecture ja suunnittelumallit käytännössä-oppitunti sisältää sisäänrakennetun koodieditorin, joten voit kirjoittaa ja suorittaa oikeaa koodia suoraan selaimessa ja saada välitöntä palautetta tekoälyltä – paikallista asennusta ei tarvita.

Kaikki tämän kurssin oppitunnit

Dependency Inversion -periaatteen syvällinen tarkastelu
Interface Segregation käytännössä
Refaktorointi suunnittelumalleilla
Yhden vastuun periaatteen ja avoin–suljettu-periaatteen hallinta

← Takaisin: Clean Architecture ja suunnittelumallit käytännössä