Pull to refresh
  • by relevance
  • by date
  • by rating

How Non-Member Functions Improve Encapsulation (C++)

C++
Листал старые журналы и наткнулся на широко известную в узких кругах статью Scott Meyers: How non-member functions improve encapsulation. Если кто-то ее еще не читал — прочитайте обязательно.
Мысль там излагается понятная и верная, но все же по-моему в статье есть большая недосказанность.
Говоря кратко, в этой статье Мейерс утверждает, что вынесение функций из класса всегда делает код более инкапсулированным.
Читать дальше →
Total votes 23: ↑15 and ↓8 +7
Views1.2K
Comments 16

Как я заново открыл для себя инкапсуляцию в java.

Java
Я всегда считал, что Java — лаконичный и красивый (в плане концепции) язык с четкой структурой, позволяющей расширять эту структуру и на всевозможные фреймворки, там самым помогающая привнести порядок и в код конечного программиста. И, прежде всего, я считал, что java — это 100% ОО язык! Но недавно мне попался код, после которого я вечер ходил возмущался. Код совершенно несложный для понимания даже людей несведующий в java.
Читать дальше →
Total votes 87: ↑50 and ↓37 +13
Views17.5K
Comments 68

10 лет практики. Часть 1: построение программы

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

Материал разбит на части, от самых общих практических правил, интересных начинающим, до конкретных вопросов, актуальных опытным программистам.
В первой части я на практике дам свой ответ на самые базовые вопросы. Как вообще писать программу, в особенности — сложную программу? Что следует сделать в самом начале, чтобы потом не переделывать с нуля? Как создать оптимальную структуру программы?
Читать дальше →
Total votes 152: ↑125 and ↓27 +98
Views17.9K
Comments 195

Слой магии

Programming
Translation
Любая достаточно сложная технология неотличима от магии
Артур Кларк


Как программист и просто человек, увлекающийся компьютерами, я знаю о том, как они работают, больше, чем первый встречный. Мне всегда интересно наблюдать за тем, как пользуются компьютерами люди, которые знают о них меньше меня. Для многих из них процесс выглядит следующим образом: они нажимают на что-то, компьютер делает нечто загадочно-магическое, и результаты появляются на экране.

Впрочем, даже знакомые с технологией в целом люди на каком-то этапе могут обнаружить, что происходящее с равным успехом могло бы быть магией — очень немногие понимают все протекающие процессы целиком.
Читать дальше →
Total votes 56: ↑36 and ↓20 +16
Views3.2K
Comments 32

Где спряталась логика?

Programming

Вопрос


Очень часто при обсуждении программ употребляется термин «логика» или «бизнес-логика».
Например:
  • (о юнит-тестах) не обязательно добиваться стопроцентного покрытия кода тестами, достаточно тестировать лишь логику.
  • (о веб-приложениях) контроллер не должен содержать никакой бизнес-логики, а должен только вызывать методы других классов
  • В слое VIEW (то есть в JSP-файлах) не должно быть бизнес-логики


Так вот, кто скажет мне, что такое «логика»? Надо ли понимать под этим любой IF в коде? Но разве бывает код без IF'ов? Или (бизнес-)«логика» означает любую информацию, которая исходит от клиента? Но разве можем мы на деньги клиента делать что-то, чего он не заказывал? Не можем. Стало быть, весь наш код — это целиком «бизнес-логика» от клиента. Вот поэтому я никогда не мог понять, что же такое эта чёртова логика.

Ответ:
Total votes 72: ↑55 and ↓17 +38
Views3.6K
Comments 75

Проблемы инкапсуляции

Programming
Недавно мне попалась на глаза интересная статья о проблемах в концепции инкапсуляции — почитайте, если есть время.
Для тех, у кого времени нет, я быстренько перескажу суть: инкапсуляция не выполняет одной из своих основных задач (дать «черный ящик» с описанными входами и выходами) по целому ряду причин:
  1. Программисты не доверяют чужим «черным ящикам».
  2. В чужих «чёрных ящиках» случаются ошибки, которые приходится фиксить, влезая в их внутренности (и ломая этим всю затею).
  3. Входы и выходы не всегда описаны понятно. Иногда бывает проще создать свой велосипед, чем разбираться в том, как поехать на чужом.

Всё это презренная реальность, которую теоретики программирования игнорируют. И как же с этим жить?
Читать дальше →
Total votes 55: ↑36 and ↓19 +17
Views2.1K
Comments 36

GC в C++: преодоление соблазна

C++ООP
Недавно появилась заметка о простой и эффективной «ручной» сборке мусора в С++. Вполне допускаю, что локальная сборка мусора внутри какого-то сложного класса (где идёт активная низкоуровневая работа с указателями) может быть оправдана. Но в масштабах большой программы, существует более надёжный и простой метод избавления от утечек памяти. Не претендуя на «метод на все случаи жизни», очень надеюсь, что он сделает проще жизнь хотя бы некоторым из читателей.

Суть метода предельно проста: если каждый объект является переменной какой-либо области видимости или простым («стековым») членом другого объекта, то даже при аварийном закрытии программы от необработанного исключения, всегда будет происходить корректная очистка. Задача заключается в том, чтобы свести всё многообразие динамических сценариев к этой схеме.
Вот отсюда поподробнее...
Total votes 33: ↑28 and ↓5 +23
Views8.2K
Comments 39

Я, наверное, знаю ООП. Опыт объектно-ориентированного программирования и дизайна. Ответ «не знающим ООП.»

ProgrammingJavaООP
Sandbox
После появления статей типа "Я не знаю ООП" — возникает желание внести ясность, «сорвать покровы» и «докопаться до истины».

Принципы объектно-ориентированности


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

На мой взгляд (не говоря о том, что абстракция и полиморфизм могут быть запросто отнесены к подразделам наследования), принцип тут один, в общем, тот же самый, что при проектировании баз данных: представление всего в виде объекта — некоторой штуковины со свойствами. Набор обычно бывает фиксированным, и тогда говорят о классе объектов, а даже если понятия класса и нет, то наличие свойств с определёнными названиями подразумевается логикой программы, т.е. нечто типа класса в виде некоего минимального набора свойств всё равно присутствует. В общем, воззрения восходят к давнему С-шному/паскалевскому типу данных struct/record. Потом к этому добавили немного «функциональности» (в смысле функционального программирования): значением свойства может быть функция, причём такая, которая имеет доступ к самой структуре/записи, значением одного из свойств которой она является. Сей феномен, в лучших традициях немецкого латиноязычного нейминга (когда опция называется «вариантом», а степень числа — «потенцией»), назвали «методом». Желание повторно использовать код, в сочетании с представлением каждого предмета как некоего подобия паскалевской «записи», привело к появлению концепции «наследования».
Читать дальше →
Total votes 59: ↑35 and ↓24 +11
Views32.5K
Comments 144

В C++ единицей инкапсуляции является класс

C++
Заголовок статьи на самом деле представляет собой не одно утверждение, а два, хотя оба они известны:
  1. В C++ единицей инкапсуляции является класс – а не отдельный объект ([Stroustrup3e], 24.3.7.4).
  2. В C++ единицей инкапсуляции является класс – а не класс вместе с его ниже стоящей иерархией.
Читать дальше →
Total votes 41: ↑23 and ↓18 +5
Views17.8K
Comments 29

Смена парадигмы программирования на C#, переход на сигналы и очереди (слоты)

Programming.NET
В этом посте я рассматриваю концепцию и ее реализацию (пока в начальной, но рабочей стадии), которая с недавних пор стала меня сильно привлекать. Опыта в программировании на сигналах у меня ранее не было, поэтому что-то мог упустить или неоптимально продумать, потому и пишу сюда. Надеюсь на квалифицированные отзывы и советы. Несмотря на то что библиотека только начала развиваться, я уже начал ее использование в реальных проектах, на реальной нагрузке, это помогает быстро понять что действительно нужно и куда двигаться дальше. Так что весь приведенный код находится в рабочем состоянии, компилируется и готов к использованию. Единственное все делается на Framework 4.5, но не думаю что это будет для кого-то препятствием, если же идея окажется стоящей, пересобрать под 3.5 проблем не будет.

Что же не так с текущей парадигмой


Устройство обычного приложения на .NET подразумевает что у нас есть набор классов, в классах есть данные, и методы которые эти данные обрабатывают. Также нашим классам надо знать друг о друге, о public методах, свойствах и событиях. То есть у нас сильносвязная архитектура. Конечно мы можем уменьшить связность, построить взаимодействие исключительно через интерфейсы и фабрики (что увеличит размер кода раза в два, и существенно усложнит читабельность), можем убрать открытые методы и стоить все на событиях, придумать можно много чего, но перейти к слабосвязанной архитектуре все равно не выйдет, получим в лучшем случае «среднюю» связанность.

Да, и еще есть такая вещь, которая с развитием процессоров становится все более актуальной, это асинхронность, microsoft делает много хорошего в этом направлении, тот же PLINQ, всякий сахар вроде await, но все это делается все равно в привычных рамках ООП, и нам все еще приходится самим создавать потоки, пускай и в виде тасков, но самим. Нужно отслеживать окончание исполнения задач, чтобы определить когда рессурсы станут ненужными.

В общем все это постепенно надоедает, становится лень писать одни и те же вещи в каждом новом проекте, когда правильнее было бы сосредоточиться на логике задачи.
Читать дальше →
Total votes 29: ↑15 and ↓14 +1
Views15.9K
Comments 64

POKA-YOKE проектирование: от «запаха» к благоуханию

ProgrammingPerfect code.NET
Translation
От переводчика. Это перевод серии постов из блога Марка Симана. Я не хочу объединять некоторые из постов, несмотря на то, что они небольшие по размеру, а просто постараюсь соблюсти структуру, предложенную Марком.

Ещё немного от переводчика. POKA-YOKE можно перевести как «дуракоустойчивый» или отказоустойчивый.

Инкапсуляция является одной из самых недопонимаемых концепций в объектно-ориентированном программировании (ООП). Похоже на то, что большая часть людей думает, что, имеющая отношение к инкапсуляции, концепция «сокрытия информации», просто означает, что закрытые поля должны быть раскрыты через публичные свойства (или getter\setter-методы в языках, которые не обладают поддержкой свойств).
Читать дальше →
Total votes 36: ↑27 and ↓9 +18
Views16.2K
Comments 16

«Запах» проектирования: одержимость примитивами

ProgrammingPerfect code.NET
Translation
Это второй пост из серии о Poka-yoke проектировании – также известном, как инкапсуляция.

Множество классов имеют тенденцию к потреблению или раскрытию примитивных значений, таких как int, или string. В то время как такие примитивы существуют на любой платформе, их использование может приводить к процедурному коду. Более того, они обычно нарушают инкапсуляцию, допуская присвоение некорректных значений.
Читать дальше →
Total votes 23: ↑16 and ↓7 +9
Views9.1K
Comments 24

«Запах» кода: автоматические свойства

ProgrammingPerfect code.NET
Translation
Это третий пост из серии о Poka-yoke проектировании – также известном, как инкапсуляция.

Автоматические свойства – одна из наиболее излишних возможностей в C#. Я знаю, что многие люди очень их любят, но они решают проблему, с которой вы и сталкиваться не должны.
Читать дальше →
Total votes 19: ↑11 and ↓8 +3
Views15.8K
Comments 2

«Запах» проектирования: излишний атрибут Required

ProgrammingPerfect code.NET
Это четвёртый пост из серии о Poka-yoke проектировании – также известном, как инкапсуляция.

Недавно, я прочитал из какого-то технологического события Microsoft пост, написанный с энтузиазмом:
Атрибут [Required] в коде автоматически создаёт запись в БД, которая не может принимать null, а также создаёт валидацию на веб-странице – симпотично […]

Читать дальше →
Total votes 26: ↑17 and ↓9 +8
Views8.1K
Comments 23

«Запах» проектирования: конструктор по умолчанию

ProgrammingPerfect code.NET
Translation
Это пятый пост из серии о Poka-yoke проектировании – также известном, как инкапсуляция.

Конструкторы по умолчанию являются «запахом» в коде. Именно так. Это может звучать возмутительно
Читать дальше →
Total votes 26: ↑17 and ↓9 +8
Views9.9K
Comments 19

На границах, приложения не являются объектно-ориентированными

ProgrammingPerfect code.NET
Translation
Я получил множество отзывов на мою недавнюю серию постов по Poka-yoke проектированию (я был бы расстроены, если было бы иначе). Множество из этих отзывов касаются различных технологий сериализации или трансляции, используемых обычно на границах приложения: сериализация, XML (де)гидратация (прим. переводчика: тоже самое, что и сериализация), UI-валидация и т.д. Заметьте, что такая трансляция происходит не только по периметру приложения, но также и на уровне сохраняемости (persistence). ORM-ы также являются трасляционными механизмами.
Общим для многих комментариев является утверждение о том, что большая часть технологий сериализации требует наличия конструктора по умолчанию. Например, класс XmlSerializer требует наличия конструктора по умолчанию и публичных, доступных для записи свойств. Большая часть объектно-реляционных преобразователей, которые я изучал, похоже, имеют те же требования. Контролы Windows Forms и WPF (UI – также граница приложения) почти обязаны иметь конструктор по умолчанию. Не нарушает ли это инкапсуляцию? И да и нет.
Читать дальше →
Total votes 24: ↑15 and ↓9 +6
Views10.2K
Comments 5

«Запах» проектирования: временная связность

ProgrammingPerfect code.NET
Translation
Это первый пост из серии о Poka-yoke проектировании – также известном, как инкапсуляция.

Известной проблемой в проектировании API является временная связность, которая получается в том случае, если в классе присутствуют скрытые отношения между двумя или более членами, требующие от клиента правильной последовательности вызовов. Это жёстко связывает члены класса во временном разрезе.
Читать дальше →
Total votes 21: ↑14 and ↓7 +7
Views8.8K
Comments 5

Инкапсуляция CSS-стилей — Часть 1. Проблема

CSSHTML
Главным драйвером роста веба на рубеже тысячелетий было потребление контента. Сайты создавались для предоставления своим посетителям какой-либо полезной информации или развлекательного содержимого. Но в последние годы резко выросло значение веб-ресурсов, предоставляющих пользователям сервисы генерации контента (текстовые и графические редакторы, электронные таблицы, мессенджеры и т.п.). Это вызвало трансформацию сайтов в одностраничные приложения и миграцию в веб сложных интерфейсов, которые ранее были прерогативой прикладных программ.
Читать дальше →
Total votes 40: ↑33 and ↓7 +26
Views41.1K
Comments 14

Выразительный JavaScript: Тайная жизнь объектов

JavaScriptProgramming
Translation

Содержание




Проблема объектно-ориентированных языков в том, что они тащат с собой всё своё неявное окружение. Вам нужен был банан – а вы получаете гориллу с бананом, и целые джунгли впридачу.

Джо Армстронг, в интервью Coders at Work


Термин «объект» в программировании сильно перегружен значениями. В моей профессии объекты – стиль жизни, тема священных войн и любимое заклинание, не теряющий своей магической силы.

Стороннему человеку всё это непонятно. Начнём же с краткой истории объектов как концепции в программировании.
Читать дальше →
Total votes 25: ↑25 and ↓0 +25
Views77.9K
Comments 4

Интернет в РФ будет несовместим с мировыми стандартами

Legislation in IT
Управление «К» предложило госдуме новый законопроект.

Согласно последним исследованиям, за последние 4 года каждое киберпреступление было совершено с использованием инкапсуляции. По результатам трудных дебатов Алексей Мошков принял решение, что на территории РФ необходимо законодательно запретить инкапсуляцию.
Читать дальше →
Total votes 68: ↑21 and ↓47 -26
Views727
Comments 8
1