Hur brukar ni använda er av konstruktorn i en factory? Det beror givetvis på hur klassen man ska instansera är uppbyggd.
Nedan ger jag två alternativ på en enkel factory som instanserar customer på olika sätt. Vilket sätt brukar man använda sig av?
public class CustomerFactory {
public Customer Create(IDataReader dataReader) {
Customer customer = new Customer();
if(dataReader.Read()) {
customer.FirstName = dataReader["FirstName"].ToString();
customer.LastName = dataReader["LastName"].ToString();
... etc (mängder med egenskaper)
}
return customer;
}
}
public class CustomerFactory {
public Customer Create(IDataReader dataReader) {
if(dataReader.Read()) {
Customer customer = new Customer(dataReader["FirstName"].ToString(), dataReader["LastName"].ToString(), (etc, mängder med egenskaper));
}
return customer;
}
}
Jag gillar inte riktigt den nedersta varianten eftersom det kan bli hur många inparametrar som möjligt till konstruktorn. Jag kan acceptera något mellanting där man skickar inparametrar till konstruktorn som är obligatoriska och där egenskaperna är satta till readonly. Men hur brukar ni göra och vad rekommenderas som best practice?
Jag tycker nog nästan att det är en smaksak, alternativ 2 ger iofersig lite mer säkerhet att man inte glömmer något, å andra sidan blir det lite mindre översiktlig kod om man tänker på att man inte direkt ser till vilken property attributet sätts till.
Om det inte är särskilt många parametrar som är obligatoriska så kan de gärna skickas in med konstruktorn, men man behöver inte vara manisk i sitt sökande efter "compile time constraints enforcement". Lite beroende på hur projektet är uppbyggt kan du ju dessutom gömma set-accessorn i en property för publika konsumenter.
Jag tycker även att du bör deklarera metoderna som statiska, för att slippa skapa en instans av Facory-klassen innan du kommer åt metoderna. För det är inte logiskt att bygga en ny Factory. "Nu vill jag ha en bil, så istället för att gå till en publik bilhandlare(Factory), väljer jag att bygga en ny industri (Ytterligare en Factory)." Typ.
Jag tycker även att du bör deklarera metoderna som statiska, för att slippa skapa en instans av Facory-klassen innan du kommer åt metoderna. För det är inte logiskt att bygga en ny Factory. "Nu vill jag ha en bil, så istället för att gå till en publik bilhandlare(Factory), väljer jag att bygga en ny industri (Ytterligare en Factory)." Typ.
I den factory-klass som visades här så är det definitivt så, men man kan ha logik i ett factory som kräver instantiering.
-> emission
Du skrev: "Lite beroende på hur projektet är uppbyggt kan du ju dessutom gömma set-accessorn i en property för publika konsumenter.".
Det har jag aldrig hört talas om. Hur gör gömmar man set-accessorn?
--> Nickemannen
Jag håller med om att man tappar översikten om man väljer alternativ 2 om det är många inparameterar. Jag märkte också ett annat problem och det var en gång när applikationen smällde vid instanseringen. Jag fick felmeddelandet: Invalid data eller något i den stilen, och radnumret var just vid instanseringen. Det var inte det lättaste att hitta vilken parameter som det var fel på så i det fallet skulle alternativ 1 hjälpt en del. Men något mellanting är nog ändå bäst...
Apropå detta med factory som singelton. Spin gav förslaget att göra factoryn shared istället. Skulle det vara bättre eller är det bara en smaksak?
Alltså om du inte har någon särskild använding av att komma åt instansen av din factory (singleton) så kan du lika gärna ha factory-metoden statisk.
Fördelen med att ha den statisk mot icke statisk är att du inte behöver instansiera factory-klassen för att använda den. Nackdelen med att deklarera din factory-metod statiskt är att du inte kan subklassa den om du skulle vilja göra det.
Jag brukar i regel låta min factory vara statisk om det inte är så att den har attribut som kan variera.
emission skrev:
I den factory-klass som visades här så är det definitivt så, men man kan ha logik i ett factory som kräver instantiering.
Om din factory stämmer in på detta fall låter det vettigt med en singleton om du bara vill ha en instans. I en singleton-klassen har du en konstruktor som anropas av metoden getInstance eller liknande, där du kan köra logiken som krävs vid instansiering.
Vad som passar bäst beror från fall till fall.
1. En instans av din factory kan se olika ut från instans till instans: vanlig klass.
2. Din instans ser alltid likadan ut och har ingen instansierings-logik: statiskt klass.
3. Du behöver bara en instans men behöver köra logik vid instansiering: singleton.
-> emission
Du skrev: "Lite beroende på hur projektet är uppbyggt kan du ju dessutom gömma set-accessorn i en property för publika konsumenter.".
Det har jag aldrig hört talas om. Hur gör gömmar man set-accessorn?
Get och Set kan ha olika tillgänglighet, så om du delar upp projektet i flera assemblys så kan du gömma Set-accessorn.
public string FirstName
{
get {return _firstName;}
internal set {_firstName=value;}
}
Lukaspojken skrev:
Apropå detta med factory som singelton. Spin gav förslaget att göra factoryn shared istället. Skulle det vara bättre eller är det bara en smaksak?
Brrr....du pratar VB-språk.... :)
Det är inte en smaksak, utan en fråga om vad ditt factory ska tillföra. I ditt exempel är CustomerFactory bara en helper-klass som gör att du slipper skicka in DataReaders in i domänklasserna. Helt klart en bra sak och om det är det enda den ska göra så är statiska metoder helt klart smidigast.
I ett annat läge kanske fabriken måste utföra andra åtgärder under objekttillverkningen (t.ex. rättighetskontroller, loggning, felhantering ) som kräver att den är en instans, och då är Singleton en smidig pattern. Det förutsätter dock att instanteringen av själva fabriken i sig inte kräver en massa kringliggande logik. Singleton fungerar bäst om den berörda klassen inte kräver några argument till konstruktorn.
266 ms totalt · 4 externa anrop · v20260731065814-full.86ec41c2
