избегая, если заявления

Question

Сегодня я думал об объектно-ориентированном дизайне, и мне было интересно, стоит ли вам избегать операторов if. Я думаю, что в любом случае, когда вам требуется оператор if, вы можете просто создать два объекта, реализующих один и тот же метод. Две реализации метода будут просто двумя возможными ветвями оригинального оператора if.

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

EDIT

Ничего себе, это не заняло много времени. Я полагаю, это слишком экстремально. Можно ли сказать, что при ООП вы должны ожидать гораздо меньше заявлений?

ВТОРОЕ РЕДАКТИРОВАНИЕ

Как насчет этого: объект, который определяет реализацию своего метода на основе своих атрибутов. То есть вы можете реализовать someMethod() двумя способами и указать некоторые ограничения. В любой момент объект будет направлен к правильной реализации метода на основе его свойств. Так что в случае if(x > 5) просто есть два метода, которые опираются на атрибут x

Answer 1

Я согласен с Вэнсом, что ЕСЛИ не очень хорошо, потому что оно увеличивает условную сложность и его следует избегать, насколько это возможно.

Полиморфизм является полностью жизнеспособным решением при условии, что он имеет смысл, а не "Избегать, если".

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

Answer 2

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

Answer 3

Вы должны понять, что на самом деле означает (x > 5). Если предположить, что x представляет число, то оно в основном «классифицирует» все числа больше пяти. Таким образом, код будет выглядеть на языке с синтаксисом Python:

class Number(Object):

    # ... Number implementation code ... #

    def doSomething():
        self = 0
        return self

    def doSomethingElse():
        pass

class GreaterThan5(Number):
    def doSomething():
        print "I am " + self

    def doSomethingElse():
        print "I like turtles!"

Тогда мы могли бы запустить код, подобный следующему:

>>> type(3)
<class Number>
>>> type(3+3)
<class GreaterThan5>
>>> 3.doSomething()
0
>>> (3 + 3).doSomething()
I am 6
>>> (7 - 3).doSomethingElse()
>>>

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

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

Answer 4

Я скажу, что ответ смутно да-иш. Особенно, когда язык допускает тяжелое функциональное программирование (например, C #, F #, OCaml).

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

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