[OO] Loginmethodes en UI

[NMe]

Ik heb zojuist een discussie gehad met een leraar over de verantwoordelijkheden wat betreft het aanmaken van een formulier bij een loginsequentie. Mijn leraar stelde het volgende ontwerp voor:

Uitleg:
De applicatie (GUI) gebruikt een abstracte login-class, welke gebruikt kan worden om op verschillende manieren in te loggen. Het Formulier onder LottoLogin kan gebruikt worden om een gebruikersnaam en wachtwoord in te vullen, terwijl een Kaartlezer gebruikt kan worden om in te loggen middels een pasje, waarbij dus geen formulier op het scherm zichtbaar wordt. Hierbij zijn er dus twee totaal verschillende manieren om in te loggen.

Dan nu methode 2:

Uitleg:
Hierin gaat hetzelfde verhaal op, alleen is de verantwoordelijkheid voor het tekenen van het formulier verplaatst naar de applicatie zelf. Dit betekent dat de rest van de klassen generiek is, en de GUI makkelijk ervan los te koppelen is, zonder de "hoofdapplicatie" aan te passen.

Nou hebben beide methoden voor- en nadelen. De eerste methode houdt in dat het zaakje generieker aan is te passen; de interface met de kaartlezer is irrelevant, en dat geldt ook voor het formulier. Echter betekent dit wel dat je telkens de hoofdapplicatie aan moet passen wanneer je een ander formulier wilt gebruiken om in te loggen, terwijl mij altijd is geleerd dat dit deel van de applicatie vrij gehouden moet worden van GUI-spul. De tweede methode scheidt GUI en logica, maar resulteert in een veel minder generieke interface.

Ik vraag me af of er niet een nettere manier is om dit probleem op te lossen, zonder op functionaliteit in te leveren. Weet iemand van jullie misschien een bruikbaar pattern of architectuur?

[Verwijderd]

De schema's zijn exact hetzelfde?

[mulder]

Zoek de nul verschillen Je hebt 2x hetzelfde plaatje.

[Pakjebakmeel]

bedoel je deze soms?

[ Voor 21% gewijzigd door Pakjebakmeel op 14-03-2006 14:41 ]

[RedRose]

Ligt het aan mij of zijn beide plaatjes hetzelfde, terwijl in je verhaal functionaliteit wordt verschoven?

Anyway, waar stop je er geen 'front-controller' in die de logingegevens serialized doorstuurt naar de app? Zo kan je ook flexibel blijven m.b.t. login gegevens. GUI-code zou ik sowieso uit je app houden inderdaad. Op die manier wordt je App dan echt een business-logic laag.

[ Voor 2% gewijzigd door RedRose op 14-03-2006 14:45 . Reden: laaaaaaaat :P ]

[Verwijderd]

Wat betreft je vraag; ik denk dat het netter is om de applicatie voor de interface verantwoordelijk te laten zijn. Wel zou je bijvoorbeeld het formulier kunnen genereren op basis van bepaalde metadata in de lottologin klasse. Op die manier kun je randvoorwaarden aan de login-interface wel vastleggen op die plek.

[MicroWhale]

er zijn 3 "delen" / "schillen":

1. een functionele klasse die je daadwerkelijke functionaliteit bevat,
2. een formulier (GUI) die de klasse gebruikt en de interactie met de gebruiker afhandelt,
3. een applicatie die, afhankelijk van de gebruikte methode (kaart of handmatig) de juiste handelingen verricht.

de klasse, het formulier en de applicatie zijn dus alledrie losse onderdelen die "onafhankelijk" van elkaar gebruikt/vervangen/veranderd kunnen worden.

het formulier zie ik niet op de goede plek in je schema.

ik zou het formulier bij m'n klasse houden, zo blijft je applicatie onafhankelijk van de gebruikte methode. zo kunnen er ook makkelijk methodes bijgemaakt worden.

[ Voor 19% gewijzigd door MicroWhale op 14-03-2006 14:59 ]

[MicroWhale]

met andere woorden:

De interface van de kaartlezer zit ook bij de klasse van de kaartlezer. Er is geen reden om dat voor de interface van de handmatige login niet te doen, ook al is het een GUI. De interface staat zo bij de klasse waar deze op bouwt en niet bij de gebruiker van die interface.

[NMe]

Pakjebakmeel schreef op dinsdag 14 maart 2006 @ 14:41:
bedoel je deze soms?

[afbeelding]

Stiekem wel ja. Dat zal me leren even snel een topic te openen voor ik naar huis ga.

Verwijderd schreef op dinsdag 14 maart 2006 @ 14:45:
Wat betreft je vraag; ik denk dat het netter is om de applicatie voor de interface verantwoordelijk te laten zijn. Wel zou je bijvoorbeeld het formulier kunnen genereren op basis van bepaalde metadata in de lottologin klasse. Op die manier kun je randvoorwaarden aan de login-interface wel vastleggen op die plek.

Ik zou de interface inderdaad heel graag puur in die units houden die niets anders doen dan de UI regelen, en de business logic allemaal lekker gescheiden houden, maar dat geeft zoals ik al zei dus problemen wanneer er een kaartlezer of misschien zelfs een vingerprint- of irislezer aangesloten is. Je hebt dan geen form meer, en in plaats daarvan ga je met hardware zitten praten. Volgens methode 2 krijg je IMO een erg slecht model en kun je de zaak later niet goed onderhouden. En volgens methode 1 ben je generieker bezig, maar moet je wel in je business logic gaan klooien om een andere UI eraan te hangen. Beiden lijken me niet wenselijk.

RedRose schreef op dinsdag 14 maart 2006 @ 14:44:
Anyway, waar stop je er geen 'front-controller' in die de logingegevens serialized doorstuurt naar de app? Zo kan je ook flexibel blijven m.b.t. login gegevens. GUI-code zou ik sowieso uit je app houden inderdaad. Op die manier wordt je App dan echt een business-logic laag.

Hoe stel je je dat voor met (bijvoorbeeld) zo'n kaartlezer? Hoe verloopt de communicatie? Wanneer je een kaartlezer gebruikt is die communicatie significant anders dan wanneer je vanuit een form username en password doorstuurt, en dat is net waar hem de schoen wringt.

Logos schreef op dinsdag 14 maart 2006 @ 15:02:
met andere woorden:

De interface van de kaartlezer zit ook bij de klasse van de kaartlezer. Er is geen reden om dat voor de interface van de handmatige login niet te doen, ook al is het een GUI. De interface staat zo bij de klasse waar deze op bouwt en niet bij de gebruiker van die interface.

Ja, maar mijn bezwaar daartegen is dat je je business logic moet gaan aanpassen zodra je GUI verandert. Wil je een button toevoegen dan voldoet het aanpassen van de GUI-unit niet meer, je zult dan in de business logic moeten duiken en daar vanalles moeten aanpassen, en dat is iets wat me vanaf het begin van mijn opleiding altijd is afgeraden, en waar ik dus ook intuïtief vies van ben.

De vraag is dan ook niet welke van deze twee methoden het beste is, want dat weet ik wel. Alleen de eerste methode kan immers op een relatief nette manier toch generiek blijven. Wat ik wèl vraag, is of er een alternatieve methode is, al dan niet via een bekend design pattern, om de zaak weg te halen uit de business logic, maar wel zo dat het generiek te houden is, en dezelfde interface dus gebruikt kan worden voor die kaartlezer.

[Cuball]

Ik zou je applicatie een apparte presentatie laag geven, de applicatie zelf hoeft totaal niet te weten hoe de gebruiker ingelogd is.

In deze laag dan de mogelijkheid voorzien om verschillende login methodes te gebruiken, als je dan een nieuwe login methode wil toevoegen dan hoef je deze maar te registeren bij een verwerk login module ofzo en deze zorgt er dan wel voor dat je correct doorgestuurd wordt naar de applicatie zelf.

[MicroWhale]

-NMe- schreef op dinsdag 14 maart 2006 @ 16:32:
[...]

Ja, maar mijn bezwaar daartegen is dat je je business logic moet gaan aanpassen zodra je GUI verandert. Wil je een button toevoegen dan voldoet het aanpassen van de GUI-unit niet meer, je zult dan in de business logic moeten duiken en daar vanalles moeten aanpassen, en dat is iets wat me vanaf het begin van mijn opleiding altijd is afgeraden, en waar ik dus ook intuïtief vies van ben.

De vraag is dan ook niet welke van deze twee methoden het beste is, want dat weet ik wel. Alleen de eerste methode kan immers op een relatief nette manier toch generiek blijven. Wat ik wèl vraag, is of er een alternatieve methode is, al dan niet via een bekend design pattern, om de zaak weg te halen uit de business logic, maar wel zo dat het generiek te houden is, en dezelfde interface dus gebruikt kan worden voor die kaartlezer.

ligt eraan waar je die knop wilt toevoegen. In beide gevallen klopt de tekening van het eerste model nog. Dit tast ook niks aan aan het model. Het probleem is dat je niet 'zomaar' een knop kán toevoegen aan het formulier wat bij je login hoort. Als je dat doet veranderen ook de functionele specificaties van de onderliggende klasse, anders is er geen noodzaak voor een extra knop. Als je in de hoofd-app een knop toevoegt, veel plezier, zolang die niks aan functionaliteit toevoegd van het login-scherm die bij je klasse hoort.

wat is in jouw ogen dan die 'business logic'?

hoe verder je bij elkaar horende onderdelen uit elkaar gaat trekken, hoe moeilijker deze te onderhouden zijn.

[Orphix]

Het probleem is dat je enerzijds de presentatie laag en de business logic wil hebben. Maar in dit geval kan dat niet omdat het een sterk afhankelijk is van het andere. Immers zal een andere login (bv iris-scanner) andere gegevens doorsturen naar de loginmodule dan een online gebruikersnaam/wachtwoord formulier. Ik vind het eerste diagram dus beter dan het tweede diagram.

Aangezien er geen uniforme interface is, is het loginformulier toevoegen aan de applicatie geen goed idee. Je bent dan te beperkt.
Wil je dat je applicatie zich bezig houdt met het aanroepen van de juiste interface? Nee, je applicatie wil gewoon inloggen, en terugkrijgen of het lukt, meer niet. Het creeren van de interface in je applicatie is geen goed idee. Eigenlijk zou het niet moeten uitmaken of er een interface is, wellicht is er een Kerberos login waarbij er geen (gebruikers)interface nodig is.

Dan nu de scheiding tussen logic en interface. Logisch dat je dat wilt doen, immers zal je bank login niet op elke machine / platform dezelfde interface hebben naar de gebruiker toe. Wel dezelfde rekenmethodiek, inscantechniek, etc. Die moet je dan loskoppelen.

En waar koppel je interface en inlog logic samen? Via een factory die je aanroept vanuit je applicatie.

Ik zou het zo aanpakken (mocht het echt nodig zijn zo flexibel te zijn!):

code:

interface ILogin 
{ 
 // methodes
 void DoLogIn(); 
 // properties
}

public class BankInterfaceWindows : ILogin
{
 private ILogin loginModule;
 // forward ILogin interface
 public void DoLogIn()
 {
    loginModule.DoLogIn();
 }
 public BankInterfaceWindows (ILogin loginModule)
 {
    // constructor
    this.LoginModule = loginModule;
 }
}

public class LoginFactory
{
   public static ILogin CreateLogin()
   {
      return new BankInterfaceWindows(new BankReader());
   }
}


public class Application
{
   private ILogin loginModule;
   private void DoLogIn()
   {
      loginModule = LoginFactory.CreateLogin();
      loginModule.DoLogIn();
   }
}

[NMe]

Cuball schreef op dinsdag 14 maart 2006 @ 17:32:
Ik zou je applicatie een apparte presentatie laag geven, de applicatie zelf hoeft totaal niet te weten hoe de gebruiker ingelogd is.

Dat weet ik, dat was ook één van de argumenten die ik gebruikt heb om de tweede methode te verdedigen, ondanks dat deze dus niet goed is.

In deze laag dan de mogelijkheid voorzien om verschillende login methodes te gebruiken, als je dan een nieuwe login methode wil toevoegen dan hoef je deze maar te registeren bij een verwerk login module ofzo en deze zorgt er dan wel voor dat je correct doorgestuurd wordt naar de applicatie zelf.

Een soort veredelde observer dus? Of begrijp ik je verkeerd?

Logos schreef op dinsdag 14 maart 2006 @ 18:56:
ligt eraan waar je die knop wilt toevoegen. In beide gevallen klopt de tekening van het eerste model nog. Dit tast ook niks aan aan het model. Het probleem is dat je niet 'zomaar' een knop kán toevoegen aan het formulier wat bij je login hoort. Als je dat doet veranderen ook de functionele specificaties van de onderliggende klasse, anders is er geen noodzaak voor een extra knop. Als je in de hoofd-app een knop toevoegt, veel plezier, zolang die niks aan functionaliteit toevoegd van het login-scherm die bij je klasse hoort.

Goed, laat ik een ander voorbeeld nemen. Lees waar ik in mijn vorige post "button" schreef eens "label". Een label heeft doorgaans geen andere functie dan een informatieve. Wil je een label toevoegen in het eerste model, dan ga je je business logic (die bijvoorbeeld onder andere in LottoLogin zit) aanpassen, terwijl je geen enkele functionaliteit eraan hoeft toe te voegen. Wanneer de GUI los staat, hoef je alleen de GUI te wijzigen. Wat betreft het aantal wijzigingen dat je moet doen is dit exact hetzelfde, maar de plaats van die wijzigingen is in dat laatste geval beter. GUI-spul hoort bij elkaar en moet los te trekken zijn. Als ik wil moet ik hetzelfde programma voor de commandline kunnen compilen, door alleen maar de UI-klassen te herschrijven. Dat kan nu dus niet.

wat is in jouw ogen dan die 'business logic'?

Alles in bovenstaande modellen, behalve de beide "App"-klassen en de Formulier-klasse.

hoe verder je bij elkaar horende onderdelen uit elkaar gaat trekken, hoe moeilijker deze te onderhouden zijn.

Dat is niet waar. Als je je zaken netjes op een rijtje hebt en op een logische manier dingen uit elkaar trekt wordt het juist veel makkelijker te onderhouden, juist omdat je dan alleen die dingen aan hoeft te passen die wijzigen. GUI gewijzigd? Geen probleem, even de Formulier-klasse updaten. Nieuw loginsysteem? Geen probleem, even een nieuwe class afleiden van Login. Onderhoudbaarheid wordt juist lastiger als je je spullen dichter bij elkaar zet, IMHO.

Orphix schreef op dinsdag 14 maart 2006 @ 19:14:

Dit is inderdaad ook hoe mijn leraar het uitlegde, zij het iets minder duidelijk. Van de beide bovengenoemde methodes is dit ook zonder meer de beste, maar ik hoopte dat er een betere manier was.

[ Voor 6% gewijzigd door NMe op 14-03-2006 20:41 ]

[mulder]

Is beide niet waar, horen de LottoLogin, BankLogin etc in de business en hun schil in de presentatie?

[MicroWhale]

je maakt de denkfout. Orphix heeft het juist als hij zegt dat, in dit geval, de GUI en de daaronderliggende functionaliteit met elkaar verbonden zijn.

Een uitspraak als "alleen de GUI aan te passen" getuigt hiervan. Eén "de GUI" bestaat in dit geval niet, omdat de functionaliteit verdeeld is. Kijk bijvoorbeeld naar het "OpenDialog", "BrowseFolderDialog" of "ColorDialog". Dit is standaard functionaliteit die je gewoon kunt aanroepen. Deze "GUI's met functionaliteit" zijn al voor je gemaakt. Je kunt (afhankelijk van de ingestelde opties) de functionaliteit en het uiterlijk zelfs veranderen. De interface naar de gebruiker (maker van de app) blijft echter altijd hetzelfde en je "kunt er niet bij" als programmeur. (dit laatste is niet helemaal waar...:) )

Dit is exact wat er met je Login scherm ook aan de hand is, alleen toevallig ben je nu de programmeur van zowel de Login GUI als de algemene GUI.

[ Voor 7% gewijzigd door MicroWhale op 14-03-2006 22:30 ]

[NMe]

Don Facundo schreef op dinsdag 14 maart 2006 @ 19:36:
Is beide niet waar, horen de LottoLogin, BankLogin etc in de business en hun schil in de presentatie?

In de kern is dat wat Orphix zei, toch?

Logos schreef op dinsdag 14 maart 2006 @ 22:29:
je maakt de denkfout. Orphix heeft het juist als hij zegt dat, in dit geval, de GUI en de daaronderliggende functionaliteit met elkaar verbonden zijn.

Een uitspraak als "alleen de GUI aan te passen" getuigt hiervan. Eén "de GUI" bestaat in dit geval niet, omdat de functionaliteit verdeeld is. Kijk bijvoorbeeld naar het "OpenDialog", "BrowseFolderDialog" of "ColorDialog". Dit is standaard functionaliteit die je gewoon kunt aanroepen. Deze "GUI's met functionaliteit" zijn al voor je gemaakt. Je kunt (afhankelijk van de ingestelde opties) de functionaliteit en het uiterlijk zelfs veranderen. De interface naar de gebruiker (maker van de app) blijft echter altijd hetzelfde en je "kunt er niet bij" als programmeur. (dit laatste is niet helemaal waar...:) )

Dit is exact wat er met je Login scherm ook aan de hand is, alleen toevallig ben je nu de programmeur van zowel de Login GUI als de algemene GUI.

Als je het zo bekijkt is het inderdaad wel een stukje logischer, alleen is het verschil met een OpenDialog dat de OpenDialog uit kan gaan van enkele vaste gegevens. De OpenDialog wéét dat er een formpje is waar hij zichzelf op tekent. Dit in tegenstelling tot die Login-klasse, die geen idee heeft wat zijn eigen implementatie is. In de kern lijkt het er inderdaad wel op, maar ik ben nog steeds van mening dat het een beetje lelijk ontwerp is, omdat je dus niet meer generiek bezig bent. Maar uit de replies tot nu toe begrijp ik dat deze twee opties zo'n beetje de enige zijn die ik heb, en ik was er al uit dat de eerste methode in dat geval beter was. Nouja, dan ga ik dat maar implementeren.

Het is ook niet alsof dit voor een grote app is die perfect ontworpen moet zijn, maar ik ga met deze leraar graag de discussie aan, omdat hij iemand is die daadwerkelijk weet waar hij het over heeft.

[MicroWhale]

hoe weet je dan wanneer je welke implementatie gebruikt? Dat regel je toch in de app zelf?

Volgens mij haal je nu het object- en het business-model door elkaar.

[Orphix]

Logos schreef op woensdag 15 maart 2006 @ 08:20:
hoe weet je dan wanneer je welke implementatie gebruikt? Dat regel je toch in de app zelf?

Er is altijd een punt waarop je concreet moet worden; de lijm binnen je applicatie. In mijn opzet doet de factory dat. Hoe de factory dat doet ligt natuurlijk aan de eisen. Wellicht gewoon hard-coded, wellicht via een configuratie bestand, etc. Voordeel is dat dan applicatie en loginmodules puur tegen interfaces aan blijven praten zonder ergens de concrete types te definieeren.