>Java
>ООП
Нет пути. В Java оче сложно сделать чтобы было ООП.
>ООП
Нет пути. В Java оче сложно сделать чтобы было ООП.
Но Java и есть ООП. Это первая глава почти в любой книге про Java.
ООП - это архитектура, состоящая из полноценных и самодостаточных объектов, общающихся через отправку и получение сообщений. Всё состояние в программе инкапсулировано внутри объектов, объекты не обязаны предоставлять доступ к своему состоянию.
Java - это язык, позволяющий для некоторых типов переменных определять дополнительную структуру. Общение элементов происходит через вызовы методов, каждый объект рутинно вывешивает своё состояние наружу через геттеры, которые не просто можно - нужно вызывать.
а вызов методов по твоему не общение объектов?
ООП - ничего общего к архитектуре не имеет, это подход.
Интуитивно понятный код - уже неплохо, код, который при этом еще и можно комфортно поддерживать и допиливать - вообще супер. Главное, чтобы код приносил пользу.
Сам почему-то всегда замечал, чем идеальнее внутри - тем с большей вероятностью продукт не приносит пользы ( = никому не нужен) и наоборот. Особенно ,если это какой-то стартап.
Интуитивно понятный код - уже неплохо, код, который при этом еще и можно комфортно поддерживать и допиливать - вообще супер. Главное, чтобы код приносил пользу.
Сам почему-то всегда замечал, чем идеальнее внутри - тем с большей вероятностью продукт не приносит пользы ( = никому не нужен) и наоборот. Особенно ,если это какой-то стартап.
Для твоей задачи вообще никаких ооп не нужно, без задней мысли пишешь функцию/метод которая дергает апи, и возвращает результат в виде какой-нибудь структурки.
Что там твой изобретатель ООП подразумевал под этим тремином - никого уже не ебет. Де-факто наиболее распространенное определение - это как раз джава/с++ стайл, как бы таким как ты от него не пекло.
"Я раньше поражался тому, как уродливы изнутри «взлетевшие» проекты. Сейчас я знаю: красивые проекты не взлетают, потому что они не успевают взлететь. Пока инженеры в белых халатах прикручивают красивый двигатель к идеальному крылу, бригада взлохмаченных придурков во главе с безумным авантюристом пролетает над ними на конструкции из микроавтобуса, забора и двух промышленных фенов, навстречу второму туру инвестиций. Авантюрист любезно раздаёт восторженным пассажирам талоны и бумажные пакетики."
Это может быть "общением объектов". Но для вызова метода нужен экземпляр получателя, а для отправки сообщения - нет. Улавливаешь или ещё больше разжевать?
Разжуй.
мимо другой анон
Само существование "метода" организует утечку прав объекта на управление своим состоянием. В этом плане даже objective-с больше ооп-язык, чем java.
Отправка сообщения безусловно требует только наличие среды для распространения сообщений, но любое сообщение может быть предназначено и для одного адресата, и для нескольких или вообще ни для кого, в зависимости от конфигурации или текущего состояния программы.
Причем отсутствие адресата не обязано быть проблемой отправителя, если отправитель не ожидает реакции адресата.
При вызове метода отсутствие отправителя приводит к NullPointerException, например, и из-за этого отсутствие адресатов всегда является проблемой отправителей.
>При вызове метода отсутствие адресата
Самопочин
> джава/с++ стайл
А ничего, что у это два разных оопа?
>Улавливаешь или ещё больше разжевать?
Ага.
>Это может быть "общением объектов". Но для вызова метода нужен экземпляр получателя
Двое друзей беседуют
>а для отправки сообщения - нет.
Долбоеб беседует с пустотой
> Двое друзей беседуют
Один деспот командует другим.
> Долбоеб беседует с пустотой
И мешает жить всем остальным.
> Ага.
Походу нет.
Не про фасад ли ты случаем?
Сообщения или методы - это сорта говна.
По сути одно и то же, различается реализацией.
Для методов есть менторы - мониторы, отвечающие за наш сегмент, к которым можно обратиться для посылки писем другим менторам и подписывания на чужие рассылки, и которые пнут нас если нам придет письмо.
Плюсы: контроль доступа - о тебе знает только твой ментор, никто кроме него тобой не воспользуется. Отвечает философии ООП: все инкапсулировано по максимуму, все безопасно.
Минусы: нужен ментор.
Для сообщений ситуация обратная: никто никого не знает, но все могут подписаться на любого. Живешь как шалава: любой может воспользоваться. Никакого контроля.
Проблему ограничения доступа решают... те же менторы.
Т.е. в любом случае проблем с сообщениями нет.
Только в одном случае ментор обязателен и все безопасно по дефолту, а в другом ничего не безопасно, зато ментор по желанию.
Философия жабы - первый подход: он более строг и безопасен.
Философия сишек - второй подход: он более свободен, зато как всегда, по традиции сишек, небезопасен, и легко наворотить делов.
Зачем слать сообщения тому, кого не существует?
Опять со своим выдуманным другом Славиком разговариваешь?
Методы более логичны: ты обращаешься только к тому, кто существует.
оопе - эта smalltalk
Ну вот собственно очередное подтверждение. Вместо того чтобы искать решение, программач начинает маневрировать и самоутверждаться - "Ваше ООП это не ООП", "Ваш ЯП не ЯП", "Давайте устроим еще один ненужный языкосрач".
Потому что если твоему объекту надо нарисовать прямоугольник в центре экрана, то он запрашивает размеры экрана. В случае с сообщениями, ответственного за размер экрана объекта может вообще не быть. Или вместо него кто-то другой может вернуть размер листа принтера. Или при первом запросе разрешения экрана может ответить один объект, а при втором - другой, потому что его подменили в рантайме без рекомпиляции.
>любой может воспользоваться
Поговорить. Это только в ваших жабах и крестах могут воспользоваться.
И где они там разные? Те же самые классы-хуясы, полиморфизм-наследование-инкапсуляция.
А чего ты хотел-то? Так как даже понятие ООП неоднозначно определено.
Ну и конечно никто нахуй тут не заинтересован за тебя писать твой курсач или что там это у тебя про скачивание данных. Так что на код можешь не рассчитывать.
> НО! Это должен быть код и архитектура, к которому не подъебешся
Так не бывает. Архитектура не формализованное понятие, которое каждый дебил понимает по своему. Ты пытаешься технически решить проблему, которая решается фразой - "Пшел нахуй пес".
Я и говорю, хуета какая-то получается: хочешь узнать размер экрана, а не у кого, или какой-то левый тролль тебе присылает вместо размера экрана размер листа принтера, а ты его принимаешь за размер экрана и получаешь пиздец.
В жабах хоть какие-то механизмы безопасности, сишка же пиздец, голой жопой светит, любой мимокрокодил может писать/читать что угодно, без спросу, и фиг ты что сделаешь с этим.
> а что если я хочу узнать смещение поля относительно начала объекта
Батенька, если вы выбрали парадигму, которая не удовлетворяет вашим хотелкам, то это не значит, что ошибка в парадигме. Ошибка в ваших хотелках, вы организовали код так, что он приходится менять парадигму. В вашем примере, нужно писать так, чтобы вам не нужен был размер экрана.
Очень неплохо описан message queue. Добавь триггер ивентов по дате и получишь reactive programming. К ООП-у описание никакого отношения не имеет.
>какой-то левый тролль тебе присылает вместо размера экрана размер листа принтера, а ты его принимаешь за размер экрана и получаешь пиздец
Нет, получаешь пиздец ты не потому, что тебе прислали не то, а потому, что ты долбоёб. Во время работы программы экран заменили на принтер - теперь тебе надо печатать на принтер. Ты же нарушил все абстракции и закономерно получил хуйню. Страдай, что тут ещё можно сказать.
А вообще, ты не поймёшь, потому что blub programmer эффект.
То размер экрана нужен, то внезапно не нужен... Пожалуйста, ты уж определись там!
Пацаны жалуются, нихуя ж не понятно что делать.
Зачем это нужно? Да вот просто я столкнулся на просторах интернета с тем, что в принципе нет никаких стандартов того, как должно выглядеть хорошее приложение, любое приложение обосрут. Более того, некоторые программисты имеют свойство противоречить друг другу в вопросах того , что является хорошим примером ООП. Абсолютно непонятно на что ориентироваться. Почему непосильная задача для программача? Да потому что я также ни разу не встречал здесь такого, чтобы чей-либо код назвали хорошим. Вот мне и интересно, каким видит хороший или даже идеальный код программач.