Как я объясняю слабую связь и сокрытие информации новому программисту? [закрытый]

Точно так же, как перемещение от 16 битов до приложений Windows на 32 бита, где процессам дали их собственное адресное пространство. Это остановило любой другой процесс от способности уничтожить Ваше приложение, когда это "случайно" шло по Вашим данным.

Движущиеся процессы к различным адресным пространствам был похож на обработку каждого процесса как класс, и сокрытие память внутренне и разъединение процессы, вынудив межпроцессное взаимодействие только произойти через ожидаемый интерфейс (например, сообщения Windows).

Программы являются системами взаимодействующих частей.

Для системы взаимодействующих частей для сотрудничества требует соединений между этими частями.

Чем больше соединений, тем более дорогостоящий программа.

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

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

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

Слабая связь и сокрытие информации являются основными принципами минимизации воздействия соединения.

Это не дополнительное знание для программиста.

Это фундаментально.

Вы не можете быть экономным программистом без этого ведома.

При выяснении, как объяснить, слабая связь и сокрытие информации новому программисту похожи на выяснение, как объяснить хирургию новому хирургу? Или объяснить архитектуру новому архитектору? Или как объяснить полет пилоту.

Если Ваш, 'Новые программисты', не знают слабую связь и сокрытие информации, то они не, 'Новые программисты'; они - потенциальные программисты.

Любопытно, это, вероятно, не поможет сказать им читать исходные две газеты: i) Слабая связь: 'Структурное проектирование', W.P. Stevens, G.J. Myers и L.L. Constantine. ii) Сокрытие информации: http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf

пропавший без вести: сокрытие информации , Steve McConnell

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

Хорошо, если необходимо объяснить это им тогда, я вынужден спросить: они - действительно программист?

Говорят им, что им нужен "колледж, переделывают"?

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

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

сверхнаследование не может быть их отказом. Они, возможно, учились в курсе, разработанном в 90-х, это захватывается в идее, что "все должно наследоваться". Я помню, что старые примеры менеджера расширяют Сотрудника. Это просто ПЛОХО. Вещью являются люди, преподаются эту ерунду. Все еще.

Для C++ Scott Meyer Эффективный ряд C++, вероятно, стоит poniting их к (предположение, что они могут быть побеспокоены для чтения чего-то). Для Java Эффективный Java Josh Bloch ("состав пользы") в том же направлении. Не уверенный в C#.

Эти виды книг дают лучший подход к наследованию по сравнению с составом и также дают некоторые хорошие примеры того, почему наследование (как Josh Bloch выражается), "деталь реализации". Я также услышал, что это описало как "инкапсуляцию повреждений наследования".

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

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

, Учитывая Вашу ситуацию, вот то, что я предложил бы:
1. Заставьте их следовать за Вашим дизайном точно (по крайней мере, в течение нескольких недель). Если они хотят отклониться, сделайте, чтобы они обсудили какой и почему с Вами. [Ограничения времени не могут разрешить это].
2. Сидите с ними на том, какой бы ни часть дизайна Вы делаете затем и объясняете некоторый o0f Ваши проектные решения им с примерами. Somethings, которые очевидны для Вас, возможно, должен быть указан им.
3. Будьте в поисках примеров, обоих из хорошего дизайна и плохого дизайна и покажите им, как это работает лучше.

самая важная задача здесь имеет делегацию. Необходимо показать им, на что похож хороший код, возможно, обучите их в течение нескольких часов. Тогда Вы договариваетесь, когда рассмотреть и как можно помочь им (в течение ограниченного свободного времени (?)), делают задачу хорошо. Главное состоит в том, чтобы заставить их отождествлять с и понимать хороший дизайн. Выполнение этих вещей поможет им 'закрытие сделки' к дизайну. Как только они чувствуют, что это - их дизайн, я уверен, что они сделают лучшую работу.

В целом, я думаю, что необходимо занять твердую позицию и заставить их кодировать его право, не душа их креативность.

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

Примечание
я хотел бы добавить, что понятия OO могут быть усвоены из книг, в то время как их приложение может быть изучено только практикой. Я добавил это примечание в ответ на комментарий Christopher W. Allen-Poole.

Если он неправильно истолкует Ваши проекты, то возможно, пары парных сеансов программирования будет достаточно для получения их на ходу. Я действительно должен согласиться с @ThomasD и подробно остановлюсь на нем - инкапсуляция, продолжающаяся здесь могли быть Вы. Это мог быть простой случай неверного истолкования вместо них не понимание понятий.

Мне нравится кредитная карта за пример.

у Вас есть кредитная карта. Кредитная карта представляет Вашу кредитную историю. Это имеет баланс и APR. Это имеет полномочия и все финансовое положение. Это имеет идентификатор, дату истечения срока и код в системе защиты. Магнитная полоса суммирует все это.

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

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

Просто не говорите с ним. Это должно учить его сокрытию информации.;-)

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

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

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

Покажите ему это представление . Хотя это главным образом о DI, это является совершенно блестящим и до точки.

• Слабая связь: части часов могут быть заменены другими с повреждением целых часов. Например, можно убрать одну руку, и она будет все еще работать.

• Сокрытие информации: стрелки часов не знают, что позади них существует оборудование.

Дополнительная Высокая связность понятия

• : Все элементы в часах "модуль" сильно связаны. В этом определенном сценарии батарея принадлежала бы другому модулю или пространству имен.

Нет ничего как физическая аналогия. Забастовка к Вашему автомобилю и указывает, как все сложное, горячее и опасное вполне прилично изолируется от хрупкого человека. Сидите у руля и укажите на некоторые важные индикаторы; например, температура хладагента, тахометр и спидометр. Отметьте, как индикаторы удивительно подобны: они все принимают скалярное значение (от где-нибудь) и представляют его путем перемещения иглы в положение между минутой и максимум

Однако, если Вы думаете о том, что измеряется, сильная мотивация для поддержания той изоляции (иначе слабая связь или сокрытие информации) становится намного более очевидной.

• , "Как хотели бы Вы измерять температуру хладагента? Путем рассмотрения индикатора или путем засовывания пальца в почти кипение жидкости?"

• , "Как хотели бы Вы измерять скорость вращения механизма? Путем рассмотрения индикатора или позволяя коленчатому валу на мультитысячу об/мин разорвать плоть от костей, поскольку Вы пытаетесь оценить его вручную?"

• , "Как хотели бы Вы измерять скорость автомобиля? Путем рассмотрения индикатора или путем перетаскивания ноги на земле, поскольку Вы ревете вниз магистраль?"

Оттуда, можно основываться на понятии "индикатора температуры хладагента , - индикатор. Это не - кипящая жидкость" и т.д к более сложным понятиям.

Теория только получит Вас до сих пор.

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

Он, конечно, поймет avantages написания хорошего кода.

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

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

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

в стороне - я замечаю, что люди ищут эти ярлыки все время с абстрактными навыками, но не с большим количеством "физических" навыков. Возьмите теннис, например. Если бы Вы были теннисным тренером, и новый плеер продолжал поражать свои удары справа долго, то Вы только показали бы ему видео YouTube удара справа Roger Federer и ожидали бы, что он "получит его". Большой удар справа занимает Годы опыта, поскольку Вы изучаете чувство и используете его в различных сценариях - не Ваше приобретение знаний мышц, его Ваш мозг. Это не отличается с разработкой программного обеспечения. Вы становитесь хорошими в нем путем выполнения его много раз. Вы медленно учитесь на своих ошибках и поправляетесь при понимании последствий каждого отдельного проектного решения.

Спросите его, если это - хорошая идея позволить Вам одолжить 10$ путем предоставления его кошелька Вам на мгновение и взятия денег самим.