Программирование для себя - PullRequest
8 голосов
/ 21 июля 2009

Если вы пишете что-то самостоятельно, будь то на практике, для решения личной проблемы или просто для развлечения, можно ли время от времени иметь публичное поле? Может быть?

Ответы [ 9 ]

31 голосов
/ 21 июля 2009

Позвольте привести аналогию.
Я родом из той части мира, где английский не является основным языком. Но это необходимо для всего в жизни.
В один из тех обычных дней, когда я был подростком, я говорил что-то очень смешное на английском. Тогда мой папа сказал: « Сынок, думай по-английски. Тогда ты будешь бегло говорить

Я думаю, что это идеально подходит для этой ситуации.

Подумайте, попробуйте и задайте вопросы лучшие практики на вашей игровой площадке. Вскоре вы поймете, что для чего лучше. Почему свойства нужны в первую очередь. Почему это должно быть публичным? Почему я не должен вызывать виртуальный член из конструктора? Позвольте мне попробовать использовать "новый" модификатор для вызова метода. Что происходит, когда я пишу 10 вложенных уровней if-then-else и пытаюсь прочитать его снова через 10 дней . Какого черта я должен использовать фабричный шаблон для простого проекта. И так далее.

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

10 голосов
/ 21 июля 2009

Я думаю, что это разумно, если вы потом сознательно выбрасываете код. В частности, если вы экспериментируете с чем-то совершенно другим, использование ярлыков имеет смысл. Только не позволяйте этому вести к привычкам, которые переходят в «реальный» код.

4 голосов
/ 21 июля 2009

Нарушение общих принципов всегда в порядке! Нарушение принципа - это не ошибка, а компромисс. Стоимость написания не чистого кода будет тем выше, чем дольше будет работать ваше программное обеспечение. Мое мнение таково: если сомневаетесь, сделайте это чистым!

3 голосов
/ 21 июля 2009

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

2 голосов
/ 21 июля 2009

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

1 голос
/ 21 июля 2009

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

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

1 голос
/ 21 июля 2009

Открытые члены допустимы в шаблоне Data Transfer Object :

Как правило, члены в Transfer Object определяются как публичные, что исключает необходимость в методах get и set.

0 голосов
/ 22 июля 2009

Вот мое мнение:

  1. Я бы посоветовал избегать открытых полей. У них есть неприятная привычка кусать тебя позже, потому что ты не можешь их контролировать. (Слово, которое вы ищете здесь, это volatility. ). Далее, если вы решите изменить их внутреннюю реализацию, вам придется коснуться гораздо большего количества кода.

  2. Опять же, это то, для чего нужны инструменты рефакторинга. Если у вас есть достойный инструмент рефакторинга, это не так сложно.

  3. Серебряной пули нет. Я не могу повторить это достаточно. Если у вас есть работа, которую нужно выполнить, и вы должны выполнить ее в спешке, то написание одной строки кода вместо восьми (как в случае с Visual Basic), безусловно, быстрее.

  4. Правила должны были быть нарушены. Если правило не обязательно применяется в вашем случае, не используйте его. Шаблоны проектирования, руководящие принципы кодирования, законы и передовые практики не должны рассматриваться как простой жакет, требующий от вас ненужного усложнения вашего кода до такой степени, что он становится чрезвычайно сложным и трудным для понимания и поддержки. Не позволяйте кому-то заставлять вас практиковать только потому, что это популярно или «стандартно», когда не соответствует вашим требованиям.

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

0 голосов
/ 21 июля 2009

Примечание: это также зависит от языка:

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

Scala хранит имена полей и методов в одном и том же пространстве имен.
Многие языки, такие как Java, хранят имена полей и методов в отдельных пространствах имен.
Однако в результате эти языки не могут поддерживать принцип унифицированного доступа, если они не встроили специальную поддержку в свои грамматики или компиляторы.


Итак, настоящий вопрос:

Какую услугу вы выставляете (здесь, имея публичное поле) ?.

Если служба (получить / установить заданное значение типа) имеет смысл для вашего API, тогда «ярлык» является допустимым.
Пока вы в конечном итоге инкапсулируете это поле, это нормально, потому что вы сделали ярлык по «правильной» причине (API и сервисное обслуживание), а не по «неправильной» причине (быстрый специальный доступ).
Хороший модульный тест (с точки зрения пользователя вашего API) может помочь вам проверить, следует ли обращаться к этому полю напрямую или он полезен только для внутренней разработки других классов в вашей программе.

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