none
Классы - использование RRS feed

  • Вопрос

  • Добрый день.

    Подскажите по такому вопросу. Предположим, нужно создать систему автоматизации кафе. Требования - возможность лёгкой модификации, добавления новых компонентов, масштабируемость.

    Пусть сначала будет возможность заказа 10 напитков и 10 десертов.

    Когда имеет смысл делать класс здесь? Можно сделать так:

    1) Класс Напиток (Drink) и дальше от него Tea. В то же время можно так: само название напитка может быть просто свойством в классе Напиток, а отдельного класса Чай не нужно делать.

    Соответственно, можно сделать массивы по 10 элементов, при необходимости многомерные (сорта чая и названия десертов).

    ООП позволяет обеспечить масштабируемость, инкапсуляцию. Так заявляется в данном подходе.

    Можно обойтись и функциональным программированием. Т.е. мы делаем просто массивы с названиями и функции по их обработке. И нам не нужно делать класс Tea, Coffee, Gingerbread и так далее.

    Чем конкретно нам поможет ООП в этом случае (а он типичный) и стоит ли здесь обходиться без ООП?

    Кстати, при создании программы ООП нам уже предлагается в виде class Program. Однако класс Чай - пока что не догма.


    • Изменено royalpiano 16 марта 2016 г. 16:58
    16 марта 2016 г. 16:41

Ответы

  • Если речь идет о функциональности и масштабируемости, то однозначно ООП, но с подходом "Drink", "Tea" и т.д. далеко не уехать. Дело в том, что сегодня у вас напитки и десерты, а завра котлеты с мухами. Что писать новые классы? Однозначно будет путаница.

    Я считаю, что должен быть базовый класс Product, а его поля уже будут описывать, что это за продукт. То есть "категория", "подкатегория" и т.д. и т.п.

    Обычно в книгах по ООП объясняют на примере класса Transport с полями "Колеса", "Цвет", "Марка" ну и далее по смыслу. Ваши позиции хранятся в базе данных и загружаются в коллекцию классов Product, а затем с помощью методов сортировки, группировки и прочее вы получаете нужные товары и возможность работы с ними.

    Все вышесказанное на основе моего опыта и моих личных предпочтений, поэтому воспринимайте как мнение.

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


    VB.Net - WPF, UWP


    • Изменено LXGDARKEditor 17 марта 2016 г. 7:47
    • Предложено в качестве ответа Liliya Muray 17 марта 2016 г. 8:29
    • Помечено в качестве ответа LXGDARKEditor 27 марта 2016 г. 19:34
    17 марта 2016 г. 7:47
    Отвечающий

Все ответы

  • Если речь идет о функциональности и масштабируемости, то однозначно ООП, но с подходом "Drink", "Tea" и т.д. далеко не уехать. Дело в том, что сегодня у вас напитки и десерты, а завра котлеты с мухами. Что писать новые классы? Однозначно будет путаница.

    Я считаю, что должен быть базовый класс Product, а его поля уже будут описывать, что это за продукт. То есть "категория", "подкатегория" и т.д. и т.п.

    Обычно в книгах по ООП объясняют на примере класса Transport с полями "Колеса", "Цвет", "Марка" ну и далее по смыслу. Ваши позиции хранятся в базе данных и загружаются в коллекцию классов Product, а затем с помощью методов сортировки, группировки и прочее вы получаете нужные товары и возможность работы с ними.

    Все вышесказанное на основе моего опыта и моих личных предпочтений, поэтому воспринимайте как мнение.

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


    VB.Net - WPF, UWP


    • Изменено LXGDARKEditor 17 марта 2016 г. 7:47
    • Предложено в качестве ответа Liliya Muray 17 марта 2016 г. 8:29
    • Помечено в качестве ответа LXGDARKEditor 27 марта 2016 г. 19:34
    17 марта 2016 г. 7:47
    Отвечающий
  • А в базах как лучше именовать поля?

    1) Category1, Category2, Category3 и т.п.

    Тогда методы выборки и биндинга к DataTemplate будет одинаковыми.

    Или

    2) TableTea-> NameTea, CategoryTea, PriceTea,

    TableCoffee-> NameCoffee, CategotyCoffee, PriceCoffee

    Но тогда если поля в базах названы по разному, грузить разный шаблон под DataTemplate?

    А если надо отобразить в одном ListView и кофе и чай, то создавать новый класс на его основе коллекцию и к ней биндинг ?

    Какой вариант?

    А при первом варианте просто join из двух таблиц и отображаются и чай и кофе


    Может вопрос и не в тему, но где то рядом :)
    • Изменено DevingAs 19 марта 2016 г. 13:16
    19 марта 2016 г. 13:11
  • Честно говоря, не понятно, чем это действительно лучше просто массивов.

    21 марта 2016 г. 17:33
  • Честно говоря, не понятно, чем это действительно лучше просто массивов.


    Простой массив тяжело масштабировать, потом уйдете в многомерный куб.
    22 марта 2016 г. 3:58
  • К примеру, в языке PHP просто добавляем элемент как $ar[]=1;

    Вы имеете в виду, что это потребляет много ресурсов?

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

    Так вот в чём использование классов (функций/методов внутри объектов) лучше, чем если эти же функции будут написаны отдельно - снизу от объявления данных?

    Это надо воспринимать как данность или имеет доказательство? Примерчик можно?

     



    • Изменено royalpiano 26 марта 2016 г. 10:59
    26 марта 2016 г. 10:55
  • Цитата:

    Ваши позиции хранятся в базе данных и загружаются в коллекцию классов.

    Может быть, вы имели в виду в коллекцию внутри класса продукт? Collection.

    Если нет, то каких классов?


    Пресеты могут быть, я пытаюсь понять принцип.
    • Изменено royalpiano 26 марта 2016 г. 12:20
    26 марта 2016 г. 10:57
  • Это надо воспринимать как данность или имеет доказательство? Примерчик можно?

    Была у меня знакомая христианка, которая стала жить с мусульманином. Будучи очень верующей, она пошла к священнослужителю с вопросом "будет ли такой брак одобрен на небесах?". Ей ответили "нет" и тогда она задала тот же вопрос но по другому. Снова получив отрицательный ответ, она пошла к другому священнослужителю и т.д. В конечном итоге она услышала заветное благословение и именно к словам этого священника она прислушалась, хотя остальные 10 в один голос говорили "нет".

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

    Нравится вам функциональный подход, так и пишите ваш код так. Кто ж мешает то? Тем более, что когда проект будет расти и нужно будет переписывать кучу кода заново, вы все равно убедите себя, что так все равно проще и быстрее.

    Я не пытаюсь вас оскорбить, я просто призываю принять себя и не искать одобрения от людей, которых вы даже не знаете.

    Единственная проблема с которой вы можете столкнуться, так это передача проекта другому программисту. ООП не панацея, но все же стандарт в современном мире и когда кто то другой после вас захочет продолжить развивать ваш проект, стабильная икота вам обеспечена. А пока вы сами работаете над проектом, как он устроен внутри не важно, важно что бы он работал так как хочет заказчик.

    Ну и по вашему уточняющему вопросу в последнем сообщении. Я не буду на него отвечать, так как я понял, что вы знакомы с ООП очень плохо и мой ответ все равно вам ничего не даст. В любом случае, если вы все таки решитесь писать проект, так как это стали бы делать здесь сидящие, то в реализации конкретных моментов мы вам с удовольствием поможем. Разводить же халивары о базовых концепциях нет никакого желания.


    VB.Net - WPF, UWP

    26 марта 2016 г. 12:19
    Отвечающий
  • Может стоить принять себя таким и не парится?

    Поддерживаю!

    Я смотрю вы (royalpiano) пытаетесь разбираться в том, стоит или не стоит изучать классы и следовательно ООП в целом. Без применения классов можно писать программы и не плохие, работать с базами данных, если правильно их проектировать (я про нормальные формы баз данных). Код будет приемлемым...

    Но... Стоит обратить внимание, что любая среда разработки уже оперирует классами и понятиями объектов (форма, кнопка и прочее). Качественный интерфейс не построить без применения MVVM, который без знаний класса не возможен.

    Я пока с трудом осваиваю классы, но это нужно... Я начинала с Basic, Pascal, Delphi, c#... В паскале использовала структуры и динамические данные, в дельфи это уже были списки, в с# - это классы... До слов "наследование" и "полиморфизм" наверное никогда не дорасту ;-)

    Поэтому я присоединяюсь к совету LXGDARK и вам советую пишите на том, к чему есть стремление и понимание. А если вам не хватает возможностей функционального программирования, как мне в одном моем проекте, где мне пришлось интерфейс реализовывать через некое подобие MVVM, тогда изучайте классы и применяйте их. А всё и всегда пытаться решать через классы не стоит, тем более если вам это сложно понять и не лежит к ним душа...

    26 марта 2016 г. 21:30
  • Добрый день.

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

    Раз LGXDark вы написали, так почему бы не уточнить ваш пример кодом? Как раз тогда и прояснится всё.

    Вот именно тут проблемы в конкретике. Какая именно коллекция классов, почему это лучше массивов и т.п.

    Это не холивар, а техническая конкретика.

    Я отлично знаю PHP, также стал изучать C#, VB.NET. Сейчас многие работодатели пишут про ООП. Так так ли им важно, что это будет на классах или нет? А если да, то приходится их изучать. Мне в целом нравится. И тут важно понять на примерах типа простой автоматизации кафе, где бонусы.

    Вот паттерны проектирования - там уже начинается... А наследование это просто, по-моему.

    Среда разработки - это то, что нужно. Она ускоряет написание и воодушевляет.

    К примеру, простой вопрос - почему у нас есть класс Program в C#? Ведь более 1 экземпляра программы не требуется запускать (хотя вот Firefox можно открыть 2 раза в 2 вкладках). Так зачем делать целый класс объектов? Или: методы объекта - это то, что он делает или над ним делают - это важно или всё равно?

    Честно скажу, что мне захотелось большего - и получать за это достойную оплату.

    Можно делать и свои проекты. Но как я смотрю, в большинстве вакансий требуется знание .NET Framework, Classes, etc.

    P.S. Наверное, основной вопрос - это зачем нам делать шаблон объекта, а не сразу сам объект?

    С целью дальнейшей модификации программы? Или чтобы их можно было создавать в любом количестве?





    • Изменено royalpiano 27 марта 2016 г. 12:43
    27 марта 2016 г. 12:30
  • И по поводу куба - по-моему, $drinks['TEA']['BLACK']['HYLEYS'] не так уж и сложно.

    Класс в целом всё-таки близок к массиву или это принципиально другое?

    Набор полей есть, но вот это шаблон, а массив это не шаблон.

    27 марта 2016 г. 13:12
  • Мне не хотелось отвечать, потому что вы хоть и утверждаете, что разбираетесь в ООП, на деле же для вас это темный лес и каждый новый ответ породит новый уточняющий вопрос и так до бесконечности. Практически тот же халивар.

    Но я все же рискнут ответить. Заданный вами вопрос схож с задачей, что я решал для своей работы.

    На скриншоте версия 2.6. Первую версию я написал за неделю в промежутках между работой и просмотром сериалов. То есть под настроение. Каждая последующая версия создавалась либо от скуки, либо при появлении какой либо необходимости в новой функции. Занимало это день-два. Не знаю как по вашим меркам, но по моим трудозатраты на данное приложение были минимальными.

    Итак что мы имеем. Есть коллекция классов PriceItem. Список что мы видим слева собственно эту коллекцию и отображает. Но почему же классы, а не массивы? Да потому, что проект создан в WPF и использование классов тут поощряется всячески. Панель списка имеет привязку к полю основного класса AplicationClass, которое содержит коллекцию вышеупомянутых классов. Выбрав элемент списка я жму добавить и в правый список добавляется выбранный объект (экземпляр класса PriceItem). Шаблон правого списка привязывается к полям моего объекта и отображает нужные данные. То есть нажав добавить я сделал одну единственную манипуляцию - скопировал объект из общего списка услуг в список текущих. Никаких функций работы с массивами, выбора значений и подсовывания куда нужно. Все это уже сделало за меня мое проектное решение.

    Я не буду расписывать подробно весь процесс работы программы. Скажу лишь, что все ее возможности опираются на работу с объектами типа "Позиция прайса" и я могу манипулировать ими как угодно и где угодно и мне видится это в разы удобнее, чем манипулирование элементами массива.

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


    VB.Net - WPF, UWP

    27 марта 2016 г. 13:45
    Отвечающий
  • А сами эти классы вы писали сами или брали готовые в Visual Studio?

    27 марта 2016 г. 17:39
  • В 1С-Битрикс, к примеру, постоянно используются массивы - в том числе и те, где есть массив в качестве элемента. И ядро в нем на ООП. Но это к слову.
    • Изменено royalpiano 27 марта 2016 г. 17:44
    27 марта 2016 г. 17:43
  • А сами эти классы вы писали сами или брали готовые в Visual Studio?

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

    VB.Net - WPF, UWP

    27 марта 2016 г. 18:04
    Отвечающий
  • Вот именно тут проблемы в конкретике. Какая именно коллекция классов, почему это лучше массивов и т.п.

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

    Грубо говоря, я бы дала классу такое определение с точки зрения функционального программирования: Класс - это составной тип данных, который может состоять как из простых типов, так и из функций и процедур... Вот кусок кода из моего класса...

        //класс группы участников
        public class SpUser : INotifyPropertyChanged
        {
    
            public SpUser()
            {
                xDistance = 0;
            }
    //поля класса список участников
            public string _UserName { get; set; }//ник пользователя
            public double _xDistance { get; set; }//вычисленная дальность
            public string _Distance { get; set; }//текс дальности
    
    //обработка полей
    
            //имя пользователя
            public string UserName
            {
                get { return _UserName; }
                set
                {
                    _UserName = value;
                    NotifyPropertyChanged("UserName");
                }
            }
            
            //дистанция вещественная
            public double xDistance 
            {
                get { return _xDistance; }
                set
                {
                    _xDistance = value;
                    double ds = _xDistance; 
                    if (ds < 10)
                    {
                        Distance = ds.ToString("00.0") + "m";
                    }
                    else
                    {
                        if (ds < 1000)
                        {
                            Distance = ds.ToString("0") + "m";
                        }
                        else
                        {
                            if (ds < 10000)
                            {
                                Distance = (ds / 1000).ToString("00.0") + "km";
                            }
                            else
                            {
                                Distance = (ds / 1000).ToString("0") + "km";
                            }
                        }
                    }
                    NotifyPropertyChanged("xDistance");
                }
            }
    
            //текстовое значение дистанции
            public string Distance
            {
                get { return _Distance; }
                set
                {
                    _Distance = value;
                    NotifyPropertyChanged("Distance");
                }
            }
    
    
        }
    В нем отслеживается дальность до до участника, дальность хранится как в числовом виде, так и текстовом, причем текстовый формат заполняется автоматически при изменении вещественного значения. В функциональном подходе я должна была бы после изменения вещественного значения не забыть вызвать функцию преобразования в текстовое значение. А если учесть, что вещественную дальность я тоже получаю из функции изменения координат, то в моей задачи без классов мне никак... Потому что помнить каждый раз в какой последовательности вызывать функции для изменения всей цепочки данных очень утомительно и нечитабельно будет...



    • Изменено Liliya Muray 27 марта 2016 г. 18:07
    27 марта 2016 г. 18:06
  • Liliya Muray, вам спасибо, пишете понятно и дельно. А вот мой пример:

    class Chocolate {
    public $name;
    public $color;
    };

    class Tea {
    public $name;
    public $fruit;
    };
    Классы шоколад и чай. Тут 2 поля - бренд и цвет, а у чая бренд и фрукт. Можно обойтись

    ведь массивами аналогичными: $ch=array($name,$color); $tea=array($name,$fruit);

    При необходимости создать новый объект мы инициализируем массив и добавляем туда свойства.

    На этом этапе принципиальные отличия есть или они появятся когда понадобятся функции?


    • Изменено royalpiano 27 марта 2016 г. 18:46
    27 марта 2016 г. 18:45
  • В чем мораль этой истории? В том, что вы, будете мысленно или в слух оспаривать сотни доводов в пользу ООП и стоит прозвучать лишь одному в пользу функционального программирования, как вы скажете "о да, я всегда это знал".

    И вы утверждаете, что не планировали разводить халивар? Лилия дала вам четкий довод, почему в нашем понимании ООП проще, но вы продолжаете впаривать идеологию из PHP. Либо вы пытаетесь обернуть нас в свою веру, либо просто тролль.

    Хватит отнимать чужое время. Не нашли доводов в пользу ООП, не используйте. Приходится использовать? Тогда читайте книгу, что вам показали в соседнем топике.

    На этом считаю тему закрытой.


    VB.Net - WPF, UWP

    27 марта 2016 г. 19:34
    Отвечающий
  • Я уже участвовала в разработке подобной задачи. Это автоматизация центра питания. Было необходимо вести учет расхода продуктов и соблюдение норм питания по БЖУК, потом задача обрастала новыми подзадачами...

    Я бы решала эту задачу на уровне простой базы данных. Сначала бы определилась с объектами хранения, т.е. определилась бы со структурой таблиц - это исходные ингредиенты, рецепты, блюда и прочее. Организовала ввод первоначальных данных - запасы продуктов, рецепты и т.п.; алгоритмы обработки - преобразование продуктов блюда, а лишь затем решала вопросы интерфейса. Тут можно выделить два класса объектов ингредиенты и блюда, но это скорее больше два сложных типа данных, чем классы.

    Моё отношение к массивам в основном негативное. Я считаю, что их можно использовать только для хранения заранее определенного кол-ва элементов, а использование динамических массивов считаю дурным тоном в программировании, так как всегда нужно где-то помнить сколько элементов, проблемы с удалением элемента в середине или начале массива и прочее... Т.е. от массивов больше головной боли чем удовольствия. Когда изучили массивы, казалось все можно делать через них... Но у меня любовь к ним пропала сразу после изучения динамической структуры данных (Pascal), так как было удобней, решались проблемы с границами диапазонов, удалением и прочие. Это довольно сложно для понимания, по крайней мере в Паскале. Изучите такой тип данных как List<T> вам уже будет легче принять классы, а не зацикливаться на массивах.

    27 марта 2016 г. 20:05
  • Либо вы пытаетесь обернуть нас в свою веру, либо просто тролль.

    Хватит отнимать чужое время. Не нашли доводов в пользу ООП, не используйте. Приходится использовать? Тогда читайте книгу, что вам показали в соседнем топике.

    Просто человек не может понять в чем разница сложного типа данных и класса. Когда я писала программы на Дельфи я использовала сложные типы данных и листы, а классы вообще не понимала зачем они нужны и соответственно не использовала. В c# проще описать класс, чем сложный тип данных, вернее примеров с классами больше чем со сложным типом данных. А проблем автора топика, как мне кажется, в том, что он не знает чем можно заменить массивы для хранения данных.

    27 марта 2016 г. 20:30
  • Проблема не в том, что человек не понимает, а в том, что он не прикладывает к пониманию усилий. А усилия эти заключаются в чтении книг и статей. Нельзя научить человека уравнениям, пока он не познакомился со сложением и вычитанием. А судя по уточняющим вопросом, знаниями базовых вопросов тут и не пахнет.

    Я начинал с QBasic, перешел на VB6, а затем на VB.Net и только в последней появилось ООП. Помню как нашел цикл из 50 статей об ООП в VB.Net. Помню как ничего не понимал и перечитывал снова и снова, пока не понял. Полное же понимание пришло вместе с практикой. Тут же сплошная демагогия и полное не желание работать!

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


    VB.Net - WPF, UWP

    28 марта 2016 г. 6:18
    Отвечающий
  • Проблема не в том, что человек не понимает, а в том, что он не прикладывает к пониманию усилий. А усилия эти заключаются в чтении книг и статей. Нельзя научить человека уравнениям, пока он не познакомился со сложением и вычитанием. А судя по уточняющим вопросом, знаниями базовых вопросов тут и не пахнет.


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

    Хоть кто-то на форуме ему сказал: "Чувак, забей на массивы это прошлый век, переходи на списки, листы или коллекции!"? Никто ему этого не сказал, а лишь отвечают, что классы лучше чем массивы. А разве нельзя создать массив элементы которого будут объекты типа класса? И что сравнивать массивы и классы это не правильно... Это все равно что сравнивать проселочную дорогу с гоночным автомобилем. И говорить, что дорога такая отстой и прошлый век, а вот автомобиль классный и крутой... Просто, если бы автор топика задал вопрос: "На каких дорогах можно ездить на гоночном автомобиле?", то получил бы нормальный ответ...

    Простите, если что не так сказала...

    28 марта 2016 г. 8:59
  • Я еще раз приведу свой пример с изучением уравнений, до изучения базовых арифметических операций.

    Как бы Марь Ивановна не старалась бы объяснить первоклашке Вовочке, что такое уравнения и в чем их преимущество, он ничего не поймет, пока не научится складывать и вычитать.

    Цитирую: "А сами эти классы вы писали сами или брали готовые в Visual Studio?"

    Этот вопрос свидетельствует о том, что человек не просто плохо развирается в вопросе, а не разбирается в нем вообще. Это все равно, что спросить - А это вы перемалываете мясо или мясорубка?

    Пока нет базовых знаний нет смысла объяснять все остальное.

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


    VB.Net - WPF, UWP

    28 марта 2016 г. 9:51
    Отвечающий
  • Пока нет базовых знаний нет смысла объяснять все остальное.

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


    Я не поощряю разжевывание, но и посылать тоже не считаю правильным. И да, тема закрыта, а то это уже флуд получается... Если у автора топика есть вопросы - то формат форума: один вопрос - одна тема.
    28 марта 2016 г. 11:48
  • LXGDark, простите, вам не кажется, что тон слишком груб для форума? Вас никто не просил отвечать, если что-то не нравится, проходите мимо. Такое впечатление, что вы хотите сделать вид, что лучше других.

    Вы не знаете, сколько книг у меня дома лежит и что я читаю. "Впаривать идеологию" - докажите. Я очень много писал на PHP, C# же не основной язык, - поэтому вопросы насчёт классов вполне резонны. Кто-то вообще на Дельфи пишет, а при переходе на .NET что же спросить нельзя? Во всех языках такие вещи сильно отличаются.

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

    Пример был на том языке, который больше понятен. Мог бы и на C# написать. У меня есть статьи в сборниках и журналах.

    А сами эти классы вы писали сами или брали готовые в Visual Studio?"

    А вы можете написать на PHP что-то? Почему здесь нельзя использовать библиотеку классов Майкрософта C#? Классы можно или самому написать или взять готовые.

    Откуда такая грубость?


    • Изменено royalpiano 30 марта 2016 г. 16:46
    30 марта 2016 г. 16:40
  • C# я начал изучать в 2008 году. Времени не хватало на всё, но он мне понравился. Но так как основным языком был PHP, в котором ООП считается не совсем обычным, возникли такие вопросы. Стоит ли изучать основной язык дальше, в котором ООП считается не совсем традиционным, либо изучать ещё или вместо него C#.

    Насчёт 1 топик - 1 вопрос - согласен, но если тема большая, то 1 вопрос может иметь продолжение. Я так понял. Чтобы не плодить несколько веток по одной теме. Разные правила и понимание бывают.

    P.S. И да, писать можно и это будет работать - и даже делать вид, что разбираешься. А вот глубокое понимание требует того, чтобы разобраться. Зачем же тогда существуют форумы типа Stackoverflow - там миллионы программистов общаются. В книгах есть не всё, а у живого человека можно спросить...

    • Изменено royalpiano 30 марта 2016 г. 17:00
    30 марта 2016 г. 16:45
  • А сами эти классы вы писали сами или брали готовые в Visual Studio?

    Никакой грубости. Чистая констатация фактов и я это легко обосную.

    Visual Studio в принципе не содержит никаких классов. Студия это всего лишь инструмент. Мало того C# не содержит никаких классов. C# это синтаксис, логика и т.д. и по сути это то же инструмент. А откуда же классы?

    .NET Framework - платформа разработки для Windows. Именно она является источником всех готовых классов при разработке. Но и это еще не все. Набор классов зависит от подплатформы (WinForms, WPF, WinRT, WP, UWP и т.д.).

    Что в итоге? Мы берем .Net язык. Для многих это C#, для меня же VB.Net и создаем в Visual Studio проект подходящей платформы на этом языке. Например моя программа выше написана на WPF и затем используем доступные классы. Например класс Binding позволяет осуществлять привязку данных к интерфейсу.

    НО работа со всеми моими данными я организую сам. Платформа в принципе не может знать мой набор данных и соответственно какой я хочу класс и с какими полями.

    Public Class MainClass
    
    Public Property MyProperty as String
    
    End Class
    Тут элементарный класс с единственным текстовым полем. Откуда платформе знать, что мне нужен именно такой класс с таким полем, ведь она всего лишь инструмент?

    Для человека изучающего C# 2008го, посещающего библиотеку MSDN и имеющего кучу книг, должно быть очевидно насколько глуп был тот вопрос на который я обратил внимание.

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

    И снова я призываю вас сначала понять то о чем вы спрашиваете и только потом спрашивать и возможно вам трудно в это поверить, но я забочусь о вас, а не о себе. Только научившись с 100го раза вникать в тему самостоятельно можно набить реальный скил разработчика. До тех пор никаких успехов у вас не будет.

    Форумы же нужны для решения локальных затыков, а не изучения базовых вопросов.


    VB.Net - WPF, UWP

    30 марта 2016 г. 17:14
    Отвечающий
  • Вас никто не просил отвечать, если что-то не нравится, проходите мимо. Такое впечатление, что вы хотите сделать вид, что лучше других.

    А как вы думаете, почему больше никто не вмешался в тему и не дал альтернативного ответа?

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

    Здесь года 3 назад был батл по выяснения какая платформа лучше WinForms или WPF. Несмотря на подавляющее число сторонников WPF и не смотря на массу аргументов и даже на наличие готовых крутых примеров, зачинщик батла все равно остался при своем мнении. Никто его не осуждает. Право каждого использовать, то что он хочет, но не надо пытаться обратить других в свою веру.

    Все ваши уточняющие вопросы из разряда "Но ведь то же самое можно и без ООП" как раз и являются попыткой переубедить нас в чем то. Зачем?

    Лилия не так давно на форумах и еще не так избита, поэтому и старается отвечать на все, на что может ответить, да же если вопрос того не стоит.


    VB.Net - WPF, UWP

    30 марта 2016 г. 17:26
    Отвечающий
  • Форумы же нужны для решения локальных затыков, а не изучения базовых вопросов.

    Лилия не так давно на форумах и еще не так избита, поэтому и старается отвечать на все, на что может ответить, да же если вопрос того не стоит.

    Да, c# я начала изучать в августе 2014, в сентябре появился первый затык, о котором спросила на форуме. Иногда сама задаю вопросы, но чаще никто не отвечает. Поэтому иногда отвечаю на вопросы в которых не разбираюсь на достаточном для ответа уровне. Получаю не лестные отзывы...

    Но иногда даже встречный глупый вопрос помогает найти ответ. Хотя моё замечание про то, что нельзя сравнивать массивы и классы никто и не заметил...

    30 марта 2016 г. 17:47
  • Но иногда даже встречный глупый вопрос помогает найти ответ. Хотя моё замечание про то, что нельзя сравнивать массивы и классы никто и не заметил...

    А вы думаете я не задавал глупых вопросов? Мало того я даже давал глупы ответы. Все таки с 2009 на форумах. Всякое было...

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


    VB.Net - WPF, UWP

    30 марта 2016 г. 17:53
    Отвечающий
  • Последнее замечание.

    Я имел в виду, что всё что у вас в программе, можно сделать на готовых списках, коллекциях и т.п., без необходимости писать свой класс.

    Все ваши уточняющие вопросы из разряда "Но ведь то же самое можно и без ООП" как раз и являются попыткой переубедить нас в чем то. Зачем?

    Ниоткуда это не следует. Это бездоказательно.

    Наоборот, у меня есть желание попробовать писать на ООП. Уже это делал, но сейчас некоторые проблемы с ноутубуком.

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

    Конкретные вопросы без всяких холиваров. А так чтобы не писать класс "из пушки по воробьям".


    • Изменено royalpiano 30 марта 2016 г. 18:59
    30 марта 2016 г. 18:58
  • Ну вот, результат, пусть нельзя сравнивать массивы и классы. А может, кому-нибудь неясно, ПОЧЕМУ. Так вот в этом и суть.

    В PHP вообще типизация другая. Там нет обязательной типизации, движок сам приводит типы.

    30 марта 2016 г. 19:03
  • Хотя вот люди сравнивают:

    http://stackoverflow.com/questions/3709578/using-arrays-vs-objects-for-storing-data

    http://stackoverflow.com/questions/2193049/php-objects-vs-arrays

    Так что не всё так очевидно.

    30 марта 2016 г. 19:11
  • Ну вот, результат, пусть нельзя сравнивать массивы и классы. А может, кому-нибудь неясно, ПОЧЕМУ. Так вот в этом и суть.

    В PHP вообще типизация другая. Там нет обязательной типизации, движок сам приводит типы.

    Потому, что мы говорим о .Net, не о PHP. Если вы хотите говорить о PHP, то вы форумом ошиблись.

    В HTML можно не закрыть тег и браузер это проглотит, можно написать полную белеберду и браузер это проглотит, а в XML любой не закрытый тег ломает весь файл. Так что теперь сравнивать HTML и XML только потому, что и там и там есть теги и содержимое внутри них? Так же и в PHP что массивы, что классы все едино, а .Net невозможно представить без ООП, так как в этом его философия.

    Но я полагаю, что я опять бросил мяч в стену. Вам будет не ясно то, что мы говорим пока вы не выучите ОСНОВЫ ООП. Я это слово до дыр уже затер наверное в данном топике. Вам в соседней теме дали книгу. Прочтите ее 2 раза как минимум и потом поговорим.


    VB.Net - WPF, UWP

    30 марта 2016 г. 19:24
    Отвечающий
  • Я имел в виду, что всё что у вас в программе, можно сделать на готовых списках, коллекциях и т.п., без необходимости писать свой класс.


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

    VB.Net - WPF, UWP

    30 марта 2016 г. 19:42
    Отвечающий
  • Ну вот, результат, пусть нельзя сравнивать массивы и классы. А может, кому-нибудь неясно, ПОЧЕМУ. Так вот в этом и суть.


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

    30 марта 2016 г. 20:07