Results 1 to 13 of 13

Thread: Strict Private vs Private

  1. #1

    Strict Private vs Private

    Hallo hallo,

    Waarom zou je nog private gebruiken in plaats van strict private? De enige redenen die ik kan bedenken zijn:

    1) De klasse moet ook werken in Delphi 7 of lager

    2) Je levert geen sourcecode en wilt "voorkomen" dat er afgeleide van je class worden gemaakt.

    Zijn er nog andere redenen?

    Bij voorbaat dank!

  2. #2
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,230
    Ik vind 'private' niet eens echt private. Je kan er altijd bij. Ik gebruik 'strict private' als er variabelen zijn, die echt niet gezien mogen worden.
    Delphi is great. Lazarus is more powerfull

  3. #3
    Hoe kan je er altijd bij? Private is alleen zichtbaar voor code binnen dezelfde unit, niet in afgeleiden. Strict private is stricter, en staat alleen het gebruik binnen de class toe, dus niet in andere code. De unit-grens geldt nog steeds; daarbuiten kan je er sowieso niets mee.

    Dus wanneer gebruik je strict? Als je meerdere classes in een unit hebt, maar wel wilt afdwingen voor jezelf en je collega's dat die classes niet aan elkaars privates mogen zitten.

    Voor mij is dat niet zo'n interessante principe. Classes die hun eigen specifieke functionaliteit hebben staan toch al niet in dezelfde unit. Classes die bij uitzondering wel bij elkaar staan, zijn een hoofdclass en wat hulptypen die specifiek voor die class nuttig zijn. In dat geval zijn ze al zo verstrengeld dat het private-principe vaak ook niet veel meer uitmaakt.

    Al met al gebruik ik vrijwel nooit strict private, maar beschouw ik private vaak wel als zodanig, en kan ik waarschijnlijk zonder issues 99% van al m'n privates in strict private veranderen.
    1+1=b

  4. #4
    Dus wanneer gebruik je strict? Als je meerdere classes in een unit hebt, maar wel wilt afdwingen voor jezelf en je collega's dat die classes niet aan elkaars privates mogen zitten.
    Aan elkaars "privates" zitten is sowieso not done met die hele #MeToo Maar even zonder dollen waarom zou je aan private members willen komen? Is dat niet per definitie een slecht ontwerp?

  5. #5
    Fornicatorus Formicidae VideoRipper's Avatar
    Join Date
    Mar 2005
    Location
    Vicus Saltus Orientalem
    Posts
    5,212
    Quote Originally Posted by luigi View Post
    Is dat niet per definitie een slecht ontwerp?
    Dat kan (wanneer bepaalde functionaliteit niet of niet goed is geïmplementeerd), maar
    ik zie ook veel onkunde/gebrek aan kennis in sommige code, dus de klasse kán het wel
    zelf, maar de programmeur die de klasse aanspreekt denkt het beter te weten.

    (Op dit moment ben ik door code als onderstaand aan het waden: ook zo'n feest)

    Delphi Code:
    1. implementation
    2.  
    3. var
    4.   Other: TSomeOtherForm; // Ja dit staat echt globaal gedeclareerd...
    5.   S: string;
    6.  
    7. procedure TSomeForm.DoButton(Sender: TObject);
    8. begin
    9.   Other := TSomeOtherForm.Create(Self);
    10.   try
    11.     Other.Caption := 'Dit is een dialoogvenster';
    12.     Other.Label1.Caption := 'Hoe heet u?';
    13.     Other.ComboBox1.Items.Add('Ja');
    14.     Other.ComboBox1.Items.Add('Nee');
    15.     Other.ComboBox1.Items.Add('Weet niet');
    16.     if Other.ComboBox1.Items.Count > 0 then
    17.       Other.ComboBox1.ItemIndex := 1;  
    18.     Other.EenDataModule.EenConnectie.ConnectionString := EenHeelAndereForm.Connection.ConnectionString;
    19.     Other.EenDataModule.EenConnectie.Active := True;
    20.     Other.Showmodal;
    21.     if Other.ModalResult = mrOk then
    22.     begin
    23.       S := Other.Edit1.Text;
    24.     end;
    25.   finally
    26.     Other.Free;
    27.   end;
    28. end;
    Waarom?
    Omdat het kan (designtime componenten zijn niet private, dus iedereen kan erbij).
    TMemoryLeak.Create(Nil);

  6. #6
    altijd fijn, die sociale classes die de hele wereld kennen

    Die zijn ook altijd leuk als je ze used in een project, ineens is je project afhankelijk van alle andere units in het pad.

  7. #7
    Ik leef oprecht met je mee VideoRipper Het lijkt me onbegonnen werk om van dat soort code nog iets te maken.

  8. #8
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,230
    Hoe kan je er altijd bij? Private is alleen zichtbaar voor code binnen dezelfde unit, niet in afgeleiden
    Delphi Code:
    1. type TFoo=class
    2.   private
    3.     fFoo1 : string;
    4.   public
    5.    property Foo1 : string read fFoo write fFoo;
    6. end;
    7.  
    8. MyFoo = TFoo;
    9. MyFoo.Foo1 := 'hallo';  // <---- dit mag
    10. MyFoo.fFoo1 := 'hallo';  // <---- dit mag
    Delphi Code:
    1. type TFoo=class
    2.   strict private
    3.     fFoo1 : string;
    4.   public
    5.    property Foo1 : string read fFoo write fFoo;
    6. end;
    7.  
    8. MyFoo = TFoo;
    9. MyFoo.Foo1 := 'hallo';  // <---- dit mag
    10. MyFoo.fFoo1 := 'hallo';  // <---- dit werkt niet
    Delphi is great. Lazarus is more powerfull

  9. #9
    Senior Member EricLang's Avatar
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,016
    @Videoripper: been there too. still am...
    Groot nadeel van designtime is alles published, vind ik.
    Strict private en private vind ik wel handig eigenlijk. Soms "lees" ik in dezelfde unit wel privates uit van een andere klasse.
    Omdat ze inderdaad meestal verstrengeld zijn.

  10. #10
    Quote Originally Posted by jkuiper View Post
    Delphi Code:
    1. MyFoo.fFoo1 := 'hallo';  // <---- dit mag
    Maar dat werkt dus (nogmaals) alleen als je al binnen dezelfde unit zit. Iemand die een DCU van jou krijgt kan dus niet zomaar een stuk code toevoegen of een afgeleide maken die bij die private kan.
    1+1=b

  11. #11
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    9,652
    Quote Originally Posted by luigi View Post
    Hallo hallo,

    Waarom zou je nog private gebruiken in plaats van strict private? De enige redenen die ik kan bedenken zijn:

    1) De klasse moet ook werken in Delphi 7 of lager

    2) Je levert geen sourcecode en wilt "voorkomen" dat er afgeleide van je class worden gemaakt.
    3) Het is 6 letters meer, incompatible met een hoop versies en het nut is zwaar overschat. Eigenlijk is het alleen nuttig voor een paar component boeren die per se toegang willen ontzeggen. (scheelt weer support)

  12. #12
    Begrijp eerlijk gezegd nog steeds niet waarom je niet standaard strict private zou gebruiken en voor de uitzonderingen private. Op het moment dat je strict private naar private moet veranderen dan kun je het ontwerp misschien nog even onder de loep nemen en je afvragen of het gewenst is.

    Het is 6 letters meer, incompatible met een hoop versies en het nut is zwaar overschat.
    Volgens mij wordt het na D7 ondersteund en wil je ivm unicode toch geen applicaties meer schrijven die in zowel D7 als in Tokyo werken, maar misschien zit ik hier verkeerd. Het is nu ook niet zo dat ik strict zo ontzettend belangrijk is, maar ik zie wel het voordeel van het gebruik.

  13. #13
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    9,652
    Afaik D2006, maar ja, de D7ers zijn het probleem. Maar het punt is, het nut is er eigenlijk niet, dus waarom de moeite hoe triviaal dan ook? De IDE zet geloof ik ook nog steeds private (b.v. property completion)

    De strict* modifiers zijn gewoon voor de meeste gebruikers onzin, behalve voor componenten boeren, wie het een paar vragen scheelt voor de gebruikers die met hack trucken toch access krijgen als ze een intern veld veranderen/verwijderen e.d.

    Maar goed dat soort gebruikers zijn per definitie hopeloos .

    Mocht het echt een probleem zijn, is het een met een sed script in 2 minuten gepiept als je private maar apart op een regel zet.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •