То есть, если моя недалекость позволила мне правильно все понять, то Вы считаете трушными те языки, которые непоколебимо исповедуют правило “все является объектом”, так?
Тогда я понял Вашу точку зрения 
1 лайк
briv, taemdam я еще раз хочу сказать, что это лишь мое личное мнение, к тому же основанное не на шибко большом опыте. Это как ктото считает, что трули манты, это в которых мясо нарезано кусочками, а ктото считает, что это те, в которых мясо - фарш. Вот линк, там моя любимая жава совсем не трули и стоит в одном ряду с сями. Но те, что там указаны как pure далеко не так распространены как жава. Да и к тому же я их не знаю. Если бы я их знал, мое мнение наверняка бы изменилось, и жаву я бы уже считал не трули ОО ЯП. Но пока так
Под “намутить с объектами” я имел в виду написать, что-нибудь типа:
class Employee {blah-blah-blah}
и затем:
emp = new Employee(…)
Это позволяют сделать многие языки, в том числе поддерживающие ООП не в полной мере. Например, в некоторых языках можно создать объект, но нельзя использовать полиморфизм или даже наследование, т.е. объекты вроде есть, а ООП-то и нет как такового.
Там нигде не написано что “true” там написано “pure” . Разница (по-моему) очевидна. “pure” спирт знают все, а вот “true” почему-то его растворы, а никак не он в чистом виде. В целом же “знать” надо не языки а приёмы программирования, тогда новый язык / ide будет всего-лишь небольшой головной болью.
1 лайк
3 признака ООП (Инкапсуляция, полиморфизм, наследование) вечны и не меняются, как и 3 принципа робототехники, а язык - уже личное дело каждого.
Для чего-то лучше использовать одно, для других задач другое.
Правда на синтаксисе С и рнр основано, и ява…
Меня всегда забавляло разделение на тру и не тру ООП и языки программирования. ООП оно должно быть в первую очередь в голове, в схемах классов в конце концов. Что касается того, что C++ позволяет отклоняться от концепции ООП, то я и на Java могу нафигачить все в main на 100 страниц, даже не утруждая себя процедурами.
P.S. Сам на данный момент пишу на Java. Доводилось разрабатывать приложения и на PHP. Знаком с C#.
1 лайк
Для поддержания флуда могу сказать, что ООП языки программирования позволяют писать ОО код совсем не так как это подразумевалось с самого начала. Кому интересно, почитайте про “liskov substitution principle”.
Подскажите pls. что входит в понятие “знание протокола/лов” (tcp/ip/http и др.). На каком уровне их необходимо знать ?
Вот я знаю, что за протокол, за что он отвечает, что он делает…, но это, подозреваю, не есть знание протокола, которое необходимо для работы.
Знание Ваше может быть разным. И чем оно выше, тем лучше. Невозможно ответить на вопрос “на каком уровне их необходимо знать”. Лучшее, что мне приходит в голову - на уровне системного администратора.
На уровне системного администратора, я так понимаю значит на уровне настройки в ОС и др приложениях, в которых присутствует протокол?
“Знание протокола” понятие растяжимое. Растягивается от “знать что веб-сервер работает на http\https и номера портов” до “знать до уровня IP\TCP\UDP заголовков, флагов и т.п.”.
Думается, все от позиции зависит. Для системного администратора одно, для разработчика сетевых и клиент-серверных приложений - совсем другое.
Нет, это как раз-таки базовый уровень. Ну давайте на примере. В протоколе ppp согласование логина и пароля проходит после установления соединения. Значит, если соединение выругается на логин\пасс, то с коннектом проблем нет, есть только с логином\пассом. Если же соединение выдает ошибку по таймауту, значит логин\пасс тут не при чем и нужно искать почему не устанавливается коннект. Пример на самом деле очень деревянный, просто почему-то я не могу привести годного. Не знаю почему.
Опять же, чем больше и глубже Вы знаете - тем лучше. Когда-то я пытался запомнить из каких частей состоит IP пакет, но потом плюнул и ни разу с того времени про это не вспоминал. В моей работе оно просто не нужно. Главное - знать некие базовые вещи, как например какая информация отсылается, из каких этапов состоит общение по такому-то протоколу. Вам нужно брать хорошую книжку и читать ее. Мне очень помогла книга “Полный справочник по CISCO” Брайана Хилла. Она конечно далеко не полный справочник, но как база - очень хороша. Я фактически начинал с нее. Попробуйте, может и Вам поможет. Первая часть посвящена как раз протоколам и разным сетевым вещам. Изложено очень доступно.
Ок, если настройка в рамках ОС и прог это базовый уровень. Тогда с Вашего примера, который я кстати понял, нужно знание техники поведения протокола для выявления возможной ошибки - это уже знание протокола ? или просто какой то из уровней его знания ?
Во многих вакансиях пишут что нужно знание протоколов и пишут каких, а что под этим подразумевается для практической работы, не ясно!
Если мысли вслух то вроде как получается что протокол, это часть “заводской” программы, которая в нее вшита и нужно просто знать за что отвечает протокол, как он работает-что делает, как его настроить под нужную задачу и все… наверное.:scratch_one-s_head:
За буку спасибо, сейчас найду и посмотрю что за штука!
Да вы почитайте, разберитесь более-менее. Лишним это не будет для специалиста любого уровня, так что зря время не потратите :). А как будтете иметь общее представление, то вам уже и самому будет примерно понятно, где каких знаний будет достаточно.
Можно на примере POP3/SMTP. Допустим, пишем мы прогу ,которая мыло отправляет и принимает. На каком-то этапе выловили exсeption. Это может быть ответ сервера на некорректный запрос. Аналогично с проверкой почты, наш самопис-клиент пытается получить письмо с сервака, а сервер вместо новых писем нам ошибку даёт(точно не помню какой error code, но кажется на рор3 были 501,502,505 и т.д.). Описание каждой ошибки есть в соответствующих RFC, которые нужно идти читать, с каждым получением ошибки…Вот знание протокола POP3/SMTP. Можно привести любой пример с протоколами в кодинге. ftp-клиент, web-браузер и т.д. :). В networking’е можно брать работу фаерволла…всёж нужно знать какой протокол запретить, когда просят запретить приём писем и т.д. туда же идёт знание портов, по дефолту занимаемых протоколами.
1 лайк
Ну да, это тоже все понятно.
Получается знание протокола, это знание того, за что протокол отвечает, как он настраивается в рамках ОС или программы и как он действует и работает(механизмы и логика). В случае некорректной работы система и протокл выдаст ошибку, или она будет замечена в случае получения неправильного результата работы, благодаря которой можно будет понять в чем косяк и его поправить в настройках или еще где то.
Если что еще упустил - коррект ми =)))
Все верно. Но желательно знать не один протокол (если только тебя не нанимают на обслуживание именно этого протокола), а все более-менее популярные протоколы. Естественно, не обязательно знать (да это и невозможно) все протоколы “в лицо”, глядя на шестнадцатеричный дамп сетевого трафика. Но уметь быстро найти требующуюся информацию, причем желательно ту, что нужно. Другой пример “знания протоколов”. Люди жалуются, что “определенная программа работает медленно”. Выясняется, что кто-то установил для этого трафика низкий приоритет “качества сервиса”. Или наоборот, кто-то поднял себе этот приоритет, и его трафик “давит” все другие протоколы. Где? Как? Как обнаружить? Как исправить? Или еще пример, один сервер не может установить связь с другим сервером. Где установить “прослушку”, чтобы обнаружить проблему? На что обращать внимание на каждом уровне сетевой модели OSI. Ну, и так далее. Причем это не какие-то специфичные требования, это основа основ любого грамотного сетевого или системного администратора.
Что-то я Вас не пойму. Если цель - настраивать протокол(ы) в ОС или в программах, то это и не цель (в полноценном смысле этого слова) и не знание протоколов; а так, знакомство с закладками, где можно галочку поставить.
Понимаете ли, протоколы - тема почти столь же неисчерпаемая, как и электрон с атомом… А Вы пытаетесь на форуме получить инструкцию, типа: “Здесь читать, здесь не читать, а здесь рыбу заворачивали”…
Если это действительно Вам нужно и (или) интересно, то начните просто разбираться с протоколом(ами). Глубину погружения определите в процессе изучения, причем, скорее всего, потребуется не одна итерация изучения каждого протокола и его взаимодействия с другими.
Материала полно и в книгах и в Интернете.
TCP IP
TCP IP
Сетевая модель OSI
Протокол передачи данных
Сетевые протоколы
:clapping: