Полина Титова

Вместо Number.parseInt(count, 10) писали бы Number.parseInt(args.count, 10)
Ну и удобство как бы само собой вытекающее из этого.
При этом, будь у нас это импорт какой-нибудь, то мы бы вытаскивали только нужное, типа того: { count, etc } from args, а не тянули весь огромный объект

# import xml.etree.ElementTree as XmlElementTree
# import httplib2
# import uuid
# # импорт нативных библиотек 
# from config import ** *
# # импорт конфига
# 
# ** *_HOST = '***'
# ** *_PATH = '/***_xml'
# CHUNK_SIZE = 1024 ** 2
# 
# 
# # ?
# 
# def speech_to_text(filename=None, bytes=None, request_id=uuid.uuid4().hex, topic='notes', lang='ru-RU',
#                    key=** * _API_KEY):
#     if filename:
#         with open(filename, 'br') as file:
#             bytes = file.read()
#     if not bytes:
#         raise Exception('Neither file name nor bytes provided.')
# 
#     bytes = convert_to_pcm16b16000r(in_bytes=bytes)
# 
#     url = ** *_PATH + '?uuid=%s&key=%s&topic=%s&lang=%s' % (
#         request_id,
#         key,
#         topic,
#         lang
#     )
#     # метод обработки файла
# 
#     chunks = read_chunks(CHUNK_SIZE, bytes)
# 
#     connection = httplib2.HTTPConnectionWithTimeout(***_HOST)
#     # подключение к страницы для передачи заголовка
#     connection.connect()
#     connection.putrequest('POST', url)
#     connection.putheader('Transfer-Encoding', 'chunked')
#     connection.putheader('Content-Type', 'audio/x-pcm;bit=16;rate=16000')
#     connection.endheaders()
# 
#     for chunk in chunks:
#         connection.send(('%s\r\n' % hex(len(chunk))[2:]).encode())
#         connection.send(chunk)
#         connection.send('\r\n'.encode())
# 
#     connection.send('0\r\n\r\n'.encode())
#     response = connection.getresponse()
#     # отправка и получение ответа
# 
#     if response.code == 200:
#         response_text = response.read()
#         xml = XmlElementTree.fromstring(response_text)
#         # ?
#         if int(xml.attrib['success']) == 1:
#             max_confidence = - float("inf")
#             text = ''
# 
#             for child in xml:
#                 if float(child.attrib['confidence']) > max_confidence:
#                     text = child.text
#                     max_confidence = float(child.attrib['confidence'])
# 
#             if max_confidence != - float("inf"):
#                 return text
#             else:
# 
#                 raise SpeechException('No text found.\n\nResponse:\n%s' % (response_text))
#         else:
#             raise SpeechException('No text found.\n\nResponse:\n%s' % (response_text))
#     else:
#         raise SpeechException('Unknown error.\nCode: %s\n\n%s' % (response.code, response.read()))
# 
# 
# сlass
# SpeechException(Exception):
#     pass

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

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

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

Теперь задумаемся о декомпозиции всего этого хаоса. Мы находим какую-то задачу, которую выполняет наш код (например какую функцию вызвать для обработки каждого конкретного запроса) и выносим это в отдельный объект. Отправка email-ов - отдельный объект. Весь SQL зашиваем в отдельный объект. Соединение с базой - объект. Пользователи - объекты. Все - объекты.

И главное, у каждого объекта есть своя область ответственности. UNIX way. Каждый объект делает что-то одно и делает это хорошо. Бывает так что ну... нужно сделать так что бы один объект делал две вещи. НЕ вопрос, мы можем его попросить сделать что-то сложное, а он будет как хороший менеджер тупо делегировать работу другим объектом. То есть он и сложную штуку сделает, и сам не будет знать как она делается.

А все безхозные функции, которые не пренадлежат никаким объектам (например функции порождающие объекты) можно вынести в статические методы. Главное что бы статичесих переменных у нас небыло (ибо это те же глобальные переменные). И поменьше публичного ибо черт его знает что эти разработчики будут использовать. Причем "те разработчики" это вы завтра.

Вообщем писав всё время на процедурке, сложно перейти на ооп.

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

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

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

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

Есть хорошие упражнения на развитие понимания объектно-ориентированного проектирования. Например вот: https://habrahabr.ru/post/206802/

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

Или может подскажите книгу/сайт где пошагово в ооп написан какой-то проект, чтобы быстрее пришло понимание.

Так вы научитесь делать один конкретный проект а на втором вы уже проиграете. Так дела не делаются. Надо разобраться с причинами появления идеи ООП. Ну то есть что было до. Можно еще с функциональным программированием попробовать разобраться. В PHP оно слабо применимо, но основные идеи очень тесно переплетаются с ООП и познав немного функциональщины ваше ООП будет лучше. Да и если про ООП вы можете найти много булшита, про функциональщину врут мало.