ugrás a tartalomhoz

Stop Writing Classes

Hidvégi Gábor · 2014. Már. 7. (P), 14.49
Az osztályok használata túlbonyolított kód írására ösztönöz
 ■
1

Kívánságműsor

Hidvégi Gábor · 2014. Már. 7. (P), 15.37
Ezt a számot inf3rno kollegának küldöm sok szeretettel ; )
2

Osztályok

Poetro · 2014. Már. 7. (P), 15.45
Nem azt mondja, hogy ne használjunk osztályokat, hanem hogy feleslegesen ne használjuk őket. A kettő között azért elég nagy a különbség.
3

A videónak nem én adtam a

Hidvégi Gábor · 2014. Már. 7. (P), 15.57
A videónak nem én adtam a címét.
7

Az osztályok használata

inf · 2014. Már. 8. (Szo), 04.43
Az osztályok használata túlbonyolított kód írására ösztönöz


Előszöris :D

Az osztályok használata túlbonyolított kód írására ösztönöz


Igen, ez tényleg így van. Erre azonban nem az a megoldás, hogy nem használjuk emiatt az osztályokat. Van egy olyan aranyszabály, hogy single responsibility principle, ami elég jól meghatározza, hogy egy-egy osztálynak mekkora lehet a hatóköre. Ha ezt a szabályt alkalmazzuk, akkor jó eséllyel elkerülhetjük az overengineeringet. Ami még nagyon sokat segített nekem ezzel kapcsolatban az a TDD. A TDD-nél magasabbról alacsonyabb absztrakciós szint felé haladva az SRP alapján osztjuk fel a kódot osztályokra, és írjuk meg ezeknek az osztályoknak a unit test-jeit. A TDD azért nagyon hatékony, mert előbb tesztet ír az ember, utána magát a kódot. Így nem fordulhat elő, hogy felesleges kód kerül a rendszerbe, és olyan dolgokkal foglalkozunk, ami a feladat szempontjából teljesen lényegtelen általános valami. Szóval a TDD nekem nagyon sokat segített az egy-egy problémára való fókuszálásban...

szerk:

Közben megnéztem, és többé-kevésbé egyet tudok érteni vele. De ez az egész inkább az overengineering-ről szól, és nem arról, hogy az osztályok rosszak lennének...
4

Minden szava arany

Hidvégi Gábor · 2014. Már. 7. (P), 17.29
  • I hate code and I want as little of it as possible in our product.
  • The signature that this shouldn't be a class, is that it has two methods, one of which is __init__ [konstruktor]. Anytime you see that you should probably think: hey, maybe I just need the one method.
  • So anytime you see aliasing your classes to just instantiate them once, use them and then throw them away - in your brain you should be thinking: oh, I should refactor that, it can be simpler. Much simpler.
  • I don't know how many of you have CS [Computer Science] degrees, I have one, I learnt about separation of concerns, decoupling, encapsulation, implementation hiding. I haven't used those words in fifteen years, since I graduated. Anytime you hear someone using those words, they're trying to pull a fast one on you [át akarnak vágni]. It just doesn't come up. And even if it does come up, people mean different things when they use them, it's not useful for furthering conversation.
  • So, the overuse of classes: lots of times people think that they might need something later. You don't. Or you can just do it later.

d = MuffinMail.MuffinHash.MuffinHash(foo=3)
  • Some other signs that you don't need this: you have to type Muffin thee times. You're not helping anyone, you're making users angry.
5

Arany bizony

Endyl · 2014. Már. 7. (P), 17.56
  • Classes are great for things that classes are great for. So when you have a bundle of mutable data and a bunch of related functions that you want to use with that data, then yes, classes are the right thing to do.
  • [...]they're always operating on the same thing, which kind of implies: yes, this actually is a class.
8

Belenéztem a speaker egy

tgr · 2014. Már. 9. (V), 09.56
Belenéztem a speaker egy találomra választott github repójának találomra választott fájljába (ez), kb. a harmada áll olyan osztályokból, amikben a konstruktoron kívül egy függvény van, vagy annyi se.

Konferencián trollkodni nyilván hálás dolog, mert annál többen fogják megosztani az előadást, minél provokatívabb. Amikor kódolni kell, akkor átkapcsol manikűr módba.
9

Belenéztem a speaker egy

inf · 2014. Már. 9. (V), 10.27
Belenéztem a speaker egy találomra választott github repójának találomra választott fájljába (ez), kb. a harmada áll olyan osztályokból, amikben a konstruktoron kívül egy függvény van, vagy annyi se


Már nem emlékszem teljesen a videora, de nekem nem tűnt úgy, hogy verné a mellét, hogy minde hülyék vagytok, bezzeg én. Egy szóval sem mondta, hogy ő ne követte volna el ugyanezeket a hibákat. De lehet én emlékszem rosszul...

Egyébként az egy osztály - egy metódus tényleg overengineering-re utaló jel lehet sok esetben, de azért nem mindben. Pl egy DTO-nál teljesen elfogadott, hogy csak adatküldő funkciója van az osztálynak, és nem igazán vannak benne metódusok...
10

A linkelt fájl a konferencia

Hidvégi Gábor · 2014. Már. 9. (V), 10.28
A linkelt fájl a konferencia előtt készült, ráadásul az előadáson is saját kódon mutatja be, hogy mi a rossz. És nem hiszem, hogy trollkodott volna az illető, szerintem tudja, miről beszél, a python egyik core fejlesztője.
11

És nem hiszem, hogy

inf · 2014. Már. 9. (V), 10.35
És nem hiszem, hogy trollkodott volna az illető, szerintem tudja, miről beszél, a python egyik core fejlesztője.


Lehet olyat mondani, hogy építő jelleggel trollkodott? :D Lehet, hogy ez ütközik a trollkodás definíciójával, de tényleg ilyen jellegű az előadása...
12

Miért?

Hidvégi Gábor · 2014. Már. 10. (H), 13.14
Nem teljesen értem, miért gondolod, hogy ilyen jellegű?
13

A hangosan felröhögés a

inf · 2014. Már. 10. (H), 14.12
A hangosan felröhögés a példakódokon ilyen benyomást keltett. Mondjuk én nem tudtam, hogy a saját kódjait mutatja...
14

Senki sem tökéletes. Nekem

Hidvégi Gábor · 2014. Már. 13. (Cs), 17.46
Senki sem tökéletes. Nekem például nincsenek rossz tulajdonságaim.
6

a tultervezesrol es YAGNIrol

blacksonic · 2014. Már. 8. (Szo), 00.40
a tultervezesrol es YAGNIrol szol...ettol meg az osztalyok nagyon jok :)