Pro насилие
Приснилось, будто попал в параллельный мир, встрял в войну между какими-то существами. Кажется, они назывались аякаси. Женился на аякаси, которая возглавляла одну из фракций. Кажется, фракцию воздуха. И мало того, она забеременела! При том, срок беременности у них всего несколько дней. Такая вот физиология.
Мы договорились с какими-то «хранителями моста»… Долго препирались, но уломали. Попали уже в наш мир, и вот картина маслом: я знакомлю Л. со второй женой, которая уже с пузиком и в субботу родит. И лицо у Л. было такое, что сразу стало ясно, вторую жену она примет, но лично я, немного позже, за «неразборчивость в связях с общественностью», познаю много всякого… разного.
Там была ещё целая пачка приключений. Например, я, с моей беременной аякаси, искали какой-то могущественный клан (и это в нашем-то мире!), который похищает людей и проводит между ними гладиаторские бои. Навёл на них призрак одного такого гладиатора, которого встретили в кафе. Оказалось, я стал видеть духов усопших.
В общем, хоть беги и пиши книги. Но нужно писать код. Я ж программист. Мне ж работать надо, а не сны пересказывать.
Считается, что работу мы себе выбираем сами. Но так ли это?
Так! Хотя здесь и имеет место скрытое насилие.
Вот смотри: выбрать работу ты можешь.
Но не всякую. Например, гендир Газпрома может быть только один. Однако, сама по себе концепция свободы выбора и не подразумевает такого финта. Выбор, это когда ты выбираешь. Выбираешь из того, что доступно для выбора. Т.е. выбирая между чёрным и белым ты не можешь выбрать зелёное. Даже если тебе оно очень надо.
С работой та же петрушка. Ты можешь выбрать любую, но лишь из доступных для выбора. Вроде-бы даже можешь выбрать «ничего». Т.е. — не работать вовсе.
Но нет. Просто у тебя появится новый выбор: либо участь бомжа, либо преступника, либо умереть с голоду, либо все три сразу. Я конечно утрирую, но зато так нагляднее. Т.е. тебя подталкивают выбрать именно работу. Не важно какую, но работу. А иначе…
И нет, предпринимательство — это тоже работа. И тоже «на дядю». Точнее, на неких дядь, которых ты может быть даже не знаешь. Просто без посредника, в виде работодателя.
Насилие ли это? Формально нет, но по факту — да. Впрочем, вокруг нас много разного насилия, от мягкого и стыливозавуалированного, до жестокого и прямого как стилет, что вонзился в печень в тёмной зассаной подворотне.
Школа = Насилие. Ребёнок не выбирает ходить туда или нет. За него решают родители. И школа это благо. Так говорят.
Законы = Насилие. Их пишут другие, а тебя ставят перед фактом. И они благо тоже, иначе придут хаос и смерть.
Налоги = Насилие. Делай что хочешь (в рамках закона), работай кем хочешь, имей мнение какое хочешь, но налоги плати. Просто «потому-что».
Поэтому, надо сделать над собой насилие усилие и поработать. Тем более, что задача интересная. Она бросает мне вызов, а значит у неё нет шансов.
Что такое концепция SOLID в программировании? Формально это свод из пяти правил, продиктованных здравым смыслом. На самом деле — это тоже насииииилие))
Solid — переводится как камень. Но по факту это что-то типа аббревиатуры или акронима. Каждая буква в слове, это первая буква правила.
Single responsibility — принцип единственной ответственности.
Open-closed — принцип открытости/закрытости.
Liskov substitution — принцип подстановки Барбары Лисков.
Interface segregation — принцип разделения интерфейса.
Dependency inversion — принцип инверсии зависимостей.
Single responsibility
Один класс — одно дело. Т.е. не стоит делать класс, который одновременно отвечает за подсчёт стоимости заказа и за способ отправки письма заказчику.
Почему? А вдруг завтра понадобится отправить эти данные не на e-mail, а в телеграм-канал? Или и туда и туда? Или ещё и в CRM, чтобы менеджер связался с заказчиком? Да мало-ли вариантов?
Вам не придётся менять класс обработки заказа. Вы лишь дополните класс, отвечающий за способ отправки.
Кстати, формирование текста сообщения тоже стоит вынести отдельно. Ведь шаблон сообщения может меняться, например, в зависимости от способа отправки.
Такой подход ускоряет правки, делает код понятнее, позволяет избегать ошибок, делает более удобным покрытие классов тестами.
Open-closed
Классы должны быть открыты для расширения, но закрыты для модификации.
Не буду описывать подробно и с примерами. Скажу только, что это «камушек в огород» тех разрабов, кто использует private методы там, где стоило-бы использовать protected.
Это не значит, что одно нужно тупо заменить на другое. Здесь требуется подойти с умом.
Liskov substitution
Ох уж эти фамилии. Абсолютно «неговорящее» название. Вот лично я с Барбарой Лисков не знаком.
Я понимаю этот принцип так: Всё что обращалось к родительскому классу, должно без проблем обращаться и к дочернему.
Т.е. наследник должен в полном объёме поддерживать «дело» своего предка.
Грубо говоря, если повар-отец на запрос клиента «а подайте-ка мне супа» готовил суп Харчо, то сын тоже должен уметь готовить какой-нибудь суп в ответ на такой запрос. Пусть хоть вермишелевый, но чтоб суп! Постоянный клиент не должен страдать.
Interface segregation
Ну тут всё просто. Класс может имплементировать в себя несколько интерфейсов.
Поэтому, лучше несколько маленьких, но специализированных интерфейсов, чем один универсальный, но большой.
Dependency inversion
Самый непонятный из принципов. На словах вроде всё просто: Модули (классы) верхних уровней не должны зависеть от модулей нижних уровней. И те и другие должны зависеть от абстракций.
Вам понятно? Мне — нет. Ху из модули верхнего уровня? Ху из модули нижнего уровня?
Придётся разбираться.
Предположим, у нас имеется некий класс, который работает с базой данных персонажей. Ну там выводит список гильдий, список персонажей, а так-же прочую информацию о них. Он и будет нашим классом верхнего уровня.
При создании объекта мы хотим сразу создать соединение с источником данных. В нашем случае, источник — база данных MySQL.
Поэтому, в метод __construct (в параметры) мы пихнём объект класса, MySQLConnect $dmObject. Это класс нижнего уровня (работающий с базой данных).
Но вот в чём сложность. Если мы так сделаем, то в будущем, при изменении источника данных (допустим я захочу использовать SQLite вместо MySQL), мне придётся вносить правки в класс верхнего уровня.
Поэтому, лучше создать интерфейс DBConnectInterface и имплементировать его к классу MySQLConnect. А в __construct подать объект не как MySQLConnect $dmObject, а как DBConnectInterface $dmObject.
Таким образом, при изменении источника данных, мы создадим для него класс, а к классу имплементируем всё тот же интерфейс DBConnectInterface, и для класса верхнего уровня ничего не изменится. Он как получал объект типа DBConnectInterface, так и будет получать его дальше.
Вот такой вот «камушек», об который можно споткнуться при работе, если не знать.
Почему я прервал серию постов «Побег из зада»? Да просто подъехали дела, которые нужно сделать, и я погрузился.
И вот, копая информацию в сети, вдруг узнал, что мои знания по Битриксу устарели. При том, устарели безнадёжно. Т.е. для текущих задач имеющихся скилов более чем достаточно. Но продвинутых конторах с Битриксом работают по другому.
Первая реакция — депрессия. Это когда начинает казаться что всё. Что единственное доступное решение, просто уйти в закат. В такие минуты очень помогает ролик Dance Monkey.
Смотрю и где-то в груди что-то закипает, прорываясь наружу решением типа: А вот хрена вам полную ложку! Да я делал вещи, от которых у одних обывателей в штанах резко добавится калу в первые же секунды, а у других напрочь зависнет головной мозг, и при том, возможно, навсегда.
Так неужели не справлюсь с какой-то фигнёй для тупых??! Да ещё и в депрессию впадать??!!! Идите лесом!!!
И с этим настроем, вгрызаюсь в задачу снова и снова.
Потому, что!
