[alg] interface methods vs util methods

[Alarmnummer]

Ik heb op mijn blog een post geplaatst over 'util methods vs interface methods'. Mijn vraag is
1) komt mijn verhaal een beetje over
2) wat is je mening over util vs interface methods

http://pveentjer.wordpres...e-methods-vs-util-methods

De reden dat ik het hier plaats is dat een aantal collega's het artikel niet hebben begrepen. Ik vond het zelf vrij helder opgezet, maar als mensen het niet snappen dan is het toch iets om rekening mee te houden voor in de toekomst.

ps:
het gaat hier niet om juniors en ik schrijf voor mensen met een bepaald niveau.

[ Voor 3% gewijzigd door Alarmnummer op 13-11-2006 08:30 ]

[farlane]

Ik moet zeggen dat ik het verhaal heel duidelijk vind, je gebruikt een heldere, directe schrijfstijl zonder allerlei ( onnodige/pupulaire ) technische termen te gebruiken.
Ik begrijp eerlijk gezegd niet wat je collega's er onduidelijk aan vinden.

Mbt je onderwerp: Het lijkt een beetje op de (C++) discussie 'Het maken van een friend class is geen pure OO JA/NEE". Je hebt bepaalde bewerkingen op een object ondergebracht in een andere klasse en daarom zou het geen OO zijn. Onzin natuurlijk; je moet je hoofd erbij houden tijdens het ontwerpen maar dat geldt voor elke techniek die je gebruikt. Ik geloof niet zo in die OO heilige graal gedachte.

[edit]
BTW Om in je sort voorbeeld te blijven:

Wat in de stdlibc++ is gedaan is dat er een std::sort<T> bestaat en bij bepaalde klassen ook een class<T>::sort die een meer gespecialiseerde sort doen (indien mogelijk)

Afgezien van het feit dat het een template is blijft het hetzelfde idee, een utility functie die een algemene sort doet. Hier leven dus beide vormen naast elkaar.

[edit2]
Ik moet zeggen dat de aanpassing die je hebt gemaakt wel de leesbaarheid bevordert

[ Voor 27% gewijzigd door farlane op 13-11-2006 12:35 ]

[Alarmnummer]

Ik vond het zelf ook een vrij helder verhaal. Ik heb intussen het stuk over de 2 verschillende methodes wat aangepast:

oud:
For this discussion I distinguish 2 different types of methods:
1 implementation dependent methods like List.size(). The size method depends on the implementation of the List interface how it is determined; maybe an internal counter is used, maybe an iteration over the elements of the list is done.

2 implementation independent methods. These methods are build on top of implementation dependent and independent methods. An example of such a method is the List.indexOf(Object). This method can use the List.get(int) and the List.size() methods to find the first index. There is not always a clear seperation which methods are dependant and which ones are not; you could always create a List implementation where the indexOf method uses a hashtable for better search-performance.

nieuw

For this discussion I distinguish 2 different types of methods:
1. implementation dependent methods like List.size(). The size method depends on a specific implementation of the List interface, how it is determined; maybe an internal counter is used, maybe an iteration over the elements of the list is done.
2. implementation independent methods. These methods are build on top of other interface methods, without having any implementation specific knowledge. An example of such a method is the
List.indexOf(Object). This method can use the List.get(int) and the List.size() methods to find the first index. There is not always a clear separation which methods are dependent and which ones are not; you could always create a List implementation where the indexOf method uses a hashtable for better search-performance.

[Creepy]

En een move naar SEA waar het denk ik beter thuishoort.

Anyway, interresant stukje leesvoer en naar mijn mening helder geschreven. Misschien dat het onduidelijk is voor sommigen omdat men zich misschien niet kan voorstellen waarom een List.IndexOf zou verschilen t.o.v. een List.size(). Zoals je zelf ook al aangeeft is er niet altijd een duidelijke scheiding tussen. Misschien dat het voorbeeld nog wat duidelijker kan door daar direct de Collection.sort() bij aan te geven samen met een eventuele, al dan niet bestaande, List.sort().

En de uitspraak dat utility classes niet OO zouden zijn. Ben ik het niet mee eens. Het zou zelfs kunnen voorkomen dat een utility class niet static is en zelf ook nog een state bij moet houden. Blijft over qua argumentatie dat je een object niet als parameter mee zou moeten geven wat imho onzin. Dat moet zeker kunnen.

Als je het niet OO vindt dan zou je bijv. het Visitor pattern ook niet OO vinden omdat de implementatie van de Visitor zelf in principe geen state hoeft te hebben en methods heeft die een object als parameter meekrijgen. De Visitor zelf zou in een aantal gevallen ook Static kunnen zijn.

[whoami]

In welk geval zou een Utility class state moeten bijhouden ?
Ik denk niet dat je dat moet doen...

[ Voor 36% gewijzigd door whoami op 13-11-2006 10:33 ]

[Creepy]

Ik zeg ook niet dat je dat moet doen: sterker nog: liever niet natuurlijk. Neemt niet weg dat het wel kan.

[Michali]

Voor mij is het erg duidelijk, dus daar geen problemen.

Ik denk dat je dit het beste kunt bepalen door te kijken naar je abstractie. Behoort een method echt toe aan je abstractie; is het wel een normale vraag om hem direct te stellen? In dat geval zou ik hem wel altijd aan je interface meegeven. Als de method wel gerelateerd is, dus er operaties op uitvoert, maar er niet echt direct toebehoort, dan lijkt het me beter om er een utility method van te maken. (Bijvoorbeeld het converteren van een datum naar een ander formaat.)

Vooral gesloten operaties (zoals in Domain Driven Design wordt uitgelegd), die een object van dat type interface aannemen en ook een (ander, nieuw) object van hetzelde type weer returnen, lijken me uiterst geschikt voor een utility class.

[JeroenB]

Heldere blogpost, interessante discussie ook. Ik ben het zelf met Michali eens dat het bij een keuze tussen de twee voor mij vooral afhangt van of ik de operatie een verantwoordelijkheid van het object vind of niet. Als het iets is waarvan je het aan het object zelf moet kunnen vragen, dan zal de method op de interface moeten.

In de praktijk speelt dan natuurlijk implementatie nog mee: het feit dat een method te implementeren is op een diepere interface, wil niet zeggen dat je niet de mogelijkheid wilt hebben om een custom implementatie te maken. Daarentegen is zo'n utility class makkelijker uit te breiden. Maargoed, die beide punten maak je zelf ook al.

[djc]

Vind het op zich een duidelijk verhaal.

Als je het echter loskoppelt van de Java-achtergrond heb je het over een verschil tussen functions en methods (Java heeft geen first-class functions, wat mijns inziens een tekortkoming is).

Meer on-topic vermoed ik dat vrijwel elke mogelijke methode implementatie-afhankelijk gemaakt kan worden (e.g. geoptimaliseerd kan worden indien er kennis aanwezig is van de achterliggende implemenatie, of de kans om gegevens te cachen in een soort Memoization-pattern).

[Verwijderd]

whoami schreef op maandag 13 november 2006 @ 10:32:
In welk geval zou een Utility class state moeten bijhouden ?
Ik denk niet dat je dat moet doen...

Ik weet niet of dit een echte Utility class is, maar veronderstel het volgende: Je stopt alle functies die als doel hebben te debuggen in een class Debug. Het is bijzonder lelijk om in de code waar het echt om draait telkens een if-statement te zetten met daarin een boolean welke aangeeft of je in debug-mode bent of niet. In dit geval is het best wel aardig om die boolean als 'state' van de class Debug te
maken. Dan hoef je niet telkens in de code waar het om draait lelijke debug code neer te zetten... die kan gewoon in je Debug class.

Voor mensen die denken in code:

code:

Class Code
{
  public bool enabled;
  public Code() { enabled = true; }
  public void DoeIets() { if (enabled) { ... } }
}

Versus

code:

Class Debug
{
  public bool enabled; // om het eenvoudig te houden, dit kan netter
  public Debug();
  public void Help() { if (enabled) { .... } }
}
Class Code
{
  public Debug d;
  public Code() { d = new Debug(); d.enabled = true }
  public void DoeIets() { d.Help() }
}

[ Voor 23% gewijzigd door Verwijderd op 14-11-2006 10:44 ]

[Alarmnummer]

Verwijderd schreef op dinsdag 14 november 2006 @ 10:35:

Ik denk dat het wel handig als er onderscheid wordt gemaakt of de state conversational is of niet. Conversational state in 'utility' classes is wel vrij heel uitzonderlijk.

En alle dingen die ongebruikelijk zijn, zijn vaak ongewenst:

Een van de regels uit de Unix filosofie

* Rule of Least Surprise: In interface design, always do the least surprising thing.

En daar sluit ik me helemaal bij aan. Als er om een of andere reden wel conversational state bijgehouden moet worden, dan moet je je advragen of de class wel een util moet zijn (geef het dus in ieder geval een andere naam en andere responsibilities).

[ Voor 19% gewijzigd door Alarmnummer op 14-11-2006 11:12 ]

[Janoz]

@enWee:

Dat noem ik nou niet echt een utility class. Het debug object is zelf weer een object. Een entiteit verantwoordelijk voor het loggen. Het is niet een class waarin losstaande static methoden staan die aangeroepen worden. Je class lijkt bijvoobeeld ook heel erg op het Logger object .