Bezestavové OOP

pepa

Re:Bezestavové OOP
« Odpověď #45 kdy: 01. 02. 2018, 11:52:43 »
Ha, takže já můžu udělat v C# tohle:

Kód: [Vybrat]
class Program
    {
        private int Orechy;
        private int Svestky;
        private int Cigara;
   
        static void Main(string[] args)
        {
            Program p = new Program
            {
                Orechy = 10,
                Svestky = 50,
                Cigara = 20
            };
        }
    }

To je brutální :) V Javě, když jsme potřebovali dělat unit testy, tak se na všechny různé fieldy psaly gettery a settery, abychom se k tomu dostali.


pepa

Re:Bezestavové OOP
« Odpověď #46 kdy: 01. 02. 2018, 11:59:18 »
No takže nic, funguje to jen zevnitř třídy, takže jsem opět u getteru a setteru nebo u konstruktoru...

anonym

Re:Bezestavové OOP
« Odpověď #47 kdy: 01. 02. 2018, 12:24:17 »
Zase taková pitomá odpověď na stackoverflow

Citace
he quick answer is that you should never, ever access non-public members from your unit tests. It totally defies the purpose of having a test suite, since it locks you into internal implementation details that you may not want to keep that way.
https://stackoverflow.com/questions/1093020/unit-testing-and-checking-private-variable-value

Unit test má testovat jenom flow v nějaké metodě. Jak jí má ale otestovat bez přístupu k private fieldům, když je to třída vytvářecího typu, jako je moje třída Program?

V podstatě pokud mám nějakou třídu B, která interně vytváří C  a já musím C namokovat, tak prostě MUSÍM mít přístup k C. Přinejmenším přes reflexi, která je ale naprd, protože hardkoduje nazvy fieldu.

To jsou fakt tohleto poučky jak z nějaké příručky univerzitního profesora v brýlích co nikdy nic nenaprogramoval.

anonym

Re:Bezestavové OOP
« Odpověď #48 kdy: 01. 02. 2018, 12:46:32 »
Já si myslím, že můj přístup s get a set je v případě mé třídy Program správný. Ta třída Program dělá to, že na základě agumentů konzole konfiguruje spuštění nějakých procesů. Je správné, že má gettery a settery na to, co nakonfigurovala, takže to není porušení zapouzdřenosti.

Kit

Re:Bezestavové OOP
« Odpověď #49 kdy: 01. 02. 2018, 12:52:35 »
No takže nic, funguje to jen zevnitř třídy, takže jsem opět u getteru a setteru nebo u konstruktoru...

V Javě se na to používá statická vnitřní třída. Výsledek je v jiném souboru, ale má přístup k privátním proměnným vnějšího objektu. Používám to.


ava

Re:Bezestavové OOP
« Odpověď #50 kdy: 01. 02. 2018, 14:31:18 »
Rozdíl mezi konstruktorem a setterem je jen a pouze v tom, že konstruktorem hodnoty nastavuješ povinně, zatímco setterem volitelně.

Netýká se to moc tématu, ale tak pro zajímavost - velký rozdíl mezi konstruktorem a setterem je ten, že pomocí konstruktrou nelze vytvářet cyklické struktury (objekt A referencuje B, B referencuje A).

Kiwi

Re:Bezestavové OOP
« Odpověď #51 kdy: 01. 02. 2018, 17:29:30 »
Tohle je fakt psina. Neustále se omílají mantry o tom, jak vysokoúrovňové jazyky a v současné době propagovaná paradigmata svou vyšší abstrakcí umožňují soustředit se na řešení problému a ne na věci okolo, jak tomu prý bývalo dříve, ale přitom se tu neustále rozebírá, jak kdejakou trivialitu správně napsat, aby to jako vyhovovalo těm teoretickým představám a návrhovým vzorům, jimž byl ten konkrétní jazyk přizpůsoben.

anonym

Re:Bezestavové OOP
« Odpověď #52 kdy: 01. 02. 2018, 17:56:50 »
Ty vole já se schálně přemůžu a napíšu ten samý program na parsovální 100gb xmlka do databáze v Céčku. Fakt to udělám. Schválně, co bude přehlednější a v čem se bude líp dělat.

anonym

Re:Bezestavové OOP
« Odpověď #53 kdy: 01. 02. 2018, 18:01:50 »
Fuj tak raději ne, vzdávám se.

Kód: [Vybrat]
/*
   A simple test program to parse XML documents with expat
   <http://expat.sourceforge.net/>. It just displays the element
   names.

   On Debian, compile with:

   gcc -Wall -o expat-test -lexpat expat-test.c 

   Inspired from <http://www.xml.com/pub/a/1999/09/expat/index.html>
*/

#include <expat.h>
#include <stdio.h>
#include <string.h>

/* Keep track of the current level in the XML tree */
int             Depth;

#define MAXCHARS 1000000

void
start(void *data, const char *el, const char **attr)
{
    int             i;

    for (i = 0; i < Depth; i++)
        printf("  ");

    printf("%s", el);

    for (i = 0; attr[i]; i += 2) {
        printf(" %s='%s'", attr[i], attr[i + 1]);
    }

    printf("\n");
    Depth++;
}               /* End of start handler */

void
end(void *data, const char *el)
{
    Depth--;
}               /* End of end handler */

int
main(int argc, char **argv)
{

    char           *filename;
    FILE           *f;
    size_t          size;
    char           *xmltext;
    XML_Parser      parser;

    if (argc != 2) {
        fprintf(stderr, "Usage: %s filename\n", argv[0]);
        return (1);
    }
    filename = argv[1];
    parser = XML_ParserCreate(NULL);
    if (parser == NULL) {
        fprintf(stderr, "Parser not created\n");
        return (1);
    }
    /* Tell expat to use functions start() and end() each times it encounters
     * the start or end of an element. */
    XML_SetElementHandler(parser, start, end);
    f = fopen(filename, "r");
    xmltext = malloc(MAXCHARS);
    /* Slurp the XML file in the buffer xmltext */
    size = fread(xmltext, sizeof(char), MAXCHARS, f);
    if (XML_Parse(parser, xmltext, strlen(xmltext), XML_TRUE) ==
        XML_STATUS_ERROR) {
        fprintf(stderr,
            "Cannot parse %s, file may be too large or not well-formed XML\n",
            filename);
        return (1);
    }
    fclose(f);
    XML_ParserFree(parser);
    fprintf(stdout, "Successfully parsed %i characters in file %s\n", size,
        filename);
    return (0);
}

Pako

Re:Bezestavové OOP
« Odpověď #54 kdy: 01. 02. 2018, 18:05:57 »
Nebylo by na to lepší použít nějaký standardní XSLT nástroj?

Re:Bezestavové OOP
« Odpověď #55 kdy: 01. 02. 2018, 18:07:44 »
Rozdíl mezi konstruktorem a setterem je jen a pouze v tom, že konstruktorem hodnoty nastavuješ povinně, zatímco setterem volitelně.

Netýká se to moc tématu, ale tak pro zajímavost - velký rozdíl mezi konstruktorem a setterem je ten, že pomocí konstruktrou nelze vytvářet cyklické struktury (objekt A referencuje B, B referencuje A).

No to platí v javě, protože konstruktor lze použít jen jednou a java používá Call_by_value takže zvnějšku už to nezměním.

Ale platí to i v C#? Když tam zdá se můžeme použít i Předávání parametrů odkazem (ref) takže bych mohl nastavit prázdný ukazatel jako výstupní parametr a ten pak dodatečně změnit?

?? (C# neznám...)

Lopaťuk

Re:Bezestavové OOP
« Odpověď #56 kdy: 01. 02. 2018, 20:45:42 »
Tohle je fakt psina. Neustále se omílají mantry o tom, jak vysokoúrovňové jazyky a v současné době propagovaná paradigmata svou vyšší abstrakcí umožňují soustředit se na řešení problému a ne na věci okolo, jak tomu prý bývalo dříve, ale přitom se tu neustále rozebírá, jak kdejakou trivialitu správně napsat, aby to jako vyhovovalo těm teoretickým představám a návrhovým vzorům, jimž byl ten konkrétní jazyk přizpůsoben.

Přesně z toho důvodu jsem se na OO před pár lety vyprd a utekl jsem k FP, jmenovitě F# a teď trochu Elixir(ten se mi moc líbí) a Clojure (s tím si zatím jen hraju, protože jsem se vždycky chtěl naučit LISP, ale nebyl na to čas. LISP nad JVM je něco, co se může někdy hodit).

SB

Re:Bezestavové OOP
« Odpověď #57 kdy: 02. 02. 2018, 10:42:56 »
...V Javě, když jsme potřebovali dělat unit testy, tak se na všechny různé fieldy psaly gettery a settery, abychom se k tomu dostali.

A je to skutečně potřeba? Jednotkovými testy se přece testuje správnost objektu navenek, ne uvnitř - funguje-li navenek, je v pořádku. Naopak čuměním jedn. testy dovnitř porušujete zapouzdření, které platí i zde, tj. nezávislost vnitřku a venku. Mimoto je možno vytvořit objektu metodu, která si ověří vlastní správnost stavů, případně i v kombinaci se závislými objekty, a zahlásí rozpor (používám běžně), aniž by bylo třeba zapouzdření porušit.
Myslím si, že na to nejdete dobře.

Kit

Re:Bezestavové OOP
« Odpověď #58 kdy: 02. 02. 2018, 11:06:57 »
...V Javě, když jsme potřebovali dělat unit testy, tak se na všechny různé fieldy psaly gettery a settery, abychom se k tomu dostali.

A je to skutečně potřeba? Jednotkovými testy se přece testuje správnost objektu navenek, ne uvnitř - funguje-li navenek, je v pořádku. Naopak čuměním jedn. testy dovnitř porušujete zapouzdření, které platí i zde, tj. nezávislost vnitřku a venku. Mimoto je možno vytvořit objektu metodu, která si ověří vlastní správnost stavů, případně i v kombinaci se závislými objekty, a zahlásí rozpor (používám běžně), aniž by bylo třeba zapouzdření porušit.
Myslím si, že na to nejdete dobře.

Jednotkovými testy se skutečně testuje jen chování objektu navenek. Jenže jsou zde ještě vývojářské testy, které se zaměřují na vnitřní chování objektu. Za tím účelem se hodí statická vnitřní třída, ve které se dají psát tyto vývojářské testy, které mají přístup k privátním proměnným i metodám.