Forum PHP.pl

Ale taki obiekt który ma tylko dane + gettery i settery jest jak lodówka która nie mrozi albo auto które nie jeździ. Niewiele różni się od tablicy albo zbioru luźnych zmiennych.

Zależy czym ma być ten obiekt.Tu są dwie strony medalu:

1. Getery i setery są konwencją która pozwala na pewnego rodzaju "rozpoznawalny" interfejs dostępu do danych obiektu. Dzięki czemu łatwiej zaprzęgnąć do pracy zewnętrzną bibliotekę tak aby współdziałała z twoimi obiektami. Np chcesz wprowadzić zapis obiektów do bazy danych. Zamiast pisać własny kod który to obsługuje korzystasz z Doctrine2. Albo chcesz przeprowadzać inicjalizację przez kontener IoC. Jakikolwiek nie był by to mechanizm musi jakoś obsługiwać twoje obiekty, zrobi to dzięki getterom i setterom które umieścisz w swoim obiekcie. (To nie musi być zewnętrzny system to moze byc system który sam chcesz napisac) I to jest dobre prawidłowe wykorzystanie get i set.

2. Getery i setery mogą też stać się 'protezami' dla programisty który nie potrafi zaplanować dobrze kodu i zamiast prosić obiekt aby ten coś dla niego wykonał co chwile używa get i set aby cos z obiektu wyciągnąć albo cos do niego wrzucic.

Czyli zamiast

[PHP] pobierz, plaintext 
$kucharz = new Kucharz(array($skladnik, $skladnik)) 
$pizza = $kucharz->robPizze('Roma')
[PHP] pobierz, plaintext 

piszesz

[PHP] pobierz, plaintext 
 
$pizza = new Pizza();
$pizza->setSkladnik1($skladnik);
$pizza->setSkladnik2($skladnik);
$kucharz = new Kucharz()
$kucharz->setPizzaName('Roma')
$kucharz->setPizza($pizza);
$pizza = $kucharz->getPizza($pizza);
[PHP] pobierz, plaintext 

I to jest złe stosowanie get i set. Jezeli wprowadzasz get i set do swojego systemu nie wiedząc DOKLADNIE do czego jest ci to potrzebne to już zrobiłeś błąd.

Im mniejsze czyli bardziej rozdrobnione obiekty tym lepszy system. Z drugiej strony jeżeli ma to być prosty system to nie ma sensu sztucznie go komplikować, tak że możesz rejestracje i logowanie zrobić w jednym obiekcie, tylko niech to nie będzie ten sam obiekt który reprezentuje użytkownika. Może 'UserAuthorisation'?



Tak ale nazwa tego obiektu nie mówi o tym co obiekt robi.



Charakter jest biznesowy. A CharacterManager to obiekt, który powinien zostać podzielony na tyle obiektów ile widzisz 'problemów' do rozwiązania z wiązanych z obiektem Character. Każdy nowy kontekst wprowadza nowe obiekty.

Jeżeli chodzi o sam obiekt Character. Nawrzucałeś do niego różnych zmiennych które ci przyszły do głowy a które nie mają jakiegokolwiek uzasadnienia. Obiekt Character to nie jest prawdziwy obiekt w rozumieniu OOP. Od tablicy różni go tylko forma zapisu.

Przykładowo $_speed. Czym jest speed? Prędkość z którą porusza się byt w danym momencie czy maksymalna prędkość z którą może się poruszać? Prędkość to jest coś względnego. Względem czego liczysz prędkość? Jeżeli nie masz tego czegoś to może i sama speed powinna na razie zniknąć? Może prędkość nie powinna być zmienną tylko wynikać z relacji obiektów, tak jak w świecie rzeczywistym?

Chodzi mi o to ze program mozna koncepcyjnie podzielić na:

- Cześć APLIKACYJNA, która jest "wspólna" dla większości systemów www. Do tego wchodzi np. autoryzacja. (twoje logowanie) obsługa sesji, jakaś implementacja MVC (lub prostszy mechanizm zamiast MVC). Routingu.

Tej części nie wymyślaj od nowa użyj jakiegoś frameworku.

- Część BIZNESOWĄ która jest unikalna dla danego systemu. Jeżeli piszesz system do obsługi pizzerii to to będą obiekty Kucharz, Klient, Pizza, Składnik, Pizzy, Kelner, etc. (z palca pisze).

Skup się na tej części biznesowej a pierwszą znajdziesz w gotowych rozwiązaniach. Obie warstwy powinny zajmować się różnymi rzeczami. To znaczy obiekt Kucharz nie powinien implementować logowania ani zapisu danych dobazy, nawet jeżeli koncepcyjnie użytkownik będący kucharzem może się logować.

Obiekt Kucharz może za to przyjmować w konstruktorze obiekty Składaniki Pizzy oraz posiadać metodę makePizza() która zwraca Pizze.

Poćwicz sobie tworzenie systemów składających się z małych obiektów które rozwiązują tego typu problemy.

Bez tej umiejętności będziesz jak papuga która klepie bezmyślnie kod według koncepcji wymyślonych przez innych, których to koncepcji nawet nie rozumie, ale sam nie będziesz potrafił zaprojektować nawet prostego systemu...

To czy jakiś obiekt ma sens, czyli czy powinien istnieć czy nie, nie wynika bezpośrednio z tego że program jest OOP tylko z dziedziny problemu który program rozwiązuje. Ale jeżeli hurtowo nazywasz swoje obiekty "manager" to coś może być nie tak. Zbyt ogólna nazwa sugeruje że obiekt robi zbyt wiele rzeczy lub że sam nie wiesz co ma robić.



Moja propozycja: Olej całkowicie logowanie. Skup się na problemie który twój program ma rozwiązywać.



Staramy się wstrzykiwać obiekty w inne obiekty a nie inicjalizować jedne w drugich. Oczywiście inicjalizacja musi gdzieś nastąpić. Także to że przekazujesz usera do innego obiektu jest ok, pytanie tyko czy wiesz do czego ma słuzyc manager?

Przy każdym pobraniu z serwera strony przez użytkownika, który zainicjalizował wcześniej sesję i teraz wysyła jej identyfikator. Request = żądanie obsługi poprzez HTTP.

Osobiście nie używam sfguard, to jest zbyt prosty system i nie nadaje się do bardziej zaawansowanych zastosowań w firmie mamy własny plugin także oparty o rbac ale z dodatkowymi ograniczeniami dostępu, cachowaniem, dostępem z panelu itd.

Myślę że w którejś z ebookow na http://www.symfony-project.org/doc/1_4/ na bank znajdziesz przyklady użycia sfguard + dokumentacja samego pluginu. Twoje pytania są zbyt obszerne aby sensownie na nie odpowiedzieć.

Jak mówił tata wielbłąd do małego wielbłądka, pracuj, pracuj a garb ci sam wyrośnie...

Nie potrzebujesz dużego pojęcia na temat programowania obiektowego aby zacząć programować w jakimkolwiek frameworku o ile ma on dobrą dokumentację a symfony ją ma.

Inicjalizujesz sesję ale nie ustawiasz niczego pod identyfikatorem 'mySession'. Brakue Ci czegoś jak:

[PHP] pobierz, plaintext 
$_SESSION['mySession'] = 'cokolwiek';
[PHP] pobierz, plaintext 

To chyba nie jest dział na tego typu pytania...

Twój identyfikator musi składac się z 2 części które skonkatanujesz (złączysz) w jedno.
A wzór jest taki:

identyfikator = część unikalna + szum

Implementacja:

identyfikator = primary_key + md5( salt + primary_key )

gdzie:
salt = ciąg znaków (tajny) pobierany np. z pliku konfiguracyjnego systemu.
primary_key = autkoinkrementowany klucz (najlepiej primary key) tworzony automatycznie przez bazę podczas dodawania nowego rekordu
+ = znak konkatanacji

Wynika z tego że potrzebujesz 2 pingów do bazy jeden żeby stworzyć rekord i uzyskać nowy id (primary key)
drugi żey zpisac do bazy utworzyony identyfikator.

Można by to uprościc i primary_key zamienić na microtime(). Wtedy jednak bezpieczeństwo systemu wiążemy z zegarem systemowym.

Ale wszystko to teoria... Jeżeli strona jest dostępna publicznie to tego typu zabezpieczenie nie jest żadnym zabezpieczeniem. Jeżeli chcesz mieć zabezpieczone zasoby to dostęp musi być po zalogowaniu, dla konkretnych użytkowników.

Metoda unset() poszukaj w manualu phpa. Tylko dlaczego miałbyś usuwać indeksy tablicy? Wybierz to co cie interesuje a pustymi indeksami się nie przejmuj.

1. W javascript nie ma czegos takiego jak klasa. To co w swoim programie nazywasz klasą, jest funkcją (która jest także obiektem). A co do zasłoniętej metody, proponuje przerobic kod na taką modłę:

[PHP] pobierz, plaintext 
<?php
var Pane = function(){ // <---Przy tym zapisie widac wyraznie, ze Pane to nie zadna klasa a obiekt :)
    this.costam = 'xxx';
    this.ooo = 'ababa';
    this.close = function(){
        alert('zamykam' + this.costam)
    }
    
    
};
 
var PaneLog = function(){
    //Po odkomentowniu zmienna o wartości yyy 'wyjdzie na wierzch' 
    //this.costam = 'yyy';
    this.close = function(){
        alert('closing' + this.costam)
 
    }
}
 
 
var myPane = new Pane();
myPane.close();
 
//wskaźnik this z obiektu PaneLog będzie od tego momentu wskazywac na obiekt Pane
PaneLog.prototype = new Pane();
 
var myPaneLog = new PaneLog();
myPaneLog.close();
?>
[PHP] pobierz, plaintext 

2. Co do drugiego błędu, zgaduje że w danym momencie pod zmienną this.jquery nie ma wartości która odnosiła by sie do obiektu
jQuery. Tak jak w przykładzie poniżej. W wiekszości przypadków używasz this.jquery do budowy selectora tak więc nigdy nie wygeneruje to błędów (co najwyżej elementy drzewa DOM nie zostaną znalezione).

[PHP] pobierz, plaintext 
<?php
$(document).ready(function(){
    var smiec = 'bzdury';          // <-- łancuch znaków
    var element = $('#usmiech2'); // <-- obiekt jQuery
    
    element.remove();
    smiec.remove();
});
?>
[PHP] pobierz, plaintext 

Fakt że this.jquery jest zmienną obiektu wydaje mi się złym rozwiązaniem. Obiekt powinien zawierać to co jest jego częścią składową this.jquery jest tu 'ciałem obcym'

Musisz myśleć bardziej globalnie.
Programuj swoje obiekty tak jak by cała warstwa wizualna wogóle nie istniała zajmuj się nią na samym końcu. Np metoda do usunięcia czegos:

[PHP] pobierz, plaintext 
<?php
... //jestsmy w obiekcie    
    this.id; //Parametr id identyfikuje nam obiekt. 
    this.close = function(){
        //Tutaj kod który usunie element + jakieś inne działania na innych obiektach z tym zwiazane
 
            ....
 
        //Wyrzucamy nasz element z drzewa DOM (przestaje byc widoczny)
        $('#' + this.id).remove();
 
... //i dalej nastepne metody obiektu
    }
?>
[PHP] pobierz, plaintext 

Parametr this.id to praktycznie wszystko co jest potrzebne aby odnaleźć interesujący nas węzeł drzewa DOM i zmienić wygląd strony. Mając go możemy użyc jQuery czy innej biblioteki. aby zmienić ten fragment strony, który przedstawia nasz obiekt .