Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+1
// Не очень красивое решение. Но зато можно не выставлять в паблик всякие кишочки
private void SetValueToPrivateField<Type>(Type instance, string field, object value) {
if (instance != null) {
FieldInfo fieldInfo = typeof(Type).GetField(
field,
BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic
);
if (fieldInfo != null) {
fieldInfo.SetValue(instance, value);
}
}
}
Публичный сеттер нарушит инкапсуляцию, поэтому будем использовать рефлексию
"Мне нельзя ничего есть, поэтому я вставлю себе трубку прямо в живот и буду при необходимости заливать прямо туда. Но есть не буду"
Запостил: 
Caritas,
11 Марта 2015
Follow us!
Спасибо! Мой нынешний проект манагер хочет больше прайвитов - и прочих ОО фишек - и теперь я знаю как его идеи претворить в жизнь!
А в шарпе разве нету какихнить friend'ов как в крестах или package private как в жабе? Чтобы доступ к кишочкам предоставить только ограниченному кругу близких друзей.
Я пока вижу примерно два варианта:
1. Иерархиопуть. Запилить интерфейсы YA, YB, YC, ... c a*, b*, c*, ..., унаследовать от них Y и кастовать к Y*&. Но тогда придётся платить за виртуальные функции. Хотя, нет тут нужны в виртуальных функциях, я бы на месте компилятора их выпиливал.
2. Питонопуть. Сделать a*, b*, c*, ... публичными. Написать в документации, что a* могут вызывать только A, b* - только B, c* - только C. Пирфоманс!
3. Крестопитонопуть. Сделать a*, b*, c*, ... приватными. Задрузить A, B, C и написать в документации, что что a* могут вызывать только A, b* - только B, c* - только C. Наследники A, B, C соснут.
Пример:
интерфейсы же. приводить и обращаться
2 и 3 - сатанизм чистой воды
а вообще это скорее хреновая архитектура - богообъекты нинужны
+ если нужно различное поведение из схожих блоков действий - можно сделать над объеком 3 адаптера, дабы не нагружать его левыми, не нужными самому обьекту, методами
Санитары, быстрее сюда! У пациента приступ ООПянки!
Это можно разрулить через интерфейсы и перекастовочки, да. Но это, имхо, оверкилл. Через friend'ов (c++), package private (java) или internal (c#) получается проще и приятней.
Хуёвый пример, да. Тут хватит IDBQuery для клиентов и его реализации DBQuery, которую запиливает и настраивает DBConnection...
А у 1024-- как дать разным классам разные наборы функций
С интерфейсами надо выносить и дублировать сигнатуры, платить за виртуальные методы. С друзьями нельзя передать права наследникам. Без премудростей можно случайно наплодить зависимостей.
Вот было бы что-то типа
...и зажили бы.
Убить Бьярни?
И тогда ООП будет смолтолковское...
Видимо мутировали в крестоблядей (это что за покемон?..)
(Тарас, это не про тебя, просто похоже получилось...)
Я недавно видел в коридоре. Спокойные, бородатые дядьки, обсуждали, как удалить rad studio.
Ибо внутренние кишки я всегда могу запимплить, а приватные структуры и методы, нужные в нескольких модулях, тупо не выставлять наружу из динамической либы.
Ибо нехуй. У тебя ИРЛ тоже дружба по наследству передаётся?
Говно же. Надо делать как с обычными методами. К приватным друзьям добавить публичных. Запилил я интерфейс фигни, которая мне заполняет объекты смыслом, кто-то сделал несколько реализаций - и всё. Либо дружить с реализациями, либо соснуть.
Так что не вижу смысла в public friend.
Это да, душа потомков - потёмки.
Потомки друга хотят лезть в класс (по крайней мере, у меня). Скажем, если смотреть мой пример сверху, компьютер даёт абстрактной программе доступ к памяти, а какая-то конкретная программа работает и пишет.
Зачем? Их предок им предоставил недостаточный интерфейс?
А так ты связность повышаешь на пустом месте - у тебя хуй знает какое число потомков, написанных хуй знает кем, знает о кишках того класса. В итоге тот класс уже никогда не изменить.
Больно мне нужно лезть в кишки асов.
да и кто тебе мешает писать кейсы в каждом методе?
... и ввести прототипное ООП, что бы прямо в рантайме делать:
Как по мне, то лучше отдельные декларации для модулей, и там описывать что доступно снаружи.
Вот про это я и спрашивал. Спасибо.
В жабе не надо, если число используемых! реализаций не более двух.
Думаю в других компилерах с JITом хотя бы одна реализация, но инлайнится. Но способ мудацкий и оверхедный в т.ч. по писанине.
Ну и пакет можно по нескольким файлам размазывать.
Или с ActiveX какогото? Я когдато для DsoFramer обьектов что-то подобное писал