Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 [8] 9   вперед  Ctrl      все
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
nik_x
Member

Откуда:
Сообщений: 1887
ХВАЛА АКСЕСС!!!

АУМ. АУМ.
28 июн 04, 19:09    [769770]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
Guest_333
Guest
Поддерживаю ACURUSа на 1000% насчет наследования! Уже из-за одного того, что в Access нет наследования - у меня нет никакого энтузиазма писать что-либо на нем :( Все контролы/бизнес-объекты, выполняющие сходные функции должны наследоваться из одного класса, в котором и должен быть прописан прописан нужный, общий для них функционал, а самих наследниках при необходимости уточняться в соотвествии с контекстом. Даже какая-нибудь банальная кнопка "Закрыть" должна наследоваться с одного места, чтобы при необходимости всего лишь одним движением руки изменить поведение хоть тысячи кнопок-наслеников... Применение наследования существеннейшим образом облегчает любые манипуляции в больших проектах, где любимый VB/VBA-шниками способ разработки "Copy/Paste" может запросто свести в могилу, когда количество сходных объектов пойдет на сотни... Сам на Visual FoxPro пишу. Пытался в свое время кое-что сделать на Access и меня совершенно разочаровало отсутствтие возможности наследования :( Это ж в какой гемоорой может превратиться разработка, если количество форм/контролов (аka стандартных, повторяющихся ситуаций) будет все больше и больше возрастать?
Access хорош для Power Users, и мелких проектов... Что-то более сложное и замороченное - ИМХО выливается ад для программиста, ибо я не понимаю, как можно без наследования управлять тучей объектов со схожей функциональностью...
2 июл 04, 11:00    [779591]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
x
Guest
Guest_333
Поддерживаю ACURUSа на 1000% насчет наследования! Уже из-за одного того, что в Access нет наследования - у меня нет никакого энтузиазма писать что-либо на нем
...
ибо я не понимаю, как можно без наследования управлять тучей объектов со схожей функциональностью...

И как только люди жили без объектного программирования ?
Да еще и Copy/Past не было ...

Наверно ничего хорошего написать и не могли
2 июл 04, 12:14    [779950]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
йцук
Guest
стерлядь, на благостной почве программизма выросло ну столько баобабов... ну таких баобабов...

Вся эта объектно-ориентированная п...обратия ну дико напоминает соседний топик:
в соседнем топике mv писал
Вроде бы были нормальные чайники, тыкались мокрыми носами, расползались по столу толстыми лапами, а перешли на Oracle/C++ - как сырого мяса наелись

и там же писал Markus
Нихера не знают кроме Oracle и пучит их от своей якобы крутизны.


Наверняка же хера не знают, кроме "классической" (С++, Delphi, etc) модели объектно-ориентированного программирования. Про какой-нибудь smalltalk слыхом не слышали, про COM - слышали, но ни хера не поняли.

Наследования реализации у них блин нет. Интересно, чего такого волшебного вот именно этот Guest_333 может сделать с помощью "классического" наследования реализации, чего нельзя сделать с помощью связки "наследование интерфейса + приватный экземпляр родителя"? Или вообще с помощью агрегации (недоступной, правда, в VB)?
Хотя чего этот Guest_333 может сделать... он с помощью Copy-Paste программирует...

Они такие тупые... (с) Задорнов
2 июл 04, 13:17    [780238]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
Guest_333
Guest
Чем выпендреживаться чужими цитатами и орать как кастрированному, лучше сделай мне на VB/VBA трехуровневую иерархию наследования с помощью связки "наследование интерфейса + приватный экземпляр родителя" (aka Implements + Dim xxx AS ParentClass)

1. Создай в классе FirstClass метод MyMethod + штук 5 свойств
2. Унаследуй от FirstClass класс SecondClass (заодно продемонстрируешь, каким геморром в Бейсике является "наследование интерфейса", когда объявление каждго наследуемого свойства и метода в обязательном порядке надо описывать руками)
3. Переопредели в нем метод MyMethod. Добавь к описанию класса еще пару свойств
4. Унаследуй от SecondClass класс ThirdClass
5. Покажи как тебе это удалось

Открываем MSDN и видим, что достижение п. 5 невозможно по причине:
MSDN
Note Visual Basic does not implement derived classes or interfaces.

Если ты этого не сможешь, то дальнейшее обсуждение этого вопроса я считаю бессмысленным. Наследование (пусть даже только наследование интерфейса как в VB), ограниченное всего одним уровнем иерархии, для меня лично серьезным инструментом, который можно было бы использовать в работе, не является



ЗЫ
Пример той же задачи на VFP:

* Выполнение

oThirdClass = CREATEOBJECT("ThirdClass")  && Создаем объект класса ThirdClass
oThirdClass.MyMethod()  && Вызываем метод MyMethod класса ThirdClass



**
* И сами описания классов

*****************************************************
DEFINE CLASS FirstClass AS Custom
*  
*****************************************************
    Property1 = 1111  && Свойства класса
    Property2 = 2222
    Property3 = 3333 
    Property4 = 4444
    Property5 = 5555 

    PROCEDURE MyMethod
        ? "Код из FirstClass.MyMethod"  && Это вывод текста на экран
        ? This.Property1                && Выведем на экран наше свойство Property1 
    ENDPROC    

ENDDEFINE



*****************************************************
DEFINE CLASS SecondClass AS FirstClass
*  
*****************************************************
    Property6 = 6666 && Добавим свойств
    Property7 = 7777 

    PROCEDURE MyMethod         
         ? "Код из SecondClass.MyMethod"    
         ? This.Property6  && Это новое св-во
         ? This.Property5  &&  А это - доставшееся по наследству
         DODEFAULT()  && Вызов кода унаследованного метода      
    ENDPROC    
 
ENDDEFINE



*****************************************************
DEFINE CLASS ThirdClass AS SecondClass
*  
*****************************************************

    Property8 = 8888   && Еще одно свойство добавим

    PROCEDURE MyMethod         
         ? "Код из ThirdClass.MyMethod"    
         ? This.Property8  && Это новое св-во
         ? This.Property7  && А это - доставшееся по наследству
         DODEFAULT()    && Вызов кода унаследованного метода    
    ENDPROC    

ENDDEFINE

Результаты вывода на экран:
Код из ThirdClass.MyMethod  
      8888
      7777
Код из SecondClass.MyMethod    
      6666
      5555
Код из FirstClass.MyMethod  
      1111
2 июл 04, 17:48    [781419]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
IgorM
Member

Откуда: Тула - Москва, транзит
Сообщений: 633
Ув. Guest_333, честно говоря, мне кажется Вы не очень знаете как используется наследование в VB/VBA, потому что в противном случае, Вы бы в MyMethod последнего класса написали бы

         ? This.Property8  && Это новое св-во
         ? This.Property1  && А это - доставшееся по наследству

(смею предполагать, что в VFP это возможно). Это, конечно, не привело бы к невозможности написания аналогичного функционала на VB/VBA, но, по понятным причинам, увеличило размер кода и потребовало аккуратности при "наследовании интерфейса". Для Вашего же примера, реализация будет такая:

Class1
Public Property1 As Long
Public Property2 As Long
Public Property3 As Long
Public Property4 As Long
Public Property5 As Long

Public Sub MyMethod()
    Debug.Print "Код из FirstClass.MyMethod"
    Debug.Print Me.Property1
End Sub

Private Sub Class_Initialize()
    Property1 = 1111
    Property2 = 2222
    Property3 = 3333
    Property4 = 4444
    Property5 = 5555
End Sub

Class2
Public Property6 As Long
Public Property7 As Long

Private cls As New Class1

Public Sub MyMethod()
    Debug.Print "Код из SecondClass.MyMethod"
    Debug.Print Me.Property6
    Debug.Print cls.Property5
    cls.MyMethod
End Sub

Private Sub Class_Initialize()
    Property6 = 6666
    Property7 = 7777
End Sub

Class3
Public Property8 As Long

Private cls As New Class2

Public Sub MyMethod()
    Debug.Print "Код из ThirdClass.MyMethod"
    Debug.Print Me.Property8
    Debug.Print cls.Property7
    cls.MyMethod
End Sub

Private Sub Class_Initialize()
    Property8 = 8888
End Sub

И, наконец, вызов:
    Dim cls3 As New Class3
    cls3.MyMethod

Результат:
Код из ThirdClass.MyMethod
 8888 
 7777 
Код из SecondClass.MyMethod
 6666 
 5555 
Код из FirstClass.MyMethod
 1111

Вы позволите не приводить код, который требуется при "наследовании интерфейса", для доступа к Property1 из Class3?

Guest_333
Если ты этого не сможешь, то дальнейшее обсуждение этого вопроса я считаю бессмысленным. Наследование (пусть даже только наследование интерфейса как в VB), ограниченное всего одним уровнем иерархии, для меня лично серьезным инструментом, который можно было бы использовать в работе, не является

Не хотите - не используйте, можете даже других отговаривать, но качество аргументации и знание предмета должно быть все же повыше.
3 июл 04, 00:05    [781905]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
йцук
Guest
Они такие тупые...

Это, разумеется, относится не к IgorM :)
4 июл 04, 02:41    [782861]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Говоря про наследование, я имел ввиду впервую очередь наследование форм и визуальных обьектов (насколько я помню, невизуальные классы можно и на VBA катать). Чтобы предупредить вопрос специалистов по Access "А зачем оно нужно, ни разу не пригодилось" (кстати стандартный вопрос специалиста на заявление по отсутствию какой то фичи в его продукте), я поясню:
Например, мы делаем MDI приложение. Пользуясь наследованием создадим такую иерархию на PowerBuilder:
Window (базовый предок окон)
-- w_Child (базовое дочернее окно)
-- w_Sprav (базовое окно для просмотра и изменения справочников)
-- w_Sprav_1 (Справочник 1)
-- w_Sprav_2 (Справочник 2)
-- w_Data (базовое окно для просмотра и изменения данных)
-- w_Data_1 (Данные 1)
-- w_Data_2 (Данные 2)
-- w_Report (базовое окно для просмотра отчетов)
-- w_Report_1 (Отчет 1)
Все базовые окна имеют общие для их потомков свойства, методы и события, что означает централизованное управление кодом потомков, например базовое окно w_Sprav уже содержит в себе нужные визуальные компоненты, код по отображению/изменению/сохранению/печати информации справочника и необходимые меню и клавишы быстрого доступа. Чтобы сделать справочник - остается только от него наследоваться, указать с каким DataWindow справочник будет работать и выставить для достижения нужной функциональности свойства, определенные в w_Sprav (например, в отличие от Delphi в PB нет необходимости регистрировать в IDE компоненты, чтобы их свойства можно было изменять в Object Inspector - в PB свойства предка автоматически показываются в Окне Свойств наследуемого обьекта). Ну и если справочник содержит в себе дополнительную логику - нужно написать код в нужных событиях. Все тоже самое касается меню, стандартных контролсов, составных визуальных и т.д. Как видите, говоря о наследовании, я впервую очередь имел ввиду построение иерархий визуальных компонент для построения интерфейсных решений, а не бизнес-логики. В Access, в отличие от PB, к сожалению то же наследование форм не возможно, так как в нем форма напрямую завязана с данными, а в PB DataWindow хранятся как обычные описания в проекте, на формы ложаться DataWindow Control, которые и занимаются визуальным представлениям DataWindow и которые тоже удобно наследовать для расширения например, функциональности гридов или отчетов.
5 июл 04, 07:59    [783428]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
IgorM
Member

Откуда: Тула - Москва, транзит
Сообщений: 633
ASCRUS
Говоря про наследование, я имел ввиду впервую очередь наследование форм и визуальных обьектов (насколько я помню, невизуальные классы можно и на VBA катать). Чтобы предупредить вопрос специалистов по Access "А зачем оно нужно, ни разу не пригодилось"

Опять двадцать пять... :)

ASCRUS
В Access, в отличие от PB, к сожалению то же наследование форм не возможно,...

Наследование форм возможно, т.к. каждая форма - это класс, унаследованный от абстрактного класса Form. Далее, к списку радительских свойств, методов и событий можно добавить свои, можно создать своего наследника любой формы и т.д.

ASCRUS
...так как в нем форма напрямую завязана с данными, ...

А что имеется в виду под прямой завязкой?
5 июл 04, 10:48    [783808]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
йцук
Guest
ASCRUS, ты меня поражаешь
Неужели ты думаешь, что, раз уж нету в VB наследования реализации вообще и наследования визуальных объектов в частности, то разработчики вынуждены десяток одинаковых справочников делать методом Copy-Paste? И создавать десяток одинаковых менюшек для десяти одинаковых справочников? Вот уж действительно, как люди раньше жили?

Стандартную функциональность для гипотетических справочников - прописываешь в отдельный класс, который привязывается к форме в момент ее загрузки, и дальше уже сам ловит все интересующие его события (от формы, ее контролов, ассоциированных с ней менюшек и тулбаров, и т.п.) и выполняет всю нужную работу. При необходимости "тонкой" настройки работы этого класса - пусть он в ключевые моменты события выкидывает, а уж нестандартный справочник их будет ловить и обрабатывать (помимо того, что остается возможность обработки тех же самых событий формы, контролов и т.д.)
Стандартные "визуальные" блоки - оформи в виде подформочки (а-ля ActiveX) и втыкай единым куском в любой справочник. Хоть с кодом, хоть без кода, хоть с возможностью переопределения работы, хоть без такой возможности.

Разумеется это все - "наследование для бедных".
Как и в случае с наследованием реализации "невизуальных" объектов - для реализации чуждых VB идей требуется написание дополнительного кода. Для больших (особенно плохо спроектированных) систем - действительно становится не особо комфортно.
Но это не есть что-то принципиально нереализуемое.
Например, сделать на VB полноценную многопоточность (а-ля Win32) - невозможно. Хоть пиши код, хоть не пиши код, не дружит VB с многопоточностью.
А отсутствие наследования реализации обходится достаточно легко - при наличии головы на плечах и отсутсвии привычки писать сто производных классов для ста одинаковых кнопок "Закрыть".
5 июл 04, 10:51    [783822]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
ASCRUS, ты меня поражаешь
Неужели ты думаешь, что, раз уж нету в VB наследования реализации вообще и наследования визуальных объектов в частности, то разработчики вынуждены десяток одинаковых справочников делать методом Copy-Paste? И создавать десяток одинаковых менюшек для десяти одинаковых справочников? Вот уж действительно, как люди раньше жили?

Да никто и не спорит, что можно спрограммировать что угодно и как угодно, причем при достаточных знаниях и квалификации все это будет выглядеть красиво и удобно. Но есть такой ньюанс - где то мне придеться попотеть, пописать больше кода, а значит поисправлять больше ошибок, а где то мне достаточно один раз написать централизованное решение, отладить его и больше о нем не думать. А в крупных проектах, где работает команда вообще желательно построить иерархию решений, чтобы существовали готовые стандартные решения, от которых просто нужно наследоваться и не помнить, что, где и как нужно вызывать и в какой последовательности, а главное чтобы я, как руководитель проекта был уверен, что код командой пишется быстро, без ошибок и собственных "изобретений", причем однотипно для всех разрабатываемых проектов, что гарантирует легкость их сопровождения и взаимозаменяемость в команде.

P.S. Рассуждения вроде я вел о Access, про VB ничего сказать не могу, так как видел, но не работал. Но насколько я понимаю Access и VB в качестве клиентов - это все таки немножко разные вещи ?
5 июл 04, 11:02    [783864]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
SSY
Member

Откуда: Москва
Сообщений: 198
IgorM
Наследование форм возможно, т.к. каждая форма - это класс, унаследованный от абстрактного класса Form. Далее, к списку радительских свойств, методов и событий можно добавить свои, можно создать своего наследника любой формы и т.д.

Опаньки... А вот тут, если можно, поподробнее: в Аксесс появилось наследование форм!?

йцук
Стандартную функциональность для гипотетических справочников - прописываешь в отдельный класс, который привязывается к форме в момент ее загрузки, и дальше уже сам ловит все интересующие его события (от формы, ее контролов, ассоциированных с ней менюшек и тулбаров, и т.п.) и выполняет всю нужную работу.

Только не надо путать теплое с мягким (С). With Events - хорошая "заплатка", но это не наследование, то есть совсем не то, что имел ввиду ASCRUS.
5 июл 04, 11:31    [783966]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
IgorM
Member

Откуда: Тула - Москва, транзит
Сообщений: 633
SSY
Опаньки... А вот тут, если можно, поподробнее: в Аксесс появилось наследование форм!?

Это то, что ты ниже называешь "теплым" (или наоборот "мягким").

SSY
Только не надо путать теплое с мягким (С). With Events - хорошая "заплатка", но это не наследование, то есть совсем не то, что имел ввиду ASCRUS.

Тогда для непонятливых подробнее объясни, что имел в виду ASCRUS? Что ожидается от наследника формы?
VBA, конечно, не настоящий ОО язык, но "наследование для бедных" ((с) йцук) в нём присутствует.

В качестве примера: я реализовал дерево классов, которое обеспечивает функционал размещения и выравнивания объектов на форме (свойство Align в Delphi и Builder или Dock в .NET), включая сплиттеры, фреймы (панели) и т.п. Там есть базовый класс TControl, который умеет отрисоваться в нужных координатах родителя, установить для себя границы изменения размеров и т.д. И есть его наследники (TFrame, TTabControl, TSplitter и т.д.), которые расширяют функционал базового класса. И есть класс TForm, который обеспечивает всё взаимодействие. Теперь я просто кладу на форму контролы, в tag'ах пишу нужные свойства и форма у меня выравнивается без единой дополнительной строчки кода. Пример можно посмотреть здесь Это, кстати, было сделано в A'97, и поэтому не используется такая фича старших версий, как генерация собственных событий...

Всё вышеизложенное не объявление VBA настоящим объектно-ориентированным языком, а просто пример его возможностей, которые отрицаются в вышестоящих постах.
5 июл 04, 12:35    [784268]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
SSY
Member

Откуда: Москва
Сообщений: 198
IgorM
Тогда для непонятливых подробнее объясни, что имел в виду ASCRUS? Что ожидается от наследника формы?
VBA, конечно, не настоящий ОО язык, но "наследование для бедных" ((с) йцук) в нём присутствует.

Я имел ввиду, что "with events" метод позволяет обрабатывать только то, что уже есть на форме, к которой он "присосался". Ну, например (очень плоский и примитивный), если на все формы надо кинуть дополнительную кнопку, то надо добавлять именно в каждую из них, а не только в предка, от которого наследуются эти формы.

На самом деле, как я уже раньше отмечал, именно наследование форм не так уж и нужно в Аксессе и большинство проблем, связанных с перенастройкой внешнего вида и поведения большого числа форм, можно так или иначе обойти, в том числе и таким сложным и нетривиальным путем, как предложил Игорь. Проблема в том, что это не очень-то удобно и может иметь неприятные побочные эффекты, однако хватит уже ругать Аксесс :) Для этого есть другие ветки в этом форуме! :)
5 июл 04, 13:28    [784502]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
йцук
Guest
2 SSY
With Events - хорошая "заплатка", но это не наследование, то есть совсем не то, что имел ввиду ASCRUS

А я говорил, что это наследование? Да я тут весь топик твержу о том, что в VB нет наследования в общепринятом смысле, но это не особо мешает (хотя с ним было бы лучше)

ASCRUS предлагает стандартную функциональность выносить в базовые классы/формы, наследовать от базовых классов/форм, для достижения требуемой функциональности выставлять какие-то св-ва, при необходимости дописать какой-то код. Объекты взаимодействуют между собой через св-ва, методы и события. Ну и правильно, ну и отлично!
Если такой возможности нет (классическое наследие отсутствует) - то выносишь всю эту стандартную функциональность в обособленные классы/формы, включаешь эти обособленные классы/формы в свои собственные, для достижения требуемой функциональности выставляешь в своих классах/формах какие-то св-ва, при необходимости дописываешь какой-то код. Объекты взаимодействуют между собой через св-ва, методы и события.

Технические отличия в реализации этих двух схем - имеются. Принципиальных отличий - вроде как не видно. Это вам не принципиальное несходство многопоточности Win32 и COM-овской модели аппартментов.

Если бы в дельфи не было нормального ресайза для форм - то дельфицы сделали бы базовую форму, в которой был бы интеллектуальный ресайз, двигающий контролы в зависимости от их аттрибутов. И наследовали бы все от этой формы.
В VB нет нормального ресайза. И нет наследования. Поэтому пишется класс, в котором и реализуется интеллектуальный ресайз. И нужная форма с этим классом связывается.
Большая разница - базовая форма со стандартной функциональностью или отдельный класс с реализацией стандартной функциональности?

2 ASCRUS
Но насколько я понимаю Access и VB в качестве клиентов - это все таки немножко разные вещи ?

В том, что касается отсутствия наследования - абсолютно одинаковые :)

А в крупных проектах, где работает команда вообще желательно построить иерархию решений, чтобы существовали готовые стандартные решения, от которых просто нужно наследоваться и не помнить, что, где и как нужно вызывать и в какой последовательности, а главное чтобы я, как руководитель проекта был уверен, что код командой пишется быстро, без ошибок и собственных "изобретений", причем однотипно для всех разрабатываемых проектов, что гарантирует легкость их сопровождения и взаимозаменяемость в команде.

Хорошие аргументы. Туше.

Однако кто вам сказал, что аксес вообще пригоден для крупных проектов и командной разработки? Да он с SourceSafe'ом до сих пор подружиться не может :)
5 июл 04, 13:34    [784518]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
йцук
Guest
SSY
Ну, например (очень плоский и примитивный), если на все формы надо кинуть дополнительную кнопку, то надо добавлять именно в каждую из них, а не только в предка, от которого наследуются эти формы.

Ну вынесите вы стандартные, повторяющиеся группы объектов в отдельные повторно используемые блоки.
То, что приводится в качестве аргументов сторонниками классического ООП - не выдерживает критики даже с точки зрения обычного процедурного программирования.
Не было бы у вас классов - вы бы одинаковый код методом Copy-Paste плодили???
5 июл 04, 13:37    [784528]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
Однако кто вам сказал, что аксес вообще пригоден для крупных проектов и командной разработки? Да он с SourceSafe'ом до сих пор подружиться не может :)

Ну так тема плавно из похвалы Access (и я считаю заслуженной), переросла в тему "Чего в нем не хватает для того, чтобы подрасти до инструмента для построения клиентской части в крупных проектах". Насколько я понимаю новые веяния в виде ADP в Access делались совсем не для того, чтобы работать с парой десятков таблиц, тут наоборот Jet-движок рулит. Ну а раз маздайщики сделали его тесную интеграцию с MSSQL, то почему бы спрашивается им нельзя было немножко почесать репу и расширить функциональность Access, благо им стоит только спросить, чего в нем не хватает, желающих рассказать найдется много, так как это действительно очень популярный инструмент у нас и за рубежом. Иначе весь этот ADP получается чистой воды рекламной компанией MSSQL, а не эволюцией Access (да в принципе оно так и есть, с учетом ограничения MSSQL ONLY).
5 июл 04, 13:50    [784601]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
IgorM
Member

Откуда: Тула - Москва, транзит
Сообщений: 633
SSY
Я имел ввиду, что "with events" метод позволяет обрабатывать только то, что уже есть на форме, к которой он "присосался". Ну, например (очень плоский и примитивный), если на все формы надо кинуть дополнительную кнопку, то надо добавлять именно в каждую из них, а не только в предка, от которого наследуются эти формы.

Предок для каждой формы Access - голая абстрактная форма, в которую, действительно, добавить ничего нельзя. Но если ты сделал три разных класса, на основе конкретной формы (например, для реализации различного функционала), то можно добавить кнопку на базовую форму, и она понятно будет работать при создании любого из классов наследников. Но это так, к слову. :)

ASCRUS
Ну а раз маздайщики сделали его тесную интеграцию с MSSQL, то почему бы спрашивается им нельзя было немножко почесать репу и расширить функциональность Access,

Тогда уже это бы не Access получился, а, например, VB.NET.
5 июл 04, 14:25    [784738]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
SSY
Member

Откуда: Москва
Сообщений: 198
йцук
Это вам не принципиальное несходство многопоточности Win32 и COM-овской модели аппартментов.

Мощно задвинул, внушает. (С)

йцук
В VB нет нормального ресайза. И нет наследования. Поэтому пишется класс, в котором и реализуется интеллектуальный ресайз. И нужная форма с этим классом связывается.
Большая разница - базовая форма со стандартной функциональностью или отдельный класс с реализацией стандартной функциональности?

В данном конкретном случае разница действительно небольшая и есть множество других случаев, когда with events вполне достаточно.

йцук
Однако кто вам сказал, что аксес вообще пригоден для крупных проектов и командной разработки? Да он с SourceSafe'ом до сих пор подружиться не может :)

Это точно. Только проекты имеют наглость разростаться и становиться ой какими большими. И работать с ними норовят не 1-2, а 3-4 и более программистов. А пересесть "в процессе" на другое средство разработки зачастую просто невозможно :(

йцук
Не было бы у вас классов - вы бы одинаковый код методом Copy-Paste плодили???

Ну а как бы Вы ту-же кнопку в пару десятков форм вставляли?
5 июл 04, 14:54    [784859]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
SSY
Member

Откуда: Москва
Сообщений: 198
IgorM
Предок для каждой формы Access - голая абстрактная форма, в которую, действительно, добавить ничего нельзя. Но если ты сделал три разных класса, на основе конкретной формы (например, для реализации различного функционала), то можно добавить кнопку на базовую форму, и она понятно будет работать при создании любого из классов наследников. Но это так, к слову. :)

Конечно будет: форма-то одна и та же, пусть даже и в нескольких экземплярах :)
5 июл 04, 15:09    [784921]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
йцук
Guest
В данном конкретном случае разница действительно небольшая и есть множество других случаев, когда with events вполне достаточно.

Да при чем здесь WithEvents?
Объекты как-то между собой взаимодействуют. Кто-то вызывает что-то. Пользовательские действия (например) действительно удобно автоматически перехватывать в классе, реализующем базовую функциональность, вместо того, чтобы перехватывать их в "дочерней" форме и вручную передавать их в "базовый" класс.
Так же удобно выбрасывать свои события из "базового" класса - для того, чтобы иметь возможность тонкой настройки базовой функциональности.
Не нужно все это - да и хрен бы с ними, с событиями. Одними пропертями и методами получится обойтись - вперед. Смысл от этого не меняется. Вместо базовой формы со стандартной функциональностью и наследования от нее - выделенный объект с той же самой функциональностю и его использование.

Только проекты имеют наглость разростаться и становиться ой какими большими. И работать с ними норовят не 1-2, а 3-4 и более программистов. А пересесть "в процессе" на другое средство разработки зачастую просто невозможно :(

Имхо аксес вполне подходит для максимально быстрого стартапа. За месяц первоначальной работы и еще месяц попутных переделок создать систему, которая удовлетворит пользователей на год-два, самому в течении этого года-двух начать (и, если повезет, то и закончить) "правильную" разработку того же самого на каком-нибудь дотнете (к примеру)

Ну а как бы Вы ту-же кнопку в пару десятков форм вставляли?

А как бы вы вставляли одни и те же пять строчек кода в пару десятков (условно одинаковых) функций?
Головой надо думать. Причем желательно до того, как умудрились насоздавать сотню полуодинаковых, полуразных однотипных форм :)
А то получается, что кричим о необходимости рисовать красивые схемы классов, делать супер-пупер наследование, заниматься проектированием системы, большая комманда программистов, опупенно большой проект... И вдруг на нас как снег на голову сваливается необходимость модифицировать двадцать форм, которые почему-то (совершенно случайно) оказались одинаковыми по сути своей справочниками :)
5 июл 04, 15:14    [784939]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
SSY
Member

Откуда: Москва
Сообщений: 198
йцук
Да при чем здесь WithEvents?

Я вытащил на свет With Events, когда тут заговорили о возможности что-то унаследовать от формы :)
Ну, так скажем, это единственный способ "прицепиться" к уже имеющимся формам и дать им дополнительную функциональность "малой кровью", например, я так добавлял логирование действий пользователей в унаследованную систему. К ООП это действительно не относится.

йцук
Головой надо думать. Причем желательно до того, как умудрились насоздавать сотню полуодинаковых, полуразных однотипных форм :)
А то получается, что кричим о необходимости рисовать красивые схемы классов, делать супер-пупер наследование, заниматься проектированием системы, большая комманда программистов, опупенно большой проект... И вдруг на нас как снег на голову сваливается необходимость модифицировать двадцать форм, которые почему-то (совершенно случайно) оказались одинаковыми по сути своей справочниками :)

Да речь не об этом... Может пример с кнопкой - не самый удачный, но я говорю о принципиальной возможности централизованно менять внешний вид и поведение форм и контролов, а главное об удобстве этого. Ведь наперед уж совсем всего не продумаешь, как красиво схемы не рисуй :)
5 июл 04, 16:16    [785151]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
Guest_333
Guest
IgorM

OK. Метод MyMethod класса Class3
    Debug.Print Me.Property8
    Debug.Print Me.Property1
Как будет тут? Как будет это работать?

* Могу ли я написать (в Вашем варианте кода, в последней строке самого вызова):
MsgBox Str(cls3.Property1)
Нет? Тогда какое же это наследование?
* Если я объявлю в Class1 новую переменную Property0 - появится ли она автоматом в Class3? (без_моего_вмешательства_руками в описание классов Class2 и Class3). Нет? Тогда какое же это наследование?
* Если я создам в Class1 новый метод MyMethod0 - появится ли он автоматом Class3? Нет? Тогда какое же это наследование?

Для достижения всего этого извраты в описании интерфейсов руками делать надо? Тогда какое же это наследование?
IgorM

         ? This.Property8  && Это новое св-во
         ? This.Property1  && А это - доставшееся по наследству


(смею предполагать, что в VFP это возможно).

Да, это возможно. И, само собой, не только "This" (что является прямым аналогом "Me" в VB), но и извне кода класса:
oThirdClass = CREATEOBJECT("ThirdClass")
oThirdClass.MyMethod()  
MessageBox(oThirdClass.Property1)

IgorM
И есть класс TForm, который обеспечивает всё взаимодействие. Теперь я просто кладу на форму контролы, в tag'ах пишу нужные свойства и форма у меня выравнивается без единой дополнительной строчки кода.

Ну вот она вся мощь наследования в VB во всей своей красе. Использование Tag вместо нормального субклассирования контролов и добавления нужных свойств субклассам. Что Вы будете делать, когда придется еще больше навернуть обработку и придется в контролах еще что-либо набивать на этапе разработки? Какие св-ва базовых текстбоксов использовать? Ведь Tag уже занят!

IgorM
Всё вышеизложенное не объявление VBA настоящим объектно-ориентированным языком, а просто пример его возможностей, которые отрицаются в вышестоящих постах.

Это не "возможности", сорри, а обходные пути - от бедности

IgorM
Предок для каждой формы Access - голая абстрактная форма, в которую, действительно, добавить ничего нельзя. Но если ты сделал три разных класса, на основе конкретной формы (например, для реализации различного функционала), то можно добавить кнопку на базовую форму, и она понятно будет работать при создании любого из классов наследников. Но это так, к слову. :)

Покажите, пожалуйста какие кнопки жать, чтобы сие счастье поиметь



йцук


йцук
А я говорил, что это наследование? Да я тут весь топик твержу о том, что в VB нет наследования в общепринятом смысле, но это не особо мешает (хотя с ним было бы лучше)

От оно как... да уж.. не мешает. Ну тебе может и не мешает, ты же гений

йцук
В VB нет нормального ресайза. И нет наследования. Поэтому пишется класс, в котором и реализуется интеллектуальный ресайз. И нужная форма с этим классом связывается.

Как связывается? С каждой формой через Copy/Paste? А если я этот класс подменить захочу? У меня 120 форм. Расскажи последовательность действий - как я это сделаю? Всем за раз как подменить?

йцук
Большая разница - базовая форма со стандартной функциональностью или отдельный класс с реализацией стандартной функциональности?

При чем здесь это? Можно класс положить на форму и объявить в свою очередь эту форму саму классом - и от нее уже создавать новые формы. Где тут, покажи мне, разница в подходах? Форма классом всё равно является, хотя функциональность я добавил по-бейсиковски

йцук
Однако кто вам сказал, что аксес вообще пригоден для крупных проектов и командной разработки

Ну так давайте его и спозиционируем как продукт для менеджера (двух-трех-отдела). Ведь наверное не зря же он в MS Office, а не в MS Visual Studio входит, наряду с другими навороченными средствами разработки как Ёхель и Ворд :) ?

йцук
Ну вынесите вы стандартные, повторяющиеся группы объектов в отдельные повторно используемые блоки.

Разверни свою мысль поподробнее. Ты о чем? В нормальной ситуации это заносится в описание родителя. Все остальные этот код/объекты получают по-умолчанию! Какие блоки в черту?

йцук
Не было бы у вас классов - вы бы одинаковый код методом Copy-Paste плодили???

Да что ты постоянно былое вспоминаешь? Может на лошадей вместо автомобилей еще пересядем?
5 июл 04, 16:33    [785213]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
Guest_333
Guest
Guest_333
Если я объявлю в Class1 новую переменную Property0 -

Сорри. Описка. Новое свойство, конечно же, в виду имеется
5 июл 04, 16:55    [785314]     Ответить | Цитировать Сообщить модератору
 Re: Д а в а й т е п о х в а л и м M i c r o s o f t A c c e s s .  [new]
IgorM
Member

Откуда: Тула - Москва, транзит
Сообщений: 633
Guest_333
Нет? Тогда какое же это наследование?

Самое обычное "interface inheritance" - наследование интерфейса.

Guest_333
Если я объявлю в Class1 новую переменную Property0 - появится ли она автоматом в Class3? (без_моего_вмешательства_руками в описание классов Class2 и Class3). Нет? Тогда какое же это наследование?

Нет, не появится. Вот с этого и надо было начинать. Я же говорил, тщательнее надо вести дискуссию... Ведь сначала было просто:

Guest_333
Чем выпендреживаться чужими цитатами и орать как кастрированному, лучше сделай мне на VB/VBA трехуровневую иерархию наследования с помощью связки "наследование интерфейса + приватный экземпляр родителя" (aka Implements + Dim xxx AS ParentClass)


Ответьте, пожалуйста, я Вам это сделал?
Далее... Вам уже много раз написали, что VBA поддерживает не наследование реализации, а наследование интерфейса. От того, что я буду вынужден написать дополнительный код, с точки зрения внешнего приложения результат не изменится.

Guest_333
Ну вот она вся мощь наследования в VB во всей своей красе.

Так, значит наследование все же есть...

Guest_333
Использование Tag вместо нормального субклассирования контролов и добавления нужных свойств субклассам. Что Вы будете делать, когда придется еще больше навернуть обработку и придется в контролах еще что-либо набивать на этапе разработки? Какие св-ва базовых текстбоксов использовать? Ведь Tag уже занят!

В Tag'е можно хранить любые другие свойства, они там идут обычным списком. А сам tag был выбран для того, что бы эти свойства прописывать визуально в конструкторе, т.к. наследника контрола на форму не положить, а ручками в коде устанавливать свойства не хочется.

Все остальные рассуждения как бы и не очень по теме. Я не позиционировал Access, как средство замены Delphi, VC, .NET и т.п. поэтому спорить по этому поводу не буду.

Кстати, хотите почитать, что поэтому поводу думает MS?

MSDN - Understanding Interface-based Programming
The Two Faces of Inheritance
Inheritance is an objected-oriented concept that models an "IS A" relationship between two entities. So far, this article has used the term implementation inheritance instead of the more generic term inheritance because extending a super class with a sub class is only one way to leverage an "IS A" relationship. When a class implements an interface, it also takes advantage of an "IS A" relationship. For instance, if a class CBeagle implements the interface IDog, it is correct to say that a beagle "IS A" dog. You can use a CBeagle object in any situation in which an IDog-compatible object is required.

Interface-based programming is founded on a second form of inheritance known as interface inheritance. This means that inheritance does not require the reuse of method implementations. Instead, the only true requirement for inheritance is that a sub class instance be compatible with the base type that is being inherited. The base type that is inherited can be either a class or a user-defined interface. In either situation, you can use the base-type references to communicate with objects of many different types. This allows both forms of inheritance to achieve polymorphism.

Both forms of inheritance offer polymorphism, yet they differ greatly when it comes to their use of encapsulation. Implementation inheritance is based on white-box reuse. It allows a sub class to know intimate details of the classes it extends. This allows a sub class to experience implicit reuse of a super class's method implementation and data properties. Implementation inheritance is far more powerful than interface inheritance in terms of reusing state and behavior. However, this reuse comes with a cost. The loss of encapsulation in white-box reuse limits its scalability in large designs.

As the term black-box reuse suggests, interface inheritance enforces the concepts of encapsulation. Strict adherence to the encapsulation of implementation details within classes allows for more scalable application designs. Interface-based programming solves many of the problems associated with white-box reuse. However, to appreciate this style of programming, you must accept the fact that the benefits are greater than the costs. This is a struggle for many programmers.

When a class implements an interface, it takes on the obligation to provide set methods. Sub class authors must write additional code whenever they decide to implement an interface. When you compare this to implementation inheritance, it seems like much more work. When you inherit from a class most of your work is already done, but when you inherit from an interface your work has just begun. At first glance, implementation inheritance looks and smells like a cheeseburger, while interface inheritance looks like a bowl of steamed broccoli. You have to get beyond the desire to have the cheeseburger to reach a higher level of interface awareness. The key advantage of interface inheritance over implementation inheritance is that it is not vulnerable to the tight coupling that compromises the extensibility of an application.

Про фастфуд прикольно написано...
5 июл 04, 18:17    [785605]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 [8] 9   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить