Довольно часто у студентов, изучающих C++ в определённых учебных кругах, складывается мировоззрение о том, что всё должно быть объектами. Попросите их написать программу, которая считает некоторое значение - и они начнут с создания объекта ValueComputer и метода vc.computeResult().
Например: дана задача с помощью динамического программирования посчитать количество способов замостить костяшками домино прямоугольник 
. Студент пишет:
LSP (протокол языкового сервера) сегодня весьма популярен. Есть стандартное объяснение этого феномена. Возможно, ранее вам уже попадалась эта картинка, у нас также являющаяся заглавной.
Считаю, что такое стандартное объяснение популярности LSP – неверное. Ниже предложу вам альтернативную трактовку.
Объектно-ориентированное программирование (ООП) трудно реализовать на динамическом прототипном языке, таком как JavaScript. Вы должны вручную придерживаться принципов ООП из-за языковых особенностей, таких как утиная типизация. Это требует дисциплины, поскольку ничто в языке не навязывает принципы. Если задействована разнородная команда разработчиков с разным опытом работы, кодовая база, наполненная благими намерениями, может быстро превратиться в один хаотичный беспорядок.
В этом отрывке мы углубимся в правильные методы ООП в TypeScript, показав, как язык автоматизирует кучу ручного труда и поощряет лучшие практики. Мы начнем с того, что немного поговорим об утиной типизации, а затем перейдем к трем основным элементам: инкапсуляции, наследованию и полиморфизму.
Готовы? Поехали!
От автора перевода: Написанный далее текст может не совпадать с мнением автора перевода. Все высказывания идут от лица оригинального автора, просьба воздержаться от неоправданных минусов. Оригинальная статья выпущена в 2014 году, поэтому некоторые фрагменты кода могут быть устаревшими или "нежелаемыми".
Содержание статьи:
В статье приведены доводы, которые ставят под вопрос правильность присутствия ORM в рамках ООП.
В этой статье автор высказывает личное мнение, сформулированное на основе его собственного опыта и вкуса. Поэтому просьба не обижаться, если вы с ним не согласны. Конечно, оно может быть ошибочным – но это и стоит обсудить.
(на картинке изображён С++ среди других функциональных языков)
Классы - это скорее всего первое, что добавил Страуструп в далёких 1980х, ознаменовав рождение С++. Если представить, что мы археологи древних плюсов, то косвенным подтверждением этого факта для нас будет this, который по прежнему в С++ является указателем, а значит, скорее всего, он был добавлен до "изобретения" ссылок!
Но речь не про это, пора окинуть взглядом пройденный с тех пор путь, изменение и языка и парадигм, естественный отбор лучших практик, внезапные "великие открытия" и понять к чему это всё привело язык, который когда то вполне официально назывался С с классами (ныне мем).
В конце(СПОЙЛЕР) мы попытаемся превратить С++ в функциональный язык за несколько простых действий.
Для начала рассмотрим базовое применение классов:
Существует множество мнений о возможности применения ООП подходов и паттернов в Rust. Кто-то считает, что полноценного ООП в Rust нет и быть не может. Другие разработчики, наоборот, высказывают мнение, что элементы языка позволяют использовать приёмы из ООП именно так, как их видели создатели этой парадигмы.
В данной статье я постараюсь продемонстрировать, какие идеи и принципы из ООП позволяет реализовать Rust, и как это работает на простых примерах.
Я считаю, что именно агрегаты из Domain-Driven Design лежат в основе поддерживаемых информационных систем. Однако эта концепция малоизвестна за пределами DDD-сообщества и довольно сложна для понимания, поэтому я решил написать очередной пост посвящённый агрегатам. В основном для чтобы структурировать собственное понимание агрегатов и создать "методичку" для своих команд, но и широкой общественности, я надеюсь, этот пост тоже может быть полезен.
Перевод с английского с адаптацией
Ссылки на оригинал:
https://www.geeksforgeeks.org/design-a-chess-game/
https://massivetechinterview.blogspot.com/2015/07/design-chess-game-using-oo-principles.html
Уровень сложности: Сложный
Последнее обновление: 30 Сент., 2020
Постановка задачи:
Проблема состоит в том, чтобы разработать шахматную игру с использованием объектно-ориентированных принципов.
На вопрос: Adobe, Amazon, Microsoft и т. д.
Решение:
Эти виды вопросов задаются на интервью, чтобы судить о навыке объектно ориентированного дизайна кандидата. Итак, прежде всего, мы должны подумать о классах.
Примечание автора перевода:
Хорошо было бы определиться со структурой кода и построить UML диаграмму.
Затем сформировав связи и отношения, строить классы. Такой подход к проектированию был бы более наглядным и написание кода отнимало бы меньше времени.
Далее в тексте: Прим. - примечание автора перевода.
*«Читать далее»
Основными классами будут:
В Java можно объявлять переменные в классе, методе, блоке или конструкторе. В зависимости от варианта объявления, у переменной могут быть разные области видимости в программе, а сама переменная может относиться к статическому или нестатическому типу в зависимости от того, где она объявлена.
Основываясь на этих критериях, можно разделить все переменные в Java на следующие типы: локальные переменные, переменные экземпляра и переменные класса. Затемнение и сокрытие переменных происходит, когда оказываются одноименными две переменные в разных областях видимости (в локальной и глобальной области видимости, в родительских и дочерних классах). При таком сценарии используется значение той переменной, которая находится во внутренней области видимости, так как она затемняет/скрывает значение той переменной, что находится во внешней области видимости.
Map - это интерфейс, а HashMap - одна из его реализаций. Тем не менее, в этой статье мы постараемся разобраться, чем полезны интерфейсы, узнаем как сделать код гибче с помощью интерфейсов и почему существуют разные реализации одного и того же интерфейса.
Давайте я сразу зайду с козырей. Сколько ошибок в коде этой функции вы можете найти за 60 секунд?
func NewConnectionString(host, path, database, user, password string, debug bool) string {
return fmt.Sprintf(
"proto://%s/%s?userName=%s&password=%s&database=%s&debug=%t",
host, path, database, user, password, debug,
)
}
Все ошибки в этом довольно небольшом коде найти и обезвредить довольно сложно. Я попробую их сейчас сформулировать и скомпоновать в две основные:
Ладно, признавайтесь — наверняка каждый за 60 секунд смог заметить первую ошибку, но не все из вас смогут заметить вторую. Если ваш список ошибок оказался короче, чем мой — тогда прошу под кат.
Многие из вас, вероятно, слышали об упоминаний контрактов во время обсуждения кода. Фразы наподобие "Код должен соблюдать контракт интерфейса", "Юнит-тестами тестируется не код, а контракт класса", "Тестируйте не код, а контракты" и т.п. Сегодня постараемся понять, что такое контракты и что они дают.
Преимущества данного метода:
Независимость: возможность не зацикливаться на бизнес логике.
Можно задекларировать, описать схему работы нашего приложения до создания внешних сервисов, использовать замоканные данные в реализации адаптеров.
Гибкость: использование любых фреймворков, перенос доменов адаптеров в другие проекты, добавление новых адаптеров без изменения исходного кода.
Легкая изменчивость: изменения в одной области нашего приложения не влияют на другие области.
С появлением подсказок типов (type hints) в Python 3.5+ добавилась опциональная статическая типизация – поэтому эти подсказки так мне нравятся. Теперь я аннотирую ими все мои проекты.
class Checkbox extends React.Component {
constructor(props) {
super(props);
this.state = { isOn: true };
}
// ...
}class Checkbox extends React.Component {
state = { isOn: true };
// ...
}class Checkbox extends React.Component {
constructor(props) {
super(props);
this.state = { isOn: true };
}
// ...
}
О чем эта статья
Это продолжение моих похождений по ФААНГ. Предыдущая статья была о моем опыте собеседования в Амазоне.
Здесь я тоже поделюсь всем процессом: как я попал на собеседование, все этапы, вопросы на интервью, как я готовился, некоторые детали офера, и общее впечатление от интервью. Так же будут всякие сравнения опыта собеседования в Майкрософте и в Амазоне.
К слову, все собеседования тоже сейчас проходят онлайн, и никаких онсайт интервью нет.
Многие разработчики считают принципы программирования обязательными и используют их по дефолту во всех проектах. На самом деле большинство из них нереализуемы на практике — докажем это на нескольких примерах.
В качестве иллюстрации для этой статьи рассмотрим проект-пример. Предположим, вы пишете код приложения-чатбота. Вы хотите, чтобы некоторые классы можно было переиспользовать от бота к боту, чтобы не переделывать всякий раз всю работу заново.