Запитання з тегом «dry»

Я завжди намагаюся чітко дотримуватися принципу DRY на роботі; кожен раз, коли я повторював код із ліні, він відвертається пізніше, коли мені потрібно підтримувати цей код у двох місцях. Але часто я пишу невеликі методи (можливо, 10 - 15 рядків коду), які потрібно повторно використовувати в двох проектах, які не …

102 project-management  code-reuse  projects-and-solutions  dry 

Досить просто, чому я хотів би написати код, який працює для всіх випадків і масштабованих даних, коли все, що мені потрібно зробити, це повторити той самий процес кілька разів з кількома незначними налаштуваннями? Мені навряд чи доведеться скоро редагувати це знову. Це схоже на набагато менше роботи, аби просто піти …

81 code-quality  dry 

Наприклад, врахуйте, що у мене є клас для інших класів, який слід продовжити: public class LoginPage { public String userId; public String session; public boolean checkSessionValid() { } } і деякі підкласи: public class HomePage extends LoginPage { } public class EditInfoPage extends LoginPage { } Насправді, підклас не має …

36 inheritance  composition  dry 

У мене є код, який майже ідентичний, але використовує абсолютно різні типи, без спадкування між ними, на головній змінній. Зокрема, я пишу аналізатор з Roslyn для C # та VB.NET із такими типами: Microsoft.CodeAnalysis.CSharp.Syntax.AttributeSyntax Microsoft.CodeAnalysis.VisualBasic.Syntax.AttributeSyntax Мені цікаво, якщо, оскільки код робить те саме, я повинен зберігати його як можна DRY, …

34 c#  design  dry 

Мені цікаво, що краще в плані хорошого дизайну OOP, чистого коду, гнучкості та уникнення запахів коду в майбутньому. Образна ситуація, коли у вас є дуже багато подібних об'єктів, які вам потрібно представити як класи. Ці класи не мають жодної конкретної функціональності, просто класи даних і відрізняються лише назвою (і контекстом) …

24 object-oriented  inheritance  dry 

У мене є кілька класів, які успадковують усі із загального базового класу. Базовий клас містить колекцію декількох об'єктів типу T. Кожен дочірній клас повинен мати можливість обчислювати інтерпольовані значення з колекції об'єктів, але оскільки дочірні класи використовують різні типи, обчислення змінюються незначно біт від класу до класу. Поки я копіював …

24 c#  code-quality  complexity  code-reuse  dry 

Розглянемо такі методи: public List<Employee> GetAllEmployees() { using (Entities entities = new Entities()) { return entities.Employees.ToList(); } } public List<Job> GetAllJobs() { using (Entities entities = new Entities()) { return entities.Jobs.ToList(); } } public List<Task> GetAllTasksOfTheJob(Job job) { using (Entities entities = new Entities()) { return entities.Tasks.Where(t => t.JobId == …

23 c#  design-patterns  dry 

Я будую API REST, щоб відкрити більшість функціональних можливостей існуючого Java API. Обидва API призначені для внутрішнього використання в моїй організації; Мені не доводиться проектувати для зовнішнього використання. Я маю вплив на обидва API, але я реалізую REST. API API і надалі буде використовуватися для локальних додатків (він не "звільнений"), …

19 java  api  rest  coupling  dry 

Я на 100% працюю над тим, що, безумовно, слід використовувати як перевірку даних на стороні клієнта, так і на сервері. Однак у рамках, в яких я працював, підходи, які я бачив, ніколи не бували сухими. У більшості випадків немає плану чи шаблону - перевірки записуються у специфікації моделі, а перевірки …

17 design  validation  dry  client-server 

Я щойно натрапив на статтю " Правило трьох " у вікіпедії Правило три - це правило перетворення коду, яке вирішує, коли повторний фрагмент коду слід замінити новою процедурою. У ньому зазначається, що код можна скопіювати один раз, але що коли той самий код використовується тричі, його слід витягти в нову …

16 refactoring  dry  rule-of-three 

Де найкраще визначити вхідні параметри функції: абонента або самої функції? Оскільки я хотів би вдосконалити свій стиль кодування, я намагаюся знайти найкращі практики чи деякі правила щодо цього питання. Коли і що краще. У попередніх проектах ми перевіряли та обробляли кожен вхідний параметр всередині функції (наприклад, якщо він не є …

16 coding-standards  validation  dry 

Припустимо, у нас є програмний модуль A, який реалізує функцію F. Інший модуль B реалізує ту ж функцію, що і F '. Існує кілька способів позбутися від дублюючого коду: Нехай A використовує F 'від B. Нехай B використовує F від A. Помістіть F у власний модуль C і дозвольте їм …

14 design  architecture  dry  coupling 

Я шукаю вказівки щодо сполучення DRY проти коду. Мені не подобається дублювати код, і мені також не подобається з'єднання коду між непов'язаними модулями. Тож я рефактор дублюючого коду, якщо виявляю ідентичний дублікат коду через рік після введення дублювання. Однак у мене все частіше виникають ситуації, коли реальний світ набагато непередбачуваніший, …

14 design  dry  coupling 

Щоб уникнути нетривіального копіювання C ++, пов'язаного з const, чи бувають випадки, коли const_cast буде працювати, але приватна функція const, що повертає non-const, не буде? У пункті 3 ефективного С ++ Скотта Майєрса він припускає, що const_cast у поєднанні зі статичним складом може бути ефективним та безпечним способом уникнути повторюваного …

14 c++  dry  const 

Я завжди застосовував обмеження на рівні бази даних, крім моїх (ActiveRecord) моделей. Але мені було цікаво, чи справді це потрібно? Трохи фону Нещодавно мені довелося провести тестування базового автоматизованого методу генерації часових позначок для моделі. Зазвичай тест створює екземпляр моделі та зберігає її без перевірки. Але є й інші необхідні …

13 database  orm  validation  dry