uzycie typu czy klasy - co lepsze?

hi,
jestem poczatkujacym jesli chodzi o OOP, i mam pytanie odnosnie delphi.

powiedzmy, ze potrzebuje stowrzyc 'cos' co przechowa mi imie i nazwisko pracownika.

czy lepiej tworzyc wlasny typ np

type
   TPracownik = array[0..1] of string 

i przypisywac imie i nazwisko

czy moze rekord:

type
  TMyRecord = record
    X : Integer;
    Y : Integer;
  end;

a moze ostatecznie zbudowac klase?

type
   Tnowaklasa = class
      FImie: String;
      Fnazwisko: String 

itp

?
jak najlepiej ?

pozdrawiam

Jak na tak prostą małą liczbę informacji to najlepiej było by skorzystać z rekordu, bo po co Ci babrać się w tworzenie i usuwanie obiektów, dodawanie metod itd., skoro masz przechować tylko dwa łańcuchy?

Jeżeli chcesz to możesz cały mechanizm obsługujący pracowników opakować w klasę (i to będzie zalecane), dodać jej metody odpowiedzialne za dodawanie/usuwanie pracowników (ogólnie metody służące do modyfikowania i obsługi zawartości listy pracowników);

jak najlepiej ?

To zależy...

TPracownik = array[0..1] of string

0 to imie czy nazwisko? Genialny pomysł.. A teraz dodaj płacę.

a moze ostatecznie zbudowac klase?

Gdyby Ci chodziło o implementacje TImieINazwisko to REKORD (bo nie jestem sobie w stanie wyobrazić ciekawszych metod do tego).
Jeżeli TPracownik to KLASA (bo można do tego nowe pola łatwo dodać [będą inicjalizowane], nowe metody itd. itd.).
Jeżeli twój typ ma służyć jedynie do grupowania danych/zapisu to użyj rekordu. Inna nazwa dla klasy to w wielu językach 'obiekt' więc jeżeli coś możesz zdefiniować jako obiekt w rozumieniu generalnym to definiuj jako klasa. Chodzi o to żeby w przypadku klasy można było łatwo stwierdzić co ona może a czego nie powinna móc (np. Tsamochod może zapalić silnik, ale nie może się zatankować [TStacjaBenzynowa może Zatankuj na TSamochod]).
No i generalnie musisz się też trochę wyrobić żeby wiedzieć kiedy warto robić klasę a kiedy nie i jak ją definiować żeby było git...

Póki jest mało informacji, osobiście preferowałbym rekord (łatwo do odczytu, od razu widać konkretne pole).
Potem klasy lub advanced record (w zależności jak bardzo chcesz się z tym "babrać" i jak bardzo ma być to zaawansowane).

jesli chcesz w prosty sposob zapisywac te dane do pliku to powinienes uzyc rekordu, a stringi w srodku powinny miec ograniczona dlugosc. Jesli planujesz trzymac stringi bez ograniczen dlugosci (tak jak masz teraz) to praktycznie nie masz zadnego profitu z trzymania tych danych jako struktury i sugerowalbym Ci zmiane tego na klase, ktora nie bedzie miala zadnych publicznych pol (publiczne tylko metody/wlasciwosci).

ATSWD. Uwazam ze nauka OOP w Delphi jest najgorsza z mozliwych drog. Wg. mnie jesli juz dobrze ogarniasz skladnie Delphi to to jest dobry moment na nauke C++. Jak ogarniesz klasy w C++ to przesiadz sie z powrotem na delphi lub na C#. W Delphi i C# (w Javie i paru innych jezykach chyba tez) na pierwszy rzut oka nie widac co jest value type a co reference type i bedziesz mial przez to niezly metlik w glowie - w C++ widac co sie dzieje po pierwszym spojrzeniu i potem wyniosiona z C++ wiedze umialbys wykorzystac w innym, bardziej przyjaznym dla programisty jezyku.

no wlasnie c++ to unikam jak ognia bo nie jest zbyt przyjazne.

Generalnie nie jestem programista, ale czasem cos tworze przydatnego dla siebie.

rozumiem ze klasy maja metody itp itd i to jest fajne, ale jesli chce stworzyc powiedzmy typ rekordowy imie i nazwisko to wlasnie tak chyba najprosciej, bo unikam
tworzenia i zwalniania obiektow.

w tym przypadku

tworze sobie klase TListaPracownikow ( stringlista z imieniem i nazwiskiem)
jednak latwo mozna wypelnic taka stringlsite wlasnie rekordem Trekord.imie i trekord.nazwisko.

wiec tak chyba zrobie.

stringlista z imieniem i nazwiskiem)

Nie lepiej jest dane przechowywać w czymś w stylu:

var Lista: List<TypJakistam>;

O ile mi wiadomo, Delphi posiada takie coś (nie pamiętam tylko czy na pewno to się tak nazywało).

Patryk27 napisał(a):

stringlista z imieniem i nazwiskiem)

Nie lepiej jest dane przechowywać w czymś w stylu:

var Lista: List<TypJakistam>;

O ile mi wiadomo, Delphi posiada takie coś (nie pamiętam tylko czy na pewno to się tak nazywało).

Enumeratory wprowadzili bodajze w delphi 2005, a ja dzialam na delphi 7.

Ok to może przybliżę Wam moi drodzy mój problem.

Mam bazę danych i powiedzmy tabele pracownicy o polach: NrID, Imie, Nazwisko, Adres, NIP, PESEL itp

do łączenia sięz bazą używam ZeosLib(darmowy i fajny), to co mi zwraca biblioteka podłączam do StringGrida i w tabelce otrzymuje wykaz pracowników.
Do tego momentu wszystko jasne.

Wpadłem na genialny pomysł napisania kontrolki, która będzie zawierała listę pracowników(nazwisko i imie) i po wpisaniu powiedzmy 'Kow' kontrolka wyświetli listę pomocniczą z pracownikami, których nazwisko zaczyna się na 'Kow'.
Na tą chwilę brak mi wiedzy jak to zrobić, więc oparłem się na comboboxie i tam poleceniem (przykład z głowy): SELECT Imie, nazwisko FROM Pracownicy pobieram dane podstawowe.

Tutaj przydałby się rekord TImieNazwisko i dane by tu wpadały.

Do tego zrobiłem sobie klasę TlistaPacjentow i ona nie zawiera wszystkie dane pacjentów, lecz tylko Imie i nazwisko.
Klasa ma w sobie StringListe i ją przypisuje do ComboBoxa - otrzymuję w ten sposób comboboxa z listą pracowników i mogę filtrować tabelkę z danymi pracowników.

Trochę już zagmatwałem co? :)

I teraz pytanie:
Jak takie rzeczy robić profesjonalnie?

Napisać całą klasę TPracownicy i tam trzymać listę pracowników całą z wszystkimi danymi i listę skróconą(imię, nazwisko), czy osobna klasa.
generalnie chodzi o to, że muszę potworzyć 'jakieś fajne rzeczy', które będą mi trzymały dane, które będe mógł wykorzystać.
Bo na razie StringGrid wyświetla dane, ale nie mam nad nimi kontroli(jako takiej).

pozdrawiam

jakieś pomysły?

Zleć takie zadanie profesjonaliście.

Jak takie rzeczy robić profesjonalnie?

Profesjonalnie to prawdopodobnie byłoby dobrze wykorzystać ORMa (http://en.wikipedia.org/wiki/Object-relational_mapping), dzięki czemu operowałbyś na bazie danych tak, jak na obiektach.

Do małego projektu, jeżeli nie chcesz uczyć się nowych technologii, najlepiej będzie jak napiszesz sobie tą klasę TPracownik (raczej liczbą pojedynczą nazywamy klasy). Raz napiszesz i będziesz miał spokój, będziesz korzystał sobie z pól jakich chcesz, zależnie od potrzeby w danej chwili.

Jeżeli jednak tabelek do odwzorowania jest więcej niż 2, to już bym się zainteresowała ORMem ;)

ok,
czyli oprocz podpiecia danych do dbgrid, zrobic przypisanie danych do wlasnych obiektow?

a moze raz przypisac do wlasnych obiektow dane, a potem przejechac po nich i powpisywac do petla do stringgrida?

a moze raz przypisac do wlasnych obiektow dane, a potem przejechac po nich i powpisywac do petla do stringgrida?

Lepiej.

A ja to bym zrobiła tak:

1. Stworzyć strukturę danych TPracownik, która w konstruktorze przyjmuje ID pracownika. Na podstawie ID, konstruktor wypełnia obiekt danymi pobranymi z bazy.
2. Każdy atrybut powinien posiadać setter, który poza przypisaniem wartości wykona update na bazie danych.

Następnie w programie potrzebujesz tylko pobrać id pracowników, pętelką lecąc po tych id tworzysz pracowników. Następnie to sobie wyświetlasz już gdzie tylko chcesz, operując po prostu na obiektach...

Ale czy to wydajne? Chyba nie bardzo. Na mały projekt ok, ale tak jak pisałam, przy jakiejkolwiek rozbudowie poczytałabym o ORM.

wydajne to jest wlasnie samo wyswietlanie polaczone dbgrid z zquery i wszystko w locie.

jednak zeby operowac juz na danych samych to trzeba sie pomeczyc.

aha a jeszcze jest kwestia zmian w tabeli, np dopisanie kolumny.
Z automatu zquery dopasuje wyglad tabeli do nowych danych i zobaczymy wszystko co trzeba.
Z obiektami wiazaloby sie dopisywanie nowego pola i wypelnienie go...