а можно узнать

и как это проявляется

?

и еще. если Вам удалось раз и навсегда решить

с удовольствием послушаю решение

да вообще иронии нет.. Вот только как знание ответа на вопросы поможет в написании кода... Возьми с десяток проектов с абстрактными классами, всё реализовано но у всех по разному..


а мне больше всего хочется послушать вот по этому, особенно по второй части

Ну и как они связаны?  

Добавлено через 49 секунд

Почему по-умолчанию считается, что их использовать нельзя?   

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

может использовать вместо должен слово может? если вопрос верен, и именно в этом слове подвох то, не должен.

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

а почему можно?

Это сообщение отредактировал(а) krundetz - 2.4.2013, 15:51

опрос затеять штоли))))

Можно - потому что есть возможность 

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

вообще на мой взгляд вопросы не совсем корректны в формулировках?


зачем?

что бы устроить холивар остроконечников и тупоконечников

Перечитай свой вопрос. Ты спрашивал "а почему можно"

А нужно ли - это совсем другой вопрос   

спалил

Ну вот я и говорю, что вопросы не совсем корректны

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

Такс, извиняюсь, что пропал. Времени не было.


Protected методы уровня абстракции класса подразумеваются, что используются в absctract методах. 
Например, если у вас в уровне абстракции есть public метод и в нём используется protected метода, а так же есть abstract метод - то это ошибка проектирования. Это следует из принципа единой ответственности. Класс, который показывает, каким способом расширяется приложение, должен быть ответственен за один из способов расширения.


Нет, не должен. Опять же следует из принципа единой ответственности. 
Чаще всего этот вопрос возникает, когда нужно использовать в методах класса getter/setter. Если ваш класс ответственнен за предоставление данных, то он не должен их же использовать. 
Если нужно выполнять какую то не тривиальную операцию в классе, нужно либо выделить дочернюю абстракцию с решением данной задачи, либо создать отдельный класс, для её решения.


Да, вы правы, я не верно задал вопрос.


Вы более элегантно изложили то что у меня вертелось в голове, спасибо.

Добавлено @ 16:52

Это самый замечательный функционал, который ввели не до конца продумав.
На мой взгляд static методы нужны и оправданы лишь для порождения экземпляра текущего класса (или дочерних) и получение информации о не расширяемых свойствах класса. 



Это сообщение отредактировал(а) Deja_Vu - 9.4.2013, 16:54

имхо чушь
например, что тут не так?




с чего бы это?

или я должен отдельный класс создать для вычисления массы?

  

   нерепрезентативна

Добавлено @ 16:58
гы. на С++ написал. ну, думаю меня поймут

Это сообщение отредактировал(а) baldina - 9.4.2013, 17:00

Чего?
Кем подразумеваются?


Не понял.

Т.е. если у меня в сеттере происходит фильтрация каких-то raw значений.
То, если я буду устанавливать свойства скопом (например, инициализации массивом при создании объекта класса), я должен буду этот же функционал фильтрации реализовывать еще раз?
Или создавать специально для этого случая приватные/протектед методы для каждого из свойств и вызывать их в сеттерах и конструкторе соответственно?

А нафига?

для чего по вашему нужны getter/setter? особенно, если операция тривиальная.
что бы при изменении операции (не наследовании, а именно изменении в процессе разработки) не нужно было переписывать доступ к элементам класса.
других резонов нет.
если другие функции этого класса (неважно с каким модификатором доступа) должны получать доступ к этому элементу, логично этот доступ реализовать через getter/setter именно для упрощения обеспечения целостности класса в при его изменениях.

а плодить абстракции вообще надо с осторожностью

не поймут.


То что это вообще не подходит под тот случай, который я описыва. Где здесь абстрактный метод?


Если я правильно понял это C++ творчество, то тут вычисление массы является getter-ом некого виртуального свойства.

Расхождения со своими словами я тут не вижу

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

Я же написал, что это следствие из SOLID. 
Если вы считаете его не верным, то и следствие для вас будет не верно.


Изходя из SOLID конструктор не попадает под это правило. Извиняюсь, что этого не указал ранее, из головы вылетело.

А вообще, на всякое "А нафига?" можно сказать - да пожалуйста. Только потом сами для себя объясните, по каким правилам вы классы создаёте. Я устал уже от "выковыривания" их из головы.
Как только нарушается одно из правил, создается новый уровень абстракции или выделяется класс для реализации функционала. Такой код на много(на порядок) проще поддерживать. А если суть ООП в снижении сложности поддержки и понимания кода - значит это верный путь, выделять абстракции.