Pastāstiet par šablona projektēšanu, ko izmantojāt…

Izmantoja šādus projektēšanas modeļus:

MVC (Model-View-Controller): Programmas loģikas sadalīšana. Modelis pārvalda datus, Skats ir atbildīgs par attēlošanu, bet Kontrolieris apstrādā lietotāja mijiedarbību un atjauno modeli vai skatu. Tika izmantots Angular, kur komponenti daļēji īsteno šo ideju.
MVVM (Model-View-ViewModel): līdzīgs MVC, bet ievieš ViewModel kā starpnieku starp Skatu un Modeli. ViewModel satur biznesa loģiku datu attēlošanai un lietotāja darbību apstrādei. Aktīvi izmantots React un Vuex (Vue), kur programmas stāvoklis tiek centralizēti pārvaldīts.

// Reaktivitātes piemērs React ar useState
import React, { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0); // useState - MVVM daļa

  const increment = () => {
    setCount(count + 1); // Stāvokļa atjaunināšana ar setter
  };

  return (
    <div>
      <p>Count: {count}</p> {/* Stāvokļa rādīšana */}
      <button onClick={increment}>Increment</button> {/* Darbība, kas ietekmē stāvokli */}
    </div>
  );
}

Komponenta modelis: lietotāja saskarnes sadalīšana neatkarīgos, atkārtoti lietojamos komponentos. Katrs komponents inkapsulē savu loģiku, izkārtojumu un stilus. Tas ir mūsdienu ietvaru pamats, piemēram, React, Vue un Angular.

// Vienkārša React komponenta piemērs
function Button(props) {
  return (
    <button className="my-button" onClick={props.onClick}>
      {props.label}
    </button>
  );
}

Adapteris (Adapter): pārveido viena klases saskarni citā, ko sagaida klienti. Ļauj strādāt ar nesaderīgām saskarnēm. Tika izmantots trešo pušu bibliotēku vai API integrācijai ar dažādām metožu parakstiem.

// Adaptera piemērs, strādājot ar dažādiem API klientiem
class OldApi {
  getDataOld(id) {
    console.log(`Getting data from Old API for id ${id}`);
    return { id: id, name: `Item ${id}` };
  }
}

class NewApi {
  fetchDataNew(itemId) {
    console.log(`Fetching data from New API for item id ${itemId}`);
    return { itemId: itemId, label: `Product ${itemId}` };
  }
}

class ApiAdapter {
  constructor(apiClient) {
    this.apiClient = apiClient;
  }

  getData(id) {
    if (this.apiClient instanceof OldApi) {
      return this.apiClient.getDataOld(id);
    } else if (this.apiClient instanceof NewApi) {
      const newData = this.apiClient.fetchDataNew(id);
      return { id: newData.itemId, name: newData.label };
    }
    throw new Error("Nepalaikams API klientas");
  }
}

const oldApiAdapter = new ApiAdapter(new OldApi());
console.log(oldApiAdapter.getData(1));

const newApiAdapter = new ApiAdapter(new NewApi());
console.log(newApiAdapter.getData(2));

Iterators (Iterator): nodrošina veidu, kā secīgi piekļūt sastāvdaļa objekta elementiem, neizpaužot tā iekšējo pārstāvību. Izmanto ciklos (for...of) un masīvu metodēs (forEach, map, filter).

// Iteratora piemērs JavaScript
const numbers = [1, 2, 3, 4, 5];

// Tieša iteratora iegūšana
const iterator = numbers[Symbol.iterator]();

console.log(iterator.next()); // { value: 1, done: false }
console.log(iterator.next()); // { value: 2, done: false }
// ...
console.log(iterator.next()); // { value: undefined, done: true }

// Iteratora izmantošana for...of
for (const number of numbers) {
  console.log(number);
}

Dekorators (Decorator): dinamiski pievieno jaunas atbildības objektam, ļaujot paplašināt objekta funkcionalitāti bez tā struktūras izmaiņām. Tika izmantots HOC (Higher-Order Components) React vai dekoratori Angular/TypeScript.

// Higher-Order Component (HOC) React piemērs
function withLogging(WrappedComponent) {
  return function WithLogging(props) {
    console.log(`Komponents ${WrappedComponent.name} renderēts ar props:`, props);
    return <WrappedComponent {...props} />;
  };
}

// HOC piemērošana
const EnhancedButton = withLogging(Button);

// Uzlabotā komponenta izmantošana
// <EnhancedButton label="Klikšķini mani" onClick={() => console.log('Klikšķināts!')} />

Odininkas (Singleton): garantē, ka klasei ir tikai viens instances, un nodrošina globālu piekļuvi tam. Tika izmantots globālas stāvokļa pārvaldībai vai vienota pakalpojuma (piem., žurnāla, konfigurācijas) izveidei.

// Odininkas šablons
class ConfigManager {
  constructor() {
    if (ConfigManager.instance) {
      return ConfigManager.instance;
    }
    this.settings = {}; // Iestatījumu inicializācija
    ConfigManager.instance = this;
  }

  setSetting(key, value) {
    this.settings[key] = value;
  }

  getSetting(key) {
    return this.settings[key];
  }
}

const config1 = new ConfigManager();
const config2 = new ConfigManager();

console.log(config1 === config2); // true (viena un tā pati instances)

config1.setSetting('apiUrl', 'https://api.example.com');
console.log(config2.getSetting('apiUrl')); // https://api.example.com

Fabrikas metodes (Factory Method): definē saskarni objekta izveidei, bet ļauj apakšklasēm izlemt, kādu objektu izveidot. Tika izmantots dažādu lietotāja saskarnes elementu vai objektu izveidei pēc konfigurācijas.

Stratēģija (Strategy): definē algoritmu ģimeni, to inkapsulē un padara tos savstarpēji aizvietojamus. ļauj algoritmam mainīties neatkarīgi no klientiem, kuri to izmanto. Tika izmantots dažādu datu kārtošanas, formu validācijas vai notikumu apstrādes pieeju īstenošanai.

Šo modeļu izmantošana palīdzēja radīt strukturētāku, modulārāku, testējamu un uzturamu kodu.

Pastāstiet par šablona projektēšanu, ko izmantojāt savā izstrādē.