Wpis z mikrobloga

@Rincewind: Za prefiksy/postfiksy powinni strzelać. Osobiście wolę

lower_snake_case
bo wtedy od razu widać czy to zmienna czy klasa. Co do ang. to zgadzam się w 100%.
  • Odpowiedz
@sylwke3100: Tak bardzo nie. Samego stosowania getterów i setterów powinno się unikać, a przynajmniej ich nazywania tak. Ani nie

camelCase
ani stosowanie przedrostków czasownikowych, i.e.

get_name
.
  • Odpowiedz
@Hauleth: Podałem przykład. Tak poza tym jakieś wytłumaczenie co do setterów, getterów bo ja nigdy takiego stwierdzenia nie słyszałem tak samo jak tego że się używa typu funkcja_co (nawet to w jakimś większym OSowym projekcie widziałem)
  • Odpowiedz
@sylwke3100: ja zawsze dostosowuję się do standardów języka, w którym piszę. Raz, że taki standard jest wypracowany przez społeczność ludzi, którzy klepią godzinami w konkretnym języku, a więc jest często dosyć "optymalny" i czytelny. Dwa: jeśli pokazuję kod innej osobie, to łatwiej jej czytać ustandaryzowany kod (np. w C# nazwy interfejsów są zapisywane za pomocą notacji węgierskiej i widząc C# ICośtam wiadomo, że to interfejs, czy też nazwy zmiennych prywatnych
  • Odpowiedz
@Hauleth: Prefix – postfix to temat na holy war, więc nie zagłębiajmy się. ;) To głównie zależy od języka. Ale weźmy taki C++ (nie programowałem w nim od lat, ale wciąż co nieco pamiętam): zawsze robiłem tak, że getter był w postaci

T foo() const
, natomiast setter
  • Odpowiedz
@sylwke3100: Jeśli ma być trywialny getter albo setter to lepiej ustawić zmienną jako publiczną, a jeśli robi coś więcej to zazwyczaj nazwa set_blabla jest niewystarczająca. Co innego jednak, jeśli jest to język, w którym nie ma zmiennych publicznych instancji (jak Ruby).
  • Odpowiedz
@sylwke3100: Wielu teoretyków do OOP uważa za dobre minimalizowanie przepływu danych między obiektami. Coupling też się zwiększa przez takie coś: Car::Engine::turnOn() vs Car::Engine::setRunning(bool), getter/setter niepotrzebnie eksponuje wnętrze obiektu.

Albo inny przykład:

IObject & GameUniverse::getObject(Identifier id); // IObject *,
  • Odpowiedz