01. februar 2005 - 16:42Der er
11 kommentarer og 1 løsning
Design patterns: Controller vs Interface?
Hej,
jeg har et spørgsmål i forbindelse med OOA/D og design patterns. Kilden er "Applying UML And Patterns" af Craig Larman.
Det er i forbindelse med en webapplikation. Jeg har en klassisk system arkitektur: 1. UI 2. Applikationslogik 3. Database
Der er en hel masse UI klasser. Jeg følger GRASP og derfor må UI klasserne ikke få direkte adgang til applikationslogikken. Der er derfor 'øverst' i applikationslogik laget nogle klasser som tager sig af input fra UI klasserne. Nærmere beskrevet er der tale om use case controllere - een use case controller per use case (bør use case controllers være et lag for sig selv? for så får jeg fire lag??). Disse controllere har ansvaret for at modtage system input fra UI klasserne og uddelegere opgaverne til klasserne i applikationslogik laget.
De klasser som jeg betegner som use case controllere, er de ikke på samme tid nogle interface klasser - og kan det lade sig gøre at være begge dele på en gang? Eller er use case controller og interface bare to ord for det samme?
Alternativet til use case controllere ville være at anvende en facade controller, men så ville jeg overtræde reglerne for Low Coupling og High Cohesion - derfor har jeg valgt at lave een use case controller per use case.
Jeg håber der er nogen som kan forklare det lidt :o)
ja lag 3 er naturligvis data laget. jeg har en DbHandler klasse som det eneste i lag 3. Denne klasser overtræder så vidt jeg har forstået principperne for low coupling (alle klasser som skal have adgang til databasen er forbundet til denne klasse) og high cohesion (klassen laver mange urelaterede ting - den tager for stort ansvar).
Men som jeg har forstået det er det i nogle tilfælde ok (er min DbHandler Pure Fabrication?). For i større projekter kan det tænkes, at der er mange flere OO programmører i forhold til SQL eksperter - og det er ikke sikker at SQL eksperterne har så meget forstand på OO programmering. Så vil det være nemmere for vedligholdelses arbejdet, at al SQL er samlet i een klasse som så er DbHandler.
Men Craig Larman nævner, at Pure Fabrication (hvis DbHandler ellers er Pure Fabrication) kun bør anvendes, når man er "desperat", men jeg tror det er ok i tilfælde af en DbHandler.
>> Men man kan vel godt sige at en controller altid definerer en form for logisk interface.
Betyder det at en controller er et interface uden så egentligt at være det eller hvad?
Som jeg ser det så er interface og facade det samme.
Larman skelner mellem facade controllers og use case controllers. Jeg synes ikke at den opdeling nødvendigvis er helt entydig. Men hvis vi føger hans terminologi, så er en controller som er et interface/facade til hele systemet en facade controller.
Pure fabrication er en fællesnævner for klasser som kun eksisterer af kode mæssige årsager men ikke har nogen baggrund i data eller forretnings logik. Larman angiver jo selv et eksempel med en persisted storage klasse. Jeg synes måske at der ville være bedre eksempler. Fordi en database forbindelse er trods alt noget rimeligt konkret. Men er det godt nok for Larman, så er det også godt nok for dig.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
