Binary Digit

Паттерн объектно-оринтированного программирования "Одиночка" (Singleton). В чем смысл? Как реализован? Решил написать небольшой цикл постов, посвященных паттернам объектно-ориентированного программирования. Если вам интересна эта тема и вы хотите узнать больше - то рекомендую к прочтению книги "Design Patterns" за авторством Банды Четырех и "Head First Design Patterns" за авторством еще четырех людей :) Для людей, совсем не знакомых с шаблонами проектирования, коротко скажу, что они являются всего-навсего проверенными временем идиомами, которые позволяют писать качественный с точки зрения дизайна код, который понятен другим людям. Итак, начнем. Представьте, что у вас есть набор данных, а также функций для манипуляции этими данным. Тут вам сразу захочется объединить все это в класс (это ведь одна из основных идей ООП). Отлично, но что если семантически может существовать один и только один объект данного класса на всю программу. Например, он является владельцем какого-то уникального аппаратного ресурса. Тогда появляется необходимость контролировать создание объекта данного класса и следить, чтобы этот объект был уникальным. Тут-то и был придуман паттерн "Одиночка". Так, требование есть - осталось выразить его в коде. Один из основных подходов заключается в следующем: 1) Сделать конструктор "одиночки" приватным, чтобы его нельзя было создать явно. 2) Добавить в класс публичную статическую функцию (назовем Get), тело которой будет содержать определение статической переменной типа "одиночка", а также возвращать ссылку на эту переменную. 3) Обращаться к полям "одиночки", получая ссылку на единственный объект данного класса посредством вызова метода Get. Да, это, мягко говоря, может звучать запутанно, но пример все прояснит: class Singleton { public:    Singleton& Get()    {    static Singleton instance;    return instance;    }    void DoWork();    // other methods private:    Singleton()    {    // constructor logic    } }; int main() {    Singleton::Get().DoWork();    return 0; } Данный код гарантирует, что: 1) Создать объект класса Singleton в обход функции Get невозможно 2) Будет существовать только один экземпляр класса Singleton В следующих постах - больше паттернов. Все хорошего дня :)

C++ - сложный язык. Язык умеет много. Но те возможности, которые в нем реализованы, добавлялись постепенно, и вряд ли у разработчиков стандарта изначально был план создать язык таким, каким он является сейчас. Следствием сложности языка является наличие большого числа семантических правил, которые часто вводят в ступор не очень опытных (да и опытных тоже) программистов. Например, пусть есть следующий код: << class A { public: void foo(double i); private: void foo(int i); }; int main() { A a; a.foo(21); } >> Скомпилируется ли данная программа? Нет. И это вряд ли то поведение, которое ожидает программист. Ведь у класса A есть публичный метод A::foo(double), а число 21 может быть неявно приведено к типу double. Так что ожидаемое поведение - вызов метода A::foo(double). Однако программа не компилируется, и это происходит потому, что сначала происходит разрешение вызова функции (определяется наиболее подходящий кандидат из множества перегрузок), а после этого найденный кандидат проверяется на доступность (проверяется спецификатор доступа). И проблема в том, что метод A::foo(int) участвует в перегрузке, несмотря на то что является приватным. Для вызова a.foo(21) данный метод является лучшим выбором, но оказывается, что он недоступен. Поэтому код не компилируется. Да, на C++ пишут явно не те, кто ищет легкий путь :)

Как войти в IT? Что нужно знать? Основываясь на собственном опыте, могу выделить несколько контрольных точек, которые, как я считаю, необходимо пройти, чтобы получить работу разработчика. Хочу отметить, что это именно мой список. То есть он отражает путь, по которому шел я. Ваш путь может отличаться от моего. Однако, список, приведенный ниже, является более или менее общим, так что его можно считать более или менее объективным. Итак, вот список: • База по информатике. Без этого нет смысла изучать язык программирования. Необходимо иметь базовое представление об устройстве компьютера: как данные хранятся в памяти, как компьютер выполяет программы. Необходимо понимать смысл компьютеров как средств хранения и обработки информации, следовательно, должно быть представление о различных способах представления информации. • Язык программирования. Я бы рекомендовал начать с Си, даже если вам интересна область, которая не использует этот язык. Так как Си крайне близок к железу, то научившись писать программы на этом ЯП, вы получить хорошее представление об устройстве компьютерных программ и о работе самого компьютера. • Алгоритмы и структуры данных. Необходимо знать базовые алгориты и структуры данных и уметь хотя бы в виде псевдокода их реализовывать. Это позволит вам писать эффективные программы, а также читать программы, написанные другими людьми. • Многопоточное программирование. Его необходимо освоить, так как почти любое более или менее сложное приложение работает в несколько потоков, и необходимо уметь писать и читать соответствующий код. • Паттерны проектирования. Необходимо знать основные популярные паттерны, чтобы писать хорошо спроектированные приложения, а также понимать намерения других программистов. Повторюсь, это, по моему мнению, минимальный список необходимых знаний и умений, чтобы получить работу в IT и быть эффективные разработчиком. Конечно, на этом обучение не заканчивается, но о том, что изучать дальше, напишу в другом посте. Всем хорошего дня.

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