в Б+ деревьях есть два класса отвечающих за уровни
один за самый нижний другой за верхние.
Все базирутся от
LevelBase<K, V> который является абстрактным классом
namespace RSDN.Collections
{
/// <summary>
/// Summary description for LevelBase.
/// </summary>internal abstract class LevelBase<K, V>
{
public int _levelNum;
public BPlusTree<K, V> _bPlusTree;
public int _index;
public NodeLevel<K, V> _parent;
public abstract void First();
public abstract void Last();
public abstract void GetFirstElem();
public abstract void GetLastElem();
public abstract bool NavigateKey(K key);
public abstract bool NavigateKeyFromParent(K key, PageBase page);
public abstract bool NavigateOrInsertDefault(K key);
public int LevelNum { get { return _levelNum; } }
public abstract void SetPage(PageBase page);
}
}
Понятно, что LeafLevel и NodePage никогда перекрываться не будут,
(PageBase тоже абстрактный класс, так как на уровнях разные страницы)
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Serginio1 пишет: >> ANS>отменять наследование?.. >> >> Логикой проектирования класса. Там где не нужно перекрытие. Таких >> классов очень много, базирующихся на определенном кастомном, в котором
ANS>Приведи пример такого класса.
Тот же FileStream, (а так же типизированные делегаты, массивы итд.)
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Serginio1 пишет: >> > ANS>отменять наследование?.. >> > >> > Логикой проектирования класса. Там где не нужно перекрытие. Таких >> > классов очень много, базирующихся на определенном кастомном, в котором > > ANS>Приведи пример такого класса. > > Тот же FileStream, (а так же типизированные делегаты, массивы итд.)
За делегатов не скажу, а в переопределении потоков и массивов криминала
нет. В ST это распространённая практика.
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
>> ANS>Приведи пример такого класса. >> >> Тот же FileStream, (а так же типизированные делегаты, массивы итд.)
По поводу массивов, то для них нужно назначить только тип ( и соответственно длину). И соответственно все методы доступа инлайнятся.
По поводу FileStream и более экзотичных стримов методы Read и write это имеет какой либо смысл.
Опять же не охота ввязываться в спор, есть достаточно много своих личных конечных классов, где по личному мнению не нужно перекрытие, и если по какой то причине это нужно всегда легко снять эти ограничения.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Хотя бы потому, что просто написав программу на том же Smalltalk будет ANS>задействована большая часть того, что называется "патерны". Имхо, этого ANS>достаточно.
Нда, логика ниже плинтуса. Концепции они и в африке концепции. А паттерны их нужно или узучать отедьно или вообще от них абстрагироваться.
ANS>Ну и второй аргумент — чистота. "Любить — так любить, гулять — так ANS>гулять". Допустим изучение ООП. Изучать нужно не отвлекаясь на то, что ANS>можно доступ к членам класса напрямую получить, на всякие там ANS>модификаторы доступа, виртуальные/невиртуальные функции, final/sealed. ANS>Или ты и с этим не согласен?
Ну, а я считаю, что такая чистота — это и есть грязь. И если бы это было не так, то все бы в промышленном производстве софта использовали бы именно Смолток, а не Яву и Шарп.
ANS>Кстати, какая польза от sealed?
Запред на наследование от некоторого класса. Если по прикладной логики у класса не должно быть наследников, то ты это выражашь.
>> хуже в Яве, C#, Хаскеле, Скале какой нибудь и т.п.
ANS>Так ты таки предлагаешь учить с начала хаскель/скалу?
Скала слишком сложно для начала. Хаскель можно как представителя ФЯ. Но уж ООП точно начинаь учить нужно на Яве или Шарпе. И уж после освоения можно для расширения кругозора дать Скалу и Смолток.
Мне просто забавляет логика по которой Шарп с Явой вообще учить нельзя, а Смолток нужно.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 пишет: > ANS>Хотя бы потому, что просто написав программу на том же Smalltalk будет > ANS>задействована большая часть того, что называется "патерны". Имхо, этого > ANS>достаточно. > > Нда, логика ниже плинтуса. Концепции они и в африке концепции. А
Так с концепциями там тоже фиговенько. Той же посылки сообщений в
"псевдо-оо" как не было так и нет. А всё туда же — ОО обучать.
> паттерны их нужно или узучать отедьно или вообще от них абстрагироваться.
Так как же ты от них абстрагируешся если на каждом шаге их нужно
применять явно?
> ANS>Ну и второй аргумент — чистота. "Любить — так любить, гулять — так > ANS>гулять". Допустим изучение ООП. Изучать нужно не отвлекаясь на то, что > ANS>можно доступ к членам класса напрямую получить, на всякие там > ANS>модификаторы доступа, виртуальные/невиртуальные функции, final/sealed. > ANS>Или ты и с этим не согласен? > > Ну, а я считаю, что такая чистота — это и есть грязь. И если бы это было
Да-да-да. Попробую объяснить медленнее. модификаторы доступа,
невиртуальные функции, sealed классы не имеют отношения к ОО. Как ты их
будеш использовать для обучения ОО.
> не так, то все бы в промышленном производстве софта использовали бы > именно Смолток, а не Яву и Шарп. > > ANS>Кстати, какая польза от sealed? > > Запред на наследование от некоторого класса. Если по прикладной логики у > класса не должно быть наследников, то ты это выражашь.
А какая польза от запрета наследования?
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
Andrei N.Sobchuck пишет:
>> Запред на наследование от некоторого класса. Если по прикладной логики у >> класса не должно быть наследников, то ты это выражашь. > А какая польза от запрета наследования?
Cyberax пишет: >> > Запред на наследование от некоторого класса. Если по прикладной логики у >> > класса не должно быть наследников, то ты это выражашь. >> А какая польза от запрета наследования? > > Гарантируемая иммутабельность объектов.
Про это я помню
Думается мне, это решаемо введением соответсвующего модификатора и
проверкой на этапе компиляции. Не нужно ограничивать наследование.
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
Andrei N.Sobchuck пишет:
> > > > >> Гарантируемая иммутабельность объектов. > Про это я помню > Думается мне, это решаемо введением соответсвующего модификатора и > проверкой на этапе компиляции. Не нужно ограничивать наследование.
public class A1
{
final int val=1;
int getVal() {return val;};
};
public class A2 extends A1
{
int getVal(){return Math.rand();}; //Hehe
};
То есть с помощью наследования можно нарушить иммутабельность. Проверить
на этапе компиляции это невозможно, так как класс A2 может быть,
например, загружен из сети во время работы приложения.
C>public class A1
C>{
C> final int val=1;
C> int getVal() {return val;};
C>};
C>public class A2 extends A1
C>{
C> int getVal(){return Math.rand();}; //Hehe
C>};
C>
C>То есть с помощью наследования можно нарушить иммутабельность. Проверить C>на этапе компиляции это невозможно, так как класс A2 может быть, C>например, загружен из сети во время работы приложения.
Курилка пишет:
> >C>public class A1 >C>{ >C> final int val=1; >C> int getVal() {return val;}; >C>}; >C>public class A2 extends A1 >C>{ >C> int getVal(){return Math.rand();}; //Hehe >C>}; >C> > > > C>То есть с помощью наследования можно нарушить иммутабельность. > Проверить > C>на этапе компиляции это невозможно, так как класс A2 может быть, > C>например, загружен из сети во время работы приложения. > А что мешает сделать getVal final?
Тогда ее наследовать нельзя будет, в чем собственно и был вопрос.
Здравствуйте, Cyberax, Вы писали:
C>Тогда ее наследовать нельзя будет, в чем собственно и был вопрос.
Т.е. вопрос получается — имеет ли смысл запрещать наследование класса целиком, или только опр. части его, жаба даёт оба варианта и выбор за программером
Курилка пишет:
> C>Тогда ее наследовать нельзя будет, в чем собственно и был вопрос. > Т.е. вопрос получается — имеет ли смысл запрещать наследование класса > целиком, или только опр. части его, жаба даёт оба варианта и выбор за > программером
Да, причем запрет наследования всего класса можно считать просто как
сокращение, чтобы не писать final перед каждым членом класса.
ANS>модификаторы доступа, ..., не имеют отношения к ОО.
А что, инкапсуляция тоже не имеет отношение к ОО?
Учитывая, что модификаторы доступа — это есть механизм управления инкапсуляцией...
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Так с концепциями там тоже фиговенько. Той же посылки сообщений в ANS>"псевдо-оо" как не было так и нет. А всё туда же — ОО обучать.
Да нет необходимости для ООП эмулировать поведение Смолтока. Вызов методов — это та же послыка сообщений.
ANS>Так как же ты от них абстрагируешся если на каждом шаге их нужно ANS>применять явно?
А так и асбрагируешся. Они в язык вмонтированы. Ненапряжно изучашь себе языки и за одно преобщаешся к паттернам. Потом когда начнешь их проходить явно (жаль что скорее всего уже не в инстуитуте), то останется только уточнить понятия и закрепить материал.
ANS>Да-да-да. Попробую объяснить медленнее. модификаторы доступа, ANS>невиртуальные функции, sealed классы не имеют отношения к ОО. Как ты их будеш использовать для обучения ОО.
ОО — это в первую очередь принцип инкапсуляции логики и данных в объектах. Так как это достигается действительно дело десятое. И модификаторы доступа — это всего лишь удобное и простое решение задачи. Однако они не чем не хуже, а на мой взгляд лучше, чем другие решения.
ANS>А какая польза от запрета наследования?
В каждом случае разная. Где-то защита инкапсуляции. Где-то предотвращения неверного дизайна иерархии классов. Где-то оптимизация (хотя на сегодня от этого толку 0).
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Да, причем запрет наследования всего класса можно считать просто как C>сокращение, чтобы не писать final перед каждым членом класса.
Именно. Но изменение неизменяемого объекта — это всего лишь частичный случай нарушения инкапсуляции от которого и позволяют застраховаться средства вроде final/sealed. Если использовать их с умом, то в больших проектах можно сэкономить кучу сил и времени.
Врочем в целях обучения, на первых порах можно опускать эти тонкости. Шапри и Ява тем и хороши, что их расширенные средства не обязательны. Начать писать приложения можно на очень ограниченном поднаборе средств языка. А потом увиличивать свои возможности за счет освоения более высокоуровневых и сложных вешей.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
prVovik пишет: > ANS>*модификаторы доступа*, ..., не имеют отношения к ОО. > А что, инкапсуляция тоже не имеет отношение к ОО? > Учитывая, что модификаторы доступа — это есть механизм управления > инкапсуляцией...
Ага, выходит так: Smalltalk — нет модификаторов, совсем не ОО;
С++ — 3 модификатора, чуть-чуть ОО; Java — поболее модификаторов, значит
более ОО, чем С++; и С# — еще больше модификаторов, ну полный ОО.
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
