Pole klasy to 1 przypadek. 2 przypadek, to zastosowanie std::remove_const na tej stalej, a trzeci to wylaczenie w kompilatorze sprawdzania inicjalizacji (flaga).
Ale tak, zgadzam sie - ta 4 linijka w tym akurat przypadku musi byc inicjalizowana.
Wersja do druku
Siema, mam za zadanie napisać projekt na studia i chyba zabraknie mi czasu żeby go zrobić, byłby ktoś chętny się podjąć czegoś takiego? Oczywiście dogadamy się jeśli chodzi o cenę :)
Zadanie szczegółowe
Projekt 1 -- język C
Proszę napisać program realizujący prosty silnik wnioskujący. Powinien on umożliwiać:
(minimum)
- wczytywanie bazy wiedzy (faktów) i bazy reguł z pliku/ów
- przeprowadzenie wnioskowania na podstawie faktów i reguł w celu ustalenia wartości nieznanego "faktu"
- obsługę faktów o wartościach prawda i fałsz oraz reguł wnioskowania składających się z przeczenia, sumy oraz iloczynu logicznego z uwzględnieniem ewentualnych nawiasów
- wybór uruchomienia programu w trybie wnioskowania w przód i wnioskowania w tył
- wyświetlanie informacji o przebiegu wnioskowania
Oczękuję kodu wraz komentarzami/pdfem wyjaśniającym tok rozumowania, projekt mam na wtorek, więc najlepiej żeby ktoś podejmujący się go, wyrobił się na niedzielę.
PW, dzięki :)
Jest tu jakiś spec od UNITY 3D ? :)
czemu nie spytasz na answers.unity3d?
Mam problem ze zrozumieniem roznicy z propertisami, polami i modyfikatorami dostepu. (aktualnie C#)
Rozwazmy, ze mam jakas tam swoja klase, a w niej:
Lub tezKod:private string przyklad_;
public string Przyklad
{
get{return przyklad_;}
private set{przyklad_=value;}
}
Przy tak prostym przykladzie nie widze roznicy w dzialaniu, zatem ma to jakies znaczenie? Jaka jest generalnie przyjeta koncepcja?Kod:public string przyklad_{get;private set;}
jak robisz zwykły {get; set;} bez żadnych bajerów, to tworzona jest zmienna, która przechowuje wartość, więc
jest równoznaczne zKod:public string s{get; set;}
po prostu skrót, coby nie trzeba było cały czas pisać takiego snippeta cały czas.Kod:private string _s;
public string s{ get{ return _s;} set { _s = value; }}
jednak jak chcesz robić jakieś dodatkowe rzeczy, np. walidację, to musisz już jawnie zadeklarować zmienną, której property będzie używać, np
property, które nie robią nic specjalnego (czyli mają puste get; set;) używa się z kilku powodów:Kod:private int _wiek;
public int wiek
{
get;
set
{
if(value < 0) _wiek = 0;
if(value > 150) _wiek = 150;
_wiek = value;
}
}
1) możesz pozwolić odczytywać zmienną poza klasą, a zmieniać jej wartość tylko w klasie - publiczne pole można i odczytywać, i modyfikować z każdego miejsca programu
2) dziedziczenie
składniowo mogłem gdzieś się jebnąć bo piszę z głowy a ostatnio w c# robiłem z pół roku temu albo i lepiej.
Czyli rozumiem, ze dopoki get i set nie maja bardziej skomplikowanej struktury, dopoty moge uzywac tej krotszej formy. Ktoregos z zapisow uzywa sie czesciej anizeli drugiego? Nauczyciel wyraznie nam zaznaczal, ze pola w klasie musza byc prywatne, ale wydaje mi sie to zbednym pisaniem kodu w takim wlasnie przypadku.
Imo krótszy będzie ok.
Jeżeli masz jakąś klase i w niej jakieś pola, do których masz i gettery i settery to jest to równoznaczne z tym jakbyś te pola miał public. I tak w każdym z tych dwóch przypadków możesz zmieniać stan obiektu. Pewnie 70letni Marian, wykładowca w twojej szkole będzie mówił że settery i gettery zapewniają enkapsulacje(xD) ale go nie słuchaj :)Cytuj:
Nauczyciel wyraznie nam zaznaczal, ze pola w klasie musza byc prywatne, ale wydaje mi sie to zbednym pisaniem kodu w takim wlasnie przypadku.
Jest to oczywiście gówno prawda
A właśnie, że słuchaj bo ma rację ( inna sprawa, ze ustawianie stanu obiektu przez set to największy rak w programowaniu )
Enkapsulacja, definicja:
To teraz tak, jaka jest różnica między:Cytuj:
Hermetyzacja (inna używana nazwa to enkapsulacja[1], ang. encapsulation) – jedno z założeń programowania obiektowego. Hermetyzacja polega na ukrywaniu pewnych danych składowych lub metod obiektów danej klasy tak, aby były one dostępne tylko metodom wewnętrznym danej klasy lub funkcjom zaprzyjaźnionym.
a:Kod:public String dupa
Ano taki, że w pierwszym przypadku piszesz:Kod:private String dupa
public void setDupa(String dupa) {
this.dupa = dupa;
}
Przez co łamiesz enkapsulację, bo nie operujesz na kontrakcie obiektu, tylko na jego polach, co jest zabronione w dobrych praktykach OOP. ( Tu mały disclaimer - są języki, w których można zrobić taki myk, że takie pole zrefaktorujesz na Propertiesy i nie będziesz w dupie, ale jestem zwolennikiem robienia dobrze od początku )Kod:mojObiekt->dupa = "dupa";
Poprawnym odwołaniem ( tzn poprawynm z punktu widzenia enkapsulacji bo metoda nadal jest chujowa ) jest :
W ten sposób logika zapisu tej wartości jest zachowana w obiekcie.Kod:obiekt.setDupa("dupa");
Masz, poczytaj kogoś mądrzejszego od siebie.
http://typicalprogrammer.com/doing-i...s-and-setters/
Cytuj:
Correct object-oriented design requires an object to encapsulate and hide its data, and to expose methods that are verbs acting on the object (not on individual properties of the object). The large majority of accessors are nouns — nothing more than pointless proxies for direct access to the object’s private data.