(vel obiekcie)

jak ktos ma modul i kilkanascie jego funkcji (vel metod) w nim napisanych
to funkcje te tworza pewien porzadek w sensie hierarchii wywolan

np 'na poczatku' jest jakis 'init', albo np alloc w przypadku obiektowym, np
'update' w przypadku agentowo modulowym itp - dalej jest hierarchia wywolan
z poziomami

chodzi mi o to czy ktos uwaza jakies konkretne konwencje z tym zwiazane
czy stawia metody raczej przypadkowo

czy lepiej pisac

f2() {}
f1() {}
init() {}

czy

init() {}
f1() {}
f2() {}

czy

init() {}
relaease() {}
f1() {}
f2() {}

czy

init() {}
f1() {}
f2() {}
relaease() {}

czy jeszcze inaczej ?


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

W dniu 2011-09-02 10:21, kenobi pisze:

>
> chodzi mi o to czy ktos uwaza jakies konkretne konwencje z tym zwiazane
> czy stawia metody raczej przypadkowo

Na pewno jak ktoś używa repozytorium kodu, "ulepszanie" estetyki przez
zmianę kolejności zwykle jest źle widziane.

do góry

> W dniu 2011-09-02 10:21, kenobi pisze:

>

> >

> > chodzi mi o to czy ktos uwaza jakies konkretne konwencje z tym zwiazane

> > czy stawia metody raczej przypadkowo

>

> Na pewno jak ktoś używa repozytorium kodu, "ulepszanie" estetyki przez

> zmianę kolejności zwykle jest źle widziane.


zmiane wzgledem czego ? to cos jaki ma porzadek - pewnie przypadkowy

sam poki co pisalem na poly przypadkowo z elementami organizacji odwrotnej
(znanej z c) ale teraz sie zastanawiam - organizacja jest (czy moze raczej moze moze
byc) wazna bo zauwazam ze czasem sporo wysilku zajmuje mi wyszukanie funkcji
ktorej szukam - a po nazwie tez nie bo czesto nie pamietam nazwy - wiem tylko ze
ta ktorej szukam jest nadrzedna czy podrzedna czy gdzies tam


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

> (vel obiekcie)

>

> jak ktos ma modul i kilkanascie jego funkcji (vel metod) w nim napisanych
> to funkcje te tworza pewien porzadek w sensie hierarchii wywolan
Czy ja wiem czy to ma jakieś znaczenie. W kilku projektach a w nich w
wielu plikach/klasach mam taką samą kolejność metod ale nie planowałem
jej - po prostu klasa była kopiowana z szablonu i wypełniana treść
metod. Więc kolejność jest uporządkowana. Ale czy to ma jakieś znaczenie
dla czytelności? Chyba nie ma.
Pozdrawiam



--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

On 2-9-2011 10:21, kenobi wrote:
> (vel obiekcie)
>
> jak ktos ma modul i kilkanascie jego funkcji (vel metod) w nim napisanych
> to funkcje te tworza pewien porzadek w sensie hierarchii wywolan
>
> np 'na poczatku' jest jakis 'init', albo np alloc w przypadku obiektowym, np
> 'update' w przypadku agentowo modulowym itp - dalej jest hierarchia wywolan
> z poziomami
>
> chodzi mi o to czy ktos uwaza jakies konkretne konwencje z tym zwiazane
> czy stawia metody raczej przypadkowo
>
> czy lepiej pisac
>
> f2() {}
> f1() {}
> init() {}
>
> czy
>
> init() {}
> f1() {}
> f2() {}
>
> czy
>
> init() {}
> relaease() {}
> f1() {}
> f2() {}
>
> czy
>
> init() {}
> f1() {}
> f2() {}
> relaease() {}
>
> czy jeszcze inaczej ?
>
na tej samej zasadzie mozna by zapytac o kolejnosc sekcji: public,
protected i private czy tez odwrotnie... a gdzie typedefy w tym
wszystkim. niekiedy chcac przestrzegac z gory ustalonych regul robi sie
straszny bajzel w .h.

ja nie przywiazuje wagi do kolejnosci. inaczej, nie zawsze robie to tak
samo. zalezy to troche od samej klasy, jakie ma za zadanie, czy jest
duzo virtuali, etc.

zalezy tez troche od tego w jaki code base sie wgryzamy, niekiedy warto
trzymac sie utartych wzorcow niz w sztuczny sposob nakladac swoje. na
przyklad jesli dziedziczymy i mamy do zadeklarowania kilka virtuali,
warto umiescic je w podobnym miejscu i kolejnosci jak w samej nadrzednej
[?] klasie ktora je deklaruje po raz pierwszy. jesli startujesz od zera
to oczywiscie jestes na uprzywilejowanej pozycji i wzorce mozesz zalozyc
osobiscie.

pozdrawiam
Sarr.

do góry

On 2 Wrz, 14:04, "Sarr." <s...@g...pl> wrote:
> na tej samej zasadzie mozna by zapytac o kolejnosc sekcji: public,
> protected i private czy tez odwrotnie...

Znane mi standardy kodowania sugerują najpierw public, potem protected
i na końcu private - ta kolejność wynika z tego, że czytelnik, który
zwykle jest użytkownikiem klasy, najbardziej jest zainteresowany
publicznym interfejsem, więc jest sens go napisać na początku.

> a gdzie typedefy w tym
> wszystkim.

To zależy, czy są publiczne, czy nie, bo patrz wyżej.

> niekiedy chcac przestrzegac z gory ustalonych regul robi sie
> straszny bajzel w .h.

Właśnie po to są te reguły, żeby bajzlu nie było.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

> > (vel obiekcie)

>

> >

>

> > jak ktos ma modul i kilkanascie jego funkcji (vel metod) w nim napisanych

> > to funkcje te tworza pewien porzadek w sensie hierarchii wywolan

> Czy ja wiem czy to ma jakieś znaczenie. W kilku projektach a w nich w

> wielu plikach/klasach mam taką samą kolejność metod ale nie planowałem

> jej - po prostu klasa była kopiowana z szablonu i wypełniana treść

> metod. Więc kolejność jest uporządkowana. Ale czy to ma jakieś znaczenie

> dla czytelności? Chyba nie ma.

> Pozdrawiam

>
rozumiem te (ta i uz sarr) wypowiedzi, jako 'niezaleznie
od ukladu dla nas i tak jest czytelnie' - no ok, ale

tez mz byc moze dla mnie chyba jednak warto
ew zwrocic na to troche uwagi - badz co badz jest to
jeden z elementow poziomow organizacji w kodzie
('cialo modulu');
o ile jak napisac i poznazywac funkcje w kodzie to
jeden temat, to poukladac je w module (cialo modulu)
to drugi, a sam rozklad modulow w programie to trzeci


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

> tez mz byc moze dla mnie chyba jednak warto
> ew zwrocic na to troche uwagi - badz co badz jest to
> jeden z elementow poziomow organizacji w kodzie
> ('cialo modulu');
> o ile jak napisac i poznazywac funkcje w kodzie to
> jeden temat, to poukladac je w module (cialo modulu)
> to drugi, a sam rozklad modulow w programie to trzeci

W przypadku metod ważne są ich nazwy i "przestrzenie
dostępu". Jeśli język wspomaga metody polimorficzne,
to nazwy są szczególnie ważne. Kolejność ich to
drugorzędna sprawa, może być ważna ale w małym stopniu.

Natomiast organizacja modułów, np. ich nazwy i położenie w
podkatalogach to kluczowa sprawa w dużych projektach.
W kodzie który ma chociaż łączny rozmiar 1MB odnajdywanie
odpowiedzialnego fragmentu za daną funkcjonalność bywa
bardzo męczące. Położenie modułów to problem innej rangi
niż organizacja funkcji.

Pozdrawiam



--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

W dniu 2011-09-03 10:27, m...@t...pl pisze:
>
> W przypadku metod ważne są ich nazwy i "przestrzenie
> dostępu". Jeśli język wspomaga metody polimorficzne,
> to nazwy są szczególnie ważne. Kolejność ich to
> drugorzędna sprawa, może być ważna ale w małym stopniu.
>
> Natomiast organizacja modułów, np. ich nazwy i położenie w
> podkatalogach to kluczowa sprawa w dużych projektach.
>

Zahaczyłbym o "paradygmat", bo zaczynamy się poruszac gdzieś pomiędzy
obiektowy a ... jakims innym.
Nie jest to wielki grzech (chyba) i w realnym programowaniu występuje,
ale teoretycy pewnie by się krzywili.

Dla mnie OOP i programowanie modułowe/modularne itd ... realizują bardzo
stare i uniwersalne postulaty izolacji, separacji, ukrywania
implementacji (i wiele innych). Sa w tym podobne, konkurują, uzupełniają
się a zarazem do pewnego stopnia wykluczają.

Zapewnienie postulatów z grupy 'izolacji' oboma ujęciami jednocześnie
(OO i modułowym), stosuje się w praktyce, ale jakoś ... dziwne jest. Na
pewno trzeba sporo dopowiedzieć co do naszej konwencji itd.

do góry

> W dniu 2011-09-03 10:27, m...@t...pl pisze:

> >

> > W przypadku metod ważne są ich nazwy i "przestrzenie

> > dostępu". Jeśli język wspomaga metody polimorficzne,

> > to nazwy są szczególnie ważne. Kolejność ich to

> > drugorzędna sprawa, może być ważna ale w małym stopniu.

> >

> > Natomiast organizacja modułów, np. ich nazwy i położenie w

> > podkatalogach to kluczowa sprawa w dużych projektach.

> >

>

> Zahaczyłbym o "paradygmat", bo zaczynamy się poruszac gdzieś pomiędzy

> obiektowy a ... jakims innym.

> Nie jest to wielki grzech (chyba) i w realnym programowaniu występuje,

> ale teoretycy pewnie by się krzywili.

>

> Dla mnie OOP i programowanie modułowe/modularne itd ... realizują bardzo

> stare i uniwersalne postulaty izolacji, separacji, ukrywania

> implementacji (i wiele innych). Sa w tym podobne, konkurują, uzupełniają

> się a zarazem do pewnego stopnia wykluczają.

>

> Zapewnienie postulatów z grupy 'izolacji' oboma ujęciami jednocześnie

> (OO i modułowym), stosuje się w praktyce, ale jakoś ... dziwne jest. Na

> pewno trzeba sporo dopowiedzieć co do naszej konwencji itd.

>

>

jesli ktos chce odniesc pojecie systemu modulowego do
czegos konkretnego to moze to byc klasyczny c:

lista plikow .c z ktorych kazdy jest kompilowany do
odpowiedniego pliku .obj

(zarowno plik .c jak i .obj nazywam modulem, bo jest modulem,
.c jest sourcem dla modulu a .obj jego binarka)

.obj lacza sie miedzy soba przy pomocy externow (ale
w ogolnosci nie kazdy z kazdym i tworzy to swoisty
'rozgałęziak' system modulowy)

nie mam doswiadczen z powaznym ukladaniem takich
systemow w duzej skali (a bardzo mnie to ciekawi) -
pojedyncze projekty jakie pisalem to poki co skala
co najwyzej 30-40 modulow (kazdy modul ma u mnie
zwyczajowo kilkaset do tysiaca pareset lini)

fajnie by bylo zajac sie zastanawianiem nad
organizacją wiekszych systemow np po kilka tysiacy lub
kilkadziesiat tysiecy modulow :]

ciekawym czy pojawilaby sie na tym poziomie jakas nowa
warstwa posredniosci (organizacji) - poki co nie mam
pojecia





--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry