Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Projects to inspect to learn how to use oop principles and modular programming

Discussion in 'Scripting' started by hakankaraduman, Oct 20, 2017.

  1. hakankaraduman

    hakankaraduman

    Joined:
    Aug 27, 2012
    Posts:
    353
    Hi,

    I am working to improve my programming skills by integrating oop principles into my usual workflow, and also trying to create modular systems when I create a system for my game.

    I watch lessons on the internet about those but I feel like the very small, lesson specific projects on those lessons are not enough for me to understand those principles and use them in my own projects.

    Can you please recommend some assets on the asset store that it's worth to buy, to inspect and learn from the code structure of them. Or do you have other recommendations for me to improve my coding skills?

    Thanks.
     
  2. fire7side

    fire7side

    Joined:
    Oct 15, 2012
    Posts:
    1,819
    I don't know about the store, but some of the learn sections are pretty good if they do a full game. There is the tanks game, which I haven't done yet, and there is the Rogue game, which I am just going through. He uses abstract classes, generic functions, etc, in the Rogue game. My experience with the asset store aren't very good because when there is an upgrade there are a lot of errors and you have no idea where they came from. You get that anyway, I guess.
     
    Last edited: Oct 21, 2017
    hakankaraduman likes this.
  3. MaxGuernseyIII

    MaxGuernseyIII

    Joined:
    Aug 23, 2015
    Posts:
    315
    I'm not sure what kind of asset you could buy to this end. I can recommend some subjects and you can easily find very popular reading material in each of those topics.

    Code Qualities
    There are objective and subjective properties of code that make it easier to change going forward. These properties are collectively referred to as code qualities. A mountain of material can be found on this topic and it is a basic analytical framework that underpins and drives object-oriented programming and design, design patterns/pattern-oriented thinking, and even test-driven development.

    Design Patterns
    Going back as far as Christopher Alexander writing about architecture (real architecture, not software architecture), people have been moving how we think about design from bottom-up synthesis (taking little concepts and assembling them into something useful) to context-driven distinction (taking big concepts and dividing them up into smaller pieces that support the whole). At its core, Design Patterns is about making this mental shift.

    There are recurring problems in any kind of design-space, whether it is architecture, software, logo development, or carpentry. Collections of wisdom around how to wrangle the forces intrinsic to those problems accumulate until we have enough data to form what we call a pattern.

    For instance, a recurring problem is that you have a family of interchangeable algorithms and each variant has something in common but also has some parts that are different. That's the problem addressed by the Template Method pattern.

    The patterns, themselves, aren't really that important. They are just starting points and a mechanism for high-bandwidth conversation between professionals in the same or similar lines of work. The mental shift to attend to the primary forces in software development...that's the brass ring.

    Briefly, you want to design stuff from the outside-in rather than inside-out, find concepts that vary in your design and encapsulate the variation (hide that they vary from anything that need not know), and favor delegation between objects over inheritance wherever you can (meaning, use inheritance to categorize alternatives rather than to specialize from a generalization).

    Test-Driven Development
    Test-Driven Development (TDD) is, again, some useful advice that really becomes powerful when it triggers a mental shift. The shift here is in what you consider to be the primary or authoritative artifacts in your code base. A lot of people think of their production (or, in this case, game) code as the "real" code and everything else is kind of a second-class citizen.

    Once you've truly embraced TDD, you won't feel that way. Passing, meaningful tests (ones that define a single behavior and pass or fail based only on the presence or absence of that behavior) become your goal. If there's a second-class citizen in your code base, it's your production code. That's just this derivative stuff you have to do to get the next test to pass. Of course, you will never truly stop valuing your production code but, given enough time, you will probably start to consider it the lesser of two equals.

    People often confuse TDD with test-first. Test-first is a technique we frequently employ in TDD but it is not TDD. TDD is a lot more than that.

    One of the more important takeaways from adopting and embracing TDD is that your tests inform your design decisions. It is especially good at telling you when there is something wrong with your design. Understanding design patterns can help you figure out how to make it right.

    Once you've made the decision to change your design, you want to do so safely and, it turns out that good test coverage also helps you do that, too.

    Refactoring
    The other big spoke on the wheel of being a developer is refactoring. It's a word that gets bandied about a lot but it actually has a very specific meaning.

    Refactoring is a controlled, verified, behavior-preserving change to design. If you are changing behavior, you are not refactoring. That doesn't mean you're doing the wrong thing. It just means what you are doing is not refactoring.

    The nice thing about refactoring is that it is very safe. It is done in very tiny increments and each increment is nearly-instantaneously verified to be behavior-preserving. Because each step is so safe and you will so quickly get feedback when you've made a misstep, you can go fast. The same way that having brakes on your car gives you the confidence to drive at higher speeds than you would consider if you had to Fred Flintstone your way to a stop every time.

    A good rule of thump is that each change (unbroken interval of time during which your tests are not compiling and passing) should only either modify your tests or your production code but never both.

    Tying It All Together
    Google will give you reams of information on each of those topics. Heck, they are so prolific, even Yahoo! might.

    When you've studied and internalized all those things, you will be able to use TDD to get feedback about what's wrong with your design or your behavior, use design patterns to pick the right designs, use refactoring to safely move from one design to another, and attend to code qualities throughout.
     
    hakankaraduman likes this.
  4. hakankaraduman

    hakankaraduman

    Joined:
    Aug 27, 2012
    Posts:
    353
    Thank you very much for the detailed post. I read reading materials and watch video materials about those subjects. I'm having trouble to apply those techniques to my own applications. Because when those written or video materials describe those techniques, they show a codebase which is very small and specifically designed for that material's topic. That's why I wanted to inspect a few real time projects to understand how to apply it to a custom, big project.