ООП *

(Update: заменил картинку на более нейтральную)

Коллега упомянул в беседе принцип "Convention over configuration", и я подумал, блин, наверно это что-то крутое, нужно изучить, почитать статьи, а то отстану от жизни.

Каково было моё удивление, что вcё обьяснение помещается в одной фразе "Используй дефолты, которые можно при желании переопределять".

И тут я подумал, что очень много понаверчено принципов, которые произносятся с умным лицом и наморщенным лбом, хотя по сути там ничего сложного нет. Многие из них можно объяснить буквально одной фразой. Ну, может, абзацем текста или практическим примером. На пальцах, короче. Вообще, очень часто бывает такое, что объясняешь кому-то за минуту то, что сам изучал довольно долго. А какие-то детали прирастают уже потом, главное получить "ключ".

В итоге я попытался сделать такую табличку. Можно сказать, своего рода русско-китайский разговорник:

Язык php часто ругают, обычно необоснованно. Особенно удивляет, что javascript ругают меньше. Зачастую это делают люди, которые писали на нем 10+ лет назад, когда язык был действительно чертовски плох, да и разработчики в те времена не задумывались над качеством кода. Посмотрите хотя бы на код wordpress, который до сих пор вызывает шок.

Ругают необоснованно, но проблемы у языка, конечно же, есть, и они серьёзные. Разуметеся, если сравнить последние релизы php7 (с нормальным ООП и строгим тайпхинтингом) и php4, то разница будет колоссальная. Однако и в последних версиях языка не всё гладко, и до java/c# пока что очень далеко. Более того, берусь утверждать, что будущее php тоже довольно сомнительно (с точки зрения типов).

Другими словами, давайте рассмотрим предметно, что хорошо и что плохо в php с точки зрения типизации.

Статья представляет собой очень краткое введение в Simula.

Simula ((SIMIUlation LAnguage) ), первый язык программирования с классами и объектами, незаслуженно почти забытый, но из которого выросло современное ООП в том виде, в котором оно присутствует в нашем коде. Это язык для имитационного моделирования реальности. Разработчики новых языков программирования «оглядывались» на Simula при добавлении механизмов объектно-ориентированного программирования в свой язык. Однако Simula упоминается настолько редко, что в русской википедии на момент публикации был только хеллоуворд, а в сети куча устаревших ссылок.



Бьерн Страуструп, говоря о причинах создания C++, сказал так: «Этот язык возник потому, что автору потребовалось написать программы моделирования, управляемые прерываниями. Язык SIMULA-67 идеально подходит для этого, если не учитывать эффективность.»

Немного о тексте ниже

Самый ленивый портфельный инвестор обычно поступает так: идет к финансовому управляющему, они вместе составляют профиль инвестора и на основании этого профиля они собирают портфель из активов, которые соответствуют тем показателям риска\доходности, которые портфельный инвестор готов принять.

Если инвестор очень долгосрочный и портфель составлен правильно, то он может покупать бумаги в любое время и по любой цене, 10-тилетний временной промежуток сгладит разницу за счет див.выплат (конечно мы должны искать ценные бумаги с постоянным денежным потоком).
Рассмотрим ситуацию, в которой вам надо найти ценные бумаги (далее я буду подразумевать конкретный тип бумаг — акции, с облигациями все понятно, там купон), которые приносит в виде дивидендов денежный поток, удовлетворяющий вашему финансовому плану. Самый простой пример — найти акцию, денежный поток которой превышает значение инфляции, т.е. 4% (по данным Росстата)

Когда я учился в университете мне довольно тяжело было понять ООП (Объектно-ориентированное программирование), сейчас я понимаю, что просто нас учили ООП на не совсем ясных и правильных аналогиях и вообще, кажется, сами преподаватели не совсем понимали, в чем же суть ООП.


Вспомните, классические аналогии ООП, вот есть класс Домашние любимцы с методами «голос» и «есть», от него мы наследуем Кошку и Собаку и все хорошо.

Но тут приходит Света и приносит аквариумных рыбок, которые не разговаривают, а потом приходит Вася, которые приносит любимый кактус, которые не только не разговаривает, но и не ест.

Мы уже запутались, но Вовочка спрашивает: «а где в этом зоопарке статические методы, интерфейсы, абстрактные классы и чем отличается объект класса от самого класса?». Объяснить, несомненно, можно, но сложно. Понять, еще сложнее.

Или другой классический пример, вот есть прямоугольник, от которого так и хочется унаследовать квадрат (ну по логике, квадрат это частный случай прямоугольника), но у прямоугольника есть длина и ширина, а у квадрата только одна сторона. Что-то тут тоже запутано.

Теперь подумаем как объяснить ООП лучше?

Дамы и господа, здравствуйте.

Мы как раз закончили перевод интересной книги Яцека Галовица о STL С++ 17, которую надеемся выпустить чем раньше, тем лучше.


Сегодня же мы хотим предложить вашему вниманию перевод статьи Джулиана Темплмана с сайта «O'Reilly» с небольшим анонсом возможностей стандартной библиотеки нового стандарта С++.

Всех — с наступающим новым годом!

Зависимости между слоями приложения | Внедрение конструктора, время жизни | Сквозные аспекты приложения, перехват, декоратор

В двух предыдущих заметках мы рассмотрели основные части веб-приложения. У нас есть объект реализующий бизнес логику – MyService. Есть IRepository, отвечающий за взаимодействие с БД. Не хватает ролевой модели и логирования.

Декоратор

Есть мнение, что в MVC веб-приложениях проверку прав удобно делать прямо в начале метода контроллера. Например:

[HttpPost]
public void DeleteProduct(int id) 
{
    if (!Thread.CurrentPrincipal.IsInRole("ProducManager")
        throw new UnauthorizedAccessException();

    this.MyService.DeleteProduct(id);
}

Листинг 1. Проверка прав в методе контроллера

Область ИТ растёт, и легко заблудиться в зоопарке подходов, фреймворков и технологий, которые громко заявляют о своей "новизне" и "эффективности". Но за обёрткой обычно скрываются старые добрые идеи, заново "изобретённые" в другом контексте. В итоге распространяется не самая простая и эффективная, а самая разрекламированная реализация. Разработчики не успевают вдумчиво произвести выбор из-за постоянного недостатка времени, а менеджеры выбирают самое распространённое, чтобы снизить риски при поиске разработчиков.

Для себя я стараюсь свести используемый в индустрии термин или технологию к простому определению или наглядному примеру. Предлагаю справочник, очень краткий, и поэтому неполный и не претендующий на точность.

Зависимости между слоями приложения | Внедрение конструктора, время жизни | Сквозные аспекты приложения, перехват, декоратор

Продолжаем борьбу за слабую связанность. В предыдущей заметке мы рассмотрели зависимости между слоями приложения, прейдем к меньшим формам.

Агрегация, внедрение конструктора

Объекты/классы системы, как и слои, взаимодействуют друг с другом. Между классами тоже есть зависимости.

Например, в листинге 1 MyService использует MyDataContext (EF) – имеет зависимость MyDataContext.

class MyService
{
    public void DoSomething()
    { 
        using(var dbCtx = new MyDataContext())
        {
            // используем dbCtx
        }
    }
}

Листинг 1. Сильная зависимость MyService от MyDataContext

Перевод статьи Mark Seemann о популярных архитектурах разработки ПО и о том, что между ними общего.

Один из моих читателей спросил меня:

Вернон, в своей книге «Implementing DDD» много говорит об архитектуре Порты и Адаптеры, как о более продвинутом уровне Слоистой Архитектуры. Хотелось бы услышать ваше мнение на этот счёт.

Если не вдаваться в детали, то в своей книге я описываю именно этот архитектурный паттерн, хотя никогда не называю его этим именем.

TL;DR Если применить принцип инверсии зависимостей к слоистой архитектуре, то в конечном счете получим Порты и Адаптеры.

Похоже, что в наши дни RESTful API существует абсолютно для всего. От платежей до бронирования столиков, от простых уведомлений до развёртывания виртуальных машин — почти всё доступно через простое HTTP-взаимодействие.

Если вы разрабатываете собственный сервис, то часто хотите обеспечить его работу одновременно на нескольких платформах. Проверенные временем принципы ООД (объектно-ориентированного дизайна) сделают ваш код более отказоустойчивым и упростят расширяемость.

В этой статье мы изучим один конкретный подход к проектированию, который называется SOLID (это акроним). Используем его на практике в написании сервиса с интеграцией Slack, а затем расширим для использования с Twilio.

Введение

В это горячее время криптовалют стоит помнить не только о высоких мгновенных спекулятивных доходах, но и о том, что ваши деньги могут работать и зарабатывать всю вашу жизнь. Являясь приверженцем фундаментального анализа при выборе объектов инвестирования я уже несколько лет предпочитаю хранить деньги в ценных бумагах. Я прошел через несколько этапов формирования инвестиционного портфеля, подходящего моей психологической устойчивости, несколько раз пересматривал состав портфеля, и постепенно пришел к тому, что имею сейчас.

Зависимости между слоями приложения | Внедрение конструктора, время жизни | Сквозные аспекты приложения, перехват, декоратор

Принципы разработки программ, названные «Внедрением зависимостей» (ВЗ) тема не новая, но от этого не менее интересная и полезная. Даже если вы не знаете, что такое «Контейнер внедрения зависимостей», возможно вы уже используете ВЗ. Работаете с Angular? — вы в теме. В любом случае, игнорировать эту концепцию и оставаться конкурентоспособным разработчиком невозможно.

Поговорим о замечательной книге Марка Симана. Данная заметка не претендует на полноту, не является кратким изложением и никак не может заменить труд Марка. Зато, надеюсь, мотивирует на прочтение 379 страниц (всего в книге 463 страницы), покажет интересные приемы из арсенала автора. И, конечно, поможет поддержать беседу с коллегами у кулера с водой.

Привет, Хабр!

У нас заканчивается уже порядком букинистическая книга "Ruby. Объектно-ориентированное проектирование" Сэнди Метц, которую мы надеемся обновить в будущем году. Тем временем мы убедились, что читателей госпожи Метц немало интересуют ее взгляды на ООП, а не только на ООП в Ruby, поэтому предлагаем перевод ее сентябрьской статьи с большим количеством картинок и немалым количеством интересных выводов на заявленную тему. Приятного чтения!

В данной статье я расскажу о собственных наработках, которые я опробовал на практике, чтобы внести больше ясности в разработку и эксплуатацию кода.

Последние пару лет я работаю в крупном проекте и наткнулся на некую закономерность, которая приводит к тотальному запутыванию кода. Код, который развивался лет двадцать командой около сотни человек трудно назвать кодом без эпитетов. Скорее это гора на десяток миллионов строк из всяких правильных и неправильных техник, умных идей, ухищрений, заплаток, копипастов на скорую руку и тд тп…


В организации, где я работаю, автоматизируют бизнес процессы, и обычно это связано с ведением базы данных. У нас принято работать по канонам, — сначала проводить бизнес анализ, составлять умное ТЗ, писать код, проводить тестирование и много всякой деятельности при дефиците времени. Первичная мотивация, вроде разумная, — “давайте будем разделять обязанности”, “давайте будем делать так, чтобы было безопасно” и тд и тп. Все эти приемы менеджмента с восторгом преподают на различных курсах, обещая много хайпа и охмурянта. Надеюсь, что читатель уже знаком с некоторыми модными словами, которые зачастую ни потрогать, ни налить нельзя. Но вопрос не об них, а о том, как программисту жить с ними.

Далее постараюсь объяснить, в чем разница между “бизнес логикой” и “строгой логикой”, на которую почему-то многие не обращают достаточного внимания. В результате оголтелого использования бизнес логики страдает просто логика, за которую боролись и математики и философы сотни лет. А когда страдает настоящая логика, то вместе с этим страдают сначала исполнители-технари, которые от безысходности могут начать лепить несуразное, чтобы лишь бы начальники отвязались. А потом бумерангом страдания возвращаются на источник “ярких супер бизнес идей”, заставляя их придумывать другие еще более “яркие супер бизнес идеи” или в конце концов надевать накладную бороду и темные очки, чтобы больше никто не узнавал на улице и не показывал пальцем.

В этой статье рассматривается проектирование типов для работы с объектами линейной алгебры: векторами, матрицами, кватернионами. Показано классическое применение механизма перегрузки стандартных операций, использование приёма «Copy On Write» и аннотаций.

(Этюд для программистов или заявка на Интернет-поиск нового типа)



Программа, делающая из мухи слона (далее программа МС), показала, что неориентированный граф существительных с заданным количеством букв хоть и содержит тысячи вершин, но при этом довольно «тощий» (т.е. имеет сравнительно не много ребер) и до полного графа ему далеко (см. Пример 1). Вслед за Чарлзом Уэзереллом (Charles Wetherell), автором широко известной книги «Этюды для программистов», выбрал жанр этюда, чтобы представить различные способы представления таких графов. (И сделать из этого выводы для автоматизации выбора представления – вплоть, может быть, до Интернет-поиска нового типа).

Start for word length 8
6016 words loaded from dictionary file: ..\Dictionary\ORF3.txt
Graph was made: edges number = 871

Пример 1. Характеристики графа существительных длиной 8 букв.

Сейчас об этом принципе слышал любой, кто занимается программированием. Чуть меньше тех, кто думает, что его знает. Гораздо меньше тех, кто действительно умеет его использовать. Я постараюсь объяснить суть, назначение и применение этого принципа как можно проще и короче.

Определение

Каждый программный объект имеет одно и только одно назначение.
Его можно исчерпывающе описать одним предложением, не используя союзы.

Пример

Lazy<T> — обертка для объекта, чье создание откладывается до первого обращения к нему.

Антипример

Синглтон — класс, не допускающий создания более одного экземпляра. В этом описании нет союзов, но оно неполное — синглтон всегда имеет основную функциональность помимо контроля единственности собственного экземпляра. Синглтон — класс, реализующий полезную функциональность и контролирующий единственность собственного экземпляра. Теперь описание исчерпывающее, но имеет союз "и" — у синглтона два разных назначения. Он не соответствует принципу единственной ответственности.

Еще антипример

Локатор сервисов — позволяет получить доступ к любому сервису приложения. Это описание без исчерпывающего списка сервисов заведомо неполное.

Назначение

Упрощение создания, анализа и модификации программных систем.

В этой статье в качестве примера у нас будет программа чуть посложнее, а именно — торговый автомат, реализация которого часто встречается в качестве тестового задания до собеседования. Будут рассмотрены взаимодействие нескольких View с одним VM и наоборот, будет показан подход «View first» и будет показан не итоговый код, с рассказом какая часть для чего нужна (ссылка для скачивания кстати Vending Machine (программный код), а будет продемонстрирован весь процесс создания и, самое главное, последовательный ход мысли.

Но перед этим я постараюсь еще раз ответить на вопрос, который обычно не задают люди, имеющие опыт отладки неструктурированных проектов, а именно: «Так зачем все-таки нужен паттерн MVVM?»

Если формально и коротко, то паттерн MVVM используется в первую очередь для разделения ответственности, для повышения читабельности, управляемости, поддерживаемости и тестируемости кода. Программный продукт состоит из модели (доменной модели и бизнес-логики) и инфраструктурного кода в соотношении, допустим, 20% на 80%. Инфраструктурный код должен быть простым, понятным, чуть ли не автоматным — как Scaffolding. А вот модель…

Здравствуйте! Есть Была у меня следующая задача: надо было спарсить кучу данных и организовать их в классы, а позже загрузить в БД. Вроде бы, ничего сложного, но в этот день я даже забыл поесть, а почему — смотрите под кат, потому что я сделяль.