Уже давно известно, что Бритва Оккама не работает для больших систем.
Кстати, как раз об этом говорили на конференции «Свободное программное обеспечение в высшей школе», проходившей в январе этого года.


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


Это сообщение отредактировал(а) Deja_Vu - 10.4.2013, 08:38

если все, то конечно нет необходимости. но если не все? именно такой пример я и привел

кстати, вот те же примеры на пхп




Добавлено через 2 минуты и 22 секунды

вопрос-то был не в квалификаторе, а применении изнутри класса


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

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

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

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

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



Хм, так и что тут не так? 
Если один и тот же метод abstract и protected - он по прежнему является abstract методом.
Может я не полностью выражаю свою мысль, поэтому у нас с вами проблема во взаимопонимании

Вот тут явно нарушение в принципе единой ответственности. Такой код, кстати встречается очень часто во многих проектах.


Смотрите, если ваш класс предоставляет public getter к свойству и ещё его же использует где то в своих методах - то тут явная проблема с принципом единой ответственности. Т.е. как только у вас появляется метод, который находится внутри класса, который начинает использовать этот public getter возникает вопрос, а почему он там находится, если он с полями работает через внешний интерфейс?


Уровень абстракции появляется тогда, когда текущий уровень абстракции нарушает SOLID

Добавлено @ 10:44

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

Это сообщение отредактировал(а) Deja_Vu - 10.4.2013, 10:45

чем плох этот контекст? задача простая и типовая. как еще её решить. не нарушая ваших принципов?


я вроде бы понимаю о чем вы. но, повторю, как решить такую задачу: есть общая схема обработки препроцессор-решатель-постпроцессор. 
конечному пользователю нужен лишь сам процесс - public function process()
каждая из трех частей нужна только в процессе обработки (т.е. не public)
работа каждой из частей может изменяться (в переопределенных классах)
некоторые части могут иметь действие по умолчанию, которое может, при необходимости, переопределяться
итого

вам такой подход не нравится. ок, тогда
1. чем он плох? (с примерами, пожалуйста)
2. как его изменить, что бы он стал хорош?


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


слишком общее и потому совершенно пустое утверждение (имхо и неверное - OCP не относится к выделению абстракций). что именно и как именно в SOLID нарушает мой пример с получением массы?
как нарушение SOLID может удовлетворять Бритве Оккама и наоборот, удовлетворение SOLID нарушать его? (приведите пример)


думаю мы это одинаково понимаем. витиеватой фразой я лишь хотел намекнуть на SRP



именно. есть методология, методики нет. два разных решения могут быть одинаково хороши, выбор в таком случае - дело вкуса.

Добавлено через 8 минут и 29 секунд
кстати, не приходило вам в голову, что внутреннее использование геттеров - это как раз поддержание OCP?

Это сообщение отредактировал(а) baldina - 10.4.2013, 11:21

бэктрейсы java видели?





Скрин выше, его точно на порядок проще поддерживать?   

Браузер упал, все что писал - пропало. Пипец желания нет повторяться. Но осилю спустя время.


И? Могу вам привести класс на 4000 строк, могу заявить, что backtrace там будет не меньше.


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

Добавлено через 4 минуты и 7 секунд

Перечитаю Мэйера. Но я более чем уверен, что в public нельзя использовать public методы - верен.
К тому же, я поддерживаю использование getter/setter т.к. они очень полезны при рефакторинге. А вот уже нужда в рефакторинге возникает, когда вам нужно сложную функцию вставить в getter/setter. 
А если оставлять как есть, то это приводит к ужаснейшому ###коду - проверено.

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

Плохо, потому что мне нужно полностью просмотреть код класса, что бы понять, как связаны pre, post и run. И как же заставить Processor работать правильно.


Классы меньше. Понять логику работы проще.
Легче покрыть тестами.
Backtrace покажет в каком уровне абстракции возникает ошибка и исправлять нужно будет только там.

Добавлено через 9 минут и 3 секунды

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

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

Всё нужно решать в общем виде. Частности лгут и не приводят к хорошему результату.
А вообще в SOLID я жирным выделил те компоненты, о которых я говорю, а не обо всем принципе  Наверное получилось не понятно.


Меня ввел в ступор данный вывод. Наверное мы друг друга не поняли.

Это сообщение отредактировал(а) Deja_Vu - 10.4.2013, 13:56

Я бы сказал так, есть множество методов N не удовлетворяет методологии SOLID -))
Я нашел для себя один метод который не входит в множество N и ещё ни разу ни кем не видел предложенного другого метода.

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

Это сообщение отредактировал(а) Deja_Vu - 10.4.2013, 14:20

но почему? если это просто вера - дело ваше, до религии мне дела нет. или приведите обоснования (что врядли, т.к. есть опровергающие примеры - см. выше)


вы удивитесь, но если есть getter и вы его используете повсюду, то весь рефакторинг будет заключаться в написании нового тела getter'a
кстати, я не настаиваю, но есть мнение, что рефакторинг - это устранение бардака. так может его не создавать?


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

но и Fortop поддерживаю: мельчить не надо. и вообще не надо фанатизма   

  

Цитата(Deja_Vu @  10.4.2013,  13:54 )

Браузер упал, все что писал - пропало

ну вы там поаккуратней, так и важное потерять можно. возьмите хороший браузер, не падающий: ie, mozilla, chrome.

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

Для себя я выделяю несколько этапов рефакторинга:
1. на этапе проектирования
2. после первой реализации
3. после длительного практического использования

Причем только 2 пункт обязательный при любом уровне задачи.

Это сообщение отредактировал(а) krundetz - 10.4.2013, 17:05

в вашем случае код класса смотреть не надо? что-то я не вижу в этом смысле отличий. кстати, что бы понять логику работы класса, изучают документацию и интерфейс. в документации, естественно, будет описана схема pre->run->post.
то, что вы говорите, конечно, имеет место - и понятность, и тесты, и отладка. но выбор правильной степени детализации зависит от задачи, требует вкуса и меры. 
для данного класса из 5 строк деление это чересчур, не находите?


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

получается, вы мне навязываете некие формальные правила нормализации. в результате мой код становится более пухлым, реальной декомпозиции не происходит, реальных дивидендов от этого я не получу. (сравните с нормализацией БД: НФБК, 5НФ, 6НФ, умышленная денормализация).
итого: то что вы проповедуете - форма, прием, но не закон.


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

Deja_Vu, я не против всех этих принципов, я против ортодоксального их использования, я за понимание причин и следствий вместо слепого следования авторитетам.

  , про функцию вы говорите, я говорю про систему(программный продукт) в целом

Дело в том что на проектирование тоже выделяется конечный срок и кроме этого его качество будет зависеть еще от:
1. Полноты полученных данных по решаемой проблематике.
2. Качества проработки ТЗ.
3. Опытности проектировщика.
Отсюда вытекает, что проект не может быть идеальным, а следовательно необходимо получить как можно раньше полноценный прототип, чтобы иметь обратную связь. И уже его можно рефакторить, в соответствие с этой обратной связью.

Это сообщение отредактировал(а) krundetz - 11.4.2013, 16:53

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

чувствуете разницу?
к тому же я сильно сомневаюсь, что неопытный проектировщик сможет после первой итерации значительно улучшить свой проект

Обычно как раз уточнения ТЗ и попытки реализовать их в коде вызывают рефакторинг.
Т.е. вобщем-то это разные вещи, но рефакторить без необходимости исключительно ради любви к искусству.... я бы не стал.

для этого существует куратор с большим опытом.


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