VB.NET. Какова цель classа или модуля?

Соус для новичков здесь … Итак, я попытался найти ответ, но не смог.

Какова цель создания classа или модуля? Все, что я читаю, пытается рассказать мне, что это такое, но не то, для чего оно предназначено. Зачем мне это нужно?

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

Модуль действительно очень похож на class, содержащий только общие члены. На самом деле, в C # нет такой конструкции, как «модуль». Вы не можете писать какое-либо приложение, не имея хотя бы одного модуля или classа, поэтому я подозреваю, что ваш реальный вопрос не «зачем использовать classы и модули», а скорее «зачем использовать несколько classов и модhive и когда подходит для запуска нового», , Поскольку модули и classы по существу то же самое, я просто сосредоточусь на том, почему у вас будет несколько classов вообще. Существует четыре основных причины создания нового classа:

  1. Сохранение данных в незаметных элементах
  2. Организуйте свой код
  3. Обеспечить швы в коде
  4. Разделите свой код на слои и поддерживайте n-уровни

Теперь давайте посмотрим на каждую из них более подробно:

Хранить данные в секретных элементах

Часто вам нужно хранить несколько данных об одном элементе и передавать эти данные между методами как один объект. Например, если вы пишете приложение, которое работает с человеком, вам, скорее всего, захочется хранить несколько данных о человеке, например их имя, возраст и название. Очевидно, вы можете хранить эти три данных в виде трех отдельных переменных и передавать их как отдельные параметры для таких методов, как:

 Public Sub DisplayPerson(name As String, age As Integer, title As String) Label1.Text = name Label2.Text = age.ToString() Label3.Text = title End Sub 

Однако часто бывает проще передавать все данные как один объект, например, вы могли бы создать MyPersonClass , например:

 Public Class MyPersonClass Public Name As String Public Age As Integer Public Title As String End Class 

И тогда вы можете передать все данные о человеке в одном параметре, например:

 Public Sub DisplayPerson(person As MyPersonClass) Label1.Text = person.Name Label2.Text = person.Age.ToString() Label3.Text = person.Title End Sub 

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

 Dim names(9) As String Dim ages(9) As Integer Dim titles(9) As String 

Разумеется, совершенно не очевидно, что names(3) и age(3) хранят данные для одного и того же человека. Это то, что вам просто нужно знать, или вам нужно написать его в комментарии, чтобы вы не забыли. Однако это намного проще и проще, если у вас есть class для хранения всех данных для человека:

 Dim persons(9) As Person 

Теперь совершенно очевидно, что persons(3).Name и persons(3).Age – оба данные для одного и того же человека. Таким образом, он самодокументируется. Для разъяснения вашей логики не требуется комментариев. В результате, опять же, код будет менее подвержен ошибкам.

Часто classы будут содержать не только данные для определенного элемента, но также методы, которые действуют на эти данные. Это удобный механизм. Например, вы можете добавить метод GetDesciption к classу person, например:

 Public Class MyPersonClass Public Name As String Public Age As Integer Public Title As String Public Function GetDescription() As String Return Title & " " & Name End Function End Class 

Затем вы можете использовать его следующим образом:

 For Each person As MyPersonClass In persons MessageBox.Show("Hello " & person.GetDescription()) Next 

Который, как я уверен, вы согласитесь, намного чище и проще, чем что-то вроде этого:

 For i As Integer = 0 To 9 MessageBox.Show("Hello " & GetPersonDescription(title(i), names(i))) Next 

Теперь скажем, вы хотите сохранить несколько псевдонимов для каждого человека. Как вы можете легко видеть, persons(3).Nicknames(0) намного проще, чем некоторые сумасшедшие двумерные массивы, такие как nicknames(3)(0) . И что произойдет, если вам нужно хранить несколько данных о каждом прозвище? Как вы можете видеть, не использование classов будет очень беспорядочным.

Организуйте свой код

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

  • GetPersonDescription
  • GetProductDescription
  • FirePerson
  • SellProduct

Я уверен, вы согласитесь, что намного проще следовать коду, если эти методы были разбиты на отдельные classы, такие как:

  • Person
    • GetDescription
    • Fire
  • Product
    • GetDescription
    • Sell

И это очень простой пример. Когда у вас есть тысячи методов и переменных, относящихся ко многим различным элементам и различным типам элементов, я уверен, что вы можете легко представить, почему classы важны для организации и самодокументации кода.

Обеспечьте швы в своем коде

Это может быть немного более продвинутым, но это очень важно, поэтому я попытаюсь объяснить это простым языком. Предположим, вы создали class трассировщика, который записывает записи журнала в файл журнала трассировки. Например:

 Public Class TraceLogger Public Sub LogEntry(text As String) ' Append the time-stamp to the text ' Write the text to the file End Sub End Class 

Теперь давайте скажем, что вы хотите, чтобы class журнала мог записывать в файл или в базу данных. На этом этапе становится очевидным, что запись записи журнала в файл – это действительно отдельный тип логики, который должен был быть в своем собственном classе, поэтому вы можете разбить его на отдельный class, например:

 Public Class TextFileLogWriter Public Sub WriteEntry(text As String) ' Write to file End Sub End Class 

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

 Public Interface ILogWriter Sub WriteEntry(text As String) End Interface Public Class TextFileLogWriter Implements ILogWriter Public Sub WriteEntry(text As String) Implements ILogWriter.WriteEntry ' Write to file End Sub End Class Public Class DatabaseLogWriter Implements ILogWriter Public Sub WriteEntry(text As String) Implements ILogWriter.WriteEntry ' Write to database End Sub End Class 

Теперь, когда вы нарушили эту логику доступа к данным в свои classы, вы можете реорганизовать свой class регистратора следующим образом:

 Public Class TraceLogger Public Sub New(writer As ILogWriter) _writer = writer End Sub Private _writer As ILogWriter Public Sub LogEntry(text As String) ' Append the time-stamp to the text _writer.WriteEntry(text) End Sub End Class 

Теперь вы можете повторно использовать class TraceLogger во многих других ситуациях без необходимости когда-либо касаться этого classа. Например, вы можете дать ему объект ILogWriter который записывает записи в журнал событий Windows или в электронную таблицу или даже в электронную почту – все, не касаясь исходного classа TraceLogger . Это возможно, потому что вы создали шов в своей логике между форматированием записей и записью записей.

Форматирование не волнует, как записи регистрируются. Все, о чем он заботится, – это форматирование записей. Когда ему нужно писать и записывать, он просто просит отдельный объект-автор выполнить эту часть работы. Как и что этот автор на самом деле делает внутренне не имеет значения. Точно так же писателю все равно, как форматируется запись, он просто ожидает, что все, что передается ему, является уже отформатированной допустимой записью, которая должна быть зарегистрирована.

Как вы могли заметить, TraceLogger не только TraceLogger повторно записывать на любой тип журнала, но также и записывает записи для записи любого типа журналов в эти типы журналов. Вы можете повторно использовать DatabaseLogWriter , например, для записи журналов трассировки и журналов исключений.

Небольшая надежда на инъекцию зависимостей

Просто немного пошутите меня, так как я делаю этот ответ немного дольше, размышляя о чем-то важном для меня … В этом последнем примере я использовал метод, называемый инъекцией зависимостей (DI). Это называется инъекцией зависимостей, потому что объект записи является зависимостью от classа журнала, и этот объект зависимостей вводится в class регистратора через конструктор. Вы можете сделать что-то подобное без инъекции зависимости, сделав что-то вроде этого:

 Public Class TraceLogger Public Sub New(mode As LoggerModeEnum) If mode = LoggerModeEnum.TextFile Then _writer = New TextFileLogWriter() Else _writer = New DatabaseLogWriter() End If End Sub Private _writer As ILogWriter Public Sub LogEntry(text As String) ' Append the time-stamp to the text _writer.WriteEntry(text) End Sub End Class 

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

Другой альтернативой подходу для внедрения зависимостей будет использование наследования для создания нескольких classов TraceLogger , по одному на тип записи:

 Public MustInherit Class TraceLogger Public Sub New() _writer = NewLogWriter() End Sub Private _writer As ILogWriter Protected MustOverride Sub NewLogWriter() Public Sub LogEntry(text As String) ' Append the time-stamp to the text _writer.WriteEntry(text) End Sub End Class Public Class TextFileTraceLogger Inherits TraceLogger Protected Overrides Sub NewLogWriter() _Return New TextFileLogWriter() End Sub End Class Public Class DatabaseTraceLogger Inherits TraceLogger Protected Overrides Sub NewLogWriter() _Return New DatabaseLogWriter() End Sub End Class 

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

Вернуться к описанию логических швов

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

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

Разделите свой код на слои и поддерживайте N-уровни

Когда вы правильно организовали свой код в отдельные classы, где каждый class отвечает только за один тип задач, вы можете начать группировать свои classы в слои . Слои – это просто высокоуровневая организация вашего кода. В языке нет ничего конкретного, что делает что-то технически слоем. Поскольку на языке нет ничего, что позволяет понять, где каждый слой начинается и заканчивается, люди часто помещают все classы для каждого слоя в отдельные пространства имен. Так, например, у вас могут быть пространства имен, которые выглядят так (где каждое пространство имен является отдельным слоем):

  • MyProduct.Presentation
  • MyProduct.Business
  • MyProduct.DataAccess

Как правило, вы всегда хотите иметь по крайней мере два уровня в коде: уровень представления или пользовательского интерфейса и уровень бизнес-логики. Если ваше приложение выполняет какой-либо доступ к данным, который обычно помещается в свой собственный слой. Каждый слой должен быть, насколько это возможно, независимым и взаимозаменяемым. Так, например, если наш class TraceLogger в приведенном выше примере находится в бизнес-слое, он должен быть повторно использован любым пользовательским интерфейсом.

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

Конец того, что я должен сказать

Короче говоря, вам никогда не нужно создавать более одного classа или модуля. Всегда можно писать все приложение в одном classе или модуле. В конце концов, все операционные системы и программные комплексы были разработаны, прежде чем объектно-ориентированные языки были даже изобретены. Тем не менее, есть причина, почему языки объектно-ориентированного программирования (ООП) настолько популярны. Для многих проектов объектная ориентация невероятно выгодна.

Класс – это механизм для инкапсуляции состояния (данных) и поведения (методов).

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

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

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

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

Класс – это более общая концепция объектно-ориентированного программирования, которая позволяет вам определять «вещь», а затем создавать ее несколько раз во время работы вашей программы.

Предположим, вы хотели создать игру Virtual Pet в Visual Basic. Вы позволяете пользователю добавлять столько разных животных, сколько захотите, и вы начинаете понимать, что отслеживать это очень сложно. Используя classы, это становится очень просто …

 Class PetDog Private _id As Integer Public Name As String Public Breed As String Public Sub Bark() Console.WriteLine(Name + " says Woof!") End Sub End Class 

После того, как вы написали этот код, позволяя пользователю добавить еще одну собаку в свой зоопарк, так же просто:

 Dim Dog1 As New PetDog() Dim Dog2 As New PetDog() 

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

 Dog1.Name = "Fido" Dog2.Breed = "Poodle" Dog1.Bark() 

Вышеприведенный fragment напечатает «Fido говорит Woof!».

Надеюсь, это поможет 🙂

Если вы собираетесь создать свой собственный тип и позже создать объекты этого типа – используйте class.

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

Теперь разработчики C # могут показать кислое лицо, потому что вы должны использовать общие методы общего classа вместо модуля на C #, в конечном счете, потому что у C # нет модhive. Таким образом, вы должны использовать classы в обоих случаях в C #. И вы должны сделать то же самое в VB.NET. Это дает вам проблему разделения пространства имен, поэтому ваш intellisense более организован. С модулями все ваши общедоступные методы из всех модhive находятся в глобальном ведре методов – больше беспорядка для решения.

Единственное хорошее применение для модhive в VB.NET – это использование методов расширения.

Классы, формы и код – «Модули» – это все типы модhive в VB.

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

Наиболее простые, так называемые «Модули» (или «модули кода», как они когда-то назывались, чтобы отличить их от более общей концепции модhive) дают немного больше, чем это, плюс способ объявить переменные, которые живут вне любых единую рутину и не уходят, когда вы выходите из подпрограммы, и простой способ связать, какой код / ​​модуль (ы) находятся в исходных файлах.

Классы – это более мощный тип модуля (*), который может быть «Instanced», что означает, что вы можете рассматривать их как тип данных, создавать несколько копий из них с разными значениями / содержимым, назначать их переменным, передавать их от функций и других методов и т. д. Эти копии или «экземпляры» чаще называют «объекты».

Формы – это всего лишь особый тип classа, который автоматически интегрируется с визуальными компонентами и элементами управления, чтобы помочь вам создать графический пользовательский интерфейс.

(* – Обратите внимание, что сегодня это учит иначе: Классы – это общая концепция, а VB-код-mdoules – это очень ограниченный специализированный class, называемый «Singleton». Но как исторически, так и в традициях Basic, это было Модули задолго до Классы.)

Похоже, вы знакомы с некоторым уровнем написания сценариев, но не обязательно с объектно-ориентированным программированием.

Причиной использования classов или модhive (которые являются обоими объектами) является то, что подобные функции позволяют повторно использовать код, объекты позволяют повторно использовать.

Помимо возможности повторного использования, у них есть то преимущество, что они могут содержать как данные (свойства), так и функции. Например, class Person может иметь такие свойства, как имя, дата рождения и т. Д., А также метод расчета их возраста.

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

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

Чтобы найти полезные статьи, вы можете google для ознакомления с объектно-ориентированным программированием.

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

  • Возврат функции VB.NET
  • VB.NET progressbar backgroundworker
  • Контрольный массив в VB.NET
  • Могу ли я разместить Windows Form внутри элемента управления
  • Как вы привязываете CollectionContainer к коллекции в модели представления?
  • Отключить использование JSON.net
  • Задание логического значения для целого числа возвращает -1 для true?
  • Скрыть одиночную форму при запуске
  • Как создать комбинации элементов из списка в .NET 4.0
  • Является ли String.Format таким же эффективным, как StringBuilder
  • Как наследование работает для атрибутов?
  • Давайте будем гением компьютера.