>наследуем хлеб от крючка приватно.
Ты из тех долбоебов которые делают танк наследуя его от колес и пушки?
Cначала надо писать тесты.
>очевидно удочку надо относледовать от палки
>очевидно что груз это базовый класс. от него наследуються крючок и поплавок.
>тогда надо относледовать хлеб от крючка.
Программач поясняэ
Собрать удочку без наследования, композицией и не ебать мозги.
Ретвитнул.
>наследуя его от колес и пушки?
>наследуя
>колес и пушки
С++ говноед незаметен
Пишу в ЭПИЧНОМ треде.
Оп забыл, что есть такой прекрасный паттерн как обсервер. Таким образом, хлеб становится observable и при поедании его рыбой (sic!) сообщает об изменении крючку, который вызывает у рыбы метод попасться(). Если вызов удачный то крючок (сам являющийся observable) вызывает зарегистрированный метод лески, которая в свою оучередь натягивается(), сообщая об этом катушке и удочке, которые принимают решение согласно бизнес-логике, порвать леску или нет.
В целом такой изящной конструкцией мы инвертировали зависимость ключка от картошки (очевидно что картошка не должна плавать на воде) и избавились от по-моему ненужного грузила.
В тред приглашаются знатоки GoF, приветствуются непосредственные члены GoF, если тут такие есть. Поясните, какие паттерны еще стоит применить в нашей конструкции.
Оп забыл, что есть такой прекрасный паттерн как обсервер. Таким образом, хлеб становится observable и при поедании его рыбой (sic!) сообщает об изменении крючку, который вызывает у рыбы метод попасться(). Если вызов удачный то крючок (сам являющийся observable) вызывает зарегистрированный метод лески, которая в свою оучередь натягивается(), сообщая об этом катушке и удочке, которые принимают решение согласно бизнес-логике, порвать леску или нет.
В целом такой изящной конструкцией мы инвертировали зависимость ключка от картошки (очевидно что картошка не должна плавать на воде) и избавились от по-моему ненужного грузила.
В тред приглашаются знатоки GoF, приветствуются непосредственные члены GoF, если тут такие есть. Поясните, какие паттерны еще стоит применить в нашей конструкции.
Рыба должна быть Flyweight, потому что ее много и надо сэкономить память. Самый охуительный паттерн в мире.
А вода синглетон?
Спасибо, проблевался. Мудак, открой для себя композицию и о наследовании вспоминай в самую последнюю очередь. Хлеб он собрался наследовать от груза... ну ахуеть теперь
Так уж и быть, научу детей ООП. Ок, давайте опишем удочку с точки зрения ООП. Для начала надо посмотреть на задачу, что нам требуется сделать. Найти условия задачи в потоке бессвязного бреда довольно трудно, но мы будем исходить из предположения, что Удочка способна поймать Рыбу, а также, мы можем снять пойманную Рыбу. При этом очевидно что на Удочку на которой уже есть Рыба, поймать ничего не получится.
Если не сделать это предположение, то так как никаких требований к Удочке нет, класс Удочка можно описать так:
class FishingRod {}
Так неинтересно, потому решим задачу в соответствии с придуманными требованиями. Итак, очевидно что на Удочку может быть поймана Рыба, и может быть не поймана. Сделаем свойство для хранения пойманной Рыбы, и сразу же методы для ее ловли/снятия.
class FishingRod
{
private $caughtFish;
public function catchFish(Fish $fish) { ... }
// возвращает Рыбу
public function removeFish() { ... }
}
Насчет самой Рыбы, неясно, есть ли у нее какие-то свойства — если нет, хватило бы поля типа bool вместо объекта, потому придумаем условия что Рыба бывет разных видов и веса.
class Fish
{
const TYPE_PIKE = 1;
const TYPE_SWORD_FISH = 2;
const TYPE_SHARK = 3;
private $weight;
private $type;
public function __construct($type, $weight);
}
Ну и раз есть вес, то вдобавок можно сделать допольнительные проверки: например, сделать Удочке свойство МаксимальныйВес и проверять, выдержит ли она Рыбу или нет (выбрасывать в этом случае исключение RodBrokenException).
Молодец, хорошо сделал. А потом ты уйдешь, и окажется, что нам надо несколько разных удочек, и мы будем переписывать весь проект.
Переписывайте, ебет ли меня.
Продолжай, я заинтригован. Потом вам понадобятся не только удочки, но и лопата.
FishingRod implements FishingDevice
class FishingDeviceFactory {
public FishingDevice getFishingDevice(int fishCapacity);
}
Если вы не разбираетесь в ООП то да, будет тяжко. А так, ООП как раз делает код более гибким и позволяет вносить изменения меньшей ценой.
Алсо, эта тема пару лет назад разжевывалась на Хабре:
http://habrahabr.ru/post/153225/
http://habrahabr.ru/post/153845/
ОП просто не осилил ООП (видимо в его книжке про перестановку байтов этой темы нет) вот и переживает.
ПХП макака не могла не обосраться и вместо удочки создала палку для хранения рыбины. Как через объект такого класса выразить одевание наживки, забрасывание, мониторинг поплавка, подсекание, вытягивание и прочие вещи которые делают из палки удочку - непонятно.
>груз это базовый класс. от него наследуються крючок и поплавок
> ПХП макака не могла не обосраться и вместо удочки создала палку для хранения рыбины
;DD
>;DD
А ну-ка съебал отсюда!
Неистово двачую данный пост.
Даже это
>ОП просто не осилил ООП
тоже хотел написать.
Например, у тебя есть такие сущности - клиент и покупатель. Ты, как человек, знаешь, что обе эти сущности представляют тоже люди, и чтобы тебе было легче ориентироваться в системе наследуешь их от общего класса Person. Ведь это максимум логично. Да. Но потом ты смотришь на это, плачешь и бежишь создавать в /pr/ тред о том, что ооп говно.
В описанном примере наследовать от общего класса не стоит, если у сущностей нет ничего общего. Да, и то, и то это люди, но если в контексте твоей программы они не пересекаются, то и наследование нинужно, это абсолютно разные классы.
> но если в контексте твоей программы они не пересекаются, то и наследование нинужно
два чая этому товарищу.
а есь чонить подобное про рекурсии? тоже охота ебануться на всю бошку такими аллегориями
Сколько макак клюнуло на ОПа-толстяка и даже не заподозрели, что навернули тухлого гавнеца.
Лол.
Школоло детектед.
В рекурсиях нет ничего сложного для понимания, это способ решения задач вроде быстрой сортировки или просмотра дерева каталогов, и только-то.
Niet, рекурсия хорошо даже в бузинесс-логике (обработка структурированных данных бывает той еще сукой)
Поссал на безграмотного дауна-позёра
Удочка - это слишком плохой пример для изучения ООП.
Гораздо интереснее изучать ООП на примере педо-леса:
есть класс Лоля, у неё есть атрибуты:
- имя
- возраст
- желание
- опыт в обычном сексе
- опыт в анальном сексе
- опыт в оральном сексе
и следующие методы:
- быть отняшенной в писю(Лолиёб кем)
- быть отняшенной в попу(Лолиёб кем)
- быть отняшенной в рот(Лолиёб кем)
- отняшить ртом(Лолиёб кого)
- выдать статистику
По аналогии создаём класс Лолиёба. А так же необходимо игровое поле Педолес, который разбиваем на клетки и располагаем в нем лолей и лолиёбов. По очереди при помощи генератора случайных чисел передвигаем лолей и лолиёбов и если они встречаются в одной клетке, то в зависимости от желания и генератора случайных чисел, применяют друг-на-друга различные методы.
Применение методов, лучше всего при этом снабдить выдачей в консоль соответствующих комментариев. Так же, можно сделать возможным, что бы один из лолиёбов или одна из лолей находился/лась в прямом управлении пользователя.
ПИДАФИЛ!!111
Господи, на что я трачу свою жизнь. http://rghost.ru/private/60083028/b4fda828dc8f66185c0da9603ffd50cb 2ch
Спроси у Цивеника, он в этом плане переплюнул тебя раз в 20.
Касательно кода: coin_flip() и generate_name() к классу Loli не относятся, их надо вынести в топ-левел. Алсо, мог бы и рогалик сделать при помощи escape-последовательностей.
А, еще. "_orally", "_anally", "_vaginally" - тебе не кажется, что код с этими вещами довольно сильно повторяется? Зделой признак "how", который будет равен ANALLY, ORALLY, VAGINALLY, например.
Очень хорошо получилось, правда можно сделать еще ряд улучшений, например, самое простое - это добавить несколько лолиебов, так как с одним скучно и собирать статистику и для них.
Ну и самое пожалуй сложное - это написать более интересные диалоги при сексе: зависящие от возраста, опыта и опционально от рэндома.
Я сам когда пытался это сделать, мне это не удавалось, так как после написания нескольких фраз, у меня появлялся дикий стояк и дальше продолжать не было никакой возможности.
http://rghost.ru/private/60087504/52505f9672f509ef2f627bfb9569847e
1.01rc
В диалоги я не умею.
Детект в pedobear.process(loli) тоже сделан бездумно, и его надо как-то менять (но я не знаю как, без разделения обработки на два прохода). Алсо, ооп в пистоне - неудобный пиздец.
>Спроси у Цивеника
Кто такой, чем знаменит? Не гуглится. Я знаю только парня с форчана с его loli raep sim.
1.01rc
В диалоги я не умею.
Детект в pedobear.process(loli) тоже сделан бездумно, и его надо как-то менять (но я не знаю как, без разделения обработки на два прохода). Алсо, ооп в пистоне - неудобный пиздец.
>Спроси у Цивеника
Кто такой, чем знаменит? Не гуглится. Я знаю только парня с форчана с его loli raep sim.
какие же вы все дебилы
у удочки не может быть никаких методов, это тупо предмет
логика может находиться только в рыбаке
у удочки не может быть никаких методов, это тупо предмет
логика может находиться только в рыбаке
> Кто такой, чем знаменит?
Ну ты даешь. Это же http://ru.linkedin.com/in/variousfurriness/en , разводчик фуррей на Рубях.
А, этот. Я его под именем Мяуки знаю.
пидор блять как наживку тогда одевать?
как забрасывать?
как подсекать?
как рыбу снимать?
уёбуй тварь говно
fishman.Fishing(Rod rod){};
мимо
мимо
коза.ебись (онегин);
Какая нахуй удочка, че ты там написал.
У тебя есть класс Vehicle с методом drive.
От него наследуются классы Car и Train.
Все блять /thread
http://rghost.ru/private/60102498/0d11f2bb191864e4da59559eb77245fc
Применил паттерны KIFS и YAGNATS. Совершенно непонятно, как делать взаимодействие между объектами - вот уж где ооп сосёт с причмокиванием.
Применил паттерны KIFS и YAGNATS. Совершенно непонятно, как делать взаимодействие между объектами - вот уж где ооп сосёт с причмокиванием.
пиздец как ты далек от рыбалки, грузило у него леску рвет, у лески методов нет, охуеть теперь, дальше не читал.
Начнем с того что нужно подбирать вес груза, для этого есть приватная переменная и сеттер, который заранее не дает ставить такой груз который своей тяжестью вызовет интерфейс из класса лески который ее рвет. Ты написал хуету.
Что вы тут блядь все несете, дибилы сука?
Здесь от удочки должен наследоваться кручек с рыбой (насаженной), где рыба наследуются от привычного анимал, а леска наследуется от черенка, а грузы уже от лески. Далее по цепочке вызываем методы от наследованных объектов, получаем профит. Всё!
В данном конкретном примере с удочкой, вообще ничего не нужно наследовать, а следует применить агрегацию (или композицию), т.е.
класс Удочка, должен состоять из параметров:
грузило, леска, крючек, палка, барабан (и какие там еще составные части у удочки?)
Наследование имеет смысл только тогда, когда Класс-Ребенок - это подвид Класса-Родителя, например:
Автомобиль -> Волга 2110
Животное -> Собака
Персоонаж -> Лоля
Это у тебя наследование интерфейсов. Мы пишем на C/C++.
Зачем ты испортил возраст девочек? А вообще, с диалогами лучше конечно стало, впрочем диалоги к сожалению весьма однообразны.
Это не важно на чем вы пишете.
Наследовать составные части предмета друг от друга, когда нужно применить агрегацию (или композицию) - это высший идиотизм.
Кстати да. Умение определять когда A, B, C являются частными случаями D, а когда D состоит из A, B, C похоже важнейшее в ООD.
Хотя я как-то давно разочаровался в наследовании и использую онли композицию и интерфейсы, полёт нормальный. Иногда хочется взять и заебашить всё на наследовании, так как проще, но потом когда вспоминаешь эту хрупкую абстракцию, эти уёбищные пятиэтажные деревья наследования, в которые в результате все разрастается, то быстро бросаешь эту задумку.
Попытался научить их ходить и обосрался. Зато есть мысли как отрефакторить тот пиздец, который в диалогах.
Поправь, делов-то.
Поправь, делов-то.
>Попытался научить их ходить и обосрался.
В чем проблема? Это же не очень сложно
>Зато есть мысли как отрефакторить тот пиздец, который в диалогах.
Вообще, на мой взгляд, для большего интереса, стоит создать целый сложный массив (или набор массивов) с диалогами. (Можно все это положить в отдельный файл).
> очевидно удочку надо относледовать от палки
И сразу файл, дальше не читал.
Удочку следует отнаследовать от абстрактного класса инструментов, а палкой следует композиционно расширить этот класс
http://rghost.ru/private/60121102/c310cef0faab04b3d9de5e6ab7d3e6f9
Надо же правильно сделать. Вообще, там надо будет весь лес переписывать, а мне было лень, а как сделать попроще я не осилил.
Диалоги писать сложно.
Надо же правильно сделать. Вообще, там надо будет весь лес переписывать, а мне было лень, а как сделать попроще я не осилил.
Диалоги писать сложно.
В общем, если подумать, то я начинаю понимать, откуда появляются паттерны. Вот такая, казалось бы, простая задача, которая не в ООП стиле решается со скоростью набора текста на клавиатуре, тут превращается в полный пиздец. Вот, например, диалоги у меня вставлены рандомно между строками кода. Это неправильно. А чтобы сделать красиво, поддерживаемо и вообще, надо вводить полноценную систему сообщений. Лолиёб видит лоли, отправляет себе сообщение, некий "модуль диалогов" его перехватывает и выбирает реплику, которая отсылается лоли (и печатается в консольку). Лоля получает это сообщение и как-то реагирует, отсылает сообщение лолиёбу, и т.д. и т.п.. Но я не хочу это делать; слишком много лишнего кода ради ничего. Задача-то решена, в принципе. Дальше только развитие вширь, с добавлением вытекающей спермы, диаметров отверстий/хуйцов и всего такого, но это уже не сильно интересно. Разве только управление прикрутить и цветное отображение.
Архив сломан.
У меня открылось. Либо пароль неправильно вбил, либо перекачай.
Либо прыщепроблемы. Перепакуй в 7z какой-нибудь, плиз.
А, отбой. Нужно было `unrar-nonfree` юзать.
Добро пожаловать в волшебный мир ынтырпрайза!
…Тебя ждет увлекательный мир XML и dependency injection…
> dependency injection
Ненужная хуйня. Потому как все это вырастает потом в SendMessage(ISender sender,IMessage msg,IReceiver receiver). И ты ахуееваешь от этой ненужной иерархии.
>XML
Сжечь нахуй
+
> Сжечь нахуй
А ты попробуй сжечь все эти километры говна и конфигов. И бизнесменов-пидорасов, которые это говно проталкивают в моё IT.
>>XML
>Сжечь нахуй
Почему? Вроде удобно если использовать без фанатизма, всяк лучше просто текста.
> ненужная хуйня
А тестировать мы не будем? Или ты из этих.. кто код с первого раза рабочий пишет и без багов?
> без фанатизма
Понимаешь, XML действительно удобен как язык разметки (хотя я бы предпочел аналогичный вариант SGML с «</>» в качестве закрывающего тега), но так как в подавляющем большинстве случаев, с которыми я имел дело, его используют неуместно, то лучше пусть его сожгут вообще, нахуй.
Не, ящитаю ты неправ. XML должен существовать, чтобы на него как мухи на говно слетались разные идиоты от мира программирования. Сожгут XML - они ПРИДУТ ЗА ТОБОЙ
не "попасться()" а "съесть()"
Вообще-то не съесть(), юноша, а клюнуть(). Действительно, тогда рыба будет унаследована от птицы (через Dependency Injection примесь)
Как может рыба по собственному желанию клюнуть? Он только хочет есть.
используй гист наконец
> XML
> удобен как язык разметки
сосёт у s-выражений с причмокиванием
Там регистрироваться надо, ник придумывать.
А вот всё это делает как раз рыбак. То есть рыбак наблюдает за удочкой (implements Runnable), а Рыба попадается на удочку в случайный момент времени (она может кружить вокруг удочки и покусывать приманку, может попасться на крючок, то есть она тоже implements Runnable).
Я могу тебе придумать ник.
moms_pineapple
Пароль сам придумаешь. Поставь прогу какую-нибудь, если не можешь.
у удочки, у разичных её частей, есть стейт
крючёк с червём, без червя, с рыбой, папловок прыгает/в покое и т.д.
Еще момент - покусывая приманку, рыба может её eventually съесть полностью, нужно этот момент обработать, чтобы она съела и при этом не попалась
>Как может рыба по собственному желанию клюнуть? Он только хочет есть.
Так рыбак тоже только хочет есть, а удочка - иплементация его интерфейса Hungerable с методом findFood()
Мне не нравится этот ник.
пириводится как материнские арбузы?
итак. для начала перечислим состовными частями.
вот они:
палка,лекса,катушка,груз,круюёк,папловок.
очевидно удочку надо относледовать от палки.
так же очевидно что нужно агрегировать леску и катушку.
теперь надо разобраться с грузом крючок и поплавком.
очевидно что груз это базовый класс. от него наследуються крючок и поплавок.
так. с основной частью разобрались.
теперь рассмотрим методы которые есть у лески.
у ней нет методов.
рассмотрим методы которые есть груза:
прикрепиться к леске.
открепиться от лески.
порвать леску.
рассмотрим методы которые есть у удочки.
прикрепить леску.
открепиться лески.
порвать леску.
рассмотрим методы которые есть у катушки:
прикрепить леску.
открепиться лески.
порвать леску.
очевидно у них есть общий интерфейс. значит наследуем удочку и барабан от груза.
кстати, агрегировать барабан и леску удочке не нужно.
деагрегируем.
так. кажеться я забыл про палку.
ок. тогда надо сначала палку относледовать от груза, а потом удочку от палки... стоп.
палка это и есть удочка. значит удаляем удочку и делаем палку которая наследуеться от груза и ничего не агрегирует.
итак, теперь груз - корень иерархии наследования.
ок. тогда заканчиваем описывать удочку.
начинаем рыбачить.
итак.
для начала возмём кусочек хлеба.
хлеб надо относледовать от груза.
нет. стоп. нам не наго крепить хлеб к леске. нам надо крепить хлеб к крючку.
тогда надо относледовать хлеб от крючка.
но тогда не клюнет рыба.
что же делать?
я вспомнил у нас же есть инкапсуляция.
ок используем приватное наследование.
наследуем хлеб от крючка приватно.
oh shi~ что стало с моей буханкой хлеба, кажеться я проколол себе крючком язык.
/убежал к хирургу.