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

[Dennis_Chikin 3 658]

Судя по регулярно происходящему в других темах - таки нужна.
Вот здесь как раз можете спросить про "зачем создали эту тему ?"

 

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

 

Но таки да, пп 2.0, 2.1 и даже 2.5 правил здесь вполне таки действуют.

Изменено 30 Января 2015 пользователем Dennis_Chikin

[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ь

[Desertir 202]

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

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

---

@Viнt@rь, я тогда не очень понимаю, что там и как у тебя, тогда уж не буду глупости советовать Изменено 7 Февраля 2015 пользователем Desertir

[Viнt@rь 50]

 

 

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

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

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

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

[Allender 11]

@Viнt@rь, 

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

 

 

class Position() {
    private double[] finalLocation;
    private double[] currentLocation;
    private boolean arrived = false;

    public Position(double lat, double lon) {
        finalLocation = new double[] {lat, lon};
    }

    public void setPosition(doulbe lat, double lon) {
        currentLocation = new double[] {lat, lon};
        if (currentLocation[0] == finalLocation[0] &&
            currentLocation[1] == finalLocation[1]) {
            arrived = true;
        }
    }

    public boolean isArrived() {
       return arrived;
    }
}

// в диалоге
Position position = new Position(10.0, 10.0);
// если местоположение изменилось 
position.setPosition(location.getLatitude(), location.getLongitude());
// прибыли на место?
if(position.isArrived()) {
   ...
}

 

 

 

 

 

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

Метод можно написать в том же классе. Или нужно что-то другое?

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

[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ь

[Allender 11]

@Viнt@rь, 

"Так вот как его готовить нужно!"

Базовый класс с логикой диалога. Два наследника, один из которых реализует показ кнопки с методом получения координат, а во втором показываем финальный результат.

Если на примере JComponent, там просто переопределяется метод paintComponent(), чтобы задать свою отрисовку. По-аналогии сделать содержимое диалога. Так не подойдет?

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

[Viнt@rь 50]

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

 

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

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

[xStream 86]

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

Это ужасно...

 

Вот выше приведенное в пример, показалось мне костылем

А что мешает использовать тот класс, объектом которого является location? Не придется ничего присваивать. 

 

mSettings.setCurLatitude(loc.getLatitude()); 
mSettings.setCurLongitude(loc.getLongitude())

Фиг с ней, с венгеркой, но почему, блин, координаты раздельно то?

 

 

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

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

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

[Malandrinus 615]

 

 

Как эффективнее, так и лучше

А критерий эффективности какой?

[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ь

[xStream 86]

пусть и на несколько байт, но все же

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

 

 

Это не венгерка,

Скажу по секрету - это венгерка И что значит "общепринятые"? Я умоляю, пруф в студию. Как минимум к любому языку существует огромное количество code guideline'ов.

 

 

А критерий эффективности какой?

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

 

 

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

Эм... ну вроде как написали уже: нет "правильного", есть различные подходы. Я предлагаю, чтобы вью содержала в себе весь функционал, который бы настраивался. Как, в принципе, ты и хотел делать. Изменено 7 Февраля 2015 пользователем xStream

[Viнt@rь 50]

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

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

 

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

 

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

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

 

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

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

 

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

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

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

[Desertir 202]

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

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

---

В таком случае я бы ничего не трогал, раз все его используют и все ок Ну это немного шутки. А в том, что ты изменяешь поведение окошка исходя из условия, что такого костыльного? В продакшене и похлеще бывает. Изменено 7 Февраля 2015 пользователем Desertir

[Viнt@rь 50]

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

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

 

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

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

 

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

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

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

[Allender 11]

 

 

Скажу по секрету - это венгерка И что значит "общепринятые"? Я умоляю, пруф в студию.

 

это все же венгерка, вернее ее очень малая часть

Точнее, основная идея венгерки.   Выглядит, эм, несколько странно в java, верблюд мастхэв. Да и Сode Conventions дает однозначную рекомендацию:

 

Naming
If the name you choose consists of only one word, spell that word in all lowercase letters. If it consists of more than one word, capitalize the first letter of each subsequent word. The names gearRatio and currentGear are prime examples of this convention. If your variable stores a constant value, such as static final int NUM_GEARS = 6, the convention changes slightly, capitalizing every letter and separating subsequent words with the underscore character. By convention, the underscore character is never used elsewhere.

 

 

@Viнt@rь,

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

 

@xStream, 

А можно по наглеть, попросить небольшую заметку по разработке проектов написать? Как нужно, как не можно делать, как принято.)

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

Или в книжку тыкнуть носом. 

[Desertir 202]

заметку по разработке проектов написать

А что конкретно то? Это по-моему уж слишком абстрактно. Под какую платформу проект, в чем смысл...

Разработка десктопного бизнес-приложения? Скорее всего подойдет .NET и скорее всего языком разработки будет C# + какой-нибудь SQL, а может VB, а если веб, то сверху еще шаблон MVC и клиентский JavaScript.

"Легкий" веб? Можно PHP+MySQL, но я ни за что не буду на пыхе писать. Можно Node.JS.

А может быть просто нужен ГУИ - WinForms и вперед, Если конечно не приверженец C++, но есть C++/CLI.

Создание мобильного приложения? Опять же, нужна платформа, там может быть и C# и Java и Swift (что там еще?).

Хотим игрулю запилить? Загнувшийся XNA, а может двиг на уже C++ (их очень много), а может свое производство.

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

 

Всегда нужна конкретика, никаких "допустим", а то пойдут нереальные примеры как пару страниц назад про танцы и ивенты

Я уж молчу про различные Ф# Хаскелы Лиспы Перлы, они тоже используются и для иных проектов.

[Viнt@rь 50]

 

 

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

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

 

 

 

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

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

[Allender 11]

@Desertir, 

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

Я вот про что, если перечитать тему, можно набрать с десяток "советов" как не нужно делать. Вот это было бы интересно.)

[Desertir 202]

Кто задумывался о стиле кода в скриптах? Везде используется змея (моя_переменная_самая_крутая), но ведь экспортированные вещи написаны в другом "обрезанном" верблюжьем стиле (КИОкна::МояМногоЗадачнаяФункция). Как бы по хорошему надо писать в едином стиле. Пусть двиг и скрипты это разное, но тем не менее экспорт функций мог быть и в нужном стиле.

Так вот что лучше, переписать экспорт в змеиный стиль или переписать скрипты под верблюда?

1. Змея. Надо лезть в двиг, надо переписать многие вызовы для разных "неверно" экспортированных классов и функций в скриптах, но в скриптах будет чистый стиль.

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

[abramcumner 1 146]

Вообще-то экспортрованные вещи написаны и так и так:

змея: game_object, биндер, серверные классы(за исключением имен )

верблюд: уи-классы и прочее

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