Комментарии 39
Я предпочитаю руководствоваться этими принципами пиши-код-блять.рф
По себе знаю — без тестирования не обойтись
Правда я сначала пишу код как мне удобно, потом пишу тесты, потом подгоняю под тесты (хотя считается, что нужно наоборот, но у меня подход такой: сначала — идея, потом реализация, потом тестирование, в запутанных случаях отладка).
Кстати, есть ли какой-нибудь gpl инструмент для проверки coverage для с++?
Правда я сначала пишу код как мне удобно, потом пишу тесты, потом подгоняю под тесты (хотя считается, что нужно наоборот, но у меня подход такой: сначала — идея, потом реализация, потом тестирование, в запутанных случаях отладка).
Кстати, есть ли какой-нибудь gpl инструмент для проверки coverage для с++?
gcov?
Bulls Eye кажется
Эти принципы совсем-совсем не про то.
Сильно, но чтоб понять что тут написано нужен серьезный опыт. Примеры выстрелов в ногу привели бы что-ли?
Статья-тезисов, Patterns Head First в кратком изложении
Источник Эрик Фримен?
Давно стемлюсь к сильной связности, но слабой связанности.
По этой причине адекватному переводчику желательно использовать англоязычные термины хотябы в скобках, для начинающего разработчика и так в порядке вещей путаться в coupling и coherence, чтобы дополнительно путать его переводам.
Мневмоправило (хотя и не идеально отражающее соотношение сущностей):
coupling — от couple, парочки, парочки зависят друг от друга.
coherense — согласованность, парочка согласна делать ремонт вместе.
Мневмоправило (хотя и не идеально отражающее соотношение сущностей):
coupling — от couple, парочки, парочки зависят друг от друга.
coherense — согласованность, парочка согласна делать ремонт вместе.
Принципы в статье хорошо перекликаются с SOLID.
>… у всех задача одна и та же – уменьшение сложности системы и, как следствие, жизни программистов.
А вот это — пугает :)
>… у всех задача одна и та же – уменьшение сложности системы и, как следствие, жизни программистов.
А вот это — пугает :)
Лучше уж подробней изложить про основной императив снижения сложности, выделенный МакКоннелом в его формулировках, чем запоздалые на 10-15 перепевки Code complete авторами из разряда «лишь бы засветиться» со всякими введенными принципами имени себя, лишь что-то необычное сказать, которые стройного видения области в голове не формируют.
Что касается тезисов, то не читав оригинала и не понимая о чем идет речь можно придраться к каждому второму слову, просто для примера:
>Это основа всего ООП. Надо выделить компоненты, которые могут измениться, и отделить их от части системы, которая останется неизменной.
Что представляют из себя «неизменные» части и как их определить до окончания разработки?
>Естественно, везде фанатично применять композицию и совсем отказаться от наследования было бы неразумно.
Ну и когда же ее в итоге применять? Есть же два элементарных вопроса, которые надо надо задавать при создании модели взаимодействия классов «Являются ли B, C, D разновидностью A?» или «Состоит ли A из B, C, D?», ответ на который достаточно однозначно говорит об уместности того или иного подхода.
«Используйте как можно чаще, но не злоупотребляйте» — это рекомендация ни о чем.
И т.д.
Что касается тезисов, то не читав оригинала и не понимая о чем идет речь можно придраться к каждому второму слову, просто для примера:
>Это основа всего ООП. Надо выделить компоненты, которые могут измениться, и отделить их от части системы, которая останется неизменной.
Что представляют из себя «неизменные» части и как их определить до окончания разработки?
>Естественно, везде фанатично применять композицию и совсем отказаться от наследования было бы неразумно.
Ну и когда же ее в итоге применять? Есть же два элементарных вопроса, которые надо надо задавать при создании модели взаимодействия классов «Являются ли B, C, D разновидностью A?» или «Состоит ли A из B, C, D?», ответ на который достаточно однозначно говорит об уместности того или иного подхода.
«Используйте как можно чаще, но не злоупотребляйте» — это рекомендация ни о чем.
И т.д.
Хм. похоже, половину принципов я уяснил для себя интуитивно.
А эт распространная ситуация — человек интуитивно использует какой-нибудь принцип или паттерн, при этом не знает как это все формально называется. ИМХО, эт естественно и даже хорошо — лучше органично сделать, при этом заюзать все паттерны\принципы, что надо, чем зная кучу названий, не уметь их применять.
Ну а в идеале — знать и применять, конечно же :)
Ну а в идеале — знать и применять, конечно же :)
В общем используйте Spring )
Это всё перевод или персональный опыт автора? Если перевод, то кто источник и где?
НЛО прилетело и опубликовало эту надпись здесь
а мне очень напомнило Code Complete)
Уважаемый автор, чья-то жизнь станет легче не после вашей статьи (заметки), а после прочтения книги, из которой вы все эти принципы позаимствовали.
В дополнение к книге, которую вы посоветовали, принципы проектирования классов и сборок подробно описаны в книге www.amazon.com/Agile-Principles-Patterns-Practices-C/dp/0131857258
Для тех, кто хочет эту книгу купить, я бы рекомендовал посмотреть на Амазоне. Даже с учетом недешевой доставки, это все равно будет раза в полтора дешевле, чем по ссылке выше. Ну и есть русская версия, однако что там с качеством перевода я не знаю.
Не хватает:
9. Принцип замещения Лисков.
9. Принцип замещения Лисков.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Восемь принципов программирования, которые могут облегчить вам жизнь