>я бы сказал, что это намеренное издевательство :)
Ради интереса, можно глянуть здесь примеры «А+В» для различных ЯП, если интересно A+B.
>Нет определяющего общий стиль фреймворка и это не так плохо, хотя думать на проблемой выбора своего стиля надо больше.
Для С++ это всегда было большой проблемой, если используешь несколько сторонних библиотек в проекте, то гарантированна головная боль по согласованию стилей. Но больше всего мне не нравятся различные подходы к управлению памятью почти в каждой библиотеке, написанной на С++.
>Честно тебе скажу, второй твой пример с ООП не имеет ничего общего, как впрочем и первый
Смысл был не в том, чтобы писать какую-то навороченную архитектуру, а в том, что показать как эти архитектуры применяются для решения простых задач:
str = new StringTokenizer(in.readLine());
int a = Integer.parseInt(str.nextToken());
Слишком сурово и расточительно для элементарных задач плодить объекты классов, лишь только для того, чтобы они были, т.е. не стоит плодить лишних сущностей там, где их не должно быть.
— Например реализовать систему делегатов и событий для С++ не составляет большого труда, благо получить адрес объекта и адрес метода в С++ можно без проблем и на уровне библиотеки это реализуется в виде 200-300 строк кода (если без особых наворотов)
— По поводу свойств в С++ тоже не все однозначно, например Рихтер в последней книге CLR via C# утверждает что свойства вообще лучше не использовать и их не следовало включать в C#, так не ужели тогда есть эта необходимость в С++.
— И по поводу ООП. Думаю, иногда лучше просто решить поставленную задачу, а не строить «космолет», если вы не пишите библиотек для дальнейшей дистрибуции, то в ряде случаев ООП больше головная боль, чем полезный инструмент. Например, нам надо сложить два числа и результат вывести в терминал.
На С/C++:
#include <stdio.h>
int main()
{
int a, b;
scanf("%i %i", &a, &b);
printf("%i\n", a + b);
return 0;
}
На Java:
import java.io.*;
import java.util.*;
class solver
{
public static void main(String[] args) throws IOException
{
BufferedReader in = new BufferedReader(new InputStreamReader(System.in));
PrintWriter out = new PrintWriter(new OutputStreamWriter(System.out));
StringTokenizer str;
str = new StringTokenizer(in.readLine());
int a = Integer.parseInt(str.nextToken());
str = new StringTokenizer(in.readLine());
int b = Integer.parseInt(str.nextToken());
out.println(a + b);
out.flush();
}
}
Какой случай вам больше нравится? Где ООП или где СП? А где код работает быстрее?
>В нашей стране долго и упорно доказывали школьникам, что учится не обязательно, нужно иметь диплом.
Вот и пишут наши депутаты диктанты по русскому языку на «2» бала.
Думаю все же «Базы данных». Хотя, когда я учился, то на дисциплине «Базы данных» все юзали Access, можно было и другую СУБД выбрать если хотелось, правда для многих (а точнее для всех) это была дисциплина — «можешь дать мне лабухи распечатать, а то завтра сдавать надо», вопросов языка SQL вообще никто не касался — для многих это был бы взрыв мозга (считай «допса»), а вот мышкой базу нарисовать по методичке еще куда ни шло. Ну вобщем все мы знаем, что такое преподавание it-дисциплин в большинстве наших вузов.
Тоже с такой проблемой сталкивался. ИМХО от БД — хранение и масштабируемость, а бизнес-логика — в ORM. Бизнес-логика в ХП — зло: долго писать, неудобно отлаживать, сложно и опасно изменять (особенно если бд активно используется).
Нормальный антивирус. Недавно случайно обнаружил незащищенную Wi-Fi точку (кто-то забыл пароль поставить), после лазания по чужому компу MSE оперативно нашел достаточно новые трояны и совсем «нехороший» Kido )
Про ActiveX не спорю, но COM вполне неплохая вещь — по крайней мере позволяет использовать объектный API независимо от языка программирования, а это намного удобней в сравнении с процедурными API, для которых приходиться писать объектный костыль (вспоминая Win32).
Ради интереса, можно глянуть здесь примеры «А+В» для различных ЯП, если интересно A+B.
>Нет определяющего общий стиль фреймворка и это не так плохо, хотя думать на проблемой выбора своего стиля надо больше.
Для С++ это всегда было большой проблемой, если используешь несколько сторонних библиотек в проекте, то гарантированна головная боль по согласованию стилей. Но больше всего мне не нравятся различные подходы к управлению памятью почти в каждой библиотеке, написанной на С++.
Ну собственно никакого изврата не вижу. вот простейшая сигнатура делегата:
template class Delegate
{
private:
struct T { };
typedef void (T::*PMETHOD) (TArg);
protected:
T* m_pObject;
PMETHOD m_pMethod;
public:
Delegate();
template Delegate(TClass* pObject, void (TClass::*pMethod) (TArg));
Delegate(const Delegate& delegate);
~Delegate();
Delegate& operator = (const Delegate& delegate);
bool operator == (const Delegate& delegate);
bool operator != (const Delegate& delegate);
void operator () (TArg arg);
void Invoke(TArg arg);
bool IsNullOrEmpty();
};
Чего уж такого ужасного, не понятно.
>Честно тебе скажу, второй твой пример с ООП не имеет ничего общего, как впрочем и первый
Смысл был не в том, чтобы писать какую-то навороченную архитектуру, а в том, что показать как эти архитектуры применяются для решения простых задач:
str = new StringTokenizer(in.readLine());
int a = Integer.parseInt(str.nextToken());
Слишком сурово и расточительно для элементарных задач плодить объекты классов, лишь только для того, чтобы они были, т.е. не стоит плодить лишних сущностей там, где их не должно быть.
— Например реализовать систему делегатов и событий для С++ не составляет большого труда, благо получить адрес объекта и адрес метода в С++ можно без проблем и на уровне библиотеки это реализуется в виде 200-300 строк кода (если без особых наворотов)
— По поводу свойств в С++ тоже не все однозначно, например Рихтер в последней книге CLR via C# утверждает что свойства вообще лучше не использовать и их не следовало включать в C#, так не ужели тогда есть эта необходимость в С++.
— И по поводу ООП. Думаю, иногда лучше просто решить поставленную задачу, а не строить «космолет», если вы не пишите библиотек для дальнейшей дистрибуции, то в ряде случаев ООП больше головная боль, чем полезный инструмент. Например, нам надо сложить два числа и результат вывести в терминал.
На С/C++:
#include <stdio.h>
int main()
{
int a, b;
scanf("%i %i", &a, &b);
printf("%i\n", a + b);
return 0;
}
На Java:
import java.io.*;
import java.util.*;
class solver
{
public static void main(String[] args) throws IOException
{
BufferedReader in = new BufferedReader(new InputStreamReader(System.in));
PrintWriter out = new PrintWriter(new OutputStreamWriter(System.out));
StringTokenizer str;
str = new StringTokenizer(in.readLine());
int a = Integer.parseInt(str.nextToken());
str = new StringTokenizer(in.readLine());
int b = Integer.parseInt(str.nextToken());
out.println(a + b);
out.flush();
}
}
Какой случай вам больше нравится? Где ООП или где СП? А где код работает быстрее?
Вот и пишут наши депутаты диктанты по русскому языку на «2» бала.