Ребята. кому интересно.
Что сделать.
Взять код Игоря и улучшить.
Предостерегаю. Ни в коем случае не подходить к коду, каким то образом осуждая Игоря или кого-либо другого.
Позиция должна быть одна. Я хочу его улучшить не ломая идею автора, но расширив код. Важно не повторять полностью код автора, а дописать нечто своё, что принесёт пользу проекту в целом.
Да пока проект маленький, но ведь все равно идея есть.
Игорь Гресько молодчина, что прислал код и он так думает на данный момент.
А нам нужно учится использовать опыт других людей и наращивать.
Принцип, я думаю вот так то и так то и улчшил код, таким образом и обязательная очень подробная аргументация.
Итак, что делать.
Взять код и развить, пусть даже один фрагмент.
Что важно сейчас, научится работать по Линусу Торвальдсу.
1.Скопировать код Игоря.
2. Прокомментировать от себя.
3. Посмотреть задачу , то есть картинку
Понять для себя видите ли вы полную идею, что выразил Игорь?
Видите ли вы пласты идеи, то есть что происходит в конкретном куске кода?
Поставить к каждому фрагменту вопрос:
- Какую роль играет фрагмент кода в общей задаче?
- Как его можно реализовать точнее?
Описать и реализовать.
Игорь так ж думает над своим кодом и старается его улучшить.
Итак подводит задачи, кроме выполняемой, на что обращать внимание.
Сформировать в голове правила, использование абстрактных классов и интерфейсов.
К сожалению, здесь не получится один раз понять и все...
Нет нужно написать много кода и посмотреть на это с разных сторон.
В этом деле нам помогут патерны, так как их пишут опытные люди, как первичный шаблон.
Опираться на простое правило. Если мы садим помидоры то в теплицу, но ни как ни в кузов москвича.
Ну и так же работает над улучшением кода. То есть мысленный процесс и умение видеть весь код, умение видеть пласты кода и его задачи, это и есть чему учил в интервью Линус Торвальд.
По сути нужно понимать весь код и его задачу и цели, а потом поставить каждому фрагменту кода (классу, методу), вопрос и понять полностью ли отвечает этот код поставленному вопросу, если видим, что сделат ьможно что то ещё, делаем.
Важно.
Задача оказалась намного сложнее, чем я ожидал.
Нам нужно сформировать одно поле понятий, что бы каждый участник школы под тем или иным понятием
подразумевал одно и то же.
На информацию в интернет опираться не представляется возможным, так как процентов 90 это обычная чушь.
Будем опираться на старых программистов и готовые написанные библиотеки, разработчиками со опытом больше 25 лет, а как первое понимание потерны.
Всегда нужно искать недочёты только в базе.
Поэтому я подхожу к формированию базы очень серьёзно, что и я вам предлагаю делать.
Например, когда мы хотим попить у нас в голове есть интерфейс.
Который продиктован потребностью Жажда.
То есть у нас есть соглашение в голове, мы точно знаем, что мы будем делать. когда захотим попить.
То есть это и есть интефейс, между нами и реальным миром, а точнее между той обстановкой, которая нас окружает в виде классов.
Он подразумевает попить и не более того.
То есть попить - это интерфейс.
Оно не знает что мы будем пить - это будет зависеть от ситуации.
Когда жарко холодного кваса.
Когда вечер - чаю
Когда обед компот.
Поэтому к интерфейсу пить у нас есть соглашения в голове, которые включают.
Что нам нужно.
Интерфейс попить:
тара или что то ещё
жидкость
какое то действие (например глотать)
и что ещё придумаете
полезность
По сути дела сам интерфейс, ничего конкретного не реализует, но мы точно знаем, что будем делать, когда захотим пить:
Если попить кваса в жару, а возможно его нет, значит нужно купить, это новые и новые методы. которые будут реализованы дальше.
То есть в интерфейсе, мы не можем указать точно напиток, так как тогда интерфейс перестаёт быть интерфейсом, а становится обычным конкретным классов, что в данной ситуации гибель программы, так как вы не смогли бы попить чего либо другого.
И так далее по пунктам учесть все соглашения.
Иными словами интерфейс в себя включает набор правил, которые точно не будут нарушены, но в то же время интерфейс ничего не знает о чём то конкретном.
То есть интерфейс не может контролировать что либо конкретное.
Но тем не менее интерфейс имеет очень точную цель.
Свод общих правил для удаления жажды.
Обратите внимание именно общих правил.
Так как например нам нужно напоить корову, ведь жажда и ей присуща, действия будут сходны.
По сути дела благодаря интерфейсу, мы точно знаем что будем делать, где бы мы не находились.
Если захотим пить.
Можно сказать и по другому интерфейс - это самый общий уровень абстракции.
Но при этом очень чётко следящий за выполнением набора правил в отношении главной цели.
Между чем то и чем то.
В данном случае между нашим чувством жажды.
реальностью и нами.
Я это опустил, но здесь не хватает
Factory то есть явного понятия. что это фабрика. (исправить обязательно) здесь понятия важны очень важны.
# создаем конкретный город
class City(IAmACity):
# банк, церковь, гостиница...
def create_building(self):
return TypesOfBuilding()
# улицы
def create_street(self):
return TypesOfStreet()
# люди
def create_people(self):
return TypesOfPeople()
Далее Игорь перешёл к конкретике и выразил объекты, при этом у него на всё абстракции.
Это задумка автора и она верная.
Но я бы попросил Игоря. как вариант уменьшить код.
То есть абстрактный дом, абстрактная улица и другие объекты.
Я вас прошу, как вариант задать больше вопросов и уменьшить количество кода.
Игорь. Молодчина. Но все же прошу вас переработать код, поставить более конкретные задачи каждому фрагменту, расширить вопросы, не только город (деревня, хутор и так далее).
Постараться сделать так, что бы кода было меньше, а возможностей больше.
Заметьте. Я ни сказал. что это плохо или хорошо. Это ваша задумка. И вы так думаете на данный момент.
Что я от вас добиваюсь? Заметьте, моя цель. что бы вы не переставали изматывать вопросами свой код.
Я разделил его на пласты и решил описать деревню.
Я понял, что этот код мне нужно полностью править.
Задайте вопросы своему коду более широко и выдержит ли он проверку?
Игорь, заметьте задача стояла описать город, да это сделано.
Но вам необходимо самому поставить вопросы к коду, что бы программист открыл и сказал, О класс, я могу описать деревню и что угодно.
Теперь работайте в сторону абстракции больше. Что бы промежуточные вещи, которые создают связь между классами. были независимы ни от чего.
Что делать я не знаю, я знаю. что хотелось бы видеть.
А видеть хочется. что бы можно было описать любое селение.
Попробуйте поработать начиная с этого места, подумайте может здесь создать интерфейс, а не абстрактный класс.
Которым потом будет делится. Просто я хочу. что бы вы убрали зависимость в этом коде в этом месте, а что прикажете делать, если я захочу описать хлев или баню.
Пока вижу каша. Что делать. Больше вопросов задавать своему коду. Если взяли прослойку город, то попутно ставьте вопросы в категории (город, деревня, хутор).
Как сделать, что бы это соответствовало общему замыслу поселение.
И теперь подумайте абстактный метод bank и другие методы, ограничили использование вашей фабрики.
Да, конечно можно приравнять банк например к магазину и переопределить метод далее.
Но это уже будет плохой код, очень плохой.
Можно написать для других объектов другие абстрактные методы.
Но сейчас вы делаете то же самое, что когда то делали программисты 70-х, они описывали шахматную партию классами.
Так сколько вам нужно будет классов написать, если например нужно описать все города России.
Ответ много.
Значит нужно работать в этом месте и написать так класс, что бы можно было реализовать любой город и любое здание.
Вот задача?
А так вы молодчина, но как видите на лаврах вам не даю почевать.
Так как ваш код, для вас самого по моим вопросам проверку точно не пройдёт.
Работайте. Разбирайтесь и делайте код, что бы не было зависимости и костомности ( то есть реализации только чего либо)
# абстрактный дом
class IAmABuilding(ABC):
@abstractmethod
def bank(self):
pass
@abstractmethod
def church(self):
pass
@abstractmethod
def hotel(self):
pass
Что будет если не будет интерфейса или он будет спонтанным.
Когда испытываем жажду мы будем кусать кирпич или будем прыгать, так точно вы не напьёмся и не утолим жажду, поэтому правила очень конкретны.
После интерфейса, всегда идёт абстракция.
Я не зря написал как улучшить код Игоря.
Ребята улучшить, что бы разобраться. а не осудить.
Важно.
Игорь изменил этот пункт, а сразу перешёл к конкретике, что придало его коду костомность и узконаправленность и сразу понятно при этой идее нужно дописывать и дописывать классы, для реализации новых объектов.
2020-02-12 16:53:34+00:00