Здравствуйте, HowardLovekraft, Вы писали:
HL>Полиморфизм — тоже паттерн, конкретней, паттерн поведения (см. GRASP).
Инкапсуляция и наследование по вашему тоже паттерны?
Здравствуйте, HowardLovekraft, Вы писали:
HL>Однако полиморфизмом я бы называть это не стал — зачем обманывать топикстартера?
А как еще называется работа с классом через его базовый класс или интерфейс? Фабрика классов — это паттерн, а полиморфизм — это принцип ООП. Не надо путать понятия.
Здравствуйте, Аноним, Вы писали: А>не совсем онял, причем тут полиморфизм, просто, насколько я знал, абстрактный класс создать нельзя, интерестно, как он там создаётся, внутри
Создается экземпляр неабстрактного наследника от Image и возвращается как ссылка на Image.
Здравствуйте, Spiceman, Вы писали:
S>Полиморфизм, однако.
Это — полиморфизм?
switch (((ImageTypeEnum) type))
{
case ImageTypeEnum.Bitmap:
return Bitmap.FromGDIplus(nativeImage);
case ImageTypeEnum.Metafile:
return Metafile.FromGDIplus(nativeImage);
}
Ну на фиг.
Image.FromFile
От:
Аноним
Дата:
18.11.09 16:36
Оценка:
Не вкурил, Image абстрактный класс, как он создаёт себя внутри статического метода — FromFile?
Re[2]: Image.FromFile
От:
Аноним
Дата:
18.11.09 16:50
Оценка:
Здравствуйте, Spiceman, Вы писали:
S>Здравствуйте, Аноним, Вы писали:
А>>Не вкурил, Image абстрактный класс, как он создаёт себя внутри статического метода — FromFile? S>Полиморфизм, однако.
не совсем онял, причем тут полиморфизм, просто, насколько я знал, абстрактный класс создать нельзя, интерестно, как он там создаётся, внутри
Здравствуйте, Аноним, Вы писали:
А>не совсем онял, причем тут полиморфизм, просто, насколько я знал, абстрактный класс создать нельзя, интерестно, как он там создаётся, внутри
Внутри создается не абстрактный класс, а Bitmap или Metafile, которые являются наследниками Image. Т.е. возвращается на самом деле объект типа Bitmap или Metafile.
Здравствуйте, Mr.Cat, Вы писали: MC>Создается экземпляр неабстрактного наследника от Image и возвращается как ссылка на Image.
Это, типа, нормально, когда базовый класс знает о наследниках?
Здравствуйте, Аноним, Вы писали:
MC>>Создается экземпляр неабстрактного наследника от Image и возвращается как ссылка на Image. А>Это, типа, нормально, когда базовый класс знает о наследниках?
А какие возможные проблемы от такой реализации вы видите в данном случае?
Здравствуйте, MozgC, Вы писали:
MC>Здравствуйте, Аноним, Вы писали:
MC>>>Создается экземпляр неабстрактного наследника от Image и возвращается как ссылка на Image. А>>Это, типа, нормально, когда базовый класс знает о наследниках?
MC>А какие возможные проблемы от такой реализации вы видите в данном случае?
Например нерасширяемость. По-моему, можно было сделать регистрацию соответствий типов изображений и фабричных делегатов, создающих инстансы потомков Image. Тогда можно было-бы регистрировать новых потомков и они сразу становились бы доступны через этот метод. Но возможно, у авторов были причины так не делать.
Здравствуйте, koandrew, Вы писали:
K>Это ... фабричный метод.
Спс, в курсе.
Однако полиморфизмом я бы называть это не стал — зачем обманывать топикстартера?
Здравствуйте, Spiceman, Вы писали:
S>Фабрика классов — это паттерн, а полиморфизм — это принцип ООП
Фабричный метод — порождающий паттерн.
Полиморфизм — тоже паттерн, конкретней, паттерн поведения (см. GRASP).
В данном случае — фабричный метод в чистом виде.
Re[6]: Image.FromFile
От:
Аноним
Дата:
19.11.09 08:30
Оценка:
Здравствуйте, MozgC, Вы писали: MC>А какие возможные проблемы от такой реализации вы видите в данном случае?
Ну, я не знаю, просто чуствую одним место, что, увеличивается свазанность кода, и уменьшается сципление.
Допустим, в реальном мире, который, собственно и должно описывать ООП (в моём понимании),
отец рождается раньше детей, дети могут и не родится, или умереть раньше, но, с другой стороны, если взять абстрактный мир (в данном случае мы его и описуем), где отец и дети рождаются и умирают вместе, то это, наверно, логично
Здравствуйте, HowardLovekraft, Вы писали:
HL>Полиморфизм — тоже паттерн, конкретней, паттерн поведения (см. GRASP).
Вы о чем??? Какой нахер паттерн??? Принципы ООП Полиморфизм
Метод FromFile возвращал абстрактный класс. О конкретной реализации нам ничего не известно. Причем тут фабричный метод или какие-то еще паттерны? Мне абсолютно по барабану как и какой объект создается методом.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, MozgC, Вы писали: MC>>А какие возможные проблемы от такой реализации вы видите в данном случае? А>Ну, я не знаю, просто чуствую одним место, что, увеличивается свазанность кода, и уменьшается сципление.
Абсолютно правильно чувствуете. Никогда так не делайте. Ну по крайней мере без весомого обоснования.
Здравствуйте, HowardLovekraft, Вы писали:
HL>Полиморфизм.
В сборник паттернов можно много всего засунуть. От этого полиморфизм не перестает быть одним из четырех принципов ООП.
HL>P.S. Эмоции чуть-чуть убавьте.
Ок. Накатило просто
Здравствуйте, Spiceman, Вы писали:
S>полиморфизм не перестает быть одним из четырех принципов ООП
Этого я не утверждал.
Тем не менее, и паттерн "полиморфизм" никуда не денешь.
НЯП, тема про создание объектов конкретного класса в методе абстрактного класса — как это реализовано. Так что все-таки про фабричный метод.
Здравствуйте, HowardLovekraft, Вы писали:
HL>НЯП, тема про создание объектов конкретного класса в методе абстрактного класса — как это реализовано. Так что все-таки про фабричный метод.
Уговорил.
Но можно ведь было и не лезть в рефлектор, а сказать — создается неабстрактный наследник и возвращается с использованием полиморфизма.
Здравствуйте, koandrew, Вы писали:
K>Ээээ... А какой четвёртый-то? Вроде всегда их три было — инкапсуляция, наследование, полиморфизм...
По некоторым версиям, в столпы ООП еще включается абстракция.
Здравствуйте, MozgC, Вы писали: MC>По некоторым версиям, в столпы ООП еще включается абстракция.
Если это та, что гуляет за ручку с композицией, то так это вообще столп всего программирования.
Здравствуйте, MozgC, Вы писали:
MC>Здравствуйте, koandrew, Вы писали:
K>>Ээээ... А какой четвёртый-то? Вроде всегда их три было — инкапсуляция, наследование, полиморфизм... MC>По некоторым версиям, в столпы ООП еще включается абстракция.
Здравствуйте, ylem, Вы писали:
Y>Что плохого в том, что объект изображения можно создать из файла? Y>Image.FromFile()
С этим все нормально
Y>Причем тут кохежн и каплинг? Y>Или Вы исключительно про реализацию, которую подсмотрели рефлектором?
Именно, про реализацию, которую кто-то тут на форуме подсмотрел рефлектором
Re[4]: Image.FromFile
От:
Аноним
Дата:
19.11.09 13:44
Оценка:
Здравствуйте, koandrew, Вы писали:
K>Это называется фабрика классов, точнее, фабричный метод.
неправда ваша. это просто фабрика. а фабричный метод немного другое (Фабричный_метод)
Здравствуйте, Мизантроп, Вы писали:
М>Например нерасширяемость. По-моему, можно было сделать регистрацию соответствий типов изображений и фабричных делегатов, создающих инстансы потомков Image. Тогда можно было-бы регистрировать новых потомков и они сразу становились бы доступны через этот метод. Но возможно, у авторов были причины так не делать.
Однако, это не мешает потом создавать собственно конкретный класс через Image.FromFile (а он внутри бы уже разбирал цепочку нарегистрированных делегатов)
Проблема текущей реализации не в методе Image.FromFile а в жестко забитых классах внутри него.