На прошлой неделе, когда я начал изучать Android, мне действительно трудно писать код. Было много всего, столько шаблонов проектирования, лучших практик кодирования, фабричных методов, поэтому я действительно боролся со своими методами кодирования. Затем я нахожу эту книгу Head First Object-Oriented Analysis and Design, после прочтения первой главы я нахожу ее действительно полезной.

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

Шаг 1.Сначала сделайте так, чтобы клиент был доволен, т. е. это можно сделать, только заставив ваше программное обеспечение работать должным образом.

Шаг 2. Затем сделайте свой код гибким, т. е. удалите повторяющийся код.

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

Итак, позвольте мне дать немного больше вкуса этой абстракции;

Применение ШАГА 1:

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

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

Решение. Они использовали перечисляемые типы для хранения информации об элементах;

Перечисленные типы позволяют определить имя типа, например Wood, а затем набор значений, разрешенных для этого типа (например, COCOBOLO, SITKA и MAHOGANY). Затем вы ссылаетесь на конкретное значение, например Это: Wood.COCOBOLO.

Что помогает им полностью удалить операцию сравнения строк.

Применение ШАГА 2:

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

Применение ШАГА 3:

Проблема:

«Клиент предъявляет вам новые требования по добавлению программного обеспечения, но, если подумать, вам нужно обновить несколько мест. Каким-то образом вам удается находить правильные места, но вы сами сказали, что в будущем, когда появятся новые требования, вы сможете сделать это снова?»

Решение.Делегирование приходит на помощь:

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

Таким образом, после выполнения этих шагов ваше приложение готово, может использоваться повторно и может быть легко изменено при изменении требований.

Комментарии очень ценятся, и если вам понравилась эта статья, пожалуйста, поделитесь ею.