Пропало желание кодить в ООП

Похоже на нормальное нарабатывание опыта.
В крайности ООП вы уже были, осталась крайность функционального и скоро все придет в баланс.
Концепции процедурного подхода важны для понимания сущности ООП - т.е. от чего и когда хотели избавиться создавая его. Ведь уже сейчас вам навороты страна-объект кажутся странными? Пишите что-нибудь как хочется и пересматривайте свои приемы, подходящий момент настал.

 

Да ладно!
Посмотри как реализован класс Runtime
или в OpenGl класс GraphicDevice

 

америкосы в магазин за 10м ездят на специальных машинках, а кто не, тот покупает себе стульчики с мотором и ездит на них. При этом едят если сало, то только безкалорийное, тк эпидемия ожирения. Почему ездят? Потому, что это круто! Да и как это можно - "не ездить"?

 

Это все строка, или если нужно отдельно по составляющим - структура.

 

Из за таких концепций рождаются глючища типа 1С .

Проще да, char address написать, чем создавать модель.

 

osrootd
Ну так я же говорю, если нужен доступ отдельно к составляющим адреса, то нужна структура...
А если адрес это просто какая-то "атомарная" характеристика чего-то - то строка...

 

osrootd
Еще раз, мы обсуждаем ентерпрайз приложение?
статические методы ведут к статическим данным, а статические данные не только для чтения требуют синхронизации, а синхронизации нужно избегать всеми способами

 

смотря какие данные...

 

ой, ну и все как обычно про опенжл вспомнили!

Код (Text):

1.    #pragma pack(1)
2.     struct Entity{
3.  
4.       int Index;  // [i]ndex
5.       byte Type;  // shape
6.       byte ef;    // effect
7.       bool mat;   // sunblicks on/off
8.       bool globed;// is camera vovement-independent
9.       Entity*Dependant;
10.       byte collision;
11.       DWORD reserved;
12.  
13.       GLdouble R; // -color
14.       GLdouble G; // -|
15.       GLdouble B; // -'
16.       GLdouble A; // -alpha
17.  
18.  
19.       GLdouble PosX;  // -basic position
20.       GLdouble PosY;  // -¦
21.       GLdouble PosZ;  // -'
22.  
23.       GLdouble RotX;  // -rotation
24.       GLdouble RotY;  // -¦
25.       GLdouble RotZ;  // -'
26.  
27.       GLdouble ScalX; // -scale
28.       GLdouble ScalY; // -¦
29.       GLdouble ScalZ; // -'
30.  
31.  
32.       GLdouble pPosX; // -collisions backups
33.       GLdouble pPosY; // -¦
34.       GLdouble pPosZ; // -'
35.     };//Entity;
36.  
37. ...
38.  
39. void Scale(pobj H,GLdouble x,GLdouble y,GLdouble z){
40.   H->ScalX=x;
41.   H->ScalY=y;
42.   H->ScalZ=z;
43. }
44. void ScaleP(pobj H,GLdouble x,GLdouble y,GLdouble z){
45.   H->ScalX+=x;
46.   H->ScalY+=y;
47.   H->ScalZ+=z;
48. }
49. void SetPos(pobj H,GLdouble x,GLdouble y,GLdouble z){
50.   H->PosX=x;
51.   H->PosY=y;
52.   H->PosZ=z;
53. }
54. void MoveOLD(pobj H,GLdouble x,GLdouble y,GLdouble z){
55.   H->PosX+=x;
56.   H->PosY+=y;
57.   H->PosZ+=z;
58. }
59.  
60.  
61. void Move(pobj H,GLdouble x,GLdouble y,GLdouble z){
62. ///X
63.   H->PosX-= x *dcos(H->RotY);
64.   H->PosX-= z *dsin(H->RotY);
65.  
66. ///Y
67.   H->PosY+= y *dcos(H->RotX);
68.   H->PosY+= z *dsin(-H->RotX);
69.  
70. ///Z
71.   H->PosZ+= x *dsin(H->RotY);
72.   H->PosZ-= z *dsin(H->RotY+90);
73. }
74.  
75. ...
76.  
77. pobj PutEnt(byte tp=0,Entity* rel=0){
78.  
79.   if(ocnt==mxsz) return ojs[ocnt-1];
80.  
81.   if(!ojs[ocnt]){
82.     ojs[ocnt]=(pobj)GlobalAlloc(GMEM_ZEROINIT,sizeof(Entity));
83.     DBG("Allocated %03d:%p",ocnt,ojs[ocnt]);
84.   }else ZeroMemory(ojs[ocnt],sizeof(Entity));
85.  
86. //  DBG("put %x %d",(int)ojs[ocnt]%1024,GetLastError());
87.  
88.   ojs[ocnt]->Type=!tp?_tCUBE:tp;
89.   ojs[ocnt]->Index=ocnt;
90.   ojs[ocnt]->ScalX=1.0;
91.   ojs[ocnt]->ScalY=1.0;
92.   ojs[ocnt]->ScalZ=1.0;
93.  
94.   if(rel){
95.     ojs[ocnt]->PosX=rel->PosX;
96.     ojs[ocnt]->PosY=rel->PosY;
97.     ojs[ocnt]->PosZ=rel->PosZ;
98.  
99.     ojs[ocnt]->RotX=rel->RotX;
100.     ojs[ocnt]->RotY=rel->RotY;
101.     ojs[ocnt]->RotZ=rel->RotZ;
102.   }
103.  
104.   ocnt++;
105.   if(ocnt>mxsz){
106.     ocnt=0;
107.     MessageBeep(MB_ICONASTERISK);
108.   }
109.  
110.   return ojs[ocnt-1]; // inc count after ret
111. }
112.  
113. pobj glFree(pobj H){
114.   int indx=H->Index;
115.   DBG("del %03d:%p",indx,ojs[indx]);
116.  
117.   GlobalFree(ojs[indx]);
118. //  ZeroMemory(ojs[indx],sizeof(Entity));
119.  
120.   pobj t=ojs[indx];/// 1
121.   ojs[indx]=ojs[--ocnt];/// 2
122.   if(ojs[indx])ojs[indx]->Index=indx;
123. //  ojs[ocnt]=t; /// 3
124.  
125.   for(int i=0;i<ocnt;i++){
126.     if(ojs[i]->Dependant==t){
127.       DBG(" found depended %03d:%p from current %x, deleting..",i,ojs[i],(int)H%0x1000);
128.       glFree(ojs[i]);
129.     }
130.   }
131.  
132.   ZeroMemory(t,sizeof(Entity));
133.  
134.   return 0;
135. }...

вот такой вот опенжл без ооп,
и всё прекрасно создаётся/обрабатывается/рисуется и работает без лишних тормозов, и килограммов лишнего жира в бинаре.

 

Да

Видать я не так сформулировал:

Код (Text):

1. Class Country
2. {
3. static   Country getNew ( [Список параметров извлечения страны] ){
4.              Country TemporaryCountryBuild = new Country();
5.       *** код инициализации **
6.            return TemporaryCountryBuild;
7.   }
8. }

Так яснее?

 

osrootd

fasm, masm32 ) покодь в своё удовольствие - отдохни душевно ) если работа мешает - возьми творческий отпуск новые силы которые ты в нём обретёшь выведут тебя на новый уровень понимания и окупят издержки

scf

считаешь лучше когда этот идентификатор неявно подставляется компилятором? а по моему лучше всегда знать что же происходит на самом деле, даже если прячешь что-то из-за удобства в ООП.

вовсе не обязательно всё зависит от реализации, особенно когда "статические методы" это просто функции )
а вот мысли:

загромождают мозг и мешают медитации над кодом

 

osrootd
это называется "фабрика":

Код (Text):

1. public Class Country{
2.  
3.   public static final class Factory{
4.     public static Country newInstance( [Список параметров извлечения страны]){
5.        return new Country( [Список параметров извлечения страны]);
6.     }
7.   }
8. }

 

varnie
Это строго по паттерну. Иногда бывает неуместно.
Делать фабрику стран - онанизм тот еще.

У тебя получится Country.Factory.newInstance(mixed params);

Можно страну по ссылке передавать конструктору адресов ( у меня так по крайней мере реализовано )

Address.Country.getCountry ( mixed[] ), причем getCountry перегруженный метод.

Была как-то реализация в виде дерева. Класс AddressTreeModel implements CorporateObjectTreeModel - позаимствовал из TreeModel нативного..

Ты не в теме чуть-чуть. У нас энтерпрайз кодинг. Там такого нету
Либо Persistense работает на подстановку (если применяется), либо - сам кодер.

 

А что есть такие заказчики,для которых важно ооп или структурное программирование?Мне казалось заказчику до лампочки, как написано лиж бы работало по заказу.

 

Library developing

Иногда они читают код.

 

Интересно зачем,просто от нефиг делать или тырят реализацию?

 

Y_Mur
Мне врача прислали.
Щас проект на ооп закончу и...
В общем, девайс принесли для контроля термальной радиации.
К нему драйвер нужен. Он от USB работает. Есть документация, даже с примером драйвера, так что скоро пойду лечиться.

 

scf
ООП надо понимать как простоту разработки. Она невсегда нужна. Главное знать где кончается одно и начинается другое.

 

K10
Можно пример модифицируемых данных, не требующих синхонизации? Кроме конечно классов, которые синхронизируюся сами "изнутри"

Ты не прав. Заказчику нужно, чтобы эту систему можно было дорабатывать когда ты свалишь.
osrootd
Статические методы - почти всегда плохой подход.
1. многопоточность - см. выше
2. если сейчас этот метод не ссылается на внешние ресурсы, значит будет ссылаться потом и тебе придется убирать static и перефигачивать код в месте использования.
Pavia
+1
Главное - видеть золотую середину. Что приходит только с опытом.

 

scf
Могу, конечно, ошибаться, но например DWORD?
Запись/чтение производятся атомарно.
DWORD'ом может быть и указатель на какую-то структуру, в этом случае вся структура подменяется атомарно...