Comments 21
Все же не контекст, а описание предметной области
Лично я взял за правило описывать предметную область русскими именами, если только в ТЗ нет однозначного перевода терминов как говорит бизнес на английские термины программы
В ТЗ этого нет? (а никогда нет) - значит и в коде нет!
Соответствие должно быть так чтобы в коде по Ctrl+F искать бизнес термин.
Потому что медицинский термин из 10 слов каждый будет переводить по разному и со словарем.
Весь домен у меня в русскоязычных классах и их методах
А технологическая обвязка как обычно - англоязычная
class Гражданин
{
public int Id { get; set; }
public string Имя { get; set; }
}
Не устаете переключать раскладку? Id почему не переведено?
Очевидно же: id это не бизнес термин.
Домен меньше остального кода.
Да флаг вам в руки:
"ЗаболевшиеОРВИ"
Что будете искать в коде?
ArviPatients
PatientsWithArvi
PatientsWithAcuteViralRespiratoryInfection
AcuteRespiratoryInfectionCases
ViralUpperRespiratoryInfectionPatients
RespiratoryViralInfectionPatients
PatientsWithRespiratoryVirusInfection
PeopleAffectedByArvi
ArviInfectedPatients
PatientsDiagnosedWithArvi
ArviPatientCount
PersonsSufferingFromArvi
ActiveArviCases
IndividualsWithArvi
ARVI: 'A' - acute
Но многие поставили бы О
И вариант посложнее
"Хронический рецидивирующий афтозный стоматит полости рта"
Несколько возможных вариантов перевода на английский (PascalCase):
ChronicRecurrentAphthousOralStomatitis
RecurrentChronicAphthousMouthStomatitis
ChronicRelapsingAphthousOralStomatitis
RecurringChronicAphthousMouthInflammation
ChronicRecurrentOralAphthousStomatitis
программировали на 1С? :-)
Функциональный стиль хорош для работы с данными, параллельных вычислений и минимизации побочных эффектов. - пишет автор
Может я не правильно прочитал статью (перевод) https://habr.com/ru/articles/570642/ Но помоему здесь написано про то что функциональное программирование как раз и создает эти side effects
Функциональное программирование чуть более явно разделяет чистые вычисления и побочные эффекты.
Каким образом?
Я имел в виду, что говорить "ФП создаёт сайд эффекты" - это всё равно что говорить "ПДД создаёт нарушителей скорости".
От того что у тебя в языке нет явного разделения на чистые функции и функции с сайд эффектами - это не значит, что у тебя нет сайд эффектов.
Ну вот на примере хаскеля - для побочных эффектов есть монада IO.
Если без хаскеля, то ограничениями синтаксиса. Иммутабельность по умолчанию, отсутствие какого-то глобального состояния, отсутствие объектов как в ООП, где методы имеют полный доступ ко всем полям объекта. На примере Rust - у замыканий есть типы Fn, FnMut, FnOnce, которые тоже позволяют ограничить сайд эффекты в них.
Хорошо, согласен, ФП не создает side effect. Побочный эффект присущ по сути любому языку программирования. Но разве тогда не получается что ООП как-раз шаг в сторону по борьбе с побочными эффектами?
Что вы имеете в виду под "шаг в сторону"?
Логический шаг к возможности контролировать эффекты функций при выполнении программ, на уровне языка программирования
А как ООП позволяет контролировать эффекты, если вроде бы ни в одном из изначально ООП языков такого нет? Ну по крайней мере из мейнстримных.
Максимум какой-нибудь constexpr из плюсов позволяет пометить чистые функции.
В ООП можно ограничить изменения данных до 1 файла (класса). Контролировать код на уровне объектов, за счет магических методов например
А как ты ограничишь влияние, если ты в любом месте в коде можешь, например, обратиться к файловой системе или какому-нибудь public static полю?
И что такое "магические методы"?
Ты можешь обращаться к файловой системе через объект который выражает файловую систему в коде. И опять же с помощью магических методов контролировать работу с ним. Магические методы помогают программно задать логику объекта при работе с ним в клиентском коде. Например (в зависимости от языка): создание, вызов объекта как функцию, вызов как строку, сравнение объектов и еще чуть больше разных операций
Всё ещё не понимаю магию.
И инкапсуляция никак не отменяет побочные эффекты.
Вот оберну я файловую систему в объект. Выделю интерфейс, естественно, чтобы можно было реализацию подменять и использовать все оопшные прелести.
Как я могу на уровне типов описать условно "эта функция имеет какой-то побочный эффект" или "эта функция не имеет побочных эффектов"?
Это может быть полезно, например, при кэшировании, при ленивых вычислениях, при работе в многопотоке.
А побочный эффект, в общем случае, запрещает подобное.
С помощью объектов и контроля за ними можете гарантировать что любая функция в коде не изменит данных.
Все ООПшные прелести не завязаны на интерфейсе, само наличие интерфейсов и фабрик не делает по определению архитектуру качественной. Можно написать и плохую фабрику.
Чем плох интерфейс? Если вам не надо расширять, можно и без интерфейса обойтись
Приветствую всех! Вау я даже не думал что она опубликуется это моя первая статья)
class Person { public int PersonId { get; set; }
Зато PersonId искать в тексте легче, чем кучу просто Id.
Контекст и парадигмы программирования