|
|
|
ООП
|
|||
|---|---|---|---|
|
#18+
Имеется базовый класс BaseClass. У базового класса имеется конструктор с одним параметром New(id as guid) Возникла необходимость в создании класса-наследника DerivedClass Однако выходит так, что у класса-наследника должен быть конструктор с тремя параметрами New(id as guid, idperiod as guid, idbranch as integer) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 11:25 |
|
||
|
ООП
|
|||
|---|---|---|---|
|
#18+
Не могу сообразить, как такое следует делать, не переписывая целиком весть конструктор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 11:26 |
|
||
|
ООП
|
|||
|---|---|---|---|
|
#18+
BrokenPotИмеется базовый класс BaseClass. У базового класса имеется конструктор с одним параметром New(id as guid) Возникла необходимость в создании класса-наследника DerivedClass Однако выходит так, что у класса-наследника должен быть конструктор с тремя параметрами New(id as guid, idperiod as guid, idbranch as integer) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 11:49 |
|
||
|
ООП
|
|||
|---|---|---|---|
|
#18+
То есть, нужно все-таки наново переписывать весь конструктор? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 12:10 |
|
||
|
ООП
|
|||
|---|---|---|---|
|
#18+
BrokenPotТо есть, нужно все-таки наново переписывать весь конструктор? Бозе мой. Ну напиши Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 12:17 |
|
||
|
ООП
|
|||
|---|---|---|---|
|
#18+
(меня всё равно забанят) BrokenPotТо есть, нужно все-таки наново переписывать весь конструктор? Бозе мой. Ну напиши Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. тогда уж так Код: plaintext 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 14:16 |
|
||
|
ООП
|
|||
|---|---|---|---|
|
#18+
BrokenPotНе могу сообразить, как такое следует делать, не переписывая целиком весть конструктор. Вызывать (использовать) прежний из нового. Как это делать - см. описание используемого языка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 14:27 |
|
||
|
ООП
|
|||
|---|---|---|---|
|
#18+
Беда в том, что в конструкторе базового класса происходит добавление в некие коллекции неких элементов. Это происходит с использованием параметра, передаваемого в конструктор базового класса. В классе-наследнике также должно происходить добавление неких, но других, элементов, также с использованием, но уже трех, параметров, которые должны передаваться в конструктор класса-наследника. Если записать так, как обычно, то есть так, как мне советуют, то получается, что отрабатывает уже конструктор базового класса, без дополнительных параметров. Получается, что нужно весь конструктор переписывать по новой, но этого, во-первых, не хочется, во-вторых - переписывание представляется нарушением объектной модели, ведь конструктор класса-наследника почти ничем не должен отличаться от конструктора базового класса, только лишь в части добавления других элементов и передачи этим элементам своих дополнительных параметров. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 14:46 |
|
||
|
ООП
|
|||
|---|---|---|---|
|
#18+
BrokenPot Получается, что нужно весь конструктор переписывать по новой, но этого, во-первых, не хочется, во-вторых - переписывание представляется нарушением объектной модели, ведь конструктор класса-наследника почти ничем не должен отличаться от конструктора базового класса, только лишь в части добавления других элементов и передачи этим элементам своих дополнительных параметров. Я вам привел пример. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Обратите особое внимание на модификаторы видимости. В объекте-наследнике доступ к конструктору с одним параметров в приинципе запрещен извне. Что вы баламутите? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 15:53 |
|
||
|
ООП
|
|||
|---|---|---|---|
|
#18+
Я не баламутю. А в тебе бла-бла-бла присутствует вызов конструктора базового класса? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 16:13 |
|
||
|
ООП
|
|||
|---|---|---|---|
|
#18+
BrokenPot А в теле бла-бла-бла присутствует вызов конструктора базового класса? Хм... Могу лишь посоветовать вынести BaseClass и ExtClass в отдельные пакеты (или как там они в твоем языке называются) - т.е. чтобы к конструктору BaseClass без параметров никто не имел доступа (кроме наследников BaseClass - т.е. ExtClass и других). Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. Либо, как вариант Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 18:08 |
|
||
|
ООП
|
|||
|---|---|---|---|
|
#18+
BrokenPotведь конструктор класса-наследника почти ничем не должен отличаться от конструктора базового класса, только лишь в части добавления других элементов и передачи этим элементам своих дополнительных параметров. Осталось сделать единственный шаг, чтобы получить из этого ответ "как надо делать". Вообще, отмечу, создание элементов коллекции в конструкторе коллекции и только там - малость странная постановка вопроса. Но тем не менее..... Вы определили, что именно должно различаться в конструкторах. Что следует делать в том случае, если есть две похожие подпрограммы? Правильно: выделить общую часть кода в одну подпрограмму (в данном случае в конструктор), а различающиеся - в другие (например, в разные реализации виртуального метода). Итого - базовый конструктор вызывает виртуальный метод "создать очередной элемент коллекции" и спокойно работает в любом наследнике. Тут возникает вопрос, как передать параметры. Есть два метода. Первый - через локальные поля; конструктор наследника запоминает параметры, вызывает базовый, тот строит коллекцию, вызываемый при этом виртуальный метод читает поля. Второй - сделать объект "параметры инициализации" и передавать именно его. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 21:59 |
|
||
|
ООП
|
|||
|---|---|---|---|
|
#18+
О! Спасибо большое. Рад получить содержательный и исчерпывающий ответ. Особенно приятно, что он совпал с моими соображениями, которые появились, пока я ожидал ответа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2006, 09:18 |
|
||
|
ООП
|
|||
|---|---|---|---|
|
#18+
имхо, нужно делать через параметры инициализации, а то вызывать метод для ещё неинициализированного объекта – как-то не очень… ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2006, 15:13 |
|
||
|
ООП
|
|||
|---|---|---|---|
|
#18+
maXmoимхо, нужно делать через параметры инициализации, а то вызывать метод для ещё неинициализированного объекта – как-то не очень… Ничуть не более, нежели делать с "еще не инициализированным объектом" что-то другое. Подозреваю, Вы отталкиваетесь от явы, то как сделана инициализация там, меня, если честно, напрягает, по разным причинам. В частности, я уже приводил этот код: Код: plaintext 1. 2. 3. 4. и Код: plaintext 1. 2. 3. 4. 5. Я понимаю, почему компилятор ругается на второй вариант, но полагаю такое поведение глупым. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2006, 16:27 |
|
||
|
ООП
|
|||
|---|---|---|---|
|
#18+
softwarerПодозреваю, Вы отталкиваетесь от явы, то как сделана инициализация тампонятия не имею, как она там сделана. На практике это наверняка заработает, просто это как-то интуитивно нехорошо – вызывать какие-то левые методы до того, как конструктор отработает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2006, 16:52 |
|
||
|
ООП
|
|||
|---|---|---|---|
|
#18+
maXmoпросто это как-то интуитивно нехорошо – вызывать какие-то левые методы до того, как конструктор отработает. Левых методов в классе быть вообще не должно. Не хочется устраивать громоздкое обсуждение, поэтому постараюсь обойтись одним простым тезисом, имеющем отношение уже не ООП, но к программированию вообще: любой фрагмент кода, если это нужно, может быть выделен в подпрограмму. Нарушение этого тезиса очевидно приводит к ситуации "подпрограмма не выделена там, где она нужна" и всем последствиям - дублированию кода, плохой сопровождаемости итп. Таким образом, если нужно выделить подпрограмму из тела конструктора - ее нужно выделять. Очевидно, что там, где такое выделение запрещено, придется выдумывать кривые методы обхода. Скажем, в примере выше - придумать функтор "создатель элементов коллекции" и передавать его в базовый конструктор. Формально это уже не собственный метод объекта, фактически - кривизна на пустом месте. Можно вести речь о том, какие подпрограммы правильно либо неправильно вызывать из конструктора. Тут мне ява когда-то подкинула забавный сюрприз. Код был примерно следующим: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Прикол этого кода был в том, что в результате его выполнения сначала был вызван конструктор базового класса, он вызвал виртуальный метод и инициализацию someData, а только потом отработало присваивание someData = null. Особой логики я в таком поведении не вижу, имхо неудачная калька с C++ как раз там, где стоило чуть изменить модель. В Java5, если мне не изменяет память, как раз из-за подобных эффектов рубанули топором и компилятор стал ругаться на вполне разумный код, пришлось придумывать обходы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2006, 18:51 |
|
||
|
ООП
|
|||
|---|---|---|---|
|
#18+
softwarerлюбой фрагмент кода, если это нужно, может быть выделен в подпрограмму. Нарушение этого тезиса очевидно приводит к ситуации "подпрограмма не выделена там, где она нужна" и всем последствиям - дублированию кода, плохой сопровождаемости итп. Таким образом, если нужно выделить подпрограмму из тела конструктора - ее нужно выделять.согласен. Если нужно. Но тут явно была задача на написание конструктора в более общей форме. softwarerСкажем, в примере выше - придумать функтор "создатель элементов коллекции" и передавать его в базовый конструктор. Формально это уже не собственный метод объекта, фактически - кривизна на пустом месте.если нужно создать объект почти произвольного типа, ответ один – фабрика. Если хочется ограничения видимости, фабрику можно сделать в виде класса, вложенного в DerivedClass из твоего примера, можно даже с модификатором private. Но тут это не понадобилось, т.к. чел хотел всё сделать в одном месте – в базовом конструкторе обобщённой формы… получилось сделать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2006, 11:44 |
|
||
|
ООП
|
|||
|---|---|---|---|
|
#18+
[quot softwarerПодозреваю, Вы отталкиваетесь от явы, то как сделана инициализация там, меня, если честно, напрягает, по разным причинам. В частности, я уже приводил этот код: ... Я понимаю, почему компилятор ругается на второй вариант, но полагаю такое поведение глупым.[/quot] Ага, во всех грехах виновата java %) з.ы. Тоже самое сделано в языках .NET, потому что это правильно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2006, 13:03 |
|
||
|
ООП
|
|||
|---|---|---|---|
|
#18+
maXmoсогласен. Если нужно. Но тут явно была задача на написание конструктора в более общей форме. "Как оптимально решать данную конкретную задачу" можно обсуждать; пока кроме моего никаких предложений не прозвучало. Но здесь я сосредоточился на более узкой теме, вызове подпрограммы из конструктора как идее. Я так понимаю, мы пришли к согласию в том, что это может быть уместно. maXmoесли нужно создать объект почти произвольного типа, ответ один – фабрика. Я не очень понимаю, что такое "объект почти произвольного типа", и во всяком случае задача "создать указанного наследника базового типа" - имхо к таковым не относится. И это одна из наиболее типичных задач в ООП. Далее, у меня нет уверенности в том, что я понимаю, что Вы называете "фабрикой". Точнее, разные люди при мне определяли это понятие с существенными различиями. Если понимать фабрику как некий выделенный объект, то это очевидно не единственный ответ и очень далеко не факт, что лучший. maXmoЕсли хочется ограничения видимости, фабрику можно сделать в виде класса, вложенного в DerivedClass Вложенный класс инициализируется указателем на объемлющий, так что здесь мы имеем ту же самую проблему "еще не инициализированного объекта", которой Вы опасаетесь. В целом у меня есть ощущение, что Вы советуете как раз то, что я склонен считать нагромождением "сложностей" на пустом месте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2006, 20:26 |
|
||
|
ООП
|
|||
|---|---|---|---|
|
#18+
NotGonnaGetUsАга, во всех грехах виновата java %) Прошу прощения, но по-моему у Вас mania grandioso. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2006, 20:30 |
|
||
|
ООП
|
|||
|---|---|---|---|
|
#18+
softwarerНо здесь я сосредоточился на более узкой теме, вызове подпрограммы из конструктора как идее. Я так понимаю, мы пришли к согласию в том, что это может быть уместно.ну если ограничиться более узкой темой softwarerСкажем, в примере выше - придумать функтор "создатель элементов коллекции" и передавать его в базовый конструктор. Формально это уже не собственный метод объектая же предлагаю этот несобственный метод объекта выделить в другой класс, в котором он будет собственный и в котором он будет вызываться на уже сконструированном объекте. softwarerЯ не очень понимаю, что такое "объект почти произвольного типа", и во всяком случае задача "создать указанного наследника базового типа" - имхо к таковым не относится. И это одна из наиболее типичных задач в ООП.под фабрикой я понимаю объект, создающий наследников базового класса. Создавать же указанных наследников можно просто оператором new, нет? softwarerЕсли понимать фабрику как некий выделенный объект, то это очевидно не единственный ответ и очень далеко не факт, что лучший.ну… выделяешь ты эту логику в отдельный класс или не выделяешь, в любом случае роль фабрики выполняет тот класс, в котором этот метод содержится. Почему бы не выделить эту логику в отдельный класс? Разве это не логично? Мне это видится логичным; это распространённый метод, к тому же исчезнут всякие сюрпризы с конструкторами. softwarerВложенный класс инициализируется указателем на объемлющийвовсе не обязательно. softwarerВ целом у меня есть ощущение, что Вы советуете как раз то, что я склонен считать нагромождением "сложностей" на пустом месте.мне видится, что место совсем не пустое. Либо пишешь метод, который не меняет состояний окружающих объектов (и не зависит от них), либо одно их двух. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2006, 11:39 |
|
||
|
ООП
|
|||
|---|---|---|---|
|
#18+
maXmo softwarerСкажем, в примере выше - придумать функтор "создатель элементов коллекции" и передавать его в базовый конструктор. Формально это уже не собственный метод объектая же предлагаю этот несобственный метод объекта выделить в другой класс, Хм. "Функтор" - это и есть "другой класс". maXmoпод фабрикой я понимаю объект, создающий наследников базового класса. Создавать же указанных наследников можно просто оператором new, нет? Оператором new можно создавать статически указанных наследников. Если не ошибаюсь, Код: plaintext 1. в яве не пройдет, да и в C++ тоже. maXmoв любом случае роль фабрики выполняет тот класс, в котором этот метод содержится. Почему бы не выделить эту логику в отдельный класс? Разве это не логично? Мне это видится логичным; это распространённый метод, к тому же исчезнут всякие сюрпризы с конструкторами. То есть Вы понимаете фабрику примерно как я ожидал. Описанное выделение - совершенно не факт, что логично. По общему принципу Оккама, наоборот, нужно доказывать, что оно в данном конкретном случае дает преимущества. Насчет распространенности метода.... скажем так, он распространен только потому, что закрывает один из концептуальных недостатков C++, который там никак иначе не решишь (разве что в последних версиях). maXmo softwarerВложенный класс инициализируется указателем на объемлющийвовсе не обязательно. Будем считать, Вам виднее. Для меня это новость. maXmoмне видится, что место совсем не пустое. Либо пишешь метод, который не меняет состояний окружающих объектов (и не зависит от них), либо одно их двух. Хм. Давайте так: я сейчас не хочу спорить по этому поводу. Предложите топикстартеру свое решение, пусть делает как ему больше понравится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2006, 12:31 |
|
||
|
ООП
|
|||
|---|---|---|---|
|
#18+
softwarerПо общему принципу Оккама, наоборот, нужно доказывать, что оно в данном конкретном случае дает преимущества.то есть если, скажем, мы будем писать приложение для накачки мячей, мы в нём можем мяч и насос объединить в один класс, потому что мы можем так сделать? softwarerБудем считать, Вам виднее. Для меня это новость. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. softwarerПредложите топикстартеру свое решение, пусть делает как ему больше понравится.да он уже удовлетворён. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2006, 13:22 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=34213898&tid=1346350]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
158ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
| others: | 199ms |
| total: | 456ms |

| 0 / 0 |
