Я в одной книге как-то прочитал "правило Буравчика" про уровень доступа - "Лучше всего члены класса делать как private, и только если этот уровень доступа не устраивает - постепенно его повышать.

Я сейчас читаю про структуры и про то, что их использование может сэкономить память, которую занимает программа, т.к. по 100 раз не выделяется область управляемой кучи для каждого экземпляра, если используешь структуру.

В связи с этиа вопрос - можно ли сказать, что когда пишешь программу, лучше вначале использовать структуры и только если они вдруг не устраивают - менять их на классы?

Classes are reference types and structures are value types. Reference types are allocated on the heap, and memory management is handled by the garbage collector. Value types are allocated on the stack or inline and are deallocated when they go out of scope. In general, value types are cheaper to allocate and deallocate. However, if they are used in scenarios that require a significant amount of boxing and unboxing, they perform poorly as compared to reference types. 

Consider defining a structure instead of a class if instances of the type are small and commonly short-lived or are commonly embedded in other objects.
Do not define a structure unless the type has all of the following characteristics:

- It logically represents a single value, similar to primitive types (integer, double, and so on).
- It has an instance size smaller than 16 bytes.
- It is immutable.
- It will not have to be boxed frequently. 
- If one or more of these conditions are not met, create a reference type instead of a structure. Failure to adhere to this guideline can negatively impact performance.

Под класс память выделяется ровно один раз. А под структуру - минимум один раз, а при активной работе - еще много-много раз.

подпишусь под QryStaL и PashaPash, классы передаются по ссылке, а структуры по значению. 
Структуры например селесообразно использовать когда нужно обьеденить несколько "примитивных" данных в одну конструкцию. 



Это сообщение отредактировал(а) Grok - 30.1.2009, 17:10

для структуры память выделяется не в куче, а  в стеке.

по поводу экономии памяти:
при копировании структуры у тебя как раз будет выделяться память для еще одного экземпляра.
при копировании класса (экземпляра) - только ссылка на него.

Привет всем.
Можно и мне добавить свои пять копеек про структуры и их использование.

Представте себе трехуровневую архитектуру приложения.
Т.е. имеем три уровня: уровень данных, уровень бизнес логики и уровень представления.
При этом уровень бизнес логики имеет референс на уровень данных, а уровень представления имеет референс на уровень бизнес логики.

        Уровень представлени (user interface - GUI)

    Уровень бизнес логики (классы бизнес обьектов BL )

Уровень данных (классы для работы с хранилищем данных DAL)

Представили? 
Так вот, рассмотрим взаимодействие двух нижних уровней. 
Из самого нижнего слоя вы не видите ничего кроме хранилища данных(ни BL ни GUI). Задача этого слоя организовать доступ к хранилищу данных и методы работы с ним: вставка, чтение, изменение и удаление данных.
Из вторго слоя (BL) вы видите только обьекты нижнего слоя (DAL), но выше стоящий слой (GUI) вы не видите. 
Соответственно из самого верхнего слоя вы видите обьекты второго слоя (BL) и не видите обьекты самого нижнего слоя (DAL).
Теперь самое интересное: как организовать взаимодействие между первым и вторым слоями нашего приложения? Как DAL может обмениваться данными с BL. Ведь из слоя бизнес логики мы должны передавать данные на обработку в слой данных и получать их обратно через слой данных их хранилища данных. При этом слой бизнес логики совершенно не должен знать что там происходит с данными на нижнем слое, с каким хранилищем данных он работает, с  XML, с MS SQL или MySQL или Oracl. Используются там хранимые процедуры или пишутся SQL команды слою бизнес логики ЗНАТЬ совсем не к чему. 
И вот мы подошли к тому, с чего начинали, к СТРУКТУРАМ. Исходя из того что, обьект - класс из слоя бизнес логики невозможно прописать в качестве входного параметра в метод класса слоя данных, можно и нужно использовать структуры в качестве параметров для методов классов слоя данных.
Как это выглядит?
С слое данных создаете структуру и класс, ну например, который создает соединение с БД на сервере и предоставляет стандартные методы для вставки изменения и удаления данных в таблицу БД.
В слое бизнес логики создаете класс описывающий обьект бизнес логики, ну например клиент, и предоставляющий методы для работы с ним. Ну например самый простой: в таблице базы данных отдельно предусмотрены поля для имени, отчества и фамилии. Наш класс имеет соответственно три свойства. А мы хотим иметь ФИО полностью, т.е. пишем метод выдающий ФИО.
Теперь самое интересное. Для вызова методов класса из слоя данных в классе слоя бизнес логики создается экземпляр этого класса в конструкторе . Далее нам надо создать нового клиента. В методе сохранить вызываем структуру, присваиваем значения её полям и в экземпляре сласса слоя данных вызываем соответствующий метод и в качестве параметра передаем ему заполненную структуру.
А уже там внизу из этой структуры извлекут данные вставят их в соответствующие SQL команды и передадут их на выполнение.

Соответственно поля структуры должны соответствовать по типу полям класса бизнес логики.


 




Это сообщение отредактировал(а) thomas - 4.2.2009, 00:54

thomas, да, паттерн "доменная модель" на пальцах - это круто, но при чем тут структуры? Классы тоже вполне справляются. И без выжирания доп памяти на каждом "качестве параметра передаем". Если совсем точно - то вот как раз в доменной можели структуры лучше не использовать, т.к. сразу отпадают все возможные бонусы типа Identity Tracking и Lazy Load.
А то как в анекдоте: Рыба - животное, живет в воде, покрыто чешуей. Но если бы оно было покрыто шерстью, в шерсти жили бы блохи...

Невозможно прописать в качестве входного параметра в метод класса слоя данных - возможно, нужно, и прописывают. Эта мегапробема отлично решается выносом объектов бизнес логики - BE - в отдельную сборку. Но уж точно не дублированием всех классов BE в виде структур.

UPD: Официальный гайд от производителя (с)


Это сообщение отредактировал(а) PashaPash - 4.2.2009, 10:47

согласен полностью с PashaPash, дублирование ни к чему хорошему не приведет, задолбаетесь поддерживать соответствие между структурой и классом
общепринятая практика - выносить доменные объекты в одну общую сборку

Это как так? Хотя из того, что у Вас память под класс выделяется, а не под экземпляр можно сделать определённые выводы...


Толька такую операцию называть копированием объекта будет как раз таки неверно. Это именно копирование ссылки на объект, а если хотите скопировать объект - 

Вообще, топикстартер слышит звон, но ... На самом деле структуры (или записи) в современных мейнстрим языках  - это как бы "недообъекты". Им не хватает методов, да и память под них не там выделяется. Есть два альтернативных подхода:

•  применённый Виртом в языках семейства OBERON, т.н. механизм расширения записей. Т.е. нет даже такого ключевого слова OBJECT. Есть только RECORD. Можно объявлять как обычные записи, так и расширяемые (т.е. дополнять их методами).
•  приенённый Аланом Кейем в Smalltalk. Труъ ООП, так сказать. Всё есть объект. Нет никаких примитивных типов, boxing/unboxing, ...

Вот это, что называется правильный дизайн языка. И OBERON, и Smalltalk. А C# (Java, Delphi, ...) так и тащать за собой тяжёлое наследство прошлого, родившееся из ускоренных попыток Страуструпа побыстрее внедрить в С объекты, природу которых он тогда ещё не очень то понимал. Но свои ошибки признавать умеют очень немногие... 

P.S. Сорри за оффтоп...

kemiisto,  Ну понятно же, что речь шла именно об объектах ;) В компетенции PashaPash сомнений никаких не возникает 

дада, память выделяется под класс, а я дикий нуб. Каюсь, пойду читать троелсона с логотипом винграда (с), или что там нубам положено...

Добавлено через 1 минуту и 18 секунд

Из этого заявления тоже можно сделать далеко идущие выводы...

Ну и троллинг исчо никто не отменял!  


Ага! Вот только сделал их, пожалуй, один Вирт! Бритва Окама, однако.  

PashaPash, не заводись! Я, возможно, иногда бываю резок, не надо так вот сразу принимать на свой счёт и сгущать краски.  

Лично мне система типов .NET (с методами у структур и у примитивных типов) нравится намного больше, чем в Java, где примитивным типам пообрезали много чего этой самой бритвой. Оба "чистых" подхода на практике вызывают неудобства в определенных задачах. На чисто-ООП языке с железом эффективно не поработаешь. А на рекордах - чистых структурах - не напишешь крупный проект.
На C# можно писать в pure-OOP стиле, просто забыть про слово struct. Или клепать километры кода с чистыми структурами. Что плохого в возможности выбора?

Ну можно ж потроллить... 

С первым - скорее соглашусь, второе - считаю спорным. Взять хотя бы GNOME 2.0.

P.S. Partizan, с назначением!  

Шанс успешно написать крупный проект намного меньше  За это время куча проектов, использующих плюшки ООП, догонят, перегонят и вытеснят с рынка. А авторы гнома - экстремалы.