[.NET] base(): private constructor aanroepen

[H!GHGuY]

Ik wil een System.Diagnostics.Process aanbieden aan plugins, maar ik wil de controle beperken.

Dus heb ik een stuk van de interface van de Process klasse gecopy-paste in een interface

C#:

interface IMyProcess
{
   // members die ik wil aanbieden
}

Natuurlijk leidt de Process klasse hier nog niet vanaf, dus

C#:

class MyProcess : System.Diagnostics.Process, IMyProcess
{
  internal MyProcess() {}
}

... en klaar was de kous.

Nu wil ik de static member GetProcessById(int) gebruiken. Via disassembly zie ik dat die een private constructor aanroept.

Is er een manier om alsnog die memberfunctie te kunnen gebruiken met mijn afgeleide klasse?

- Via reflection oproepen kan niet aangezien je niets kan doen met/voor de base() constructie (~ interne code)
- Casten en dergelijke kunnen ook niet aangezien de Process geen MyProcess is natuurlijk (~externe code)

ik zie er eigenlijk tegenop om een is-a relationship op te bouwen en dan te gaan wrappen voor elke member, zeker aangezien het niet enkel over de members gaat die ik wil aanbieden in de interface, maar ook aangezien ik de andere members wel zelf wil kunnen gebruiken.

[ Voor 7% gewijzigd door H!GHGuY op 27-11-2007 20:49 ]

[cspare]

H!GHGuY schreef op dinsdag 27 november 2007 @ 20:48:
Dus heb ik een stuk van de interface van de Process klasse gecopy-paste in een interface

Ik snap niet helemaal wat je wilt, als jouw MyProcess zowel System.Diagnostics.Process als IMyProcess implementeerd krijgt je klasse juist meer functionaliteit in plaats van minder?
Je erft over van de Process klasse, dus moet jouw MyProcess zich ook aan die interface conformeren, je kan niet zomaar methodes weghalen.

Edit: Of bedoel je soms te zeggen dat je een IMyProcess wilt aanbieden aan de plugins, ipv een System.Diagnostics.Process zoals je zegt?

Nu wil ik de static member GetProcessById(int) gebruiken.

Waar, hoe? en wat voor invloed heeft het voor jou dat er een private methode word aangeroepen, dat werkt toch gewoon prima zolang jij de GetProcessByID methode maar kan benaderen.

[ Voor 8% gewijzigd door cspare op 27-11-2007 22:01 ]

[Gerco]

Wrappen lijkt me hier toch de oplossing. Maak een System.Diagnostics.Process aan en wrap deze in je eigen class die IMyProcess implementeert. Dan delegeer je alle calls naar die System.Diagnostics.Process instance die je wrapt en je bent klaar.

Je moet inderdaad wat members "overbodig" wrappen, maar een beetje IDE heeft wel een manier om dat grotendeels automatisch te doen.

[ Voor 5% gewijzigd door Gerco op 27-11-2007 21:31 ]

[whoami]

H!GHGuY schreef op dinsdag 27 november 2007 @ 20:48:
Ik wil een System.Diagnostics.Process aanbieden aan plugins, maar ik wil de controle beperken.

Dus heb ik een stuk van de interface van de Process klasse gecopy-paste in een interface

C#:

interface IMyProcess
{
   // members die ik wil aanbieden
}

Natuurlijk leidt de Process klasse hier nog niet vanaf, dus

C#:

class MyProcess : System.Diagnostics.Process, IMyProcess
{
  internal MyProcess() {}
}

... en klaar was de kous.

[/code]Nu wil ik de static member GetProcessById(int) gebruiken. Via disassembly zie ik dat die een private constructor aanroept.

Die static member zal vziw geen private instance constructor gaan aanroepen, maar een static constructor en die is -volgens mij- altijd private

Verder: waarom laat je MyProcess niet wrappen rond System.Diagnostics.Proces ? Je wilt een beperkte functionaliteit aanbieden, maar aangezien jouw MyProcess een System.Diagnostics.process is, is het gewoon mogelijk dat alle members van Process aangeroepen worden ?
Is er een manier om alsnog die memberfunctie te kunnen gebruiken met mijn afgeleide klasse?

ik zie er eigenlijk tegenop om een is-a relationship op te bouwen en dan te gaan wrappen voor elke member

wrappen != een is-a relationship ?

zeker aangezien het niet enkel over de members gaat die ik wil aanbieden in de interface, maar ook aangezien ik de andere members wel zelf wil kunnen gebruiken.

Ik volg je even niet meer .... Wat wil je nu eigenlijk gaan doen ?

[DrDelete]

Ik zou NIET overerfen van Process.

Zoals Gerco aangaf, moet je inkapselen. Maak "Proces" een private member van jouw eigen class, implementeer jouw IProcess interface en stuur calls door naar jouw private Proces instance van System Diagnostics.

dus

code:

public interface IMyProcess
{
    void MyMethod();
}

public class MyProcess : IMyProcess
{
   private System.Diagnostics.Process _process;
   internal MyProcess()
   {
   }



   public MyMethod()
   {
      process.YYYYY()
   }
}

Maak daarbij nog een ProcessFactory bij die de instance van deze class kan maken want de constructor is internal waardoor een reguliere "new" niet werkt.

[ Voor 13% gewijzigd door DrDelete op 28-11-2007 07:32 ]

[H!GHGuY]

cspare schreef op dinsdag 27 november 2007 @ 21:26:
Edit: Of bedoel je soms te zeggen dat je een IMyProcess wilt aanbieden aan de plugins, ipv een System.Diagnostics.Process zoals je zegt?

Juist.

Die interface bevat ongeveer de helft van alle methodes die System.Diagnostics.Process heeft.

Waar, hoe? en wat voor invloed heeft het voor jou dat er een private methode word aangeroepen, dat werkt toch gewoon prima zolang jij de GetProcessByID methode maar kan benaderen.

C#:

class Process
{
   private Process(int id, bool remote, string machine, System.Diagnostics.ProcessInfo info) {...}
   public static System.Diagnostics.Process GetProcessById(int id)
   {
      return new Process(id, false, ".", new System.Diagnostics.ProcessInfo());
   }
}

zijn de signaturen/implementaties ongeveer.

Ik wil diezelfde method hebben, maar dan met mijn MyProcess klasse, zonder dat ik al die idiote members moet gaan wrappen.

whoami schreef op dinsdag 27 november 2007 @ 21:48:
Die static member zal vziw geen private instance constructor gaan aanroepen, maar een static constructor en die is -volgens mij- altijd private

zie hierboven

Verder: waarom laat je MyProcess niet wrappen rond System.Diagnostics.Proces ? Je wilt een beperkte functionaliteit aanbieden, maar aangezien jouw MyProcess een System.Diagnostics.process is, is het gewoon mogelijk dat alle members van Process aangeroepen worden ?

Hmm, juist ja.

wrappen != een is-a relationship ?

toch wel, maar containment is meer typisch voor een has-a relationship, waar wrappen natuurlijk uitzondering #1 op is.

Waar het op neerkomt is een

C#:

MyProcess GetProcessById(int id);

aanbieden.

[whoami]

Wrappen is voor mij ook een has - a relationship.
Wrappen is geen is - a relatie want je zal nooit Liskov kunnen toepassen.

code:

MyProcess myP = new MyProcess();

DoSomething (myP);
...
public void DoSomething( System.Diagnostics.Process p )
{
}

H!GHGuY schreef op woensdag 28 november 2007 @ 18:56:
[...]

Ik wil diezelfde method hebben, maar dan met mijn MyProcess klasse, zonder dat ik al die idiote members moet gaan wrappen.

Tja, .... als je die methods niet kunt overriden (wat je niet kunt), zal je ze moeten hiden, en dat vind ik pas ranzig (zeker als je dan gaat gaan casten, kan je lekkere resultaten krijgen).
Waarom wil je niet gaan wrappen; het lijkt me dat dit in dit geval de beste oplossing zal zijn.

[ Voor 50% gewijzigd door whoami op 28-11-2007 19:00 ]

[whoami]

H!GHGuY schreef op woensdag 28 november 2007 @ 18:56:

C#:

class Process
{
   private Process(int id, bool remote, string machine, System.Diagnostics.ProcessInfo info) {...}
   public static System.Diagnostics.Process GetProcessById(int id)
   {
      return new Process(id, false, ".", new System.Diagnostics.ProcessInfo());
   }
}

zijn de signaturen/implementaties ongeveer.

Ik wil diezelfde method hebben, maar dan met mijn MyProcess klasse, zonder dat ik al die idiote members moet gaan wrappen.


[...]

zie hierboven

Ah ok, die static member is dus gewoon een factory method die een private instance constructor aanroept om jou een instance te returnen.
Maar goed, dat veranderd niets aan m'n mening dat ik vind dat je moet wrappen.

[ Voor 5% gewijzigd door whoami op 28-11-2007 19:06 ]

[cspare]

Hmm, ik zal wel iets over het hoofd zien, maar is onderstaande geen optie dan?

C#:

class Process
{
   private Process(int id, bool remote, string machine, System.Diagnostics.ProcessInfo info) {...}
   public static System.Diagnostics.Process GetProcessById(int id)
   {
      return System.Diagnostics.Process.GetProcessById(id);
   }
}

Anyways, waar haal je opeens de Process klasse vandaan? Hoe mapt dat op je verhaal in de threadstart post?

Edit: En wederom moet ik 20 keer lezen voordat ik snap wat je bedoeld... het gaat dus om de implementatie van de .NET framework klasse?

[ Voor 44% gewijzigd door cspare op 28-11-2007 20:40 ]

[Verwijderd]

Beste lijkt mij Process als private member op te nemen.

Wat je namelijk ook doet met overerven, je kunt ook gewoon een interface casten naar een object. Geef jij IProcess, wat in wezen MyProcess is welke weer afstamt van Process, dan kan je plug-in gewoon die IProcess casten naar Process. En daar gaat je "beveiliging"

Dan mijn vraag aan jou: een plug-in kan toch ook een Process verkrijgen?

[H!GHGuY]

Verwijderd schreef op woensdag 28 november 2007 @ 21:33:
Beste lijkt mij Process als private member op te nemen.

Wat je namelijk ook doet met overerven, je kunt ook gewoon een interface casten naar een object. Geef jij IProcess, wat in wezen MyProcess is welke weer afstamt van Process, dan kan je plug-in gewoon die IProcess casten naar Process. En daar gaat je "beveiliging"

Dan mijn vraag aan jou: een plug-in kan toch ook een Process verkrijgen?

Niet als ie niet de juiste security permissions heeft
En dat is nu net de bedoeling: De plugins krijgen geen enkele permission, enkel mijn hoofdprog en eventuele libraries.

Wrappen zal het dus worden zeker
Zal ik even zoet mee zijn.

[ Voor 4% gewijzigd door H!GHGuY op 29-11-2007 18:45 ]

[farlane]

Is er geen tooltje die die informatie voor je kan genereren uit de assembly?

[H!GHGuY]

farlane schreef op donderdag 29 november 2007 @ 20:34:
Is er geen tooltje die die informatie voor je kan genereren uit de assembly?

Zegt me niets...
Dat er macro's bestaan om van fields properties te genereren, dat zeker maar properties wrappen uit een assembly?

[farlane]

H!GHGuY schreef op zaterdag 01 december 2007 @ 15:36:
Zegt me niets...
Dat er macro's bestaan om van fields properties te genereren, dat zeker maar properties wrappen uit een assembly?

Met al die reflection topics moet er toch wel iets voor zijn lijkt me .... kun je hier http://www.java2s.com/Cod...mationaboutanassembly.htm iets mee ?

[Gerco]

H!GHGuY schreef op donderdag 29 november 2007 @ 18:44:
Wrappen zal het dus worden zeker
Zal ik even zoet mee zijn.

Eclipse heeft hiervoor in het context menu "Source -> Generate delegate methods", Visual studio zal zoiets toch ook wel hebben. Helemaal niet veel werk dus.