Господа, день добрый. Извечный вопрос "как назвать переменную", в моем случае - есть класс для работы с базой, с redis, с внешним api (несколько внешних сервисов). В какую папку это обычно всё кладется, при условии, что у меня веб-апп (на flask, в котором никаких ограничений на фантазию разработчика)?

понятно что я могу положить всё в сферическую папку services\utils, но интересует мнение более опытных коллег

Господа, день добрый. Извечный вопрос "как назвать переменную", в моем случае - есть класс для работы с базой, с redis, с внешним api (несколько внешних сервисов). В какую папку это обычно всё кладется, при условии, что у меня веб-апп (на flask, в котором никаких ограничений на фантазию разработчика)?

а где интерфейс у тебя лежит?

а где интерфейс у тебя лежит?

нет интерфейсов (простой проект на python, где обычно предпочитают без интерфейсов и абстракций)

есть банальный controller (view в терминологии django\flask), есть service-класс который выполняет свою простую логику (несколько service-классов, если логика разная) и возвращает обратно в контроллер

я бы сделал какой-то Storage Interface и мб App\Database\Redis или App\Support\Facades\Redis хз

я бы сделал какой-то Storage Interface и мб App\Database\Redis или App\Support\Facades\Redis хз

ок, а если есть обращение к внешнему сервису (например, api, чтобы подгрузить прогноз погоды)?

namespace App use App\Database\Redis; class WeatherCrawler { ... }

namespace App use App\Database\Redis; class WeatherCrawler { ... }

вопрос, в какую папку обычно это всё кладется - в данном случае WeatherCrawler

в данном в App, насколько это правильно хз. На почитай авось вдохновишься https://gist.github.com/fesor/76d39b19b18f7103a7c058301dc6a8fe ну и пару слов за DDD можешь глянуть

в данном в App, насколько это правильно хз. На почитай авось вдохновишься https://gist.github.com/fesor/76d39b19b18f7103a7c058301dc6a8fe ну и пару слов за DDD можешь глянуть

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

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

плохо представляю что именно вызывает проблемы с хранением пароля в открытом видел - просто делаешь PLainPasswordHasher или что там есть

и все работает

есть мнение что ты просто не до конца понимаешь смысла этих абстракций

а еще есть мнение что хранение пароля пользователя в открытом видел - очень плохая идея либо это не пароль

хранить пароль в открытом виде в 2017, отличная идея.

нет интерфейсов (простой проект на python, где обычно предпочитают без интерфейсов и абстракций)

- там нет интерфейсов, в принципе. Абстракции там делаются чуть по другому. За счет классов без реализации + множественное наследование для ISP - абстракции и прочие solid-ы там все так же в чести.

подобное суждение может быть только в ситуации если ты плохо понимаешь суть абстракций

а еще есть мнение что хранение пароля пользователя в открытом видел - очень плохая идея либо это не пароль

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

- там нет интерфейсов, в принципе. Абстракции там делаются чуть по другому. За счет классов без реализации + множественное наследование для ISP - абстракции и прочие solid-ы там все так же в чести.

Ок, а как же abc, который есть в стандартной библиотеке?

подобное суждение может быть только в ситуации если ты плохо понимаешь суть абстракций

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

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

Привет всем. Правильно ли я понимаю, что при отказе от анемичных моделей мы вместо $fileStorage->upload($file) пишем $file->uploadTo($fileStorage)? Проблема в том, что file может храниться как удалённо (в БД - remoteUrl), так и локально (в БД - relativeUrl). То есть для локальных файлов нужно откуда-то достать абсолютный путь к файлу.

второй вариант хорош еще и тем, что ты как пользователь file знаешь, что с ним можно делать(uploadTo)

f

Привет всем. Правильно ли я понимаю, что при отказе от анемичных моделей мы вместо $fileStorage->upload($file) пишем $file->uploadTo($fileStorage)? Проблема в том, что file может храниться как удалённо (в БД - remoteUrl), так и локально (в БД - relativeUrl). То есть для локальных файлов нужно откуда-то достать абсолютный путь к файлу.

Здесь скорее всего профит в том что твой код который будет сохранять файл будет вызывать метод у storage, если тебе нужно будет сохранить файл как то по другому то может понадобится изменить этот метод, а так ты просто передаёшь ссылку на storage в файл, а сам файл уже вызывает нужный метод у storage т.е. сохраняет себя. Хотя там может быть то же самое вроде uploadTo(FileStorage storage) { storage.upload(this); } Как по мне не очень хороший пример

Здесь скорее всего профит в том что твой код который будет сохранять файл будет вызывать метод у storage, если тебе нужно будет сохранить файл как то по другому то может понадобится изменить этот метод, а так ты просто передаёшь ссылку на storage в файл, а сам файл уже вызывает нужный метод у storage т.е. сохраняет себя. Хотя там может быть то же самое вроде uploadTo(FileStorage storage) { storage.upload(this); } Как по мне не очень хороший пример

но при этом клиенту этих классов уже не важно какие методы будут у storage и будут ли они вообще, клиенсткий код будет передавать storage в file

Привет всем. Правильно ли я понимаю, что при отказе от анемичных моделей мы вместо $fileStorage->upload($file) пишем $file->uploadTo($fileStorage)? Проблема в том, что file может храниться как удалённо (в БД - remoteUrl), так и локально (в БД - relativeUrl). То есть для локальных файлов нужно откуда-то достать абсолютный путь к файлу.

вот получше пример http://www.yegor256.com/2016/04/05/printers-instead-of-getters.html

Спасибо за ответы. Да, идея доверять объектам мне нравится. Тогда такой вопрос - в сущности файл хранится только локальный путь вроде /folder/filename.ext, как мне в ней получить полный путь к файлу? В документации к фреймворку советуют навесить какой-то слушатель, который при извлечении сущности из БД будет автоматически пропихивать в свойство $absolutePath полный путь к файлу. Но мне эта идея не нравится - для absolutePath нужен сеттер. ORM - Doctrine (сделана по примеру Hibernate)

Спасибо за ответы. Да, идея доверять объектам мне нравится. Тогда такой вопрос - в сущности файл хранится только локальный путь вроде /folder/filename.ext, как мне в ней получить полный путь к файлу? В документации к фреймворку советуют навесить какой-то слушатель, который при извлечении сущности из БД будет автоматически пропихивать в свойство $absolutePath полный путь к файлу. Но мне эта идея не нравится - для absolutePath нужен сеттер. ORM - Doctrine (сделана по примеру Hibernate)

А зачем тебе полный путь к файлу?

FileStorage будет брать файл по этому пути и аплоадить его куда-то (на дропбокс либо яндекс диск, это уже неважно)

FileStorage будет брать файл по этому пути и аплоадить его куда-то (на дропбокс либо яндекс диск, это уже неважно)

ну так замени относительный на абсолютный

В БД хранить абсолютный путь?

В БД хранить абсолютный путь?

Не зная остального контекста, почему бы и нет?

А какой контекст интересует? Хранение абсолютного пути к файлу в БД в будущем обернётся неудобствами с переносом сайта в другое место.

Кстати, фабрики для сущностей: https://packagist.org/packages/dittto/doctrine-entity-factories - по-видимому, то, что мне нужно.

А какой контекст интересует? Хранение абсолютного пути к файлу в БД в будущем обернётся неудобствами с переносом сайта в другое место.

uploadTo(FileStorage storage) { String absolutePath = this.getAbsolutePath(); storage.upload(absolutePath); } Можно изменить это в методе сохранения файла, как то получить абсолютный путь из относительного и уже storage передавать не сам файл, а путь например.

Где можно прочитать про стили ООП которые сейчас самые популярные и используются на работе?

Где можно прочитать про стили ООП которые сейчас самые популярные и используются на работе?

что значит "стили ооп"?

Это стандарты psr? Или как нпзываются правильно

Где можно прочитать про стили ООП которые сейчас самые популярные и используются на работе?

SOLID, GRASP ?

Ну ООП можно использовать же по разному. Можно с пространством имен с интерфейсами и обстрактными классами и прочее, еще какая-то автозагрузка классов и прочее что не назвал. И хотелось бы узнать что на работе используют и вообще термин этого стиля

Ну ООП можно использовать же по разному. Можно с пространством имен с интерфейсами и обстрактными классами и прочее, еще какая-то автозагрузка классов и прочее что не назвал. И хотелось бы узнать что на работе используют и вообще термин этого стиля

это не про ООП все, но в контексте PHP да, ориентируйся только на psr

SOLID, GRASP ?

В краце читал но не много. Это psr стандарты? Или что

там все остальное уже экзотика

В краце читал но не много. Это psr стандарты? Или что

ты точно читал?)

В краце читал но не много. Это psr стандарты? Или что

что такое psr?)

и помни - "ООП" это не про классы

Пару предложений и довил в закладки статьи)

что такое psr?)

похапэшные рекомендации, типа пытались запилить аналог pip

Пару предложений и довил в закладки статьи)

короч, то о чем ты интересуешься - читай psr. Но это не про ООП. Это можешь про структурное программирование погуглить и про модули

А тот же psr там всякие psr2 psr4. Последнюю версиб читать или в каждой конторе своя используется?

А тот же psr там всякие psr2 psr4. Последнюю версиб читать или в каждой конторе своя используется?

.........почитай все. Они РАЗНЫЕ

и про разное

Ок)

psr-6 про кэш, psr-7 про http и т.д

А solid grasp dry это все рекомендации как использовать ООП?

А solid grasp dry это все рекомендации как использовать ООП?

это принципы, а не рекомендации. Тебе еще рано такое

всеравно недочитаешь и не поймешь

http://www.phptherightway.com/

на вот читай

и да - для вопросов по php есть отдельный чатик

у тебя вопросы пока не про ООП

так что...

А про ооп какие задавать?)

А про ооп какие задавать?)

что такое ООП для начала разберись, уже жирный топик будет)

Ну в целом. Какие практики еще почитать чтобы повысить свою квалификацию чтобы мог спокойно работать в команде

Ну в целом. Какие практики еще почитать чтобы повысить свою квалификацию чтобы мог спокойно работать в команде

вот я тебе ссылку дал - там есть все

вообще все что тебе на данном этапе стоит читать

Ок спс за комп сяду почитаю)

Еще кусы по ООП нашел на торрентах. Там как раз манические методы psr и все такое. Дмитрий Синельников или как-то так. Годные, стоит смотреть для экскурса или ерунда?

Еще кусы по ООП нашел на торрентах. Там как раз манические методы psr и все такое. Дмитрий Синельников или как-то так. Годные, стоит смотреть для экскурса или ерунда?

понятия не имею но 90% что ерунда

Там 7 видео по 3-4 часа

Там 7 видео по 3-4 часа

да хоть 100 по 10-ть.

> манические методы psr и все такое. иди с подобным в php чат будь добр

Ок

Еще кусы по ООП нашел на торрентах. Там как раз манические методы psr и все такое. Дмитрий Синельников или как-то так. Годные, стоит смотреть для экскурса или ерунда?

Мне в свое время как совсем нубу помог Stepic, там сейчас полно курсов (java, c++, python, всё с основами ООП), но тебе для усвоения обязательно надо выполнять все практические задания без использования гугла.

Кто что думает о дружественных классах? Увидел чт в пыхе хотят реализовывать и подумал юзал ли кто в других языках и вообще где это есть?

В C++ есть

+ интересно, звучит как жесть, прост.

В некотором роде есть в Java (nested classes)

как часто юзается? и когда?

Ну возможно удобно для композиции в некоторых случаях...но инкапсуляция к хуям летит как я понял))

Редко используется. Как правило в тех случаях, когда очень хочется обойти запреты private/protected.

просто зачем создавать эти запреты, если нужно использовать... Хотя мб в единичных случаях

Ну возможно удобно для композиции в некоторых случаях...но инкапсуляция к хуям летит как я понял))

Это (про "улет") - довольно спорное утверждение. Если мы говорим "метод x() - публичный, его может использовать кто угодно" - это вроде как инкапсулированно; вот с friend class мы можем сказать "метод x() может использовать лишь определенный класс (не кто угодно)" - это как будто бы... еще более инкапсулированно?