| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > .NET для новичков > По умолчанию структуры вместо классов? |
| Автор: slavaentp 28.1.2009, 17:09 |
| Я в одной книге как-то прочитал "правило Буравчика" про уровень доступа - "Лучше всего члены класса делать как private, и только если этот уровень доступа не устраивает - постепенно его повышать. Я сейчас читаю про структуры и про то, что их использование может сэкономить память, которую занимает программа, т.к. по 100 раз не выделяется область управляемой кучи для каждого экземпляра, если используешь структуру. В связи с этиа вопрос - можно ли сказать, что когда пишешь программу, лучше вначале использовать структуры и только если они вдруг не устраивают - менять их на классы? |
| Автор: PashaPash 28.1.2009, 19:00 | ||
Под класс память выделяется ровно один раз. А под структуру - минимум один раз, а при активной работе - еще много-много раз. |
| Автор: Grok 29.1.2009, 12:13 |
| подпишусь под QryStaL и PashaPash, классы передаются по ссылке, а структуры по значению. Структуры например селесообразно использовать когда нужно обьеденить несколько "примитивных" данных в одну конструкцию. |
| Автор: Vex 1.2.2009, 11:04 | ||
для структуры память выделяется не в куче, а в стеке. по поводу экономии памяти: при копировании структуры у тебя как раз будет выделяться память для еще одного экземпляра. при копировании класса (экземпляра) - только ссылка на него. |
| Автор: thomas 4.2.2009, 00:51 |
| Привет всем. Можно и мне добавить свои пять копеек про структуры и их использование. Представте себе трехуровневую архитектуру приложения. Т.е. имеем три уровня: уровень данных, уровень бизнес логики и уровень представления. При этом уровень бизнес логики имеет референс на уровень данных, а уровень представления имеет референс на уровень бизнес логики. Уровень представлени (user interface - GUI) Уровень бизнес логики (классы бизнес обьектов BL ) Уровень данных (классы для работы с хранилищем данных DAL) Представили? Так вот, рассмотрим взаимодействие двух нижних уровней. Из самого нижнего слоя вы не видите ничего кроме хранилища данных(ни BL ни GUI). Задача этого слоя организовать доступ к хранилищу данных и методы работы с ним: вставка, чтение, изменение и удаление данных. Из вторго слоя (BL) вы видите только обьекты нижнего слоя (DAL), но выше стоящий слой (GUI) вы не видите. Соответственно из самого верхнего слоя вы видите обьекты второго слоя (BL) и не видите обьекты самого нижнего слоя (DAL). Теперь самое интересное: как организовать взаимодействие между первым и вторым слоями нашего приложения? Как DAL может обмениваться данными с BL. Ведь из слоя бизнес логики мы должны передавать данные на обработку в слой данных и получать их обратно через слой данных их хранилища данных. При этом слой бизнес логики совершенно не должен знать что там происходит с данными на нижнем слое, с каким хранилищем данных он работает, с XML, с MS SQL или MySQL или Oracl. Используются там хранимые процедуры или пишутся SQL команды слою бизнес логики ЗНАТЬ совсем не к чему. И вот мы подошли к тому, с чего начинали, к СТРУКТУРАМ. Исходя из того что, обьект - класс из слоя бизнес логики невозможно прописать в качестве входного параметра в метод класса слоя данных, можно и нужно использовать структуры в качестве параметров для методов классов слоя данных. Как это выглядит? С слое данных создаете структуру и класс, ну например, который создает соединение с БД на сервере и предоставляет стандартные методы для вставки изменения и удаления данных в таблицу БД. В слое бизнес логики создаете класс описывающий обьект бизнес логики, ну например клиент, и предоставляющий методы для работы с ним. Ну например самый простой: в таблице базы данных отдельно предусмотрены поля для имени, отчества и фамилии. Наш класс имеет соответственно три свойства. А мы хотим иметь ФИО полностью, т.е. пишем метод выдающий ФИО. Теперь самое интересное. Для вызова методов класса из слоя данных в классе слоя бизнес логики создается экземпляр этого класса в конструкторе . Далее нам надо создать нового клиента. В методе сохранить вызываем структуру, присваиваем значения её полям и в экземпляре сласса слоя данных вызываем соответствующий метод и в качестве параметра передаем ему заполненную структуру. А уже там внизу из этой структуры извлекут данные вставят их в соответствующие SQL команды и передадут их на выполнение. Соответственно поля структуры должны соответствовать по типу полям класса бизнес логики. |
| Автор: PashaPash 4.2.2009, 10:43 | ||||
| thomas, да, паттерн "доменная модель" на пальцах - это круто, но при чем тут структуры? Классы тоже вполне справляются. И без выжирания доп памяти на каждом "качестве параметра передаем". Если совсем точно - то вот как раз в доменной можели структуры лучше не использовать, т.к. сразу отпадают все возможные бонусы типа Identity Tracking и Lazy Load. А то как в анекдоте: Рыба - животное, живет в воде, покрыто чешуей. Но если бы оно было покрыто шерстью, в шерсти жили бы блохи...
Невозможно прописать в качестве входного параметра в метод класса слоя данных - возможно, нужно, и прописывают. Эта мегапробема отлично решается выносом объектов бизнес логики - BE - в отдельную сборку. Но уж точно не дублированием всех классов BE в виде структур. UPD: Официальный гайд от производителя (с)
|
| Автор: mihryak 4.2.2009, 17:25 |
| согласен полностью с PashaPash, дублирование ни к чему хорошему не приведет, задолбаетесь поддерживать соответствие между структурой и классом общепринятая практика - выносить доменные объекты в одну общую сборку |
| Автор: kemiisto 4.2.2009, 18:35 | ||
Это как так? Хотя из того, что у Вас память под класс выделяется, а не под экземпляр можно сделать определённые выводы... Толька такую операцию называть копированием объекта будет как раз таки неверно. Это именно копирование ссылки на объект, а если хотите скопировать объект - Вообще, топикстартер слышит звон, но ... На самом деле структуры (или записи) в современных мейнстрим языках - это как бы "недообъекты". Им не хватает методов, да и память под них не там выделяется. Есть два альтернативных подхода:
Вот это, что называется правильный дизайн языка. И OBERON, и Smalltalk. А C# (Java, Delphi, ...) так и тащать за собой тяжёлое наследство прошлого, родившееся из ускоренных попыток Страуструпа побыстрее внедрить в С объекты, природу которых он тогда ещё не очень то понимал. Но свои ошибки признавать умеют очень немногие... P.S. Сорри за оффтоп... |
| Автор: Partizan 4.2.2009, 18:41 | ||
kemiisto, Ну понятно же, что речь шла именно об объектах ;) В компетенции PashaPash сомнений никаких не возникает |
| Автор: PashaPash 4.2.2009, 18:53 | ||
дада, память выделяется под класс, а я дикий нуб. Каюсь, пойду читать троелсона с логотипом винграда (с), или что там нубам положено... Добавлено через 1 минуту и 18 секунд Из этого заявления тоже можно сделать далеко идущие выводы... |
| Автор: kemiisto 4.2.2009, 19:44 | ||
Ну и троллинг исчо никто не отменял! Ага! Вот только сделал их, пожалуй, один Вирт! Бритва Окама, однако. PashaPash, не заводись! Я, возможно, иногда бываю резок, не надо так вот сразу принимать на свой счёт и сгущать краски. |
| Автор: PashaPash 4.2.2009, 20:08 | ||||
Лично мне система типов .NET (с методами у структур и у примитивных типов) нравится намного больше, чем в Java, где примитивным типам пообрезали много чего этой самой бритвой. Оба "чистых" подхода на практике вызывают неудобства в определенных задачах. На чисто-ООП языке с железом эффективно не поработаешь. А на рекордах - чистых структурах - не напишешь крупный проект. На C# можно писать в pure-OOP стиле, просто забыть про слово struct. Или клепать километры кода с чистыми структурами. Что плохого в возможности выбора?
Ну можно ж потроллить... |
| Автор: kemiisto 5.2.2009, 10:46 | ||
С первым - скорее соглашусь, второе - считаю спорным. Взять хотя бы GNOME 2.0. P.S. Partizan, с назначением! |
| Автор: PashaPash 5.2.2009, 16:19 | ||
Шанс успешно написать крупный проект намного меньше |
| Автор: kemiisto 5.2.2009, 16:33 | ||
Мишка де Иказа уже осознал свою ощибку.
|
| Автор: PashaPash 5.2.2009, 16:37 |
| kemiisto, да, счас он набросает на коленке конвертор C<->C#<->Python и наступит мир во всем мире |
| Автор: Partizan 5.2.2009, 23:20 | ||
Спасибо, конечно, но Модератор: Давайте вернёмся к теме обсуждения. ;) |