Pull to refresh

Comments 39

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

Кстати, есть ли какой-нибудь gpl инструмент для проверки coverage для с++?
Эти принципы совсем-совсем не про то.
Сильно, но чтоб понять что тут написано нужен серьезный опыт. Примеры выстрелов в ногу привели бы что-ли?
Статья-тезисов, Patterns Head First в кратком изложении
А также Берт Бейтс и Кэти Сьерра.
Давно стемлюсь к сильной связности, но слабой связанности.
По этой причине адекватному переводчику желательно использовать англоязычные термины хотябы в скобках, для начинающего разработчика и так в порядке вещей путаться в coupling и coherence, чтобы дополнительно путать его переводам.
Мневмоправило (хотя и не идеально отражающее соотношение сущностей):
coupling — от couple, парочки, парочки зависят друг от друга.
coherense — согласованность, парочка согласна делать ремонт вместе.
Принципы в статье хорошо перекликаются с SOLID.

>… у всех задача одна и та же – уменьшение сложности системы и, как следствие, жизни программистов.

А вот это — пугает :)
Лучше уж подробней изложить про основной императив снижения сложности, выделенный МакКоннелом в его формулировках, чем запоздалые на 10-15 перепевки Code complete авторами из разряда «лишь бы засветиться» со всякими введенными принципами имени себя, лишь что-то необычное сказать, которые стройного видения области в голове не формируют.

Что касается тезисов, то не читав оригинала и не понимая о чем идет речь можно придраться к каждому второму слову, просто для примера:

>Это основа всего ООП. Надо выделить компоненты, которые могут измениться, и отделить их от части системы, которая останется неизменной.

Что представляют из себя «неизменные» части и как их определить до окончания разработки?

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

Ну и когда же ее в итоге применять? Есть же два элементарных вопроса, которые надо надо задавать при создании модели взаимодействия классов «Являются ли B, C, D разновидностью A?» или «Состоит ли A из B, C, D?», ответ на который достаточно однозначно говорит об уместности того или иного подхода.
«Используйте как можно чаще, но не злоупотребляйте» — это рекомендация ни о чем.

И т.д.
Хм. похоже, половину принципов я уяснил для себя интуитивно.
А эт распространная ситуация — человек интуитивно использует какой-нибудь принцип или паттерн, при этом не знает как это все формально называется. ИМХО, эт естественно и даже хорошо — лучше органично сделать, при этом заюзать все паттерны\принципы, что надо, чем зная кучу названий, не уметь их применять.
Ну а в идеале — знать и применять, конечно же :)
По этому поводу вспоминается холивар на тему подгонки кода под unit-тесты…
я начал писать на C# в феврале, а смотря на свой код после прочтения статьи понял что использую вполне спокойно и считаю это логичным
Ну надо не подгонять. Надо писать в соответствие с требованиями к кусочку кода, которые выражены в виде юнит-тестов
Это всё перевод или персональный опыт автора? Если перевод, то кто источник и где?
Это не перевод, а выдержки из переведенной книги. Автор, кстати, на нее ссылается в 7 пункте.
По моему, эта книга лидер по цитированию на Хабре
тоже возникло ощущение некоторого дежавю…
UFO landed and left these words here
а мне очень напомнило Code Complete)
только вместо логики туман и путаница
Уважаемый автор, чья-то жизнь станет легче не после вашей статьи (заметки), а после прочтения книги, из которой вы все эти принципы позаимствовали.
Для тех, кто хочет эту книгу купить, я бы рекомендовал посмотреть на Амазоне. Даже с учетом недешевой доставки, это все равно будет раза в полтора дешевле, чем по ссылке выше. Ну и есть русская версия, однако что там с качеством перевода я не знаю.
К сожалению, с оригиналом я не знаком, но русская версия вызвала у меня исключительно положительные эмоции!
Не хватает:
9. Принцип замещения Лисков.
UFO landed and left these words here
а я вот вижу кучу ссылок на мсдн по использованию интерфейсов и делегатов.
код, красивый, работает.
но что это и нафига оно нужно — до сих пор понять не могу. и как его исполдьзовать тоже.
Взял книгу по шарпу — Троелсена, там тоже описано, но сути я так и не понял (
UFO landed and left these words here
Было бы интересно узнать. Спасибо.
просто я со следующей зарплаты хочу брать книгу по паттернам еще, в дополнение к Троелсену

UFO landed and left these words here
Похоже, Вы «изобрели» паттерн Наблюдатель.
UFO landed and left these words here
Only those users with full accounts are able to leave comments. Log in, please.