Эволюция кода: путь к лучшему дизайну

[SH33011]

Изначальное решение этой задачи было реализовано с помощью объектно-ориентированного подхода на Go

Разве в Go есть классы?

[DollyPapper]

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

[vadimr]

Конечно, это Африка, но я бы за такое преподавание увольнял. Какой смысл в наличии класса Car в этой задаче? Магазину настолько не всё равно, чем торговать, что надо автомобиль зашить в код приложения? А если Джон захочет продать резину, придётся менять код?

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

[avshkol]

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

Поэтому все товары имеют название, цену и количество, а автомобили могут иметь ещё массу специфичных полей/признаков и методов.

[vadimr]

type Car struct {

Product
}

(однако, почему-то,

if p.(Car).Name == name

).

Да и вряд ли в реальной жизни вы найдёте такой типизирующий магазин.

[MentalBlood]

Классы — часть ПО. Прикладное ПО проектируется в первую очередь исходя из удобства использования, потому что оно прикладное, а не рекреационное

[vadimr]

Удобство использования ПО никоим образом не зависит от внутреннего устройства его кода.

[MentalBlood]

Удобство использования библиотеки сильно зависит от иерархии классов, доступных пользователю

[funca]

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

Напомнило старый анекдот, кажется ещё из 90х: "шел второй день конференции на тему ООП. Одни докладчики рассказывали про моделирование объектов окружающего мира. Другие выступали по делу."

Тема интересная, я пожалуй подпишусь на комменты. :)

[yellow79]

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

[alhimik45]

которая товаром не является, а лишь содержит его

Не знаток Go, но вроде это стардартный метод для него выразить наследование а-ля class Car extends Product

[Blogoslov]

непонятно, а зачем в таком примере вообще вводить interface?
Тем более вы ими почти и не пользуетесь, а в том месте где используется можно было просто вернуть тип Product, из которого и вызываются соответствующие методы.
В чём сакральный смысл для interface в данном примере и почему нельзя без него?