Программирование для и собой
Мне нравится объяснение Лямбд в этой статье: Эволюция LINQ И Его Влияние На Дизайн C#. Это имело много смысла мне, поскольку это показывает реальный мир для Лямбд и пристраивает его как практический пример.
Их быстрое объяснение: Лямбды являются способом рассматривать код (функции) как данные.
9 ответов
Приведу аналогию.
Я приехал из той части мира, где английский не является основным языком. Но это необходимо для всего в жизни.
В один из тех обычных дней, когда я был подростком, я сказал что-то очень смешное на английском. Тогда мой папа сказал: « Сынок, думай по-английски. Тогда вы научитесь бегло »
Я думаю, что это идеально подходит для данной ситуации.
Думайте, пробуйте и задавайте вопросы передовым методам на вашей игровой площадке. Вы скоро поймете, что лучше для чего. Зачем вообще нужна недвижимость. Почему это должно быть публично? Почему я не должен вызывать виртуальный член из конструктора? Позвольте мне попробовать использовать модификатор "новый" для вызова метода. Что происходит, когда я пишу 10 вложенных уровней if-then-else и пытаюсь прочитать его снова через 10 дней . Какого черта я должен использовать шаблон фабрики для простого проекта. И так далее.
И тогда вы поймете, не стреляя в ногу ,
Я считаю разумным, если вы впоследствии сознательно выбросите код. В частности, если вы экспериментируете с чем-то совершенно другим, использование ярлыков имеет смысл. Только не позволяйте этому вести к привычкам, которые переходят в «настоящий» код.
Нарушение общих принципов всегда нормально! Нарушение принципа не является ошибкой, это компромисс. Стоимость отказа от написания чистого кода будет тем выше, чем дольше просуществует ваше программное обеспечение. Моя позиция такова: если есть сомнения, сделайте это чистым!
Конечно, нормально. Это ваш код , вы можете делать с ним все, что хотите. Лично я стараюсь придерживаться хорошей практики и в своем частном коде, просто чтобы сделать это естественной привычкой, чтобы мне не приходилось думать об этом.
Короткий ответ - да, если вы считаете, что многое выиграете, сделав вещи общедоступными, а не закрытыми с помощью аксессуаров, вы можете сделать это. Я думаю, что последовательность - это самое главное, о чем нужно помнить. Например, не делайте некоторые переменные общедоступными, а некоторые - нет. Если вы отказываетесь от передового опыта, делайте то же самое. Это возвращается к компромиссу. Практически никто не следует многим спецификациям IEEE в отношении того, как следует выполнять и документировать разработку программного обеспечения, потому что накладные расходы слишком велики и могут стать неуправляемыми. То же верно и для личного, легкого программирования. Сделать что-то быстро и грязно - это нормально, только не привыкай к этому.
Открытые члены допустимы в схеме проектирования объекта передачи данных :
Как правило, члены в объекте передачи определяются как общедоступные, что устраняет необходимость получения и установить методы.
Одним из ключевых преимуществ ООП является масштабирование и ремонтопригодность. Инкапсулируя код, можно скрыть реализацию. Это означает, что другим программистам не обязательно знать реализацию, и они не могут изменить внутреннее состояние вашего объекта. Если ваш язык не поддерживает свойства, вы получите много кода, который запутывает и раздувает ваш проект. Если над кодом не нужно работать нескольким программистам, вы не создаете повторно используемый компонент, а ВЫ являетесь программистом обслуживания, тогда код любым способом позволяет вам выполнять задачи .
Нужно ли горничной заправлять себе постель по утрам, чтобы практиковаться в правильной заправке постели?
Примечание: это также зависит от языка:
В Scala , согласно Согласно Uniform Access Principle , клиенты читают и записывают значения полей, как если бы они были общедоступными, даже если в некоторых случаях они фактически вызывают методы. Сопровождающий класса имеет право изменять реализацию, не заставляя пользователей вносить изменения в код.
Scala сохраняет имена полей и методов в одном пространстве имен.
Многие языки, например Java, хранят имена полей и методов в отдельных пространствах имен.
Однако в результате эти языки не могут поддерживать принцип унифицированного доступа, если только они не встроят специальную поддержку в свои грамматики или компиляторы.
Итак, реальный вопрос:
Что такое сервис вы выставляете (здесь публичное поле) ?.
Если служба (получение / установка значения заданного типа) имеет смысл для вашего API, то "ярлык" является допустимым.
Если вы в конечном итоге инкапсулируете это поле, все в порядке, потому что вы сделали ярлык по «правильной» причине (API и доступ к сервису), а не по «неправильной» причине (быстрый специальный доступ).
Хороший модульный тест (мыслящий как пользователь вашего API) может помочь вам проверить, нужно ли обращаться к этому полю напрямую или оно полезно только для внутренней разработки других классов в вашей программе.
Вот мое мнение:
Я бы посоветовал избегать общедоступных полей. У них есть отвратительная привычка кусать вас позже, потому что вы не можете их контролировать. (Здесь вы ищете волатильность. ) Кроме того, если вы решите изменить их внутреннюю реализацию, вам придется затронуть гораздо больше кода.
Опять же, это то, что инструменты рефакторинга за. Если у вас есть достойный инструмент для рефакторинга, это не так уж и сложно.
Нет серебряной пули. Я не могу повторить этого достаточно. Если у вас есть работа, и вам нужно сделать ее в спешке, написание одной строки кода вместо восьми (как в случае с Visual Basic), безусловно, будет быстрее.
Правила предназначались для нарушения. Если правило не обязательно применимо в вашем случае, не используйте его. Паттерны проектирования, рекомендации по кодированию, законы и передовой опыт не следует рассматривать как смирительную рубашку, которая требует от вас ненужного усложнения кода до такой степени, что он становится чрезвычайно сложным и трудным для понимания и поддержки. Не позволяйте никому заставлять вас заниматься практикой только потому, что она популярна или «стандартна», когда она не соответствует вашим требованиям.
Опять же, это субъективное мнение,