Maciek pisze:

> Właściwie nie widziałem jeszcze projektu w Builderze, czy Delphi (ale
> nie mówię, że widziałem ich jakoś bardzo dużo), który nie opierałby się
> na formie/formach i całej logice wciśniętej w zdarzenia, w najprostszy
> możliwy sposób. Wynika to chyba ze specyfiki tych środowisk - użytkownik
> właściwie jest zachęcany do tego typu programowania.

Tak jak i w VS, NetBeans itp... Jednak to, że coś daje jakąś możliwość,
nie znaczy że trzeba z niej korzystać. Uwierz mi, bo się w tym
środowisku obracam, że niektóre projekty wprawiłyby Cię w osłupienie
odnośnie sposobu ich wykonania.
Nie ma żadnych przeszkód żeby tworzyć aplikacje w oparciu o wzorce
projektowe. A tak naprawdę to projektu o których piszesz dobre są na
początek. Prędzej czy później każdy dojdzie do momentu gdy to nie
wystarcza. I tu się pojawiają rozwiązania odchodzące od EDP, jednak
dające szybką możliwość skorzystania z niej.
Wydaje mi się, że projekty które widziałeś były albo bardzo marne, albo
pisane przez "studentów" za kiść bananów.

Ale niestety, taka "sława" ciągnie się za środowiskami wizualnymi...

pozdrawiam,
Przemek O.

--
www.soft-system.pl

do góry

Przemyslaw Osmanski pisze:
> Maciek pisze:
>
>> Właściwie nie widziałem jeszcze projektu w Builderze, czy Delphi (ale
>> nie mówię, że widziałem ich jakoś bardzo dużo), który nie opierałby się
>> na formie/formach i całej logice wciśniętej w zdarzenia, w najprostszy
>> możliwy sposób. Wynika to chyba ze specyfiki tych środowisk - użytkownik
>> właściwie jest zachęcany do tego typu programowania.
>
> Tak jak i w VS, NetBeans itp...
Builder (Delhi) jest zdecydowanie najłatwiejszym, więc najlatwiej bez
uczenia sie cos robić, najwyżej pytając na forum.
Powiem Ci, że na klikalnym inspektorze w NB potrafię się spocić ;)
VS nie wiem do którego języka się odnosisz.


> Nie ma żadnych przeszkód żeby tworzyć aplikacje w oparciu o wzorce
> projektowe.

> Ale niestety, taka "sława" ciągnie się za środowiskami wizualnymi...

I ludzie się ciągną, panie, ludzie...

potem jeden drugiego pyta (na żywo czy na forach). Osobiście wierzę w
tzw. 'wspólnotę języka programowania" gdzie nastepuje przekaz
'międzypokoleniowy'.

Powiedziałbym filozoficznie: MY WIERZĄCY że da się i nalezy dobrze
projektować w BCB nalezymy do mniejszości, (oby nie wymierającej).

do góry

On 19 Lut, 16:13, Jacek Czerwinski <x...@...z.pl> wrote:
> Przemyslaw Osmanski pisze:> Maciek pisze:

> Powiedziałbym filozoficznie: MY WIERZĄCY że da się i nalezy dobrze
> projektować w BCB nalezymy do mniejszości, (oby nie wymierającej).

Oczywiscie ze sie da, nie trzeba w to wierzyc, mozna sprawdzic.
Wystarczy oddzielic logike aplikacji od czesci "builderowej".
Wystarczy
porzadnie zaprojektowac logike, na zewnatrz wystawic elastyczny
interfejs,a
nastepnie mozna owa logike podpinac pod dowolne gui, w dowolnym
srodowisku, a nawet w dowolnym jezyku programowania.

Tyle ze czasami w malym projekcie szybciej jest zadeklarowac tu i
owdzie
kikla zmiennych i w procedurach zdarzeniowych przeprowadzic
obliczenia.
Nie uwazam ze tworzenie aplikacji z pomieszana logike w interefejsie
jest czyms bardzo nagannym. Ostatecznie chodzi o czas i pieniadze.
Male i
proste aplikacjie najszybciej tworzy sie wlasnie tak bez projektu i
byle jak.
Czas zainwestowany w porzadny projekt zwraca sie dopiero gdy aplikacja
jest duza,
dopiero gdy w przyszlosci bedzie wymagala konserwacji, itd.

Pozdrawiam




Pozdrawiam

do góry

Mariusz Marszałkowski pisze:
/ciach/

> Czas zainwestowany w porzadny projekt zwraca sie dopiero gdy aplikacja
> jest duza,
A kiedy aplikacja jest duża?

> dopiero gdy w przyszlosci bedzie wymagala konserwacji, itd.
Każda aplikacja, która działa w zmiennym otoczeniu (np. biznes), wymaga
konserwacji...

--
wloochacz

do góry

On 20 Lut, 00:46, wloochacz <w...@n...dgbit.spameromnie.pl>
wrote:
> Mariusz Marszałkowski pisze:
> /ciach/
>
> > Czas zainwestowany w porzadny projekt zwraca sie dopiero gdy aplikacja
> > jest duza,
>
> A kiedy aplikacja jest duża?
Hmmmm... mniej/wiecej wyglada to tak, ze jak cala aplikacje napisze w
jeden/dwa
dni to olewam projekt. Jesli aplikacja jest typowo obliczeniowa, typu
czyta dane ze
standardoweg wejscia i wypluwa wyniki na standardowe wyjscie to tez
nie robie
projektow.

> > dopiero gdy w przyszlosci bedzie wymagala konserwacji, itd.
>
> Każda aplikacja, która działa w zmiennym otoczeniu (np. biznes), wymaga
> konserwacji...
No tak, ale jak projekt i dokumentacja zajmuja dwa razy wiecej czasu
niz
napisane aplikacji to tez go robic? Jesli aplikacja jest tak prosta ze
pozniej
w jej logice mozna sie polapac po 15 minutach zastanowienia to tez
pisac
ksiazke do aplikacji?

Pozdrawiam

do góry

W dniu 2010-02-20 00:46, wloochacz pisze:
> Mariusz Marszałkowski pisze:
> /ciach/
>
>> Czas zainwestowany w porzadny projekt zwraca sie dopiero gdy aplikacja
>> jest duza,
> A kiedy aplikacja jest duża?
>
>> dopiero gdy w przyszlosci bedzie wymagala konserwacji, itd.
> Każda aplikacja, która działa w zmiennym otoczeniu (np. biznes), wymaga
> konserwacji...

Ci, którzy potrafią poprawnie odpowiedzieć na pierwsze pytanie
i dobrze przewidzieć tempo i wielkość zmienności zarobią więcej 8-)

A i tak sporo zależy od cierpliwości i kasy klienta oraz zdolności
negocjacyjnych sprzedawców - projekty mogą dowolnie poruszać się
w przedziale od ortodoksyjnego i poukładanego projektu do "spaghetti
code". Problem dla deweloperów jest taki, że w krótkiej perspektywie
łatwiej (szybciej, taniej) przejść do gorszych rozwiązań niż do
lepszych.

--
Paweł Kierski
n...@p...net

do góry

Paweł Kierski pisze:
> W dniu 2010-02-20 00:46, wloochacz pisze:
>> Mariusz Marszałkowski pisze:
>> /ciach/
>>
>>> Czas zainwestowany w porzadny projekt zwraca sie dopiero gdy aplikacja
>>> jest duza,
>> A kiedy aplikacja jest duża?
>>
>>> dopiero gdy w przyszlosci bedzie wymagala konserwacji, itd.
>> Każda aplikacja, która działa w zmiennym otoczeniu (np. biznes), wymaga
>> konserwacji...
>
> Ci, którzy potrafią poprawnie odpowiedzieć na pierwsze pytanie
> i dobrze przewidzieć tempo i wielkość zmienności zarobią więcej 8-)
>
> A i tak sporo zależy od cierpliwości i kasy klienta oraz zdolności
> negocjacyjnych sprzedawców - projekty mogą dowolnie poruszać się
> w przedziale od ortodoksyjnego i poukładanego projektu do "spaghetti
> code". Problem dla deweloperów jest taki, że w krótkiej perspektywie
> łatwiej (szybciej, taniej) przejść do gorszych rozwiązań niż do
> lepszych.
>

Czas życia (konserwacji). Wiodąca sprawa.
Częściej trafiam na sytuacje że coś miało być na krótko a trwa latami,
niż na odwrót (chyba najczesciej upadłość/niedostepnośc wykonawcy tylko
kończy). Może pehapki na słuzbie działu marketingu są stosunkowo na
krótko, ale to taka uroda tych działów, byle do następnych wiatrów.
Reszta w moim doświadczeniu chce długo żyć i być ciągle rozwijana.

Albo że projekt da się 'niewiele' zmodyfikowany sprzedać jeszcze raz
itd. Problem w tym 'niewiele'. Jak masz wg wzorców, oddzielasz to co
zmienne i specyficzne od stałego i wspólnego, jesteś w domu. Ze spagetti
masz przerąbane.

do góry