Как реализовать зависимость аргумента одного класса от другого класса?

Question

[Pitonoslav]

Выдуманный упрощенный пример. Допустим есть класс Car, в котором есть аргумент tanker_path(НЕбак, а расстояние) где считается сколько хватит бензина. И есть отдельный класс Road, в котором есть аргумент length - длина дороги. Car.tanker_path - будет зависеть от Road.length.

Как такую зависимость правильно реализовать? Так делают или это изначально неправильная схема?

Самый простой вариант вижу такой - выносить переменную length в глобальную область. Пока писал ещё один вариант придумал - в классе Car нужен отдельный аргумент, например Car._road где значением будет другой класс Road(композиция?), откуда уже и будет браться длина дороги

class Ship:
    def __init__(self, x=None, y=None):
        self.x, self.y = x, y  # нужна проверка, будет ошибка если не влезает в Space.size


class Space:
    def __init__(self, size):
        self.size = size
        

sp = Space(50)
sh = Ship(100, 100)  # должна быть ошибка т.к. не влезает в пространство

Comments

[mayton2019]

Не надо ничего глобального.

Напиши самый простой вариант кода который работает. Потом приаттачь его сюда.
Эксперты посмотрят и дадут советы. А то ты сейчас придумаешь новую космологическую теорию
вселенной. А у тебя просто машина с баком.

[Adamos]

mayton2019, с баком, который уже сложно запутан с дорогой и находится в состоянии квантовой суперпозиции с калькулятором бензина %)

[mayton2019]

Я всегда говорил что ООП - это набор практических советов. Но так туда заходят всякие теоретики. И как начинают разводить 7 воду на киселе. Я помню в университете мы спорили. Как дизайнить UI API. Кисть должна быть аргументом метода draw Canvas? Или наоборот? До сих пор спорим. Как про первичность яйца и куриц.

[Алан Гибизов]

Если нет кода - зачем ставить тэг языка?

[Алан Гибизов]

mayton2019, ИМХО кисть вообще не может быть методом. Методом может быть только действие. Но draw это действие не над кистью (мы же не меняем состояние кисти рисованием), а над холстом (canvas), мы меняем состояние холста (добавляем на него линию или фигуру или заливку и т.п.)
А кисть - это объект, но он же не может быть методом метода draw.

Больше холиваров богу холиваров!

[Алан Гибизов]

аргумент tanker_path(бак) где считается сколько хватит бензина.

вот это явно не там должно считаться. Бак не должен уметь рассчитать сколько хватит. Он же не калькулятор…
Он должен содержать литры бензина.
Двигатель должен преобразовывать бензин в «километры проехатого пути» с определенной для двигателя эффективностью. Условно литр бензина на двигателе Жигуленка это 10 км, а на двигателе ГАЗ-66 это 2.5 км.
В итоге машина вырабатывает «проеханный путь», и вы его получаете у машины и вычитаете из длины всего пути, получаете «оставшийся путь».

[Pitonoslav]

Алан Гибизов, да НЕбак это, я исправил, не бак. Вопрос был не про бак,а про зависимость одного класса от другого

[Pitonoslav]

Я всегда говорил что ООП - это набор практических советов. Но так туда заходят всякие теоретики. И как начинают разводить 7 воду на киселе.

Супер, жду ваших практических советов.

[mayton2019]

Vladislav, покажи исходник.

[mayton2019]

Алан Гибизов,
brush.draw(canvas);
?

canvas.draw(brush);
?

[Adamos]

mayton2019, for(el in canvas.elements) el.draw(canvas.context)

[mayton2019]

Adamos, ты предлагаешь чтобы каждый элемент канваса сам себя рисовал?

А откуда он знает как он выглядит?

[Pitonoslav]

mayton2019, добавил пример, нет какого-то "исходника", это учебная задача по теме ООП

[mayton2019]

Vladislav, а Питон. Ну ладно. Я думал какой-то строгий язык типа C#.

Я вот по поводу этой строки.

sh = Ship(100, 100)  # должна быть ошибка т.к. не влезает в пространство

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

Переусложнять это я не вижу смысла.

[Pitonoslav]

Но думаю мне и этих ответов уже хватит. Закидали, что не унести) В решениях Ипатьев ответил про отдельный класс Trip который свяжет машину и дорогу(из примера), в таком виде, по отдельности, Car и Road или Space и Ship получается никак не связаны.

[Алан Гибизов]

mayton2019, конечно, сам. Всякий экземпляр класса должен содержать в себе все необходимые средства для изменения любых своих атрибутов. И никак иначе. Я так понимаю, для того классы и придумали, чтобы привязать к экземплярам их атрибуты и методы по их изменению.
А кисть - это курсор, элемент UI, и он прямого отношения к рисованию не имеет. Он, точнее возвращаемые им координаты, по клику мышки или по перемещению курсора передаются в экземпляр класса элементов изображения его методам, например draw, который проделывает с этим элементом то, что надо.

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

[Pitonoslav]

mayton2019 Алан Гибизов Подскажите средство от перфекционизма?) Чтобы не усложнять. У меня на это много времени уходит. Бывает что простая задача превращается в научное исследование, поиск примеров, книг и т.д. хотя могу решить намного быстрее или иногда забить на какой-то момент

[Алан Гибизов]

Как я понимаю про машинку и путь:

Машинка и Путь

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

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

Я могу неправильно что-то понимать, пусть меня поправят старшие товарищи.

[mayton2019]

Vladislav, об этом еще Грибоедов писал. Горе от ума называется.

Забудь про ООП. Просто сделай чортову задачу. Сделай в 1 класс.
А потом когда проект станет большой - у тебя появится естественное разделение
его на части. И это разделение будет как раз правильным. Мотивированным.

Почитай про философии KISS, YAGNI.

Типизация что ты затеял - это штука полезная. Но в плане motivation - ты просто звучал
неубедительно. Нет мотивации делать отдельный контейнер для размеров.

[Adamos]

mayton2019, это не "я предлагаю", это практически цитата из классических "Паттернов программирования" GoF.

[mayton2019]

Adamos, да эта задача с канвасом и кистью - это как задача о взлетающем самолете с транспортера. Она не решаема. И GoF здесь непричем. Просто в ней не хватает исходных данных. Не описан контракт. Или отвественности.
А ответственности кисточки и канваса - каждый себе придумывает так как хочет. И уже после этого бери хоть ГоФ хоть Дядьку Боба хоть Иисуса Кириевского.

[Adamos]

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

[Ипатьев]

Vladislav, не надо путать понятия. Это не перфекционизм, а профессиональный рост.
Дополнил свой ответ.

Answer 1

[Ипатьев]

Соглашусь с предыдущими комментаторами, пример СЛИШКОМ высосан из пальца, чтобы по нему давать какие-то рекомендации.
Но в целом, бак должен быть отдельным объектом в составе машины, а никаким не "аругментом".
И у него может быть метод consumeFuel(miles)
Который может принимать длину дороги в качестве аргумента, и уменьшать количество топлива в соответствии с заложенной формулой.

Car.Tank.fillMax()
print Car.Tank.getLevel()
Car.Тank. consumeFuel(Road.length)
print Car.Tank.getLevel()

По поводу последнего варианта - всегда исходите из здравого смысла. Может ли быть дорога частью автомобиля? Нет, это очевидная бессмыслица. Дорога может быть частью поездки. Как и автомобиль. Вот в рамках объекта Trip они вполне могут взаимодействовать друг с другом.

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

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

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

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

Comments

[Pitonoslav]

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

[Василий Банников]

Vladislav, нужно конкретизировать, что такое "зависимость", тк ваше понимание зависимости не совпадает с общепринятым.

[Pitonoslav]

я добавил другой пример

[Pitonoslav]

Думаю вашего ответа достаточно, спасибо. Должен быть третий класс, Trip как в примере с машиной.

Answer 2

[Василий Банников]

в примере с кораблём и пространством можно использовать паттерн "фабрика".
Делаешь третий класс, в нём поле, которое содержит Space, и метод который будет принимать координаты нового корабля и возвращать созданный экземпляр. В этом методе и будет проверка.

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

В любом случае, в отрыве от конкретной задачи, вопрос смысла не имеет.

Answer 3

[Дмитрий Каратаев]

Если вопрос "в общем случае", то тут стоит прочитать про разные отношения между классами. Подробнее, например, здесь