Красота кода

[Smitt&Wesson]

Сообщение от BOBAH13

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

Спасибо. Я это называю иначе (не хочу флудить), хотя суть понятна.
Пепел Феникса, более детально пояснил. Так, что отпишусь в одном посте.

[Пепел Феникса]

Можно конечно выкрутиться, создать класс и статическую функцию в нем, но это не то, т.к. доступа к предкам и к полям класса не будет, т.к. это не будет частью объекта/класса.

ну а по этой части это похоже на class-helper так называемый.

помоему это выходит чтото среднее между Class-Helper и Interface.

[netrino]

Следует уточнить, что дано определение типажа (trait), которое используется в некоторых объектно-ориентированных языках. Фактически, trait похож на множественное наследование в C++, он позволяет структурированно добавлять функционал к классу, разбивая сей функционал на части. Похожим функционалом обладают примеси в Ruby и категории в Objective-C.
Можно ещё встретить понятие type traits, которые лишь описывают некоторые свойства типа, но не несут в себе функционала, полезны для обобщённого программирования (type_traits в C++, __traits в D) и подобны классам типов (type classes) в Haskell.

[ds.Dante]

Сообщение от Базиля

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

Не спешите использовать все фишки ООП, паттернов, и т. д., как только про них прочитали. Держите их в голове, но пишите код самым простым образом, не внося неоправданных усложнений. Вы сами почувствуете (надеюсь), когда разбиение кода на модули сделает программу гибче и читабельнее. Код размером меньше 100-200 строк (без комментариев и пустых строк) обычно вообще нет смысла разбивать на классы.

И опять же, работайте с чужим качественным кодом; периодически показывайте свой код более опытному товарищу.

Сообщение от Пепел Феникса

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

Тогда почему панель без ООП?

[Пепел Феникса]

Тогда почему панель без ООП?

код под панель писал раньше(на функциях), переписывать пока некогда.

[Базиля]

ds.Dante

И опять же, работайте с чужим качественным кодом;

Что вы именно подразумеваете под качественным?

периодически показывайте свой код более опытному товарищу.

Так и делаю И мне советуют использовать классы

Спасибо!

[ds.Dante]

Сообщение от Базиля

Что вы именно подразумеваете под качественным?

Без багов, оптимизированный, читабельный и легкоизменяемый. Обычно это серьёзный софт, которым пользуется множество людей, особенно open source.