LINUX.ORG.RU

Почему нельзя не думать об архитектуре.

 ,


0

3

Почему все книги учат, что нужно отделять гуй, usecase, бизнес сущности и т.д.

- Зачем я должен отделять sql код от бизнес сущности если, исходя из требований, никогда не будет меняться метод сохранения в бд? Почему я должен вносить не оправданную сложность?

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

Сам я так не делаю, но и объяснения «почему бы и нет» я найти не могу. Другое дело, когда мы заранее видим вектор изменений и готовим нашу архитектуру к будущим изменениям. Но если, например, у меня Android проект, и там для сохранения в базу я могу юзать только sqlite, зачем придумывать какие-то абстракции и усложнять себе жизнь? Например, я вижу только один кейс, зачем я должен придумать абстракцию в виде DAL для SQL кода. Просто что бы это все гуано лежало в одном месте ))). Но если удобно и без DAL, но зачем его писать.

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

Ответ на: комментарий от CrossFire

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

pozitiffcat ★★★
() автор топика
Ответ на: комментарий от pozitiffcat

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

CrossFire ★★★★★
()
Ответ на: комментарий от CrossFire

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

pozitiffcat ★★★
() автор топика
Ответ на: комментарий от pozitiffcat

Хорошая архитектура не может появиться потом — это уже больше тянет на переписывание продукта в процессе масштабного рефакторинга.

CrossFire ★★★★★
()
Ответ на: комментарий от pozitiffcat

Обычно я мучаюсь, когда нахерачу 100500 классов в угоду архитектуре

Вот я не понимаю одного, почему нахерачить 100500 классов называют «в угоду архитектуре», если архитектура от этого только страдает? Зачем тогда наследование нужно? Совместное, повторное использование кода уже к архитектуре не относится? Тогда причем тут ООП вообще?

filequest
()
Ответ на: комментарий от filequest

Вот я не понимаю одного, почему нахерачить 100500 классов называют «в угоду архитектуре», если архитектура от этого только страдает?

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

CrossFire ★★★★★
()
Ответ на: комментарий от CrossFire

И что? Использовать 5 классов там где достаточно одного свитча — признак хорошей архитектуры? Или к чему это было сказанно?

filequest
()
Ответ на: комментарий от filequest

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

CrossFire ★★★★★
()
Ответ на: комментарий от CrossFire

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

filequest
()
Ответ на: комментарий от pozitiffcat

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

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

Debasher ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.