stanford-oval/wikipedia huggingface dataset:
Juha Molari
Mediahuomio > Venäjällä

Venäjällä Molari tunnetaan yli puolesta tuhannesta liiketaloutta, kuluttajien käyttäytymistä ja kansainvälisiä suhteita käsittelevästä lausunnosta eri venäläisissä medioissa. Venäjällä on paljon herättänyt huomiota myös Molarin kritiikki Aleksei Navalnyin väitettyjä amerikkalaisia rahoitussuhteita vastaan. Venäjällä sai paljon huomiota myös se, kun Molari erosi lokakuussa 2011 luterilaisesta kirkosta ja liittyi Venäjän ortodoksiseen kirkkoon.
Mediahuomio > Suomessa

Suomessa Molarin Venäjä-suhteet ovat paremmin tunnettu lausunnoistaan suomalais-venäläisten lasten huostaanotto- ja huoltajuuskiistoissa, kuten Anton Salosen tapauksessa. sekä kritiikistä Kavkaz-Center -sivuston toimintaa vastaan. Saara Jantunen on Infosota-teoksessaan arvioinut Molarin toimivan Venäjän informaatiosodassa. Yhdysvaltalaisen radiokanavan Voice of American (VOA) johtaja James Brooke moitti 21.4.2012 Molaria osana RT-kanavaa Kremlin propagandasta Yhdysvaltoja vastaan. Molari on ollut yhteistyössä informaatiosodan teemassa Venäjän ulkoministeriön diplomaattiakatemian professori Viktor Manoilon kanssa, joka on myös liittynyt Molariin diplomaattiakatemian informaatiosodan tutkimuksissaan muun muassa Georgian sodasta.
Syytöksiä

Molarin kerrotaan osallistuneen papinpuvussa The Soviet Story -elokuvan esitystä vastustavaan mielenosoitukseen Tampereella ja Helsingissä, mikä johti tutkintapyyntöihin poliisille ja kanteluihin Espoon hiippakunnan tuomiokapitulille. Poliisi ei aloittanut asiassa tutkintaa. Molari kiisti osallistuneensa tapahtumaan papinpuvussa, myöntää sen verran että papinpuku oli toisessa tilaisuudessa mutta sen päällä oli takki. Tuomiokapituli käynnisti tutkinnan ja epäili Molaria Stalinin tekojen puolustelusta. Se julisti asiaa koskevat asiakirjat toistaiseksi salaisiksi ja siirsi asian kurinpitoasiamiehelle. Kurinpitoasiamiehen vaatimuksen mukaisesti Molari sai kirjallisen varoituksen. Pariisin Venäjä-kulttuurikeskus, professori Jean-Pierre Arrignon ja Venäjän kulttuurikeskuksen presidentti Irène Commeau esittivät vetoomuksen Euroopan valtioille Molarin oikeuksien puolesta.
Kaukasian islamistien verkkosivusto Kavkaz Center on syyttänyt Molaria Venäjän tiedustelupalvelun FSB:n agentiksi ja ”terroristiksi”. Tapauksesta on kerrottu useassa venäläisessä tiedotusvälineessä.
Molari on kertonut saaneensa tšetšeenien separatistihallinnon Itškerian tšetšeenitasavallan presidentiltä Doku Umarovilta sähköpostin, jossa hän ja hänen perheensä uhataan mestata.
Marraskuussa 2010 Kavkaz Centerin ylläpitäjä Mikael Storsjö johti 20 tšetšeenin mielenosoituksen Molaria vastaan jumalanpalveluksen aikana. Mukana oli myös Suomalais-venäläinen kansalaisfoorumi -järjestön jäseniä. Storsjön mukaan Molari on esittänyt vihamielisiä kommentteja Suomen tšetšeenipakolaisista.
Koko maailman venäläisten kansojen neuvosto eli Moskovan ja koko Venäjän patriarkan johtama ortodoksisen kirkon neuvosto vetosi 15. huhtikuuta 2011 Molarin puolesta: ”Olemme varmoja, että Juha Molari nähdään mielellään Venäjän ortodoksisen kirkon jäsenenä, joka ei koskaan flirttaile terroristien kanssa eikä pelkää heidän uhkauksiaan. Ortodoksit tarvitsevat nyt todella tällaisia rohkeita ihmisiä”.
Tuomiot

Helsingin käräjäoikeus tuomitsi 16. lokakuuta 2020 Juha Molarin viiden kuukauden ehdolliseen vankeusrangaistukseen toimittaja Jessikka Aron vainoamisesta ja toisen naisen törkeästä kunnianloukkauksesta. Oikeuden mukaan Molari vainosi Aroa esimerkiksi ottamalla häneen yhteyttä tai kirjoittamalla valheellisia ja halventavia kirjoituksia Arosta. Molarin mukaan lähes kaikki kirjoitukset olivat reagointia johonkin Aron tekoon tai häneen kohdistuneisiin valheellisiin väitteisiin. Molari tuomittiin maksamaan korvauksia rikosten aiheuttamista vahingoista, ja hänen maksettavakseen määrättiin myös oikeudenkäyntikulut. Oikeus kohtuullisti Molarin rangaistusta, koska oikeudenkäynti oli venynyt pitkäksi ja Molarin oikeutta oikeudenmukaiseen oikeudenkäyntiin oli siten loukattu.
Teoksia > Väitöskirja

Molari, Juha: Q-evankeliumi ja psykohistoria: Uuden testamentin eksegetiikan väitöskirja.  Helsinki:  Helsingin yliopisto, 2009.  ISBN 978-952-92-4839-1  Teoksen verkkoversio (PDF).
Teoksia > Muita teoksia

Missä viipyy Jumalan valtakunta?  (Iustitia – Muuttumaton ja muuttuva)  Helsinki:  STI: SLEY-kirjat, 1991.  ISBN 951-617-960-6
Lex Naturae, Regula Aurea ja lapsenmielisten moraali.  (Iustitia – Paavali ja laki)  Helsinki:  STI: Yliopistopaino, 1995.  ISBN 952-9857-02-0
Ihminen on kulttuurinsa tuote.  (Syntyjä syviä)  Vantaa:  Osumakirjat, 1995.  ISBN 951-602-008-9
Venäjästä ilman fobiaa ja russofobiasta.  Helsinki:  omakustanne, 2010.  ISBN 978-952-92-7026-2
Normaaleja ajatuksia.  (V-M. Hynninen, Miksi minusta pappi)  Helsinki:  Edico OY, 2009.  ISBN 978-952-5708-37-0
The Government and Middle-Size Enterprises in Finland and Sweden.  (Государство и бизнес. Вопросы теории и практики: моделирование, менеджмент, финансы.)  Санкт-Петербург:  СЗАГС, 2011.  ISBN 978-5-89781-364-3
University – Business Partnership Programmers. Университет – Бизнес-Программы Партнерства.  (Государство и бизнес. Вопросы теории и практики:  Материалы V Международной научно-практической конфереции. Северо-западный институт управления – филиал РАНХиГС.)  Санкт-Петербург:  СЗАГС, 2013.  ISBN 978-5-89781-513-5
Euraasian Unioni - oikeassa paikassa oikeaan aikaan. PDF. 2013.  Helsinki:  omakustanne, 2013.  ISBN 978-952-93-1927-5
Aiheesta muualla

Sitaatteja aiheesta Juha Molari Wikisitaateissa
Wikiuutisissa on aiheeseen liittyvä uutinen: Kantelu Pohjan seurakunnan kirkkoherrasta tuomiokapitulille
Juha Molarin kotisivu.
Juha Molarin blogi.
Juha Molari: Venäjästä ilman fobiaa ja russofobiasta (Arkistoitu – Internet Archive). (2010, PDF, ISBN 978-952-92-7026-2)
Suunnittelumalli

Suunnittelumalli (engl. Design Pattern) on ohjelmistotekniikassa ohjelmistorakenteen käsitteelliset (abstraktit) avainkohdat määrittävä kuvaus toistensa kanssa yhteistoiminnassa olevista luokista ja olioista. Suunnittelumalli sisältää yleisellä tasolla esitetyn ratkaisun johonkin oliopohjaisen suunnittelussa esiintyvään tavanomaiseen tilanteeseen tai kohteeseen. Suunnittelumalli perustuu käytännön kokemukseen ratkaisun toimivuudesta tietyssä tilanteessa, ja sen käytöstä on pitkä kokemus. Suunnittelumallin tärkeimmät osat ovat ongelma, ongelmayhteys ja ratkaisu. Suunnittelumallia voidaan käyttää työvälineenä suunniteltaessa ohjelman konkreettista arkkitehtuuria.
Yleistä

Suunnittelumalli on yleiskäyttöinen, käytännössä toimiva, uudelleenkäytettävä ja oliosuuntautunut ohjelmointilähtökohta, jota aloitteleva ohjelmoija ei tunne. Suunnittelumalli voi myös koskea ohjelman suppeaa yksityiskohtaa. Suunnittelumallin määrittelyssä kerrotaan sen käyttökohde, käyttöä rajoittavat tekijät, mallin seuraukset ja sen vahvuudet ja heikkoudet. Suunnittelumallin käyttö edellyttää riittävät ominaisuudet omaavan oliokielen käyttöä (esimerkiksi C++). Paras keino ymmärtää ja omaksua suunnittelumalli on sen tutkiminen.
Suunnittelumallissa ei ole tärkeintä malli itse, vaan se suunnittelukokemus ja asiantuntemus, joka sitä käyttäen saadaan säilytettyä ja siirrettyä muille ohjelmoijille. Kerätty informaatio tulee esittää käytännönläheisessä, selkeässä ja järjestelmällisessä muodossa, jolloin malli antaa käytännön ohjelmointityöhön järjestetyn ja valmiin kokoelman tiettyihin tilanteisiin sopivia ratkaisuja. Suunnittelumalleja ei tule käyttää tilanteissa, joista niistä ei ole hyötyä.
Ohjelmistoarkkitehtuurin kannalta suunnittelumallit käsittelevät yleensä suhteellisen pieniä yksiköitä (mikroarkkitehtuuria), mutta suunnittelumalleja voidaan käyttää myös koko sovelluksen perusrakenteessa (makroarkkitehtuuri). Suunnittelumallien ideaa on sovellettu käänteisenä keräämällä ns. antisuunnittelumalleja, joissa esitetään virheellisiä suunnitteluratkaisuja. Antisuunnittelumallia voidaan käyttää tunnistamaan ohjelmarakenteen virheitä ja suositeltavan suunnittelumallin soveltamiseen virheen poistamiseksi.
Historia

Suunnittelumallin käyttö ohjelmistotekniikassa perustuu amerikkalaisen arkkitehdin Christopher Alexanderin esittämään ajatukseen (Alexander, C. & ym. (1977). A Pattern Language. New York: Oxford University Press) siitä, että rakentaminen perustuu hyväksi havaittujen ratkaisumallien keräämiseen, oppimiseen ja toistamiseen. Eräät ohjelmistotekniikan tutkijat (Kent Beck, Jim Coplien, Erich Gamma, ym.) tutustuivat näihin ajatuksiin, ja ryhtyivät kehittämään niiden käyttöä ohjelmointitekniikan yhteydessä.
Vuoden 1994 elokuussa pidetty PLoP-konferenssin (Pattern Language of Programming) jälkeen aloitettiin useita projekteja suunnittelumallien löytämiseksi. Vuoden 1995 alussa Erich Gamma, Richard Helm, Ralph Johnson ja John Vlissides ("Gang of Four") julkaisivat Design Patterns: Elements of Reusable Object-Oriented Software, jossa esitettiin 23 suunnittelumallia.
Aikaisemmin Kent Beck ja Ward Cunningham toivat suunnittelumallit ohjelmistosuunnitteluun vuoden 1987 OOPSLA-konferenssissa. Vaikka he käyttivätkin esittelemiään suunnittelumalleja olio-ohjelmoinnin suunnittelussa, eivät ne olleet oliosuunnittelumalleja sanan nykyisessä merkityksessä, vaan niitä voidaan pitää käytettävyysmalleina. Erich Gamma oli käsitellyt suunnittelumalleja vuonna 1991 julkaistussa väitöskirjassaan, ja häntä pidetään suunnittelumallien tärkeimpänä kehittäjänä.
Suunnittelumallin sisältö

Suunnittelumallia kuvataan yleensä sen perustiedoilla, jotka määrittelevät mallin ja kuvaavat sen toiminnan.Nämä perustiedot ovat nimi, ongelman kuvaus, ratkaisun kuvaus ja ratkaisun vaikutukset ohjelmistoon ja tietokoneen laitteisiin. Muita suunnittelumallista esitettäviä tietoja voivat olla mm. luokittelu, mallista käytettävät muut nimet, esimerkki käyttötilanteesta, soveltuvuus, rakenteen esittäminen kaaviolla, malliin kuuluvat luokat ja niiden välinen tehtävien jako (vastuut), luokkien väliset rajapinnat, toteutuksessa esiintyvät ongelmat (esim. ohjelmointikielen vaikutus), esimerkki mallin toteuttamisella ohjelmointikielellä, esimerkkejä käytöstä todellisissa ohjelmissa ja mallia muistuttavat muut mallit ja mallit, joiden kanssa mallia olisi hyvä käyttää.
Suunnittelumallin sisältö > Nimi

Suunnittelumallin nimi kuvaa mallin sisältämän periaatteen lyhyesti ja yksiselitteisesti. Mallin nimen perusteella voidaan nopeasti hahmottaa käytetty rakenne, sen tuottama hyöty ja siihen liittyvät rajoitukset. Mallin nimi auttaa ohjelmiston suunnittelemaan ajattelemaan ohjelmistorakennetta yleisellä (abstraktilla) tasolla, ja sen käyttö voi helpottaa suunnittelijoiden välistä keskustelua. Suunnittelumallin nimen tulisi olla osa suunnittelijan ammattisanastoa, mutta tilannetta on vaikeuttanut mm. se, että sama suunnittelumalli on nimetty eri nimillä tai käytännössä samat suunnittelumallit on nimetty eri nimillä. Samaa nimeä voidaan myös käyttää eri suunnittelumalleille.
Suunnittelumallin sisältö > Ongelma

Ongelma (Problem) kuvaa ohjelmoinnissa esiintyvää tavanomaista tilannetta, jonka ratkaisemisessa suunnittelumalli on ollut hyödyksi. Ongelman kuvaus voi olla laaja arkkitehtuuriin liittyvä tai sitten suppeampi, esim. tietyn algoritmin kuvaus. Suunnittelumalli voi joskus sisältää ominaisuuksia, joiden vuoksi sitä ei ole tarkoituksenmukaista käyttää muissa kuin erityistilanteissa. Nämä erityistilanteet on kuvattu tässä osassa suunnittelumallin määrittelyä. Ongelman tulee ilmetä toistuvasti monenlaisissa ohjelmistoissa ja sen tulee olla yleisluontoinen (esim. ohjelmointikielestä riippumaton). Muut kuin arkkitehtuuri- tai yksityiskohtaiseen suunnitteluun liittyvät ongelmat rajataan pois.
Ongelma esittää tilanteen, jossa mallia voidaan soveltaa. Ongelman kuvaus esitetään tarkasti identifioituna, mikä helpottaa käyttöalueen määritystä. Kuvaus voi myös esittää jonkin tyypillisen joustamattoman rakenteen, jota on parannettava. Suunnittelumallia ei ole syytä käyttää ellei ongelman kuvaus vastaa toteutettavassa ohjelmistossa esiintyvää ongelmatilannetta. Yleisesti voidaan todeta, että suunnittelumallien tehokas soveltaminen vaatii huolellista pohdintaa, sillä mallien soveltaminen voidaan tehdä vain suppeasti määritellyllä ongelma-alueella. Joskus ongelman kuvaus sisältääkin listan ehdoista joiden tulee täyttyä ennen kuin on hyödyllistä soveltaa suunnittelumallia.
Suunnittelumallin sisältö > Ongelmayhteys

Ongelmayhteys (Context) kuvaa sen kokonaisuuden, jossa ongelma ilmenee, ja se kertoo sen, missä tilanteissa suunnittelumallia voidaan käyttää. Ongelmayhteys määrittää lisäksi ratkaisulle asetettavia vaatimuksia ja niitä ohjelman laatuominaisuuksia, joita ratkaisun tulisi parantaa. Usein ongelma ja ongelmayhteys esitetään yhdessä, ja niitä havainnollistetaan esimerkeillä.
Suunnittelumallin sisältö > Ratkaisu

Ratkaisu (Solution) kuvaa mahdollisen ohjelmointirakenteen ja sen osat (esim. luokat, oliot, algoritmit), osien väliset suhteet ja niiden välisen vuorovaikutuksen (yleensä funktiokutsut) yleisellä tasolla. Ratkaisun antamia ohjelmoinnin suuntaviivoja on käytettävä käsitteellisenä runkona laadittaessa käytännön ratkaisua käsillä olevaan ohjelmointiongelmaan. Ohjelmistosuunnittelija arvioi tapauskohtaisesti sen, miten mallin ratkaisu sopii kyseessä olevaan tilanteeseen. Ratkaisun tulee olla sovellettavissa yleisesti ohjelmoinnissa, ja se tulee pystyä esittämään yleisti käytössä olevalla mallinnuskielellä (esim. UML). Ratkaisun yleiskäyttöisyydestä voi seurata se, että ohjelmiston laatuominaisuudet (esim. nopeus) heikkenee.
Ratkaisu on suunnittelumallin tärkein asia, ja se esitetään usein staattisena rakenteena (esim. UML:n luokkakaavio) jota täydennetään dynaamisen vuorovaikutuksen kaaviolla (esim. UML:n sekvenssikaavio). Kuvausta voidaan täydentää pseudokoodikuvauksella, joka kuvaa ohjelman kulun vaihe vaiheelta.
Ratkaisun tehtävänä on muodostaa yleinen kuvaus ongelman ratkaisusta. Ratkaisu kuvaa toteutuksessa käytettävät luokat, rajapinnat ja oliot, sekä niiden suhteet yleisellä tasolla. Vaikka ratkaisun rakenne esitetään yleensä UML-kaaviolla tai jollain muulla oliorakennetta kuvaavalla yleisesti tunnetulla kuvaustavalla (notaatio), ei ratkaisu kuvaa mitään erityistä tilannetta vaan yleisen tavan ratkaisulle. Tosin yksinkertainen esimerkki helpottaa ratkaisun toteutustavan ymmärtämistä. Ratkaisussa ei yleensä oteta kantaa käytettävään ohjelmointikieleen, mutta esimerkiksi moniperinnän puuttuminen osasta oliokieliä saattaa hankaloittaa ratkaisun toteuttamista. Yleisesti suunnittelumalleissa ei käytetä jonkin tietyn kielen erityisominaisuuksia ongelman ratkaisuun.
Suunnittelumallin sisältö > Seuraukset

Seuraukset kuvaa mallin vaikutusta ohjelman sisäiseen ja ulkoiseen toimintaan, sekä sen käytöstä seuraavia hyviä ja huonoja seikkoja. Ohjelmistojen toiminnan kannalta tärkeitä seurauksia ovat mm. muisti ja suoritusaika ja ohjelmiston uudelleenkäyttö. Ohjelmiston uudelleenkäytön kannalta tärkeitä seurauksia ovat mm. käytetyn mallin vaikutus ohjelman laajennettavuuteen, muunneltavuuteen ja siirrettävyyteen. Mikään suunnittelumalli ei tuota joka suhteessa parasta ratkaisua, vaan kukin niistä optimoi tietyt ohjelman laatuominaisuudet ja heikentää muita. Seurausten kuvaaminen auttaa suunnittelijaa arvioimaan sitä, miten malli soveltuu käsillä olevaan suunnittelutilanteeseen. Seurauksista kertominen helpottaa suunnittelumallin soveltamista käytännön ohjelmistotyössä.
Suunnittelumallin sisältö > Toteutusnäkökulma ja esimerkit

Toteutusnäkökulma kertoo käytännön ohjelmoinnissa esiintyvien tilanteiden ratkaisemisesta, esimerkiksi kertomalla mallin käytöstä eri ohjelmointikieliä käytettäessä. Toteutusnäkökulma on pidettävä erillään suunnittelumallin esittämästä teoreettisesta ajattelutavasta. Suunnittelumallin käytöstä voidaan antaa esimerkki todellisen järjestelmän toteutuksessa tai ohjelmointikielikohtaisena.
Luokittelu

Suunnittelumallit luokitellaan yleensä sen tarkoituksen (luonti, rakenne, käyttäytyminen) ja sen kohteen (luokka, olio) perusteella. Mallit voidaan luokitella lisäksi myös sen mukaan, mitä malleja käytetään yleensä toistensa kanssa, mitkä mallit ovat toistensa vaihtoehtoja tai rakenteeltaan toisiaan vastaavia. Mallien luokittelun tarkoituksena on jäsentää ohjelmistoa käsitteellisiä lähestymistapoja (abstraktiotaso) kuvaavat mallit toistensa suhteen ja nopeuttaa mallien oppimista.
Luokittelu > Luontimallit

Luontimalli on suunnittelumalli, jolla ohjelmassa toimivan olion rakentaminen esitetään käsitteellisellä tasolla. Luontimalli peittää konkreettisesti käytettävien tuotantoluokkien näkyvyyden niitä käyttäviltä luokilta ja sen, miten tuotantoluokkia luodaan ja yhdistellään toisiinsa, eli tuotantoluokkia käyttävä tilaajaohjelma tuntee niistä vain niiden abstraktissa luokassa esitettävän rajapinnan. Rajapinnan käyttö mahdollistaa sen, että tuotantoluokkia ja niiden välisiä suhteita on helppo muuttaa ilman että sillä olisi vaikutusta luokkia tilaavan ohjelman toimintaan.  Luontimalli kuvaa olioiden luomisprosessin, eli sen, kuinka, koska ja mitä olioita luodaan, ja huolehtivat luokkien ja olioiden asetusten konfiguroinnista.
Luontimalli on suunnittelumalli, jossa monimutkainen toiminnallisuus toteutetaan yhdistämällä useita eri toiminnallisuuksia. Luontimallit kätkevät tiedon siitä, mitä luokkia toiminnallisuuden toteuttamisessa käytetään ja miten näitä luokkia käytetään, luodaan ja liitetään toisiinsa.
Luokittelu > Luontimallit > Epäkonkreettinen tehdas

Epäkonkreettinen tehdas (Absract Factory, Kit) on olion luontimalli, jossa konkreettisten luokkien olioryhmä (-perhe) luodaan luokasta jolla itsellään ei ole konkreettista ilmentymää (abstrakti luokka). EKT on rajapintaluokka, joka yhdistää toisiinsa saman tyyppisiä oliota.
EKT:tä voidaan käyttää ohjelman rakenteen mallina esim. käyttöliittymän toteutukseen eri alustoilla seuraavasti: Sovellusta käytetään eri käyttöliittymässä, jolloin käyttöliittymän rakentamistyökalun tulee tukea erilaisia käyttöliittymästandardeja. Käyttöliittymää luotaessa sovellus kutsuu abstraktin luokan (esim. UITehdas) funktiota (esim. luoIkkuna(), luoVierityspalkki(), luoPainonappi), joka edelleen kutsuu kyseisen ohjelmaympäristön konkreettista luokkaa, joka toteuttaa tarvittavat toiminnallisuudet.
EKT toteutetaan usein tehdasmenetelmällä, ja toteutuksessa voidaan käyttää myös prototyyppimallia. Abstraktin tehtaan alaluokka konkreettinen tehdas on tavallisesti ainokainen (luokasta luodaan vain yksi ilmentymä).
Luokittelu > Luontimallit > Rakentajarajapinta

Rakentajarajapinta (Builder) on olion luontimalli, jossa erotetaan toisistaan olion esitysmuoto ja sen luomisprosessi. Tämän vuoksi sama prosessi voi tuottaa erilaisia olioita. Abstrakti rakentaja on abstrakti rajapintaluokka, joka luo konkreettisen rakentajaluokan osat. Rakentajaluokka toteuttaa halutut toiminnallisuudet (tuotteet).
Rakentajaa voidaan käyttää ohjelman rakenteen mallina esim. muunnettaessa RTF-muotoista tekstiä muihin tekstiformaatteihin (esim. ASCII, muotoiltu teksti, jota ei voida muokata, muotoiltu teksti, jota voidaan muokata). RTFLukija (pääohjelma) kutsuu abstraktin rakentajan (TekstiKonvertoija), joka kutsuu edelleen konkreettisen rakentajan (ASCIIKonvertoija, TekstiKonvertoija, TekstiMuokkausKonvertoija) pääohjelman funktiokutsun sisältämän tiedon mukaan. Konkreettinen rakentaja määrittelee tuotteen kokoamisen prosessin ja kokoaa tuotteen sisäisen esitysmuodon.
Rakentajarajapinta muistuttaa epäkonkreettista tehdasta siinä, että molemmilla voidaan toteuttaa monimutkaisia toiminnallisuuksia. Mallit eroavat toisistaan siinä, että epäkonkreettinen tehdas palauttaa pyydetyn tuotteen välittömästi, kun taas rakentajarajapinta valmistaa tuotteen vaiheittain ja palauttaa sen prosessin viimeisenä vaiheena. Rakentajarajapintaa käytetään usein rekursiokoosteen kokoamiseen.
Luokittelu > Luontimallit > Tehdasfunktio

Tehdasfunktio (Factory Method, Virtual Constructor) on luokan luontimalli, jossa käytetään abstraktia funktiokutsua. Olion kutsumuoto on määritelty, ja luokan ilmentymän luominen on aliluokan tehtävä. Tehdasfunktiomallissa abstrakti luokka kapseloi konkreettisen luokan tarvitsemat tiedot ja välittää ne konkreettiselle tuotantoluokalle. Tehdasfunktiota voidaan käyttää ohjelman rakenteen mallina esim. sovelluksessa, joka tuo käyttäjän muokattavaksi useita dokumentteja.
Luokittelu > Luontimallit > Prototyyppirajapinta

Prototyyppirajapinta (Prototype) on olion luontimalli, jossa olion määrittely suoritetaan abstraktilla prototyyppiluokalla. Olio luodaan prototyyppiluokkaa kutsumalla ja luomalla siitä kopioita (kloonaus). Kopioiden ominaisuuksia voidaan muokata parametreilla, jolloin voidaan vähentää luokkien määrää.
Luokittelu > Luontimallit > Ainokainen

Ainokainen (Singleton) on olion luontimalli, jossa luokasta luodaan täsmälleen yksi konkreettinen ilmentymä. Ilmentymään pääsy on globaali.
Luokittelu > Rakennemallit

Rakennemalli on suunnittelumalli, joka kuvaa luokkia (ja olioita) ja niiden yhdistelyä suuremmiksi rakenteiksi. Rakennemalli kuvaa tavan, jolla luokkia ja olioita käytetään laajoissa rakenteissa. Rakennemalli esittää rajapinnat ja toteutuksen toisistaan erotettuina.
Luokittelu > Rakennemallit > Sovitin

Sovitin (Adapter, Wrapper) on luokan tai olion rakennemalli, jossa kaksi toisiinsa sopimatonta rajapintaa liitetään toisiinsa käyttäen rajapintaluokkaa.
Luokittelu > Rakennemallit > Silta

Silta (Bridge, Handle, Body) on ohjelmiston rakennemalli, jossa sovellukseen liitetty abstrakti rajapintaluokka kutsuu haluamansa toiminnallisuuden abstraktilta toiminnallisuuden rajapintaluokalta. Nämä kaksi rajapintaa muodostavat sillan, ja molempia rajapintoja voidaan vapaasti muunnella.
Luokittelu > Rakennemallit > Koosteensa sisältävä kooste

Koosteensa sisältävä kooste (rekursiokooste, Composite) on ohjelmiston rakennemalli, jossa yksi koosteolion rakentava abstrakti luokka käsittelee kyseistä koostetta samalla tavalla ja samanaikaisesti konkreettisten aliluokkien olioiden kanssa. Ohjelma käsittelee kaikkia itsensä sisältävän koosteen osia samalla tavalla.
Luokittelu > Rakennemallit > Kuorruttaja

Kuorruttaja (Decorator, Wrapper) on suunnittelumalli, jossa oliolle (ei koko luokalle) lisätään toiminnallisuutta (vastuita) ajon aikana (dynaamisesti) käyttämällä abstraktia rajapintaluokkaa, jonka alaluokat toteuttavat toiminnallisuuden. Kuorruttaminen on joustava vaihtoehto perinnälle.
Luokittelu > Rakennemallit > Julkisivu

Julkisivu (Facade) on ohjelmiston rakennemalli, jossa julkisivu-luokka tarjoaa yhden yhtenäisen rajapinnan alijärjestelmäluokkien rajapintojen joukolle ja niiden keskeisille palveluille. Julkisivu vähentää alijärjestelmien riippuvuuksia ja niiden välistä kommunikaatiota ja helpottaa alijärjestelmän käyttöä.
Luokittelu > Rakennemallit > Hiutale

Hiutale (Flyweight) on ohjelmiston rakennemalli, jossa yhteiskäyttöistä oliota käytetään samanaikaisesti useissa eri yhteyksissä. Hiutale käyttäytyy jokaisessa käyttöyhteydessään itsenäisesti. Hiutaleessa olion sisäinen ja ulkoinen tila on erotettu toisistaan, sisäinen tila on tallentuneena hiutaleeseen, ja ulkoinen tila vaihtelee tilanteen mukaan ja riippuu asiayhteydestä.
Luokittelu > Rakennemallit > Edustaja

Edustaja (Proxy, Surrogate) on ohjelmiston rakennemalli, jossa olioille luodaan korvike (tai paikan pitäjä) käyttäen abstraktia rajapintaluokkaa, jonka alaluokka konkreettinen Edustaja-luokka on. Edustaja-luokka kontrolloi olioon kohdistuvia pyyntöjä.