ООП в BGT

Автор статьи:
Igorek.

Приветы!
Почитав статьи, комментарии и посты на форумах, стал подозревать, что люди либо не используют ооп в bgt либо используют, но плохо понимают как это всё работает. Извините, если кого обидел, я просто хочу рассказать об этом, чтобы все могли полноценно кодить. Верю что это ещё актуально.
Сразу хочу сказать, что нужно понять теоретические моменты, так чтобы не путаться, и я начну с этого, но кратко.
Ооп позволяет описывать, создавать и использовать объекты в программе, это значит, что описав один раз птицу, мы сможем создать множество птиц по образцу или шаблону. Если бы не было ооп, то каждую птицу мы бы описывали отдельно, что черевато тоннами кода, и плохой читабельностью.
Итак, шаблон — это описательная часть объектов, в нем мы описываем свойства, которые должны быть, в нашем случае у птиц. Правильно шаблоны называются классами, очень надо четко понимать, что класс, это шаблон, а объект — это сущность созданная на основе класса.
В статье на сайте blind.games я прочёл, что люди это класс, а человек это объект. Это в корне не так, поэтому наверно вам сложно понять эту тему в программировании. Попробую объяснить.
Мы всё же будем операться на птиц. Вот есть птица, любая птица, если она есть в реальности, ну то есть вот она сидит на ветке, но мы не знаем что это за птица, то это объект, это сущность которая имеет признаки птицы, ну например, крылья, клюв. Давайте даже скажем, что её создал кто-то на основе класса птицы, то есть по описательному шаблону.
Вот она сидит, может чирикает там на своём. Она существует. Надеюсь понятно что это объект сидит на ветке, а не класс.
Как бы смешно я не описывал, хочу чтоб было доходчиво и просто, чтобы было понятно, отнеситесь к этому моменту серьёзно.
Идём далее.
Ворона. Как выглядит ворона? Ну пусть есть клюв как у любой птицы, и она чёрная. Ворона каркает, вот минимум что мы знаем о ней, однако я не говорю что ворона сидит. Вот именно эта ворона. Просто говорю о классе птиц ворона, то есть это описательная часть, конкретной вороны нет.
Если мы напишем класс ворона, напишем там её свойства, ну например цвет размер, то потом можем рассадить их на любых ветках, создав 100500 объектов ворона, научим их каркать и перемещаться.
А как научить объекты ворона перемещаться? Мы должны в классе ворона описать метод переместиться, а у объектов вызывать этот метод.
Надеюсь понятно, что все признаки объекта и действия описываются в классе, а при создании вороны мы уже можем ей присвоить признаки и вызывая методы заставлять её что-то делать.
Если в классе есть признак возраст, то при создании объекта этот возраст можем определить, ну взять и создать ворону молодую и старую.
Поэтому когда говорят люди это класс, а человек — это объект, это не верно. Это 2 класса. А вот именно этот человек — это уже объект.
Вообще не представляю себе класс люди. Расса людей как класс — это более реально.
Если эти моменты усвоены, то идём дальше. Переходим к практике, и уверяю вас, это не сложно. Когда я програмировал только переменными и массивами, меня всё устраивало. Когда я начал програмировать используя ооп, я понял что меня раньше не всё устраивало, и я на самом деле очень сильно мучался.
П.С. Конечно будут и теоретические вставки, и я постараюсь написать много. Не пугайтесь, просто перечитывайте. Это нужно понять, а главное практика.

Часть 1. Создаём класс, и на его основе объекты.

1.1. Объявление класса
Понятно что в языке програмирования определён синтаксис и есть правила кодинга, поэтому нам нужно запомнить как в bgt объявляются классы.
Сначала идёт ключевое слово class, потом имя класса и пара фигурных скобок, будем внутри них писать тело класса.

class Bird {

} // end class Bird

Обратите внимания. После правой фигурной скобки я написал коментарий , мол эта скобка заканчивает тело класса. Иногда такие комментарии помогают быстро понять где мы находимся.
Ещё обратите внимание, что имя класса я написал с большой буквы. Во многих языках програмирования принято это правило, то есть договорённость, чтобы классы отличались от объектов.
По сути этого достаточно, чтобы создавать на основе этого класса конкретных птиц. Да, птицы будут странными, ничего не описано, да и птицами их назвать будет сложно.

Bird@ bird; // Ссылка на объект типа Bird
Bird bird(); // Объект типа Bird, пока будет ошибка, нет конструктора.

О создании объектов поговорим позже. Пока нужно понять что две строки выше, это примеры объявления объектов по правилам bgt, то есть идёт сначала тип объекта, а потом имя объекта. Тип — это класс, он с большой буквы. Мы ведь его написали так, а в bgt есть учёт регистра букв, а следовательно Bird и bird это не одно и тоже, а совсем даже наоборот.
В классе можем объявлять свойства и методы. Свойство это переменная характеризующая что-то, например цвет. Метод это функция. Обычно методы нужны для действий над объектами, которые будут созданы на основе этого класса.
Если мы внутри фигурных скобок, то есть внутри класса напишем

string color;

то мы добавим строковое свойство.
А если напишем функцию-метод

void set_color(string s) {
color = s;
}

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

1.2. Конструкторы и деструктор.
Тоже очень важная тема, поняв её, вы поймёте как создаются объекты внутри компьютера, вернее внутри языка програмирования.
Итак, конструктором называется специальный метод, который инициализирует объект. В нём обычно инициализируют все свойства, но не обязательно это делать в конструкторе.
После выполнения конструктора объект является созданным, при прерывании конструктора bgt выдаёт фатальную ошибку и закрывается, отсюда, нельзя в конструкторе писать прерывание return;
Конструкторов может быть много, то есть на основе класса можно создавать объекты разными конструкторами.
Сигнатура конструктора описывается как обычный метод, за исключением двух моментов:
1. В конструкторах не указывается тип возвращаемого значения.
2. Конструктор имеет такое же имя как у класса.
Создадим класс ворона и объявим в нём конструктор, в котором примем свойство вороны — возраст.

class Crow {
int age; // возраст

Crow(int age) { // конструктор
// В конструкторе приняли число, переменные называются одинаково. Теперь чтобы обратиться к свойству объекта, надо писать this
this.age = age;
}

} // end class Crow

Ну теперь можно создать объект, какую-нибудь старую ворону.

Crow old_crow(99);

О создании объектов поговорим позже, сейчас же необходимо пояснить некоторые моменты, ну и закончить рассказ о конструкторах и деструкторе.
Ключевое слово this указывает на текущий объект. Обратите внимание не на класс, а на объект.
Вот создали мы старую ворону, и отправили возраст 99 в конструктор класса ворона. Если бы мы написали просто

age = age;

то это было бы бессмысленно. Это то же самое, если бы мы написали

99 = 99;

так как age это переменная, которая находится во входных параметрах конструктора. Но почему тогда назвали её также как и свойство класса ворона?
А потому, что все переменные нужно называть осмысленно, чтобы в будущем мы понимали, где приходит возраст, а где приходит ещё что-то в конструктор.
Согласитесь, если мы напишем

Crow(int a, int b, int c, int d, int e) { // конструктор
// здесь присваивания разным свойствам пришедшие значения
}

то после какого-то времени зайдя в код, мы можем забыть что куда присваивается. Да, да. Если у кого-то память хорошая, попробуйте заглянуть через года 2, или после того, как вы написали других пару сотен классов.
Поэтому используем this — указатель на текущий объект, то есть при создании старой вороны оно будет указывать на старую ворону, а через точку её свойство age.
а если создадим ещё молодую ворону

Crow young_crow(2);

то при создании молодой вороны this укажет на молодую, и молодая получит возраст 2 года.
но тут мы захотели создавать случайную ворону, чтобы возраст был не определён нами, а придуман всемогучим рандомом. Можно конечно в этом же конструкторе рандомить число, но тогда мы молодую и старую создать не сможем.
Может создать ещё один класс ворона? Хах, нет конечно. Решаем вопрос ещё одним конструктором.
Добавляем в класс ещё один метод-конструктор

class Crow {
int age; // возраст

Crow() { // конструктор
age = random(1, 100);
}

Crow(int age) { // второй конструктор
// В конструкторе приняли число, переменные называются одинаково. Теперь чтобы обратиться к свойству объекта, надо писать this
this.age = age;
}

} // end class Crow

Я сделал конструктор без параметров первым, хотя разницы нет. В нём мы рандомим число, и к свойству age присваиваем его.
Обратите внимание this не используем, потому что тут нет коллизии, и bgt поймёт что это свойство объекта, хотя если бы мы this.age написали ошибки бы не было, ведь this направил бы на объект и всё бы прокатило, просто незачем.
Ну что? теперь и молодая со старой будут нормально создаваться? Да. И со случайным возрастом можно создавать, хоть 1000 ворон. Можно создать.

Crow random_crow(); // создали ворону, а сколько ей лет фиг знает.

Надеюсь с конструкторами понятно, это методы создания объектов. Их может быть много. Отличаются они разными входными параметрами, а именно типами и количеством. То есть если объявить 2 конструктора, а в обоих принимается одна переменная типа string, даже если переменные называются по разному, то будет ошибка
Деструктор, метод который вызывается автоматически после уничтожения объекта. Писать его не обязательно, в отличии от конструкторов, ведь хотя бы один конструктор быть должен.
Если деструктор есть, то только один, двух и более написать нельзя, да и незачем.
В деструкторе уничтожаем всё что нужно, тем самым освобождаем память. когда объект удалится, деструктор обязательно сработает.
Объявляется он также как конструктор, только вначале ставиться знак тильда

~Crow() { // Объявили деструктор

age = 0; Обнулили возраст
}[/code]
Простые переменные вроде обнулять не обязательно. Вроде bgt сам их обнуляет.
А теперь подводный камень. Дело в том, что уничтожение объекта на совести bgt. Он уничтожит его тогда, когда никто на этот объект не ссылается, другими словами, когда объект станет не нужен в коде, и тогда, когда до него дойдёт очередь.
То есть, если мы уничтожили какую-то ворону, то bgt проверит, действительно ли она не нужна, и если да, то ей конец. При этом, это может произойти не сразу.
А теперь представьте. Мы создали 1000000 ворон, и всех их уничтожили. Когда уничтожится ворона под номером 999999?
Правильный ответ, скоро, но хз когда. Отсюда вытекает следующий момент:
Если мы научили каркать вороны, ну повесили звук. И вот они все радостно каркают, тут мы говорим больше нам вороны не нужны, то они каркать перестанут в зависимости от того, когда bgt их уничтожит.
А это зависит от их количества, от мощности компьютера и от сложности кода.
Мы вышли из игры, попали в меню, ходим по пунктам, а вороны ещё докаркивают. Не порядок.
Поэтому я очень редко пользуюсь деструктором, я пишу свой метод уничтожения, называю его традиционно destroy и вызываю тогда, когда нужно уничтожить объекты.. Естественно это пишем внутри класса

void destroy() { // Метод уничтожения
// Уничтожаем всё у объекта, в том числе звуки. Они много потребляют памяти.
age = 0; // Обнулили возраст
}

Вот вроде и всё по конструкторам и деструкторам. За одно узнали, что лучше использовать свой метод уничтожения. Далее научимся объявлять объекты, тут тоже много интересного.

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

Crow crow();

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

Crow crow(55);

Создали ворону через другой конструктор, правда имя оставили как у предыдущей, просто ворона, а вместе они не уживутся, будет ошибка мол такой объект уже есть, так что либо ту оставляем, либо другую, либо даём разные имена, как делали выше.
Если мы объявили ворону глобально, то есть за пределами функций, то жить она будет пока не закроем игру. Часто это не удобно, ну убили мы ворону, а она собака живет в памяти компьютера.
Некоторые пользуются, по моему не верным решением, а именно добавлением ворон в массивы и удалением их из массивов, при этом создают отдельно объект, потом добавляют его в массив, вот уже 2 объекта, а следовательно в два раза больше памяти компьютера используется. Не хорошо.
Дело там не только в памяти, да и не в 2 раза, я пошутил, но всё же об этом ниже будет, а пока про объекты внутри функций.
Если мы переменную объявляем внутри какой-то функции, то эта переменная локальная, её можно использовать только в этой функции, а когда функция завершиться, то переменная уничтожается также с объектами созданными таким же образом как выше создавали.
Допустим наша ворона продвинутая, умеет много, и каркает и летает и ходит, то есть кучу звуков использует. Помимо звуков, ещё много других свойств имеет, ну допустим занимает 200 килобайт в оперативной памяти, хотя я лишка взял, но для наглядности пойдёт.
Чтобы её создать, нужны ресурсы процессора и оперативной памяти. Первый исполнит код, то есть создаст ворону, затратит время, вторая запомнит данные этой вороны.
И вот мы создали кучу ворон, а нам столько не надо, но уничтожить мы их не сможем, пока не завершим игру, а когда откроем игру заново, то снова все вороны создадутся. Ну поубивали мы их, но они будут живы, то есть память занимать будут столько же.
100 ворон 20 мегабайт в оперативе. Некоторые могут сказать, с нашими современными компьютерами можно эти моменты не учитывать, однако эффективный код всегда лучше. Наверно задумывались, что в последнее время программы выполняются сложнее чем раньше?
Это именно потому, что многие забивают на этот момент, мол компы схавают. Об этом много рассуждений, например на хабре можно найти. Поэтому лучше если вы будете следить за памятью и процессором.
Однажды я тестил. Создал 5000 рычащих мобов, у меня игра подвисала очень серьёзно, потом я оптимизировал код. Я начал заставлять рычать только тех, кто в радиусе видимости. В общем, игра стала летать. Надеюсь я вас убедил, что ресурсы это серьёзно, и объекты созданные таким образом это сильно не хорошо.
Однако есть плюс создания объекта таким образом. Дело в том, что если нам нужно чтобы вначале игры выполнился код, то можно сделать класс и создать на его основе объект. То есть при запуске игры в конструкторе класса выполнится всё что нам надо.
Вы можете возразить, мол можно в функции входа main выполнить всё что нам надо. Вы правы, но объект может отвечать за определённую работу, и если ему отдать все рутинные задачи, которые по смыслу относятся к нему, то это делает код читабельнее и логичнее.
Например я написал класс Info_manager и создаю объект который живет всё время, в нём. Я обрабатываю все эти дела с выводом текстовых сообщений через скринридеры и прочее.
Класс и объявление объекта в отдельном модуле, отсюда удобство, я подключаю его к любому проекту и всё, мне не надо подключать dll от nvda, отключать / включать key_hook, всё делается автоматом. Я просто вызываю функцию show_info(«прочти этот текст»); b он озвучивается.
Теперь согласны, что иногда создавать таким образом объекты это очень удобно?
Насчёт массивов, мы можем создать объект, положить его в массив, а если он нам перестанет быть нужным, удалить из массива. Давайте пройдёмся по алгоритму, и я постараюсь объяснить чем мне это не нравится.

Crow[] crows; // массив типа ворона, пока здесь 0 ворон

//Лучше добавлять ворон в какой-то отдельной функции, поэтому создаём её

void add_crow(int age) {
Crow crow(age); // создали ворону, назовём её временной. Она удалится после завершения функции, 200 килобайт памяти и немного процессорного времени затратили
crows.insert_last(crow); // добавили временную ворону в массив, а это значит, что создалась новая ворона, но такая же внутри массива, ещё 200 килобайт памяти и немного процессорного времени
} // конец функции

// После функции удаляется автоматом временная ворона, освобождается память, если мы это предусмотрели в деструкторе, ещё немного процессорного времени.
Мы могли метод destroy написать, и там уничтожать, не суть, главное видно что код выполняется не очень хорошо. Создаёт две вороны и одну уничтожает.
Я видел, что люди создают объекты именно так. Давайте напишем немного подругому, хотя для меня это всё равно не приемлемо. Для множества объектов, создавать и уничтожать их надо используя ссылки на объекты, но об этом ниже будет.
// Перепишем функцию

void add_crow(int age) {
crows.insert_last(Crow(age)); // Создаём временную ворону уже не используя отдельную переменную на объект. Сразу при добавлении в массив, создали ворону. Для этого вызвали конструктор класса Crow
} // конец функции

Честно не знаю, но мне кажется что будет создано всё равно две вороны. Сначала конструктор вернёт ворону, а потом внутри массива создастся ворона, копия той что пришла во входных параметрах в метод insert_last
Ещё один момент, если мы создадим массив с определённым числом элементов

Crow[] crows(10);

то у нас создадутся 10 ворон. Для каждой вызовется конструктор без параметров.
Плохо это тем, что используя этот метод создания объектов, они сразу создадутся, даже если они пока что нам не нужны. Ну не играем мы ещё, а просто ходим по меню игры, а вороны уже есть, а число мы использовали чтобы зарезервировать память.
Резервация памяти часто полезна. Это быстрее работает, чем добавлять по одной вороне каждый раз, увы, 10 ворон у нас, хотя пока что не нужны. Да можно память зарезервировать позже, когда вошли в игру и готовы поиграть.
crows.resize(10); // Изменили размер массива, зарезервировали тем самым память.
Ещё плохо это тем, что если конструктора без параметров объявлено в классе не будет, то будет ошибка. С ссылками таких проблем нет.
Выводы: Используйте такой способ только тогда, когда это необходимо

Ссылки на объекты отличаются в использовании кординально. Позволяют использовать один объект, используя множество ссылок на него.
Ссылка может ссылаться на объект, а может не ссылаться. Тогда она равна null.
Если есть объект, на него ссылается хотя бы одна ссылка, он будет жить, если 0 ссылок ссылается, то bgt этот объект удалит.
Через ссылки можно работать с объектами так же как напрямую через переменную объекта, однако можно сами ссылки обнулять или присваивать на объект, или сравнивать между собой или с null, чтобы узнать ссылается ли она на объект или нет.
Объявить ссылку можно так:

Crow@ crow;

К типу добавился знак собаки, следовательно crow переменная ссылка на объект. Конструктор не вызвался. Объекта не существует, ссылка ссылается на null, вернее не ссылается никуда.
Можно проверить так:

if(@crow==null) {
show_info("объект не существует");
} else {
show_info("объект существует");
}

Когда мы работаем с ссылкой, то перед переменной ставим знак собаки. Этот момент очень важен. Надо понять, когда мы работаем с ссылкой.
Если сравниваем ссылки между собой или с null, это мы проверяем ссылаются ли они на один и тот же объект, или может они никуда не ссылаются. То есть работа с ссылкой, знак собаки ставим.
Если присваиваем ссылке что-то, то тоже знак собаки ставим, например:

@crow = null; // обнулили ссылку. Если на объект больше ничто не ссылается он уничтожится.

Если знак собаки будем ставить не верно, то всегда будут ошибки в bgt, игра не запустится. Лучше это понять очень хорошо и не делать ошибок.
Ну ок! Мы ссылку объявили, она не ссылается никуда, теперь создаём объект, связываем с ссылкой, то есть приравниваем ссылке адресс на объект. Знак собаки обязателен.

@crow = Crow(55); // вызвали конструктор вороны

Ничего сложного. Это надо только один раз понять и писать создания объектов правильно.
Давайте ещё раз, объявим ссылку. Инициализируем ссылку, давайте и уничтожим ссылку.

Crow@ old_crow; // ссылка на старую ворону, пока никуда не ссылается

@old_crow = Crow(99); // Присвоили ссылке на старую ворону адресс на объект старой вороны, создали объект вызвав конструктор.

@old_crow = null; // уничтожили адресс на старую ворону. Ссылка никуда не ссылается, старая ворона как объект уничтожена.

@old_crow = Crow(89); // Присвоили этой же ссылке уже другую ворону, помоложе, пусть вороны отличаются только на 10 в возрасте, но это разные объекты. Того объекта ведь уже нет.

А вот чтобы работать с объектом, то мы это делаем через точку. То есть доступ к свойствам и методам объекта через ссылку происходит в коде. Также, и знак собаки не ставится. Запомните, если есть точка, то собака не нужна.
Продолжим издеваться над вороной.

old_crow.age = 99; // Повзрослела старушка. Было 89, это этот самый объект, но не та ворона, которая исчезла. Просто стала тоже старой.

Но можно объявить ссылку и сразу её инициализировать одной инструкцией:

Crow@ crow = Crow(55); // Объявили и приравняли к объекту, вызвав конструктор.

Если вам кажется, что ну его нафиг, уверяю вас, разберитесь с этим. Вы поймёте, это не сложно и эффективнее, а главное удобнее использовать в коде. Можно удалять, создавать сколько угодно.
Ещё плюс ссылок, можно использовать много ссылок на один и тот же объект. Например:

Crow@ crow1 = Crow(12);

Crow@ crow2 = @crow1; // Объявили вторую ворону и присвоили ей адресс первой вороны

Теперь они ссылаются на одну и ту же ворону. Если через одну изменить возраст вороны

crow1.age = 25;

то вторая ссылка будет возвращать возраст этой же вороны.

show_info(crow2.age); // вернёт 25

Если первую ссылку обнулить, то объект не удалиться, ведь на него ссылается ещё вторая ссылка.
Сами ссылки занимают мало памяти в оперативке, и можно создать карту на каждой клетке будет ссылка на объект. Ну например лежит вещь на клетке или нет.
Представляем ситуацию, вещь занимает 6 килобайт памяти, на карте может лежать 250000 вещей, я взял карту 500 на 500
1500000 килобайт, это ну чуть меньше полутора гигабайт. Без ссылок тут не обойтись. Используя ссылки будет максимум 20 мегабайт оперативы использоваться.
Не верите что это так? Я проверял. Свободная память тает на глазах. Я так почти всю оперативку себе забивал, у меня 4 гб.
С массивами похожий код, но он эфективнее. Давайте ворону добавим в общий вороний массив

Crow@[] crows; // Массив ссылок на ворон, собака ставится до квадратных скобок.

void add_crow(int age) { // Функция добавления вороны
crows.insert_last(Crow(age)); // Добавили в массив ссылок ворону, Создали ворону сразу в этой же строке.
}

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

crows[2].age = 81;

Обратились к объекту, собаки нет.
А вторую удалим.

@crows[1] = null;

Удалили, то есть обнулили ссылку, знак собаки есть.
При использовании ссылок, надо быть осторожным. Если мы обратимся к ссылке, а она никуда не ссылается, то будет ошибка. Вот теперь когда второй вороны нет, нельзя изменить её возраст.

crows[1].age = 27; // Будет ошибка, связанная с null.

Ещё нужно понимать, что в массиве было 3 вороны, удалили вторую, остались первая и третья, но ссылка 2 в массиве всё равно осталась, то есть в массиве все равно 3 элемента. Если ходим удалять элементы, то надо использовать метод remove_at()

crows.remove_at(0); // Удалили первую ворону.

Теперь первый элемент нулл. Он был вторым, стал первым.
Второй элемент, это третья ворона. Она тоже сместилась в начало.
Всего 2 элемента в массиве, ведь первую мы удалили как элемент, а не просто обнуляли ссылку.
Вот впринципе основы объявления и использования классов и объектов. Надо четко всё понимать, тогда писать легче и интереснее.
В продолжении часть 2: «Наследование и смежные тем»ы, а это ещё интереснее. Наследование открывает невероятные возможности, но надо усвоить первую часть.
П.С. — Писал быстро, Русскому языку внимания не уделял вообще.

[attachment=202]

ООП в BGT: 0 комментариев

  1. Благодарю за замечательную статью! Она однозначно лучше предыдущей от Рыжикова и прекрасно раскрывает суть ООП. Даже мне, всё это по сути уже знающему, она помогла обновить знания и разложить все по полочкам.

  2. Автор конечно молодец, прям глава с книги, но! Страшные 2 но!
    П.С. — Писал быстро, Русскому языку внимания не уделял вообще.
    Извините, молодой человек, но я даже в пьяном бреду не напишу дважды вместо «язык программирования» «язык програмирования». Это было круто. Рассказал Американским программерам этот прикол приведя в ример «programing» вместо «programming», поржали откровенно.
    Ну и второй момент. Автор, если ты так уж решил превзайти меня и написать статью лучше по ООП. Причем предрался к классу люди. Так вот.
    Во первых, спроси любого профессионала на ЯП с ООП. Он тебе скажет то же, что писал я. Класс описывает объект. Объект — экземпляр класса. Класс люди описывает свойства и методы человека, а объект человек получает эти параметры.
    Во вторых, грамотей, что же ты не указал 3 главных вещи в ООП и как их использовать в BGT?
    Сколько пантов, и все на уровне приметизма.
    best_gamer, пофамильничать вздумал, Белоусов, ну ок. Да, соглашусь, в статье больше инфы, но не нужной для новичков.
    Т.е в большинстве случаев в приоритете моя статья до сих пор. показал статью нашему, русскому человеку, который 25 лет проживает в США, чемпион Java, кто не знает, гуглите что это такое. О таком объяснении ООП он высказался негативно. А вот теперь посудите. Мнение профессионала на ООП против молодого неопытного юноши. Ну это же смешно.

  3. Костя, ну хватит комедию ломать?
    Знаем Мы какой ты англоязычный юзер. Давай вспомним Vovanq\’а и тебя в конфиренцие blind games!
    По этому, не верится мне, что с тобой какой-то адекватный программист из США, будет общаться. Та и 99.9% это очередной трёп.
    Лично я в твоей статье реально мало чего понял, в отличии от этой, так что не рви бомбильник и учись писать!

  4. слушай костя.
    мало того что ты элементарный код в примере с ошибками дал в коде
    так ты ещё и людей которые в разы лучше написали статью пытаешься указать на не значительные ошибки.
    а про твоих друзей с «америке» это бред полнейший.
    сам бы написал нормальную статью по которой можно было бы нормально понять ооп.

  5. Я уже много статей написал. Только вот у нас на бг появился странный модератор, который не пропускает вообще ничего. Но я админам написал, с этим разберемся. А по поводу Американцев, увы, но сейчас они вперееди по технологиям.

  6. Не понял ни одной претензии. Я тебя превосходить не собирался, я написал на форуме, Bestreader спросил меня, можно ли её опубликовать. Твою статью читал, ничего плохого о ней не говорил, никаких трёх принципов ООП там не вычитал. Класс называть во множественном числе глупо, отсюда недопонимания начинающих, почему люди это класс, а человек это объект, по себе помню.
    Я понимаю тебя, ты обиделся, начал придираться ко всему, к чему только можно, пытаясь убедить хотя бы самого себя, что ты лучше знаешь и описываешь ООП, но у тебя это пройдёт, когда вырастешь. Извини за колкости, но просто надо быть воспитаным.

  7. Даааа, а почему тогда мой уровень английского оценивают как intermediate. Я согласен, профессионалу со мной тягаться бред, но я вполне свободно общаюсь на общие темы и темы по программированию.
    Не веришь, могу добавить в скайп группу программистов, где я тоже сижу.

  8. Igorek, да нет, я не обиделся. Просто для хорошего программиста да, эта статья будет полезней, но не для начинающих. Тем, кого я обучаю программированию, была понятней первая статья. Более того, я на бг не хожу, потому вообще случайно узнал, когда 1 из учеников спросил мое мнение об этой статье.

  9. Костя, если бы я читал твою статью и при этом не шарил в ООП, я бы ни хрена не понял…. Одни теоретические рассуждения и бла бла бла… В этой же статье человек реально показывает ООП, помогает начинающему юзеру разобраться. Ничего не имею против твоей статьи, но читать бы, если б был нубом, стал бы эту.

  10. И ещё: ребят, на фига гнаться за америкой, учить англ на профи уровне и т. д.? Я за Россию и русского программиста! Надо развиваться самим, а не смотреть на жирных потребителей тонн бургеров и гектаров пиццы. 🙂

Добавить комментарий