Java a atribúty (prečo súkromné?) – Java – Fórum – Programujte.com

Zdravím,

učím sa programovať v jave, mám kúpenú knihu od Rudolfa Pecinovského Myslíme objektově v jazyku java 2. akt. vydanie.

V knihe píše, že atribúty sa väčšinou používajú ako súkromné (private) aby nikto iný nemal ku nim prístup, ale nikde sa nepíše prečo. A preto vyplíva moja otázka čo sa stane alebo môže stať keby ich nedám private ale public? pokiaľ ja niečo nenaprogramujem použivateľ to nemá ako použiť keď mu nedám možnosť tým, že mu naprogramujem s public atribútom príkaz nie? Alebo to niekto môže zistiť a naprogramovať vďaka tomu nejaký crack programu, ktorý potom dokáže robiť s týmito atribútmi veci? Ospravedlňujem sa za možno hlúpu otázku ale iba sa to učím a fakt to neviem :D 

#1 filip212
Atributy objektu se dávají private, aby k nim zvenku nneměl nikdo přístup. Říká se tomu zapouzdření. Všechno, co je public, je součástí rozhraní. Je žádoucí, aby toto rozhraní bylo co nejjednodušší. Zjednoduší se tím komunikace mezi objekty, zjednoduší se dokumentace a aplikace se i zrychlí.

#2 Kit
Ahoj ďakujem za odpoveď, ale celkom aj tak tomu nerozumiem keby to dám public ako k tomu uživateľ z vonku čo si zapne aplikáciu a nemá tam žiadne tlačítko alebo mnou naprogramovanú možnosť niečo robiť s tým atribútom tak ako k nemu získa prístup a niečo zmení? Troška viac do hĺbky ak by si mi to vedel vysvetliť aby som tomu úplne pochopil ako to funguje budem ti vďačný.

 Když to nedáš public tak uživatel k tomu může mít přístup za pomocí getter/setter.

class Trida {
	private int hodnota;
	public int getterHodnota()  { 
		return this.hodnota; }
	public void setterHodnota(int cislo) {
		this.hodnota = cislo;	}
{

Navíc když se naučíš toto zapouzdření(dle Herouta autorizovaný přístup k datům ) úspěšně jsi zvládl první pilíř OOP.

existují 4 modifikátory přístupu :

* private

* protected

* bez označení

* public

Pozn1.  zapouzdření má zabránit chybám vzniklých ze snadného přístupu k vlastnostem objektu

Pozn2. U malých programů,(100-200-300 řádků)je zbytečné mít OOP vč. zapouzdření. Ale u větších kde se pracuje v teamu je vhodné zapouzdření používat aby někdo jiný kdo bude pracovat objektem(instancí) z třídy kterou naprogramuješ nemohl snadno měnit stav a vlastnosti. Pokud jej mění přes setter pak to nemění neúmyslně ale úmyslně a to už není tvoje chyba.

#4 NotBeginner
Když už, tak getHodnota() a setHodnota().

Nevýhodou getterú/setterů je, že zbytečně rozšiřují rozhraní. Jak jsem již psal, důsledkem je horší dokumentace i rychlost.

Proto je lepší, když gettery/settery jsou také private.

Jak jiz ostatni zminili, jedna se o zapouzdreni. Vyznam tohoto principu neni zjevny u malych programu, protoze trid a objektu, ktere mezi sebou komunikuji je minimum.

Zkusim uvest priklad:

Objekt A ma public atributy, prijde objekt B a zacne vyuzivat funkcionalitu A, pak prijde objekt C a zatimco B vyuziva A tak C zmeni atributy A protoze k nim ma public pristup. Pak treba jeste prijde D, E, F (+ zbytek cinske abecedy) a zacnou stourat do A stejnym zpusobem. B z toho bude mit hlavu jak balon, protoze chovani A bude pokazde jine.

Kazdy objekt by mel mit jasne definovane rozhrani a ucel. Co neni nutne vystavovat navenek to se skryva. Pak kdyz nekdo prijde a chce takovy objekt vyuzit, tak nemusi dlouze premyslet nad vsemi vedlejsimi efekty a situacemi, ktere mohou nastat.

#5 Kit
Proto je lepší, když gettery/settery jsou také private.

Jenže toto jaksi už není konvenční způsob zapouzdření. Mimochodem např. v knihách o Javě vč. OOP např. Deitel(ISBN-13: 978-0-13-380780-6), for Dummies(ISBN 978-1-118-26201-6 (ebk)), od Oracle(ISBN: 978-0-07-180926-9),apod.. se to vůbec nevyskytuje. 

#5 Kit
Ahoj, ja to nechapu. Ja myslel, ze filozofie getru asetru je prave dana tim, ze jsou public. K cemu by mi pak byly?? Pouzivat je uvnitr tridy je zbytecny......

Kdyz by byly private, jak k nim teda pristupovat?

Ahá už mi troška začína svietiť takže vlastne ide o ostatních programátorov čo by sa mohli dostať k zdrojovému kódu a niečo meniť alebo pridávať aby sa v tom zbytočne nezamotali a omylom neurobili s atribútom niečo iné ako chceli ale na koncového uživateľa, ktorý si iba spustí program cez jar súbor alebo nainštaluje cez vytvorenú inštalačku to nemá vpliv a on s tým nemôže spraviť nič chápem to správne?

//EDIT prípadne keď viac objektov pracuje s danou triedou a aby som sa aj aj pri väčšom projekte nesekol a nezmenil omylom atribútu hodnotu

#8 brucak
Nijak. Nikdo nemá právo ani důvod sahat na privátní atributy objektů. A to ani prostřednictvím getterů nebo setterů. Nepoužívám je a nechybí mi.

#10 Kit

Ty ještě žiješ? Po tom co ti udělal David Čápka. Já jsem z IT Network přešel na http://svobodneforum.tk/ .

Můžeš zkusit také jsou tam lidé z IT Networku, kteří nesnášejí Davida :D .

#11 Fanda Kita
Proč bych neměl žít? A co mi udělal Čápka? Stejně bych odešel, protože se začal chovat jako fašista.

#6 Petr
toto urcite nieje cielom kvoli ktoremu sa davaju fieldy ako private ... chovanie ktore si popisal je chovanie immutable objektu (ktory je sice velmi vyhodny ale implementacia je potom znacne narocna) ... normalne objekty sa menia v case

ak je field private potom sa ti vsetko zjednodusi ak by si ten field nahodou chcel odstranit alebo rozsirit ... ak by si mal objekt okno a v nom field material (povedzme ze typu String) a bol by public potom by vsetci uzivatelia pristupovali k typu materialu cez tento field a ocakavaju ze dostanu String ... lenze komunizmus sa skonci a okna sa zrazu zacnu vyrabat z dvoch materialov ... vsetci tvoji uzivatelia su strateny pretoze cakaju ze tvoje okno ma len jeden material ... keby si to mal aspon trochu zapuzdrene a neposkytoval priamo field material (mal by si getter cez ktory sa da dostat k materialu) potom si mozes ten field s materialom dat ako List<String> ... tym padom budes mat realne zachytene ze sa dane okno vyraba z viacerych materialov ... a aby aj ty komunisticky uzivatelia zostali spokojny tak im budes posielat len prvy material zo zoznamu

dalsi problem s fieldami je ze ich nedokazes dat ako povinnu vlastnost do interface cize mutacie daneho objektu su znacne problematicke

preto tu mame teoriu zvanu OOP ... keby si mal objekt okno tak jeho uzivatelov v skutocnosti vobec nezaujima z akeho materialu je vyrobene ... v skutocnosti ich zaujima ake ma izolacne vlastnosti ... kolko svetla prepusti ... to su realne vlastnosti okna a tieto by si mal poskytovat okoliu (samozrejme ak dane okno predavas tak ta bude zaujimat aj material - v tom pripade je to validna vlastnost a je vhodne pouzit 'getter' ako ho pozname)

cize v jave:

public interface Okno {
	double priepustnostSvetla();
	Object tepelnoIzolacneVlastnosti();
}
public interface StavebnyMaterial {
	String narocnostNaInstalaciu();
	double vaha();
}
public interface Tovar {
	BigDecimal hodnota();
	String material();
}
public class MojeOkno implements Okno, StavebnyMaterial, Tovar {
...
}

samozrejme tie vystupne hodnoty neber doslovne urcite sa daju vymysliet aj lepsie

vyhoda interface je ze zachytava len nevyhnutne poziadavky ... implementacia sa potom moze jednoducho zmenit bez ovplivnenia zakaznika

#13 Flowy
Vďaka bohu za teba konečne chápem načo to je dobré a čo sa deje, keď to dám ako public :)

#14 filip212
Neber si však příklad z těch interface - má popisovat vlastnosti rozhraní.

#15 Kit
Áno to mi je jasné :) Ale ďakujem chlapi konečne to chápem :)