Подробнее
Макс “такс такс" Джаз @maxjazzz - а чем объект отличается от класса? - вот Translate Tweet
приколы для образованных даунов со знанием программирования,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор
Еще на тему
приколы для образованных даунов со знанием программирования geek
Подробнее
Макс “такс такс" Джаз @maxjazzz - а чем объект отличается от класса? - вот Translate Tweet
приколы для образованных даунов со знанием программирования,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор
Подробнее
Макс “такс такс" Джаз @maxjazzz - а чем объект отличается от класса? - вот Translate Tweet
приколы для образованных даунов со знанием программирования,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор
Объект - это экземпляр класса. А класс - описание объектов и определение их методов (функций).
Чот ты быстро сдаешься, жесть ещё даже не началась.
Еще немного определений для разогрева:
Ковариантностью называется сохранение иерархии наследования исходных типов в производных типах в том же порядке.
Контравариантностью называется обращение иерархии исходных типов на противоположную в производных типах.
Инвариантностью называется отсутствие наследования между производными типами .
Ковариантностью называется сохранение иерархии наследования исходных типов в производных типах в том же порядке.
Контравариантностью называется обращение иерархии исходных типов на противоположную в производных типах.
Инвариантностью называется отсутствие наследования между производными типами .
Мы ещё инкапсуляцию не прошли а я уже на реакторе про Ковариантность читаю и наследование. Я тут деградирую или учусь?
это зависит от времени суток
Смотря по тому адепт чего - ООП или структурной логики. Если структурной - то конкретно сейчас деградируешь - все в порядке. Если ООП - срочно две дозы деграданта нужны!
Щас понабегут адепты того, что инкапсуляция — это сокрытие
Есть только фанаты смешных видосиков
О, сколько уже таких видосиков и статей напилили, про "правильное" объяснение ООП. ХЗ, все как-то понимают ООП по-своему, но особо это не мешает. Хотя количество людей с ООП головного мозга, пихающие ООП куда можно и куда нельзя, удручает.
Так блэт, могут гуру ООП пояснить простому сишнику с фетишем на ФП, какого хуя тут происходит?
Я позволю себе слегка изменить код из видео, а именно, переименовать аргументы.
// C
double getDistance(Point* this, Point* other);
// C#
double getDistance(Point other);
Т.е. мы добавляем по-сути синтаксических сахар, позволяющий не прокидывать this явно, и всё, ниибацца инкапсуляция, ниибацца ООП? Что-то звучит как сильное заявление. Как по мне, семантически две функции выше одинаковы, просто у второй есть сахар.
Я позволю себе слегка изменить код из видео, а именно, переименовать аргументы.
// C
double getDistance(Point* this, Point* other);
// C#
double getDistance(Point other);
Т.е. мы добавляем по-сути синтаксических сахар, позволяющий не прокидывать this явно, и всё, ниибацца инкапсуляция, ниибацца ООП? Что-то звучит как сильное заявление. Как по мне, семантически две функции выше одинаковы, просто у второй есть сахар.
Во втором случае нет прямого доступа к полям X и Y и метод работает напрямую с данными текущего объекта. Вот 2 отличия, а то, что this передаётся автоматом - к делу не относится.
В первом случае, у нас нет прямого доступа к this - то есть нет доступа к внутреннему состоянию объекта. Тогда получается, что Point уже будет просто структурой данных, а getDistance - функцией. То есть, то самое функциональное программирование, когда при одинаковых входных параметрах, получим одинаковый результат, так как он не зависит от внутреннего состояния (к которому нет доступа).
Во втором случае есть доступ к this и функция превращается в метод, результат которого может зависеть от внутреннего состояния. Соответственно, и Point становится уже не структурой данных, а объектом, обладающим внутренним состоянием и зависящим от него поведением (реализуемое методами)
Во втором случае есть доступ к this и функция превращается в метод, результат которого может зависеть от внутреннего состояния. Соответственно, и Point становится уже не структурой данных, а объектом, обладающим внутренним состоянием и зависящим от него поведением (реализуемое методами)
собственно, это и есть магия ООП - когда переходим от структур данных и функций к объектам, обладающим внутренним состоянием (набором полей) и поведением (с прямым доступом к состоянию).
ну и ООП - это не новые законы вселенной, а просто следующий уровень абстрагирования, реализуемый неким набором сахара в языке. И этот сахар позволяет не заниматься микроменеджментом с передачей this и его полей во все функции, а работать на уровне абстракции "объект", который сам может разобраться как работать со своими полями
Все ещё не понял. Смысл в сахаре или нет?
Я всегда могу сделать мысленный финт ушами и на уровне соглашения сказать, что первый аргумент - это this, и функция зависит от его внутреннего состояния. Как, собственно, и сделано в каком-то GTK.
Переходим от структур данных и функций к объектам с внутренним состоянием и методам.
typedef struct foo foo_t;
void foo_do_shit(foo_t* this);
int foo_get_hui(foo_t* this);
Как по мне, различие исключительно синтаксическое, а не семантическое.
Более того, могу сделать финт ушами и сделать сахар, пусть он и не так привычен, как точка.
#define M(this, method, ...) (method(this, __VA_ARGS__))
M(my_foo, get_hui);
Я всегда могу сделать мысленный финт ушами и на уровне соглашения сказать, что первый аргумент - это this, и функция зависит от его внутреннего состояния. Как, собственно, и сделано в каком-то GTK.
Переходим от структур данных и функций к объектам с внутренним состоянием и методам.
typedef struct foo foo_t;
void foo_do_shit(foo_t* this);
int foo_get_hui(foo_t* this);
Как по мне, различие исключительно синтаксическое, а не семантическое.
Более того, могу сделать финт ушами и сделать сахар, пусть он и не так привычен, как точка.
#define M(this, method, ...) (method(this, __VA_ARGS__))
M(my_foo, get_hui);
Если очень упростить, для наглядности, то класс - например, человек как обобщенная идея, типа две руки, две ноги, функции типа дыхание и так далее; объект класса человек - вот лично ты, либо лично я, либо лично Вождь.
Немного не понял, если человек это класс то объектами будут руки которые выполняют функцию хватать или ноги которые выполняют функ. бега?
Человек - класс, ты - объект
хватать, бегать - уже будут методы этого класса/объекта. Класс содержит в себе инструкцию, как работает метод(так же определенные свойства, которые может получить при объявлении или иметь сразу, чтобы применять их в методах), а объект использует всё это уже на практике(Объектов может быть сколько угодно и все они могут идти от одного класса, например пользователи и их методы для отправки коммента и свойства вроде имени).
Класс это концепт, как чертеж здания на бумаге. Физического воплощения не имеет.
А вот уже "объект класса" это здание которое построили по этому чертежу.
А вот уже "объект класса" это здание которое построили по этому чертежу.
Класс - человек как вид.
Экземпляр - конкретный человек (как и написали - ты, я, вождь).
Экземпляр - конкретный человек (как и написали - ты, я, вождь).
Шлюха это экземпляр под мамкой. А мака это юнит содержащий описание объектов и определение их методов (функций).
Давай к нам в Си, у нас ни ООП не эксепшенов.
Инклуд пайтон онп.
Инклуд пайтон онп.
ООП - это парадигма, а не какая-то конкретная совокупность фич языка. (Оставлю за скобками, что ООП в С++/Java/C#/итпитд и тот исходный ООП в Smalltalk сильно отличаются).
Сишный GTK - вполне себе близко к ООП. Пример: https://developer.gnome.org/gtk3/stable/GtkButton.html
В общем, ничего не мешает писать на си в неком подобии ООП-стиля, разве что this придется передавать вручную. Виртуальное наследование? Их есть у меня. Яркий пример - это Linux Kernel, где модули определяют какой-то определенный интерфейс в виде структуры с указателями на методы, которые ты у себя в модуле реализуешь (всякий init, open, write, read итп).
Наследования без извратов нет, да. Хотя есть мнение, что наследования не нужны (с)
Ну а вообще, давай к нам в Rust, здесь нет ООП и эксепшенов, зато есть трейты, this вручную передавать не надо, типы-суммы и зайчатки ФП.
Сишный GTK - вполне себе близко к ООП. Пример: https://developer.gnome.org/gtk3/stable/GtkButton.html
В общем, ничего не мешает писать на си в неком подобии ООП-стиля, разве что this придется передавать вручную. Виртуальное наследование? Их есть у меня. Яркий пример - это Linux Kernel, где модули определяют какой-то определенный интерфейс в виде структуры с указателями на методы, которые ты у себя в модуле реализуешь (всякий init, open, write, read итп).
Наследования без извратов нет, да. Хотя есть мнение, что наследования не нужны (с)
Ну а вообще, давай к нам в Rust, здесь нет ООП и эксепшенов, зато есть трейты, this вручную передавать не надо, типы-суммы и зайчатки ФП.
P.S. Напиздел. Наследование в сишечке можно сделать путем копипасты всех полей структуры с дописыванием новых полей снизу. Если лейаут полей "базового класса" сохранен, то указатель на "потомка" можно спокойно приводить к указателю на "базовый класс".
Пример такого непотребства - интерфейс сокетов, в котором передается указатель на структуру описания всякого адреса, которая зависит от типа протокола.
Пример такого непотребства - интерфейс сокетов, в котором передается указатель на структуру описания всякого адреса, которая зависит от типа протокола.
Сутенер выкладывает на сутенерском хэдхантере вакансию проститутки с определенным набором качеств, которыми должен обладать потенциальный кандидат. Сам текст объявления - это класс.
Человек, который подошел по всем параметрам, и отправился обслуживать клиентов - это объект этого класса. Работать может несколько человек по одной вакансии.
Человек, который подошел по всем параметрам, и отправился обслуживать клиентов - это объект этого класса. Работать может несколько человек по одной вакансии.
Тут скорее вакансия - это интерфейс
интерфейс - это уже то как клиент вызывает проститутку. Он может не знать о ее венерических заболеваниях и о том, насколько хорошо она выполняет свои функции. Он знает точно только то, что функция "раздвинуть ноги" есть.
Ну так всё, что ты описал, применимо и к вакансии.
а хэдхантер - адаптер для сутенера
Иди но не забывай! Класс это тоже объект!
когда меня просят объяснить это, я всегда сравниваю класс с чертежом
подробней пожалуйста
Класс - чертёж болта.
Объекты - изготовленные болты.
Объекты - изготовленные болты.
Давай проще, у тебя есть завод который делает жигули.
Жигуль как совокупность чертежей для его производства и работы это класс.
Но каждый произведенный жигуль это объект этого класса, со своим порядковым номером и прочим.
Жигуль как совокупность чертежей для его производства и работы это класс.
Но каждый произведенный жигуль это объект этого класса, со своим порядковым номером и прочим.
Вообще-то нет. Класс и экземпляр класса, в зависимости от реализации на конкретном ЯП, оба могут быть объектами.
А его определение этого и не исключает
Класс - это описание или определение структуры, а объект - это сформированный по этому описанию участок памяти (переменная), который ты уже можешь изменять, этих участков (объектов) может быть сколько угодно. И объект класса может быть частью структуры другого класса.
П.С. Не понимаю за что заминусили, человек не знал, человек спросил.
П.С. Не понимаю за что заминусили, человек не знал, человек спросил.
Всё пацаны, я уже почитал теорию, понял, осознал. Всем спасибо за ответы!! Не ожидал что реактор заставит меня лишний раз открыть книгу. Будет экзамен, мб отчитаюсь (но это не точно)
Класс - ДНК Джанго Фетта
Объекты - клоны Джанго Фетта
Объекты - клоны Джанго Фетта
> Я не спец, но объект это переменная в классе же?
ну, чисто по-дружески можно так сказать: "объект - это переменная, с типом = какому-то классу"
это когда совсем тяжко понимать.
но с уровня "универ" и выше такое уже не простят.
то, про что ты, это запись:
var a = new MyClass(); (создали объект класса, и связали его с этой переменной)
но НА САМОМ ДЕЛЕ можно написать и просто new MyClass() (создали объект класса), без присваивания переменной. Это нормально, но ты не сможешь добраться до этого объекта и сделать с ним что-либо ещё, а в некоторых системах он будет удалён как "мусор".
Объект это не переменная, но объект может быть "указан" под переменной (самому объекту будет похуй, он не в курсе что на него ссылается переменная).
ну, чисто по-дружески можно так сказать: "объект - это переменная, с типом = какому-то классу"
это когда совсем тяжко понимать.
но с уровня "универ" и выше такое уже не простят.
то, про что ты, это запись:
var a = new MyClass(); (создали объект класса, и связали его с этой переменной)
но НА САМОМ ДЕЛЕ можно написать и просто new MyClass() (создали объект класса), без присваивания переменной. Это нормально, но ты не сможешь добраться до этого объекта и сделать с ним что-либо ещё, а в некоторых системах он будет удалён как "мусор".
Объект это не переменная, но объект может быть "указан" под переменной (самому объекту будет похуй, он не в курсе что на него ссылается переменная).
Вот не знал человек, вопрос задал, а вы ему минусов налепили. Не надо так.
Объект это - SCP, а класс это - Кетер.
Класс - шаблон для создания объектов. Все, а не вот эти все ваши пространные объяснения с хабров, кто длиннее.
Собака - это класс. Барбос - объект.
На картинке ситуация, когда объект одного класса охраняется объектами другого класса.
А еще можно сказать, что класс - это контракт, объект - поставки по контракту.
На картинке ситуация, когда объект одного класса охраняется объектами другого класса.
А еще можно сказать, что класс - это контракт, объект - поставки по контракту.
Отличный комментарий!