Я не понимаю ООП. Кто-нибудь может мне простым языком для дебила объяснить в чем суть? Пытаюсь делать лабу - нихуя не понимаю. Наследование, инкапсуляция хуе мое, интерфейс, абстактный класс, о чем вообще блядь.
бамп
бамп
бамп
бамп
бамп
Задай вопрос конкретнее, что именно непонятно.
Для начала нахуй оно вообще нужно? Ну то есть я сейчас делаю какую-то простейшую хуету которую без ООПа можно написать в 15 строк. Зачем так усложнять?
>простейшую хуету которую без ООПа можно написать в 15 строк. Зачем так усложнять?
Незачем. Делай как проще, тебя никто не заставляет (если это, конечно, не тренировочное задание) везде тыкать ООП.
И вообще, что это за школьный максимализм? ООП - просто один из подходов решения задач, не более ни менее. Это не панацея, а просто одна из парадигм и не нужно хейтить её, потому что иногда она действительно бывает удобна.
>нихуя не понимаю
>ООП
В этом причина.
В джаваскрипте нет классов, так что это не обман.
Все просто - в ООП программной единицей является объект. Объекты содержат в себе некие параметры и методы взаимодействия, определяемые в классе. Класс, в свою очередь, является неким отличным от стандартных типом данных, предоставляя для своих экземпляров поля и методы. Далее исходя из этих основ, мы добавляем еще пару парадигм - инкапсуляция, к примеру, это локальное сокрытие данных. Наследование вполне логично - классы могут "вкладыватся" друг в друга в иерархическую структуру, где класс-потомок может "унаследовать" поля и методы класса-предка. Есть еще полиморфизм - еще одна парадигма, говорящая о том, что в идеальном коде тип выполняемой операции зависит от типа оперируемого объекта. Примеры можешь сам поискать, нету смысла повторяться, стандартные "машина" - "колесо", "стул" - "офисный стул". Интерфейс, для простоты понимания, можешь представить как класс, который описывает доступные методы, но не их реализацию. В свою очередь, абстрактный класс может иметь в себе как интерфейс, так и реализацию, включает в себя минимум 1 абстрактный метод и не позволяет создать объект своего класса.
мимо-наруто
мимо-наруто
Долбоеб, берешь Страуструпа и учишь. Наизусть, по ролям. Завтра в это же время жду рассказ по памяти. Еблан, ООП он не понимает
>Я не понимаю ООП
Год назад хотел стать продвинутой веб-макакой, но не въехал в ООП. Потупил немного и бросил.
>стандартные "машина" - "колесо", "стул" - "офисный стул"
ох уж эти уебские метафоры уровня хабра
Задание напиши к лабе. Скорее всего ооп там тебе нахуй не упало.
Хуйня это ваше ооп.
мимосистемщик
Смотри оп.
Инкапсуляция - это когда нет прямого доступа к внутренностям, и все взаимодействие через интерфейс - вот например автомобиль. Мы не можем манипулировать двигателем напрямую, только вере специальный интерфейс - руль, педали, коробка передач. Нужно для этого же - чтобы легко пользоваться сложными вещами и не грузиться, чо там внутри происходит.
Наследование - это такой способ организовать иерархию. Во взрослом программировании его мало используют, потому что оно жестко связывает классы. Нужно для много чего, но самое простое - чтобы одно и то же. Например мы делаем йобу по типу варкрафта. Там есть герои, пехотинцы, стрелки и т.д. Это все - отдельные классы. Но чтобы каждому не прописывать тот код, который отвечает за хождение (они же все ходят), создают базовый класс юнита, в нем определяют механизм хождения, а все ходящие юниты наследуют этот класс копируя это поведение, но не копируя ход
Полиморфизм - юниты из предыдущего пункта умеют атаковать, но сильно по разному - кто-то магией, кто-то мечом, кто-то копьем. Нам же не очень важно, как это происходит, а важен сам факт аттаки. Поэтому у всех будет метод unit::attack(), но работать он для всех будет по разному
Чо там еще было? Интерфейсы? Это тебе пока рано
Инкапсуляция - это когда нет прямого доступа к внутренностям, и все взаимодействие через интерфейс - вот например автомобиль. Мы не можем манипулировать двигателем напрямую, только вере специальный интерфейс - руль, педали, коробка передач. Нужно для этого же - чтобы легко пользоваться сложными вещами и не грузиться, чо там внутри происходит.
Наследование - это такой способ организовать иерархию. Во взрослом программировании его мало используют, потому что оно жестко связывает классы. Нужно для много чего, но самое простое - чтобы одно и то же. Например мы делаем йобу по типу варкрафта. Там есть герои, пехотинцы, стрелки и т.д. Это все - отдельные классы. Но чтобы каждому не прописывать тот код, который отвечает за хождение (они же все ходят), создают базовый класс юнита, в нем определяют механизм хождения, а все ходящие юниты наследуют этот класс копируя это поведение, но не копируя ход
Полиморфизм - юниты из предыдущего пункта умеют атаковать, но сильно по разному - кто-то магией, кто-то мечом, кто-то копьем. Нам же не очень важно, как это происходит, а важен сам факт аттаки. Поэтому у всех будет метод unit::attack(), но работать он для всех будет по разному
Чо там еще было? Интерфейсы? Это тебе пока рано
Ну вот есть переменные, есть функции (процедуры), ты же в курсе что это? Переменные хранят данные, а функция это алгоритм (т.е. что делать с данными).
Вот у нас есть какой-то объект в программе, например человек. У человека есть имя, фамилия, рост, вес, дата рождения, и т.п. Каждый параметр мы храним в переменной. Для каждого действия с человеком (например посчитать возраст человека, сохранить его данные в БД) у нас своя функция.
Внезапно у нас оказывается стопицот переменных man_параметр=что-то
и стопицот функций man_get|set|do_что-то(переменная1, переменная2, перменная3.... переменная5)
А для ста человек вообще пиздец, надо массив мутить, в каждую функцию передавать все данные человека длинным списком аргументов, мрак короче.
И вот умные люди придумали все связанные переменные группировать в одну структуру, и назвали ее, как ни странно, структурой.
struct {
string name,
string surname,
date birthday,
int weigth,
int height,
tinyint penissize
} man; //здесь и далее псевдокод
Теперь во все функции использующие данные человека, мы передаем не кучу аргументов-переменных, а одну структуру (точнее указатель на нее). Красота.
Но умные люди пошли дальше и в структуру всунули еще и функции, которые с этими данными работают, получился класс.
class man {
string name,
string surname,
date birthday,
int weigth,
int height,
tinyint penissize,
function get_age(today){
return (today - this.birthday)/365;
}
function is_jeerobass(){
if (this.weight>(this.height-110)) return true;
else return false;
}
}
Теперь мы создаем не переменные, а экземпляр класса, заряжаем его данными, и вызывая функции (они теперь называются методы) получаем то что нужно.
var anon = new man;
anon.name='Vasya';
anon.height=175;
anon.weight=85;
anon.birthday='10.02.2000';
if (anon.get_age()<18) print "shkalnik please";
if (anon.is_jeerobass()) print "jeerobass detected";
Вот у нас есть какой-то объект в программе, например человек. У человека есть имя, фамилия, рост, вес, дата рождения, и т.п. Каждый параметр мы храним в переменной. Для каждого действия с человеком (например посчитать возраст человека, сохранить его данные в БД) у нас своя функция.
Внезапно у нас оказывается стопицот переменных man_параметр=что-то
и стопицот функций man_get|set|do_что-то(переменная1, переменная2, перменная3.... переменная5)
А для ста человек вообще пиздец, надо массив мутить, в каждую функцию передавать все данные человека длинным списком аргументов, мрак короче.
И вот умные люди придумали все связанные переменные группировать в одну структуру, и назвали ее, как ни странно, структурой.
struct {
string name,
string surname,
date birthday,
int weigth,
int height,
tinyint penissize
} man; //здесь и далее псевдокод
Теперь во все функции использующие данные человека, мы передаем не кучу аргументов-переменных, а одну структуру (точнее указатель на нее). Красота.
Но умные люди пошли дальше и в структуру всунули еще и функции, которые с этими данными работают, получился класс.
class man {
string name,
string surname,
date birthday,
int weigth,
int height,
tinyint penissize,
function get_age(today){
return (today - this.birthday)/365;
}
function is_jeerobass(){
if (this.weight>(this.height-110)) return true;
else return false;
}
}
Теперь мы создаем не переменные, а экземпляр класса, заряжаем его данными, и вызывая функции (они теперь называются методы) получаем то что нужно.
var anon = new man;
anon.name='Vasya';
anon.height=175;
anon.weight=85;
anon.birthday='10.02.2000';
if (anon.get_age()<18) print "shkalnik please";
if (anon.is_jeerobass()) print "jeerobass detected";
Мне даже как не программисту, не писавшему ничего сложнее сортировки массива, все эти концепции весьма понятны.
Ты тупой просто, тут уж как ни объясняй...
Твой батхерт понятен, так как в твоей ситуации тебе нужно применить инструмент, без которого можно обойтись. Задачу то опиши.
>я сейчас делаю какую-то простейшую хуету которую без ООПа можно написать в 15 строк
А когда/если будешь макакой в проекте на 10-15 тыс. срок, тогда почуствуешь зачем нужно ООП. Оно помогает структурировать программу. Еще оно действительно облегчает отображать логику/структуру приложеия в код. Например, в типичных энтерпрайз системах многие понятия прямо ложатся в классы: пользователь, счет, роль, товар и т. д.
А когда/если будешь макакой в проекте на 10-15 тыс. срок, тогда почуствуешь зачем нужно ООП. Оно помогает структурировать программу. Еще оно действительно облегчает отображать логику/структуру приложеия в код. Например, в типичных энтерпрайз системах многие понятия прямо ложатся в классы: пользователь, счет, роль, товар и т. д.
Если бы я учил ООП по учебникам, я бы нихуя его не понял. Потому что их ебанутые мудаки писали.
Инкапсуляция - она и у функции есть, ты просто ее вызываешь и тебя не ебёт что у нее там внутри, разве не так?
Наследование - ну да, круто, но оно вовсе не обязательно в ООП. Не стоит наследовать собаку от велосипеда только ради наследования.
Полиморфизм - это вообще костыль для строго типизированных языков, в языках с динамической типизацией он нинужен.
Пишу с тилибона, поэтому немного криво
Абстрактный класс там еще был
Кароч, есть например собака, кот, человек - мы их можем там потрогать, вот это все
А есть "живое существо" - более абстрактное понятие. Не существует такого живого существа, для которого не было бы большей степени детализации (т.е. любое живое существо - это или человек, или собака, или еще кто-то - но точно кто-то).
Но тем не менее, "живое существо" нам говорит о многом - мы сразу представляем НЕЧТО, что дышит, питается, размножается. Это все так или иначе делают и все "конкретные" живые существа.
Теперь возвращаемся к нашему варкрафту. Unit - это абстрактный класс. Ну серьезно, у нас же не может бегать по карте нечто НЕ КОНКРЕТНОЕ, да и как должен выглядеть юнит? Это точно абстрактная вещь и нам надо этот класс как-то обезопасить от того, чтобы какой-то криворукий мудак не создал его экземпляр - для этого и есть понятие абстрактного класса. Мы не можем создать экземпляр абстрактного класса, точно так же, как не может на свете появиться какое-то ЖИВОЕ СУЩЕСТВО непонятное.
Фишка абстрактного класса - абстрактные функции. Это применимо тогда, когда все наследники делают какую-то хуйню (ну вот все живые организмы размножаются), но в рамках программы почти все они делают это очень по разному.
Например, в нашей программе есть человек, курица и дождевой червь. Нет смысла прописывать механизм размножения в базовом классе (живое существо) - они все очень по разному это делают
Но нужно как-то отметить, что все они так или иначе умеют размножаться и что в каждом классе (человека, курицы и червя) этот механизм реализован - именно так и работают абстрактные методы. Ты объявляешь абстрактный метод (ну тип abstract public function eblia()) и теперь все, кто отнаследуются от этого класса должны реализовать этот класс у себя, иначе пизда.
А вообще оп, надеюсь ты там физик или химик какой-то и программирование тебе не нужно, иначе туго тебе прийдется
>Если бы я учил ООП по учебникам, я бы нихуя его не понял
Не обольщайся, ты и так его не понял
Попробуй хотя бы прочитать, что я написал
-кун
Абстрактный класс там еще был
Кароч, есть например собака, кот, человек - мы их можем там потрогать, вот это все
А есть "живое существо" - более абстрактное понятие. Не существует такого живого существа, для которого не было бы большей степени детализации (т.е. любое живое существо - это или человек, или собака, или еще кто-то - но точно кто-то).
Но тем не менее, "живое существо" нам говорит о многом - мы сразу представляем НЕЧТО, что дышит, питается, размножается. Это все так или иначе делают и все "конкретные" живые существа.
Теперь возвращаемся к нашему варкрафту. Unit - это абстрактный класс. Ну серьезно, у нас же не может бегать по карте нечто НЕ КОНКРЕТНОЕ, да и как должен выглядеть юнит? Это точно абстрактная вещь и нам надо этот класс как-то обезопасить от того, чтобы какой-то криворукий мудак не создал его экземпляр - для этого и есть понятие абстрактного класса. Мы не можем создать экземпляр абстрактного класса, точно так же, как не может на свете появиться какое-то ЖИВОЕ СУЩЕСТВО непонятное.
Фишка абстрактного класса - абстрактные функции. Это применимо тогда, когда все наследники делают какую-то хуйню (ну вот все живые организмы размножаются), но в рамках программы почти все они делают это очень по разному.
Например, в нашей программе есть человек, курица и дождевой червь. Нет смысла прописывать механизм размножения в базовом классе (живое существо) - они все очень по разному это делают
Но нужно как-то отметить, что все они так или иначе умеют размножаться и что в каждом классе (человека, курицы и червя) этот механизм реализован - именно так и работают абстрактные методы. Ты объявляешь абстрактный метод (ну тип abstract public function eblia()) и теперь все, кто отнаследуются от этого класса должны реализовать этот класс у себя, иначе пизда.
А вообще оп, надеюсь ты там физик или химик какой-то и программирование тебе не нужно, иначе туго тебе прийдется
>Если бы я учил ООП по учебникам, я бы нихуя его не понял
Не обольщайся, ты и так его не понял
Попробуй хотя бы прочитать, что я написал
-кун
Есть класс Human(человек) у которого есть свойство Name и Age, допустим надо создать класс Engineer(Инженер), который тоже может иметь Имя и Возраст, но дополнительно имеет например Образование, или сесто работы, понятно что иженеры входят в класс Людей, поэтому создавая класс Enfineer можно унаследовать его от Human, дабы не писать лишнего кода,
Пример:
class Human { int age; string name; }
class Engineer : public Human { string quality; }
e = Engineer()
e.age = 22;
e.name = "Anton Sychev"
e.quality = "UNN CMC";
PROFIT?
Годно объясняешь. Расскажи о себе. На кого учился? Кем работаешь?
>Попробуй хотя бы прочитать, что я написал
Зазубренное из книжки говно ты написал.
Например ты в курсе, что абстрактный класс и обычный скомпилируются в совершенно однохуйственный код? Потому что вся эта залупа с абстрактностью - она лишь для отлова ошибок на стадии препроцессинга, а ты в нее уверовал как в основу ООП.
Насколько помню Абстрактный класс это класс содержащий чисто-виртуальные методы,
Интерфейс полностью состоит из чисто-виртуальных методов, гугли C++ ключевое слово virtual
Гавна поешь
>Зазубренное из книжки говно ты написал.
Охуел блять, в книжках такого нет
>Например ты в курсе, что абстрактный класс и обычный скомпилируются в совершенно однохуйственный код? Потому что вся эта залупа с абстрактностью - она лишь для отлова ошибок на стадии препроцессинга, а ты в нее уверовал как в основу ООП.
А вот это типичный высер из книжки
Я ж говорю, ты копаешься в деталях, а сути не понимаешь. Как слесарь блять, который запомнил на какие кнопки жать на станке, а сам станок слабо себе представляет, разве что отдельные его элементы
В общем, надеюсь, что ты не программист или что хотя бы твою работу кто-то контролирует
Учился в ННГУ им. Лобачевского, ф-т. ВМК но по кодингу в основном все сам, в универе я учил только С\С++, Матаны, Диффуры, Алгебры, ..., etc. А так знаю 4,5 ЯП (ПХП уже не юзал года 4)
ОП, дай я тебя обниму.
Правда у меня не с ООП проблемы возникли(хотя в нём тоже не всё понимаю).
Проблемы у меня возникли на курсовой в которой впервые понадобилось использовать MFC и отрисовывать хуйню в окошке.
До этого кодить мне доставляло и я полностью понимал каждую строку написанного мною с нуля кода.
Тут же я полувслепую копипащу что-то из лекций и интернетов и с болью пытаюсь совместить написанные мной, скопипащенные и изначально включенные в солюшен части.
Так и не осилил за 2 дня, а дедлайн - сегодня.
Всё, пиздарики, кодинг - не моё?
Правда у меня не с ООП проблемы возникли(хотя в нём тоже не всё понимаю).
Проблемы у меня возникли на курсовой в которой впервые понадобилось использовать MFC и отрисовывать хуйню в окошке.
До этого кодить мне доставляло и я полностью понимал каждую строку написанного мною с нуля кода.
Тут же я полувслепую копипащу что-то из лекций и интернетов и с болью пытаюсь совместить написанные мной, скопипащенные и изначально включенные в солюшен части.
Так и не осилил за 2 дня, а дедлайн - сегодня.
Всё, пиздарики, кодинг - не моё?
В плюсах так, в шарпе воообще херпоймичо.
Дима, ты?
Николай?
Вот ваш чай
Еще раз повторяю: дрочево с абстрактными классами - оно только у тебя в голове, если абстрактный класс сделать обычным - небо не рухнет, земля не разверзнется, код будет работать как и раньше. Абстрактные классы - это не фундамент ООП, а всего лишь необязательная фича для удобства восприятия в некоторых случаях. То же самое касается полиморфизма и наследования. Не с этого нужно начинать изучать ООП новичку, иначе есть вероятность заболеть ООПом головного мозга (как ты).
>Я ж говорю, ты копаешься в деталях, а сути не понимаешь
Лол, ну конечно я не понимаю сути, а ты понимаешь
Поясните за 3d графику, вот я хочу двигать и вертеть объекты в пространстве, что там за косинусы, хуесинусы, градусы, кватернионы и прочая поебень? Надо лабу писать, а я вообще в этом не шарю.
Алсо, поясните за нормали, вершины, бампмаппинг, рельефное текстурирование, маппинг текстур, скелетную анимацию, бюджет полигонов. Я хз, что вся эта поебень значит вообще, а сдавать уже через неделю.
>Лол, ну конечно я не понимаю сути, а ты понимаешь
Именно
>Абстрактные классы - это не фундамент ООП
А я где-то сказал, что фундамент?
>Не с этого нужно начинать изучать ООП новичку,
Откуда тебе знать, с чего начинать новичку, если ты сам новичок и нихуя ООП не понимаешь?
>(как ты)
Я-то уже давно данные анализирую в R и MatLab-е, но и на руби СТАРТАПЫ писал, и даже одно время фабрики абстрактных фасолин. Просто я разбираюсь в сути парадигмы, в голове у меня это работает как система целостная, без мусора. А у тебя только мусор
Печалька
>Абстрактные классы - это не фундамент ООП, а всего лишь необязательная фича для удобства восприятия в некоторых случаях.
Вот такие у нас «специалисты» выходят.
Так я о чем, он смотрит на ООП просто как на набор навязанных синтаксических правил, у него нет картины в голове. Нет абстрактного мышления у человека, может именно поэтому у него такой латентный пунктик насчет абстрактных классов, может вообще на само слово алергия
Никогда не понимал, что если интуитивно не понимаешь суть цифрового мира, то зачем идти на прохраместа?
Иди на юриста-экономиста, долбоёбушка.
>Иди на юриста-экономиста
Тащемто экономистам надо знать базу вышки - матан, линал, матстат. А тут оп в ООП не разобрался
Я немного туповат в матане и статистиках прочих(ну решу быстро, если открыть методичку), но ООП и синтаксисы языков, прочая хуйня для меня как два пальца обоссать.
Код вообще вижу как единую картину. Картину из символов.
У меня острый приступ ОКР когда вижу грязный код
Так я и говорю, что матан и матстат сложнее ООП, а тут ты (или не ты) Опу, неосилившему даже ООП, идти в экономисты
>А я где-то сказал, что фундамент?
Выше простыню про абстрактные классы я что ли написал?
>Я-то уже давно данные анализирую в R и MatLab-е
Ну охуеть теперь
>на руби СТАРТАПЫ писал
Значит я совершенно правильно поставил диагноз ООП головного мозга
>Просто я разбираюсь в сути парадигмы
Абсолютно ВСЕ ООП-говнокодеры так считают, без исключения, им кажется что их код правильный, простой и понятный, а я потом смотрю на их трехэтажную поеботину, которую можно заменить десятком строк, и думаю "боженька убей их всех нахуй пожалуйста"
> ООП
Организация освобождения Палестины.
Пусть идёт на юриста значит.
Почему все мои знакомые экономисты не могут решить пример с простой матрицей?
Смешно пошутил, иди батю попроси дз на ИЗО нарисовать.
Вся проблема в уровне абстракции задачи.
Ясен хуй, чтобы записать в файл, вывести на экран или отправить по сети сообщение, клас нинужен.
Другое дело, что Васян мыслит абстрактно. Он не понимает ничего в файлах, сокетах и выводе на терминал. Он только понимает функцию "отправить". Таким образом, ты предоставишь Васяну интерфейс для вызова ф-ии печати, сохраняя возможность в любой момент поменять назначение отправки без изменения программы.
Ясен хуй, чтобы записать в файл, вывести на экран или отправить по сети сообщение, клас нинужен.
Другое дело, что Васян мыслит абстрактно. Он не понимает ничего в файлах, сокетах и выводе на терминал. Он только понимает функцию "отправить". Таким образом, ты предоставишь Васяну интерфейс для вызова ф-ии печати, сохраняя возможность в любой момент поменять назначение отправки без изменения программы.
>смотрю на их трехэтажную поеботину
Которую легко тестировать, отлаживать и повторно использовать в отличие от твоей процедурной дрисни.
>Выше простыню про абстрактные классы я что ли написал?
И где в этой простыне написано, что абстрактные классы - это фундамент?
У тебя с логикой проблемы?
>ко-ко-ко
Понятно, уебывай уже
В России свой особый путь и своя особая школа экономики ¯\_(ツ)_/¯
Я пидор
>Ясен хуй, чтобы записать в файл, вывести на экран или отправить по сети сообщение, клас нинужен.
Это смотря в каком языке.
Мы все тут
Няши, а поясните за покупку курсовой, кто их пишет, хорошо ли пишет? Стоит ли обращаться? Кто-нибудь покупал?
>Нет абстрактного мышления у человека
Первый и главный симптом ООП головного мозга - нагромождение излишних абстракций, впихивание их куда только можно. У вас Пердулятор генерирует Бурбулятор через фабрику Хуераторов, которые в свою очередь рефлексируют Мандуляторы через интерфейс Пиздулятора. Хуйню написал? А вот подумай, каково такой код читать.
Блестяще.
Ууу, шайтан, я не согласен с тобой. ООП не решает все задачи, и классы нужны абсолютно не всегда. Я говорил про конкретное использование ООП для простенького вывода.
Воннаби-джавист
Кто виноват в том, что ты не осилил ООП?
Это погромисты придумали наукообразных слов, чтобы чувствовать себя важными и поднять свое ЧСВ. Ведь погроммирование - лишь инженерная дисциплина, которая никогда не поднимется на уровень науки, им от этого обидно, вот они и написали уйму книжек с умными словами. А теперь нормальные аноны как ты не могут войти в тему, ведь обязательно должно быть СЛОЖНО и НЕ ДЛЯ ВСЕХ.
>Воннаби-джавист
Ну, и как ты в джаве будешь выводить информацию в консоль без ООП? Ведь придётся воспользоваться встроенным КЛАССОМ Console.
Вообще-то я сторонник умеренного ООП и за процедурную дрисню никогда не ратовал.
Это тот хуй начал тут абстракциями и полиморфизмом размахивать и рассказывать как он охуенно ООП знает
Ебал я это ваше ооп, и погромирование ебал сходил поучился и ебал эти костыли на костылях, и большинство этих ваших погромистов неадекватные криворукие дебилы заучившие эти свои 3 строчки наизусть нихуя их не понимающие.
>Console
Сишарпо-макака спалилась.
Братишка, я тебе про создание своих абстракций, своих интерфейсов и своих классов для решения этой задачи. Создание класса с ф-ей main() не в счёт.
Я, скорее всего, неправильно объяснил с самого начала.
>умеренного ООП
Что это значит? Сейчас вся современное сайтостроительство стоит на ООП. Все самые продвинутые фремворки — это реализация паттерна MVC.
Т.е. ООП говнокод априори правильный, а проблема всегда в том кто его читает и не может понять?
>Сишарпо-макака
Смешно такое слышать от того, кто хочет писать на джаве.
Нет, но по твоему тону складывается впечатление, что ты просто неосилятор.
Понять ООП можно только на практике.
Решай задачки на эту тему. Например на javarush.
Или пиши программы.
Полиморфизм многие понимают, но мало кто может объяснить что это такое своими словами.
>Сишарпо-макака спалилась.
>Смешно такое слышать от того, кто хочет писать на джаве.
Почему вы так друг друга ненавидите? Почему вы так хотите доказать, что ваш инструмент и подход единственно расово верный? Вы ебанутые? Вы что тут делаете?
ООП говно тормознутое и мегаусложненное. Открой любой фреймворк на ООП, увидишь там нагромождения говна, жрущие память, снижающие производительность и усложняющие читаемость. Единственное, почему нужно все это MVC говно, это что макаки не могут в нормальное процедурное программирование и реюз кода, потому без своего ссаного ООП копипастят код в тысячу файлов и он у них потом неподдерживаемый. Короче ООП это костыль для даунов.
По твоему тону складывается впечатление, что ты для решения СЛАУ тоже будешь использовать ООП.
Ты ОП-пост читал?
>Наследование, инкапсуляция хуе мое, интерфейс, абстактный класс, о чем вообще блядь
Так вот я пытаюсь донести, что это все не нужно начинающему для понимания ООП, оно только запутает новичка.
Именно так!
Я честно пытался найти библиотеку для отрисовки графиков на java, в которой бы не пришлось создавать кучу классов и всей хуйню, а просто вызвать статический метод Graph.plot(...., ...., Color.RED);
Везде ООПшный пиздец.
>макаки не могут в нормальное процедурное программирование и реюз кода
Привет, Линус
>Полиморфизм многие понимают, но мало кто может объяснить что это такое своими словами.
Двачую. Попробуйте это объяснить прямо сейчас.
Двачую. Попробуйте это объяснить прямо сейчас.
>основные принципы ООП не нужны новичку для изучения ООП
Ооок.
Способность объектов разных классов поддерживать общее поведение и функциональность.
mov dx, offset op
mov ah, 09h
int 21h
Различное поведение под одним и тем же названием.
Ясен хуй чтобы записать xml файл или отправить его по HTTP лучше написать класс.
Различная функциональность при одинаковых типах ссылок.
Возможность одного интерфейса(метода) иметь различные реализации.
Говно для быдла, не используй никогда.
Походу это самое лучшее определение.
Только с переопределением пересекается.
Ты это не перепутал ли с перегрузкой имен?
Я так тоже умею, а хули толку? Пока ты экономишь десять байтов в ядре, макака с современным MVC-фреймворком загрузит нахуй все твои десять ядер и 16 гигов
Оверлоадинг - вид полиморфизма, где под «названием» подразумевается имя функции.
ООП - хуй!
Дико охуенно объяснять другому всякие казалось бы очевидные вещи. Сразу находишь свои косяки и пробелы в знаниях.
> Нужно для этого же - чтобы легко пользоваться сложными вещами и не грузиться, чо там внутри происходит.
Еще для того чтобы изменяя внутреннюю реализацию для пользователя осталось все так же как и было. Типа заменили сраную шестерку на порш, но водитель в состоянии управлять и тем и другим.
Почему бы и нет?
Классы и интерфейсы будут такие:
EquationSystem:ISolve
Equation:ISolve
ISolve — интерфейс с методом Solve()
Equation e1 = new Equation();
Equation e2 = new Equation();
Equation e3 = new Equation();
EquationSystem system = new EquationSystem();
system.AddEquation(e1, e2, e3);
system.Solve();
Также можно решить отдельные уравнения:
e1.Solve();
Я пишу процедурную дрисню и использую стороннюю либу. Разработчик либы что-то там поменял, что-то переписал, но API прежнее, я ее использую как раньше.
Это инкапсуляция или что?
Это модульное программирование.
В чем отличие от инкапсуляции?
Инкапсуляция - один из принципов парадигмы ООП.
Модульное программирование - другая парадигма.
Пиздец, просто пиздец.
Нахуй мне твои парадигмы, отличие между ними в чем?
В подходе.
>Это инкапсуляция или что?
Да, инкапсуляция.
Я жду внятного ответа.
Либа инкапсулирует свои какие-то данные, и внутренние функции, как и объект. Снаружи нет доступа к этим данным. Какие тут принципиальные отличия?
Почему тогда инкапсуляцию называют основой ООП, если она широко используется без ООП?
Ну, в языке часто так бывает, что слова в зависимости от контекста имеют разные значения. Просто инкапсуляция — это, в сущности, очень широкий термин, обозначающий помещение чего-нибудь в оболочку, а в ООП — это один из основных принципов.
Нет классов. Loose coupling. Низкая поддерживаемость и мобильность.
> >стандартные "машина" - "колесо", "стул" - "офисный стул"
> ох уж эти уебские метафоры уровня хабра
Член - головка, анал - женский анал
Очень годно объяснил, ставлю лайк
Мне нравится ♥ 1
