https://dsheiko.com/categories/software-design/ Recent content in Software Design on Dmitry Sheiko's Web Development Blog Hugo -- gohugo.io en-us Mon, 17 Feb 2025 00:00:00 +0000 https://dsheiko.com/weblog/refactoring-legacy-react-code/ Mon, 17 Feb 2025 00:00:00 +0000 https://dsheiko.com/weblog/refactoring-legacy-react-code/ When React Hooks arrived in 2019, switching to functional components seemed impractical. But as the ecosystem evolved, new techniques emerged. This article explores key strategies for migrating class-based components to modern React patterns—leveraging composition, useImperativeHandle, and function-based customization. Ready to embrace the future of React? https://dsheiko.com/weblog/second-wind-for-backbone/ Mon, 10 Oct 2016 00:00:00 +0000 https://dsheiko.com/weblog/second-wind-for-backbone/ I’ve been working with Backbone for years and it suited me pretty well. I do love its conciseness. It gives the desired abstraction and yet leaves you at the full control of your app. When you need to know what exactly is happening in your app behind your code, it’s matter of minutes to go though the Backbone annotated sources and figure out the flow. That’s something you hardly can afford with other frameworks such as Angular, React, Vue or Amber. https://dsheiko.com/weblog/modularizing-and-packaging-javascript-for-scalable-high-performance-web-apps/ Fri, 07 Nov 2014 00:00:00 +0000 https://dsheiko.com/weblog/modularizing-and-packaging-javascript-for-scalable-high-performance-web-apps/ Modules in JavaScript With the advance of MV* frameworks you can observe as JavaScript evolves ahead of official specs towards large scale development. It requires even higher level of maintainability and one of the first focuses here is encapsulation and information hiding. We need the code-base to be organized into independent, interchangeable components so that each of them contained code implementing only one aspect of desired functionality. Here comes to help the Module pattern. https://dsheiko.com/weblog/javascript-mv-framework-making-the-right-choice/ Fri, 06 Jun 2014 00:00:00 +0000 https://dsheiko.com/weblog/javascript-mv-framework-making-the-right-choice/ JavaScript frameworks have been proliferating recently with a frightening rate. Just take a look at TodoMVC that provides dozens of MV* framework-specific implementation for a single task. It gives a felling how must be confused a developer making a choice for a framework. Some time ago I even ran into a manifesto (http://bitworking.org/news/2014/05/zero_framework_manifesto) against JavaScript frameworks. I do not completely agree with the author, yet he has a point – it’s too many of them, too many of meta-languages to study that you as a web-developer may not need at all. https://dsheiko.com/weblog/modular-javascript-in-the-browser-with-commonjs-compiler/ Thu, 23 Jan 2014 00:00:00 +0000 https://dsheiko.com/weblog/modular-javascript-in-the-browser-with-commonjs-compiler/ JavaScript was designed as a script language that is easy to embed in a larger host system and meant to manipulate the objects of the host system. With the advance of HTML5 formerly mostly static web-pages are turning into sophisticated web-applications. Now we expect JavaScript code to be scalable and modular. But how when JavaScript has no built-in facilities to combine distinct scripts? Surely, you can insert a script element into the DOM and therefore have outer scripts loaded dynamically. https://dsheiko.com/weblog/javascript-asynchronous-dependency-loader/ Tue, 12 Mar 2013 00:00:00 +0000 https://dsheiko.com/weblog/javascript-asynchronous-dependency-loader/ Back in 2013, AMD was the standard approach for non-blocking script loading. It works well, but requires every dependency to be wrapped as an AMD module. That’s fine for your own code. For third-party libraries, it means patching external code just to satisfy a module format, which isn’t a trade-off worth making. So I built a small loader that works around this. Non-AMD libraries expose their API via globals, and all we really care about is knowing when they’ve finished loading. https://dsheiko.com/weblog/harmony-with-typescript/ Fri, 16 Nov 2012 00:00:00 +0000 https://dsheiko.com/weblog/harmony-with-typescript/ On the way to harmony Not so long ago Microsoft announced a new language targeting front-end developers. Everybody’s first reaction was “Why on Earth?!” Is it just Microsoft taking a shot at Google? Is that a trick to promote Visual Studio? But anyway, what’s wrong with JavaScript? Why is everybody so keen to replace it? For a language designed in just two weeks, JavaScript is freakishly powerful and flexible. It was released in December 1995 and standardized as ECMA-262 in June 1997. https://dsheiko.com/weblog/getting-started-with-typescript/ Fri, 12 Oct 2012 00:00:00 +0000 https://dsheiko.com/weblog/getting-started-with-typescript/ After Microsoft released TypeScript I took a look at their examples and found the idea pretty promising. I do love JavaScript. However, it has its bad parts. JavaScript doesn’t provide any built-in facilities to declare interfaces or object abstraction. There is no explicit way to have type annotations and type checking. Well, even class-based OOP is not a part of the language. Flexibility of JavaScript is incredible. So, there are tons of libraries meant to work-around these inconveniences. https://dsheiko.com/weblog/js-application-design/ Thu, 31 May 2012 00:00:00 +0000 https://dsheiko.com/weblog/js-application-design/ Make of JavaScript the language you need Any diligent developer is constantly working on improving his or her code. There are plenty of books telling how to make your code better. However most of them use the language of class-based OOP. Reader must have enough of experience to reflect those classical design patterns on JavaScript. Thus, many and many developers give up on the language before mastering its true power. https://dsheiko.com/weblog/prototypal-inheritance-in-javascript-for-modules/ Thu, 24 May 2012 00:00:00 +0000 https://dsheiko.com/weblog/prototypal-inheritance-in-javascript-for-modules/ The classical design of object in JavaScript can be expressed like: var ConstructorFunc = function () { var _privateMember = "private member"; } ConstructorFunc.prototype.publicMember = "private member"; ConstructorFunc.prototype.privilegedMethod = function () { return _privateMember; }; Pretty clumsy, isn’t it? I prefer the module design propagated so indefatigably by Addy Osmani (http://addyosmani.com/largescalejavascript/): var Module = function () { // Constructor's job var _privateMember = "private member"; return { publicMember : "private member", privilegedMethod : function () { return _privateMember; } } } It looks much nicer to me. https://dsheiko.com/weblog/design-by-contract-and-js/ Thu, 22 Dec 2011 00:00:00 +0000 https://dsheiko.com/weblog/design-by-contract-and-js/ Related articles: Prototypal Inheritance in JavaScript for Modules and Scalable JavaScript Application Design Design by contract (DbC) is an approach in application design, which originally came from Eiffel, but now widely used on different languages (particularly in Java). In real world one party (supplier) makes an offer for an agreement (business contract) and another one (client) accepts. The same way can be described relations between objects in software engineering. As a declared agreement is accepted by the client object, the last one is expected to keep its rules. https://dsheiko.com/weblog/extending-mvc-on-drupal/ Wed, 10 Nov 2010 00:00:00 +0000 https://dsheiko.com/weblog/extending-mvc-on-drupal/ Related articles: Drupal Meets MVC: A Smarter Way to Build Websites and When Great Ideas Meet Bad Code: A Look at Drupal I’ve already described an approach of using MVC in Drupal . It wasn’t bad for the beginning I hope. Though in real life you face requirements which hardly can be fulfilled with such a simplicity. In, more or less, complex application you ain’t going to be satisfied by the only controller (page controller) to serve the whole bunch of components presented on the page. https://dsheiko.com/weblog/mvc-on-command-line/ Tue, 15 Jun 2010 00:00:00 +0000 https://dsheiko.com/weblog/mvc-on-command-line/ If you work with Zend Framework, you likely tried ZF Console (Zend_Tool on command line). But have you tried to extend it? Why? To have common interface for all your Cli-scripts related to ZF-base project. How do you find the idea to program Cli-scripts in MVC? Zend Framework provides us with the tool to do it. First, you have to make ZF shell script zf.sh and assisting zf.php globally accessible. Wherever you have located them, just make a symlink on zf. https://dsheiko.com/weblog/feature-driven-development-for-web-developers/ Mon, 22 Dec 2008 00:00:00 +0000 https://dsheiko.com/weblog/feature-driven-development-for-web-developers/ Ten years ago, most web projects were static and development was relatively straightforward. That’s changed. The gap between web apps and desktop software has largely closed, functional complexity keeps growing, and the demands on teams have shifted accordingly. Projects run longer, involve more contributors, and carry backlogs that evolve well into development. Goals and stories shift, tasks change shape, and time-based estimates become unreliable. You could try fitting a heavyweight process like Rational Unified Process (RUP) or Process Mentor to this kind of work. https://dsheiko.com/weblog/aspect-oriented-software-development-and-php/ Wed, 08 Nov 2006 00:00:00 +0000 https://dsheiko.com/weblog/aspect-oriented-software-development-and-php/ Introduction Object oriented approach has been popular for a number of years. Its advantages can hardly be visible within short-term projects, yet any major long-term one simply cannot do without it. Object-oriented programming languages provide the tools necessary to present business logic in a demonstrable form. Today UML Class diagram (http://en.wikipedia.org/wiki/Unified_Modeling_Language) does suggest itself even on the stage of developing the system logic. Demonstrable business logic makes it easier for new participants to join in, helps to save time for those developers that come back into the project at later stages.