• Является ли хорошим тоном постоянно использовать много методов/функций?

    IonDen
    @IonDen
    JavaScript developer. IonDen.com
    Лучше всего выносить, это хорошая практика выносить разный код в отдельные функции. Потом и читать удобнее и рефакторить и что угодно.
    Ответ написан
    Комментировать
  • Какой вариант изучения C++ выбрать?

    Denormalization
    @Denormalization
    Во-первых conio.h и process.h это Си, а не С++
    Во-вторых они ниразу не из стандартной библиотеки
    В-третьих в линуксе как бы всё немного подругому, и поэтому стоит получше изучить стандартную библиотеку.
    Ответ написан
    Комментировать
  • Какова роль интерфейсов в ООП?

    Много ответов есть уже, лучше попробую идти рядом с вашими словами. Итак,
    > Зачем мне создавать файл, контролирующий это, если я и сам могу контролировать то, какие методы у меня есть
    Вы - это ваша голова, вы человек, не робот, ваш может не быть на работе например, или вы сами можете забыть, как у вас взаимодействуют части системы. Интерфейсы - это в общем-то тоже документация. И не нужно строго различать "чисто интерфейсы", и интерфейсы класса - те методы, которые у класса паблик - это точно такой же интерфейс, только он явно не отделен от класса. Когда у класса всего 3-4 метода, и все они связаны простой идеей, то и выделять ничего не надо. Когда у класса уже 10 методов, и среди них есть небольшие смысловые группы, то уже имеет смысл эти группы подчеркнуть. И, в конце концов, вместо каши из 10 методов, вы читаете следующее: class Graph : IEnumerable, IIndexable, IDrawable - и вы знаете, что ваш граф перечисляется, индексируется и рисуется. Это уже очень много информации, вы уже понимаете, как взаимодействуют части вашей системы.

    > Может создано это для работы в больших коллективах? Но ведь тогда любой участник сможет поправить и интерфейс.
    Да, совершенно верно, для больших коллективов. Нет, участник просто так не сможет поправить интерфейс, не побеседовав с остальными. В лучшем случае участнику придется поправить весь код, который "висит" на этом интерфейсе, в худшем - он в принципе ничего не сможет поменять, если интерфейс "публичный" и используется несколькими командами разработчиков. Классический пример - системы плагинов. Если к MS Word-у уже написано куча плагинов, то MS не может взять и просто так поменять ифейсы, не поломав совместимость. Хотя некоторые аспекты реализации - может. Потому что, как уже сказали выше, интерфейс - это ДОГОВОР. Чем БОЛЕЕ он стабилен, тем ЛУЧШЕ. Команды договариваются (!), создавая интерфейсы, чтобы потом было как можно МЕНЬШЕ конфликтов и разногласий, т.к. проблемы с интерфейсом затрагивают всех. Найдите любую команду от 30 человек, и вы увидите, насколько это все важно.

    Еще две вещи напоследок:
    1) интерфейсы из ОО языков лишь частный пример понятие интерфейса в жизни вообще. Вы же, когда покупаете SATA-диск, наверное рассчитываете, что сможете его подключить к своему компу? А с чего вы взяли? А, ну конечно, ведь на упаковке написано SATA - значит производитель соблюдает ДОГОВОР - интерфейс передачи данных;
    2) необходимость в некоторых фичах языков сложно осознать в личных проектах и даже в маленьких командах. Это тоже как в жизни: свой дом, как говорится, должен построить каждый мужик, а чтобы построить бизнес-центр или высотку, нужны определенные знания, т.к. другие масштабы. Это нормально. Тем не менее, нужно читать и искать примеры. Хотя современные ОО-языки и сами дают много примеров. Раз у вас PHP, почитайте про Iterator например.
    Ответ написан
    1 комментарий
  • Какова роль интерфейсов в ООП?

    Приведу пример на коленке. Хотим, например, написать абстрактную файловую систему. Для начала, определим интерфейс, для ФС:

    interface FileSystemInterface {
      public function write($file, $data);
      public function read($file);
    }


    Затем, хочу реализацию интерфейса ФС для работы с файликами:

    class OSFileSystem implements FileSystemInterface {
      public function write($file, $data) {
         // открываем файлик, пишем данные
      }
    
      public function read($file) {
        // открываем файлик, возвращаем данные
      }
    }


    Вдруг, кому-то захотелось файловую систему в облаке. Окей, не проблема, реализуем это:
    class CloudFileSystem implements FileSystemInterface {
      public function write($file, $data) {
         // открываем соединение с облаком, пишем данные
      }
    
      public function read($file) {
        // открываем соединение с облаком, возвращаем данные
      }
    }

    Пусть у нас есть кой-то код, работающий с файловой системой, назовем его "Хранилище файлов". Пусть он выглядит примерно так:

    class FileStorage {
      protected $Fs;
      
      public function __construct(FileSystemInterface $Fs) {
        $this->Fs = $Fs;
      }  
    
      public function saveFile() {
        $this->Fs->write('file.txt', 'file data');
      }
    
      public function getFile() {
        return $this->Fs->read('file.txt', 'file data');
      }
    }


    Отлично! Теперь мы можем хранилищу файлов отдать любой объект с реализованным интерфейсом FileSystemInterface. Пример:

    // Хранилище файлов работает с файловой системой ОС:
    $FS = new OSFileSystem();
    $FileStorage = new FileStorage($Fs);
    $FileStorage->getFile();
    
    // Хранилище файлов работает с файловой системой в облаке:
    $FS = new CloudFileSystem();
    $FileStorage = new FileStorage($Fs);
    $FileStorage->getFile();


    Использование интерфейса, в данном случае. позволяет нам писать только реализацию работы файловой системы, а бизнес-логика, работающая с файловой системой никак не меняется, она знает, что в любом случае файловая система реализует интерфейс FileSystemInterface и может без опаски использовать методы этого интерфейса.
    Ответ написан
    14 комментариев
  • Реально ли выучить английский язык, только лишь слушая английскую речь?

    uvelichitel
    @uvelichitel
    habrahabr.ru/users/uvelichitel
    Русский вы же не по учебникам учили. Но слушать мало - кино смотреть, книжки читать и говорить, писать если найдете кому.
    Ответ написан
    Комментировать
  • С чего лучше начать изучать ООП?

    Vestail
    @Vestail
    Software Engineer
    В который рас кидаю ссылку, книги по дизайну и ООП.
    Ответ написан
    Комментировать
  • Как составить математическую модель?

    gbg
    @gbg
    Любые ответы на любые вопросы
    Моделирование транспортных потоков бывает имитационное (гидродинамическое) и автоматное. В первом случае, сеть дорог рассматривают как сеть труб с жидкостью и течением, во втором случае - как конечный автомат (близкий пример - "Жизнь" Конвея).

    В качестве старта в математическое моделирование рекомендую таких авторов:
    Пирумов У. Г. (нет, не фантаст) "Численные Методы"
    Бахвалов, Жидков, Кобельков "Численные Методы"
    Самарский, Михайлов "Математическое моделирование"
    Ferziger, J. H. and Peric, M., Computational Methods for Fluid Dynamics, 2nd ed., Springer-Verlag (2001). ISBN 978-3-540-42074-3.
    Ответ написан
    Комментировать
  • Какой профит получают разработчики крупных open source библиотек и фреймворков?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Спонсоры, коммерческие лицензии, суппорт... Чем крупнее опенсурс проект - тем больше способов сделать его окупаемым.
    Ответ написан
    Комментировать
  • Каково влияние высшего образования на карьеру предпринимателя?

    tuccar
    @tuccar
    Образование очень важно и очень вам советую получить высшее образование.
    Не забывайте, все, на чем вы ездите (поезда, самолеты, автомобили), все, чем вы поддерживаете свою жизнь (больницы, аптеки, магазины, другие учреждения) - вся инфраструктура создана людьми через высшее образование. Все нормы проектирования чего бы то ни было было создано через высшее образование. А все эти мысли о том, что можно прожить и без высшего образования, это мысли тех, кто всего лишь пользуется результатами деятельности высшего образования. Все, кто не любит высшее образование, хорошо сидят на том, что спроектировано высшим образованием. М-да..
    Ответ написан
    Комментировать
  • Каково влияние высшего образования на карьеру предпринимателя?

    EndUser
    @EndUser
    ВУЗ показывает историю развития человеческих мысли и опыта что заставляет мозг реже изобретать велосипеды, чаще изучать предыдущие, текущие и конкурентные наработки, с уважением относиться к чужому опыту, вырабатывает навыки сбора и анализа информации.

    ВУЗ показывает междисциплинарные взаимосвязи, заставляющие мозг работать более широко, выявлять в реальной жизни неожиданные параллели и нетривиальные решения. Человек перестаёт выдавать на гора наивные суждения о философии, политике, жизни, перспективах...

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

    В конце концов, ВУЗ показывает множество характеров и персонажей, и едва ли не каждый второй является экспертом в чём-то, чаще дипломированным и сертифицированным, что заставляет и считаться с ними, и заимствовать их знания и методики, и вырабатывать разнообразные линии общения.

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

    Думаю, что родители правы: честно заработанный диплом - это определённая планка в голове, ниже которой человек себе не позволяет опускаться. Да и лишняя бумажка тоже не помешает. Тем более, если работодатель знает, что даёт именно обучение в ВУЗе и ещё знает каковы работнички, лишённые такого обучения.

    Так что идите на вечерний факультет хотя бы - чтобы хоть как-то в среде вращаться.

    P.S. Везде есть исключения - есть и тупые выпускники (немало), и очень разумные и толковые "без-вышки" (мало).
    Ответ написан
    3 комментария
  • Каким должен быть собственный проект для устройства на работу?

    uvelichitel
    @uvelichitel
    habrahabr.ru/users/uvelichitel
    Коммиты в серьезные опен-сорс проекты гораздо убедительней игрушечной самоделки(по крайней мере для меня)
    Ответ написан
    3 комментария
  • Каким должен быть собственный проект для устройства на работу?

    5angel
    @5angel
    Фронтенд-лид
    Свои проекты показывать можно и нужно. А лучше всего – не просто показать, а рассказать о том, как шла разработка, с какими проблемами вы столкнулись и как их решали. Если вы таким образом хотите повысить свои шансы на получение работы, то проект должен показать, что вы хорошо владеет предметом как с теоретической, так и с практической точки зрения. Я говорю здесь даже не о Ruby, интересные вещь можно написать на любом языке.

    На что нужно обратить внимание:
    Архитектура. Грамотно спроектированная система – залог успеха всего предприятия.
    Производительность. Здесь можно показать как алгоритмическую подготовку и умение работать с базами данных, так и знание особенностей конкретного языка.
    Тестирование и документация. Покрытие тестами и описание функционала, начиная от основных модулей и заканчивая отдельными функциями – тот идеал, которого стараются (но не могут) достигнуть во всех уважающих свою разработку компаниях.

    Если у коллег есть какие-либо дополнения, прошу (:
    Ответ написан
    11 комментариев
  • Какие языки программирования наиболее востребованы в игровой индустрии?

    copal
    @copal
    𝄞 ...оооо baby
    Судя по вопросу, Вы ещё не программист, по этому вот -
    Если бы Вы спросили "какие языки учить, чтобы делать сайты и что для этого нужно", то получили бы стандартный ответ - "html5 + css3 + js + php + angular + lareval". И да, это был бы правильный ответ, так как этого достаточно. Всякий раз, при посещении какого-либо сайта, когда у Вас возникал вопрос - "как это сделать", получали ответ - "вот готовое решение, не тратьте время на сооружения велосипеда".
    Согласитесь, как все просто?

    А вот как дела в gemdev'у -
    Физика - да, существуют готовые физические движки, но это "автомобиль", который принесет пользу тем, кто имеет "водительские права" или сломает его разум. Так же для мобильных платформ физ. движки очень тяжелые, по этому нужно писать все законы физического мира - самому.
    Анимация - Вы должны понимать её работу так, словно узнали Вы о ней в раньше чем родились.
    Но на самом деле нужна она не так часто, что не означает, что Вас будет ждать коллектив, пока Вы точную траекторию кривой Безье третьего порядка рассчитаете.

    Я сказал "рассчитать"? Да, это Вам нужно делать на уровне школьного золотого медалиста.
    Уравнения, геометрия, алгебра, ранее упомянутая физика... И думаете это все?
    Нет, потому-что ещё есть же отображение!
    Вы должны разбираться в цветах лучше художника, должны уметь создавать различные эффекты с применением не самопридуманных технологий, а с вполне естественными для всего мира алгоритмами. Их очень много. А алгоритмы поиска путей и прочих столкновений?
    Да, есть много готового, даже можно сказать, что уже все создали.
    Но настоящий gamedev'овиц, должен знать все.

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

    А язык, как Вам уже сказали, почти любой.
    Ответ написан
    1 комментарий
  • Несколько вопросов о вашем переезде в другую страну?

    @ivles89 Автор вопроса
    Я создал топик, первым напишу и ответ:

    1) Статус переезда
    - В принципе, хотел бы переехать

    2) Ваша cфера работы в IT.
    - Разработка бекенда на PHP и всё сопутствующее.

    3) Общий стаж работы в IT
    - 7 лет

    4) Из какой страны и в какую вы переехали / планируете переезд?
    - Я живу и работаю в Молдове. Думаю переехать в Германию.

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

    6) Самостоятельно или с супругой/супругом, детьми?
    - Планирую переехать со своей супругой. Детей у нас пока нет.

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

    9) Каковы причины переезда?
    - Причин много но их можно суммировать и выделить главное:
    A) Перспективы профессионального роста. Самое главное, что хотелось бы получить - опыт работы в развитой компании.
    Кроме того, Молдова - конкретное захолустье, здесь почти ничего в сфере IT не происходит. В Германии же часто проходят различные IT-шные конференции, стартап-инкубаторы и прочее. Всё это можно использовать в целях профессионального роста.
    B) Социальная защищенность, хорошая медицина. В Молдове ни того, ни другого не наблюдается. В случае чего серьезного, мягко выражаясь, е**... крутись как хочешь =) Государство тут функционирует очень слабо.

    - Добавлю ещё: у меня есть высшее образование по специальности "Информатика", что, в теории, может упростить получение работы в Германии.
    Ответ написан
    Комментировать
  • Несколько вопросов о вашем переезде в другую страну?

    opium
    @opium
    Просто люблю качественно работать
    1)е
    2)системное администрирование линукс, pumainthailand.com/diskussiya-o-frilanse-i-odeske-...
    3)до переезда 5 лет сейчас 9
    4)россия тайланд
    5)получил паспорт, бросил работу, стал фрилансером, занял сто тысяч рублей, переехал.
    6)самостоятельно
    7)в офисе техдиректор
    8)2-3 тысячи долларов.
    9)Спонтанно
    10)в 2011
    11)фриланс удаленно
    12)0-6000 долларов.
    13)Очень доволен, тепло, дешево, душевно.
    Ответ написан
    1 комментарий
  • Как стать linux-user?

    vvpoloskin
    @vvpoloskin
    Инженер связи
    А как вы стали windows-пользователем? Точно также и с linux
    Ответ написан
    3 комментария
  • Выбор функционального языка программирования?

    Tyranron
    @Tyranron
    Если под "функциональным" подразумевается функциональная парадигма, то Go тут явно аутсайдер. Советую Haskell для ознакомления с парадигмой фактически в "чистом" виде. После него - Scala и/или Rust, как удачные смешения функциональной парадигмы с другими парадигмами/направлениями. И не забудьте повертеть Erlang.

    Если же под "функциональным" подразумевается удобный инструмент с многими возможностями из коробки, то тут однозначно Go, так как и порог вхождения мал, и прививает хорошие практики. После него Scala + FRP + TypesafeStack тоже должны показаться интересными, но там порог вхождения повыше будет.
    Ответ написан
    Комментировать
  • Какие языки помогут лучше всего понять указатели и рекурсии?

    @endemic
    Указатель - С
    Рекурсия - любой
    Ответ написан
    Комментировать
  • Должны ли конструкторы подклассов быть приватными при реализации синглтона?

    @DancingOnWater
    Есть классический singleton-класс. От него наследуются другие классы. Вопрос: должны ли эти классы точно так же реализовывать логику паттерна (т.е. через getInstance), или их-то как раз можно создавать классическим образом через new?

    Если вы наследуетесь от синглетона, значит вы хотите. чтоб эти классы были тоже синглетонами. Тогда ответ очевиден - да.
    Если же вы не хотите, чтоб классы были синглетонами, значит вам не надо наследоваться и тогда ответ -нет.

    Как вариант, корректен ли и хорош ли с точки зрения чистоты и красоты программирования создать в родительском классе переменные по типу инстанса:
    public static $_controller;
    ...и после, создавать их в наследуемом классе:
    parent::$_controller = new self;
    Чтобы таким образом иметь экземпляры подклассов, сконцентрированных в едином главном классе?

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

    Похоже вы хотите что-то страшное. Поясняю.
    Обычно в ООП программировании программа строится на классах, имеющие несколько экземпляров. Этим достигается инкапсуляция, повторное использование кода и потокобезопасность. Синглетон, с одной стороны, это обычный класс, но имеющий на всю программу один экземпляр.
    Чрезмерное их количество легко нарушит инкапсулированность, создаст проблемы в многопоточности и повторном использовании кода, дальше все будет только хуже.
    Ответ написан
    1 комментарий
  • Должны ли конструкторы подклассов быть приватными при реализации синглтона?

    Эммм.. Классический синглтон не может быть отнаследован. У него приватный конструктор. Разве нет? habrahabr.ru/post/31375
    Ответ написан
    5 комментариев