AS
но с помощью интерфейсов можно описывать не только поведение, но еще и какие то общие проперти, т.к. у го нет других механизмов для этого
Size: a a a
2020 April 08
p
но с помощью интерфейсов можно описывать не только поведение, но еще и какие то общие проперти, т.к. у го нет других механизмов для этого
я понимаю :) вопрос в нейминге ) не звать же это Arearer, Perimeterer итд
x
А вот расскажите про нейминг интерфейсов. Канонично ими описывать поведение объектов, все эти Reader, Writer, итп. Но в go tour использование интерфейсов показывают на примере площади треугольника/прямоугольника. И вот тут вопросов 2:
1) с каким пор площадь стала поведением объекта?
2) как такой интерфейс назвать?
1) с каким пор площадь стала поведением объекта?
2) как такой интерфейс назвать?
1. Ну сама площадь-то не является поведением, но вычисление площади — это поведение, да, ничего удивительного.
2. Каноничным, вы в курсе, думаю, является вариант с суффиксом er, то есть в данном случае Squarer с методом Square. Хотя не всегда это красиво и правильно)
2. Возможно, какой-нибудь
UPD2: исправил
2. Каноничным, вы в курсе, думаю, является вариант с суффиксом er, то есть в данном случае Squarer с методом Square. Хотя не всегда это красиво и правильно)
2. Возможно, какой-нибудь
AreaProcessor
UPD: я почему-то подумал, что речь обязательно о квадрате(UPD2: исправил
AS
я понимаю :) вопрос в нейминге ) не звать же это Arearer, Perimeterer итд
тут как удобнее / понятнее, так и называйте
ЛА
upd, не go tour: https://gobyexample.com/interfaces
Неясно зачем он привязался к фигурам и сделал интерфейс с 2 методами сразу.
По идее должно быть 2 типа интерфейса - на вычисление площади и на периметр и пофиг, какая фигура будет использовать. Композиция на то и композиция
По идее должно быть 2 типа интерфейса - на вычисление площади и на периметр и пофиг, какая фигура будет использовать. Композиция на то и композиция
p
Неясно зачем он привязался к фигурам и сделал интерфейс с 2 методами сразу.
По идее должно быть 2 типа интерфейса - на вычисление площади и на периметр и пофиг, какая фигура будет использовать. Композиция на то и композиция
По идее должно быть 2 типа интерфейса - на вычисление площади и на периметр и пофиг, какая фигура будет использовать. Композиция на то и композиция
Согласен, но это вторично. Вопрос скорее про то, что площадь и периметр - это свойство(пусть и вычисляемое). Теперь представим, что у каждого объекта есть еще и цена. Будем делать интерфейс Price?
ЛА
Согласен, но это вторично. Вопрос скорее про то, что площадь и периметр - это свойство(пусть и вычисляемое). Теперь представим, что у каждого объекта есть еще и цена. Будем делать интерфейс Price?
Вся вычисляемая логика может быть вынесена в интерфейсы, тоже не вижу противоречий
а
Неясно зачем он привязался к фигурам и сделал интерфейс с 2 методами сразу.
По идее должно быть 2 типа интерфейса - на вычисление площади и на периметр и пофиг, какая фигура будет использовать. Композиция на то и композиция
По идее должно быть 2 типа интерфейса - на вычисление площади и на периметр и пофиг, какая фигура будет использовать. Композиция на то и композиция
просто интерфейс следовало назвать Figure
ЛА
просто интерфейс следовало назвать Figure
За такой интерфейс в го наверное убьют) это ведь здесь стараются делать максимально простые и понятные интерфейсы в идеале с 1 методом, типа ридер, райтер
T
За такой интерфейс в го наверное убьют) это ведь здесь стараются делать максимально простые и понятные интерфейсы в идеале с 1 методом, типа ридер, райтер
А как же ReadWriter ))
а
ReadWriteCloser
бгг