@ilja123

Скажите, отделение данных от логики действительно явл. правилом хорошего тона в с++ ? Что-то я не видел, чтобы в других яз. это практиковалось. По мне, так это дурдом! Только для работы 1-го класса, нужно задействовать 3-и файла. В одном описать, в другом реализовать, в 3-м использовать... Зачем так усложнять????

0

@DrOffset

ilja123, это везде используется. См. тут.
Насчет усложнения - читай тут.

0

ValeryS

Не понял, переведи
вот когда у тебя будет 100500 классов и все друг с другом взаимодействуют,и нужно исправить один
поймешь что так удобней
другой пример создал класс, настолько удобный что решил его еще раз использовать, а может и не раз
как выдерешь его из готового проекта
а так взял два файла и перенес в новый проект
или вообще скомпилил из этого класса библиотеку

0

@ilja123

а по существу???

0

@DrOffset

Разве не по существу? Потрать 10 минут времени и прочитай статью. Часть вопросов должна отпасть. Если после этого еще останется что спросить, приходи сюда и задавай.

0

@ilja123

тут нет вопросов Я спрашиваю зачем в одном файле делать только описание, а в другом реализацию? Чем это упрощает?? Если у меня 100500 классов То над будет работать с 201000 файлов В чем преимущество???

Добавлено через 1 минуту
Я вам сейчас отзыв накатаю за 10 минут за флуд

0

@DrOffset

Вот как ты вопрос сформулировал, такой и ответ получил.
Разница у этого вопроса и у первого - колоссальная. От формулировки зависит то, на что был получен ответ.

По этому вопросу все гораздо проще, если писать все в одном файле получим грандиозное замедление компиляции из-за специфики сборки в С\С++- это во-первых. Во-вторых, при правильном проектировании интерфейсов, не смотря на то, что файлов много, достаточно посмотреть на объявление класса, чтобы понять как им пользоваться, поэтому лазить во второй файл (с реализацией), зачастую, уже не нужно.

1

@ilja123

Оуу блиин Ну канеш!! Я про компиляцию забыл!!!!!!!!!! Я прост на Шарпе посидел Отупел немног Сорри

0

ValeryS

ты имеешь ввиду c и h файлы?
тогда так
h файлы подключаются include, на самом деле не подключаются а "вписываются"
макрос include заносит на свое место содержимое файла
а c файл это единица трансляции
они не обязательно вместе все компилируются

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

1

@Mr.X

Это называется модульным программированием. Подробно см. статью в Википедии.
Его основной принцип: программа разбивается на модули, а каждый модуль - на интерфейс и реализацию. История концепции модулей как единиц компиляции восходит к языкам Фортран II и Кобол, то есть, к концу 1950-х годов.
Языки, формально поддерживающие концепцию модулей: IBM S/360 Assembler, Кобол, RPG, ПЛ/1, Ада, D, F (англ.), Фортран, Haskell, Blitz BASIC, OCaml, Паскаль, ML, Модула-2, Оберон, Компонентный Паскаль, Zonnon, Erlang, Perl, Python и Ruby.
<из той же статьи в Википедии>.

0

@Voivoid

Это практикуется во всех языках ( ну, конечно где средства языка это позволяют ). Пока сам шишек не набьешь на больших проектах - не поймешь. А на лабах-то, в которых три с половиной строчки кода, понятно дело что профит от всего этого не очевиден

0

@ilja123

Кого волнует, что было в 50-х годах?

В каких?

0

@Voivoid

Да бери практически любой созданный с конца 80-х

0

@ilja123

Ну и как это делается с C# например?

0

@Voivoid

При помощи ООП, в частности интерфейсов

http://ru.wikipedia.org/wiki/%... 1%80%D0%B0

http://ru.wikipedia.org/wiki/Model-View-Controller

0

Убежденный

Вы еще PIMPL не видели !

0

@ilja123

Voivoid,
Может хватит???

Добавлено через 1 минуту
Ну правд! Создал ток 2-а класса, открыл 5-ть вкладок и стал пытаться наладить взаимодействие между ними....

0

Убежденный

ilja123, я вполне понимаю Ваше недоумение по этому поводу.
Но дело в том, что большая часть всех этих практик с разделением на интерфейс и реализацию,
данные и логику, модель и представление и т.п. возникла далеко не на пустом месте.

В общем случае всегда полезно что-то от чего-то отделить.
Есть такое хорошее правило проектирования: "разделяй и властвуй".

Отделил интерфейс от реализации - значит, сделал их независимыми друг от друга, можешь
отдать клиентам интерфейс и не беспокоить их после этого месяцами, а сам занимаешься
реализацией. Об изменениях в которой они даже не узнают. Про время компиляции уже
написали выше. В некоторых случаях можно менять реализацию без перекомпиляции
клиентского кода, для больших проектов это бывает важно.

Отделил данные от логики - значит, обеспечил себя возможностью тестировать их отдельно
друг от друга. Представьте, насколько сложнее создать тесты для программы, работающей с
данными, когда вся логика работы с БД и ее специфическими особенностями намертво
зашита в код. Да еще перемешана с обработкой UI. А такого г-нкода вокруг навалом.
В итоге нельзя нормально протестить ни работу с базой, ни сам UI, ни поменять БД или
оформление, все "прибито гвоздями" и размазано по куче файлов, нажмешь в одном месте -
вспучит в другом...

Но выгоды от вышеописанного можно почувствовать только на проектах не ниже некоторого
"веса", в других случаях будет нейтрально или во вред.

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

3