public IEnumerable<string> GetPhotoUrl() =>
Api
.Wall
.Get(new WallGetParams
{
Domain = "lol.community",
Count = 2
})
.WallPosts
.Select(item => item.Attachments.FirstOfDefault()?.Instance)
.OfType<Photo>()
.Select(item => item.Sizes.FirstOfDefault()?.Url.AbsoluteUrl.ToString());@model Product
<div class="well"">
<h3>
<strong>@Model.Name</strong>
<span class="pull-right label label-primary">
@Model.Price.ToString("c", System.Globalization.CultureInfo.CreateSpecificCulture("en-US"))
</span>
</h3>
@using(Html.BeginForm("AddToCart", "Cart", FormMethod.Post))
{
@Html.Hidden("ProductID");
@Html.Hidden("returnUrl", ViewContext.HttpContext.Request.PathAndQuery());
<span class="lead">
@Model.Description
<button type="submit" class="btn btn-success btn-sm pull-right">
Добавить
</button>
</span>
}
</div>
Вообще не факт, что если объект агрегирует другой объект, то он его и создаёт. Например, коллекции. Элементы списка входят в список, но обычно не списки сами создают свои элементы.
И есть очень объёмная тема Dependency Injection (внедрение зависимостей) - там очень много нюансов: кто, когда и где инстанцирует объекты. Можно, конечно, поговорить об этом, но наверное лучше не здесь. И в случае с DI действительно получается что-то типа:
В случае DI тут "Завод" - это DI-контейнер (как пример и очень грубо).
То какие методы (публичные) есть у класса определяют API класса. То есть то как его будет воспринимать пользователь этого класса.
Чисто семантически (по смыслу, в обыденном представлении) странно от автомобиля ожидать, что он будет создавать двигатель. Пользователь автомобиля (в том числе программного объекта) может ожидать от API автомобиля, например, таких действий как поворота, изменения скорости, включения/выключения фар и т.п.