Вам не кажется, что задача немного надуманная: реализовывать доступ к приватному полю класса, если есть возможность модифицировать этот самый класс? В этом случае, всё решается public свойством/методом. В случае, когда такого доступа нет и поле действительно private, то единственный способ — это рефлексия в той или иной вариации (примеры 2 и 3 в вашей статье).
Принуждение говорить куда пошел — это определённая степень доверия. Цеплять ребёнку трекер — совершенно иное. Причём не столько из-за недоверия, сколько из-за «безбашенности» чада, и его возможности «заиграться».
Я вот пока писал это, в принципе, сам и сформулировал мотивацию.
Я больше рассуждаю про категорию 6-10.
Если есть необходимость, родители могут слушать, что происходит вокруг ребенка.
Есть предположение, что после определённого возраста данная возможность может вызвать конфликт с ребёнком.
Может немного не в тему, но у самого маленький ребёнок, и было бы интересно услышать опыт родителей о том, как договариваться с ребёнком на ношение подобного вида гаджетов с трекингом (или трекинг через мобилку). Как мотивировать?
DataTable, при всей своей избыточности в задачах с readonly-данными, довольно эффективно хранит данные поколоночно (особенно если много value-типов). И если выкинуть с него всю мишуру (о чём я напишу в следующей статье), то получится довольно эффективная структура. Т.е. фактически переписать с нуля, взяв за основу поколоночное хранение. Будет ничем не хуже DTO. По удобству использования, если нужен только произвольный доступ по индексам и именам колонок — самое оно, при минимуме накладных расходов.
То, про что пишете вы, несомненно хорошо, но для другого типа задач, когда DTO переходит в доменные объекты. У нас же была несколько иная задача — к таблице применяются различные формулы и скриптованые действия, которые пока не удалось полностью перенести в БД.
Возвращаясь к статье, подобный подход может помочь не только для DataTable, но и в других задачах — например, XML.
Используя хэшсет, вы не сможете получить по дубликату ссылку на тот элемент, который уже лежит в хэшсете. Есть Contains, который может просто проверить есть ли уже такой элемент в контейнере. Т.е. в случае дубликата, он вам просто скажет, что есть и всё. Что в принципе логично, потмоу что HashSet — это множество, а не хэш-таблица в чистом виде.
Никто не говорит, что именно так в БД данные и лежат. Как правило, много дубликатов приходит в результате выполнения вьюх (которые джойнят несколько таблиц). Да и заниматься блужданием по FK на стороне клиента — то ещё развлечение.
Согласен, по возможности, всё нужно выносить в БД. Но в моём случае к таблице применяются различные формулы и скриптованые действия, что пока не удалось полностью перенести в БД. Естественно мы стараемся по минимуму выкачивать данных на клиент, но бывают прецеденты…
В словарь кладётся один и тот же объект в качестве ключа и в качестве значения. По ключу словарь считает хэш и хранит дальше его. В Value оседает ссылка на экземпляр из кучи. Когда данная строка встречается нам вновь, то словарь найдёт её и вернёт ссылку на уже существующий в куче объект. Эту ссылку мы и присвоем вместо дубликата. Dictionary тут исключительно для линейной скорости поиска.
exclusiveStrings будет уничтожен — вы правы, но экземляру строк будут жить в памяти, т.к. таблица будет держать на них ссылки.
Кот Шрёдингера, всё же, немного про другое
Я вот пока писал это, в принципе, сам и сформулировал мотивацию.
Я больше рассуждаю про категорию 6-10.
Может немного не в тему, но у самого маленький ребёнок, и было бы интересно услышать опыт родителей о том, как договариваться с ребёнком на ношение подобного вида гаджетов с трекингом (или трекинг через мобилку). Как мотивировать?
То, про что пишете вы, несомненно хорошо, но для другого типа задач, когда DTO переходит в доменные объекты. У нас же была несколько иная задача — к таблице применяются различные формулы и скриптованые действия, которые пока не удалось полностью перенести в БД.
Возвращаясь к статье, подобный подход может помочь не только для DataTable, но и в других задачах — например, XML.
exclusiveStrings будет уничтожен — вы правы, но экземляру строк будут жить в памяти, т.к. таблица будет держать на них ссылки.