Alternatywa dla kontenera DI

1

Jeśli chodzi o obiekty Javowe to polecam ten artykuł: https://docs.oracle.com/javase/tutorial/java/concepts/object.html

Jest tam taki obrazek:
concepts-object.gif
Podpis: A software object.

0
hauleth napisał(a):

@._. tylko twoje constant nie są takie stałe, bo zmieniają się z każdą inicjalizacją obiektu. I ogólnie funkcje "czyste" powinny unikać bycia zależnymi nawet od stałych, oczywiście to nie zawsze będzie prawdą, bo np. areaOfCircle(double r) { return PI * r * r; } jest funkcją czystą, ale im mniej zależą od globalnego stanu (nie ważne czy to stałe czy zmienne), tym lepiej. No i oczywiście trzeba pamiętać, że konfiguracja nie jest stałą rzeczą. Należy to traktować jak globalną zmienną, więc jeśli funkcja zależy od globalnej konfiguracji, to nie jest czysta.

Co ty pleciesz przecież "const" oznacza, tyle że musi mieć zawsze tą samą wartość nie można tego zmienić in runtime to jest to samo co readonly.

Równie dobrze mógłbyś powiedzieć, że htttp nie jest bezstanowy albo że obiekt pobierający dane z http czy bazy danych posiada stan, ponieważ "operuje na stanie globalny" jak baza danych i tp. a tak nie jest.

A konfiguracja kontenera IOC lub connection string ile razy będzie się zmieniać podczas życia aplikacji?.

Powiedz mi ile stanów będzie posiadać ten obiekt?


class Helper {
public const string TEST2 = "Test!";
}

class Trololololo{
     private const string TEST = "Test!";
    private ReadData readData = ReadDataSingleton().Instance;

    public void Test() {
        Console.WriteLine(TEST + Helper.TEST2);
    }
    public void Test2() {
        Console.WriteLine(readData.Get(1));
    }
}
0

Bez kontekstu stany Trololololo zależą od Helper i ReadData. Akurat stworzyłeś taki przypadek gdzie po przez to ze Helper się nie zmienia też jest bezstanowe. Myślę, że akurat takie podstawienie jak robisz z Helper (czyli po prostu wartość) akurat jest po prostu skróceniem zapisu, ale rzeczy z ReadData jest już bardziej niebezpieczne. Właściwie gdybyś zrobił:

class Trololololo{
    private const string TEST = "Test!";
    private ReadData readData;
    Trololololo(ReadData readData){
        this.readData = readData
    }
 }

miałbyś podobny efekt ale dużo łatwiej testowalny. (Plus podobno singleton nie jest za bardzo zalecany)

Btw nie jest into C# ale czy const nie znaczy ze nie mozna nic innego przypisać pod to? To nie wymusza jeszcze braku zmiany stanów. Możesz pod consta przypisać wrappera na stringa i go pod spodem zmieniać. (chyba, że w C# działa to inaczej to mnie popraw)

1

@._.:
Czyli reasumując - niemutowalna klasa jest bezstanowa wtedy i tylko wtedy, gdy jej obiekty są tworzone zawsze z takimi samymi parametrami, tak?

Nie brzmi dziwnie, że dopiero sposób użycia klasy determinuje właściwości tej klasy?

0
._. napisał(a):

[...] obiekt pobierający dane z http czy bazy danych posiada stan, ponieważ "operuje na stanie globalny" jak baza danych i tp. a tak nie jest.

Bo posiada stan. DB to jest globalny mutowalny stan. Czy to lubisz czy nie, tak właśnie jest.

A konfiguracja kontenera IOC lub connection string ile razy będzie się zmieniać podczas życia aplikacji?.

Zależy jak się zmienią wymagania. Przykładowo możesz użyć Vault do tego by generować sobie sekrety i connection string będzie się zmieniał przy każdym nowym połączeniu z DB.

Powiedz mi ile stanów będzie posiadać ten obiekt?


class Helper {
public const string TEST2 = "Test!";
}

class Trololololo{
     private const string TEST = "Test!";
    private ReadData readData = ReadDataSingleton().Instance;

    public void Test() {
        Console.WriteLine(TEST + Helper.TEST2);
    }
    public void Test2() {
        Console.WriteLine(readData.Get(1));
    }
}

Będzie tyle możliwych stanów ile ma ReadDataSingleton().Instance. Bo silnie od niego zależy i musisz skonfigurować jego instancję by móc dobrze przetestować Trololololo. Dodatkowo zależy to od zewnętrznych wartości jak TEST2, więc jeśli ktoś zmieni wartość tej stałej, to masz spore szanse, że testy zaczną padać, a nie powinny.

0
 class Program
    {
        static void Main(string[] args)
        {
            //obiekty w różnych stanach
            var cheesWithSomeHoles = new Chedar();
            var cheesWithSomeMoreHoles = new Chedar();

            var redCar = new Car("red");
            var greenCar = new Car("green");

            //A to jest trolololo
            var Trololololo4Programers = new Trololololo();
            var Trololololo4Programers = new Trololololo();
            var Trololololo4Programers = new Trololololo();
            var Trololololo4Programers = new Trololololo();
            var Trololololo4Programers = new Trololololo();
        }
    }

    class Car
    {
        private readonly string color;
        private readonly string carBody;

        public Car(string color)
        {
            this.color = color;
            this.carBody = "niceBody";
        }

        public string GetNewCar()
        {
            return carBody + color;
        }
    }

    class Chedar
    {
        private static int holes;
        private string chees;

        static Chedar()
        {
            holes += 10;
        }

        public string GetCheesWithHoles()
        {
            return chees + holes.ToString();
        }
    }
0

Streszczenie ostatnich kilkudziesięciu postów. Ze zdania wyciągniętego z książki o DDD:

Bezstanowość oznacza w tym miejscu, że dowolny klient może używać dowolnej instancji danej usługi bez względu na historię danej konkretnej instancji

użytkownik ._. wywnioskował między innymi, że niemutowalna klasa jest bezstanowa wtedy i tylko wtedy, gdy za każdym razem tworzymy jej obiekty tak, że zawierają te same dane.

0
Wibowit napisał(a):

Streszczenie ostatnich kilkudziesięciu postów. Ze zdania wyciągniętego z książki o DDD:

Bezstanowość oznacza w tym miejscu, że dowolny klient może używać dowolnej instancji danej usługi bez względu na historię danej konkretnej instancji

użytkownik ._. wywnioskował między innymi, że niemutowalna klasa jest bezstanowa wtedy i tylko wtedy, gdy za każdym razem tworzymy jej obiekty tak, że zawierają te same dane.

To ty takie wnioski wyciągnąłeś z książki której nie rozumiesz, brawo możesz być z siebie dumny.

0

No to jeszcze raz: czy niemutowalna klasa jest bezstanowa wtedy i tylko wtedy, gdy za każdym razem tworzymy jej obiekty tak, że zawierają te same dane?

I bonusowe pytanie: czy usługa to synonim dla obiektu?

0

Obiekt bezstanowy to obiekt bezstanowy, czyli taki obiekt, który nie posiada stanu, geniusze. Gdyby nie ja to te forum by padło po miesiącu. Nie mielibyście co trolować.

1 użytkowników online, w tym zalogowanych: 0, gości: 1