vedesh-reddy/daily-leetcode

Purpose and Entry Points

This is a Java solution archive for daily LeetCode problems, not an integrated application or library. Each source file is an independent problem entry point intended for the LeetCode judge, with its own Solution implementation and any problem-required data structures.

The effective entry points are individual files under solutions/, for example:

• solutions/01.find-the-grid-of-region-average-medium.java

• solutions/26.design-an-atm-machine-medium.java

• solutions/61.adjacent-increasing-subarrays-detection-i-easy.java

Repository Organization Boundary

The repository has one architectural boundary: standalone submissions versus shared infrastructure. There is no visible build system, package hierarchy, shared Java module, test suite, service runtime, or application bootstrap. README.md only identifies the collection as daily-leetcode.

Because LeetCode commonly requires a class named Solution, these files should be compiled and evaluated independently rather than together; combining them in one Java compilation unit would likely create class-name conflicts.

Algorithm-Solution Units

Each numbered file represents one isolated algorithmic unit: input is supplied by the online judge, a method executes the solution, and the result is returned to the judge. Examples span core problem domains:

• Array, arithmetic, and greedy processing: solutions/02.number-of-sub-arrays-with-odd-sum-medium.java, solutions/16.maximum-number-of-weeks-for-which-you-can-work-medium.java, solutions/42.minimize-array-sum-using-divisible-replacements-medium.java

• String and parsing transformations: solutions/20.check-if-a-string-can-break-another-string-medium.java, solutions/52.split-two-strings-to-make-palindrome-medium.java

• Search and state-space traversal: solutions/12.sliding-puzzle-hard.java, solutions/53.shortest-path-to-get-all-keys-hard.java

Data-Structure-Centric Solutions

Several submissions implement or operate on judge-provided structural types, creating a boundary with LeetCode’s model classes such as linked-list, tree, iterator, or multilevel-node definitions:

• Trees: solutions/06.binary-search-tree-to-greater-sum-tree-medium.java, solutions/30.average-of-levels-in-binary-tree-easy.java

• Linked structures: solutions/14.linked-list-cycle-easy.java, solutions/54.flatten-a-multilevel-doubly-linked-list-medium.java

• Stateful design objects: solutions/26.design-an-atm-machine-medium.java, solutions/34.min-stack-medium.java, solutions/28.peeking-iterator-medium.java

Graph, Grid, and Dynamic-Programming Stages

The more complex units encode standard algorithm stages internally: construct/traverse a graph or grid, maintain search state, and return an optimal/reachable result. Representative implementations include:

• Graph reachability/path computation: solutions/11.shortest-path-with-alternating-colors-medium.java, solutions/44.reachable-nodes-in-subdivided-graph-hard.java

• Grid search: solutions/07.swim-in-rising-water-hard.java, solutions/27.word-search-medium.java

• Dynamic programming or combinatorial optimization: solutions/15.maximum-and-sum-of-array-hard.java, solutions/29.super-egg-drop-hard.java, solutions/51.count-of-integers-hard.java

Runtime and External Dependencies

The material runtime is Java under the LeetCode execution environment. Inputs, invocation, assertion, and model-type provisioning are external responsibilities of that judge. No databases, network APIs, cloud infrastructure, deployment artifacts, or third-party services are represented in the repository tree.