Оцените решение

[Useverlo]

Уважаемые форумчане, оцените пожалуйста грамотность решения задания. Имеется ввиду правильно ли спроектировано приложение, грамотно ли использовались используемые библиотеки, а также укажите на наличие "грязи" в решении. То есть, хочется услышать все "ляпы", которые допущены при выполнении задания. А также как бы Вы сами сделали бы такое задание, если бы пришлось его решать.
Само решение(проект и скомпилированный экзешник) приложил к теме.

Тестовое задание следующее:

Задание: необходимо вывести введенное 10-тичное число словами на русском языке в 8-ми и 10-ной системах. Например.

Вводим: 131
Выводим:
сто тридцать один в десятичной системе;
двести три в восьмеричной системе.

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

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

Программа спроектирована таким образом, что ее можно легко масштабировать.
Создан абстрактный класс Translate_base и от  него наследуются классы перевода на разные языки - Translate_rus и Translate_eng. В каждом из этих классов создается объект словаря, который содержит только слова перевода.
Также создан отдельный класс хранения введеного и сконевертированного значения (Storage_Values), а также метод конвертации. Классы перевода являются "друзьями" по отношению к классу хранения чисел.
Максимальное количество порядков, которое может вывести программа ограничена "триллионами". При желании это ограничение можно снять или уменьшить, добавив нужные термины в словарь и в класс перевода (по крайней мере, для русского и английского языков это не составляет труда и делается точно также как и для слов "миллионов", "миллиардов" и т.д.)

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

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

Также использовался механизм исключений для отслеживания исключительных ситуаций и их корректной обработки.
В программе использовались библиотеки STL, Boost и среда разработки VS2008.

[Dimka]

1) Зачем для этой скромной задачи использовать нескромный по размерам Boost? Для демонстрации знания о нём?

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

3) Обоснуй использование throw-catch подхода к обработке ошибок внутри одной функции, когда между функциями (местами) используется передача статуса выполнения операции.

4) Объясни, почему запрос исходных данных у тебя на русском языке, а сообщения об ошибках на английском?

5) Непонятно, зачем функция Display помимо подготовки результата к выводу ещё и очищает буферы?

6) Зачем функция Display выполняет перекодировку символов, если эту же работу выполняет перегруженный оператор << стандартного потока?

7) Как в интерфейсе транслятора сочетаются вместе и одновременно объявлены public функции Translate и TranslateImpl?

8 ) Почему функция Translate пишет в стандартные потоки, когда она же вызывается в перегруженном операторе << стандартного потока?

9) Зачем введены классы словарей, если у них нет единого интерфейса?

10) Зачем используются методы типа Initialize, когда есть конструкторы?

11) Нужны очень веские причины, чтобы нарушать инкапсуляцию классов. Назови такие причины, которые требуют использования friend-отношений?

В общем, если речь идёт о приёме на работу, то:
- за знание языка программирования - "хор.",
- за владение алгоритмическим программированием - "отл.",
- за владение проектированием - "неуд.".
- за инженерию - "неуд.".

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

[Вад]

Dimka сделал довольно подробный разбор

Кратко от себя: декомпозиции не видно. Есть два класса "переводчиков", выполняющих, очевидно, одни и те же задачи.

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

Если потом логика хоть на чуть сдвинется (изменится формат вывода, например, или, что очевидно, не нужно будет выводить оба представления числа одновременно) - переделке придётся подвергать все классы.

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



И, если уж выпендриваться по-настоящему, чтобы пустить пыль в глаза работодателю, почему бы не создать DSL для описания грамматик числительных в разных языках, а к нему - небольшой разборщик, который преобразует описание грамматик в код, создавая обобщённые "словари-переводчики" (в режиме интерпретатора или транслятора)?