justaguest: конкатенция строк это перегруженная функция(оператор) класса строк, суть метод класса, как правило оператор +.
Функция может использоваться но это ИМХО неправильно, нарушается восприятие и усложняется архитектура, увеличиваются риски модификации.
Разницы между «свободной» функцией и методом класса особой нет если работать в режиме ФП. C# все правильно в этом плане сделано, обходить это неверный путь. Мне кажется проблема в том что вы мыслите в разрезе взаимодействия данных и функций, а я говорю о взаимодействии объектов в контексте архитектуры программы. В программе может быть только одна функция не принадлежащая классу, это Main. ИМХО конечно.
justaguest: абстрактно можно говорить вечно, по крайней мере в данном контексте. Каждый человек по разному воспринимает даже отдельные слова не говоря уже о архитектуре ПО.
Да, база такая, но все нужно использовать разумно. Если одна и таже функция используется в разных частях программы на разных слоях абстрактности, значит что то мы делаем не так. Если функция(не челен класса) используется во множестве разных файлов не объединенных в один "модуль" (не файл), то это порождает задачи которые высказал ТС, а так же влечет за собой повышенные риски при модификации кода.
Если это моё заблуждение, то я бы хотел по подробнее узнать почему.
justaguest: ну так если из названия можно определить контент файла, соответственно можно с легкостью определить и какие функции там лежат. Если нет, значит тут что то не так c названием файла или с контентом файла (возможно стоит разбить или объединить файл(ы)). Конечно все это верно при учете знания языка. Я не знаю хаскел и не могу сказать что понимаю контент файлов в полной мере, так что не могу судить о названиях файлов.
Может быть моё мнение в некоторой степени дилетантское но если есть функция, то она принадлежит классу иначе она локальная (определена в нем же) для файла в котором используется или подключена явно (include) с соответствующем комментарием зачем и что подключено, но это уже плохо.
И надеюсь мы говорим о ООП, а не функциональщине. ФП подразумевает говнокод в плане архитектуры сколько-нибудь большого приложения априори.
justaguest: ну если отвязаться от привязки к языку то да, если ты смотря на иерархию проекта с ходу не можешь понять что здесь и открывая файл ты видишь не то что ожидал (при условии знания языков на которых написан проект), то над качеством архитектуры проекта стоит задуматься (возможно даже проблема в банальном не умении писать на языке).
justaguest: я не говорю что ядро Linux это плохая архитектура из-за того что ядро написано полностью(почти) на Си, но сама задача написания ядра вынуждает к такой архитектуре и писанине на Си. В любом случае ядро Linux это особый случай. Перед данным проектом стоят достаточно не тривиальные задачи (сточки зрения программирования).
justaguest: "При большой правильной архитектуре ответ может с равной вероятностью лежать в любом из десятка файлов в директории" - неверно, если только код не размазывать по всему что можно, это уже код на букву Г.
"ядро Линукс, его трудно обвинить в неправильной архитектуре" - сомнительное утверждение, учитывая что все ядро написано на "чистом" Си.
justaguest: я нашел проект о котором вы говорите. Попытался вникнуть но я не знаю Хаскель и его особенностей. Но вашу задачу я бы решал так, нашел функцию отвечающей за включение/переключение режима, как по мне логичнее было бы от туда посылать "сигнал" о том какой режим сейчас активен и уже бы посмотрел кто "ловит" этот сигнал, иначе пришлось бы по по таймауту проверять какой режим активен, а это мягко говоря неэффективно.
justaguest: под правильной архитектурой подразумевается именно легко читаемость кода, когда код сам тебе говорит из каких частей состоит программа и как эти части взаимодействуют друг с другом. Документация здесь не причем, с плохой архитектурой она мало чем поможет.
Простой пример для С++/Qt проекта.
Есть некое главное окно в котором есть менюшка которая допустим имеет пункт "Компании", этот пункт открывает окошко в котором список компаний, и их можно удалять/добавлять/редактировать/etc. Ну и мне вдруг надо поправить что то по поводу добавления новой компании, автозаполнение для полей допустим каких то сделать. Что я ожидаю и при должной архитектуре должен увидеть в коде? Ну первое функцию main в которой создается объект класса MainWindows (главное окно), в данном классе в конструкторе должна каким то образом создаваться эта менюшка. Находим к какой слот вызывает соответсвующий пункт меню. В данном слоте должен создаваться объект класса CompanyDialog или CompanyList (главное что бы имена функций, слотов и классов явно отражали свою суть). Уже в данном классе смотрим в ожидаемом месте (в конструкторе) менюшку, ищем слот который ожидаемо называеться addCompany ну и т.д. Главное в правильной архитектуре четкое разделение и однозначность имен функций и классов. Что бы человек смотря на программу уже примерно представлял как могут называться нужные ему классы и функции. Вот что я называю правильной архитектурой. Я привел пример завязаный на GUI, но данный подход должен быть во всем и в первую очередь в бекэнде(краткие но емкие комментарии о том что делается, обязательны) , просто с GUI проще понять о чем я хотел сказать.
Urukhayy: вообще слабо понял о чем вы говорите. Давайте на примере. Есть участок кода с которым вы работаете в текущий момент (функция). В нем есть другие "функции", лично я получаю их "тела" если такое вдруг нужно при помощи стандартных средств IDE, а именно Ктр+ЛКМ. Так же если допустим я пришел в файл и знаю что нужная функция мне в нем то пользуюсь списком функций, предоставляемых IDE, с помощью него и произвожу навигацию. А есть еще такая удобная штука как иерархия классов.
Если вы говорите о том что вам нужно узнать где вызывается эта функция в коде проекта вообще, то вам помогут инструменты рефакторинга вашей IDE. Но лично у меня такой необходимости никогда не возникало, кроме как переименования класса допустим.
Функция может использоваться но это ИМХО неправильно, нарушается восприятие и усложняется архитектура, увеличиваются риски модификации.
Разницы между «свободной» функцией и методом класса особой нет если работать в режиме ФП. C# все правильно в этом плане сделано, обходить это неверный путь. Мне кажется проблема в том что вы мыслите в разрезе взаимодействия данных и функций, а я говорю о взаимодействии объектов в контексте архитектуры программы. В программе может быть только одна функция не принадлежащая классу, это Main. ИМХО конечно.