Курилка программистов

[Viнt@rь 50]

Но я так и не понял почему не обменяетесь кодами

Эмм... На самом деле кодами довольно таки давно обменялись и предоставили на общее пользование.

Ув. xStream(кстати с возвращением, давно не видел на форуме ):

Песочница, даже процитирую из мануала "Песочница" основана на так называемой event-driven модели", работа с net-пакетами, универсальное хранилище, таймера и прочее.

 

Ув. Malandrinus: слот-сигнальная система, таймера, хранилище и тд...(оно же используется в новом OGSE)

 

Там это все себе подцепил и ув. Artos, немного где-то подправил, под свой стиль, так сказать...

 

Еще были реализации от Monoroch, Меня(на основе выше указанных наработок написал свое, но более упрощенное и конкретно под свои нужны без "забеганий наперед") и еще несколько других...

 

Все это происходило примерно года 2 назад(время то как летит...) в теме "Язык Lua. Общие вопросы программирования", если мне не изменяет память... Все эти наработки имели достаточно разжеванный мануал по их использованию.

 

Ну и присоединюсь к

хотелось написать о многом...да ну его

Изменено 1 Февраля 2015 пользователем Viнt@rь

[Viнt@rь 50]

@Карлан, это был не выпад, это был ответ на "Но я так и не понял почему не обменяетесь кодами". То есть, помимо простого ответа "обменялись кодами давно", я дополнил его списком систем/тех самых кодов...

 

тут вроде перечисленные тобою между собой за эти модули не говорят

Говорят за эти системы не конкретно, а в общем(не только ты, от тебя проскочило максимум пару строчек в паре постов, примерно в контексте "меганавороченныхсуперсистем"), в основном оставаясь на стороне старых(времен величия АМК мода), когда сами же их разработчики говорят, что из себя представляют "старые", и какие выгоды можно получить от "новых".

 

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

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

 

в основном оставаясь на стороне старых(времен величия АМК мода)

Это скорее всего и было адресовано Денису Просто я видимо для себя не правильно растолковал вот эту твою фразу:

 

Да и для большинства модов суперсистем 

 

и не покажете таким как я на одном конкретном примере чье кунг-фу лучше? А пока "это и есть много букв"(с) как мне видится.

В ответ на это я и дал примерную дату и место(тему) где можно почитать об этом всем, замерах, обсуждениях и тд...

 

 

 

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

ООП в Lua - не ООП вовсе, все в той же теме о которой я упоминал выше и примерно в те же даты, происходило и обсуждение ООП + Lua. В итоге помню примерно такую фразу xStream "в Lua псевдо-ООП", средствами Lua невозможно задействовать и половины принципов ООП. Было еще примерно такое class "Foo" вовсе и не класс, а само выражение равносильно class("Foo") ну и сам этот класс являет собой на самом деле некую таблицу. В итоге мы получаем примерно такое класс = таблица, методы = поля таблицы(вроде бы даже метатаблицы, не помню точно) ну и естественно в коде выходит примерно такое:

class "Foo"
function Foo:name()
   return "Foo"
end

local Foo = {}
Foo.name = function() return "Foo" end

Вроде бы так, но я и не настаиваю на конкретике примера, думаю суть и так уловить можно.
В общем ООП не ООП в Lua, тут скорее всего уже как тебе будет удобно, сама же парадигма используется программистами для удобства написания кода, хотя на деле, это потеря в скорости выполнения программы

Изменено 2 Февраля 2015 пользователем Viнt@rь

[Viнt@rь 50]

сама же парадигма используется программистами для удобства написания кода

А так же проектирования архитектуры приложения и тд...

 

это потеря в скорости выполнения программы

Имею ввиду в программах написанных на С++ и подобных(Java, C# - тут уж от объектной ориентированности никуда не уйдешь...) Как оно в Lua - вот только сейчас задумался, как бы по логике и влиять не должно, так как это не совсем ООП.

 

ЗЫ и с этими постами думаю уже можно переезжать в подобающую тему "Язык Lua. Общие вопросы программирования". Хотя тут и неопределенность получается, и там и тут курим одно и тоже...

 

Так как это курилка, почему-то мне кажется, что в скоре мы получим микс тем С++ и Lua, так как в плане Сталкера, это самые актуальные вопросы, да и по большому счету они тесно связаны между собой. Потому не думаю, что здесь пойдут вопросы или обсуждения написания ПО на Java, C# и тп.

 

хотя мне опять же интересно узнать чем конкретно плохи модули Артоса

 

Имелось ввиду это:

Мне не нравилось никогда твое стремление все сделать универсальным и я этого никогда не скрывала. Стиль программирования тоже не импонирует, но тут уж точно личное дело каждого.

Скорее всего они плохи и хороши одновременно той самой универсальностью, так как универсальность очень часто является врагом производительности. Когда ты пичкаешь кучи проверок и кучи кода, с целью предусмотреть все возможные развития того или иного сценария для разных платформ(в нашем же случае это разные моды, со своими модулями и разные движки сталкера).

Изменено 2 Февраля 2015 пользователем Viнt@rь

[Viнt@rь 50]

@Malandrinus, все мною изложенное писалось в пол третьего ночи, потому я пытался не вбиваться в подробности и по-быстрому вкратце ответить Карлану на вот это:

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

Потому просто как бы, дал наводку, в каких местах использование парадигмы все же лучше/хуже(оправдано/не оправдано), если вбиваться в подробности, то тут можно рассуждать и рассуждать, курить и курить...

 

ООП - это не просто какое-то там удобство

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

 

С этим не соглашусь, поскольку ООП - это не конкретный синтаксис в конкретном языке, а парадигма.

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

Изменено 2 Февраля 2015 пользователем Viнt@rь

[Viнt@rь 50]

Просто при использовании традиционных процедурно-ориентированных подходов достигаться он будет гораздо большими затратами.

Я думаю, что спорить с этим будет лишь дурак, и лишь дурак не поймет всех прелестей применения парадигмы.

 

@warwer, сразу скажу не наезд, а интереса ради, ну да бы понять, я нагадил или нет. Потому не стоит ниже мною написанное воспринимать в штыки.

заскриптованного мата

вроде бы от меня не поступало такого

 

То, что прочёл выше - это его добивание...

имеется ввиду наше обсуждение парадигмы ООП?

 

Точно не о тебе писал. - warwer

Изменено 2 Февраля 2015 пользователем warwer

[Viнt@rь 50]

Ну как это нет?! Инкапсуляция - это объединение кода и данных. Нет скрытия реализации, поскольку нет атрибутов приватности у полей, но это не так уж критично. Полиморфизм тоже есть. Каждый метод - виртуальный, поскольку каждый объект явно содержит ссылки на функции.

а за это спасибо учту и говоря за инкапсуляцию я и имел ввиду скрытие реализации, а точнее ее отсутствие.

 

Сам каждый день, так сказать, вынужден использовать ООП ибо Java(Android) от этого там никуда не уйдешь. Возможно у меня возникла некая путаница в реализации принципов в Lua и в Java(C#, C++)

 

ЗЫ "вынужден" сказано не с досадой, а наоборот, так как самому нравятся идеи и применение ООП.

Изменено 2 Февраля 2015 пользователем Viнt@rь

[Viнt@rь 50]

Хотя в принципе, при соблюдении драконовской дисциплины скорость разработки не страдает ни разу. Скорее даже, наоборот, отсутствуют лишние телодвижения.

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

 

2 Viнt@rь: "драконовская" - это про меры по оформлению модулей и их взаимодействия.

Уточнять же нужно сразу у каждого своя практика, потому и свои взгляды на одни и те же вещи.

 

А эти самые "драконовские дисциплины" называются соглашениями(внутренние, в команде/компании и общепринятые) по оформлению кода и тд. И я считаю абсурдно их не придерживаться. Вряд ли кто именно "заставляет" это делать. Ведь все, по идее, понимают, что это повлечет за собой.

Изменено 2 Февраля 2015 пользователем Viнt@rь

[Viнt@rь 50]

Пишу на Java(Android), и хотел бы уточнить кое что, есть некий класс диалогового окна, унаследованный от базового DialogFragment, в диалоге выполняется смена какого-то значения пользователем, допустим - выбор местоположения из предоставленного списка, с помощью этого диалога, пользователь может выбрать свое текущее местоположение, и конечный адрес, соответственно "запоминать" координаты и сам адрес нужно в разные переменные, в итоге в голову пришло такое, да бы не плодить классов разных, задавать какой то там булеан типа isFinalAddress при создании/открытии диалога и повсюду, где нужно, смотреть, выставляем конечный адрес или нет, ну и при этом выполнять нужные действия... 

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

С точки зрения ООП, я так понимаю, что более правильный - второй вариант, но в итоге у нас на 1 класс(ну и естественно файл) становиться больше, мне то это не принципиально, но все же...

Таких моментов(классов) в приложении примерно 3-4, то есть в итоге, если действовать по второму варианту, то кол-во классов увеличиться еще на такое же число.

[Viнt@rь 50]

Обычно делают массив положений.

Хотелось бы пример увидеть, если не сложно

И да, забыл упомянуть, помимо логики, еще диалоги немного разные в визуальном плане, почему немного? Потому что у первого должна быть еще и кнопка GPS, а у второго ее не должно быть, соответственно верстать почти одинаковые разметки, с различием в один элемент, нет смысла... Потому в случае с конечным адресом, как мне кажется, лучше просто скрыть кнопку...

 

В случае с первым вариантом реализации такого(таких диалогов) код будет выглядеть в таком плане:

...
if (isFinalAddress) {
    button.setVisibility(View.GONE);
}
...

Изменено 7 Февраля 2015 пользователем Viнt@rь

[Viнt@rь 50]

Ну, верно, да.

В этом то и заключался вопрос), как правильнее/лучше сделать, как диалог должен понять, что сейчас запоминаем текущие координаты, а сейчас конечное местоположение.

Возможно я немного натупил, и забыл указать еще то, что нужно запоминать координаты в разные переменные:

double curLatitude...
double curLongitude...

double finalLatitude...
double finalLongitude...

Отсюда по всему классу диалога будет код такого вида:

if (isFinalAddress) {
    finalLatitude = location.getLatitude();
    finalLongitude = location.getLongitude();
} else {
    curLatitude = location.getLatitude();
    curLongitude = location.getLongitude();
}

Вот выше приведенное в пример, показалось мне костылем, я просто не знаю правильный(либо насколько правильный) такой подход? Потому и задумался, над тем, как еще можно сделать. В голову пришло, вынести это поведение(логику/операции... чет в голове все немного перемешалось) в разные классы, при этом есть базовый диалог(наследуемый), который реализует все, и в каком-то там отдельном методе реализует "запоминание" текущих координат.

А класс наследник, переопределяет этот метод, в котором реализует "запоминание" конечных координат. В итоге так можно уйти от "какого-то флага" и всех if `ов. И в конце концов, там где необходимо установить текущие координаты, мы откроем первый диалог(базовый класс), а где необходимо конечные координаты, откроем второй диалог(класс наследник первого)

 

@xStream,

Прочитав еще несколько раз твои ответы, начало складываться мнение, что мы друг друга не правильно поняли

Массив положений, сейчас я понял, что имелось ввиду нечто типа: ArrayList<Location> верно?

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

 

А в:

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

Изменено 7 Февраля 2015 пользователем Viнt@rь

[Viнt@rь 50]

 

 

И не надо разделять переменные на текущие и финальные, смысл cuurent* в диалоге с конечными координатами и наоборот?

Вот как раз таки надо разделять, эти переменные - на самом деле, поля некоего класса "настроек" там есть и текущие координаты, и координаты конечного адреса и куча еще всего другого... Например размеры текста, его цвет и тд... Для наглядности. вот более детальный пример:

if (isFinalAddress) {
    mSettings.setCurLatitude(location.getLatitude());
    ...
} else {
    mSettings.setFinalLatitude(location.getLatitude());
    ...
}

В итоге в будущем приложение может использовать одновременно и координаты текущего и конечного местоположения, да и при том в границах одного метода, например для сортировки по дистанции(радиусу) от пользователя до конечного адреса.

[Viнt@rь 50]

@Allender, немного не то, да и в Android есть такой класс как Location и всякие приблуды для вычисления радиуса/расстояния от одной точки(lat, lon) к другой...

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

Вот я и спрашиваю, как лучше сделать, проверять условием по флагу, что диалог открыт для установки конечного адреса/координат, то бишь:

if (!isFinalAddress) {
    mSettings.setCurLatitude(location.getLatitude());
    ...
} else {
    mSettings.setFinalLatitude(location.getLatitude());
    ...
}

Либо вынести эту часть логики, которая будет отрабатываться в зависимости от условия, в класс наследник, в итоге базовый класс будет для выбора и запоминания текущих координат, а класс наследник будет для установки конечных координат.

 

Вот небольшой пример

 

// базовый класс
class SelectLocationDialog {
    ... // Некая логика и реализация вьюхи
    @Override
    private void onAddressSelected(Location loc) { // некий метод реализующий интерфейс слушателя(listener) нажатия/выбора местоположения из списка
        addressSelected(loc);
    }

    // метод, который реализует логику запоминания/сохранение местоположения
    // в данном случае текущего
    protected void addressSelected(Location loc) {
        mSettings.setCurLatitude(loc.getLatitude());
        mSettings.setCurLongitude(loc.getLongitude())
    }
}

// класс наследник
class SelectFinalLocationDialog extends SelectLocationDialog {
    @Override // переопределили метод и реализовали свою логику
    protected void addressSelected(Location loc) {
        mSettings.setFinalLatitude(loc.getLatitude());
        mSettings.setFinalLongitude(loc.getLongitude())
    }
}

 

Изменено 7 Февраля 2015 пользователем Viнt@rь

[Viнt@rь 50]

@Allender, ну примерно так во втором варианте я и реализовал... Базовый класс реализует все, что надо вообще для диалога и для запоминания текущих координат, класс наследник просто переопределяет логику запоминания координат на свою, то бишь на установку конечных координат.

 

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

Изменено 7 Февраля 2015 пользователем Viнt@rь

[Viнt@rь 50]

@xStream, мне не важно куда присваивать/запоминать, в переменные либо в Location... Location это обычный класс в котором есть те же поля широты и долготы в все том же double, так зачем мне тогда создавать объект, который, я уверен, сожрет больше памяти(пусть и на несколько байт, но все же) нежели простой тип double... Да и к тому же при каждом закрытии приложения, в настройки придется сохранять эти координаты(конечного адреса) дергая опять таки методы get... А при загрузке обратно создавать объект и сетить туда эти загруженные координаты, а это как бы не есть хорошо, хотя операции сейв/лоад и разовые.

 

Фиг с ней, с венгеркой,

 

Это не венгерка, а CamelCase(цитата с вики https://ru.wikipedia.org/wiki/CamelCase):

В языке Java принято использовать UpperCamelCase для наименования классов и lowerCamelCase — для наименования экземпляров классов и методов.

 

Вот пример того самого Location:

 

По поводу "mSettings" как видно, даже гугловцы(и не только) пишут с некими элементами венгерки Хотя так же и встречал онли lowerCamelCase по отношению к переменным во многих кодах Java разработчиков

 

"Более лучше" © Как эффективнее, так и лучше. Правильно - не то слово, в данном случае.

"правильный" и имелось ввиду эффективность, и "лучше"

 

В общем, мне интересен ответ, я уже несколько раз разжевал на что именно, но ни малейшего приближения к нему я так и не получил...

Изменено 7 Февраля 2015 пользователем Viнt@rь

[Viнt@rь 50]

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

Пересмотрел вот только что класс Location, когда делал скриншот, еще раз убедился, что класс довольно таки не маленький... Разве это рационально использовать увесистый класс, из которого мне понадобится всего лишь 2 значения?

 

ЗЫ Конечно, как вариант, написать свой класс/структуру с этими двумя переменными, широтой и долготой и сопутствующими им методами...

 

Эм... ну вроде как написали уже: нет "правильного", есть различные подходы.

Ну тогда наверное не правильный, а более рациональный что-ли...

 

Я предлагаю, чтобы вью содержала в себе весь функционал, который бы настраивался. Как, в принципе, ты и хотел делать.

Честно - я уже запутался немного Изначально было сделано, как в первом варианте, то есть исходя из условия... Вопрос чисто для уточнения/справки, "Как ты и хотел" имеется ввиду второй вариант, с наследованием и переопределением и прочим, верно?

 

Скажу по секрету - это венгерка И что значит "общепринятые"?

Поправил свой пост, который выше, согласен, немного перегнул, это все же венгерка, вернее ее очень малая часть(да и по крайней мере для Android все же так принято). По отношению к методам и другому применяется CamelCase

Изменено 7 Февраля 2015 пользователем Viнt@rь

[Viнt@rь 50]

Я бы сначала написал приложение полностью, чтобы работало, а потом уже проводил рефакторинг

Оно уже написано и работает, ежедневно не менее 10000 юзеров онлайн одновременно, потому и занялся рефакторингом и оптимизацией, ибо тогда писалось все в спешке, и сейчас, в очередной раз просматривая код, решение "исходя из условия" показалось мне немного костыльным... 

 

И еще бы забил на то, что Location это целый класс с горой полей...

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

 

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

Вот потому и отписал сюда, так как интересно мнение еще других программистов... Мне вроде как и без разницы, исходя из условия, либо переопределением... В первом варианте, условия в классе, лишний метод и тд., которые "режут глаз". Во втором - получаем дополнительные(лишние?) файлы/классы...

Изменено 7 Февраля 2015 пользователем Viнt@rь

[Viнt@rь 50]

 

 

Выглядит, эм, несколько странно в java, верблюд мастхэв.

может и "верблюд", но "глаз не режит", и вполне приятно читать такой код

 

 

 

Ааа, любимая IDEA с dracula.

Именно лучше среды разработки, чем Intellij IDEA(ну и всего, что на ней базируется) не встречал