c# acces modifier vs java modifier

[Verwijderd]

Hoi,

We zijn nu op het werk stilletjes aan aan het overschakelen van Java naar c#

nu normaal in java stak ik mijn business klassen in een package en gaf ik de klassen die van buiten het package mochten zichtbaar zijn de public modifier. Nu die public klassen erfden soms over van klassen die package visibility hadden , dit was echter geen probleem.

het probleem nu is als volgt, ik heb in c# hetzelfde willen doen, ik heb een dll gecreeërd voor mijn business klassen en de klassen die niet van buiten de dll zichtbaar mogen zijn hebben het internal keywoord gekregen en degene die wel buiten zichtbaar mogen zijn het public keywoord.
Maar nu het probleem zit hem als volgt, ik heb een klasse person die ik de internal modifier heb gegeven op zowel klas als constructor niveau. Ook heb ik een klasse supervisor die erft van person, supervisor moet zichtbaar zijn buiten mijn dll en dus is supervisor public, maar nu krijg ik altijd van mijn compiler de error dat person op klasse niveau ook public moet zijn, terwijl ik dit in java anders kon oplossen.

Person als klasse public maken vind ik echt afschuwelijk hoe doen jullie dit many thx

[whoami]

Waarom vind je het afschuwelijk om die class public te maken ?
Als die class niet public is, dan wil dat ook zeggen dat je bepaalde OO functionaliteit verliest, aangezien je niet meer 'tegen' die (abstracte?) class kunt programmeren.

Ik weet trouwens niet of hetgeen jij wilt mogelijk is in C#; ik ben nog nooit tegen dat probleem aangelopen, en ik kan het momenteel ook niet testen.

[Verwijderd]

mja dat is het nu net ik wil niet tegen de abstracte klasse programmeren.

Ik wil dat enkel en alleen mijn business klassen zichtbaar zijn voor mijn gebruikers, mijn abstracte klassen zijn enkel een implementatie detail (althans in mijn ogen) waar mijn gebruikers zelfs niet mogen weten of het bestaat.

In mijn applicatie heb ik zowel supervisors als agents (welke beiden erven van person) maar person mag nooit gebruikt worden buiten mijn assemblie.
Polymorfische is hiervoor (voor de applicatie) uitgesloten dus mijn base klasse mag verborgen blijven.

Toch wel een rare beslissing van MS om dit zo te implementeren

[misfire]

Ik vind de keuze van MS eigenlijk logischer, en het past ook in de overerving filosofie van .NET, die een stuk restrictiever is dan in Java. Ik vind package/public mixen in Java ook onnatuurlijk. Als je namelijk een subklasse van Supervisor zou willen maken, dan kun je net niet die ene package methode van Person aanroepen oid.

Wat je wilt is dat Person niet voorkomt als type buiten je .NET assemby. Er zijn twee manieren om dit te doen:

* Maak een business interface voor Supervisor. Maak de interface public, en implementeer de klasse zoals je het zelf wilt. Maak nieuwe Supervisor instanties met een factory.
* Maak de Supervisor klasse zonder te extenden van Person, maar hou de Person als member in Supervisor bij, en hergebruik de functionaliteit via compositie.

Lijken me allebei vrij nette oplossingen voor je probleem, het hangt van je situatie af welke van de twee de voorkeur verdient.

[Verwijderd]

Ik vind de keuze van MS eigenlijk logischer, en het past ook in de overerving filosofie van .NET, die een stuk restrictiever is dan in Java.

staan deze restricties ergens beschreven? Want hierover kan ik niets terugvinden in mijn boeken of op google en ook niet op msdn
nu ja misschien vind ik mijn weg nog niet zo goed op msdn, want dit is vrijwel nieuwe voor mij altijd met java api gewerkt :-)

[Verwijderd]

misfire schreef op zondag 29 januari 2006 @ 19:05:
Als je namelijk een subklasse van Supervisor zou willen maken, dan kun je net niet die ene package methode van Person aanroepen oid.

Let's hack:
reflection setAccessibility(true)

[Verwijderd]

In java zou ik zelfs geen reflection nodig hebbne in de klasse die public staat roep ik gewoon via super de methode op die in mijn package visibility klasse staat

:-)

[Verwijderd]

Sorry voor de kick maar ik vroeg me af of iemand ergens een goeie uitleg weet over de regels van overerving in c#.
Want dat je enkel maar kan overerven van klassen die dezelfde zichtbaarheidsparameter hebben heb ik nog nooit kunnen vinden in mijn boeken en documentatie, dus misschien mis ik zo ook nog andere zaken

Google zoektocht levert echter tot op heden niets op alsook op msdn zelf vind ik hier niets van behalve als mijn compiler de fout geeft en ik ga dan daar naartoe zegt hij wel dat de visibility niet minder mag zijn.

[Woy]

Ik vind het op zich ook logisch dat je alleen van public classes kunt erven als je class zelf ook public is.
Andere classes zullen toch ook de interface van de Base class moeten weten aangezien ze anders niet eens kunnen zien welke methodes ze allemaal op een class aan kunnen roepen.

Ik vind het dus logisch dat de hele class hierarchie boven een class dezelfde of een ruimere access modifier moet hebben. Als je toch gebruik wilt maken van functionaliteit die alleen package visible is dan lijkt het mij logischer dat je via composite werkt.

[ Voor 5% gewijzigd door Woy op 31-01-2006 11:56 ]