SPiN skrev:
Jag förstår vad du menar, visst känns det mer naturligt att hämta via GetByMemberStatusGold() - men frågan om att behöva ändra i gränssnitt just på grund av detta var vad jag syftade på. Istället för att behöva uppdatera ett gränssnitt när man lägger till funktionalitet för att hämta GetByMemberStatusBronze() och då oroa sig för implementationerna bör man ju ha ett så abstrakt gränssnitt som möjligt. Det var en återknytning till topic, "Förändring av interfaces", där jag bara påpekade att .NET erbjuder funktionalitet som på ett enkelt sätt kan appliceras för att slippa ändra i gränssnitt.
Jag har inte programmerat så mycket i .NET, men det är ofta jag stöter på GetXByACriteria()-metoder istället för att använda sig av closures. Men det är väl som du säger, det känns lättare att utnyttja metoder som direkt gör det man vill. För att minska beroenden mellan sina applikationer bör man däremot inte deklarera dessa GetXByACriteria() i sina, generella, gränssnitt.
erkas länk var bra och rakt på sak. Däremot håller jag inte med om att man ska sluta använda generella (inte generiska ;)) gränssnitt. En service som inte har full koll på vilket repo som ska användas, kan i så fall använda sig av det generella gränssnittet. Vill man, som Greg menar, minska kontraktes område kan man i så fall ärva från den generella gränssnittet och utöka med mer funktionalitet. Bara för att man ärver av ett gränssnitt, betyder inte det att det är gränssnittets funktionalitet man är ute efter när man tar emot i metoder osv. Bara att man _kan_ använda den funktionaliteten då ärvande klasser måste implementera gränssnittets metoder. Alldelles för ofta tycker jag att folk tar emot ett gränssnitt och kastar om det till en specifik klass istället för att ta emot klassen direkt. S.k. down-cast är tråkigt att se, då är det något i modelleringen som inte stämmer...
interface IFace {
public void DoStuff();
}
class AnyClass : IFace {
...
}
...
public void AnyMethod(IFace obj) {
AnyClass a = (AnyClass) obj;
}
/* gentemot: */
public void AnyMethod(AnyClass obj) {
...
Nu känns det som att jag bara svamlar, men jag hoppas att jag får fram något vettigt...
Det är nu jag ser istället för att "skapa" flera GetByX använda FindAll. Som ex. på
GetXByACriteria()-metoder istället för att använda sig av closures
Och implementera ett specification-pattern, exempelvis.
- GetByMemberStatusGold
- GetByMemberStatusSilver
- GetByMemberStatusBronze
Kan sättas som:
- MemberStatusSpecification.GoldStatus
- MemberStatusSpecification.SliverStatus
- MemberStatusSpecification.BronzeStatus
Och nyttja FindAll från gränssnitt:
_repository.FindAll(MemberStatusSpecification.GoldStatus);
För att sedan lätt kunna lägga till:
- MemberStatusSpecification.Platina
- MemberStatusSpecification.Iron
- MemberStatusSpecification.Dirt
Eller för exempelvis anställda:
- GetByHighPaid
- GetByLowPaid
- GetByNormalPaid
Kan sättas som:
- EmployeePaidThresholdSpecification.High
- EmployeePaidThresholdSpecification.Low
- EmployeePaidThresholdSpecification.Normal
Och nyttja FindAll från gränssnitt:
_repository.FindAll(EmployeePaidThresholdSpecification.Normal);
Så ja, det är nog kanske åt det hållet jag skulle vilja arbeta.
Istället för att använda en massa:
- GetByFirstName()
- GetByName()
- GetBySocialSecurityNumber()
Nyttja:
_repository.FindAll(e => e.SocialSecurityNumber.Equals(socialSecurityNumber));
osv.
Och använda specification delen på sådant som har Fasta värden, eller värden som styrs av ex ett tröskelvärde av något slag.
Nu babblar jag också på.. Men jag får lite svar på ang. ändra i interfacet eller inte ändra i det.