Продолжаю конспектировать "Совершенный код".
Раздел "Вопросы проектирования и реализации".
Класс может содержать данные или другой класс. Это отношение "Включение".

1. Реализуйте с помощью включения отношения "Содержит".
2. В самом крайнем случае такое отношение может быть реализовано с помощью закрытого наследования -  автор считает, что если получается только так, то это ошибка проектирования и что лучше всего еще раз подумать. Наверное, он прав. Я с таким на практике еще не сталкивалась.
3. Настороженно относитесь к классам, содержащим более 7+\-2 данных-членов. Автор считает, что можно класс, содержащий много данных разбить на несколько классов, содержащих небольшое количество данных, и что это поможет упростить работу с данными. Опять же, нужно проверить на математике "Mittens".

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

1. Реализуйте при помощи открытого наследования отношения "является". Если производный класс не будет полностью придерживаться контракта, наследоваться не надо.
2. Проектируйте и документируйте классы с учетом возможности наследования или запретите его.
3. Соблюдайте LSP: клиенты должны иметь возможность использования подклассов через интерфейс базового класса, не замечая никаких различий. Если программист, сделав наследование, забывает о деталях реализации наследников - все ОК. Если он должен думать о семантических различиях реализаций подклассов - наследование зло, тк. не способствует снижению сложности. 

Продолжение следует...

Инкапсуляция. Как сделать.

Я перечитала книгу "Эта странная жизнь" про ученого Любищева по ссылке Яны Франк. Ее поразило в нем то, что он записывал все, что делал за весь день в часах и минутах. А меня удивило, что для каждой книги(большой и умной) он писал конспект и критику. Я попробую тоже конспектировать книги по программированию, что я сейчас читаю. Не знаю, насколько меня хватит и насколько это будет полезно.

Итак, сейчас я читаю "Совершенный код" Макконнелла.

За сегодня я читала главы по инкапсуляции из раздела "Качественные интерфейсы классов".

"Без инкапсуляции абстракция обычно разрушается" - эта цитата определяет главный принцип сокрытия данных. Инкапсуляция - один из принципов управления сложностью проекта. 

Автор предлагает несколько принципов, позволяющих добиться сокрытия методов и данных классов.

1.  Минимизировать доступность классов и их членов.
2.  Не предоставлять прямой доступ к данным-членам, а только к методам доступа к данным - с этим пунктом связано у меня больше всего ляпов в моих бывших и настоящих программах. В классах, занимающихся расчетами, обычно очень много данных, которые являются результатом работы. Например, в программе "Mittens". Делать к ним методы доступа я поленилась. А по данному принципу это было необходимо. Хотя, я до сих пор не хорошо понимаю, как можно программы расчетов чего-либо сделать полностью ОО. Мне кажется, не зря до сих пор большинство расчетов остались на фортране. 
3.  Не включать в интерфейс класса детали реализации. В книге есть интересный пример для С++, как скрыть реализацию в заголовочном файле.class A{public:    Aresult Funk() const; ...private:    AEmplementation *a_emplementation;}В классе  AEmplementation находится тот код, который не должен быть доступен классу, использующему класс А.
4. Не делайте предположений о том, как класс будут использовать его клиенты. Все, что нужно, должно быть видно из интерфейса. Если какие-то значения нельзя указывать, то проверку значений не нужно отдавать классам клиентам.
5.  Избегайте использования дружественных классов. Я уже не помню точно, как их делают, т.к. ими не пользовалась. Автор указывает шаблон State(Состояние), как дисциплинированное использование таких классов. Шаблон не знаю. Нужно будет посмотреть потом.
6. Не делать метод открытым только потому, что он использует открытые методы, посмотреть, укладывается ли он в абстракцию этого класса.
7. Ценить легкость чтения кода выше, чем легкость его написания. Золотые слова! Можно их писать на мониторе, когда лениво печатать. 
8. Очень осторожно относится к семантическим (смысловым) нарушениям инкапсуляции. 
9. Остерегаться слишком жесткого сопряжения. 

Итак, итог.

• Минимизировать доступность классов и их членов.
• Избегать дружественных классов
• Делать данные базового класса закрытыми, а не защищенными, чтобы наследники были меньше сопряжены с базовым.
• не включать данные-члены в открытый интерфейс класса.
• остерегаться семантических нарушений инкапсуляции.
• соблюдать "правило деметры" - А знает о Б, но не знает о том, какие методы Б вызывает.

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

Программа для расчета варежек.

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

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

Описание программы и инструкция здесь.

Из опыта разработки.
Списки у меня заработали. Разметку я научилась делать. Второй экран в этой проге был не нужен и я с ним не разбиралась. Как и с Intent.

Сейчас читаю Android 4 и Совершенный код. Бегаю между этими двумя книжками, читаю по чуть-чуть и не могу понять, что мне сейчас важнее и интереснее. Макконел легко читается. И у него есть дельные советы. Посмотрим, сколько полезного я извлеку из этой книги.

Первое приложение готово

У нас несколько дней не было интернета и я не могла смотреть обучающие лекции. Но я застряла на переходах между окнами. Программа выдает ошибку и непонятно почему. Как ее решить самостоятельно я не додумалась. Поэтому стала делать таймер 45/15 из одного окна.

Один таймер я мучила 2.5 дня - это около 8 рабочих часов (когда дети спят и вечером).
Чуточку разобралась с хронометром(Chronometer).

Поняла, что переименовывать проект проще всего с помощью Refactor-> Rename.

И опять на меня находит паника "У меня не получается".


Скачать таймер можно здесь .
Выглядит так.

Назвала в честь Яны Франк. Я сейчас ее фанатка.

Таймер тихий. На заставке показывает время и отсчитывает рабочие минуты и секунды.
Можно запаузить.
Все просто.
Я учусь.

И кусочек кода:

// Хронометр. Отсчитывает время. Связваю его с виджетом
final Chronometer cr = (Chronometer)findViewById(R.id.chronometer1);
// Запускаю при создании программы
cr.start();
// Привязываю обработчик события тика таймера.
// Это новый класс реализующий интерфейс OnChronometerTickListener
cr.setOnChronometerTickListener(new OnChronometerTickListener(){


. . .



Продолжение следует.

Записки ПД, часть 7.

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

Оказалось, что для эмулятора отладчик работает. Просто я не знала, как его включить! Я так обрадовалась, что могу посмотреть, что там внутри программы творится. Можно просто ставить точки прерывания. А можно писать в системный лог сообщения - Log.i и еще куча разных фильтров для сообщений. И все встроенное! Это одна из самых больших радостей за этот день!

Еще я стала переименовывать стандартные названия элементов интерфейса. Я так и не поняла, если eclipse создает два элемента TextView1, к какому он будет обращаться по id, когда мне понадобится привязать к нему объект.

Думаю купить книжку по программированию на андроиде, но оказалось, что их много. И отзывы те, что читала, они все какие-то не вдохноляющие. Придется идти в магазин и смотреть книжку на месте.