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