WaReZMEN, вот тебе список вопросов, пока ты для своего кода не ответишь на все эти вопросы положительно, разговаривать с тобой будет бесполезно...



P.S. И добавь комментарии к методам и классам!!!

source777, слов нет. Ну я ведь просил не придерется к названиям та как изменить их дело 10 секунд а на данном этапе мне и так понятно что и они обозначают. Я прекрасно понимаю, что здесь можно долго возражать. В дельфи делалось все проще создал юнит там константы объявил и юзаи их де нужно.  По поводу списка вопросов вопросы конечно интересные постараюсь ответить.  Тем неимение спасибо, что так раскритиковали заставляет задуматься тем ли я занимаюсь… Мож на сварщика пойти… 
Вот enum переделал так лучше?




Ну имена переменных слабость вечно полчаса сидишь и думаешь как назвать... myBrush ну а как к примеры вы бы назвали??? tmpInfill ну да здесь глупо конечно был еще один вариант xInfill  
Infill1 и Infill2 ну здесь вообще другие варианты просто отпадают ибо у каждого infil может быть еще два...



Это сообщение отредактировал(а) WaReZMEN - 8.8.2008, 02:32

Я сразу написал, что не бо ООП мое замечание. Потому что в задачу не вникал, чтобы указать где что-то можно реализовать. Такие куски кода разве что будучи тим-лидером буду исследовать.


Приставка my в названиях мне вообще непонятна. К чему "Мои документы", ..., myBrush, myCollection и т.д.? Понятно что если я написал то оно и так - My.

В случае же расширения классов конкретно ради специфики задачи и когда на ум ничего не приходит в качестве приставки, или окончания (зависит от пожеланий к сортировке при отображении в IDE) использую название проекта. Обычно 3, 4ре первые буквы.
Пример - это тоже проект. Приучайтесь к порядку и конкретике;


Может 

Но тут решать нужно - чем больше нравится заниматься.

А насчет критики - то напрасно удивляетесь. Иного и быть не могло, даже если бы написали красивейший код.

Для того чтобы научиться писать в стиле ООП быстро и надежно (а не долго, от проекта к проекту по капле выдавливая из себя "процедуриста", и периодически впадая обратно) берете - Smalltalk(Cincom'овский например) - и вперед. Там либо ничего не напишете, либо в ООП.

Skynin, 

Я не против критики  это просто шутка была... мне какраз критика и нужна...

Это тебе пока так кажется, а практика показывает, что утверждение "как вы лодку назовёте - так она и поплывёт" вполне применимо к программированию, точнее к именованию идентификаторов. Ведь именно идентификаторы определяют под каким углом зрения ты будешь смотреть на код...


Зачем полчаса придумывать какое-то абстрактное имя для переменной? Если она не имеет чёткого семантического смысла, значит она не нужна, а если имеет, то и назови её исходя из смысла...  Смысл твоих переменных неочевиден и не описан в комментариях, поэтому хорошего названия на все случаи тебе никто не предложит, пока ты не разъяснишь конкретную ситуацию. 

"У каждого заполнения может быть ещё два заполнения" - по твоему это нормальная фраза?

Добавлено через 5 минут и 10 секунд
гораздо лучше, ещё бы приставку ms убрать из значений MouseState, и Align заменить на Alignment, всё-таки существительные в данном случае предпочтительнее.

source777, 

Фраза может и не очень, но отражает суровую действительность... Так как что структура такова что самого начала работы программы у нас есть только одно заполнение когда мы кидаем на него Импост наш инфил грубо говоря делится на две части справа от импоста и слева. Так вот мне кажется, что такая структура правильна. Иначе придется сперва заполнение делить на множество вообще на мои взгляд так проще (с двумя инфилами) 
по поводу  Alignment ну я так и сделал сначала а потом посмотрел что в Делфи к примеру это свойство отвевает за выравнивание, а меня как бы к чему прилипает (глупо конечно звучит ) а MouseState уже убрал 
Может, поможете мне решить проблему с методом Recalc



Все говорили что много switch и что нужно юзать паттерн State. Почитал я  думаю что сдесь он не уместен. Если не прав растолкуйте.
 Скажу лишь,  что это метод вызывается только при созданий экземпляра класса TPrifil это груба говоря, рама окна. 

Это сообщение отредактировал(а) WaReZMEN - 8.8.2008, 12:21

Это всё отмазы, если структура - плохая, то надо сделать хорошую исходя из задачи, а не исходя из структуры. Ты можешь хоть описать, что ты делаешь, нормальным русским языком? Или ты думаешь, что кто-то понял твой код?       

метод - рама? метод - это действие! Зачем нужен этот метод?  Что такое maspoints? Что такое Parent? Почему maspoints нельзя заменить на набор вычисляемых свойств? Почему maspoints пересоздаются каждый раз? Они устанавливаются разными методами? Так не должно быть должны быть центральные точки управления! А глобальных переменных быть не должно!!!
 

source777, еслиб запустили мои код то уивидели бы что я делаю... Это примитивный конструктор пластиковых окон.


Вообщем каждое окно состоит из рамы (я предпоситаю слово каробка TConstraction)  стекл (или запонения TInfill) и импостов TImpost перегородок разделяющих раму онка и соответствено стекла (в место одного большого) два поменьше... рама (каробка) состоит из   4-х профилеи (всмысле пластиковых профилеи TProfill). Метод Recal (деиствие или как вы его называете...) для меня это грубо говоря процедура расчета координат профиля для его графического отображения точки он записывает в maspoint... 

Parent это какраз сылка на клас TConstraction мы делаем это для того чтоб понят к какой канструкций принадлежит данный профиль... как заменить на набор вычесляемых свойств не знаю как это сделать... 

Насамом деле он создается только один раз для конкретного профиля. в дольшеишем нет пересчета...


Центральные точки управления чего?
P.S. Вот скрин программы... 
Планируется еще створки добавить предпологаю что класс створок будет наследоватся от TConstraction.

Pane - оконное стекло
WindowFrame - оконная рама
Separator - перегородка-разделитель
Profile - профиль

Ну демонстрируй, как ты за 10 сек, меняешь имена классов...

С какого хрена maspoints не private??? Она просто обязана быть private!!! Нафига метод назван ReCalc, если нет никакого пересчёта? Зачем нужен этот метод? Убери его...

Как в анекдоте:

Так что запомни: если код надо выполнить, чтобы понять, что он делает, то этот код необходимо выбросить!!!



Ну хоть что-то удалось из тебя выжать... 
Уже можно сказать, что отношения наследования тут нет!
А есть класс Window, в него включены экземпляры классов WindowFrame,  Separator,  List<Profile>, List<Pane>.
У всех классов (Window, WindowFrame,  Separator,  Profile, Pane) есть св-ва TopLeftPoint, Width и Height и метод Draw, их можно взять у IDrawable, причём эти свойства read-only(исключение для Separator, который можно двигать, и Pane, геометрические св-ва которого меняются в зависимости от Separator) и устанавливаются в конструкторе. Дальше всё вполне просто, возможно ты даже справишься с реализацией самостоятельно.


Failed. Центральные точки управления ЧЕМ? Сложностью естественно.

Названия эти не мной придуманы так они насамом деле называются в производстве оконных пластиковых конструкциях...


Ну потому как был метод Paint в классе MngConstruction (он типа управляющий класс)...

Я упоминул что в будущем будет створка и если мы будем двигать Импост или как вы его назавали Separator то естествено створка будет пересчитыватся....  а вообще можно посомтреть мою прогу работающую на дельфе http://primokna.ru/PrimOknaSoft.exe ну это если интересно...


За это спасибо! Вот только мне лично кажется что  к примеру импост (Separator) можно унаследовать  от Profile створку от WindowFrame... может я и не прав конечно... 
Так осталось не понятно как быть с расчетом координат для Profile и прочих элементов?

Это сообщение отредактировал(а) WaReZMEN - 8.8.2008, 14:57

Не использовать все эти координаты, там явная избыточность у тебя с точки зрения математики, а нужный базис я тебе указал: координаты угла, ширина и высота.



Наследовать можно лишь в одном случае - если между классами существует отношение "является". А теперь подумай: перегородка является профилем? створка является оконной рамой?

Спустил твою прогу, не очень понятно что делает.Особенно когда щелкаю на раму, ну становятся синего цвета. ну ладно написано "примитивный".
А допиши метод FMain_Paint так:

Небудет так графика мерцать.  

Это сообщение отредактировал(а) SKrivosein - 8.8.2008, 15:56

Эта тема уже разрослась до неимоверных пределов. Я думаю, обсуждение в таком же ключе мало чем поможет - надо перепроектировать. Автору неплохо бы изучить ООП, построить диаграмму классов, взаимодействий и потом уже заняться кодированием.

QryStaL, а я как раз подумал, что автору следовало бы создать новый топик в разделе о проектировании ПО и запостить туда предметную область. Я думаю, что такие корифеи системного анализа как ida, помогут.

SKrivosein, 

это выделения в будущем можно будет посмотреть размеры и тип выбраного профиля.... За код против мерцания отдельное спасибо 
source777 ,

Вот если чесно профиль делается из тогоже что и перегородка зазница между ними в ом что у профеля углы скошены а у перегоротки прямые ну и ее можно двигать... Рама тоже 4-х угольная как и створка более того в створке тоже может быть несколько стекл и перегоротка. Воообщем если говорите не нужно наследовать значит не буду... По поводу названий Pane не совсем верно так как в окнах не обязательно стекло может быть... Вообще в пластиковых окнах есть понятие заполнения в него входят стеклопаке (несколько стекл 2-3 и больше) а также сендвич-панель ну прочие не буду вдаватся в детали....
QryStaL, 

Ну этим я какраз токи я занялся... по поводу ООП ну какбы я знаю что это такое и с чам это едят...
Partizan, ну мне то ножно не готовое решения я хочу понять как должно быть. как говорилось выше программа то работает (просьба не кречать про говнокодерство) и я щас разбераюсь как по правельному должен быть написан подобный код вот и все... 

Это сообщение отредактировал(а) WaReZMEN - 9.8.2008, 01:20