Delphi - viditelnosť vlastností

http://info.borland.com/techpubs/delphi/delphi5/opl g/classes.html

You can increase the visibility of a member in a descendant class by redeclaring it, but you cannot decrease its visibility. For example, a protected property can be made public in a descendant, but not private. Moreover, published members cannot become public in a descendant class. For more information, see "Property overrides and redeclarations".

P.S. ale nepytaj sa ma preco to tak je

Dík za info

Inac ja v delphi nerobim, mne sa zda normalnejsie C++, tam su tusim 3typy dedenia a myslim ze rozumne zadefinovane:
You can derive classes using any of the three access specifiers:
* In a public base class, public and protected members of the base class remain public and protected members of the derived class.
* In a protected base class, public and protected members of the base class are protected members of the derived class.
* In a private base class, public and protected members of the base class become private members of the derived class.

P.S. Sa mi aj zda ze v delphi sa aj nejako miesa "visibility" s "accessibility", co su pre mna (C++ zalozeneho) dve totalne odlisne veci. No ale kazdemu podla jeho chuti...

Nielen Delphi má ten problém teraz som ten istý kód skúsil v C# a funguje to tam úplne rovnako(nelogicky) ako v Delfách, a predpokladám že to bude rovnaké aj v Jave.

	public class Class1 
	{
		private string attrib1;
		protected string Property1 {
			get {
				return attrib1;
			}
			set {
				attrib1 = value;
			}
		}
	}
	
	public class Class2: Class1
	{
		public string Property1 {
			get {
				return base.Property1;
			}
			set {
				base.Property1 = value;
			}
		}
	}

	public class Class3: Class2
	{
		protected string Property1 {
			get {
				return base.Property1;
			}
			set {
				base.Property1 = value;
			}
		}
	}
...
	Class3 object1 = new Class3();
	object1.Property1 = "Test";
	MessageBox.Show(object1.Property1);

Inak v Delphi funguje zapúzdrenie naozaj zvláštne napr. z triedy "A" sa dá pristupovať do private a protected časti triedy "B" ak sú umiestnené v tej istej unite atd. Niečo ako spriatelené triedy v C++. Ešte že do Delphi pre .NET už pribudali aj špecifikátory strict private a strict protected.

Ale mozes zadefinovat Class2 ako protected class, nie ako public class, potom sa nebudu dedit public ako public ale ako protected (ani nebudes musiet nic predefinovavat)... Aspon teda myslim, nepoznam dobre C#

P.S. to by ale ovplyvnilo aj ze kto moze vytvarat objekty tej triedy, takze to nie je take easy
P.S.2. aha, takze sa to v C# neda tak ako pisem, class moze byt len public alebo internal. Tak nic

P.S.3. inac to predefinovavanie co robis sa mi vobec nepaci. Vseobecne by sa to malo chapat tak, ze zdedena trieda sucasne je aj rodicovska trieda (zdedena obsahuje rodicovsku), takze ak nemozes dedit roznymi sposobmi ako v C++, tak to ostane uz public v kazdej zdedenej, dokonca nie som si isty ci nepristupujes zvonku na ten member v Class2, kedze v Class3 je protected (otazne keby to v Class3 nebolo zadefinovane ako to iste ako v Class2, ale malo by to len rovnake nazvy memberu, ze co by sa vlastne tym menilo, ci base class member alebo Class3 member ...). Povazujem to co robis za zdroj problemov alebo chaosu, radsej by som trochu inac navrhol objektovy model... alebo ako chces, ak ti program funguje tak ako to mas, tak ok

V Delpi je o trochu jinak. Pokud by ty tridy nebyly definovany v jedne unite, fungovalo by to tak, jak si to predstavujes. Pokud je deklarace trid v jedne unite, pak jednotlive tridy mohou pristupovat i ke svym private vlastnostem. Je to chyba, ktera se tahne jiz od zacatku VCL.

Je dokonce mozne "snizit" viditelnost tim, ze to presunes z public do protected nebo private. Bude to chodit, jen prekladac bude varovat. Ciste reseni by se delalo pomoci tzv. CustomClass - staci se podivat do zdroju VCL, jak jsou resene kompnenty - napr. TEdit vs TCustomEdit.