Partial class?

Josef, high cohesion och low coupling är två riktigt viktiga grundläggande designmål som man vill uppnå i objektoriterad programmering för att göra program lätta att förstå och underhålla. Low coupling, är att man ska ha så få beroenden mellan klasserna som möjligt. För att uppnå high cohesion så grupperar man man metoder som är starkt relaterade till varandra, dessa metoder utgör sedan klasserna. Ett exempel där du inte uppnår high cohesion, är naturligtvis om du har en klass som gör massa olika saker, dvs metoderna i klassen har inte ett starkt beroende mellan varandra. Det faller sig ganska naturligt att klassen blir svårare att förstå, om den inte har ett stark definierat ansvar/uppgift. Det är lättare att förstå sig på en klass som uppnår high cohesion. Bästa korta beskrivningen jag har hittat är nog...

The concepts are usually related: low coupling implies high cohesion and vice versa. In the field of object-oriented programming, the connection between classes tends to get lower (low coupling), if we group related methods of a class together (high cohesion).

Mer info
http://en.wikipedia.org/wiki/Coupling_(computer_science)
http://www.ugolandini.net/AccoppiamentoCoesioneE.html
http://www.google.se/search?hl=sv&lr=&defl=en&q=define:High+Cohesion&sa=X&oi=glossary_definition&ct=title

Vidare skulle jag tipsa om att läsa lite mer om Object Oriented Design and Analysis (OOAD) där det finns tekniker och tillvägagångssätt för att upnå dessa designmål. Jag anser nämligen att man absolut bör känna till dessa begreppen om man håller på med OOP.

Skyller på min blodbrist som gör att jag allmänt är förvirrad just nu. Menade givetvis Coupling, du vill ha high coupling, att dina klasser är starkt beroende av varandra. cohesion och coupling kan ju även gälla metoder, men jag syftar på klasserna. Om de är partials och interna klasser underordnade som partial blir ju coupling väldigt hög.

OOAD är det Mattiasen? Isf. är väll det snarare en systemutvecklingsmetod de syftar på att arbeta efter om man vill få fram en bra lösning, en blandning mellan ssm och andra mer teknikorienterade som rup. Men visst den har lite bra riktlinjer man kan norpa :) Enterprise patterns från MS-pres tar upp en hel del bra utöver patterns också:) finns på MSDN gratis.

Jag syftar inte på en systemutvecklingsmetod. Vad jag lärt mig så är OOAD ett sätt att designa/modellera ett system på en högre nivå. UML är ett användbart verktyg bland annat.
http://en.wikipedia.org/wiki/OOAD

Sedan undrar jag varför man vill ha starka beroenden? Det är ju vad man vill undvika och en stark bidragande anledning till att design mönster finns är för att kunna uppnå low coupling. Jag kanske är helt ute och cyklar, dvs att man använder partial classes när man vill ha starka beroenden mellan klasser, men jag tycker det rimmar helt fel enligt de objektorienterade principerna.

/Edit
Läste igen..

erka skrev:

Om de är partials och interna klasser underordnade som partial blir ju coupling väldigt hög.

Kanske besvarar min fråga om starka beroenden.. :q

I det här fallet har jag ju bara använt partiella klasser för att bygga upp ett "klassträd". Inte för att jag behövde funktionalliteten.

compusa skrev:

Jag kanske är helt ute och cyklar, dvs att man använder partial classes när man vill ha starka beroenden mellan klasser,

Man använder inte partial classes för att få starka beroende mellan klasser, partial är ju samma klass som läggs i olika filer bara. Partial har inget med design möster att göra, utan bara en funktion i språket för att underlätta vid utvecklingen, alla filer kompileras ju ihop till 1 klass i slutändan.

josef skrev:

I det här fallet har jag ju bara använt partiella klasser för att bygga upp ett "klassträd". Inte för att jag behövde funktionalliteten.

Jag ser fortfarande inte vinsten med att ha så många privata klasser till en annan klass. Vad är det för vits med att ha en privat adress klass till en User, om man samtidigt måste ha en adress till en companyklass, då är det ju bättre att adress är en helt vanlig klass som kan användas av både user och companyklasserna. Du kan inte ge ett exempel på hur ditt "klassträd" ser ut?

- M

- M

Gladh skrev:

Partial har inget med design möster att göra, utan bara en funktion i språket för att underlätta vid utvecklingen

Precis. Det är snarast att betrakta som ett kompileringsdirektiv.

T ex:
Klassen User har ett antal properties:
-Username
-Password
-Country
-Email
etc..

Sedan har klassen UserManager (eller Data.User) ett antal metoder Create, Update etc.. Dessa kan i sin tur ta Model.User som in-parameter.

Jag måste medge att jag för varje inlägg av Josef i denna tråd blivit mer och mer förvirrad av själva syftet till lösningen.
Ska se om jag fattat rätt:
Klassen User som du pratar om, är det din Model.User? Med andra ord Model är ditt namespace för domänmodellen?
Data.User är alltså DAL-klassen för User?
Så långt är jag med och förstår fullt och fast.
Men det du i och med partial lägger ihop till en klass är det:

Class Model.User
Username
Password
Country
Email

Class Data.User
Create()
Update()
End Class Data.User

End Class Model.User

Är då ditt syfte med detta att du kapslar in DAL i respektive klass som DAL-klassen hanterar?

Det finns ju många olika design-metod så jag ska inte klanka ner på din lösning. Man arbetar med det som fungerar för en själv.

Personligen har jag blivit DDD-frälst senaste året, men inför varje ny applikation måste man självklart se över om någon annan design-metod fungerar bättre.

Min egen simplifierade lösning av ovanstående skulle förmodligen se ut nåt sånt här:

Namespace Domain.Accounts.User

Class User
Username
Password
Country
Email
End Class

Class UserRepository
public User Create()
public bool Update(User)
public bool Save(User)
End Class

End Namespace

Där User och UserRepository ligger i varsin egen fil.

Är väldigt nyfiken på att se ett mer detaljerat exempel av Josef.
Trådens ursprungsfråga rör ju inte detta men vi kanske kan låna tråden en liten stund eftersom ursprungsfrågan redan blivit besvarad.

Jag har ju nästan gjort som du har, i ditt andra exempel. Dock har jag ju User-klassen i den partiella klassen Model, och din UserRepository-funktionalitet i min partiella Data.User-klass.

Dock är ju inte Data ett jättebra namn. Men eftersom det företaget jag jobbar på nu har döpt sin sin struktur efter ovan förklarade mönster gör jag det också. Kanske Manager.User hade varit bättre än Data.User, men men... ;)

Jo, men det är just det där "nästan" som gör en väldigt markant skillnad i och med att din Data.User klass är inkluderade inuti Model.User. Att klassen är partiell eller inte är irrelevant eftersom partial class endast handlar om att man kan dela upp klasskoden på flera filer. När du kompilerar blir det en enda klass, Model.User, som sedan innehåller klassen Data.User.
Som redan nämnts här i tråden har Partial inget med design att göra utan är endast ett hjälpverktyg som finns för att underlätta programmeringen.

Så min fråga angående din design handlar alltså om anledningen till att du vill lägga din Data.User inuti Model.User istället för som en egen fristående klass.
Eller har jag missförstått?
Har du lust att lägga in lite kodexempel på hur din partiella klass Model ser ut? Eller hur själva modell-strukturen ser ut.

Data.User ligger inte i Model.User. Har aldrig gjort, kommer aldrig att göra. ;)
Jag vet att deklarationen partial bara är ett kompileringsdirektiv.

public partial class Model
{
      public class User
      {
            private string _name;
            private string _country;

            public string Name()
            {
                  get { return _name; }
                  set { _name = value; }
            }
            [i]etc...[/i]
      }
}

Och så Data.User

public partial class Data
{
      public class User
      {
            public void Create(Model.User u)
            {
                  ...
            }

            public void Update(Model.User u)
            {
                  ...
            }

            public void Delete(Guid id)
            {
                  ...
            }
      }
}

Förstår du nu? :)

Gör Data och Model något mer? I exemplet är de reducerade till att agera namnrymder.

Ok, då var det lite missförstånd av de tidigare inläggen.
Men jag får instämma med emission. Varför har du de omgivande klasserna Model och Data? Det borde vara samma effekt som namnrymder.

namespace Model
class User

namespace Data
class User

Anropas via;
Model.User
och
Data.User

Då behövs inte partial class Model och Data.

Om jag förstår det rätt så när du lägger till t.ex. klasser för Company så skulle det bli:

partial class Model
class Company

och

partial class Data
class Company

Men vad det innebär är att i den kompilerade applikationen kan du få två enorma klasser, Model och Data. Det låter inte särskilt bra.

Som tidigare nämnt i denna tråd skulle namnrymder resultera i det samma, men vad blir egentligen skillnaden mellan partiella klasser och namnrymder?

"partiella klasser" är inte partiella, det är en stor klass. Partiell är som tidigare nämnts endast ett litet hjälpmedel som gör att man kan lägga en klass i flera filer. Kan vara till stor hjälp om man är ett team eller om man använder sig av kodgenerering. Jag vet inte ens om det existerar nån annanstans än i .NET 2.0. Det är inte en typ av klass eftersom alla dessa delar slås ihop till en klass vid kompilering.
Detta innebär att din modell består av en eller flera enorma klasser som kapslar in resterande klasser.
Skillnaden mellan namnrymder och enorma klasser är i min värld väldigt stor.
Jag säger inte att du ska sluta använda det men jag är väldigt nyfiken på hur din design-metod uppstod för jag har aldrig sett tänket någonannanstans.

Efter att ha begrundat den här tråden litegranna känns det snyggare att använda namnrymder istället för klasser till det ändamålet som jag gör idag.

Hur den uppstod? Jadu, Tyckte det vore snyggt med att ha samma namn på klasserna som hade att göra med samma sak. Nu föll det sig så att Model och Data blev "prefix" i form av någon slags övergripande klass. Detta skulle kunna åstakommits med namnrymder men det blev klasser istället. Har inte bättre förklaring än så. ;)

Hmm, diskussionen har sprungit iväg en hel del, och det har sannerligen varit intressant att läsa. Men för att knyta ihop min orginalfråga: Är webbforms partial class per default bara för att kunna dela upp klassen i två delar? (Det vill säga default.aspx och default.aspx.cs till exempel)

Ja, partial class är default för att dela upp klassen.
default.aspx och default.aspx.cs har inget med partial att göra. .aspx.cs filerna är codebehind. Det handlar om delning mellan presentation och logik.

Partial indelning ger .cs och .designer.cs av VS2005. I .designer.cs lägger VS2005 deklarationerna av webbkontrollerna.
Det är alltså codebehind som man delar in i partial class eftersom DET är själva klassen. .aspx sidan är inte klasskod utan layout (HTML).

Detta gäller inte bara webbformulär utan alla kodklasser. T.ex. i ett classlibrary kan man göra:
minklass.cs
minklass.deklarationer.cs
minklass.metoder.cs

eller nåt liknande med en partial class minklass i samtliga.