Мне по заданию нужно, чтобы метод LiftingPower() был абстрактым. Как корректнее мне реализовать  метод LiftingPower() в классе Motorcycle? Метод должен устанавливать грузоподъемность, но перед этим спрашивать про наличие коляски у мотоцикла. Если ее нету, то присваивать грузоподьемности значение 0. Мой вариант реализации метода мне не сильно нравиться.

mastermedia, как по мне так мне вообще не нравится то как у тебя написано
повторюсь так писать нельзя:


про мотоцикл:
почему мотоцикл "пытается узнать" есть ли у него коляска только когда у него спрашивают про вес? это же не логично. наличие коляски это свойство мотоцикла. оно уже должно быть определено. передай в конструктор флаг, ну или установи как то по другому это свойство. а потом при установке веса проверь его. но в любом случае ВВОДИТЬ ДАННЫЕ В СВОЙСТВАХ НЕЛЬЗЯ!!!

Экскалупатор,  почему в свойствах нельзя вводить данные, ведь акссесор get для этого и создан, для установки значений? Свойства заменяют методы get и set. А если я не прав, то поправь пожалуйста и тогда как именно нужно вводить значения?

Это сообщение отредактировал(а) mastermedia - 20.1.2012, 09:39

свойство предназначено для того что бы можно было сделать какие то действия с переменной, при этом вызывающий код не знает что это свойство или public переменная. 
вызывающий код просто пишет class.Variable = 5; при это он даже представить себе не может что внутри свойства, ВНЕЗАПНО, будет вызван код который попытается ввести туда еще одну, другую переменную. Представь себе такую ситуацию что у тебя есть метод который создает два экземпляра разных классов, по очереди, и у каждого из них есть общее(по смыслу) свойство которое по условию программы должно быть одинаково для обоих экземпляров. но в твоем случае, когда в set вызывается метод устанавливающий значение, в классах могут оказаться разные значения и как в таком случае нужно будет выкручиваться из положения? писать кучу лишнего кода, которого можно было не писать если бы свойство работало так как ему положено!
задача этих set & get, не в том что бы вызывать какую то логику, а только что бы провалидировать переданное значение, но ни в коем случае не изменять его, я еще пойму замену на 0, когда свойство не может хранить отрицательные значения, но вызывать диалог с пользователем и говорить введи другое значение это уже перебор.
 я конечно понимаю, в них можно даже работу с сетью запихнуть или сохранение в базу, язык это позволяет, но с точки зрения логики и удобства это будут совершенно не очевидные действия. только представь себе человека который будет находить баги вызванные подобными действиями и не понимать отчего же они, ведь он просто "присваивает значение public переменной другого класса).

тут важно усвоить что свойство для вызывающего кода выглядит как переменная, а переменной не свойственно вызывать какой то код!(во что свойство превращается в MSIL`е это уже отдельная тема). 

Экскалупатор, за ввод данных в set акссоре отвечает не явный параметр value. Насколько я понял из выше написанного нельзя два раза вводить данные с помощью этого параметра. А для проверки корректных данных нужно использовать исключения. В ОПП требуется, чтобы все вводимые данные проверялись, а в рамках моего задания подразумевается, что я с исключениями не знаком. В таком случае я могу присвоить параметр value уже самой переменной и проверять данные этой переменной помощью булевского метода и бесконечного цикла для того, чтобы программа требовала от пользователя вводить данные, до тех пор, пока он не введет правильные данные. Вызывающий код не знает public переменная это или свойство, но мне же нужно каким- то образом проверять введенные данные. Конечно, переменной не присуща возможность вызывают какой-то код. Но в случае, если я не буду использовать свойства, то я должен использовать методы для возврата и ввода значения get и set. В этих методах я могу вызывать другой метод для проверки вводимых данных. Шилдт пишет, что свойства предоставляют более совершенный и рациональный путь для достижения того же самого. Плюс еще есть автоматические присваиваемые свойства, они используются, когда не требуется проверять вводимые данные. А обычные свойства требуется использовать, когда нужно проверять вводимые данные. 

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

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

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

Правильно я понял идею?

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